[Part 1] 기획편: 인하우스/에이전시로 나눴다가 분류를 갈아엎었다
결론부터
- 사람이 막히는 곳은 쓰는 것보다 시작하는 것이다. 그래서 문서고는 편집기가 아니라 양식을 제품으로 삼았다.
- 분류는 보관 기준이 아니라 탐색 기준이어야 한다. 처음에 이걸 틀려서 한 번 갈아엎었다.
- "만들지 않을 것" 목록을 먼저 정해 두니 기능 요청을 판단하는 속도가 빨라졌다.
문제를 좁힌 세 질문
기획 문서를 매번 처음부터 쓰게 되는 이유를 세 질문으로 좁혔다.
- 사람이 막히는 지점은? 쓰는 것보다 시작하는 것이다. 빈 화면 앞에서 목차부터 고민한다.
- 결과물은 어디로 가나? 화면이 아니라 파일로 간다. 그것도 대부분 한글 파일로.
- 그래서 핵심은? 양식의 질과 출력의 질. 편집 경험은 그다음이다.
이 세 답이 이후 결정의 기준이 됐다.
분류를 갈아엎었다
처음 분류: 인하우스 / 에이전시
처음에는 양식을 인하우스와 에이전시로 나눴다. 내 폴더가 그렇게 나뉘어 있어서 그대로 옮겼다.
그런데 실제로 받은 피드백 한 줄에 뒤집혔다.
기획자 입장에서 인하우스랑 에이전시 이런 식으로 용어를 선택하는 게 맞나?
맞지 않았다. 문서를 찾을 때 떠오르는 건 "우리가 자사냐 외주냐"가 아니라 "지금 어느 단계냐"다.
폴더는 내가 정리한 결과고, 분류는 남이 찾는 길이다. 내 보관 방식을 그대로 옮기면 남에게는 길이 되지 않는다.
바꾼 분류: 단계 8개
작업 단계를 따라 8개로 나눴다.
- 문제 발견
- 요구 정의
- 설계
- 기술 설계
- 개발·진행 관리
- 검증·출시
- 운영·개선
- 제안·수주
자사/외주 구분은 없애지 않고 태그로 남겼다. 분류는 찾는 길이고, 태그는 문서의 성격이다. 둘을 같은 축에 두면 길이 막힌다.
열흘 뒤 한 번 더
처음 바꾼 분류에서는 "설계" 안에 화면설계서와 API 명세서가 같이 있었다. 그런데 이 둘은 찾는 사람이 다르다. 기획자가 찾는 문서와 개발자가 받는 문서를 분리해서 "기술 설계"를 새로 만들었다.
같은 때에 한 양식에 뭉쳐 있던 것들도 쪼갰다.
- 역할 정의 / 권한 매트릭스
- 리서치 계획 / 리서치 보고서
- 운영 매뉴얼 / CS 매뉴얼
한 문서에 두 목적이 들어 있으면 둘 다 얇아진다.
만들지 않기로 한 것
| 안 만든 것 | 이유 |
|---|---|
| 범용 문서 편집기 | 노션, 구글 독스와 경쟁하면 진다. 양식이 정한 칸을 채우는 것까지만 한다 |
| 사용자가 올리는 양식 | 품질이 들쭉날쭉해지고 저작권 분쟁이 생긴다 |
| 실시간 공동 편집(커서 공유) | 기획 문서는 한 사람이 쓰고 여럿이 보는 쪽이다. 대신 저장 충돌만 제대로 다룬다 |
| 댓글·승인 워크플로 | 결재는 이미 회사 시스템에 있다. 문서고는 거기 올릴 파일을 만드는 곳이다 |
| 모바일 편집 | A4 지면을 휴대폰에서 채우는 사람은 없다 |
이 목록이 있으니 기능 요청을 판단하기가 쉬웠다. "그건 편집기 영역이라 안 한다"로 끝난다.
양식이 제품이다
코드에서 가장 큰 부분이 양식 스키마다. 가장 오래 만진 곳도 여기다.
모든 양식에 공통으로 넣은 것
- 목차: 절이 3개 이상일 때만 넣는다. 본문보다 목차가 길면 안 넣느니만 못하다.
- 안내 문구: 절마다 무엇을 쓰는 자리인지 적었다.
- 변경 이력, 검토, 승인란: 모든 양식에서 같은 모양으로 맞췄다.
- 버전: 표제부 맨 앞에 둔다.
이름은 현장 말로
양식 이름을 현장에서 부르는 말로 바꿨다. 예를 들어 "유저 리서치 결과 보고서"는 "리서치 보고서"가 됐다. 목록에서 찾을 때 떠오르는 이름이어야 한다. 정식 명칭은 문서 안 표제부에 남겼다.
양식의 출처
40종은 이렇게 모였다.
- 직접 쓴 것 19종
- 리빌드 전 프로토타입에서 가져온 것 9종
- 새로 쓴 것 12종
구매한 상용 템플릿의 문안은 싣지 않았다. 개인이 보관하고 활용하는 범위를 넘어 공개 서비스로 운영하면 판매자 정책에 걸린다. 항목 구성만 참고하고 문안은 새로 썼다.
다음 편에서는 "문서는 값만 갖는다"는 데이터 모델과, 양식이 28종에서 40종으로 늘어나는 사이에도 기존 문서가 깨지지 않은 이유를 정리한다.