77. 상품개발 계획 수립 시 유의사항
성공적인 소프트웨어 신상품 개발가이드
신상품의 특성, 제약조건, 개발팀의 역량을 고려하여 신상품 계획을 수립해야 한다. 다음은 상품개발 계획 수립 시 유의할 사항들이다
- 성공을 보장하는 프로세스(은총알, silver bullet)는 없다.
몸에 좋다는 보약을 먹는다고 건강이 좋아지는 것을 보장할 수 없듯이 성공을 보장하는 프로세스도 없다. 산삼도 체질이 맞지 않으면 부작용이 있듯이 좋은 프로세스도 마찬가지이다. 애자일 방법론이 확산되면서 애자일은 무조건 좋은 것이라는 오해가 많다. 팀원과 관리자의 역량이 있어야 하고, 형식이 아닌 본질에 대한 공감도 있어야 한다. 수단이 목적으로 바뀌면 프로세스 적용자체가 목적이 되고 의미 없는 회의, 자발적이지 않은 교육, 겉치레적인 고객 VOC 분석만 있을 뿐이다. 상품개발팀의 문화와 역량에 잘 융합될 프로세스를 상품개발 계획서에 반영해야 한다. 그 숙제는 어느 누구도 대신할 수 없고 프로젝트 관리자가 팀원과 함께 결정해야 한다.
- 상품개발 계획의 가정은 최소화하고, 명확하게 문서화한다.
상품개발 계획을 빨리 확정하기 위해 가정을 사실로 판단하면 상품개발 계획서의 예측가능성은 낮아진다. 왜냐하면 사실로 판단한 가정이 미래에 어떻게 될지 모를뿐더러 안다고 해도 상품개발 계획서에 조건부 목표를 반영하기 힘들기 때문이다.
예를 들어 A라면 개발기간이 10개월이고, B라면 개발기간이 8개월이라고 정의할 수 없다는 것이다. 프로젝트 관리자가 B를 가정하고 8개월을 목표를 설정하면 가정은 잊히고 목표만 기억되는 경우가 많다. 중요한 결정은 시간이 허용하는 최후의 순간까지 미루는 것이 좋다. 또한 프로젝트 성과에 영향을 미칠 수 있는 중요한 가정들을 별도 페이지에 명확하게 기술해 두는 것이 좋다. 그 이유는 개발계획 수립 시 가정들이 적합한지 검토해야 하고, 프로젝트를 진행하는 과정에서도 가정들이 유효한지 정기적으로 검토해야 하기 때문이다. 상품개발 계획서의 예측가능성은 가정이 작을수록 높아진다. 상품개발 계획의 예측가능성에 영향을 미치는 각종 가정의 예는 아래 그림과 같다.
- 상품개발 계획서는 평가의 목적보다 프로젝트 수행을 위한 목적으로 작성한다.
상품개발 계획서는 특정 시점에서 주어진 정보를 바탕으로 수립한 것이기에 불확실성의 편차가 크다. 계획수립 시점에서는 편차의 크기를 가늠하기 힘들 뿐이다. 이러한 불확실성을 감안할 때 목표달성을 독려하기 위한 평가수단으로 상품개발 계획서를 활용하면 다음의 부작용이 생길 수 있다.
• 상품개발팀은 원가, 일정, 인적자원의 추정치에 버퍼를 반영한다.
상품개발 계획서의 내용을 달성하지 못할 경우 프로젝트 팀이 불이익을 받는다면, 상품개발팀과 프로젝트 관리자는 불확실한 미래에 대비하기 위해 자원과 시간 추정시 각종 버퍼(일종의 보험)를 반영한다. 물론 경영층도 이를 알기에 프로젝트 관리자가 수립한 계획을 그대로 승인하지 않고 일정비율(예:10%)을 삭감한다. 이렇게 상품개발 계획이 협상의 대상이 되어 버린다. 일부 순진한 프로젝트 관리자는 피해를 보고, 정치적인 프로젝트 관리자는 더 많은 버퍼를 숨기거나 정당화하는 논리를 개발한다.
• 객관적으로 확인하기 힘든 추정의 신뢰성 때문에 조직 내 갈등이 발생한다.
상품관리자, 프로젝트 관리자, 경영층이 일정과 예산 추정치에 대해 불신하면 갈등이 발생하고 이는 이해관계자들의 팀웍을 저하시키는 요인이 된다. 또한 추정치에 대해 누구 말이 맞는지 확인할 방법도 없어 이러한 불신은 일상이 될 수도 있다.
• 상품판매의 성공보다 상품개발의 성공을 우선시한다.
상품은 판매하기 위해 개발하는 것인데, 개발팀을 개발목표 준수여부로 평가하면 개발팀은 잘못된 기능을 일정 내 개발하는 것에 집중할 수 있다. 예를 들어 평가지표가 ‘계획된 상품 요구사항의 납기준수율’이라면 상품 요구사항 변경이 어려워진다. 일단 평가목표가 되면 변경절차도 까다로워지기 때문이다. 따라서 상품기획, 상품개발팀의 평가기준은 ‘경제성 지표’로 설정하는 것이 바람직하다.
• 계획준수에 대한 압박은 마지막까지 문제를 숨기도록 만든다.
한번 수립한 계획에 대한 변경은 있을 수 없다는 조직문화에서는 프로젝트 관리자가 마지막까지 문제를 숨기도록 만든다. 어차피 중간에 말하면 끝날 때까지 각종 보고에 시달리기 때문에 매를 맞더라도 마지막에 맞는 게 좋다고 생각하기 때문이다.
영화 '기생충'에서 아버지(송강호역)가 체육관에 누워 아들(최우식 역)에게 이야기하는 다음의 대사는 새겨볼 만하다.
“아들아 가장 좋은 계획이 뭔 줄 아니? 무계획이다.
계획을 세우면 반드시 계획대로 안되고, 실망하게 되어있어”
- 개발계획의 상세화 수준을 다르게 한다.
대부분의 프로젝트에서 가까운 미래는 상세한 계획을 수립할 수 있지만, 먼 미래는 개략적인 계획을 수립할 수밖에 없다. 예를 들어 스프린트 주기가 1개월이고 전체 개발기간이 4개월인 상품개발을 가정할 때 스프린트 1은 개발할 상품 요구사항과 일정이 있지만 스프린트2는 상품 요구사항만 있고 개발일정은 스프린트 1이 끝날 시점에 정의할 수 있다. 스프린트 3과 4는 상품 요구사항도 미배정 상태일 수도 있다.
만일 주어진 정보로는 위와 같은 계획을 수립할 수밖에 없는데 무리하게 아래 그림과 같은 계획을 수립하면 계획수립 기간이 길어지고 변경사항 발생시 이해 관계자들과 계획 조정을 위한 의사소통 낭비가 발생하게 된다. ‘계획 상세화’와 ‘계획 변경’은 어감이 다르다. 위의 경우에는 변경이 아니라 계획을 점진적으로 상세화 하는 것이고 이래의 경우에는 처음부터 상세한 계획을 수립했기에 계획변경이 된다. 상품관리자나 프로젝트 관리자에게 ‘계획 변경’은 좋은 단어가 아니다.
점진적 계획수립의 장점은 다음과 같다.
• 계획수립 시간을 최소화한다.
• 정보가 확실해지는 시점에 의사결정을 내리기 때문에 변경 가능성이 낮다.
• 계획준수에 대한 부담 및 부작용을 최소화한다.
상품개발 계획의 불확실성을 허용하기 위해서는 상품개발조직을 평가와 통제 대상이 아닌, 신뢰의 대상으로 존중하는 조직문화가 뒷받침되어야 한다. 상품개발팀의 규모가 작은 경우에는 개인별 업무부하를 고려한 점진적 계획수립이 용이하다. 그러나 조직의 규모가 커지면 신뢰보다는 통제, 성선설보다는 성악설을 중시하여 점진적 계획수립에 대한 부담이 커진다. 그 결과 많은 관리자들이 ‘상세계획 수립 후, 계획달성을 못하는 개인을 질책하는 통제’를 적용하게 된다.
이런 경우에는 상세한 계획을 수립하되, 가정을 명확하게 하는 것이 중요하다.
- 상품개발 도중 고객 VOC 반영을 고려한다.
상품관리자가 고객 VOC를 분석하여 상품개발 착수전에 상품개발 요구사항을 정의했지만, 개발 도중에도 지속적으로 고객 VOC를 청취하고 상품개발에 반영해야 한다. 따라서 상품관리자는 상품개발 도중 고객에게 중간 결과물을 보여주고 검토 받는 일정을 프로젝트 관리자와 미리 협의해야 한다. 물론 그때 상품요구사항 변경의 규모는 미리 예측 할 수 없다.
- 팀원의 커미트먼트를 확보한다.
상품개발 프로젝트를 진행하다 보면 계획대로 진행되지 않는 경우가 자주 발생한다. 예상하지 못했던 어려움이나 문제점이 발생했을 때 팀원들의 반응은 다음 두 가지로 나누어진다. “~때문에 목표를 달성하기 힘들다”고 핑계를 찾는 팀원과 “~임에도 불구하고 목표를 달성하겠다”는 의지를 다지는 팀원이 그것이다. “~때문에”와 “~임에도 불구하고”의 태도 차이는 프로젝트 계획에 대한 자발적인 동의 여부가 큰 영향을 미친다. 상품개발 계획에 대해 팀원들의 자발적 동의를 확보하는 방법은 상품개발 계획 수립 시 팀원들을 참여시키는 것이다. 사전에 아무런 협의를 구하지 않은 계획에 대해, 보통 사람은 부정적인 선입견을 가지기 쉽다.
- PERT (Program Evaluation and Review Technique)/CPM(Critical Path Method) 적용은 유의해서 결정한다.
특히 프로젝트 WBS를 상세하게 분할하고 전통적 일정계획수립 기법인 PERT/CPM을 적용하는 것은 신중하게 결정해야 한다. PERT/CPM은 각 작업의 수행순서와 기간을 고려하여 전체 프로젝트 일정을 확정하는 기법으로 건축이나 생산일정 계획 수립 시 주로 활용된다. PERT/CPM을 적용한 계획은 복잡하고 시간이 많이 소요되기 때문에 비용 대비 효과가 명확할 때 적용하도록 한다.
- 애자일의 스프린트 적용 시 다음에 유의한다.
• 각 스프린트에 다음 스프린트를 준비하는 활동을 포함한다.
특정 스프린트가 끝났는데 다음에 착수할 스프린트를 준비하지 않은 경우 다음 스프린트 착수가 지연된다. 다음 스프린트 착수를 위한 준비로는 상품 요구사항 상세화 , 화면 디자인 완료 등이 대표적인 활동이다.
• 특정 활동만 하는 스프린트를 수행해서는 안 된다.
예를 들어 첫 번째 스프린터에서 분석, 두 번째 스프린터에서 설계를 수행하는 방식이다. 이는 애자일을 빙자한 폭포수 방법론이다.
• 첫 번째 스프린트는 프로젝트 착수 준비를 위한 활동을 수행할 수 있다.
프로젝트 아키텍처 설계, 상품컨셉 및 고객가치에 대한 학습, 화면 표준 설계, 데이터 설계, 개발환경 구축 등 본격적인 개발 착수를 위한 활동을 첫 번째 스프린트에서 수행 할 수 있다. 이를 ‘스프린트 0’으로 표현하기도 한다.
• 마지막 스프린트는 통합테스트 및 최종 검수활동을 수행할 수 있다.
마지막 스프린트에서는 프로젝트 종료를 위한 품질검증 활동을 수행할 수 있다.
• 스프린트 주기는 프로젝트 상황에 따라 결정하되 동일주기를 유지한다.
보통 스프린트 주기는 2주 ~ 4주가 일반적이다. 팀원이 애자일 방법론에 익숙하지 않으면 3~4주의 스프린트가 적당하다. 팀원의 경험과 역량이 쌓인 후 스프린트 주기 단축을 검토해야 한다. 스프린트 주기는 릴리즈 주기와 같이 비즈니스 관점의 필요성을 고려하여 결정한다. 스프린트 주기를 짧게 해도 릴리즈도 하지 않고, 고객검토도 하지 않으면 짧은 개발주기의 의미가 없다.
• UX 디자인은 코딩보다 선행한다.
UX 디자인은 1개 스프린트 정도를 선행하면서 해당 스프린트에서는 개발자들의 질문에 답하고 필요 시 디자인을 수정하는 작업을 수행한다.
• 각 스프린트에서 단위테스트는 완료하도록 한다.
각 스프린트 계획 수립 시 단위테스트 및 결함수정을 감안한 일정계획을 수립한다.
• 각 스프린트는 금요일에 시작할 수도 있다.
대부분 스프린트는 월요일에 시작한다. 조직에 따라 월요일에 회의나 보고가 있으면 스프린트 착수를 위한 계획수립이 부담스러울 수 있다. 금요일에 스프린트 착수를 위한 계획수립을 하는 것이 효과적일 수 있다. 이는 스프린트 종료를 목요일로 할 것인지 금요일로 할 것인지와 같은 문제이다. 스프린트 종료일을 목요일로 하면 금요일 발생하는 결함에 대해 주말에 대응할 여유가 있는 장점도 있다. 금요일 종료, 월요일 착수라는 고정관념에서 벗어날 필요가 있다.
https://brunch.co.kr/@kbhpmp/160
