82. 요구사항 변경 원인 및 부작용
성공적인 소프트웨어 신상품 개발가이드
상품 요구사항의 변경은 요구사항 내용의 변경과 개발(또는 릴리즈) 우선순위의 변경을 의미한다. 상품개발 시 상품 요구사항이 변하지 않길 기대해서는 안 된다. 조금 더 빨리 변경하고, 조금 더 작게 변경하는 것만 바래야 한다. 변덕스러운 날씨에 대비해 우산을 챙기듯이 요구사항 변경에 대비하는 것이 중요하다.
다음은 요구사항 변경을 잘 설명하고 있다.
“요구사항의 동결과 눈사람은 유사하다. 모두 적당히 꾸며지고, 충분한 열이 가해지면 녹는다.”(작자미상)
1) 상품 요구사항을 변경하는 이유
상품 요구사항을 변경하는 대표적인 이유는 다음과 같다.
- 고객 요구사항 파악의 오류
고객 인터뷰에서 고객은 상품의 불편사항, 개선사항에 대해 충분히 이야기했지만, 인터뷰하는 사람이 맥락을 잘 이해하지 못해 키워드를 놓칠 수 있다. 특히 고객이 명시적으로 이야기하지 않았지만 암묵적으로 제공한 중요한 메시지를 놓치는 경우가 많다.
- 경쟁상품 대응
신상품개발 도중 출시한 경쟁상품에 대응하기 위해 상품개발의 우선순위를 변경하거나 상품요구사항을 추가, 삭제할 수 있다.
- 단계별 검토 시 경영층의 지시
단계별 검토회의에 참여한 경영층이 개발중인 상품의 요구사항 변경을 제안할 수 있다.
- 사회의 전반적 변화
기술, 경제, 문화적인 변화로 인해 개발중인 상품의 요구사항을 변경하는 경우도 있다.
- 수주를 위한 상품 요구사항 변경
B2B 상품 개발 시 주로 발생한다. 00 기능을 추가하면 00억의 사업을 수주할 수 있다는 영업대표의 이야기는 상품 요구사항 변경의 필요충분 조건이 된다.
2) 잘못된 요구사항 변경관리의 부작용
요구사항 변경관리를 잘못하면 다음과 같은 부작용이 발생할 수 있다.
- 긴급 소프트웨어 개발로 복잡도가 증가하고, 품질이슈(기술부채)가 발생한다.
<린 소프트웨어개발의 적용, 2007>에서 이야기하는 대표적인 악순환은 다음과 같다.
∙ 고객이 ‘어제’ 느닷없이 새로운 기능을 이야기한다.
∙ 개발자에게 이렇게 전달된다. “비용이 얼마가 들더라도 빨리 끝내도록!”
∙ 결과 : 코드에 조잡한 변경이 가해진다.
∙ 결과 : 코드에 복잡도가 증가한다.
∙ 결과 : 코드의 결함이 증가한다.
∙ 결과 : 기능을 추가하는데 들어가는 시간이 기하급수적으로 증가한다.
- 요구사항 변경승인을 위한 문서와 회의가 증가한다.
상품기획심의에서 승인한 상품 요구사항을 변경하면 변경을 검토하고 승인하기 위한 관리비용이 발생한다. 심한 경우에는 상품기획을 승인했던 사람들이 다시 모여 변경에 대한 적정성을 검토한다. 고위 경영층에게 보고할수록 작성하는 문서의 양이 많아지고 문서작성 시간이 길어진다. 요구사항 변경 검토에 투입되는 시간이 길어질수록 출시도 지연될 수 있다.
- 상품개발 비용이 증가한다.
상품 요구사항 변경을 검토하고 변경된 내용을 개발하는 비용은 상품기획 심의 때 예상하지 못했던 비용이다.
- 상품개발팀과 상품관리자의 갈등이 발생한다.
상품개발팀 입장에서는 변경은 반갑지 않다. 특히 변경된 요구사항 개발을 위한 예산과 시간을 반영하지 않으면 개발팀의 불만은 더욱 높아진다. 상품관리자는 상품개발팀이 금번 변경을 기회로 물 타기 식의 예산, 기간 변경을 하는 것 같아 불만이 생기기도 한다.
- 상품개발 목표(일정, 품질, 원가)에 부정적인 영향을 미친다.
상품 요구사항을 변경하고 상품개발계획을 변경하지 않는 경우 상품개발 목표 달성이 어려워지고 상품개발팀의 사기가 낮아진다.
https://brunch.co.kr/@kbhpmp/160
