티스토리 뷰

반응형

현재 근무 중인 회사에서 유일한 기획자로 일하고 있다. 기획 멤버가 많은 회사에 있다가, 서비스 기획자라는 포지션이 처음 만들어진 곳으로 이직했다. 그래서 서비스 기획 프로세스를 공유하고, 회사에 맞는 프로세스를 찾아서 공유하게 되었다. 지금까지 서비스 기획을 할 때는, 다른 멤버들도 대충 이해를 하고 있던 기획 프로세스이기에 딱히 공유 자료를 만들어 둔 것도 없었다. 그동안 해온 서비스 기획 프로세스는 어떠했을지 정리해보았다.

온라인 서비스 기획 프로세스

1단계 요구사항 분석
Top-down 의사결정을 하는 회사에서는 보통 상위 리더가 "OOO 해보자"로 매우 간단하게 요구사항이 내려오고, 리더의 선구안을 믿고 요구사항 분석을 시작한다. 또는 사업제안을 할 경우에도 요구사항에 대한 분석이 필요하다.  요구사항 분석을 철저하게 하다 보면, 리더의 선구안을 미필적 고의로 깔 수밖에 없는 상황이 오기도 한다. 리더의 명령이고, 타 팀 요청이니깐 프로젝트 기획을 했다가 실패라도 하면 책임의 화살은 기획자로 향하게 된다. 요구사항 분석은 말 그대로, 요구하는 것이 무엇일까?를 고민해보는 것이다. 달리 말하면, 기대하는 프로젝트의 결과물이다. 일반적으로 아래와 같은 요구사항을 체크하였다.

(1) User Needs
이 서비스 또는 기능이 User에게 정말 필요해? User의 요청이나 불만 표시가 있었어? 를 체크한다. 일반적으로는 담당자의 촉이 발산하여 'OOO이 있으면 User가 좋아할 거야' 로 아이디어 발제가 된다. 아이디어는 들어보면 좋다. 하지만 의심해야 한다. 담당자인 우리만 좋은 것일 수도 있다. 보통은 리서치나 고객센터를 통해 접수되는 불만사항들를 통해 User Needs를 파악한다.

(2) 마켓 규모와 성장 가능성
온라인 서비스는 무료가 많다. 무료 서비스도 만들려면 돈이 투자되어야 한다. 최소한 투자원금이라도 회수할 수 있는 시장인지를 간단하게 분석해봐야 한다. 신규 서비스를 만들어 직접적인 기여를 할 수도 있고, 신규 기능을 만들어 서비스 발전에 간접적 기여를 할 수 있다. User Needs 파악이 끝나면, 그 요구사항을 해결하는 서비스를 오픈하거나 기능을 구현했을 시장 규모와 시장의 성장 가능성을 분석해야 한다. 종속된 산업의 트렌드 분석이나 서비스 벤치마킹을 통해 확인하는 것이 일반적이다. 


2단계 요구사항 정의
요구사항을 분석해보니, '이 프로젝트는 해볼 만하다!'라면 요구사항에 대한 상세한 정의가 필요하다. 텍스트로만 이루어진 상세 기획안이라고 생각하면 이해하기 쉽다.

(1) 프로젝트의 추진배경/목적/목표/단계별 목표
(2) 구현 서비스의 FLOW 또는 구현 기능의 USER FLOW(Activity 중심으로)
(3) 마일스톤 또는 이터레이션
단계별 목표에 따라 성과 측정 후 추가 개발 검토

3단계 사업성 평가 후 진행 여부 결정
(1) 신규 사업
제안 단계부터 참여한 모든 멤버가 모여 결정하는 게 좋다. 경영진이 결정한 경우엔, 방향성이 자유롭지 않고 일정도 늘 촉박했다.

(2) 신규 기능
-시장이 크고 서비스 지표 유지 전략이라면 진행
-시장이 작고, 서비스 지표 유지 전략이라면 진행 X

신규 기능은 기존의 지표가 있기에, 지표 성장률 추이를 예상해보면 쉽게 결정할 수 있다. 자연적인 성장은 목표 지표에서 제외해야 한다. 성장률 추이를 봤을 때 정체기라고 판단되면, 신규 기능이 정체를 탈출할 만큼 혁신적인가도 검토해야 한다.

만약 "우린 모두 월급쟁이니깐, 결정에 대한 책임이 있다면 결정할 수 없어요" 라는 상황이라면, 린캔버스(Lean Canvas)를 활용해보는 것도 방법이다. 리더가 린캔버스를 채우고, 채워진 텍스트에 타당성이 충분한 프로젝트는 성공 가능성이 높은 프로젝트다. (하지만 아쉽게도, 그 린캔버스에 텍스트를 채우고 타당성을 따질 때 영혼이 탈탈 털리는 기획자들을 종종 보았다.) 사실 나도 이 린캔버스의 각 항목을 제대로 넣어본 기억이 없다. 그런 리더도 만나보지 못했다. 그만큼 이 린캔버스를 완벽하게 설계하는건 어려운것 같다.

“솔루션이 너무 복잡해서, 고객에게 가치 제안의 커뮤니케이션이 너무 어려울 구조예요"라고 말하면, “사업을 꼭 그렇게 철저하게 따져서만 하는게 아니다. 직감이라는게 있다" 라는 대답을 듣기도 했다.


4단계 커뮤니케이션을 위한 UI초안 리뷰
배경도/다이어그램/Wire-frame/ERD... 스킬이 허락되는 것들을 모두 이용하여 개발/디자인에게 0.9 이하 버전으로 Kick-Off 리뷰를 진행한다. 이때 반드시 서비스 또는 기능의 콘셉트 메시지가 전달되어야 한다. 그렇지 않으면, 프로젝트 진행 중에 외길 작업을 하고 있는 멤버를 발견하게 된다. 리뷰 후 의견을 받아보는 것도 잊지 않아야 한다.


5단계 오픈 전략 수립
자동차나 스마트폰은, 새 모델을 발표할 때 쇼케이스 행사를 가진다. 아이돌 그룹도 쇼케이스 행사라는 것을 한다. “나 나왔어요!”를 많은 사람들에게 멋지게 알리기 위해 하는 행사다. 온라인 서비스도 마찬가지다. 오픈하고 알리지 않으면, 오픈 한 달 만에 종료 프로세스를 밟아야 할 수도 있다. 오픈 전부터 오픈 후 마케팅을 고민하는 것이 오픈 전략 수립이라고 볼 수 있다. 

(1) SEED 유저 모객
유저 바이럴만으로 오가닉 성장을 보여주는 서비스들 역시, SEED유저를 모으는 계획이 있었을 것이다. 가장 쉬운 모객 방법은 CBT다. 데스크톱 온라인 서비스는, 프로덕트의 완벽함을 위해 CBT를 진행하였다. 설치/삭제가 편리한 모바일 온라인 서비스는 기대감을 심어주고 SEED 유저를 모으기 위해 CBT를 진행하는 게 일반적이다. 또는 셀럽을 활용하기도 한다. 또는 한 명 한 명 영입한다.

(2) 오픈 프로모션
소문난 잔치에 먹을 게 없다는 말도 있지만, 일단 “소문난 잔치”가 되어야 한다. 이벤트에 집중하는데, 이벤트보다는 어떤 플랫폼/어떤 타깃에 알려야 할지에 대해 집중해야 한다. 잠재고객을 발굴해야 한다. 단발성 오픈 프로모션이 아니라, 최소 6개월짜리 프로모션 계획을 세워두는 게 후회 없는 프로모션을 했다고 볼 수 있다. 

물론 돈 많으면 무슨 걱정인가. 그리고 예외사항이 있다. 기존에 큰 트래픽을 발생하는 서비스를 보유한 기업은 마케팅은 나중에 고민한다. 기존 트래픽을 신규 서비스 또는 기능으로 전이하는 것이 쉽기 때문이다.


6단계 UI기획안 1.0과 오픈 전략 리뷰
오픈 전략 배포 공유 (프로모션 페이지가 필요한 경우에는 개발, 디자인 리소스 필요)


7단계 디자인 시안 검토
디자인 시안이 나오면, 기획자는 화면 단위의 목표가 달성될 수 있는지를 가장 먼저 체크한다. 그리고 화면 단위로 UI기획안과 크로스 체크를 상세하게 진행한다.


8단계 QA 시트 작성
QA(quality assurance) 시트를 작성한다. 본래의 QA는 서비스 기획 단계부터, 출시 후 고객 의견까지 반영하는 걸 뜻하지만, 일반적으로는 QA기획자가 아닌 서비스 기획자는 테스트 매니저 수준의 역할을 하게 된다. 작성된 테스트 시트는 디자인/개발에 공유하고 피드백을 요청한다. QA는 전문적인 영역으로 품질경영기사라는 자격증도 있다.


9단계 테스트 진행
중요도에 따른 디바이스별 테스트 리소스 분배한다. 그리고 발견된 버그 이슈를 등록하고 담당자 어싸인을 요청한다.


10단계 서비스 배포와 롤백 시나리오 협의
서비스 배포일 협의한다. 되도록이면 금요일은 제외한다. 배포 후 사이드 이펙트로 인한 장애가 발생할 수 있다. 배포 즉시 발견되는 장애도 있지만, 몇 시간이 흐른 후 장애가 발생하기도 한다. 주말에 장애가 발생되면, 빠른 대응을 할 수 없기에 금요일엔 배포를 하지 않는 것을 권장한다. 

배포 후 이상 증상 발견 시 롤백 시나리오를 협의하고 미리 약속해놓는다.


11단계 오픈 후 모니터링 및 버그 픽스

12단계 오픈 후 일정 기간 후 성과보고(정성/정량적) 평가 및 향후 운영 방향 제시
일정 기간이 지나면, 성과보고를 한다. 이때 유의할 점은 본인이 한 기획이라고 긍정적인 통계만 내는 꼴불견 짓은 하지 말자. 실패인 부분은 실패라고 말하자. 

모든 기획 프로세스가 꼭 이렇지는 않다. 환경에 맞게 단계를 생략하고, 업무의 범위를 줄일 수도 있다.

반응형
댓글