제품 개발 프로세스 #3

오늘도 어제 못다한 개발프로세스를 계속 진행해 볼까 합니다.

어제까지의 과정을 정리해보면 먼저 제품기획이 완료되고 SRS가 작성이 되면 개발계획서를 작성한다고 했습니다. 이 단계 이후에는 각 개발 관련 팀들이 맡은 일을 진행하게 됩니다.

영업팀 : 사전 영업

마케팅팀 : 제품 마케팅 계획 수립 및 진행

디자인팀 : 제품의 UI 설계와 그래픽 작업에 착수 ( SRS에 화면 요구사항이 있습니다. )

QA팀 : 테스트 계획 및 설계 / 버그관리 계획

형상관리팀 : 프로젝트 형상관리에 필요한 소스트리를 생성할 것입니다.

빌드팀 : 통합빌드 시스템에 빌드 스크립트 작성

TW ( Technical Writer ) : 사용자 설명서 , 도움말 제작 ,  번역

고객 지원팀 : 제품 지원에 대한 가이드 작성

기술 지원팀 : 제품의 설치 사양 및 운용방법 확인 및 설치 테스트

개발팀 : 시스템 설계 - 구현 - 테스트

*상기의 제품팀명은 제가 역할에 맞도록 가상으로 만든 것입니다.

굉장히 많은 팀들이 개발에 관여하기 때문에 지난번에도 말씀드렸지만 개발계획서는 매우 중요합니다.

그래서 각 팀의 일정 준수 자체가 완벽하게 이루어지지 않으면 계획된 기간내에 출시가 안되는 심각한

상황이 발생 할 수 있습니다. 또한 프로젝트 관리자의 소속이 별도의 PMO 조직인 경우도 있지만 그렇지

않은 경우도 있어 팀간의 갈등이 생겼을 경우 이를 해결하는데 많은 시간이 소모되기도 합니다.

위와 같은 이유로 개발계획을 산정할 때 별도의 여유 일정을 잡게 되는데 , 이렇게 잡게된 여유 일정이 나중에는 출시를 기다리는 영업/기획팀과 개발팀들간에 심각한 갈등을 일으키도 하고 , 연구소(개발조직)에 대한

경영진의 불신을 불러오는 계기가 되기도 합니다. 여하튼 그런 내부적인 문제들이 발생 할 가능성이 있기

때문에 팀간의 협업, 관리자의 사내 커뮤니케이션이 매우 중요하다고 할 수 있습니다.

다시 개발팀만을 중심으로 설명을 드리면 , 이어지는 단계는 제품 설계입니다.

제품 설계 즉 시스템 설계는 정형화된 방법이 없다고 말씀 드리는 것이 옳을 것 같습니다. 다만 이러이러한

형태로 , 방향으로 가야 하다는 정도는 말씀을 드릴 수가 있겠습니다.

시스템이라는 것은 , 지난번 글 제안서쓰기에서 언급했듯이 , 더 작은 서브시스템으로 나뉘어 질 것입니다.

이렇게 나뉘어 지게 되면 각 서브시스템을 연결해 주는 인터페이스가 생기게 되는데 , 설계는 이러한 서브 시스템의 명세와 인터페이스의 규약의 합으로 정의 할 수 있습니다. 여기서 다시 서브시스템은 더 작은 서브시스템으로 나뉘게되고 계속해서 이러한 방법으로 전체 시스템을 클래스 수준 또는 모듈의 수준까지 나누는 것이 좋을 것 같습니다.

설계를 어떠한 수준까지 명세를 남겨야 되는 것에 대해서는 이견이 있을 것 같습니다. 또한 프레임워크 같은 사전 설계된 시스템을 재사용하게 될 경우에는 극단적으로 시스템 설계를 건너 뛸 수도 있을 것 같습니다.

또다른 관점으로 설계서의 작성 수준을 이야기 하는 경우도 있습니다. 구현 단계에서 외주를 이용하는 경우에 해당 할 수 있는데 이런 가정이라면 설계서의 수준은 개발계획서에 명시된 조건을 갖춘 개발자가 별도의 설명 없이도 구현을 할 수 있는 수준까지 일 것입니다.

설계에 관해서는 이것으로 줄이도록 하겠습니다.

다음 단계로는 구현의 단계입니다.

이 부분은 다음글에서 계속 하도록 하겠습니다.