성공적인 소프트웨어 신상품 개발가이드
프로젝트 일정계획 수립 시 유의할 사항은 다음과 같다.
- 정밀한 일정이 정확한 일정은 아니다
프로젝트 회의실 벽면을 가득 채운 복잡하고 정교하게 보이는 일정이 정확한 일정은 아니다.
요한나 로스먼 (Johanna Rothman)은 “간트 차트의 아름다움이 사람들의 눈을 멀게 해서 일정이 단지 추측이라는 사실을 가려서는 안된다”고 하였다. 대충 정확한 계획도 있고, 복잡하고 정밀하지만 매우 틀린 계획도 있다. 프로젝트 관리자가 정밀하고 상세한 일정계획에 집착하는 것은 바람직하지 않다. 미래에 발생할 모든 일을 고려한 일정계획 수립은 어차피 불가능하다. 일정 수준의 신뢰성을 갖춘 프로젝트 계획으로 프로젝트를 착수하여 목표를 맞추기 위한 노력을 하면서 계획을 변경해야 한다.
- 빠른 출시가 능사가 아니다.
Time to market은 '빠른 출시'의 의미로 많이 사용하는데 '적기 출시'가 정확한 의미다. 우리는 일정준수를 중요하게 생각하지만 어떤 이유나 배경에서 목표 완료일을 결정하는지, 1~2개월 늦추면 비즈니스 관점에서 어떤 영향력이 있는지 정확하게 설명 못하는 경우가 많다. 기 출시된 상품의 개선은 빠른 것이 좋지만 신상품은 적기출시가 중요하다. <카카오 이야기, 2016>에서는 적기 출시에 대해 다음과 같이 설명하고 있다.
시장의 선택을 받아야 하는 제품이나 서비스는 최초 타이틀이 좋은 것만은 아니다. 최초이기 때문에 인지도를 확보하는데 어려움을 겪고 가격이 비싸게 결정되는 경우가 많다. 무조건 처음을 고집하기 보다 적절한 타이밍에 진입하는 것이 효과적이다. 카카오 톡, 웨이신, 라인 모두 최초가 아니었다. 아이폰도 최초의 스마트폰이 아니었다. 1993년 IBM의 '사이먼'은 이메일, 팩스, 계산기, 메모장을 갖춘 스마트폰의 원형이었다. 당시 휴대폰에는 전화를 걸고 받는 기능만 있었다. 하지만 개발비가 많이 들고 수요가 많지 않아 사이먼은 역사속으로 사라진다.
- 상품개발 규모를 최소화한다.
상품개발 규모가 커질수록 복잡도가 증가하여 프로젝트 일정계획의 불확실성이 높아진다. 뿐만 아니라 개발규모가 커지면 투입인력 증가, 의사소통 오류 증가, 리스크 증가로 인해 일정통제도 어려워진다. 어느 정도가 적정한 개발규모인지는 상품개발 유형에 따라 달라진다. 소프트웨어 상품개발의 경우 기간은 6개월 이내, 인원수는 피자 두판의 원칙에 따라 7~10명 이내로 수행 가능한 개발규모가 적당하다. 1년을 목표로 개발 하더라도 기능의 우선순위에 따라 2~3개의 프로젝트로 나누어 진행하는 것이 일정계획 및 통제가 용이하다.
- ‘할 수 있는 일정’과 ‘해야 하는 일정’을 절충한다
‘할 수 있는 일정’이란 경영층이 프로젝트 관리자에게 “이 작업을 언제까지 완료할 수 있습니까?”라고 물었을 때 프로젝트 관리자가 상향식으로 일정계획을 수립하고 거기에 버퍼를 추가한 계획을 의미한다. 반면, ‘해야 하는 일정’이란 프로젝트 관리자에게 주어지는 ‘일정 제약조건’을 충족시키기 위해 하향식으로 수립한 일정계획을 의미한다. 프로젝트 관리자는 외부의 제약조건과 내부의 역량을 고려한 일정을 절충해야 한다. 외부의 제약조건을 그대로 받아들여서도 안되고, 팀원의 보수적인 일정을 주장해서도 안 된다. 행복한 프로젝트는 이러한 고민을 할 필요 없이 여유 있는 일정으로 시작하는 프로젝트다. 반대로 불행한 프로젝트는 일정의 여유가 있는지 없는지도 모른 채 결과를 운에 맡기고, 의욕만 가지고 시작하는 프로젝트다.
- 프로젝트가 불확실할수록 마일스톤은 자주 많이 계획한다.
프로젝트가 불확실하고 변경 가능성이 높을수록 마일스톤을 자주 많이 계획하는 것이 좋다. 마일스톤을 자주 많이 계획하면 품질검토 주기도 짧아져 프로젝트 리스크를 조기에 파악하여 대처할 수 있다. 애자일 방법론의 점검주기는 스프린트 주기와 동일하며 폭포수 방법론의 점검주기는 단계별 검토 또는 중간 고객검토 주기와 동일하다.
- 납기를 연말이나 반기말로 하는 것에 유의한다.
연말이나 반기말로 납기를 설정하면 납기일에 다른 일이 몰릴 수도 있고 다 같은 지연도 느낌이 다르다.
https://brunch.co.kr/@kbhpmp/160