• 목록
• 답변
• 글쓰기

출처 : https://brunch.co.kr/@kbhpmp/87

상품 요구사항의 변경관리를 잘하기 위해서는 필요한 변경은 빨리 하고, 불필요한 변경은 예방하고, 변경관리로 인한 비효율은 최대한 억제해야 한다.

아무리 뛰어난 상품 요구사항 문서도 대화를 대신할 수 없다

- 상품 요구사항은 명시적, 묵시적 요구사항 모두를 포함한다. 

- 상품 요구사항은 관련된 이해관계자 모두가 동일하고 정확하게 이해하는 것이 중요하다. 

- 상품 요구사항 문서만으로는 동일하고 정확하게 이해하길 기대할 수 없다. 

- 최초 상품 요구사항을 정의하고 공감하는데 시간과 노력을 아끼지 말아야 한다.

상품요구사항 우선순위를 정기적으로 검토하고 이해관계자와 공유한다.

- 상품요구사항의 우선순위는 역동적이기 때문에 정기적(예:월)으로 상품요구사항의 우선순위를 검토하고 

- 필요시 우선순위를 조정해야 필요한 변경이 지연되는 것을 예방할 수 있다. 

- 상품 요구사항을 변경해야 한다면 변경의 배경과 내용을 이해관계자에게 문서 및 대면 의사소통을 통해 공유해야 한다.

상품요구사항 변경에 따른 영향력을 분석하고 합의한다.

- 상품 요구사항을 변경하는 경우 투입공수, 개발일정, 상품 요구사항 우선순위에 대해 프로젝트 관리자와 상품관리자가 합의해야 한다. 

- 프로젝트 관리자는 변경된 요구사항의 규모, 지금까지의 개발생산성에 근거한 합리적인 추정치를 설명할 수 있어야 한다.

상품요구사항 변경 권한을 상품관리자에게 위임한다.

- 상품 요구사항 변경을 경영층에서 까다롭게 관리하면 필요한 변경은 회피하고, 불필요한 기능도 계획대로 개발하는 비효율이 발생할 수 있다. 

- 따라서 핵심적인 상품 요구사항의 변경이 아니라면 상품요구사항 변경 권한을 상품관리자에게 위임하는 것이 바람직하다.

상품 요구사항의 추가 또는 변경을 위해 릴리즈 일정을 변경하지 않는다.  

- 상품 릴리즈 일정은 특별한 사유가 없는 한 변경하지 않는 것이 바람직하다. 

- 신상품 릴리즈 일정을 연기하는 경우 출시를 위해 달려온 팀원들의 사기가 낮아지고 

- 일정 지연을 계기로 불필요한 상품요구사항을 반영 할 수도 있다. 

- 또한 출시와 같은 중요한 마일스톤을 미루려면 경영층에게 지연 사유를 보고해야 하고, 

- 지연에 대한 책임소재 다툼 등과 같은 불필요한 비용이 발생한다.

요구사항에 대한 품질기준과 검수기준은 다를 수 있다.

- 시간이 충분하다면 완벽한 품질을 갖춘 요구사항을 출시해야 하지만 경우에 따라서는 

- 완벽하지 않은 품질수준의 상품 요구사항도 상품관리자가 검수하고 시장에 출시할 수 있다. 

- 예를 들어 중요도가 낮은 상품 요구사항의 속도가 약간 느린 것은 출시 후에 개선할 수 있다.

상품 요구사항을 추적 관리한다.

- 상품 요구사항을 추적 관리하는 목적은 요구사항을 출시 상품에 누락하지 않고 정확하게 반영했음을 확인하기 위함이다. 

- JIRA와 같은 툴을 활용하여 상품 요구사항을 관리하면 상품 요구사항은 쉽게 추적할 수 있다. 

- 하나의 상품 요구사항이 복수개의 코드로 분할되거나 복수개의 상품 요구사항이 1개의 코드로 통합될 수 있다.

상품 요구사항의 상태(status)를 관리해야 한다.

- 상품 요구사항이 최초 제안된 이후 릴리즈 또는 폐기될 때까지의 라이프사이클을 관리해야 한다. 

- 상품 요구사항을 제안한 사람에게는 특히 해당 요구사항이 어떤 상태에 있는지 공유하는 것이 바람직하다. 

- 요구사항 상태관리의 예는 아래 그림 과 같다.

상품 요구사항의 변경현황을 관리한다. 

- 상품 요구사항의 변경내용을 계량적・가시적으로 정리하여 

- 정기적으로 고객과 소통하면 비효율적인 상품 요구사항 변경 통제에 도움이 된다. 

- 매주(혹은 매월) 범위의 변동내용을 아래 그림과 같이 표현하는 것도 유용하다.