83. 상품 요구사항 변경관리시 유의사항
성공적인 소프트웨어 신상품 개발가이드
상품 요구사항의 변경관리를 잘하기 위해서는 필요한 변경은 빨리 하고, 불필요한 변경은 예방하고, 변경관리로 인한 비효율은 최대한 억제해야 한다.
- 아무리 뛰어난 상품 요구사항 문서도 대화를 대신할 수 없다
상품 요구사항은 명시적, 묵시적 요구사항 모두를 포함한다. 상품 요구사항은 관련된 이해관계자 모두가 동일하고 정확하게 이해하는 것이 중요하다. 상품 요구사항 문서만으로는 동일하고 정확하게 이해하길 기대할 수 없다. 최초 상품 요구사항을 정의하고 공감하는데 시간과 노력을 아끼지 말아야 한다.
- 상품요구사항 우선순위를 정기적으로 검토하고 이해관계자와 공유한다.
상품요구사항의 우선순위는 역동적이기 때문에 정기적(예:월)으로 상품요구사항의 우선순위를 검토하고 필요시 우선순위를 조정해야 필요한 변경이 지연되는 것을 예방할 수 있다. 상품 요구사항을 변경해야 한다면 변경의 배경과 내용을 이해관계자에게 문서 및 대면 의사소통을 통해 공유해야 한다.
- 상품요구사항 변경에 따른 영향력을 분석하고 합의한다.
상품 요구사항을 변경하는 경우 투입공수, 개발일정, 상품 요구사항 우선순위에 대해 프로젝트 관리자와 상품관리자가 합의해야 한다. 프로젝트 관리자는 변경된 요구사항의 규모, 지금까지의 개발생산성에 근거한 합리적인 추정치를 설명할 수 있어야 한다.
- 상품요구사항 변경 권한을 상품관리자에게 위임한다.
상품 요구사항 변경을 경영층에서 까다롭게 관리하면 필요한 변경은 회피하고, 불필요한 기능도 계획대로 개발하는 비효율이 발생할 수 있다. 따라서 핵심적인 상품 요구사항의 변경이 아니라면 상품요구사항 변경 권한을 상품관리자에게 위임하는 것이 바람직하다.
- 상품 요구사항의 추가 또는 변경을 위해 릴리즈 일정을 변경하지 않는다.
상품 릴리즈 일정은 특별한 사유가 없는 한 변경하지 않는 것이 바람직하다. 신상품 릴리즈 일정을 연기하는 경우 출시를 위해 달려온 팀원들의 사기가 낮아지고 일정 지연을 계기로 불필요한 상품요구사항을 반영 할 수도 있다. 또한 출시와 같은 중요한 마일스톤을 미루려면 경영층에게 지연 사유를 보고해야 하고, 지연에 대한 책임소재 다툼 등과 같은 불필요한 비용이 발생한다.
- 요구사항에 대한 품질기준과 검수기준은 다를 수 있다.
시간이 충분하다면 완벽한 품질을 갖춘 요구사항을 출시해야 하지만 경우에 따라서는 완벽하지 않은 품질수준의 상품 요구사항도 상품관리자가 검수하고 시장에 출시할 수 있다. 예를 들어 중요도가 낮은 상품 요구사항의 속도가 약간 느린 것은 출시 후에 개선할 수 있다.
- 상품 요구사항을 추적 관리한다.
상품 요구사항을 추적 관리하는 목적은 요구사항을 출시 상품에 누락하지 않고 정확하게 반영했음을 확인하기 위함이다. JIRA와 같은 툴을 활용하여 상품 요구사항을 관리하면 상품 요구사항은 쉽게 추적할 수 있다. 하나의 상품 요구사항이 복수개의 코드로 분할되거나 복수개의 상품 요구사항이 1개의 코드로 통합될 수 있다.
- 상품 요구사항의 상태(status)를 관리해야 한다.
상품 요구사항이 최초 제안된 이후 릴리즈 또는 폐기될 때까지의 라이프사이클을 관리해야 한다. 상품 요구사항을 제안한 사람에게는 특히 해당 요구사항이 어떤 상태에 있는지 공유하는 것이 바람직하다. 요구사항 상태관리의 예는 아래 그림 과 같다.
- 상품 요구사항의 변경현황을 관리한다.
상품 요구사항의 변경내용을 계량적・가시적으로 정리하여 정기적으로 고객과 소통하면 비효율적인 상품 요구사항 변경 통제에 도움이 된다. 매주(혹은 매월) 범위의 변동내용을 아래 그림과 같이 표현하는 것도 유용하다.
https://brunch.co.kr/@kbhpmp/160
