PM과 PO는 문서화를 하는 사람이 아닙니다.

• 이 글은 그로우앤베터 프로이신 '박세호 리더'의 인사이트에서 발췌하였습니다. (출처)

지금까지 실무를 진행하며 어느 정도 늘었다고 생각하는 것은 “문서는 줄이고 컨텍스트는 맞출 수 있는.” 상황을 만들어나가는 방법을 어느 정도 배워가고 있다는 것 같다.

 기업이 커지면 커질수록, 또 고도화될수록 “많은 양의 문서화”와 “명확한 가이드라인”의 작성을 주요로 삼고, 지금까지 만들었던 서비스의 제품의 청사진을 다시 만드는 작업을 하곤 하는데, 그런 작업의 문제점은

어디서부터 무엇을 작성해야 할지, 문서를 만드는 와중에도 개선되고 있는 제품을 어떻게 나눠서 제공해야 하는지에 대한 기준을 만들기 어렵다.

실제로 어떤 식으로 동작하는지에 대한 이해가 부족한 상태에서 작성한 내용은 부정확성을 기를 수밖에 없기 때문에 완성되어도 신뢰성이 떨어진다.

그렇기 때문에 100% 완료! 라는 종료를 지을 수도 없고, 지어도 2차 3차 계속해서 만들어야 하는 것이다.

 기획서도 마찬가지다. 어떤 특정한 목업을 기반으로 나오는 PPT의 경우, 버전이 업데이트 된다든지 새롭게 개선이 될 경우, 이전 기획서들은 이미 유실되거있거나, 구현된 것과 달라 꿔다놓은 보릿자루가 된다. 그러고 나서 또다시 최신화라는 문서화 지옥에 빠지게 된다.

🔥 문서화 지옥의 예상도_jpg

 그래서 지속적인 문서화라는 것은 제품을 만들면서 같이 병행되어야 하고, “문서화”는 목적이 아닌 제품 자체에 녹아 있어야 한다. 그래서 애자일 방법론에서 유저 스토리나 기술적인 작업(Technical Chores)들을 작성할 때 Acceptance Criteria를 명확하게 작성하는 것이고, 완료의 조건(the Definition of done)을 명확하게 명시하는 것이다. 

그리고 하나하나 세세하게 나뉘어진 스토리와 작업들이 한곳에 모이고, 진행된 또는 진행해야 할 업무들이 모이는 한 장의 PRD가 자동으로 하나의 제품의 문서화가 되는것이다(코드를 기반으로 자동으로 디벨롭 되는 API 문서를 선호하는 것도 이하와 같다.)

그리고 빡센 UI 가이드를 하는 기획서나 플로우 차트를 작성하는 것을 개인적으로 또 지양하는 이유는,

1. 내가 신뢰하는 프로덕트 디자이너가 상상할 수 있는 영역을 막게 되거나,

2. 더 나은 플로우의 생산성을 막게 되거나,

3. 내 주관 때문에 진짜 고객이 원하는 것을 놓치는 것을 막기 위함이다.

그리고 정말로 감이 안 오는 상황이나 제품팀에서의 합이 안 맞을 경우엔 차라리 디자인 스튜디오를 통해 합치되는 플로우를 만들고, 그것을 기준으로 일을 진행하는 것이 지금까지도 더 효율적이었다. 그리고 지금까지도 개인적으론 난 이런 방법을 더 선호한다.

예전에는 거의 모든 페이지에서의 로직을 다 플로우차트화 하고, 지속적으로 업데이트 했었지...

 프로덕트를 만들기 위해서 가장 필요한 것은 “지금 이게 왜 필요한 거지?”에 대한 고민과 제품을 만드는 사람들과 고객과의 지속적인 인터렉션이지, 종일 기획서를 작성하는 일을 하는 것이 진짜 실무라고 생각하진 않는다. 

오히려, 지금 나의 제품이 어떻게 구현되어 있어서 어떤 것을 개발하는 데 시간이 걸리니 개선할 수 있는 방법을 찾아보거나 진짜 우리가 필요한 기능이 언제 나와야 하는지를 같이 고민하는 것이 진짜 PM과 PO들이 생각해야 하는 일이라고 생각한다.

 기획서, UML, 플로우 차트는 실제로 그것들이 제품으로 만들어지지 않는다면, 그건 그냥 문서를 만드는 일만 한 것이다. Agile Manifesto에서 “Working software over comprehensive documentation”은 괜히 나온 말이 아니다. 문서만 보고 있는데 어떻게 제품이 나올 수 있는가? 진짜 구현되고 있는것에 집중해야지.

 그리고 문서화의 목적이 실무자들의 퇴사로 인한 정보의 유실과 백그라운드 보완을 위해서나 뉴비 개발자나 제품 관리자들이 지금 프로덕트가 어떤 구조로 되어있는지 감을 알려주는 것에 목적이라면, 같은 일을 하는 조직원들과 Pairing을 통해 업무방식과 서비스의 구조를 확인하고 업무하는것, 그리고 지금 일하고 있는 조직원들이 이탈하지 않도록 같이 성장하고 서로 신뢰하는 조직을 만드는 것이 더 훨씬 더 싸고 지속가능한 방식이다.

문서를 잘 만드는것은 분명히 좋은 능력이다. 부정하고 싶진않다. 하지만, 진짜 제품을 만드는 사람이라면 User story mapping의 저자 Jeff Patton 옹이 이야기 한 것처럼 세상을 바꾸는 일을 해야지, 혼자의 PPT 속에 틀어박혀 "내가 분명히 문서에 기깔나게 썻는데, 아무도 안읽어 왔네!"라는 상황을 만들면 안된다고 생각한다.

* 위에서 말씀드린 User Story Mapping은 기회가 되면 꼭 읽어보세요. 리얼 찐 입니다

박세호 리더의 더 많은 인사이트가 궁금하신가요?

📝 브런치 : https://brunch.co.kr/@tsp/

🖇️ 링크드인 : https://www.linkedin.com/in/tonyseahopark/

🚨 박세호 리더님의 실무 인사이트가 더 궁금하신가요?