"기획자가 기획서를 작성해 벽 너머로 디자이너에게 던져주면 디자이너는 기획서에 따라 디자인한 뒤 벽 너머로 프로그래머에게 던진다. 프로그래머는 문서에 따라 코드를 작성해 기획자에게 던진다. 벽 너머로. 벽이 사라지면 어떻게 될까?" - 유저스토리

— 박태웅 (@parkto) 1월 6, 2012

개발 문서를 만드는 기준은 '문서를 필요로 하는 사람과 대화할 수 있는 정도' 가 적당한 것 같다. 그 이상 문서를 자세하게 쓰거나, 많은 정보를 담으려 노력하는 것은 overkill 이다.

그러니까 문서화에 들이는 노력 자체는 개발에서 보면 낭비인 셈인데, 회사의 개발 문화가 이 부분을 보충해 줄 수 있다면 비용이 적게 들어가는 것이고, 위 트윗 처럼 벽으로 칸막이가 쳐져 있다면 많은 비용을 투입해야 하는 것이다.

어찌됐든 중요한 것은 문서 그 자체가 아니라, 개발이다. 문서는 개발을 진행시키기 위한 도구에 불과하다. 문서에 투자하는 시간은 필요악에 가깝고, 가능하면 낭비를 줄여 적당한 만큼 만드는 것이 좋다.

낭비를 줄이려면 문서를 적당한 abstraction level 로 나눠야 한다. 비지니스 팀과 논의를 하기 위해서는 유저 시나리오나, 비전 문서 정도에서 얘기하는 것이 바람직하고, 개발팀과 이야기할 땐 스펙과 스토리 등이 필요하다. 개발자끼리 자신의 디자인을 논의하기 위해서는 개발 디자인 문서가 좋을 것이다. 개발에 필요한 문서의 레벨은 아래 정도로 나누면 좋은 것 같다.

• 비전
• 유저 시나리오
• 유저 스토리
• 기능 스펙
• 개발/테스팅 디자인

각 단계별로 문서에서 언급할 수 있는 어휘의 레벨도 함께 정해진다. 어휘의 범위를 정하는 것은 중요하다. 그렇게 해서 개발 디테일에 관한 것을 개발팀내의 문제로 분리할 수 있기 때문이다.