서비스 기획 절차의 이해 - 1

참고 블로그 : 서비스 기획 절차의 이해 상, 하

자세한 내용과 예시 이미지는 위 브런치에 친절하게 설명되어 있다.
그리고 브런치 덕분에 서비스 기획 절차에 대한 큰 흐름을 알 수 있게 되어서 기쁘다.

 

기획 순서

사업 분석 - 주요 기능 정의 - 기능 명세서 / 기술 요구사항 작성 - 개발 일정 수립 - 스토리보드 작성

기획은 크게 위와 같이 진행되며, 적히지 않은 다른 항목들이 진행될 수 있다.

 

"어떤 서비스를 만들어야 할까?"로 부터 기획은 시작되며, 프로젝트의 소유자와 구성원 또는 회사의 수익창출과 일맥상통하는 기획을 해야한다. 

또한, 회사는 어떤 수준까지 개발 될 수 있는지 정확히 이해하고 있지 않기 때문에 이를 확신하기 위해 시장 조사에 집중하고, 기능의 수익성을 집중적으로 분석한다. 결과적으로 서비스 기획자는 기능적, 프로젝트 관리 측면에서 이를 이해하기 위해 노력해야 한다.

 

기획 순서 1. 사업 분석

사업 분석은 크게 2가지를 세심하게 관찰하면 좋다.

1. 외부적 요소 : 목표 시장의 형태(시장 규모, 성장 방법, 영향 요소)
- 사업 기획자 만큼의 사업 분석은 하지 않아도 되지만, 서비스 기획자의 사업 분석은 어떤 시장에서 몇 개월 내에 론칭해야 효용성 있을지 확신이 생길 때 까지는 분석해야 한다.

2. 내부적 요소 : 서비스의 수익 창출 형태, 사회적 기여 여부
- 유사 서비스를 찾을 수 있다면, WWIT 와 같은 사이트를 이용하여 화면 캡쳐를 통해 서비스를 분석한다.
     - 분석할 서비스를 화면별, 기능별로 구분짓기 (정보의 계층이 다른 경우도 있으니 체크)
     - "왜 이 서비스는 이런 방법을 택했을까?"
     - 분석하는 서비스의 고객수, 수용 범위 분석/생각해보기

 

기획 순서 2. 주요 기능 정의

- 주요 기능 정의

올바른 정보를 수집, 수집한 정보를 바르게 이해 - 분석할 줄 알아야 한다.

- 주요 기능의 보조 기능 등을 정의

 

기획 순서 3. 기능 명세서 / 기술 요구사항 작성

- 기능명세서

기능명세서에는 무엇을 개발하는지, 어떻게 개발할 것인지, 언제 개발이 시작되고 완료되어야 하는지 정의한다.
100% 정확할 필요는 없지만, 정확하게 작성하기 위해 노력해야한다.

 

- 기술 요구사항

구체적인 개발 환경을 정의한다. 개발 언어, Framework, DB 등을 의미한다.

서비스 기획자가 모든 개발 용어를 알 필요는 없지만, 현재 우리의 서비스가 어떻게 구성되어 있는지, 개발자가 어떤 환경에서 개발하는지는 매우 중요하기 때문에 반드시 알고 있어야 한다.

 

기획 순서 4. 개발 일정 수립

- 화면과 기능 단위 개발 (주로 소규모 서비스 기획)

기획 완성도가 매우 높아야 한다.

- 프라모델을 조립하듯 각 부품들이 정교하게 합쳐질 수 있도록 철저한 품질 검증 단계를 구축해야 하기 때문
- 서비스가 완전히 완성되기 전까진 그 형태를 충분히 확인하기 어렵기 때문에, 화면과 최소 기능 단위 테스트가 중요
- 개발자와 공조하여 최소 기능 단위의 테스트를 위한 문서를 작성하거나 TDD(Test Driven Developer)를 위한 개요를 설계해야 한다.

 

- 최소 기능 단위 개발 (MVP : Minimum Valiable Product)

중간에 완성한 버전이 실제로 사용화 가능한 서비스여야 한다.

형태가 독립적으로 가치가 있다면 좋지만, 최종 단계의 한 부분이더라도 실제로 서비스화 할 수 있으면 문제없다.

예 - 글만 올릴 수 있는 SNS를 만들고 이후 댓글을 달 수 있는 SNS를 만드는 형태를 말한다.

 

한 가지 방법으로만 일정을 수립할 수는 없다.
규모와 마감일을 바탕으로 두 가지를 적절하게 섞는 것이 서비스 기획자, PM, PO의 역량이다. 

 

+ 개발 일정 변동 사유

DB 변동	주요 기능 변동	심각한 오류	오구현
절대 발생하지 말아할 경우 만약 발생했다면 작업을 최소화 할 수 있는 방향성으로 고민해야 한다.	현재 버전을 빠르게 완료할 수 있다면 개선작업으로 이관. 그렇지 않다면, 전반적인 일정을 수정해야 한다.	급하게 개발하거나 커뮤니케이션 부족의 경우 자주 발생. 주요 기능에대한 UNIT 테스트 문서를 미리 작성했다면 어느 정도 피할 수 있다.	커뮤니케이션 오류로 엉뚱한 형태로 기능이 개발된 경우. 커뮤니케이션의 중요성을 보여주는 변동 사유이다.

 

기획 순서 5. 스토리보드 작성

스토리보드는 꼼꼼하게 작성해야만 한다.

- 정보구조 (IA : Information Architecture)

스토리보드의 목차 = 정보구조

정보구조는 서비스에 포함된 정보들을 이해할 수 있는 가장 기본적인 방법이다.

- 거시적인 이해도 향상을 위해 작성한다.
- 모든 정보를 단 번에 이해할 수 있는 커다란 정보구조를 설계하는 것이 기본이며, 경우에 따라 세부적으로 정보구조를 묘사할 수 있다.

 

- 스토리보드

여러 화면은 독립적으로 존재하는 것이 아닌, 서로 상호작용 하고 있다는 사실을 잊지 말아야 한다.

스토리보드는 화면의 이름과 함께 각 화면의 형태가 그려진다.
- 버튼의 위치나 출력이 필요한 정보들은 반드시 존재해야 하며, 좀 더 나아가 버튼으로 인해 파생 혹은 변경 상태까지 표시할 수 있다.

화면의 이름을 잘 정하는 것도 중요하다.
- 화면의 위치를 빠르게 파학하기 위함이다.
- 또한, 각 레벨에 어떤 기능이 있는지 알고 있어야 돌발 상황에 빠르게 대처할 수 있다.

 

+ 스토리보드에서 설명이 중요한 부분

상태	동작	문제와 해결	수량
상태에 따른 변화	상호작용에 대한 결과	오류가 발생하는 경우에 대한 설명과 해결 방법	아무것도 없는 페이지 포함, 텍스트와 컴포넌트의 개수에 따른 변화
검색 전 - 후 보이기 - 감추기	확인, 경고 다이얼로그 설명은 필수	유효성 검사 실패 시 유저 입장의 해결방법