프로젝트는 요구사항보다문제를 정의하는 일에서 시작합니다

“웹사이트를 새로 만들고 싶습니다”라는 요청 뒤에는 오래된 디자인보다 프로젝트 자료가 흩어져 영업에 활용하지 못하는 문제가 있을 수 있습니다.

“업무를 자동화하고 싶습니다”라는 요청 뒤에는 반복 작업보다 요청의 입구와 완료 기준이 정리되지 않은 상황이 있을 수 있습니다. “AI를 도입하고 싶습니다”라는 요청도 실제로는 인력 부족이 아니라 검토와 승인 과정의 병목에서 출발할 수 있습니다.

요청받은 결과물을 그대로 범위로 확정하면 표면의 불편은 바뀌어도 원래 문제는 남습니다. 정의 단계에서는 요청을 거절하는 것이 아니라 그 요청이 해결해야 할 장면을 더 구체적으로 확인합니다.

요구사항은 처음부터 주어지는 정답이 아니라 문제와 목표 상태를 확인한 뒤 만들어지는 결정의 결과입니다.

요구사항이 모호하다는 이유로 끝없는 인터뷰와 회의를 진행하면 정의 단계 자체가 새로운 불확실성이 됩니다. 시작할 때 확인할 질문, 참여자, 기간과 결과물을 제한해야 합니다.

보통 핵심 담당자와 결정권자를 정하고 기존 자료와 실제 업무 장면을 확인합니다. 모든 의견을 수집하기보다 프로젝트의 목적과 범위를 바꿀 수 있는 정보에 집중합니다.

정의 단계의 결과는 화려한 전략 문서가 아닙니다. 문제 정의, 목표 상태, 범위 선택지, 선택한 최소 실행, 가정과 위험, 완료 기준과 운영 책임이 다음 제작자가 사용할 수 있는 형태로 남아야 합니다.

정의 결과에 따라 프로젝트를 진행하지 않기로 결정할 수도 있습니다. 지금 필요한 것이 새로운 시스템이 아니라 기존 도구의 운영 규칙이라는 사실을 알게 된다면 그것도 유효한 결과입니다.

첫째, 누구의 어떤 상태가 달라져야 합니까? 둘째, 이번 프로젝트에 무엇이 포함되고 무엇이 제외됩니까? 셋째, 어떤 결과를 확인하면 완료되었다고 판단합니까? 넷째, 완성 이후 누가 수정하고 운영합니까?

이 질문에 답하지 못하면 제작 견적과 일정도 신뢰하기 어렵습니다. 반대로 답이 분명하면 화면 수와 기능 목록이 완벽하지 않아도 설계와 검증을 시작할 수 있습니다.

요구사항은 제작 과정에서 더 구체화될 수 있지만 문제와 목표, 핵심 범위는 함부로 바뀌지 않아야 합니다. 새로운 정보가 범위를 바꾼다면 변경 이유와 비용, 일정 영향을 함께 결정합니다.