서비스기획 프로세스 AtoZ - 프론트
저는 이렇게 기획합니다.
오랜만에 서비스기획 실무 관련 글을 작성한다.
보통 서비스기획 직무로 회사에 취업을 하더라도
완전히 새로운 서비스를 A부터 Z까지 기획하게 되는 경우는 잘 없다.
이미 운영되고 있는 서비스를 고도화해 나가거나
이미 어느 정도 틀이 잡히고 기획이 진행된 프로젝트에 합류하게 되는 경우가 일반적이다.
그런 관계로 나도 완전히 제로 베이스 상태에서
A부터 Z까지 서비스를 설계해 본 경험은 없었는데 이번 회사에서 처음으로 경험하고 있다.
서비스기획 관련 글은 차고 넘치지만 뭔가 실무에 밀접하게
프로세스를 얘기해 주는 글은 많지 않은 느낌이라서
현재 내가 경험하고 있는 서비스기획의 프로세스 AtoZ를 공유하고자 한다.
모든 업무가 그렇겠지만 it 기획 업무 또한 실무자마다 지향하는 스타일은 모두 다르니
나의 케이스는 참고용으로만 보시면 된다.
대략적인 프로세스는 아래와 같다.
① 대략적인 요구사항명세서 작성 / 동시에 용어 정의
② 대략적인 사이트맵 작성 (프론트/어드민)
③ 대략적인 프론트 와이어프레임 작성 (그리면서 사이트맵 적절히 수정)
④ 관련 솔루션 탐색, 개발 가능 여부 검토
⑤ 프론트 화면설계서 작성
⑥ 어드민 와이어프레임 작성
⑦ 어드민 사용자 리뷰 진행
⑧ 어드민 화면설계서 작성
⑨ Information Architecture
⑩ 운영정책 설계
⑪ CS 정책 협의
엄청 체계적이고 잘 갖추어진 회사라면 모르겠지만... (일단 나는 경험해 본 적 없음 ㅎ)
보통의 it 회사에서 완벽한 요구사항이 깔끔하게 정리되어 개발팀에 전달되는 케이스는 드물다. 잘 없다;
사업팀 회의에 불려 가서 이런저런 허무맹랑한 뜬 구름 잡는 소리를 몇 달 듣고
되네 안되네 큰 소리가 몇 번 오고 가고...
그러다 보면 대강 윤곽이 좀 잡힌다 ㅎ
대충 잡아놓은 윤곽을 깡깡쳐가며 MVP 버전을 협의하고 지지고 볶고 하다 보면
MVP 버전 요구사항명세서를 겨우겨우 작성할 수 있다.
(여기서 또 이것저것 추가해 달라고 하는데 안 된다고 싸우는 거 몇 번 더 해야 됨)
참고로 농담 안 하고 성격 좋으면 기획자 못 한다고 생각한다 싸워 이겨야 되는 상대가 너무 많음;;
① 대략적인 요구사항명세서 작성 / 동시에 용어 정의
자 사업팀은 사업팀의 일을 했으니 이제 우리가 서비스기획을 시작할 단계다.
위에 적어둔 것처럼 대략적인 요구사항명세서를 작성한다.
어차피 사업팀이랑 협의하면서 수정될 거고 이 버전으로 개발자한테 넘길 거 아니니까 완벽하게 적으려고 욕심부릴 필요 없다.
대략적인 요구사항을 작성하고 문서를 기반으로 사업팀과 마지막으로 협의한다.
마지막이어야 된다 여기서 또 말려들면 기획이고 개발이고 몇 달 뒤로 밀리는 거다.
요구사항을 정리하면서 자주 사용하는 생소한 용어들은 함께 정의해 주는 것이 좋다.
이 타이밍에 정의해야 뒤에 작성할 모든 문서들에 통일성이 생긴다.
② 대략적인 사이트맵 작성 (프론트/어드민)
이제 정의한 요구사항을 기반으로 서비스를 어떻게 만들어나갈지에 대한 그림을 그려야 한다
위에 적어둔 것처럼 이 또한 대략적인 사이드맵이어야 한다.
어차피 디테일 잡다 보면 수정 들어가야 하니까 이 단계에서 완벽을 추구하지 말자.
프론트 먼저 그리고 어드민도 대강 윤곽을 잡아준다.
"대략적"이라는 워딩에 집중
③ 대략적인 프론트 와이어프레임 작성 (그리면서 사이트맵 적절히 수정)
그려둔 프론트 사이트맵을 기반으로 와이어프레임을 그려나간다.
여기도 대략적인 이라고 적혀있다.
대충 잡자 어차피 수정된다.
모든 화면을 다 잡을 필요 없다.
주요 기능 위주로 화면을 잡는다.
주요 기능이라 하면 돈 되는 기능이라고 보면 된다.
로그인, 메뉴, 문의 이런 거 다 빼고 돈 되는 기능만 일단 잡는다.
잡으면서 사이트맵에 수정이 필요하면 적절히 수정해 준다.
④ 관련 솔루션 탐색, 개발 가능 여부 검토
이제 내가 그려둔 화면을 실제로 구현하는 게 가능한가를 확인해 본다.
아마 인하우스고 개발자 있다면 1번 이전의 사업팀과의 회의에서부터 개발자가 참석했을 것이고
나와 같이 사업팀과 싸워줬을 것이니 대략적인 개발 가능 여부는 검토됐을 것이다.
그게 아니라면 1번 이전에 미리 어느 정도 검토해야 한다.
나는 불행히도 이번 회사에 같이 발맞출 개발자가 없었으나
짬 먹으니 대충 될지 말지는 감이 잡혀서 일단 화면 그리고 솔루션을 탐색했다.
내가 쓰고 싶은 기능 비슷한 단어를 열심히 구글링 하면 된다.
보통 내가 하고 싶은 건 남들도 다 하고 싶기 때문에 솔루션으로 거의 다 나와있다고 보면 된다.
솔루션을 찾았으면 개발 문서를 확인한다.
(API나 SDK 문서가 오픈되어 있는 경우도 있고 제휴담당자와 계약 얘기 좀 진행하면 주는 경우도 있다.)
개발문서를 보면 내가 그린 화면이 실제로 구현 가능한지 확인할 수 있다.
개발문서 처음 보면 너무 어려워 보일 수 있는데 대강
Request랑 Response의 Parameter만 확인하면 된다.
다른 어려운 건 안 봐도 됨 내가 개발할 것도 아니고..
(뭐만 하면 개발자한테 쪼르르 달려가고 싶지 않다면 이 정도는 볼 수 있는 게 좋다)
⑤ 프론트 화면설계서 작성
대략적인 사이트맵도 나왔고 주요 기능 와이어프레임도 나왔고 실제로 개발 가능한지도 확인했다.
더 이상 수정될 사항이 없다는 전재라면 이제 화면설계서를 작성하면 된다.
와이어프레임이 나와있는 주요 기능의 화면설계서를 작성하고
추가적인 로그인/회원가입/메뉴 등의 화면들도 와이어프레임을 그린 후 화면설계서를 작성한다.
화면설계서의 형식과 틀은 중요하지 않다.
디자이너와 개발자가 잘 알아볼 수 있고 나한테 찾아와서 물어볼 일이 많지 않으면 된다.
화면설계서가 완벽해서 관계자들이 나를 찾아오지 않으면 좋겠지만 나도 사람이다 보니 모든 걸 완벽하게 챙길 수는 없다.
빵꾸냈다고 창피하게 생각하지 말고 사고 나지 않게 사전에 필터링해주는 좋은 동료라고 생각하자
따로 적지는 않았으나 모든 과정에서 머릿속에 IA는 그려지고 있어야 한다.
수정사항이 생길 확률이 높기 때문에 IA를 미리 그리지 않은 것이지 그리지 않아도 되는 것이 아니다.
머릿속에서 어떻게 데이터가 생성되고 호출되는지 다 그려가면서 작업해야 한다.
우리는 이제 주니어 기획자가 아니니까
데이터의 흐름 정도는 파악하고 있다고 믿겠다.
중간에 자르는 거 안 좋아하는데 너무 길다...
쓰는 나도 지루하고 보는 사람도 지루하겠지...
일단 내가 너무 지루해서 어드민 얘기는 다음에 해야겠다...
