기획자의 산출물, 어디까지가 적정선인가

 

기획자의 산출물 분량에 대한 고민은 경력이 쌓여도 계속 반복됩니다.
어느 팀에서는 "왜 이렇게 문서가 많냐"는 얘기를 듣고, 어느 팀에서는 "이 정도 정보로 어떻게 개발을 시작하냐"는 얘기를 듣습니다.
저도 같은 스타일로 일했는데 팀에 따라 정반대의 피드백을 받은 경험이 있어서, 이 적정선이라는 게 정말 존재하는지 한번 정리해보고 싶었습니다.

 

기획자로서 불안할 때 저는 문서를 더 많이, 더 자세히 쓰는 쪽으로 대응하는 습관이 있었습니다.
한번은 신규 기능 하나에 화면 정의서, 플로우차트, 예외 케이스 표, 용어 정의집까지 총 40페이지짜리 문서를 만들었는데, 리뷰 회의에서 개발 리드가 "이 중에 실제로 필요한 정보는 5페이지 정도인 것 같다"고 솔직하게 말해줬습니다.
당황스러웠지만 맞는 말이었어요.
문서가 너무 많으면 정작 중요한 정보가 어디 있는지 찾기 어려워지고, 사람들은 결국 문서를 끝까지 읽지 않고 필요할 때마다 저에게 직접 물어보는 쪽을 택합니다.
문서를 많이 쓰는 게 꼼꼼함의 증거가 아니라, 오히려 정보를 우선순위화하지 못했다는 증거일 수 있다는 걸 이때 깨달았습니다.

 

반대로 다른 프로젝트에서는 "빠르게 움직이자"는 팀 분위기에 맞춰 핵심만 짧게 정리한 한 페이지 기획서로 개발을 시작한 적이 있습니다.
그런데 이 경우엔 개발 중간에 예외 케이스에 대한 질문이 하루에도 몇 번씩 들어왔고, 결국 그 질문들에 답하느라 쓴 시간을 합치면 처음부터 문서를 좀 더 자세히 썼을 때와 비슷한 시간이 들었습니다.
문서를 적게 쓰면 초반엔 빨라 보이지만, 그 빈틈을 결국 실시간 커뮤니케이션으로 메우게 되고, 이 커뮤니케이션은 기록으로 남지 않아서 나중에 "이거 왜 이렇게 만들었죠?"라는 질문에 답하기 어려워집니다.
결국 문서가 너무 적어도 어디선가는 그 비용을 치르게 되어 있었어요.

 

여러 번의 시행착오 끝에 저희 팀이 합의한 기준은, "이 정보가 없으면 개발자나 디자이너가 저에게 다시 물어봐야 하는가"였습니다.
다시 물어봐야 하는 정보라면 문서에 반드시 있어야 하고, 안 물어봐도 되는 정보(이미 다들 알고 있는 배경, 굳이 설명 안 해도 되는 UI 컨벤션 등)는 과감하게 뺐습니다.
이 기준을 적용하고 나서 문서 분량이 팀마다, 프로젝트마다 자연스럽게 달라졌어요.
신규 팀원이 많은 프로젝트는 문서가 상대적으로 자세해졌고, 오래 같이 일한 팀끼리 하는 작은 개선 작업은 문서가 짧아졌습니다.
"적정 분량"이라는 절대적인 기준은 없고, 팀의 맥락에 따라 계속 조정해야 하는 거였어요.

 

이 고민을 반복하면서 결국 알게 된 건, 산출물의 분량 자체보다 "이 산출물이 실제로 쓰이고 있는가"가 더 중요한 질문이라는 것이었습니다.
아무리 짧아도 팀이 그 문서를 계속 참조하면서 일한다면 그건 적정한 산출물이고, 아무리 길고 꼼꼼해도 아무도 다시 열어보지 않는다면 그건 낭비된 산출물입니다.

 

저는 이제 문서를 다 쓰고 나면, 2주쯤 뒤에 "이 문서 최근에 열어본 사람?"이라고 슬랙에 물어보는 습관이 생겼어요.
아무도 안 열어봤다고 하면, 그 문서의 어느 부분이 실제로는 불필요했는지를 되짚어봅니다.

기획자의 산출물은 결국 팀이 같은 그림을 보게 만드는 도구이지, 기획자의 성실함을 증명하는 증거물이 아니라는 생각을 요즘 자주 합니다.

 

이 생각을 하게 되기까지 여러 팀을 거치며 정반대의 피드백을 받아본 경험이 크게 작용한 것 같아요.
앞으로도 새로운 팀에 합류할 때마다 이 적정선은 계속 다시 맞춰나가야 할 것 같고, 그게 오히려 기획자라는 역할의 재미있는 부분이라고 생각합니다.