brunch

You can make anything
by writing

C.S.Lewis

by 가을구름 Oct 15. 2021

서비스기획자 탐구일지 - (3) 스토리보드 작성/QA

1년 차 서비스기획자가 자아 확립해가는 이야기

1년 차 서비스기획자가 자아 확립해가는 이야기

믿기지 않지만 이전까지 작성한 부분은 프롤로그 내지 기승전결의 '기'에 해당하는 파트였다. 이번 글에서 작성하는 스토리보드 작성 부분이 '승'에 해당하고 QA를 '결' 정도로 볼 수 있다고 생각한다. '전'에서 서비스기획자가 하는 역할은 보통 개발자, 디자이너와 커뮤니케이션 및 조율이기에 솔직히 큰 파트를 차지하지 않는다. 하지만 스토리보드와 QA는 정말 많은 시간을 소요하고 호흡이 긴 구간이다.


스토리보드 작성


사실 현재 회사에서는 앞의 단계들이 선행되고 나면 바로 PPT에 스토리보드를 작성하지만 다른 회사에서는 피그마 등 툴을 이용해 와이어프레임을 작성하고 시작하기도 한다. 툴을 이용해서 와이어프레임도 한 번 작성해보고 싶지만 추후 직접 다룬 이후 작성할 수 있기를 바란다. 스토리보드는 쉽게 말해서 서비스가 화면에 어떻게 나타나고 안의 구성요소들이 어떻게 작동하는지를 설명한다. 스토리보드의 내용 구성은 크게 표지, Document History, IA 및 정책, 화면 설계와 Description으로 이루어져 있다. 


표지


먼저 표지는 단순하게 제목과 작성 및 수정 일자, 문서 버전 총 3가지만 작성하면 된다. 문서 버전은 공유 전의 경우 ver 0.01로 시작하여 수정할 때마다 버전을 업데이트한다. 기획팀 내부에서 리뷰를 거쳐 수정할 때까지는 계속 버전 0.00으로 수정되지만 개발팀이나 디자인팀과 같은 타 부서에 문서를 공유할 때는 ver. 1.01로 공유한다. 물론 이것도 1.02 이런 식으로 무한 수정 루프에 빠질 수 있지만 최소 기획팀 내에서는 컨펌을 받은 문서만 내보내겠다는 의지...라고 생각한다.


문서 버전 관리

이 Document History 부분에 업데이트된 문서의 내역을 계속해서 기재하면 된다. 문서 버전과 업데이트된 날짜, 어떤 부분이 수정되었는지 간단하게 내용을 기재하고 옆에 작성자명을 쓰면 된다. 그리고 앞서 말했듯이 타 부서에 기획서를 공유할 때 1.01로 새로 버전을 시작한다. 이후 IA와 정책을 작성하면 되는데 이때는 별다른 양식 없이 작성한 내용을 그대로 넣으면 되기 때문에 예시 자료를 첨부하지 않았다.


화면 설계와 디스크립션


화면 설계와 디스크립션 부분은 스토리보드에서 사람들이 가장 많이 참고하는 영역이라고 생각한다. 템플릿은 간단하게 현재 기획서의 version과 작성하는 화면의 페이지 경로(screen path), 메뉴를 적으면 된다. 이후 화면 설계 부분에 서비스의 웹 또는 모바일 화면을 넣고 구현하고자 하는 내용을 그리면 된다. 그리고 화면에서 변경/추가/삭제되는 부분과 기능을 Description에 상세히 기재하면 된다. 처음 스토리보드를 작성할 때 Description을 얼마나 상세히 써야 할 지에 대해 고민을 많이 했었는데 이에 대한 정답은 없으니 다른 사람이 읽고 추가 설명이 필요 없을 정도로만 작성하면 될 거 같다.



QA


QA는 개발이 완료되어 리얼 서버에 배포하기 전, 즉 실사용자들이 서비스를 사용하기 전에 이상 유무를 확인하기 위한 작업이다. QA는 프로젝트의 크기에 따라 생각보다 더 많은 시간과 인력이 투입되는데 놀라운 점은 아무리 꼼꼼히 QA해도 오픈 이후 꼭 추가로 발견되는 에러 부분들이 있다는 것이다. 그래서 리얼 서버 배포 이후에도 QA는 계속 진행된다. 


회사에서 신규 솔루션을 런칭하며 서비스기획팀 전체가 QA에 참여한 경험이 있는데 이때 프로젝트 담당자는 QA 진행 범위를 파악하고 각 범위별로 QA 담당자가 배정한 이후 이에 대한 매뉴얼과 체크리스트를 배부한다. 담당자들은 자신이 맡은 파트에서 어떤 유형의 오류가(what), 어떠한 방식으로(how), 어떤 조건에서(when/where) 발생하는지를 작성하여 개발 담당자에게 전달한다. 전달한 후 개발자가 수정 완료하면 수정된 부분을 다시 QA 하는 식으로 무한 QA루프에 빠지게 된다. 그렇게 기획자는 자신이 맡은 프로젝트가 오픈 전까지 이상이 없는지를 확인한 후 프로젝트를 마무리하거나 운영/보수까지 담당한다. 




1년 차 서비스기획자가 살펴본 기획 프로세스는 여기까지다. 미처 언급하지 못 한 부분이라던가 아직 배우지 않은 내용도 있지만 지금 연차에서 경험하고 수행할 수 있는 업무는 이 정도인 거 같다. 서비스기획팀으로 배정된 지 약 반년이라는 시간이 흐르며 배우고 겪었던 내용을 정리하지 않으면 모래처럼 흩어질 것이라는 위기감을 느꼈다. 훗날 이 글을 다시 봤을 때 엉성하다며 웃을 수도 있지만 이렇게 배운 내용을 정리하며 더 성장하는 기획자로 나아가고 싶다.

작가의 이전글 서비스기획자 탐구일지-(2) 정책/사용자시나리오
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari