기능 요구사항 정의 5단계 [ 사용자 > 목적 > 과정 > 요소 > 예외 ]

우리가 만드는 대부분의 온라인 프로덕트는 결국 데이터와 통신으로 이루어 집니다.
”어떤 데이터를 어디서 가져와서, 어떻게 보여주고, 어떻게 변경할 수 있게 할 것 인가?”
지금 위 문장이 크게 와닿지 않을 수 있습니다. 이번 글을 통해서 위 문장을 같이 이해해보겠습니다.

 

주니어 PM이 PRD를 작성할 때, 가장 막히는 부분은 ‘기능 요구 사항’ 부분입니다.
배경 혹은 목적, 목표등은 비교적 간단히 작성될 수 있습니다.(* 주니어의 경우 Operation이 메인 태스크이기 때문)
하지만 ‘기능 요구 사항’ 부분은 흔히 생각하게 되는 영역은 아니기 때문에 어려울 수 있습니다.
이 ‘기능 요구 사항’을 작성하는 과정이 결국 ‘어떤 데이터를 어디서 가져와서, 어떻게 보여주고, 어떻게 변경할 수 있게 할 것인가?”입니다.

 

평소에 우리가 사용하는 웹 서비스나 어플리케이션이 만들어지기까지,
뒤에서 제품 개발자(이하 PM, 개발자, 디자이너를 통칭함)의 고민과 실행이 필요합니다.
하지만 우리는 결과만 봅니다. 그 제품이 어떻게 만들어졌는지에 대해서 평소에 크게 고려하지 않습니다.
때문에 이러한 과정이 낯설게 느껴질 수 있습니다.

** PM이라면 평소에 프로덕트를 볼 때 어떤 과정을 통해 이것이 만들어졌는지를 생각해보게 됩니다.

 

예를 들어 이런 식입니다.

 

우리는 책상 위에 있는 사과를 한 입 베어물고자 할 때, 크게 고려하지 않아도 자신의 몸을 움직일 수 있습니다.
하지만 그 과정을 아무 경험도 없는, 무의 상태에서는 이런 식으로 정의해야할 것입니다.
일단 사과를 볼 수 있어야 하기 때문에 시각 세포가 사과를 인식하게 되고, 인식을 한 후에 팔의 근육들을 조정하여 사과까지 이동한 후에 집고,
입까지 가져와서 적정한 크기로 입을 벌려서 사과의 강도보다 더 세게 물고, 삼킬 수 있는 정도의 크기로 여러 번 반복해서 턱 근육을 사용한 후 삼켜야 합니다.
혹은 오히려 그 이전 단계에서 사과라는 것이 어떻게 생겼는지부터 정의해야 할 수도 있습니다.

 

우리가 어떠한 목적을 이루기 위해 행동할 때 이런 과정을 거칩니다. 
달성하고자 하는 목적, 목적을 달성하기까지의 과정이 정의됩니다.
그리고 각 과정에서의 필요한 요소들이 정확하게 규정되어야 합니다.
왜냐하면 단순히 위의 가정에서만 보더라도 중간 과정에서 하나라도 실수를 하면,
원하는 목적이었던 사과를 먹는 행위는 달성할 수 없습니다.

 

온라인 프로덕트를 만들 때 우리는 어떻게 이러한 과정들을 MECE하게 구성할 수 있을까요? 

 

1. 사용자를 정의합니다. 경우에 따라 3명의 사용자 혹은 그 이상이 될 수 있습니다.
2. 사용자가 달성해야하는 목적을 작성합니다.
3. 목적을 달성하기 위해 필요한 과정을 작성합니다.
   과정을 정의할 때 데이터의 시작점과 끝점을 잘 정의할 수록 누락되는 흐름이 없습니다.
4. 각 과정에서 필요한 요소를 작성합니다.
   여기서의 요소는 주로 화면과 데이터입니다.
5. 엣지 케이스 혹은 예외 상황을 고려하여 추가합니다.

 

이렇게만 설명하면 어려우니 이제 사례를 덧붙여서 설명하겠습니다.
3명의 사용자가 필요한 케이스인 배달 플랫폼을 만든다고 가정하겠습니다.
이 중에서도 음식을 제공하는 사장님 입장에서 필요한 프로덕트를 정의해보죠.
** 이 경우 사용자는 사장님, 배달 파트너, 주문자 입니다.

 

1. 사용자를 정의합니다.

    - 배달 플랫폼을 통해 음식을 판매하고자 하는 사장님.

2. 사용자가 달성해야하는 목적을 작성합니다.

    - 사장님은 손님에게 음식을 주문 받고 배달파트너를 통해 음식 배달을 통해 돈을 벌 수 있어야 합니다.

3. 목적을 달성하기 위한 과정을 작성합니다.

    - 사장님 권한으로 회원가입
    - 운영하는 매장을 등록
    - 판매하고자 하는 음식을 등록
    - 주문 수신 시 배달 파트너 호출
    - 손님에게 음식이 배달 되었는지 확인
    - 배달 판매 수익 조회
    - 배달 판매 수익 정산

4. 각 과정에서 필요한 요소를 작성

    - 사장님 권한으로 회원가입
        - 역할을 선택한 후에 본인 인증을 통해 회원가입을 진행합니다.
        - 데이터 : 본인 인증할 수 있는 데이터
        - 페이지 : 회원가입 페이지
    - 운영하는 매장을 등록
        - 사업자 등록증 및 사장님 인적 정보 그리고 사업장 정보를 입력할 수 있는 페이지가 필요합니다.
        - 데이터 : 사업자 등록증, 사장님 인적 정보, 사업장 정보
        - 페이지 : 매장 등록 페이지
    - (생략)
    - 배달 판매 수익 조회
        - 사장님이 어떠한 음식을 주문 받았었고, 배달을 통해 얼마나 벌었는지 확인할 수 있어야 합니다.
        - 데이터 : 주문별 음식 종류, 금액, 배달 수수료, 최종 결제 금액 등
        - 페이지 : 배달 판매 수익 대시보드
    - 배달 판매 수익 정산
        - 회원가입시 입력한 계좌로 정산 신청한 금액만큼 신청일자 기준 7일 이후에 정산금을 지급합니다.
        - 데이터 : 정산 가능 금액, 신청 금액, 정산 예상 일자
        - 페이지 : 정산 신청 페이지

5. 엣지 케이스 혹은 예외 상황을 고려하여 추가합니다.

    - 사장님 권한으로 회원가입
        - 누구나 사장님 권한으로 회원가입할 수 있으나, 실제 사장님 권한을 획득하는 것은 사업자 등록증을 인증한 매장이 있는 경우임.
    - (생략)
    - 배달 판매 수익 정산
        - 정산은 주문 확정일이라고 볼 수 있는 주문 후 3일이 지난 배달 건에 대해서만 정산이 가능함.
        - 최소 정산 금액에 미달하는 경우 정산은 불가능함.

 

우선은 사장님 입장에서 봤을 때의 기능 요구 사항을 정의해봤습니다.
많이 생략을 했지만 길이가 꽤 깁니다. 하지만 여기서 끝이 아닙니다.
아마 배달 파트너, 주문자의 관점에서 기능 요구 사항을 정의하다 보면,
사장님 입장에서 추가되어야 하는 프로세스들이 나올 겁니다.

 

1~5번까지 전부 중요합니다.
하지만 여기서 강조하고 싶은 내용은 3, 4번에 대한 내용입니다.
3번에서 시작점을 잘 정의할 수록 이후 단계들을 수월하게 작성할 수 있습니다.
단순히 수월하다 뿐 아니라 누락되는 흐름을 없앨 수 있습니다.
또한 3번이 잘 정의될 수록 4번에서 필요한 요소들이 정의가 됩니다.

 

더 정확하게는 어디서 데이터가 생성되는지를 고려해보시면 좋습니다.
그리고 그 데이터가 시작되는 부분이 유저의 시작점이 될 확률이 높습니다.

 

그러면 3번을 잘 정의하기 위해서는 어떤 점을 더 신경써야 할까요?
당연하게도 실제 사용자가 될 유저와 인터뷰를 해야합니다.
실제로 어떻게 배달 주문을 받고 있는지, 어디서 어려움을 겪고 있는지,
PM이 생각했던 프로세스를 검증하고 누락된 부분을 점검하고 유저가 겪고 있는 어려움을 파악해야합니다.

 

위 사례에서는 매장 운영시간, 브레이크 타임…등이 빠져있습니다.
사장님과 대화하지 않고 프로덕트를 만들었을 때, 이렇게 누락이 발생하게 됩니다.
그리고 이 피해는 고스란히 배달 파트너와 주문자에게 이어지게 되죠.
시작점을 잘 정의하고 사용자 입장에서의 흐름을 고려하되,
사용자와 대화하는 것을 절대 미루지 마세요.

 

이전 글에서도 말씀드렸다 싶이 PRD는 진행형입니다.
팀원과 그리고 유저와 소통하고 문서를 업데이트 하세요.

 

부족한 부분은 언제든 yungsu2391@gmail.com으로 연락주세요! 감사합니다 :)