brunch

라이킷 21 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by florent Apr 14. 2024

기획자와 개발자의 고질적인 싸움의 원인: 문서

User Story Mapping

이 글은 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

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

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

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

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

왜 우리는 이러한 상황을 마주쳐야 하는가?

우리는 ‘완벽한 문서’의 함정에 빠진다. 우리는 문서를 쓰면서 다양한 전제를 염두한다.

첫 번째, 사람들이 문서를 꼼꼼히 읽어줄 것이라는 전제

두 번째, 내가 쓴 글은 의도대로 읽혀질 만큼 완벽할 것이라는 전제

세 번째, 문서가 자세한 만큼 프로젝트의 성공율이 높아질 것이라는 전제

하지만 긴 글은 필연적으로, 특히나 업무에 관련된 글이라면, 읽기조차 꺼려지며 내용을 제대로 파악하기도 어려워져 ‘암호화(cryptic)’된다. 그리고 ‘자세한 문서’를 쓰는 이유와 목적을 상실하게 된다.

제품 조직의 ‘역사가’가 되어 기록을 하기 위해 문서를 작성할까? 물론 아니다. 우리는 문서 작성의 이유를 다시 생각해봐야 한다. 우리는 ‘제대로 제품을 만들기 위해 팀원을 이해시키기 위해’ 문서를 작성하는 것이다.

많은 요구사항 문서는 왜 잘못되어 버리는가?

기획자는 ‘완벽한 문서’를 써야한다는 압박감에 장황한 요구사항 문서를 만들게 된다. 하지만 그 문서를 쓰지 않은 사람이 그 문서를 보면, 우선 길이에 압도되며, 읽는다고 할지라도 뭘 만들라는 명령과 같은 문서 내용에 거부감을 느낀다.

이러한 문서들은 ‘우리가 뭘(what) 필요하는지’에 대해서만 적혀있지, ‘왜(why)’ 필요한지에 대해 적혀있지 않다. 마치 외주 업체에 맡기듯이 말이다. (p.s. 외주 업체에도 이렇게 맡기면 재앙적인 결과가 초래된다.) 요구사항 문서는 제대로 제품을 만들기 위해 팀원에게 이해를 돕지도 못하게 되며, 결국 누군가의 힘을 잔뜩 쓰기만 한 기록물이 되어 버린다.

팀원들과 대화를 나누지 않는다면, 기획하고 있는 것이 아니다.

애자일 개발 방법론에서 쓰이는 ‘스토리’는 정말로 입에서 나와야하는 이야기다. 그저 글로만 쓰인 스토리는 스토리라고 칭할 수 없다. 스토리는 사용자의 이야기를 입을 통해 나누게 하는 시작점이 되어야 하며, 그 이야기의 종착점은 조직적으로 사용자의 이야기를 체화하여 ‘우리의 이야기’가 되어야한다.

즉, 사일로(silo) 현상처럼 문서만을 주고 받는 것이 아니라, 스토리를 쓰는 조직이라면 스토리가 만들어지는 시점부터 모든 직무자들이 함께 모여 이야기를 시작할 수 있어야한다. 기획자는 다양한 관점의 정보들을 수집할 수 있도록 그 이야기를 촉진시키고 이 이야기들을 종합하는 것이 역할이다.

결국, 기획자가 작성하는 문서는 얘기된 모든 것을 세세하게 적은 글이 아닌, 팀원들과의 논의를 상기시켜줄 수 있는 ‘추억의 사진’과 같은 효과를 낼 수 있는 문서가 필요한 것이다. 다시 말해, 공동의 이해는 ‘대화’를 통해 이뤄져야 하며, 문서는 이를 다시 기억해내게 해주는 자극제의 역할을 수행해야한다.