기획문서 잔혹사

초기 스타트업에서 기획문서를 셋업하는 일은 매우 중요한 일이었다.
개발팀과 기획팀이 모두 만족할 수 있는 커뮤니케이션 방식을 만들기까지 몇번의 시행착오가 있었다.
이는 그 과정을 기록하기 위한 포스팅.

시행착오1. 문서 포맷이 중요한지 몰랐음.

스타트업을 세팅할 때, 제품 기획서를 어떤 방식으로 정리해야 할지 고민했었다. 먼저 팀원들과 함께 검색을 시작했다.

구글에 검색해보면 서비스 기획서나 화면 설계서와 같은 문서를 작성하는 대중적인 포맷을 찾을 수 있다. 팀원들이 모두 활용할 수 있어 논의 없이 해당 방식으로 작업을 진행했다. 화면 우측에 있는 디스크립션 란을 확보해 최대한 많은 내용을 담으려고 했지만, 시행착오가 있었다.

화면을 기준으로 디스크립션을 작성하면 서비스 기획을 MICE하게 작성할 수 없다.
여기서 MICE는 기획문서를 작성하는 가장 이상적인 분류 방식이다. 부분의 합이 전체를 대변해야 하는 문서 관리 기준이다. 기획서에 중복된 내용이 작성되면 업데이트 누락이 생기고, 기획자와 개발자 간 커뮤니케이션 미스가 발생할 수 있다.

화면 설계서는 화면을 기준으로 디스크립션을 작성하기 때문에 동일 작동 원리에 대한 서비스 기획 내용이 중복으로 작성될 수밖에 없다. 화면 설계서를 기반으로 서비스 정책서를 작성하는 것은 좋은 대안이 되지 않는다.

그렇다면 기획문서를 어떤 기준으로 정리해야 할까?

API 작성 기준으로 작성하는 것으로 일단 진행했다. 모든 기능은 메소드 기준으로 분류되었다. 등록, 수정, 삭제, 조회의 4가지 메소드는 기능을 구현하는 최소한의 단위이고 중복되지 않는다고 판단했다. 또한 개발자 분들이 문서를 찾고 확인하기에 용이하다고 판단했다.

최소 단위를 메소드 단위로 나누어 작성하고, 노션의 롤업 기능을 활용하여 기획문서에 연결했다. 기획문서는 각각의 API와 연결되어 개발자와 기획자가 소통하기 쉬운 환경이 되었고, 특정 메소드에 맞는 정책 내용이 중복되지 않게 정리되어 개발 환경이 개선되었다는 평가를 받았다.

피그마로 정리된 기획문서의 목록

기획문서는 개발자가 작성한 API와 연결되어 있다.

API 상세를 클릭하면 세부 파라미터 값과 정리내용들을 확인할 수 있다.

시행착오2. 기획문서 길면 개발자분들 안봄.

시간이 지나면서, 기획서에 디테일한 내용을 모두 담는 것이 좋다고 생각했던 때가 있었다. 하지만 기획 내용은 항상 업데이트 되고, 변경 이력이 많을수록 커뮤니케이션이 어려워진다. 그래서 디테일하게 문서를 작성하려고 애를 쓴 적이 있었다.

그러나 그 과정에서 한 가지 시행착오가 있었다.
기획서가 길게 작성되면 쓰는 사람도 보는 사람도 힘들어진다.
제가 글이 길면 잘 안 읽는데, 길게 쓰면 개발자분들도 알기 힘들겠다고 생각했던 것이 문제였다. 길면 안 보이는 법이니까..

그래서 최소한의 내용으로 빠짐없이 기입할 수 있는 방법을 찾아보았다. 파이썬 및 스크립트 공부를 하면서 느낀 점은 결국 코드든 사용자 스토리든 모두 시퀀스를 기반으로 설계된다는 점이었다. '상황 - 판단 - 결과' 기본적인 시퀀스로 구동된다고 생각하니, 기획팀에서 녹이고자 하는 모든 서비스 정책과 비지니스 방향이 플로우차트 속에서 설명될 수 있었다.

그래서 우리 회사의 제품 기획서 방식은 플로우차트와 화면설계서를 기반으로 한 기획 형태로 정의 되었다. 이는 메소드 기준으로 작성되었고 개발자분들이 쉽게 접근할 수 있도록 구성하여, 개발하기 편한 환경에 도움이 되었다는 평가를 받았다.

시행착오3. 기획문서는 수정할 수 밖에 없음.

자주 수정해야 하는 문서라면, 작성 방법만큼 히스토리 아카이빙이 중요하다. 전통적인 양식의 화면 설계서 문서들은 한 단어만 변경해도 여러 페이지를 일일이 찾아 수정하거나 바꾸어 주어야 란다.
해당 이슈를 해결하기 위해 기획 문서 기술적으로는 MICE 방식의 기술법이 중요하지만, 툴적으로는 한 개의 수정사항에 영향을 받는 브랜치 기획 문서들이 수정과 동시에 누락 없이 함께 수정될 수 있는 환경이 조성되어야 한다.
이런 문제를 해결하기 위해 피그마의 메인 컴포넌트 기능을 활용하여 도입하였으며, 회사 자체적으로 피그마 기획 문서 정리 컨벤션을 만들었다.

메인 컴포넌트로 관리되고 있는 피그마 파일들은 수정사항이 발생할 때마다 영향받는 모든 브랜치에서 함께 수정이 되며
이는 기획팀의 퍼포먼스와 직결되었다.

아울러 피그마의 히스토리 세이브 기능을 활용하여 문서 버전을 관리했다. 이는 매우 효율적이었다. 해당 히스토리를 쉽고 빠르게 저장할 수 있었고, 세이브 링크를 통해 언제든 과거 문서로 이동할 수 있었다. 툴을 적절히 활용하는 것만으로 문서의 신뢰도가 높아지고 문서 기반으로 업무를 볼 수 있는 환경이 조성되었다.

피그마의 문서는 간단한 요약과 함께 링크로 전달되어 관리되었다.

현재 우리 조직의 기획문서는 개발팀과 기획팀 함께 보고 수정하는 구조로 정착되었다. 앞으로도 갈 길이 멀지만 같은 문서를 보고 함께 편집하는 기조가 생긴 것 같아 나름 만족스럽다. 짧은 주기로 제품이 애자일되는 조직 문화를 갖추기 위해선 효율적이고 효과적인 문서관리 체계가 필요한데, 앞으로도 이 부분에 더욱 연구를 많이 해서 좋은 애자일 문화를 만드는 데 일조하고 싶다.