개발 순서의 결정
쉬운 것부터? 어려운 것부터?
같은 회사의 동료 PM이 나에게 물었다.
"프로젝트에서 개발 순서를 정할 때 쉬운 것부터 해야 하나요? 어려운 것부터 해야 하나요? 그런 경우에 PMBOK에는 어떻게 하라고 나와있나요?"
그 때 내가 했던 대답은
"PMBOK에 일정수립시 우선순위에 대해서 나온 부분은 잘 기억이 나지 않는데, 리스크 관리 관점에서는 구현상 문제가 있거나 리스크가 있는 부분은 먼저 찾아내서 기술검증부터 해봐야 할 것 같은데요?"
라고 대답했다. 당시에는 나름 괜찮은 대답이라고 생각했지만, 자리에 돌아와서 그 질문에 대해 다시 생각해보니, 그리 틀린 답은 아니지만, 완벽한 답도 아니었던 것 같다. 그 질문에 대해서 다시 생각을 정리해보려고 한다.
개발 순서를 정할 때,
1. 개발범위 리스트 정리
- 일단 전체의 개발대상 범위를 결정해야 한다.
- 전체 개발범위를 분해하여 상세 개발리스트를 작성한다.(WBS와 연계)
- 각 개발리스트에 대해 예상되는 대략적인 공수(MD, ManDay)를 부여한다.
2. 리스크 항목의 도출 및 검증
- 전체 개발대상 범위 기능 중에서 기술적으로 구현상 문제나, 리스크가 있는 부분이 있는지 뽑아내고, 그 기능에 대한 구현을 우선적으로 수행할 필요가 있다.
- 일정상 구현을 완료하기 어려우면, 구현가능여부를 판단하기 위한 검증만이라도 수행해야 한다.
- 만일 해당 기능이 덩어리가 너무 크거나, 난이도가 너무 높아서 일정을 추정하기 어렵고, 프로젝트팀 내부에서 추진하기 어렵다면, 별도의 개발자를 배정하여 전체 프로젝트 일정과 상관없이 진행시킨다.(연구소 인력 등)
3. 우선순위 부여
- 전체 개발 범위 중 리스크 항목을 제외한 나머지 개발목록에 대해서는 후속작업이 필요하여 먼저 개발해야하는 부분과, 후속작업으로 개발해야하는 부분을 제외시키면, 전체 개발범위 중 우선순위에 상관없는 개발목록을 도출할 수 있다.
먼저 개발해야 하는 부분 : 엔진 및 인터페이스에 연관된 부분, 화면공통부분(화면 구성상 지속적으로 재활용되는 화면요소)
늦게 개발해도 되는 부분 : 기능은 고객의 요구사항에 없으나 실제 운영할 때는 필수적인 기능, 당장 서비스오픈에는 문제가 없는 기능, 야간에 수행되는 백업이나 Batch로 실행되는 작업에 대한 관리기능, 관리자 기능 등
- 이와 같이 먼저 개발해야하는 부분과 늦게 개발해도 되는 부분을 나누고 나면, 우선순위에 상관없는 개발목록이 도출된다. 우선순위에 상관없는 항목에 대해서는 소요시간이 짧고, 난이도가 낮은 것부터 개발하는 것이 좋다. 개발자가 프로젝트에 적응할 시간을 주는 것이다.
- 실제로 개발초기보다 중반부 이후에 개발자의 생산성이 더 높아지는 경우가 많다. 프로젝트에 적응도 안된 상태인데 덩어리가 너무 큰 개발건을 초반부터 진행하면 개발진행이 예상보다 지연되는 경향이 있는 것 같다. 초반부터 공정률을 까먹을 필요는 없으니, 쉬운 것부터 진행하는 게 좋을 것이다.
4. 일정 및 개발자 자원배분 조정
- 이렇게 우선순위에 따라 개발일정을 조정하고 나서, WBS에 반영해보면, 실제로 예상되는 개발완료일정을 추정할 수 있는데, 대체로 납기를 지키기 어려운 것으로 추정되는 경우가 많다. 또한, 모든 자원(개발자)에게 고르게 업무가 배포되지 않았을 수도 있다.
- 이런 경우에는 개발자에 대한 자원배분을 조정하거나, 개발규모를 다시 확인하고, 일정을 조정하여 납기를 준수할 수 있는 일정으로 만들어야 한다.
- 도저히 납기준수가 어려운 것으로 추정된다면, 인력이 부족하거나 개발기간이 너무 짧은 것이므로 대책을 마련해야 할 것이다. 그 대책에 대해서는 앞 장에서 얘기한 바 있으므로 생략한다.
