도메인 스토리텔링 연구 No. 11
<개발자와 현장 사람들의 거리를 좁혀라>편에 기술한대로 사람들의 거리를 좁혀 도메인 규칙을 정의하는 사이에 우리의 도메인 스토리텔러를 차이를 벌렸다. 대상이 무엇이건간에 개발자(developer)는 틈만 나면 끈임없이 만들어내고 다듬는 성질을 갖고 있다. :)
그런 성향을 잘 활용하면 장인정신으로 평가받을 수 있다. 하지만, 종종 혼자 고민할 수 있는 수준의 결과물을 다수와 소통할 때 여과없이 내놓으면 맥락없는 기술적 대화가 되거나 연설같은 대화가 만들어진다. 나는 무의식적으로 그런 행동을 하는 동료를 지적하는 대신에 그림을 화면에 띄우고 세 개의 덩어리로 나눴다. 그래서 오늘 함께 이야기 할 부분을 제한했다.
그랬더니 동석했던 기획자가 그건 다른 그림으로 있다고 두레이 업무 번호를 알려주셨다.
개발자(스토리텔러)는 자기의 최신 버전으로 이야기하고 싶은 욕망이 있겠으나 구체적인 사항이 업데이트가 덜 되었어도 주제의 범위와 드러맞는 그림이 대화에는 훨씬 유리하다. 이 그림으로 우리는 논의를 시작했다.
중요한 것에 대한 다양한 기준이 나왔다. 대략 이런 생각들이 나온다.
기획자가 기능적으로 중요하게 여기고 있는 것
운영자가 최근 컴플레인을 자주 문제
작업자 각자가 최근에 주목하는 문제
나는 (경험에 따른) 직관에 의해 우리가 시도하는 변화를 대변하면서 서비스의 뼈대에 해당하는 부분 중에 가장 작은 개발 범위를 설정하려고 그림을 그렸다. 그리고 참여자의 의견을 들어가며 수렴하고 동의를 얻었다.
나는 이런 방법을 종심타격(縱深打擊)이라고 부른다. 2004년 (지금은 고인이 된 컨설턴트) 선배에게 배운 군사용어를 내식대로 구체화한 방법이다. 문제의 실마리를 풀 때, 모든 것을 고려하는 대신에 가장 중요한 부분에 총력을 다해 집중하는 것이다.
뜻이 옳으면 서로 다른 배경을 갖고 있어도 조금은 다른 표현을 쓰더라도 의미가 전달되기 마련이다. 내가 저 그림을 그리고 사람들의 질문에 맞춰 부연 설명을 그림에 추가하여 의도가 전달되자 현장에서 벌어진 일을 재현해서 설명하는 참여자가 생겼다. 그리고 우리의 기록을 보고 두레이로 제보(?)하는 열성적이고 스마트한 동료도 있었다. 데이터로 우리 견해를 지지했다.
나는 이때 느낀 필요성을 도메인에 어울리는 이름으로 포착하여 재빨리 스토리 이름을 만들었다. (두레이 업무로 등록) 일부러 네 글자씩 라임도 맞췄다. :)
업무 이름에 비즈니스(UX관점) 효과가 드러났다. 비전(vision)을 문구에 담을 수도 있다니~
3. 도메인이 무엇인가요?