grownbetter
제품 기획

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

박세호2024.01.05

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


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

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

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

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

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

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

imageAlt🔥 문서화 지옥의 예상도_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/


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

imageAlt


그로우앤베터 회원 전용 콘텐츠 입니다. 회원가입 후 무제한으로 읽어보세요.

#TAG
서비스 기획프로젝트 관리PM·PO기획 경험

박세호

프로덕트를 만드는 것에 대한 전문적이고 기술적인 이야기들과 가치를 찾는 과정과 고찰을 이야기 합니다. 좋은 회사, 좋은 제품은 한명의 힘으로 만들어 나갈 수 없어요. 함께 만들어가는 제품 그리고 팀은 어떻게 협업해야 하는지 공유해 드리겠습니다.


추천 아티클
추천 프로그램
  • [사전예약] 갑자기 PM이 되어버린 실무자를 위한 매니징 스킬 3기
    주니어
    기획
    프로젝트

    [사전예약] 갑자기 PM이 되어버린 실무자를 위한 매니징 스킬 3기

    회사이건, 인생이건, '본인에게 주어진 것을 잘 해내는 것'이 진정한 PM의 역할입니다.

  • [VOD] 매력적인 서비스를 만드는 PO/PM 유니버스
    주니어
    기획
    VOD

    [VOD] 매력적인 서비스를 만드는 PO/PM 유니버스

    PO나 PM은 어떤 일을 하는걸까? 그들은 어떤 역량을 가져야 할까?

  • [VOD] PM/PO라면 반드시 알아야 할 애자일 & 스크럼
    주니어
    기획
    애자일

    [VOD] PM/PO라면 반드시 알아야 할 애자일 & 스크럼

    애자일이 뭐고, 스크럼은 또 뭐야? 완벽한 프로젝트 관리 방법론, PM이 직접 알려드립니다!

동일 카테고리 아티클
    (주)더자람컴퍼니  
    대표 천세희  
    개인정보관리책임자 : 천세희  
    사업자등록번호 : 581-87-02148  
    통신판매업신고 : 2021-서울강남-03446호  
    서울 강남구 역삼로 175 현승빌딩 5F  
    고객센터 : 02-2135-6992  
    문의 : hello@jaram.one  
    Copyright © 더자람컴퍼니. All right reserved.