제14화. '변경 요청'의 늪에서 빠져나오는 현명한 밀당의 기술
아들아, 프로젝트가 진행되다 보면 고객은 반드시 "이것 좀 살짝 바꿔주세요"라며 새로운 요구를 던진단다. 처음엔 작은 수정 같지만, 하나둘 받아주다 보면 어느새 프로젝트는 일정과 예산의 범위를 벗어나 늪에 빠지게 되지. CR(Change Request)을 무조건 거절하는 것이 아니라, 현명하게 '밀당'하며 프로젝트의 항로를 지키는 법을 알려줄게.
고객이 말하는 "살짝만 고쳐달라"는 말은 대개 데이터 구조나 기존 로직을 뒤흔드는 큰 작업일 때가 많단다. 화면상의 버튼 하나를 옮기는 일도 그 밑에 흐르는 데이터의 규칙을 바꿔야 한다면 그건 더 이상 작은 수정이 아니야.
고객의 '살짝'을 개발자의 '공수(Man-Month)'로 환산하여 팩트로 대화해야 한단다.
아빠의 노하우: 아빠는 고객의 요청이 들어오면 그 자리에서 확답하지 않았어. 대신 "영향도를 분석해서 말씀드리겠습니다"라고 시간을 벌었지. 그리고 해당 수정이 다른 기능에 미치는 부작용을 숫자로 정리해 가져가면, 고객도 무리한 요구였다는 것을 스스로 깨닫게 된단다.
요구사항이 바뀌면 반드시 그에 상응하는 '비용'이 발생한다는 것을 고객에게 알려야 한단다. 여기서 비용이란 돈뿐만 아니라 '시간'과 '품질'도 포함되지. 하나를 얻으려면 하나를 포기해야 한다는 비즈니스의 기본 원리를 잊지 마라.
새로운 배를 태우려면, 기존의 짐 중 무엇을 내릴지 고객이 선택하게 해야 한단다.
아빠의 노하우: 아빠는 추가 요청을 수용해야 할 때 반드시 '우선순위 조정' 카드를 꺼냈어. "이 기능을 넣으려면 기존에 약속한 A 기능의 일정이 밀리거나 제외되어야 합니다. 어떤 것이 더 중요하신가요?"라고 묻는 거야. 결정의 책임을 고객에게 넘기면 함부로 CR을 던지지 못한단다.
고객의 아이디어가 프로젝트에 정말 도움이 된다면 무조건 막는 것만이 능사는 아니야. 다만 지금 당장이 아니라 '언제' 할 것인지를 조율하는 지혜가 필요하단다. 무조건적인 거절은 감정적인 대립만 불러올 뿐이지.
지금의 오픈을 지키기 위해, 더 나은 제안은 '2단계 고도화'로 미루는 기술이 필요하단다.
아빠의 노하우: 아빠는 "지금 반영하면 오픈 안정성이 흔들리니, 안정화 기간이나 다음 차수 프로젝트의 핵심 과제로 넣자"라고 제안했어. 이를 '백로그(Backlog)'로 관리하며 고객의 의견을 소중히 기록하고 있다는 인상을 주면, 고객은 존중받는다는 기분을 느끼면서도 실무적인 양보를 해준단다.
구두로 합의된 변경 사항은 나중에 반드시 독이 되어 돌아온단다. "그때 해준다고 하셨잖아요"라는 고객의 말 한마디에 증거 없이 당하지 않으려면, 사소한 결정도 공식적인 문서로 남겨야 해.
메일과 회의록은 너를 지켜주는 방패이자, 나중에 정산의 근거가 되는 계약서란다.
아빠의 노하우: 아빠는 회의가 끝나면 즉시 '요구사항 변경 관리 대장'을 업데이트했어. 변경된 내용, 그로 인한 영향, 합의된 일정 조정 사항을 기록하고 관련자 전원에게 메일을 보냈지. 이 기록들이 쌓이면 프로젝트 막바지에 발생하는 '책임 공방'에서 너를 완벽하게 보호해 줄 거란다.
한 마디
"변경 요청 관리는 거절의 기술이 아니라 '우선순위의 기술'이란다. 고객의 욕심과 팀의 리소스 사이에서 정교하게 균형을 잡는 법을 배울 때, 너는 비로소 프로젝트의 진정한 조타수가 될 수 있단다."
고객의 추가 요구가 들어왔을 때, 다음 5가지를 기준으로 판단해 보렴.
[필수성] 이 기능이 없으면 서비스 오픈 자체가 불가능한 'Critical'한 사항인가?
[영향도] 기존의 DB 구조나 핵심 공통 로직을 대대적으로 수정해야 하는가?
[일정 리스크] 이 작업을 추가했을 때 전체 프로젝트 마일스톤(중요 일정)이 흔들리는가?
[대체 가능성] 개발 없이 운영 정책이나 수동 처리로 해결할 수 있는 방법은 없는가?
[비용 정산] 계약 범위 밖의 일이라면 추가 인건비(M/M)를 청구할 수 있는 근거가 있는가?