스토리텔링 문법을 개발하라
도메인 스토리텔링 응용
<실전 도메인 스토리텔링 첫 시도>편을 쓴지 6개월 가량 지났다. 의도적으로 다음 단계로 나아가기 위해 시리즈 제목도 도메인 스토리텔링 응용으로 바꾼다.
스토리텔링 문법을 개발하라
동료의 결과물을 볼 때마다 나는 반복적으로 문법을 개발해야 한다는 충동에 휩싸였다. 그게 옳은 일인지는 해봐야 알 수 있다. 한편, 모바일 세상의 UX에 진심이 나는 키오스크로 커피를 주문하다가 받은 인사이트를 도메인 스토리텔링으로 포착하고, 자산화 하기 위해 다음과 같은 두레이 업무를 생성했다.
그리고 어제 스토리텔러로 진화 중인 동료와 만나 맥락을 전했다. 아마 그 후속 경험이 이 시리즈가 계속 앞으로 나아가게 도와줄 것이라 믿는다.
비대면 소통이 만드는 극한의 생산성
한편 나는 어제 벌어진 회사의 회의에서 청자의 입장에 놓였다. 새로 만들어진 (소프트웨어) 제품의 기능과 쓰임새에 대한 구체적인 이야기가 오고 갔다. 화면을 처음 본 나로써는 따라가는 일도 쉽지 않았다. 문제는 나와 같이 청자로 놓인 이해관계자가 내용을 이해하지 못하는 듯 보였다. 나는 감각적으로 해야 할 일을 깨달았다. 그 자리에 있지 않은 동료에게 해당 논의의 근거가 되는 두레이 업무에 댓글로 이렇게 요청했다.
나는 이럴 때 우리가 두레이 프로젝트 저장소에 구축한 엄청난 생산성의 기반을 느낀다. 회의에 모두가 참석하지 않아도 우리는 협업할 수 있다. 사전에 그 회의의 존재도 모르는 동료가 우리를 도울 수 있다. 그저 각자의 위치에서 열심히 일했으면 그걸로 족하다. 단 하나의 제약조건은 평소에 자신의 일을 기록으로 남기란 점이다.
릴리즈와 피드백
아래는 바로 생산된 동료의 작품이다.
놀랍게도 (어쩌면 당연하게도) 스토리텔러와 영업책임자 사이에 비대면 소통이 이어지는 모습을 관찰할 수 있다.
내가 현장에서 포착한 Needs의 단기적인 부분은 금새 충족되었다.
지식을 널리 퍼뜨리기
하지만, 개발자가 PM(Product Manager)가 되는 경우 갖는 리스크가 남아 있다. 스타트업에서 이런 일은 바람직한 일이다. 스타트업에서는 시간이 중요하고, 릴리즈 회수가 중요하고 될놈인지 판단하는 일이 무엇보다 중요하다. 그래서 기획을 누가하느냐 따위는 굉장히 부차적인 문제다. 개발자가 기능을 정의해도 문제가 없다. 문제는 모든 지식이 그에게 암묵지로 있으면 지식의 유통이 어려워진다. 쉽게 말해 매뉴얼도 그가 만들어야 하고, 설명도 그가 해야 한다. 과거 외산 솔루션 판매 광경을 보면, 영업사원이 항상 개발자를 데려가 설명해야 하는 장면을 볼 수 있었는데 그와 같은 이치다.
출처: 구글 이미지 검색대왕으로 기억하는 우리의 선조 李祹가 훈민정음을 통해 지식을 전파하기 위해 한 일은 글자를 만드는 일이다. 우리도 우리 지식체계 전파를 위해 언어를 개발해야 할 수도 있다. 이는 DDD의 Ubiquitous Language와도 같은 맥락이다.
동료가 그림을 그렸으니 지식을 퍼뜨리는 일은 이제 나에게 주어진 임무다.
지난 도메인 스토리텔링 연구
3. 도메인이 무엇인가요?
14. 도메인 스토리의 적절한 구도
