개발 중 추가 요청이 생겼을 때 범위를 정하는 법

개발 중 실제 화면을 보고 나서야 필요한 기능을 발견할 수 있습니다. 추가 요청이 생겼다는 사실보다 그 요청을 일정과 비용에 어떻게 반영하는지가 중요합니다.

기존 합의가 빠진 것인지 새 요구인지 확인합니다

요구사항과 검수 기준에 이미 포함된 동작인지 먼저 확인합니다. 합의한 기능의 오류를 추가 개발로 처리해서도 안 되고 새로운 업무를 기존 범위에 당연히 포함해서도 안 됩니다. 애매한 항목은 결정 근거를 함께 남깁니다.

가정한 예시로 출시 전에 반품 기능을 추가해 달라는 요청이 들어왔다고 해 봅시다. 버튼 하나처럼 보여도 재고 복구와 환불, 권한, 기존 주문 데이터에 영향을 줄 수 있습니다. 연결된 업무를 확인한 뒤 규모를 판단해야 합니다.

넣을 기능과 뺄 기능을 함께 결정합니다

요청마다 필요한 이유, 출시 전 필수 여부, 우회 방법, 예상 영향, 결정자를 기록합니다. 일정이 고정돼 있다면 다른 범위를 줄일 수 있는지도 검토합니다. 범위를 유지한 채 인력만 추가하면 검토와 협의가 더 필요한 상황도 생깁니다.

합의한 변경은 문서와 일정에 반영하고 관련 담당자에게 알립니다. 구두 요청만 남으면 검수 때 서로의 완료 기준이 달라집니다.

첫 계약에서도 변경 요청을 받는 창구와 결정 절차를 정할 수 있습니다. 변경을 전혀 하지 않겠다고 약속하기보다 어떤 자료를 보고 누가 결정할지 합의하는 편이 현실적입니다.