온라인 서비스를 기획하는 것과 그 서비스를 개발 기획하는 것은 다른 기획입니다. 기획의 대상과 목표가 다르기 때문입니다. 여기서는 온라인 서비스 기획과 개발이 분리된 상황에서 개발 기획 과정과 방법에 대해 알아보려 합니다.
온라인 서비스 개발 대상의 확인
온라인 서비스 기획과 서비스 개발 기획이 분리된 대표적 상황은 아마도 개발을 외주 주는 경우일 것입니다. 외주 개발의 경우 SI나 웹에이전시의 기획자가 서비스 기획 내용을 듣고 정리하게 됩니다. 이를 요구사항(명세서) 정의라고 합니다.
- 요구사항 명세서 정의 : 개발할 서비스를 파악하고 개발과 관련하여 구체화하는 작업 과정. 고객의 요구사항을 파악하고 이를 투입할 개발자와 디자이너가 작업할 수 있도록 개발/디자인 상황을 구체화함.
요구사항이 잘 정리된다면 향후 진행될 기획 산출물의 작성 속도와 완성도를 높일 수 있습니다. 서비스 개발에 참여하는 기획자의 역량은 요구사항 명세서를 작성하는 것만 보아도 알 수 있습니다. 또한 외주 개발 과정에서 어떤 분야를 주로 작업했던 기획자 인지도 파악할 수 있습니다.
일반적으로 서비스 외주 개발에 참여하는 기획자는 크게 3 분류로 구분할 수 있습니다.
- 화면 설계 중심 : UI 및 디자인 기획을 주로 진행하였던 기획자
- 기능 설계 중심 : 서비스 기능을 중심으로 기획을 진행하였던 기획자
- 사업 관리 중심 : 프로젝트 사업 관리를 중심으로 기획 업무를 진행하였던 기획자
화면 설계 중심 기획자는 서비스를 화면 중심으로 파악하고 설계합니다. 그래서 주로 디자인 업무를 중심으로 서비스를 바라봅니다.
기능 설계 중심 기획자는 서비스가 제공하는 기능 중심으로 서비스를 파악하고 설계합니다. 그래서 주로 기능 개발 중심으로 서비스를 바라봅니다.
사업 관리 중심 기획자는 프로젝트 관리 관점에서 서비스를 파악하고 관리합니다. 주로 PM, PL의 시각으로 서비스를 바라보게 됩니다.
이것은 같은 경영 기획자라고 재무 기획자와 인사 기획자, 마케팅 기획자, 상품 기획자 이상 시각과 인지 과정에 차이가 있습니다. 그러기에 똑같은 대상을 보더라도 이를 해석하고 기획하는 것이 다르게 됩니다.
이는 서비스 경험이 사용자마다 다른 것 이상 차이가 있게 됩니다.
서비스 프로세스(플로우) 기획
요구사항을 정의했으면 이를 구체화한 후 주요한 서비스 프로세스 설계합니다. 이는 가입 유저가 서비스 사용 시 프로세스 일 수도 있고, 서비스를 사용할 때 작동되는 기능과 데이터의 프로세스일 수도 있습니다.
무엇이 되었던 서비스 프로세스(플로우)는 서비스가 제공되는 과정을 파악할 수 있어야 합니다.
요구사항이 잘 듣고 적는 것을 넘어 서비스 개발을 위한 정리가 잘 이루어졌다면 요구사항 명세서를 기반으로 서비스 프로세스를 도출하기 쉬울 것입니다.
그러나 만약 서비스 프로세스 도출에 요구사항 내용을 넘어 너무 많은 상상과 벤치마킹이 포함된다면 요구사항 정의가 부족해 일 수도 있습니다.
서비스 제공 기능 설계
개발될 서비스에서 제공되는 기능은 요구사항에 이미 다 나와 있습니다. 서비스 제공 기능 설계를 위한 문서인 서비스 기능 정의서는 요구사항에 나온 서비스 기능 부분을 모아서 개발자가 기능 내용을 이해하여 개발이 원활히 진행될 수 있도록 정리된 문서라 볼 수 있습니다.
- 기능 정의서 : 요구사항 명세서에 정리된 내용 중 기능 관련 사항을 분리하여 개발에 적합하게 설명을 넣어 적은 문서. 목표 서비스 개발을 위해 필요한 기능을 모두 나타냄.
앞서 작성한 요구사항 정의 문서와 서비스 프로세스(플로우) 설계 문서가 있다면 서비스 기능 설계를 위한 정의서 작업은 그리 어려운 일이 아닙니다.
이 문서 작업이 어렵다면 요구사항(명세서) 정의에 문제가 있는 것일 수 있습니다. 그러므로 서비스 개발을 위한 기획에서 가장 중요한 작업은 요구사항 명세서/상세화/정의서 작업이라 할 수 있는 것입니다. 이 작업하는 것만 보아도 기획자 역량을 알 수 있다는 의미도 여기에 있습니다.
서비스 화면 설계
시비스 UI 기획 또는 디자인 기획을 포함한다고도 말할 수 있습니다. 서비스 오픈 시 유저, 관리자가 이용하는 화면을 설계합니다. 기능 개발 중심 기획자나 화면 설계 중심 기획자의 문서는 비슷해 보이지만 설명(description) 내용과 화면 설계를 이어가는 방식에서 확연한 차이를 나타냅니다.
이는 결과적으로 스토리보드 작업 시 튼 차이를 나타내게 됩니다.
서비스 화면 설계는 IA 또는 서비스 맵에서 세부 카테고리로 진행하여 모든 서비스 화면을 표시하고 정의합니다. 서비스 화면 설계서를 통해 디자이너는 디자인 작업 양과 질을 파악하고, 개발자는 각 화면의 데이터 처리 기능과 작동 내용을 파악합니다.
- IA
- 카테고리
- 카테고리별 세부 화면
서비스 화면 설계는 서비스 제공 기능 설계와 연결되어 있어야 합니다.
또한 서비스 화면 설계 시 디자인 공통이나 중요한 서비스 화면 아이덴티티(identity)나 인터렉션(interaction) 사항이 있다면 추가 문서를 활용하여 정의합니다. 때로는 와이어프레임 방식이 사용될 수도 있고, 디자인 가이드 문서가 사용되기도 합니다.
스토리보드 작성
제가 작업하던 시기에는 시나리오 작업이라 불렀습니다. 지금은 스토리보드라고 이야기합니다. 주로 문자로 표현되는 느낌의 시나리오보다는 광고나 콘텐츠 제작 시 작업될 화면을 설명하는 이미지와 설명이 들어 있는 스토리보드가 더 작업될 문서에 적합할 것 같기는 합니다.
지금까지 문서가 잘 작성되었다면 이를 참고하여 스토리보드 작업은 수월히 진행될 것입니다. 그래서 스토리보드 작업은 주로 연차가 작은 주니어 기획자가 작성합니다. 문서 디자인이나 작업량이 많은 문서 작업의 속도는 나이가 어린 주니어 기획자들이 더 효율적이기 때문입니다.
- 요구사항 정의, 프로세스 설계, 기능 정의서, 화면 설계서 - 시니어 기획자
- 스토리보드 - 주니어 기획자
스토리보드의 문서 작성 난이도 역시 다른 작업에 비하면 낮은 편이나 작업량은 많은 관계로 주니어 기획자가 주로 작업하게 됩니다.
그러나 앞서 작업해야 할 요구사항 정의, 프로세스 설계, 기능 정의서, 화면 설계서가 제대로 작성되지 않고 진행되는 서비스 개발 프로젝트도 상당히 존재합니다. 이 때는 주니어 기획자가 스토리보드를 작성하기에는 무리가 있게 됩니다. 이 상황에서는 시니어 기획자가 스토리보드 작업을 하게 됩니다.
그러나 이렇게 작업한 경우 외주 개발을 맡기는 고객 기획자와 서비스 개발 기획자가 한 팀처럼 움직이지 않는다면 스토리보드가 완료되고 개발이 진행될 때 시시각각 수정 사항이 나와 스토리보드가 수정될 가능성이 큽니다. 이로 인해 개발 전체가 흔들리게 되는 게 기준이 되는 문서가 없으므로 개발에 문제가 생기기도 합니다.
서비스 개발 기획 시 주의 사항
주의 사항 내용은 서비스 개발 기획 방법의 핵심적인 인사이트를 제공할 것입니다.
기획은 특정 시점의 결과물이 아니라 목표한 것을 달성하기 위한 계획을 설계하고 이를 관리하는 과정입니다. 그러므로 서비스 개발 기획의 각 내용은 상호 연결성을 가지고 동일한 목표에 대한 흐름을 공유하고 있어야 합니다.
이것이 없는 기획과 문서는 기획 과정의 산출물이라기보다는 문서작업 결과라 보는 것이 더 타당할 것입니다. 이렇게 작업된 기획서는 결국 개발자와 디자이너의 더 많은 생각과 노력을 요구하게 됩니다.
댓글