오픈 직전 고객사의 변경 요청사항 앞에서 기획자가 가장 곤란해지는 순간은 '안 됩니다'라고 말하기도, '알겠습니다'라고 말하기도 어려울 때다. 이 시점의 요청은 대부분 운영을 전제로 하고 있고, 이미 일정 등이 확정된 확정된 상태에서 나오기 때문이다.
그래서 나는 오픈 직전 요청사항이 들어오면 해당 요청의 수락여부를 바로 결정해서 답변하지 않는다.
대신 아래와 같은 방식으로 한 번 더 정리해서 고객사에 되돌려 질문했다.
1. 요청의 성격을 먼저 되돌려 묻는다
테스트 중 발견된 오류 수정인가요?
시나리오 변경이 필요한 부분인가요?
→ 테스트 중 발견된 오류는 당연히 바로 ‘해야할 일’이지만,
변경 요청의 경우 바로 ‘해야 할 일’로 받아들이지 않는다.
즉, 요청사항에 대한 성격을 제일 먼저 파악한다.
2. 기존 합의와의 관계를 분명히 한다
요청 주신 사항은 기존 시나리오에는 포함되어 있지 않은 부분으로 새로운 요구사항으로 이해하면 될까요?
요청 주신 사항은 기존에 협의된 정책과 달릅니다. 운영 정책 변경이 되는 것으로 이해하면 될까요?
→ ‘이미 합의된 요구사항인지 새로운 요구사항인지 구분한다.
3. 영향 범위를 말로 정리해 준다
요구하신 사항을 반영하려면 ○○ 화면과 △△ 흐름, 그리고 테스트 케이스 일부를 다시 봐야 합니다. 단순 수정이 아니라 SIDE EFFECT이 발생될 가능성 또한 높습니다.
→ 요청의 크기를 기획자의 감정이 아니라 구조로 설명한다.
4. 일정과의 관계를 숨기지 않는다
지금 시점에서 이 변경을 반영하려면 추가 개발/재테스트 시간이 필요합니다.
그래서 오픈 일정 유지가 어려울 수 있습니다.
→ ‘가능/불가능’이 아니라, 지금 반영하면 어떤 비용이 생기는지 먼저 꺼내 놓는다.
5. ‘운영상 필요’라는 말을 기준으로 바꾼다
운영상 꼭 필요하다는 말씀은 이해합니다.
다만 이 기능이 없으면 실제로 오픈이 불가능한지,
아니면 오픈 후 보완해도 되는 것인지 확인이 필요합니다.
→ 필요 vs 편의, 지금 vs 이후를 구분한다.
6. 판단 주체를 다시 회의 위로 올린다
이 변경을 지금 반영할지 여부는 일정과 범위에 영향을 주는 판단이라 제가 결정하기 어렵습니다.
관련 담당자분들 모두가 함께 확인하는 게 필요할 것 같습니다.
→ 기획자가 혼자 결정하는 구조를 피한다.
7. 판단을 위한 선택지를 명확히 제시한다
오픈 범위를 조정하는 방식이나 오픈 일정을 조정하는 것 모두 에이전시 입장에서는 손실이다.
오픈 직전 단계에서 추가 비용 이야기를 바로 꺼내는 것은 현실적으로 어렵다. 따라서 비용 대신 오픈 범위의 선택으로 이야기를 옮긴다.
이 요청을 이번 오픈 범위로 가져갈지, 아니면 오픈 이후 보완 항목으로 분리할지 기준을 한번 정해야 할 것 같아요.
→ 비용을 요구하지 않아도, ‘지금 할 것인가 / 나중에 할 것인가’라는 판단은 남긴다.
8. 문서로 상태를 남긴다
그럼 이 요청은 ‘오픈 직전 추가 요청 / 검토 중’ 상태로 정리해 두겠습니다.
결정되면 기준 문서에 반영하겠습니다.
→ 말이 아니라 상태로 관리한다.
9. 결정 여부와 관계없이, 판단의 상태를 남긴다
이 요청은 반영여부와 상관 없이 ‘오픈 직전 추가 요청 / 검토 완료(또는 보류)’ 상태로 정리해 두겠습니다.
→ 수락보다 중요한 건, 판단의 흔적을 남기는 일이다.
오픈 직전 변경 요청을 잘 처리한다는 건 요청을 많이 받아주는 것도 방어적으로 막아내는 것도 아니다.
이 요청이 어떤 판단인지 드러내고,
그 판단을 누가 언제 어떻게 책임질 것인지를 명확히 문서로 남기는 것,
그게 기획자가 할 수 있는 가장 현실적인 대응이다.
** 오픈 직전 변경 요청 시 체크해야 할 사항 ** 바로보기