지금 하나도 안된다고 인식하는 영역은

소프트웨어공학론에서 도출-분석-명세 단계인거 같은데 이 부분은 단순히 개발공부를 한다고 해결될문제가 아닙니다.

우선 어떠한 서비스를, 어떠한 플랫폼으로, 어떠한 기능을 같은 영역을 지정해야하는 부분을 기획/코드 작성 착수전에 명확히 하셔야하며

일반적인 인강이든 교재든 프로그램 개발 관련 공부라는 것들은 그런것들이 종료된 이후에 착수하는 내용들이므로 단순히 개발공부를 해서 현재 부족한것을 메꿀수 있는가하면 힘듭니다

당장 회사에서 안된다고 하는 영역을 공부하신다면 소프트웨어공학론에서 실제 언어나 프레임워크로 타이핑하기 이전에 하는내용들을 공부하시고 그것을 기초로 방향성을 명확히 하세요.

그리고 그 다음에는 아키텍쳐 기술자가 될 사람을 고용하든지 내부사람을 육성해서 전체적인 흐름을 구성하도록 해야하며 이 영역은 학원이든 인강이든 교재로 개발 공부한다고 가능한 영역이 아닙니다

그다음 하부 개발자들은 그렇게 만들어진 흐름속에서 자신의 파트를 개발해나갈수 있도록 해야합니다.

다만 체계화 시켜도 “ UI 분야는 그래픽 프로그램(스캐치, 피그마)을 공부해서 UI/Usercase 등 그려서 가져다 주고”이 부분은 개발에서 하려고하냐고하면 그래도 안할 가능성 큽니다.

ㅎㅎ 그 회사 개발팀은 뭐죠.

회사가 개발팀에 뭔 약점 잡혔나요? ㅋ

당연히 개발팀에서 해야 할 일을 기획으로 미루나요.

첫째, 개발 설계라는게 살짝 배워서 할 수 있는게 아니구요.

둘째, 기획팀장이 이번에 맘 먹은거 같은데, 따라줘야 하는게 아닐까요.

요구사항 말하는건 고객이나 하는 역할이니 패스. UI나 flow chart 이런 건 원래 PM/PL 그러니까 개발이 하는게 맞죠.

설계/분석인데 개발에서도 최고급 단계입니다... 

답변과 조언에 감사드립니다.

글을 쓰면서 다시한번 정리해보니

------

기획에서 말하는 요구사항 정리는 기획에서 SRS 형식으로 작성하여 개발로 넘어간다는 것을 의미하고,

(illuza 님 께서 말씀주신 요구사항 말하는건 고객이나 하는 역할은 조금 다른 느낌인게, 상기 글에도 명시하였지만, 정부에서 작성해놓은 요구사항 작성 가이드라인에 적합하게 작성하고 있습니다. 분야가, 의료쪽 소프트웨어라서 의료지식(의사의 진단 Logic)을 기능 구현으로 바꾸고, 이를 ISO 62304 및 ISO 14971, 기타 가이드라인 규격 참조해서 만드는 SRS이기 때문에, 일반 소프트웨어에서 말하는 요구사항이라는 단어와 동일하지는 않습니다.)

정확히 현재 문제가 되는 부분은 SRS 작성 후 이를 설계해야하는 SDS 를 개발에서 작성하지 않고, 기획에게 떠넘기다가, 기획팀장이 SDS까지 써주는거 안하겠다고 하고 이를 해결하러 다른 기획 팀원이 SDS (설계)를 직접하려고 하니 발생하는 문제인 것 같습니다.

------

개발자들을 멍청이들만 갖다 놨나? 아니면 월급도둑들만?

조그마한 기업에서 의사결정과 커뮤니케이션을 위해서 그렇게까지 비용을 지불해야 하는 상황이면 문제가 심각하네요.

그 정도 수준으로 문서작업을 할 거라면 기획팀 내부에서 개발자를 따로 뽑아서 직접 만드는게 비용이 적게 먹힐겁니다.

UI 분야는 그래픽 프로그램(스캐치, 피그마)을 공부해서 UI/Usercase 등 그려서 가져다 주고, 알고리즘이나 내부 로직의 경우도, Flowcart, 도식도 까지 그려서 가져다 줌

이건 정상이 아닙니다. :(

보통 그 반대인 경우가 많은데... (예를 들자면 개발자들이 기획까지 하거나...) 이런 회사도 있군요.

글을 보다보니, 궁금한 부분이 있는데, 다른 회사에서 개발자 분들이 생각하시는 요구사항과 설계? 의 경계를 좀 말씀해주실수 있을까요?

예를 들어서 저희는

간단하게 요구사항 주는 수준을 예시로 작성해보면 

----- 환자 정보 예시

1. 환자 정보 관리 프로그램(SFR - XXX)

 (1) 요구사항 분류: 기능 요구사항

 (2) 고유번호 : SFR-XXX

 (2) 요구사항 명칭 : 환자정보 관리(환자 정보 생성, 삭제 등 변경 관리)

 (3) 기능 구현(세부내용)  :

        1) 환자 정보 이름(생성, 수정, 조회, 삭제) : 고객용

        2) 환자 정보 일괄 확인 : 관리자용

        3) 환자 정보 분석 리포트 : 

 (4) 제약 사항 : 환자 이름는 개인정보보호법 상 가명정보 해당(가명정보 처리 필수)

 (5) 참고문서 : 개인정보보호위원회 가명정보 처리 가이드라인(첨부)(주요 부분은 캡처)                       

 (6) 관련 요구사항 : PER - XXX(성능 요구사항), INR - XXX(인터페이스 요구사항)

이런식으로 작성해서 요구사항을 넘겨주고 있고,(소프트 규모에 따라 상이 하지만, 수백개의 요구사항)

----------- 1차적으로 이렇게 하는게 맞는건가도 궁금하네요(다른 업체는 저정도 작성해서 보내면 저 기능이 구현되어 오는건지, 아니면 뭘 추가로 더 줘야하는건지?? >> 당연히 인터페이스쪽 가면, 그림에다가 기능 하나하나 매칭해서 보내줍니다.)

추가로

그동안의 작업은 저렇게 기획 주고, 예를 들어 보안 부분에 비밀번호 하드코딩 문제가 있으면

그러면 이제 어떻게 처리를 하는지까지 작성해서 넘겨줬던 겁니다.

(예를 들어 보안 가이드라인에,

  비밀 번호를 하드코딩 하지 말것 >>> 블로그 등 수집해서, 하드코딩하지말라는 것의 의미, 예시 코드 등  수집해서 추가 문서 만들어줌)

제 생각은  기획팀이  엑셀로  화면 그리는것  

버튼 위치 및  기능설명등 

그리고 위 그림의 flow chart 정도는 기획팀이 하는거죠

전산팀은  디비 erd 설계,  sql 작성등 기술적 부분만 하고 

개발자 아닌 일반인 시각으로  엑셀에 화면을 그리는것  입니다.  화면 작동방식도  일반인 비전공자 관점으로 세밀히 기록 하구요

말씀하신 것이 불가능하거나 말이 안되는 것은 아닙니다만,

그게 가능하려면 말씀하신대로 기획팀에서 개발/설계 능력이 있어야 하구요.

보통 그런 조직에서는 개발팀 파워가 약하거나 개발조직이 아예 없이 외주를 줘서 만들죠.

기획팀에서 알고리즘과 내부 로직까지 해서 주는데 개발팀 인력이 고급일 필요가 없거든요.

같은 회사 직원들인데 비밀번호 하드코딩 하지 말라고 하면 그냥 알아들어야죠... ㅠㅠ

아니면 그런 경우에 대한 일반적인 처리 대안을 개발팀에서 제시를 하고, 기획팀에서 판단해서 결정하면 될 일이지...

그걸 세부적으로 가이드라인을 만들어서 문서 작성을 해서 넘겨준다고요? ㅠㅠ 아...

조금 양보해서 큰 회사라면 그렇게 할 수도 있어요.

책임소재라는가 일정관리라든가 뭐 그런 것들을 위해 근거자료를 많이 만들어야 한다고 하면요.

근데 조그만 회사라고 하셨는데 같은 회사 내부에서 일을 그 정도까지 세세하게 문서로 남겨서 진행을 한다고 하면 그게 잘 될런지...

그럴거면 기획팀에서 내부 개발자 뽑아서 문서 만들지 말고 말로 바로 바로 지시하고 구현 결과물 확인하면서 진행하는게 나을걸요.

제가 개발팀인데, 기획팀에서 알고리즘과 내부 구현까지 고민해서 문서를 만들어 가져온다고 하면...

'아 이렇게까지 하실 필요 없어요.'라고 말할 것 같고,

계속 그런식으로 하면 '개발팀을 무시하나' 하는 생각마저도 들 것 같은데요?

제 경험상 SI에서는 "기획팀"이라는 말을 잘 안쓰는 것 같습니다. 요구사항 도출과 요구사항 명세는 당연히 고객, 흔히 현업 담당자들과 협의하여 시스템 분석설계자가 문서화해서 산출물로 만드는 것이고 그것을 기반으로 기능명세 같은 것들이 나오고 또 프로그램 명세서가 나와서 결국 개발자가 그것을 보고 개발을 하는 것이죠.

그러니까 경계를 나누자면 시스템 설계는 개발 영역이긴 한데 그 "개발" 영역이라는 것도 설계 산출물을 작성하는 사람들과 실제 프로그램을 구현하는 것이 또 분리되서 서로 다르게 생각하는 경우도 많습니다. 예를 들어 설계만 하고 철수하는 사람들이 있고 이후에 "개발자"가 들어오는 경우도 있거든요. 

시스템을 구현하려면 현업, 흔히 개발 지식이 거의 없는 사람들로부터 요구사항을 듣고 그것을 조금씩 조금씩 구체화시켜서 결국 코드로 구현되게 하는 과정 전체가 개발 영역의 몫일 수 밖에 없습니다. 본문의 내용으로 미루어 짐작컨데 시스템 설계와 개발 경험이 있는 사람이 필요한 상황인듯 합니다. 앞에 답글 주신 분들 말씀처럼 이것은 책이나 단순한 학습을 통해서는 어렵지 않을까 하네요. 글쓴 분은 기획자에 가깝게 보이고 실제 구현되는 시스템을 그리는 것이 막막하다면 그건 기획자의 역할이 아닌 것이죠.

답변에 다시한번 감사드립니다.

현실적으로는 어렵더라도 소프트웨어 공학론을 공부하면서, 시스템 설계 관련 인원 채용을 회사에 요청할 수 밖에 없어보이네요.

----

일단 저희쪽 업계에 살짝 첨언을 하면,

의료 소프트웨어의 경우 제품을 만들더라도 반드시 식약처의 허가를 받아야 팔수 있고(허가를 못받고 팔면 불법),

허가 과정에서 개발 ~ 생산 ~ 판매 ~ 조직운영 까지의 제품 수명사이클 전체에서 나오는 산출물(문서 등)이 심사대상입니다.

에를 들어 개발파트의 경우 기획안 ~ 중간중간 회의록, SRS, SDS, Unit Test, 시스템 테스트 등 62304 규격에 따른 90여종의 개발문서가 허가 과정에서 전부 제출되어야 하는 최소자료입니다.

소위 폭포수 모델이라고 불리는 개발 Flow 에서 나와야하는 모든 문서 입니다.

----

살짝 그 개발 팀장 실력은 모르겠지만 게임 개발 쪽의 어설픈 프로세스를 따라하는거 같기도 합니다.

게임은 기획에서 GUI /시나리오 등등이 어느정도 완성이 되어야 하는걸로 알고 있습니다. 여기서 함정은 각각의 기획자 및 외주가 다 따로 따로 준비가 되어있다는거죠. (시나리오 기획자. GUI 담당자 등)

의료 소프트웨어라는 업계의 차이가 있긴 하네요.

그런데 폭포수 모델이라고 하면 더더욱 초기 설계에 개발 역량이 있는 조직이나 인원의 참여가 필요하다고 생각합니다.

개발쪽 커리어가 없으신 분이 그런 일을 책임지고 해야 한다면 당연히 괴로울 수밖에 없고 사표쓰겠다는 말이 나올수밖에 없습니다.

그 사표쓰신다는 분에게는 안 됐지만, 그런 분이 여럿 나와야 그 회사가 바뀌겠네요...