구축의 기본 절차 (2) 요구사항 정의와 확정
요구사항 정의서(PRD) vs 제안서 vs 수행 계획서
PM이 수행 계획서를 작성하고 나면, 그때부터 기획자가 본격적으로 움직이기 시작한다. 이 때 기획자가 가장 먼저 작성하는 산출물은 '요구 사항 정의서'이다. PRD(Product Requirements Document)라고 부르기도 한다.
요구사항 정의서와 수행 계획
요구 사항 정의서는 RFP나 미팅에서 나온 요구 사항들을 체계적으로 정리한 문서이다.
기획자가 요구 사항을 수집하고, 이를 바탕으로 요구 사항 정의서를 작성한다.
요구 사항 정의서는 기획자의 중요한 첫 번째 산출물이다. PRD는 제안서와 내용이 유사해 보이지만, 차이가 있다.
- 제안서는 RFP에 따른 변화와 그에 따른 제안 사항을 담고 있는 반면, (변화에 대한 약속)
- 수행 계획서는 절차에 대한 약속을 담고 있다.
- 수행 계획서에는 프로젝트의 인원 투입, 진행 방법, 마일스톤, 산출물 등이 포함된다.
기획자가 작성하는 첫 번째 산출물이 바로 요구 사항 정의서이다.
이를 통해 프로젝트의 요구 사항이 체계적으로 정리된다.
요구 사항 정의서의 작성은 기획자가 주도적으로 진행하며, 이를 바탕으로 프로젝트는 다음 단계로 넘어간다.
요구사항 정의서 구성 요소와 작성 방법
크게 상품 전시, 주문 결제, 회원 관리 및 고객 서비스(CS) 등 주요 분야별로 요구 사항을 구분하여 작성한다.
(각각 한 파트)
- 각 파트별로 담당자를 배정하고, 요구 사항을 정리하는 방식으로 진행된다. 기획팀 세팅 시부터 명확함을 보증하기 위함.
요구 사항 정의서에는 요구 사항의 출처도 명확히 기록해 두어야 한다. 요구 사항이 어디서 나왔는지, 누가 제시했는지 기록하는 것은 나중에 분쟁이 발생했을 때 유용하다.
- 요구 사항을 수집하고, 이를 담당자별로 분배하여 체계적으로 관리한다.
- 예를 들어, 상품 전시, 주문 결제, 회원 CS 등 각 파트별로 담당자가 요구 사항을 체계적으로 수집하고, 이를 기반으로 설계를 진행한다. 담당자가 요구 사항을 명확히 인식하고 있어야 설계가 원활히 진행될 수 있다.
- 회원/CS가 가장 간단하며, 상품 / 전시가 미디엄 단계, 주문/결제가 가장 어려움.
- 이 때 기획자는 요구 사항을 체계적으로 수집하고, 이를 문서화하여 요구 사항 정의서를 작성한다.
- 요구 사항을 정리할 때는 출처와 분류를 명확히 하여, 후속 작업이 원활하게 진행될 수 있도록 한다.
- ex. 킥오프 미팅 회의 때(회의록)에서 했는지, 아니면 RFP에서 했는지. 언제 누가 냈는지 파악.
- 접수는 기획자가 하지만 PM이 수용 여부 결정한다.
- 또한, PM이 수용 여부를 결정하는 단계에서 기획자는 요구 사항의 해결 방안을 제시하는 역할을 한다.
=> 이 때, 리서치 리포트라는 산출물이 사용된다.
리서치 리포트
- 리서치 리포트는 요구 사항에 대한 해결 방안을 제시할 때 사용된다.
- 기획자의 머릿속에 있는 정보가 아니라 객관적인 데이터를 중시하므로 그렇다.
- 예를 들어, 정기 배송에 대한 요구 사항이 있을 경우, 쿠팡, 마켓컬리, 아마존 등에서 제공하는 정기 배송 서비스를 벤치마킹하여, 가장 적합한 해결 방안을 제시하는 것이다.
- 요구 사항 정의서에 리서치 결과를 반영하고, 이를 협의하여 최종 확정하게 된다.
요구 사항의 확정
요구 사항 정의서에 기록된 내용이 모두 협의되고 확정되면, 그 날짜를 기록하고 확정된 요구 사항으로서 프로젝트의 기반이 된다. 이러한 절차를 거쳐서 요구사항을 확정한다라고 하는 절차를 거쳐야지만 착수 끝 설계 수작의 근거로서 요구사항 정의서로 활용될 수 있다.
- 착수 단계에서 요구 사항이 확정되면, 그때부터 설계 단계로 넘어가게 된다. 설계 단계로 빨리 넘어가는 것이 중요한 것처럼 보일 수 있지만, 요구 사항이 확정되지 않은 상태에서 설계에 들어가면 반복 작업이 발생할 수 있다.
⇒ 시간 더 많이 소요.
=> 그래서 요구 사항을 명확히 확정한 후에 설계에 들어가는 것이 더 효율적이다.
설계는 요구사항 정의서 범위 내에서만.
- 프로세스는 As-is 있고 요구사항을 반영했을 때 나올 수 있는 모습이 a안과 b안이 있다면 기획자가 저는 a안이 좋을 것 같은데 b 안도 나쁘지 않을 것 같아요라고 얘기하는 형태가 가장 좋은 그림.
- To-be를 두 가지로 쓴다는 것.
요구 사항 확정 이후
착수의 시작은 계약 또는 지시 / 착수의 끝은 요구 사항의 확정
요구 사항이 확정되면 설계는 크게 정보 설계와 화면 설계로 나뉜다.
- 정보 설계의 산출물은 '정보 구조도'이며,
- 화면 설계의 산출물은 '화면 설계서'이다.
> 정보 설계는 기존 데이터를 재구성하여 새로운 사이트를 만드는 것이며,
> 정보 구조도는 사이트의 정보를 페이지 단위로 정리한 것이다.