[나의 서비스기획 이야기] 기획서는 어떻게 쓸까? 2편
[나의 서비스기획 이야기] 기획서는 어떻게 쓸까? 1편
[나의 서비스기획 이야기] 기획서는 어떻게 쓸까? 2편
[나의 서비스기획 이야기] 기획서는 어떻게 쓸까? 3편
어제에 이어 서비스기획자의 기획서에 대한 이야기를 이어가보겠다. 지난 시간에는 1)기획 범위 결정과 2)벤치마킹까지 이야기했다.
3) 작업할 기능(Function) 정리
벤치마킹까지 마무리했다면 이제부터는 구체적으로 무엇을 만들지에 대한 그림을 그리는 단계이다. 프로젝트의 목적을 수행하기 위한 구체적인 실행방안을 나열하는 것이라고 보면 된다. 배달 플랫폼을 만들겠다고 하면 소비자에게는 가게 리스트, 메뉴, 주문 화면 등을 보여주어야 한다. 그리고 음식점에는 배달 주문이 들어왔음을 알리는 화면이 필요하다. 플랫폼 관리자에게는 소비자의 주문내역과 음식점의 등록현황 등을 관리할 수 있는 어드민 화면이 필요하다. 이런 식으로 세부 사항들을 나열하고 이를 다시 한번 더 잘게 나눈다. 주문 화면이라고 하면 주소입력, 결재방식 선택, 쿠폰 적용, 가게 요청 사항 작성 등 화면 안에 들어가야 하는 세부사항들을 상세하게 적어보는 것이다. 작업할 기능을 리스트업할 때는 누가 사용하는지를 기준으로 나누어보면 좋다. 방금 보았던 것처럼 배달 플랫폼 사용자는 3가지로 나누어진다. 주문을 하는 고객, 음식점 그리고 플랫폼 관리자이다. 라이더도 플랫폼에 들어와야 한다면 사용자 분류는 4가지로 늘어난다. 다음으로는 각 사용자가 자신만의 목표를 달성하기 위해 반드시 거쳐야하는 프로세스를 기준으로 기능을 나누어볼 수 있다. 고객이 배달음식을 주문하고 집에서 음식을 먹을 때까지의 과정을 살펴보면 다음과 같다. 배달앱 접속 --> 로그인 --> 음식점 탐색 --> 메뉴 탐색 --> 리뷰 탐색 --> 음식 주문 --> 결재 --> 배송현황 확인 --> 음식 수령 --> 리뷰 작성. 대충만 살펴봐도 10단계로 나누어진다. 각 단계마다 사용자들은 저마다 다른 목적을 가지게 된다. 그래서 이렇게 단계를 나눈 후 각 단계를 달성하기 위해 필요한 기능을 정리해보면 좋다.
나는 기능 정리를 할 때, 엑셀을 사용했다. 내용이 많기도 하고, 사용자나 프로세스별로 혹은 화면별로 기능을 구분해서 정리하기도 편하기 때문이다. 이렇게 정리해두고 나서, 사용자 입장이 되어서 기능들을 살펴본다. 사용자가 각 단계에서 필요한 모든 과업(Task)을 수행할 수 있는지 생각해보는 것이다. 기능 목록을 정리해두면 나중에 와이어프레임을 그릴 때에도 유용하다. 각 화면이 수행해야 할 목적과 각 화면에 포함되어야 할 기능들을 알고 있기 때문에, 이에 적합한 화면을 그릴 수 있다. 또한, 기능을 화면에서 누락하지 않게 된다.
4) 기존 시스템과의 상충 여부 파악
이제 어떤 기능들이 필요한 지를 알았으니, 이제부터는 이것이 구현 가능한 지를 파악해야 한다. 만들 수 없는 것이라면 설계를 빠르게 바꾸어야 한다. 우선은 내가 기획하려고 하는 기능과 현재 서비스 사이에 상충되는 부분은 없는지 확인해야 한다. 예를 들어, 최근 1개월 간의 주문 데이터를 활용해서 우수고객에게 자동으로 쿠폰을 발급하는 기능을 추가한다고 해보자. 그런데 회사에서는 비용 상의 이유로 15일 간의 데이터만 저장하고 있다면, 해당 기능을 온전히 구현하지 못할 수 있다. 때로는 새로운 기능을 넣거나 기존의 정책을 바꾸는 것도 가능하지만, 때로는 나의 기획안을 바꾸어야 하기도 한다. 기존 시스템을 변경할 때의 영향이 고객들이 쌓아둔 데이터나 결제 금액 등과 관련이 있다면 쉽게 건드리기 어려울 것이다. 기존 시스템과의 상충이 없더라도 다른 프로젝트와 상충이 생기는 경우도 발생할 수 있다. 동료 기획자들이 참여하고 있는 프로젝트에도 관심을 가지고 소통해야 하는 이유이다. 이럴 경우에는 논의를 통해 문제의 발생가능성을 사전에 차단해주어야 한다.
5) 1차 개발 리뷰(with 백엔드 개발자)
현재 시스템과의 상충되는 부분이 없다고 판단되면, 개발자와 논의를 통해서 개발 가능 여부를 검토한다. 1차 리뷰는 백엔드 개발팀과 진행하게 된다. 리뷰 과정에서 개발팀의 관점으로 바라본 기존 시스템과의 상충 여부를 확인할 수 있다. 또한, 투입 가능한 개발 리소스, 예상 작업 기간, 작업 착수 가능일 등에 대한 정보를 파악하는 것도 중요하다. 구현할 수 없는 기능이 있다면, 다른 대안은 무엇이 있을지 고민하여야 한다. 개발 예상 기간이 생각했던 것보다 훨씬 길다면, 두세번에 나누어 서비스를 오픈하거나 추가할 기능을 축소하는 등의 선택지를 택할 수도 있다. 개발팀과의 리뷰는 회의실을 잡고 시간을 정해서 할 수도 있고 기획 중간에 주기적으로 가볍게 이야기를 나누는 방식으로 할 수도 있다. 다만, 기획할 내용이 정리가 되지 않으 채로 이런저런 질문을 쏟아낸다면 의미없이 동료들의 시간을 뺏는 결과를 나을 수 있으니 주의해야 한다.
개발 리뷰를 바탕으로 구현이 가능한 기능 목록을 정리하고 나면 본격적으로 기획서 작성에 들어간다. 바로 와이어프레임을 그리는 것이다. 재미있기도 하지만 지루할 수도 있는 작업이다. 와이어프레임 작성부터는 다음 시간에 더 이야기하도록 하겠다.
2022.09.09.