Change Request (변경 요청)

어떻게 흐르는가

접수, 영향 평가, 승인 또는 반려, 반영의 네 걸음이다. "관리자 보고서 화면 3종을 추가해 달라"는 요청이 들어오면, 곧바로 일정에 끼워 넣는 대신 범위·일정·비용에 미치는 영향을 평가한다. 개발 3주 추가, 테스트 1주 연장, 오픈일 2주 이동 같은 값이 나오면 그 대가를 들고 의사결정자에게 간다. 승인되면 변경을 반영하되 기준선에 영향을 주는 건이면 관련 베이스라인을 함께 갱신하고, 반려되면 기록만 남긴다. 어느 쪽이든 결정의 흔적이 남는 것이 핵심이다. 평가의 산출물은 두꺼운 문서가 아니라 결정 가능한 선택지다. 수용하면 무엇을 내주고 거절하면 무엇을 잃는지가 한 장에 담기면 충분하다.

왜 중요한가

프로젝트를 침몰시키는 것은 큰 변경이 아니라 절차 없이 스며드는 작은 변경들이기 때문이다. 범위 잠식(scope creep)은 한 번의 사건이 아니라 "이 정도는 그냥 해 주죠"의 누적이다. CR은 변경을 막는 장치가 아니라 변경의 비용을 보이게 만드는 장치다. 요청한 쪽이 대가를 알고 스스로 결정하게 만드는 것, 변경 관리가 하는 일은 그것이 전부다. 구두로 합의해 끼워 넣은 범위는 검수 단계에서 "계약에 없다"와 "해 주기로 했다"의 분쟁으로 돌아온다.

흔한 오해

CR을 관료제로 여기는 것이 흔한 오해다. 절차의 무게는 변경의 크기에 비례하면 된다. 반나절짜리 변경에 위원회가 필요한 것이 아니라, 한 줄짜리 기록과 승인자 한 명이면 충분한 경우가 대부분이다. 또 하나, 일정·범위에 대한 변경 통제는 베이스라인이 있어야 성립한다. 무엇이 일정과 범위의 변경인지를 기준선이 정의하기 때문에, 그 영역에서 변경 관리의 첫걸음은 절차 설계가 아니라 베이스라인 승인이다.