월요일 착수 회의에서 “임원용 실시간 대시보드”가 화면 열두 장과 6주 일정으로 바뀝니다. 목요일에 만난 현장 담당자는 차트를 볼 시간이 없고, 마감 전에 이상 주문 한 건만 알려 달라고 말합니다. 이미 견적까지 나온 팀은 화면을 버릴지 사용자를 설득할지 갈라집니다. 되돌아간 원인은 느린 실행이 아니라 답을 정한 채 질문을 생략한 출발점입니다.
핵심 프로젝트 착수의 목적은 기능을 선언하는 것이 아니라 현재 사실과 추측을 분리하고, 가장 위험한 가정을 결정 시한 전에 검증할 순서를 합의하는 데 있습니다.
먼저 보면 좋은 점
- 확인된 사실과 강한 추측을 다른 칸에 둡니다.
- 가정은 틀렸을 때 손실이 큰 순서로 검증합니다.
- 결정 시한과 범위 변경 권한을 착수 때 합의합니다.
요청서를 일주일짜리 미지 목록으로 바꾼다
“대시보드를 만들어 달라”는 요청을 받으면 최근 30일에 누가 어떤 결정을 못 했는지, 현재 무엇을 대신 보는지, 틀리면 개발을 되돌릴 가정을 적습니다. 운영자 다섯 명의 실제 보고 과정을 보고 로그에서 반복 조회를 확인하는 일을 일주일 검증으로 잡고, 화면 제작은 그 결과 뒤에 둡니다.
다섯 명이 서로 다른 결정을 하거나 기존 보고서로 문제없이 끝낸다면 대시보드 범위를 확정하지 않습니다. 규정이나 데이터 접근 권한을 확인하지 못해도 개발을 보류합니다. 오늘 착수 문서의 해결책 문장을 지우고 확인된 사실, 가장 위험한 가정, 이번 주 확인 방법, 결정권자와 결정일 네 칸으로 바꾸십시오.
요청 문장을 문제 문장으로 되돌린다
“매출 대시보드를 만들어 달라”는 요청에는 사용자, 사용 순간, 바뀌어야 할 결정이 빠져 있습니다. 매장 관리자가 폐점 전에 재고 주문을 바꾸려는 것인지, 본사가 월말 성과를 비교하려는 것인지에 따라 필요한 정보와 갱신 속도가 달라집니다.
요청자는 해결책을 말했더라도 그 뒤의 사건을 묻습니다. 최근 어떤 판단이 늦었는지, 지금은 무엇을 보고 결정하는지, 잘못 판단하면 어떤 손실이 생기는지를 적으면 대시보드가 아닌 알림이나 업무 절차 변경이 더 작은 해법일 수 있습니다.
사실과 해석을 같은 문장에 섞지 않는다
“사용자는 매출을 실시간으로 보고 싶어 한다”는 문장은 인터뷰 발언인지, 접속 기록인지, 담당자의 추측인지 알 수 없습니다. 확인된 사실은 지난달 보고서 다운로드 시각처럼 출처와 날짜를 붙이고, 해석은 별도 칸에 둡니다.
근거가 없는 칸을 부끄러워해 채우지 않습니다. 빈칸은 다음 조사 과제입니다. 오래된 고객 문의는 현재 행동과 다를 수 있으므로 유효 기간을 표시하고, 반대 사례가 발견되면 기존 결론 옆에 함께 남깁니다.
위험한 가정은 영향과 무지로 고른다
모든 가정을 같은 깊이로 조사하면 착수가 끝나지 않습니다. 틀렸을 때 제품 가치가 사라지는지, 되돌리는 비용이 큰지, 현재 근거가 약한지를 각각 평가합니다. 실시간 갱신이 기술적으로 가능한지보다 관리자가 그 시간에 행동할 권한이 있는지가 더 치명적일 수 있습니다.
상위 가정마다 가장 짧은 확인 행동을 정합니다. 실제 의사결정 회의를 관찰하고, 수동 알림을 일주일 보내며 주문 변경이 일어나는지 봅니다. 인터뷰의 호감만으로 행동 가정을 통과시키지 않습니다.
시작 캔버스가 회의의 계약이 된다
한 장에는 목표 사용자와 상황, 확인된 사실, 모르는 것, 위험 가정, 검증 방법, 결정 시한, 책임자를 둡니다. 화면 목록은 마지막 칸에 후보로만 적습니다. 이렇게 하면 개발자는 요구사항의 배경을 알고 운영자는 검증에 필요한 현장을 준비할 수 있습니다.
예를 들어 일주일 뒤 수동 알림의 주문 변경률을 보고 계속할지 결정한다고 명시합니다. 결과가 약하면 알림 방식이나 사용자 범위를 바꾸며, 예정된 대시보드 개발을 자동으로 시작하지 않습니다.
되돌아감이 아니라 무근거 지속을 실패로 본다
초기 가정이 틀려 범위를 바꾸는 것은 손실을 줄인 학습입니다. 실패는 반대 증거가 나왔는데도 이미 약속한 화면과 일정을 지키기 위해 진행하는 것입니다. 착수 때 누가 범위를 변경할 수 있는지 정하지 않으면 팀은 증거보다 직급을 따르게 됩니다.
캔버스가 기능 목록으로 변하거나 모든 가정이 낮은 위험으로 표시되면 작업을 멈추고 다시 검토합니다. 결정 시한이 계속 밀리거나 확인 책임자가 없는 항목도 개발 준비 완료로 보지 않습니다.
해결책 요청을 일주일짜리 검증으로 되돌리는 법
“앱에 상담 챗봇을 넣자”는 요청을 받았다면 최근 문의 200건을 유형과 해결 시간으로 나눕니다. 배송 조회가 45%이고 고객이 주문 번호를 찾지 못해 상담사가 반복 질문한다면, 챗봇보다 주문 화면의 상태 설명이 먼저일 수 있습니다. 원인 후보마다 현재 근거와 틀렸을 때 낭비할 개발량을 적고 가장 비싼 가정을 일주일 안에 확인합니다.
요청자가 챗봇 자체를 계약상 약속했다면 이를 숨은 제약으로 명시하고 문제 해결과 계약 이행을 분리합니다. 배송 상태를 주문 화면에 노출하는 작은 변경으로 반복 문의가 줄었다면 챗봇 일정은 취소합니다. 반대로 계약 이행이 우선이라면 문제 해결 효과를 과장하지 않은 별도 과제로 승인합니다. 어느 쪽이든 성공 기준이 “출시”뿐인 프로젝트는 개발 대기열에 올리지 않습니다.
메모
- 요청된 기능 뒤에서 실제로 바뀌어야 할 결정은 무엇인가?
- 사실과 해석에 출처와 유효 시점이 구분되어 있는가?
- 가정이 틀렸을 때 범위를 바꿀 권한과 시한을 정했는가?