하지 않을 일을 정해야프로젝트가 움직입니다

버튼 하나, 입력 항목 하나와 보고서 한 종류는 각각 작아 보입니다. 그러나 데이터 구조, 권한, 검토 방식과 테스트 범위까지 따라오면 프로젝트의 성격이 달라집니다.

새 요청을 모두 받아들이면 팀은 원래 해결하려던 문제보다 최근에 들어온 의견에 반응하게 됩니다. 완료 기준도 계속 변해 어느 시점에도 끝났다고 말하기 어렵습니다.

반대로 모든 변경을 거절하면 실제로 발견된 중요한 정보를 놓칩니다. 필요한 것은 찬성과 반대가 아니라 새 요청의 위치를 결정하는 공통 기준입니다.

범위 밖으로 둔다는 것은 중요하지 않다는 뜻이 아니라 이번 약속과 분리해 다시 판단할 수 있게 만든다는 뜻입니다.

중요한 새 요청은 이번 범위에 들어올 수 있습니다. 다만 무엇이 추가되는지만 말하지 않고 비용, 일정과 기존 항목에 미치는 영향을 함께 결정합니다.

마감일을 유지한다면 다른 항목을 다음 단계로 옮길 수 있습니다. 모든 기능을 유지한다면 일정이나 예산이 달라질 수 있습니다. 아무것도 교환하지 않는 추가는 결국 보이지 않는 야근과 품질 저하로 이동합니다.

변경 이유와 결정자를 기록하면 같은 논의를 반복하지 않습니다. 범위 표는 계약을 방어하는 문서가 아니라 팀이 현실적인 약속을 다시 선택하는 공용 화면입니다.

다음 단계로 미룬 요청을 메신저나 개인 메모에 두면 결국 사라집니다. 요청의 배경, 기대 효과와 다시 판단할 조건을 짧게 남깁니다.

반대로 하지 않기로 한 항목을 계속 보관하면 목록만 커집니다. 근거가 부족하거나 목표와 관계없는 요청은 닫고 필요할 때 새로운 정보와 함께 다시 제안하게 합니다.

프로젝트가 끝난 뒤 네 구역을 다시 봅니다. 다음 단계 항목은 후속 프로젝트 후보가 되고, 운영 영역은 인수인계 자료에 포함됩니다. 범위 결정이 다음 실행의 출발점으로 이어집니다.