성공적인 소프트웨어 신상품 개발가이드
1) 일정계획을 수립하는 목적
완성된 일정계획은 다음과 같이 활용한다.
- 팀원들이 맡은 일을 언제까지 일을 끝내겠다는 약속을 공유한다.
일정계획은 프로젝트 관리자가 팀원들에게 일방적으로 지시하면 안 된다. 팀원들의 의견과 가정 사항들을 반영한 일정계획을 상향식으로 취합하여 조정하는 것이 바람직하다. 팀원들의 의지를 반영한 일정계획은 팀원들이 일정준수를 위해 노력하겠다는 약속을 담고 있다. 합의 없이 일정을 일방적으로 지시하면 일정지연 시 일정준수를 위해 노력하기 보다 일정지연의 핑계를 외부에서 찾는다.
- 작업 진척상황을 판단하는 기준으로 활용한다.
일정계획이 없으면 작업이 제대로 진척되고 있는지를 판단할 기준이 없어진다.
- 팀원들이 맡은 일에 대한 계획과 진척을 공유하는 수단으로 활용한다.
프로젝트 팀원들이 일정계획을 공유하면 각자가 전체 프로젝트에서 어떤 기여를 해야 하는지, 나의 업무와 연관된 다른 업무가 무엇인지 파악할 수 있다. 또한 상품개발 외부 조직에서는 QA, 구매, 마케팅의 시기도 결정할 수 있다.
- 이해관계자 기대수준을 관리할 수 있다
프로젝트 일정은 상품개발팀과 외부 이해관계자가 합의한 결과이기 때문에 일정에 대한 이해관계자의 기대수준을 확인할 수 있다.
- 불확실성을 관리할 수 있다
수립된 일정계획을 분석하여 위험을 식별하기도 하고, 이슈가 있는 경우 관련된 활동의 기간을 늘려 위험 대응수단으로 활용할 수도 있다.이상의 내용을 종합한 프로젝트 일정계획의 활용 용도는 아래 그림과 같다.
2) 달성해야 하는 일정과 달성할 수 있는 일정의 차이
일정에는 ‘달성해야 하는 일정’과 ‘달성할 수 있는 일정’이 있다. 간혹 ‘달성해야 하는 일정’이 없는 경우도 있지만 드문 경우이다. ‘달성할 수 있는 일정’은 전제조건과 달성가능성을 포함한다. 대표적인 전제조건의 예는 해당 작업을 수행하는 인력과 투입비율(예:전담), 필요한 정보 제공시기 등이다. 달성가능성은 사람에 따라 다르다. 90% 가능성을 염두에 두고 달성 가능하다고 말하는 사람도 있고, 50% 가능성을 염두에 두고 달성 가능하다고 말하는 사람도 있다. 제약조건의 관점에서 살펴보면 ‘달성해야 하는 일정’은 ‘일정 제약’이고 ‘달성 할 수 있는 일정’은 ‘자원제약’의 상황이다. 아래 그림의 왼쪽은 주어진 자원으로 달성 가능한 일정을 수립하는 과정을 설명하고 있고, 오른쪽은 주어진 일정을 달성하기 위한 자원을 도출하는 과정을 설명하고 있다.
신상품개발 일정계획 수립 시 ‘달성할 수 있는 일정’을 정확하게 분석 한 후 ‘달성해야 하는 일정’과의 갭을 줄여야 한다. 갭이 작을 경우에는 상품개발팀의 노력을 전제로 일정준수를 약속 할 수 있지만, 갭이 클 경우에는 범위를 줄이거나 자원을 추가하여 갭을 줄여야 한다.
달성 가능한 일정과 달성해야 하는 일정의 갭이 발생하는 이유는 달성해야 하는 일정을 제시하는 경영층과 달성 가능한 일정을 제시하는 상품개발팀의 인식이 다르고 적정 일정에 대한 기준이 없기 때문이다. 경영층 또는 마케팅은 비즈니스 환경을 이유로 빠를수록 좋다는 식으로 신상품 출시일정을 제시하고, 상품개발팀은 과거 경험에 근거한 일정에 약간의 버퍼를 추가한 일정을 제시한다. 최악은 상품개발팀에서 제시한 일정을 비즈니스 상황에 대한 설명 없이 경영층이 상품가격 협상하듯이 “2개월 당기세요” 라고 말하는 상황이다. 경영층이 일방적으로 일정단축을 강요하면 상품개발팀의 자존감이 낮아진다. 프로젝트에서 갈등을 유발시키는 가장 큰 요인이 ‘일정’인 이유가 여기에 있다.
일정계획이 협상의 대상이 되는 것을 예방하려면 상품개발팀과 이해관계자들이 달성 가능한 일정이 어떤 근거에서 도출되었고, 어느 정도 신뢰성이 있는지를 공감해야 한다.
3) 일정계획 수립을 위해 필요한 요소
일정계획 모델을 구성하는 요소는 WBS, 자원, 작업순서, 작업의 수행기간이다. 예를 들어 오토 캠핑장에서 저녁식사를 준비한다고 생각하자. 식단은 김치, 갈비탕, 갈치조림, 밥이다. 김치는 가져왔으나 나머지는 모두 직접 조리를 해야 한다고 할 때 저녁 준비시간은 어떻게 계산할까? 저녁시간을 계산하기 위해 최종적으로 필요한 데이터는 요리순서와 요리별 소요시간이다. 소프트웨어 상품개발에 비유하면 상품요구사항 개발을 위한 작업순서와 작업시간이다. 이상을 요약하면 아래 그림과 같다.
- 작업순서
하드웨어 상품을 개발하거나 건물을 짓는 경우 작업 순서가 일정계획 수립에 미치는 영향이 크다. 예를 들어 아파트 건설은 ‘토목공사 → 골조공사 → 창호공사 …’의 순서로 진행하며 선행작업이 지연되면 후행작업 착수가 지연되는 경우가 대부분이다. 따라서 각 작업의 순서를 임의로 진행할 수 있는 경우와 아닌 경우를 구분하여 일정계획을 수립하는 것이 중요하다. 반면 소프트웨어 개발은 작업순서가 복잡하지 않고 작업순서에 제약이 많지 않다.
- 작업시간(작업기간)
작업시간을 결정하기 위해서는 작업규모에 대한 정보와 작업을 수행할 자원에 대한 정보가 필요하다. 자원에 대한 정보는 해당 작업을 수행할 자원의 유형과 자원의 양을 의미한다. 건설에서는 인적자원과 물적자원에 대한 정보가 중요하지만 소프트웨어 상품개발의 경우 인적자원에 대한 정보가 중요하다. 일정계획 수립 시 작업시간 추정이 어려운 이유는 작업의 규모와 작업생산성을 추정이 힘들기 때문이다
https://brunch.co.kr/@kbhpmp/160