프로덕트 개발 방법론 4D:Design&Delivery
독일 글로벌대기업 프로덕트매니저가 따르는 4D 방법론
*무려 1년 넘게 글을 쓰지 않았다는 사실에 새삼 혼자 놀라며...https://brunch.co.kr/@yujinyun/31글 '4D방법론 - Discovery/Define 편에 이어서 씁니다.
4D는 총 네 가지의 D를 가지고 있어, 4D라고 부른다.
Discovery(문제발견)
Define(문제정의)
Design(솔루션 디자인)
Deliver(솔루션 딜리버, 즉 개발/릴리즈)
이번 편에서는 Design과 Deliver에 대해 설명해 본다. 사실 솔루션 디자인과 딜리버는 우리나라의 PM, PO, 서비스기획자 - 뭐라고 부르던 - 들은 너무나 잘 알고 있는 영역이다. 그래서 원론적으로 솔루션 디자인의 방법론이나 개발 방법론등을 여기서 이야기하는 건 별로 의미가 없을 것 같다. 그래서 우리나라랑 글로벌회사에서 어떻게 다른 과정으로 일하는지에 조금 더 포커싱해서 이야기해보려 한다.
Design '솔루션 디자인'
솔루션 디자인 과정은 정의된 문제에 대한 해결 방법을 브레인스토밍하며 개발자, 디자이너와(디자인 들어가는 경우) 의논하며 디자인/개발할 사항을 구체화시키는 단계이다.
이 단계에서 국내와 다른 점은 확실히 Product designer 그룹과 Engineer들의 역할이 PM에 비해 엄청나게 크다는 거다. 대부분의 국내 기업에서는 피엠이 솔루션을 생각해서 요구사항으로 정리하고, 이를 개발자와 리뷰해서 한번 더 정리한 다음, 간단한 화면 설계도 위에 디자이너가 이해할 수 있도록 소위 말하는 '장표'를 만드는 경우가 많다. 그러나 대부분의 규모가 있는 글로벌 해외 기업들은 PM이 Discovery, Define과정에 상당한 시간과 에너지를 소요하기 때문에 Design, Deliver과정은 디자인, 엔지니어 그룹의 힘에 의존할 수밖에 없다,
또 그렇게 하는 다른 이유는 디자이너와 개발자들이 Autonomous 하게(주도적으로) 일하는 것이 개발 과정에서 훨씬 효율적이라고 생각하기 때문이다. 한국 기획자라면 누구나 한 번쯤 개발자와 일할 때 개발자가 '의도'를 파악하지 않고 '적힌 그대로' 개발을 해서 요구사항과 너무나 다르게 아웃풋을 낸 경험을 한 적이 있을 것이다. 이는 개발자들이 User story기반으로 솔루션을 피엠과 같이 고민하고 이야기 나누면서 결정해 나가지 않았을 때 생기는 전형적인 문제다.
우리 회사의 경우 다음과 같이 솔루션 디자인의 단계를 거친다.
솔루션 디자인 1단계
Principle Engineer(프린시플 엔지니어) 그리고 프로덕트 디자이너는 PM이 정의한 유저스토리/인수조건(Acceptance Criteria)을 같이 리뷰하면서 질문을 많이 하고, 타깃 사용자를 이해하고, 풀려는 문제가 무엇인지를 충분히 이해하는 시간을 가진다.
대략적인 상위 해결 방법을 이때 PM이 공유하는데, 그 방향성에 대해 챌린지를 하기도 하고, 데이터를 요구하기도 한다. 그리고 함께 어느 정도 모두가 동의하는 상위 해결방법이 정해지면 Principle 개발자는 technical discovery / technical design에 들어가고 디자이너는 상위 key user flow를 목업형태로 잡는다.
Technical discovery는 말 그대로 기술적인 리서치 작업인데, 어떠한 데이터가 필요하다고 판단이 되면, 어떤 조직의 어떤 팀이 어떤 API로 이 데이터를 제공하는지를 알아내는 작업이기도 하고, 완전히 새로운 기술이나 프레임워크를 도입해야 한다면 그것들을 조사하며 장단점을 비교분석하는 것을 말하기도 한다.
디자이너는 유저 플로우를 잡는데, 여기서, 한국에서 소위 '장표'라 부르는 것 (개발되어야 하는 모든 화면을 정의 + 각 UI 컴포넌트를 설명하고 동작하는 방식까지 설명하는 장표)를 PM이 만드는 것은 최소 글로벌회사 디자이너에게는 선 넘는 행동이라는 걸 알아두자. 이건 철저히 프로덕트 디자이너의 영역이다.
솔루션 디자인 2단계
어느 정도 기술적 리서치가 마무리되면 Pr. 개발자는 이를 문서화한다. 모든 부분이 한 번에 다 명확해질수는 없으니 확실한 부분들은 기재를 하지만 그렇지 않은 부분들은 Open questions로 남겨놓고 개발 요구사항을 구체화시키는 동안 계속 이를 해결 한다. 그리고 high-level-technical design을 적는다. 어떤 식으로 아키텍처를 잡을 건지, 솔루션을 위한 api를 따로 개발할 것인지 등을 나중에 개발자들과 함께 리뷰하기 위해 Suggestion(제안)의 형태로 기재한다.
디자이너는 어느 정도 완성된 디자인 목업이 나오면 이를 Click through prototype (이미지 위에 클릭을 해서 동작하는 것처럼 보이는 프로토타입)으로 만들어 필요시 내부/외부 사용자들을 대상으로 테스트를 하기도 한다.(이는 필수는 아니다).
이쯤부터 PM은 솔루션이 어느 정도 구체화 되었으므로, PRD(Product Requirement Doc)을 만든다. 이때, Must-have, Good-to-have 요구사항을 명확히 해서 꼭 필요한 기능과, 있으면 좋은 기능을 나눠서 기재해 개발 리뷰의 효율성을 높인다. 또한 모든 것들을 다 처음부터 개발할 수 없으므로 product Scope을 명확히 규정한다. MVP, MRP로 구분하기도 하고, Milestone1, 2... 혹은 Phase 1, 2... 식으로 구분해서 어떤 기능들이 언제까지(preferrably) 처음 릴리즈돼야 하는지 명시한다.
PRD가 어느 정도 구체화 되면 내부 개발팀뿐만이 아니라, 타 팀/부서/실의 Dependency(의존도)가 있어 협업이 필요한 부분을 그 팀의 PM 그리고 개발자(개발리드)를 초대하여 함께 리뷰한다. 물론 이 리뷰 훨씬 전 Problem define 단계에서부터 이 product intiative의 우선순위와 일정에 대해 그 팀과 alignment가 되어있어야 하고, 상위 솔루션 아이디어에 대한 설명은 미리 해 놓은 상태여야 한다. 구체화된 솔루션의 리뷰 후에는 그쪽 팀/실의 PM은 이 솔루션을 이해하고 자신들이 어떤 방식으로 개발할지를 내부적으로 의논해 공유한다.
솔루션 디자인 3단계
EPIC, STORY들을 개발자들과 함께 리뷰하며 실제로 개발하는데 필요한 거의 모든 것들을 PM, Pr.Engineer와 함께 상의한다. 개발 단계에서 타 개발팀의 Dependency(의존도)가 있는 부분은 어떤 식으로 해결할지, 시스템 설계는 어떻게 할 것인지, 어떤 외부/내부 솔루션을 쓸 것인지 등을 논의하며 앞서 아주 대략적으로 산출했던 것보다 더 정확한 개발 비용을 산정한다.
PM은 PRD(Product Requirement Doc)를 더욱 구체화시켜가면서 JIRA에 EPIC과 STORY 티켓 등의 큰 단의 티켓을 생성한다. 개발팀은 그 밑에 Task단위의 티켓을 만들어간다.
디자이너는 유저테스팅 결과를 디자인에 반영하며 UI완성도가 높은 화면들을 뽑아내 함께 리뷰하고, 이때 개발 시 필요한 모든 화면과 컴포넌트들을 제작한다.
Delivery '솔루션 전달(개발&릴리즈)'
Delivery Phase, 즉 개발단계로 들어오면 Pr. Engineer의 역할은 거의 없어지고, 해당 프로덕트를 담당하는 개발자들이 주도적으로 세부적인 Ticket을 생성해 가며 개발을 진행한다. 미처 솔루션디자인 단계에서 예측하지 못했던 부분의 업무들도 당연히 생기기 마련이다. 그런 부분들도 그때그때 티켓을 생성하며 Story point(개발 비용/effort)를 부여한다.
Target release date도 대략적으로 (예:12월 초) 이때 정해지며, 이 날짜는 top-down으로 절대 내려오지 않는다. 만약, 어떠한 불가피한 비즈니스적인 이슈로 인해 특정 기능만 그때까지 개발해야 한다면 scoping을 하는 단계에서부터 그 기한에 맞게 Phase 1, Phase 2..로 나누어서 개발 범위를 정한다.
개발 단계에서는 PM이 개발 Daily standup에 대부분 참여하여 그때그때 질문에 대답하기도 하고, 개발사항들을 체크하기도 한다. 단발성 미팅이 개발자와 많아지는 단계이기도 하다.
여러 타 팀에 의존도를 가지고 함께 개발을 함께 진행해야 하는 경우, 그 복잡도와 규모에 따라 PJM(Project manager) 혹은 PMO(Project management office)가 투입되기도 한다. 국내에서는 프로덕트매니저가 있는데 프로젝트 매니저가 또 추가로 투입되는 경우를 많이 보지는 못했는데 이 부분이 또 글로벌 기업에서 다른 부분이 아닐까 한다.
한 예를 들자면, 지금 내가 잘란도에서 진행하고 있는 솔루션은 Product discovery와 design단계가 반년, 그리고 Design과 Delivery가 반년 이상 걸리는 큰 프로젝트다. 나는 몇십 명의 PM들이 함께 투입돼서 만들어가는 큰 솔루션에서 하나의 영역을 담당하고 있는데, 이 하나의 영역에는 잘란도 B2B의 6개 타 팀이 함께 일을 해야 하는 높은 의존도를 가지고 있다. 솔루션도 상당히 복잡하고 너무 많은 디파트먼트가 협업해야 하는 만큼, PMO가 투입되어 일정관리, 아직 정의되지 않은 부분 다시 제기해서 해결, 리스크 관리 등을 해주고 있다.
6개의 실 중에서 1개의 실만 일정을 지키지 않아도 전체가 밀리는 리스크를 안고 있기에, PMO는 매주 진행상황 체크인 회의를 하며 모두의 진행상황을 체크하고, 일정 딜레이가 발생하는 경우 이를 해결하기 위해 리더십에게 보고하고 리소스를 더 투입하게 만드는 역할도 해주는 것이다.
Delivery의 꽃은 E2E UAT (End to End User Acceptance Testing)이 아닐까 한다. 여기서 난리법석 여러 가지 이슈가 많이 발생하고, 이를 빠르게 해결하며 최대한 정해놓은 Target release date를 지키려고 한다.
Go-live 직전에는 정신이 하나도 없는 와중 PM이 챙겨야 할 것들이 수두룩하다. 아마도 여기서부터는 국내에서의 릴리즈 과정과 크게 다르지 않을 것이라고 생각한다. 예를 들면 아래와 같은 작업들이 PM이 추가로 챙겨야 하는 것들이다.
- 내부 운영팀, 고객 지원팀에 전달할 가이드 문서 업데이트
- 외부 고객에게 전달할 FAQ, 가이드 문서 업데이트 후 릴리즈
- 주요 고객(b2b)과 릴리즈 관련 Align
- 한 번에 모든 고객에게 릴리스하는 게 아니라면 pilot user 설정
- 데이터 트래킹할 수 있도록 데이터 로깅 요청
...
자, 정말 모든 (중요하고 급한) 이슈들을 해결한 후 Go-live를 했다면, Go-live 전체메일을 써서 릴리즈를 알린다.
지금까지 4D방법론에 대해 이야기하고, 구체적으로 각 단계별로 어떤식으로 일하는지를 공유해 보려고 노력했다. 쓰면서 느낀건, 상당히 많은 부분들이 실제로 이런 블로그로 커버되기는 힘들다는 거다.
국내에서 4D 방법론과 그 단계마다 일하는 방식을 보고 차용했으면 좋겠다고 생각하는 부분은 아래와 같은 부분이다.
1) 충분한 Discovery, Define 시간을 피엠들이 가질수 있어야 한다는 것
2) 솔루션 디자인 과정에서 디자이너, 개발자가 훨씬 더 주도적으로 솔루션을 만들어갈 수 있어야 한다는 것
3) 명확한 릴리즈 일정은 bottom up으로 솔루션 구체화 단계에서 개발팀에 의해 정해져야 한다는 것
4) 규모가 큰, 여러 팀 협업이 필요한 프로젝트에는 프로젝트 매니저의 서포트가 있어야 PM이 일정관리와 커뮤니케이션에 너무 많은 시간과 에너지를 뺏기지 않아 더 효율적으로 일할 수 있다는 것
그리고 또 하나 덧붙이고 싶은 말은, 이 4D 프레임워크도 더 효율적으로 잘 일하기 위해 만들어진것이기 때문에 그 의도를 이해한다면 그때 그때 유연한 방식으로 조직에 맞게, 상황에 맞게 일하는 것이 중요하다는 거다. 프로젝트 규모의 크기에 따라 (임펙트가 얼마나 크냐에 따라) 정말 제대로 이 4가지의 단계를 다 밝고 관련 리더들/이해관계자들에게 리뷰를 받아가며 진행하기도 하고, 그렇지 않고 Discovery와 Define을 합쳐서 1-2페이지로 정리하고 (one-pager problem definition) 이를 바탕으로 바로 PRD로 들어가기도 한다.
