서비스 기획자가 입사 후 첫 주에 하면 좋은 작업(서비스 정책서,IA,플로우차트)

입사 후 바로 일을 시키는 곳도 간혹 있겠지만 대략 1주일 정도쯤은 서비스 파악할 시간을 준다. 지금까지 경험해본 바 모두 인하우스든 SI든 기존 기획서를 공유해 주거나, 정책서등을 공유해준 경우가 많았다.

그 시간은 다시 돌아오지 않는다. 지루하다 생각 말고 미친 듯이 뜯어먹어야 하는 시간이다. (그래도 1주일은 꽤 길어서 졸기도 많이 졸았다;)
 

1. 정책서 파악 & 서비스이용

인하우스인 경우,
어떤 서비스를 하는 곳인지 대략적으로 알고 있을거라 생각한다.
받은 정책서를 정독하고 어떤 정책을 가지고 어떻게 서비스를 운영하는지 파악해 보자. 무작정 읽는다고 도움이 되진 않는다. 서비스가 있는 경우 직접 서비스를 써보면서 어떤 정책을 가지고 있는지 파악하는 게 더 수월하다.

2. IA 그려보기

이후 어느정도 파악이 되었다면 IA를 그려보는 것도 좋다. 대메뉴, 소메뉴 등 어떻게 구성하고 있는지 직접 적어보는 게 좋다. 이미 IA문서는 있을지도 모르지만 직접 해보는 것과 그냥 보는 것은 천지차이가 난다. 

전체적인 IA

3. 플로우차트 그려보기

IA가 그리기가 끝났다면 대충 어떤 플로우로 서비스가 설계되었는지 알 수 있다. 피그마나 드로우 io 툴을 가지고 회원가입/로그인/메인페이지 등 대메뉴별 플로우차트를 짜보자. 회원 구분이 있는 서비스라면(예: 기업, 개인 등) 각각 계정 생성 or 전달받은 걸로 각자의 플로우가 어떻게 다른지 파악해 보자.(없다면 패스)

플로우차트 상세

플로우차트 전체

4. QA

스타트업의 경우, QA가 되지 않은 경우가 많다. QA라하면 설계된 기능대로 이루어지지 않는 걸 뜻한다. 바빠서 못하는 경우가 많으니 정책서, IA, 플로우 차트를 그려보며 서비스 이용 시 발견된 이슈들을 정리해서 전달해 주는 것도 좋을 것 같다.
 
하지만, 이때 중요한 점은 근거를 찾아야한다. 내 머릿속에서 당연히 이렇게 플로우가 되어야 한다. 는 접근은 잘못된 것이다. 오류 발견 후 회사 정책서&기획서 확인 후에도 틀렸다면 QA로 전달해 보자. (개인적으로 나는 '이게 당연하지'라는 논리로 QA를 전달했다가 내부 사정과 정책으로 인한 것임을 알게 되었다.)

입사 후 1주일간 모든 서비스를 파악하긴 어렵지만, 기본이 되는 것들을 제대로 파악해야 추후 기획 시 온전히 몰두할 수 있게 된다.