도메인 스토리텔링 연구 No. 16
함께 일하다보면 갈등과 걸림돌은 늘 발생한다. 그리고 누군가는 인내심을 갖고 장애물을 하나씩 제거해야 한다. 그 누군가가 사람일 때는 그(혹은 그녀)를 리더라 하고 공동의 믿음일 때는 비전이라 할 수 있다.
<설계서가 아니라 의사소통>에서 다룬 바대로 소통 자체가 훈련되지 않은 사무직(테일러주의 관리 방식에 익숙한 분)의 경우는 문서로 흐름의 단절을 초래할 때가 많다. 소통을 단절할 의도가 아니었는데 보고와 결제를 위해 문서를 만드는 일에 이미 익숙해진 직장인은 너무나 많지 않은가?
보고자료의 첫 페이지는 늘 그렇듯 개요가 담긴다. 보고서 보다는 소통을 하기 위해 형태를 바꾸면 다시 더 잘 쓸 수 있다.
서술어로 쓰인 제목을 협업을 위한 두레이 업무로 만든다. Feature 태그를 붙였는데, 지속적으로 개선할 기능 즉, 버전관리를 할 기능을 부르는 이름으로 쓴다. 그리고 본문은 캡춰를 해서 두레이 본문에 넣었다. 1~2분 투자로 보고서가 아닌 의사소통을 위한 기반이 되었다.
예약 기부를 기획하던 분이 <초점 주변의 이야기까지 스토리 텔링하기> 편에서 공유한 아래의 필자의 회의 진행 메모를 토대로 깔끔한 기획서 내용에 담았다.
아래와 같은 모습니다. 공유와 보고용으로는 좋지만, 일회용으로 쓰이기엔 아깝습니다.
그래서 다시 살려내는 작업을 합니다. 먼저 앞서 설명한 Feature 개념을 설명하고, 두레이 업무로 각각이 링크가 될 것임을 암시합니다. 그리고 릴리즈를 책임지는 담당자가 현재 작성하는 목록에는 Feature 버전이 없는데 앞으로 이를 추가할 것임을 시사합니다. 마지막으로 중요한 서비스의 경우 완료하고 끝내는 것이 아니라 끊임없이 개선하고 시장 상황을 반영해야 함을 설명합니다.
마지막으로 기획자가 작성한 사용자 행동 순서를 보는데 잘 그린 그림이지만 역시 일회용으로 쓰이는 것이 아깝습니다.
역시나 마찬가지로 소통을 도모하고, 비전을 하나로 만들 방법은 예상외로 단순합니다. 관련한 일을 하는 사람이 각자 만든 결과물에서 겹치는 부분을 찾아서 어떻게 하나로 만들어갈까 고민하고 타협하는 과정에서 비전이라는 것이 만들어집니다.
비전이 나온 후에는 서로 약속이 생기고, 그 결과 표준이 만들어질 수 있습니다. 이번에는 Eric Evans의 표현을 빌면 Ubiquitous Language에 해당하는 도메인의 언어를 만드는 일도 시도해보고자 합니다.
3. 도메인이 무엇인가요?
14. 도메인 스토리의 적절한 구도