기획안 작성 끝! 이때 기획자가 하는 일

*지난 2월에 기획자로서 처음 작성해두었던 글을 공유해본다. 지금은 프로젝트가 4개월차에 접어들었다 :)

기획 문서를 완성하고 나니 예전보다 여유가 생겼다. (지난 글 참고: 링크 ) 그치만 지금이야말로 기획자의 가장 중요한 역량 중 하나인 커뮤니케이션 역량이 드러나는 시기이다. 직접 이커머스 분야의 사이드 프로젝트를 진행하며 배운 점들(TIL)을 토대로, 본격적으로 제품 개발이 이루어지는 시기에 신입 기획자가 하면 좋은 일들을 작성해 보고자 한다.  

개발자, 디자이너들과 제품에 대한 이해 얼라인하기

이 시기에는 개발자와 디자이너의 회의에 참석하면서 적극적으로 기획을 보완하고 그들의 의문을 해소해 주는 일이 정말 중요하다. 화면설계서를 통해 기능개발, 로직적 정책, 기획의도를 담았지만 회의 때 꼭 질문들이 이어지며 기획에도 변경 사항이 생기기 때문이다. 전체적인 일정이 딜레이 되지 않기 위해서, 또 내가 작성한 기획문서에 대한 책임감으로 가능한 한 디자인 회의에 참석하려고 했다. 설명이 미비했던 기획의도나 로직, 기능 구현을 위한 개발적인 부분을 설명하며 프로덕트에 대한 이해에 격차가 발생할 만한 부분을 제거했다. 

특히 내가 맡았던 화면에 유저의 특정 정보 데이터의 수집 유무에 따라서 유저의 사용 흐름이 2갈래로 나뉜 뒤에 다시 또 두 갈래로 나뉘는 복잡한 로직이 있었는데, 회의에서 디자이너분들에게 설명을 드렸음에도 불구하고 재질문이 들어왔다. 메이커들이 기획서를 이해하는 데 무리가 있다는 뜻이었다! 이때 로직이 잘 이해되게끔 케이스에 따른 처리를 도식화해서 피그마에 그려두었더니 질문이 더이상 들어오지 않았다. 이런 복잡한 로직이 있을 때는 도식화 같은 작업을 통해서 기획문서를 더 클리어하게 만들면 좋다. 

한편, 개인적으로는 경험이 부족한 신입 기획자로서 전체 디비전이 참여하는 전체 회의에서 논의될 안건들에 대한 의견을 미리 정리하며 회의를 쉽게 준비할 수 있는 기회이기도 했다.  

자식(?) 같은 내 기획이지만.. 기획 변경, 디벨롭하기

개발자들이 DB작업을 하고 디자이너들이 와이어프레임 작업을 하다 보면, 분명 제기되는 이슈를 고려해서 수정이나 재기획하는 이 있다. 내 경우에는 디자이너분들의 의견에 따라 내가 공들여 기획한 기능이 replace되는 일이 있었는데, 기존 기획이 작은 화면에 너무 많은 정보를 담고 있어 오히려 가독성이 떨어질 것 같다는 의견이었다. 제품 컨셉을 정할 때부터 굉장히 공들여서 기획한 기능이었기 때문에 마음이 아팠지만 유저들이 이 화면이 진입할 때의 목적과 프로덕트의 특수성을 고려하면 최선의 기획은 아니었다. 결국 해당 기능을 replace하며 '서비스 기획자에게 내가 만든 앱, 웹은 자식 같이 느껴진다'던 도그냥님의 말이 확 떠올랐다. 그치만 그다음에 이어지는 말은, '자식처럼 느껴진다고 해서 고집을 부리면 안 된다' 였다. 이 말은 이후에도 프로덕트 메이킹 과정 중에 종종 기능을 수정해야 하는 순간에 불쑥 찾아와 더 나은 기획을 고민하게끔 했다. 

 

변경된 화면설계서 업데이트하기

한편, 변경되는 로직정책이나 기능정의에 맞추어서 제때 화면설계서를 수정해줘야 한다. 사이드 프로젝트는 보통 전체회의를 일주일에 한 번 정도 진행하기 때문에 그 전까지는 서로 변경 사항이 잘 공유되지 않을 수 있다. 우리 역시 기획-디자인 회의를 하면서 제품 화면이나 마이페이지의 작은 기능부터 심지어 프로세스의 순서가 바뀌는 일도 있었다. 이때 자잘한 기능들이 바뀌는 일은 흔하지만 프로세스가 바뀌는 일은 개발자들 입장에서 큰일이므로 되도록 발생하지 않는 게 좋다.(물론 디자인에도!) 만일 발생한다면 빨리 알려줘야 한다. 이때 슬랙 같은 메신저에 남겨줘서 바로 팔로우업할 수 있도록 하거나 화면설계서에 별도로 버전과 변경 사항을 기록하는 등 히스토리를 관리해야 한다.