‘예약 앱이 필요합니다’라는 말은 제품의 종류를 알려주지만 대부분의 결정은 열어둡니다. 누가 예약 시간을 제공하나요? 고객이 취소할 수 있나요? 직원이 변경을 승인해야 하나요? 프로젝트 개요는 이런 질문을 기업의 실제 업무와 연결할 때 유용해집니다. 대표적인 업무 흐름 하나에서 시작한 다음, 구현에 필요한 역할, 제약 조건, 검토 시 결정할 사항을 추가하세요.
이 페이지의 내용
현재 업무 흐름과 문제를 설명하세요
업무를 시작하게 하는 이벤트부터 완료 결과까지의 순서를 작성하세요. 사람과 시스템 사이의 인계도 포함해야 합니다. 예약 서비스를 제공하는 가상의 사업장을 예로 들면, 고객이 시간을 요청하고 직원이 공유 캘린더를 확인한 뒤 수동으로 확정 안내를 보낼 수 있습니다. 문제는 예약 충돌일 수도 있고 고객이 상황을 확인하기 어렵다는 점일 수도 있습니다. 화면 목록을 제안하기 전에 어떤 어려움이 중요한지 파악하세요.
- 어떤 정보로 요청이 시작되나요?
- 진행 가능 여부는 누가 결정하나요?
- 모두가 완료되었음을 어떻게 알 수 있나요?
사용자별 책임을 명확히 하세요
고객, 직원, 관리자의 필요를 구분하세요. 고객은 자신의 예약을 확인하고, 직원은 일정을 관리하며, 관리자는 누가 해당 권한을 가질지 정할 수 있습니다. 일반적인 동작뿐 아니라 수정 과정도 설명해야 합니다. 직원이 예약을 옮기면 누가 변경 내용을 보고 원래 시간대는 어떻게 처리되나요? 이런 규칙은 디자인팀과 개발팀이 같은 제품을 놓고 논의하도록 돕습니다.
첫 버전의 경계를 정하세요
예약 예시에서 범위를 집중한 첫 버전은 고객이 가능한 시간을 고르고, 확정 안내를 받은 뒤 나중에 예약을 다시 확인하도록 할 수 있습니다. 직원에게는 예약 가능 시간 관리와 취소 처리 기능을 제공할 수 있습니다. 반복 예약이나 로열티 보상을 미룰 수 있다면 이유와 함께 별도 목록에 넣으세요. 메인 화면보다 덜 눈에 띈다는 이유만으로 합의된 이용 흐름을 실제로 가능하게 하는 보조 단계를 제외해서는 안 됩니다.
- 요청부터 결과까지 완결된 이용 흐름 하나를 포함하세요.
- 운영에 필요한 접근 관리와 수정 도구를 포함하세요.
- 미룬 아이디어를 다시 검토할 조건을 정하세요.
의존 관계를 나열하고 미확인 사항을 표시하세요
애플리케이션에 필요할 수 있는 기존 캘린더, 결제 서비스, 고객 기록, 기타 시스템을 파악하세요. 언어, 대상 기기, 마이그레이션 필요, 비즈니스 제약도 기록하세요. 확정된 요구사항과 질문을 구분해야 합니다. ‘기존 캘린더에서 실시간 예약 가능 시간을 제공할 수 있나요?’라는 질문도 프로젝트 개요에 유용한 정보입니다. 가능하다고 가정하면 필요한 조사 작업이 가려지고 초기 범위가 왜곡될 수 있습니다.
요구사항을 검토할 수 있는 사례로 바꾸세요
쉬운 말로 인수 확인 항목을 작성하세요. 예약 흐름을 예로 들면, 고객이 가능한 시간을 예약했을 때 자신의 계정과 직원 일정에 예약이 표시되어야 합니다. 다른 고객이 정원 한 명인 같은 시간대를 예약하려고 하면 두 번째 확정 안내를 받을 수 없어야 합니다. 취소 시 예약 가능 상태를 어떻게 복구할지도 합의하세요. 이런 사례는 ‘예약 관리’라는 표현으로는 정해지지 않는 결정을 드러냅니다. 누가 검토하고 범위 변경을 승인할지도 정하세요.
- 대표 사용자를 통해 완결된 업무를 검토하세요.
- 질문은 승인된 요구사항과 구분해 기록하세요.
- 충돌하는 우선순위를 조정할 담당자 한 명을 지정하세요.
일상적인 사용으로 전환하는 과정도 포함하세요
출시 후 누가 애플리케이션을 관리하고 기존 데이터를 도입하며 사용자를 지원할지 설명하세요. 팀에 필요한 교육이나 인계 자료를 파악하세요. 문제 보고 방식과 업데이트 검토 방법도 확인해야 합니다. 이런 내용이 있어야 작동하는 시연에서 기업이 운영할 수 있는 제품으로 옮겨가는 실무 과정까지 개발 범위에 포함할 수 있습니다.