brunch

매거진 App Monetization

라이킷 15 댓글 2

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Stephan Seo Feb 26. 2023

그로스 팀의 플래닝 미팅

어떻게 쉬지 않고 오랜 기간 빠르고 재밌게 달리는가?

‘그로스 해킹'은 가설 검증 실험의 반복을 통해 핵심 지표의 개선과 관련된 유의미한 레슨을 쌓는, 일종의 제품 성장 방법론이다. 지표의 개선을 위한 가설들을 기획하고 → 각각의 임팩트/컨피던스/난이도 를 산정하여 우선 순위를 정하고 → 실제 작업을 통해 실험을 배포하고 → 이후 분석을 통해 레슨을 쌓고 후속 가설을 또 쌓는 → ... 일련의 반복 프로세스인 것이다.

제품 그로스 협업 프로세스

위 그림은 ‘제품 백로그’의 생성부터 완료까지의 생애주기를 나타낸다.

이 백로그의 생애주기는, 이를 담당하는 그로스 팀의 협업 프로세스에 맞춰 크게 3단계로 나눠볼 수 있다.

문제를 정의하는 단계, 그루밍하는 단계, 파이프라인 단계로 구분된다.

1) Backlog = 문제 정의

그로스 팀 내에서 다뤄지기 전에, PO/PM 선에서 기획을 생성하고 고도화하여 완성하는 단계로, 백로그의 생애주기가 시작되는 단계이다.

기본적으로 해당 기획으로 해결하고자 하는 문제(Why)와 해결 방식 (How), 그로 인해 기대하는 결과물(What)을 뾰족하게 정의하는 것을 목표로 한다. 이를 ‘뾰족한 문제 정의’ 라고 한다.

경우에 따라 타 그로스 조직의 PO 들과 함께 검토하는 시간을 갖기도 한다. 각 백로그의 Impact 와 Confidence를 체크해보고, 혹시 모를 중복 기획, 기획 충돌 등을 미연에 방지하기 위함이다.

2) Prioritize = 그루밍

PO/PM 이 준비한 ‘어느 정도 완성도를 갖춘’ 백로그를 그로스 팀 내에 공유하고, 이미 쟁여둔 다른 백로그들 사이에서의 우선 순위를 조율하는 단계이다.

여기서의 ‘공유’란, 해결하고자 하는 문제(Why)에 대한 온도를 맞추는 것과 더 나은 해결 방식 (How)에 대한 자문을 구하는 것을 의미한다. 이를 ‘그루밍’이라고 부른다.

이에 따라 산정했던 Impact (예상 영향력) 와 Confidence (성공 가능성에 대한 ‘감’)이 싱크되고, 특히 Ease (작업 공수) 수치의 경우 해당 미팅에서 많이 조율된다.

3) Design ~ Develop ~ Analyze = 파이프라인 관리

실제 제품 내 반영이 되는 작업 단계이다. 유저 시나리오가 구체화 되고, 디자인 시안이 작업되며, 실제 개발 작업으로 이어진다. 실험의 경우 데이터 분석이 후속으로 이어져 최종적으로 제품에 반영될 실험군을 선정하며 이 백로그의 생애 주기가 끝난다. 이 단계 이후의 모든 단계를 포괄적으로 '파이프 라인'이라 부른다. 말그대로 작업 공정 라인 위에 놓인다는 의미이다.

그로스 팀 마다 적합한 주기(Cycle)를 기반으로 이 작업 단계들(파이프 라인)을 관리하는데, 이를 ‘스프린트’라고 부른다.

스프린트는 유저에게 전달하고자 하는 제품 내 가치를 적시에 잘 전달하는 것을 목표로 한다.

PO/PM 의 핵심 역량을 꼽으라 하면 여러 역량들이 언급되지만, 결과적으로 ‘제품 내 목표로 하는 개선을 이끌어내었느냐’를 생각한다면 문제 정의 역량을 꼽을 수밖에 없다. 잘못된 문제 정의에서 출발한 백로그는 100개를 하루만에 완료한다 한들 아무 지표 변화 없이 무의미한 레거시만 양산하는 데에 그치기 때문이다. 즉, 백로그의 생애 주기 중 가장 첫 단계(문제 정의)로 무게 중심이 크게 쏠리는 것이 맞다.

하지만 애석하게도 PO는 문제 정의만 잘하면 끝이 아니다. 적절한 팀내 '그루밍'을 통해 재료 손질과 엔진 동력을 비축해둬야 한다. 또한 이에 더해 (보통) 2주 단위로 반복되는 단거리 달리기를 빠른 속도로 오랜 시간 + 즐겁게 달릴 수 있게끔 파이프 라인을 잘 관리하며 스프린트를 잘 이끌어야 한다.

이 스프린트 관리에 대한 글을 두 편에 걸쳐 써보려 한다.

바로 '스프린트 플래닝'과, 그 '플래닝을 위한 사전 플래닝'이다.

성공적인 '스프린트 플래닝'

스프린트는 유저에게 그들이 필요로 하는 '가치를 적시에 잘 전달'하는 것을 그 목적으로 한다. 그러기 위해 그 호흡을 최대한 짧은 주기로 가져가며 동적으로 유저들의 피드백을 반영해 나간다. 이러한 스프린트를 '플래닝' 한다는 것은, 단순히 각 멤버들이 해당 기간 동안 '무엇을 할지' 정하는 것 그 이상을 의미하게 된다. 각자의 태스크들의 조합으로 유저들에게 '어떠한 가치가 적시에 전달되게 되는지'를 정하게 되는 것을 의미한다.

이 때 중요한 점은, 그로스 조직이 단거리 달리기 조직이 아니라는 점이다. 가치를 적시에 잘 전달하는 행위(스프린트)를 반복 지속해야 비로소, 유저 피드백 (정량적, 정성적 데이터)을 기반으로 유의미한 그로스를 해나갈 수 있기 때문이다. 우당탕탕 플래닝을 이끈다면 가치를 제 ㅇ때 잘 전달하지 못하게 되거나, 잘 전달하더라도 일회성에 그치기 일쑤다. 빠르게 달리면서 오래 달리기 위해 아래와 같은 전략들을 취하고 있다.

[A] 예측 가능성 높이기

현재 우리들의 맨 파워로 한 스프린트 동안 어느 정도의 퍼포먼스를 낼 수 있는지 정확하게 예측할수록 아주 적정한 과부하로 모두의 역량 대비 최대치의 성과를 낼 수 있는 플래닝을 할 수 있다. 일차적으로는 플래닝 태스크 대부분이 완료될 것이기 때문에 적시에 가치 전달이 될 것이고, 내부적인 성취감 또한 이어질 것이다.

또한 예측 정확도가 높다면, 필요에 따라 추가 충원에 대한 의사 결정도 미리 할 수 있고, 적시에 팀 구성을 적절하게 개편할 수도 있다. 모두가 현실적으로 만족스러울만한 아웃풋을 계획할 수 있는 것이다.

이를 위해 스프린트 플래닝 시간 동안 각 태스크들에 대해 어느 정도 시간이 소요될지 (= 스토리 포인트)를 예측해보고, 나중에 스프린트 리뷰 하는 시간에 각 태스크별 실제 소요 시간과 비교를 해본다. 더 적게 소요되었는지, 더 많이 소요되었는지 정리해보고, 각각의 이유들을 파악한다. 가령 실제 작업을 해보니 구조 설계에 시간이 많이 쓰였다든지, 타 팀의 기획과 충돌이 있었다든지, 동료들의 리뷰를 받는 데에 오랜 시간이 얼렸다든지 그 이유를 파악하는 것이다. 그럼 다음 스프린트 플래닝시에는 이를 해결할 수 있는 액션 아이템을 별도의 태스크로 가져가거나, (단기간 해결이 어려울 경우)이를 감안하여 스토리 포인트를 넉넉하게 잡아두는 행위를 통해 그 예측의 정확도를 보다 높일 수 있게 된다.

플래닝 포커 - 예시 이미지

이 때 스토리 포인트를 각 개인이 개별적으로 스스로의 태스크에 대해 예측할 수도 있지만, '플래닝 포커'라는 방식으로 동료들과 다함께 스토리 포인트를 예측하기도 한다. 각 태스크의 맥락과 도메인 전문성을 고려한다면 개개인이 스스로 예측하는 것이 가장 정확할 것 같지만, 아이러니 하게도 우리 인간은 스스로를 과신하는 경향이 있고 또 동료들 앞에서 약한 모습을 보이기 싫어하는 경향이 있어 스스로 예측하는 경우의 정확도가 훨씬 낮아지는 현상들이 왕왕 벌어진다. (물론 그 반대의 이유 - 스스로를 못 믿거나, 일을 널널하게 하고 싶어서 등 으로도 예측 정확도가 낮아질 수 있다.) 다른 동료들이 함께 서로의 태스크의 스토리 포인트를 같이 예측해주는 방식을 취한다면 이러한 현상들을 방지할 수 있다. 스프린트가 지속 반복된다는 점에서, 서로의 합을 맞춰가다보면 스스로 예측하는 것 못지 않은 정확도로 서로를 예측해줄 수 있게 되기도 한다.

[B] 심리적 안정성 높이기

각 태스크별 예측 정확도를 높였고 실제로 예측한 스토리 포인트만큼 소요되었다고 한들, 태스크 양 자체가 너무 많으면 해당 스프린트 안에 다 소화할 수가 없다. 즉 스토리 포인트의 총합이, 물리적인 가용 리소스를 넘어서는 안된다. 이러한 경우 태스크 완수를 다 할 수 없다는 것과 별개로, 스프린트 기간 내내 태스크 완수를 다 할 수 없을 것 같다는 불안감이 더 괴롭다. 불안한 마음에 스프린트 초반에 무리하여 달리게 되고, 어떻게든 완수하려다가 번아웃을 겪게 되기도 한다.

이를 방지하기 위해, 스프린트 플래닝 때 각 멤버들의 이번 스프린트 가용리소스를 계산하고, 그 이후에 각 태스크들의 스토리 포인트를 예측한다. 태스크들을 우선 순위에 맞춰 정렬하고 가용 리소스를 넘어서는 태스크들은 과감하게 이번 스프린트 태스크에서 제외한다. 각 태스크의 스토리 포인트 예측 정확도가 준수하다는 전제 하에, 이러한 가용 리소스 기반 플래닝은 가장 현실적이면서 동시에 최적의 퍼포먼스를 낼 수 있는 플래닝인 것이다.

[C] 서프라이즈 유연성 높이기

플래닝 때 모든 것을 100% 정확하게 예측할 수는 없다. 누군가 갑자기 아플 수도 있고, 개발 과정에서 뜻밖의 난관에 봉착할 수도 있으며, 여러 이유로 갑자기 기획이 바뀔 수도 있다. 이럴 때 가용 리소스를 기반으로 아주 빼곡하게 태스크를 채워 넣은 상태라면, 이러한 서프라이즈에 굉장히 예민하게 반응하게 된다. 이번 스프린트 태스크 완수율에 악영향을 줄 것이 뻔하기에 달가울 수가 없다. 그냥 원래 계획대로 하고 싶어진다.

이를 위해 가용 리소스 계산시에 '버퍼(Buffer)'를 일정 시간 할애해둔다. 보통 20% ~ 25%의 시간을 할애하곤 하는데, 쉽게 얘기해서 하루 8시간 근무시간 중에 1시간 30분 ~ 2시간 정도는 특정 태스크에 배당하지 않고 비워둔다는 의미이다. 혹시 모를 서프라이즈에 유연하게 대응할 수 있는 시간, 말그대로 완충(buffer) 시간을 확보해두는 것이다. 만약 서프라이즈가 없다면 진행 중인 작업의 퀄리티를 더 높이기 위한 일(리서치, 논의, 리팩토링 등)을 하거나, 멤버들과 커피챗을 나누며 여러 생각과 감정을 공유하면 된다. 하지만 막상 버퍼를 적용해보면 생각보다 남는 시간이 전혀 없다는 것을 금세 깨닫게 된다. 이는 그만큼 버퍼가 없던 시절에는 아둥바둥 조금씩 야근을 섞어가며 알게 모르게 우리 모두가 무리를 하고 있었다는 것을 의미하기도 한다.

물론 예측 정확도를 보다 높여서 이러한 서프라이즈를 줄이는 것이 이상적이다. 그러기 위해 플래닝 포커도 하고, 스토리포인트 관리도 하는 것이다. 결국 이 모든 것은 빠르고 오래 달리기 위한 하나의 협업 도구로서, 이상적인 협업이라는 목적지에 이르기 위해 적절하게 활용하면 되는 것이다.

이처럼 예측 가능성과 심리적 안정성, 서프라이즈 유연성을 한껏 최적화 해둔 그로스 팀은 유저에게 필요한 가치를 적시에 잘 전달하는 행위를 지속적으로 해나갈 수 있다. 이 때 가치를 적시에 잘 전달할 때에, '어떤 가치'를 전달하게 되었느냐는 또 다른 문제이다. 아무리 적시에 잘 전달한다해도, 별로 의미없는 가치를 계속 전달하고 있는 거라면 제품은 성장하지 못하고 있는 것이기 때문이다.

어떤 가치를 이번 스프린트에 전달할 것인지 정하는 것을 보통 플래닝 미팅을 활용하여 진행하곤 한다. 이는 시간 활용상 효율적일 수는 있어도, 플래닝 시점에 산출될 멤버별 가용 리소스를 미리 예측할 수 없다는 점에서 '최적의 가치'를 선정하기 힘들 수 있다. 또한 각 백로그들로 해결하고자 하는 문제에 대한 온도 싱크, 그 해결책에 대한 예상 공수 싱크 등에 따라 기획안 자체가 조금 달라질 리스크도 존재한다.

본 글을 통해 유저에게 가치를 적시에 잘 지속적으로 전달하기 위한 스프린트 플래닝 방법을 알아봤다면, 다음 글을 통해서는 전달될 가치를 극대화 할 수 있는 사전 플래닝 - 그루밍 방법을 알아보도록 하자.

keyword