기획자와 개발자의 고질적인 싸움의 원... | 매거진에 참여하세요

이 글은 Jeff Patton의 User Story Mapping: Discover the Whole Story, Build the Right Product 내용을 번역, 의역 및 재구성한 글입니다.

최고의 제품은 문제를 해결하고자 하는 제품 조직이 공동의 이해를 통해 문제를 겪는 고객을 위해 힘쓸 때 가능하다.
The best solutions come from collaboration between the people with the problems to solve and the people who can solve them.

분업화가 뚜렷하게 되어있는 제품 조직에서는, 기획팀이 요구사항(requirement) 문서를 만들어 전달하고 이 문서를 기반으로 논의를 진행한 후 최종 결재를 받는다. 최종 결재를 받고 나서는 ‘모든 게 합의돼서 다행이다.’라고 생각하며 프로젝트가 잘 마무리 되기를 예상한다.

‘합의된 것 같은’ 상황의 함정

하지만 이렇게 업무할 경우, 높은 확률로 만들고 나서야 합의되지 않았다는 것을 알게 된다. 아이러니하지만, 이렇게 일을 진척시키면 애초에 합의란 것이 존재하기 힘들다. 문서에 적혀있는 글자들은 개인의 해석에 따라 천차만별로 해독되며, 이를 통해 나올 산출물의 형태 또한 각자 다른 상태로 개개인의 머리속에 남아있다.

https://agile-od.com/mmdojo/2534/shared-understanding

이런 상황은 어떤 결과에 치닫게 될까?

철저히 문서 기반으로 진행된 프로젝트가 실패로 끝나게 되면, 그 실패의 몫은 누가 가져가게 될까? 대부분은 ‘요구사항이 잘못돼서’라고 지적할 확률이 높다. 기획자가 요구사항을 ‘더 자세하게’ 썼었더라면, ‘더 기술적으로’, 혹은 ‘더 있어보이게’ 써줬더라면 달라졌을거라고 말이다.

기획자는 기분이 나빠진다. ‘난 분명 다 썼던 것 같은데!’ 그리고 실패한 결과물을 보니 분명히 요구사항에 적혀있었던 부분이었는데 놓친 것들이 허다하다. 기획자는 개발자에게 “왜 요구사항 제대로 안 읽으시고 저부터 탓하죠?”라고 응수한다.

“그 긴 문서를 어떻게 하나하나 다 읽고 앉아있죠? 일 시작조차 못 할걸요?”라는 대답이 돌아온다. 그 다음이 결정타일지도 모른다. “그리고 읽어도 뭔 소린지 이해도 안 돼요.” 기획자와 개발자는 이제 이성을 놓고 싸울 게 분명하다.

출처 : https://brunch.co.kr/@uxn00b/123