오픈 직전의 변경 요청은 대부분 감정이 아니라 상황의 결과다.
그래서 이 시점에서 기획자가 해야 할 일은 요청의 수락 여부를 즉시 결정하는 것이 아니라,
이 요청이 어떤 성격의 판단인지 먼저 분류하는 일이다.
아래 질문들은 그 분류를 돕기 위한 체크 포인트다.
1. 이 요청은 ‘오류’인가, ‘기능 변경’인가
기존 시나리오대로 동작하지 않는 문제인가?
아니면 시나리오 자체를 바꾸자는 요청인가?
※ 오류 수정은 테스트 영역이지만, 기능 변경은 변경/추가요구사항이다.
2. 이 요청은 기존 합의의 해석인가, 새로운 판단인가
이전 회의나 문서에 언급된 전제가 있는가?
“그때 이야기했던 그 부분”이라는 말로 연결되는가?
※ 이 요청이 ‘이미 정리된 내용’인지, 아니면 지금 새로 결정해야 할 내용인지부터 구분한다
3. 이 요청은 운영의 필수 조건인가, 운영 편의에 가까운가
이 기능이 없으면 실제 운영이 불가능한가?
아니면 운영이 불편해질 뿐 대체 수단은 있는가?
※ ‘운영상 필요’라는 말 안에는 필수와 편의가 함께 섞여 있는 경우가 많다.
4. 이 변경이 영향을 미치는 범위는 어디까지인가
특정 화면이나 기능에 국한되는가?
여러 흐름과 정책, 테스트 케이스를 다시 건드리는가?
※ 영향 범위를 설명하지 못하는 변경은 대부분 예상보다 크다.
5. 이 요청을 수락하면, 무엇을 다시 해야 하는가
개발 수정만 필요한가?
테스트 재진행이 필요한가?
일정 조정이나 오픈 범위 조정이 필요한가?
※ “가능합니다”라는 말은, 이 질문에 답한 이후에만 의미를 가진다.
6. 이 판단을 누가 책임질 수 있는가
요청자는 누구인가?
이 변경으로 발생하는 일정·품질 리스크를 함께 감당할 주체가 있는가?
※ 오픈 직전 변경 요청에서 가장 위험한 구조는, 결정은 위에서 내려오고 책임은 아래로 내려오는 경우다.
7. 이 요청을 지금 결정하지 않으면, 언제 다시 돌아오는가
오픈 이후 바로 이슈로 터질 가능성이 있는가?
아니면 차기 오픈이나 운영 개선으로 분리 가능한가?
※ ‘지금 아니면 안 된다’는 말은 검증이 필요하다.
** 오픈 직전 변경 요청 시 대응 방법 ** 보기