우리 팀의 소화력을 알고 있나요?
왜 항상 일정이 미뤄질 수밖에 없는가
진행 중인 강의 보러 가기 : https://litt.ly/lbyd
개발자 A : 어떨 때는 너무 간단한 일을 줘서 할 게 금방 없어지고.. 또 어떨 때는 엄청 큰 일을 타이트한 일정으로 해달라 하고.. 도저히 어느 장단에 맞춰야 하는지 어렵네요...
디자이너 B : 하루하루 일에 치여서 이직을 해야 할 것 같아요..
회사를 다니다 보면 들쑥날쑥한 일정에 의해 갑자기 일이 몰리기도 하고 갑자기 여유로워지기도 해요. 하지만 이런 경험이 반복된다면 일의 퀄리티도 들쑥날쑥될 수밖에 없어요. 그렇기 때문에 팀에서는 스스로 일에 대한 소화력을 알고 있어야 해요.
소화력? 그게 뭐예요?
소화력은 제가 만들어낸 말이에요. 쉽게 말해서 한 스프린트 동안 처리할 수 있는 일의 양입니다. 예를 들어, 로그인을 구현한다고 했을 때 소화력을 알고 있다면 기간 내에 가능하다, 못하다를 바로 알 수 있는 것이죠. 이것을 알고 있는 것과 모르고 있는 것은 하늘과 땅 차이예요.
특히, PM/PO는 이걸 명확히 알고 있어야 하고 팀에 공유해야 해요. 팀이 소화할 수 있는 일의 크기와 수를 모르는 PM/PO의 경우 단순 의지와 열정으로 팀이 소화할 수 없는 일을 진행할 가능성이 많기 때문이에요. 갈등의 시작이죠.
예를 들면 A, B, C라는 일이 있고 C라는 일이 최종 목표이고, A와 B가 완료되어야만 할 수 있는 일이라고 할 때 팀 소화력을 모르는 PM/PO는 A가 얼마나 걸리는지, B가 얼마나 걸리는지, 그래서 최종적으로 C가 얼마나 걸리는지 확인할 수밖에 없어요. 당연한 방식입니다. 하지만 팀의 소화력을 아는 PM/PO의 경우 A, B, C 각각이 우리가 소화할 수 있는 범위에 있는지 확인합니다. 그리고 A, B, C를 더 작은 단위로 나누고 최대한 병렬적으로 진행할 방법을 찾습니다. 정말 신기하게도 수많은 PM/PO를 만나면서 일을 쪼갤 생각을 했던 분들은 팀의 소화력부터 판단하는 분들이어요. 그렇기 때문에 팀의 소화력을 아는 것은 정말 중요해요.
저 또한 입사를 하면 바로 하는 일이 팀의 소화력을 측정해 보는 것입니다.
그게 가능해요? 어떻게 하면 되는데요?
1️⃣ 사전 준비
팀의 소화력을 측정할 때는 측정하는 것보다 사전 과정과 리뷰가 더욱 중요해요. 왜냐하면 소화력을 측정한다고 하면 다들 그게 어떻게 가능해? 정확해? 이거 불만 많을 것 같은데? 등등의 피드백을 줘요. 그럴 수밖에 없다 생각해요. 대부분 한 스프린트 동안 할 수 있는 일의 양을 측정한다고 하면 대부분 개인별 처리한 티켓의 수를 합산한 것으로 이해하고 있기 때문입니다. 어떻게 보면 맞아요. 모두가 알고 있듯 일의 크기와 처리량을 측정한다는 것은 굉장히 어려운 일이기 때문이에요. 그렇기 때문에 소화력을 알고자 한다면 몇 가지 사전 조건들이 있어요.
1. 우선 Jira, Linear 등의 Task Management Tool을 사용하고 있어야 해요. 정형화된 규칙으로 잘 사용할 필요는 없어요. 대신 모든 직군의 사람들이 각자 맡은 일에 대해 epic, story, task, subtask 등 이슈들을 등록하고 due date만 설정하고 있다면 러프하게나마 우리 팀의 소화력을 측정할 기본 준비가 된 것입니다.
2. 소화력을 측정하는 배경, 그리고 명확한 기준이 사전에 공유되어야 해요. 명확한 배경 없이 소화력을 측정하겠다고 하면 대부분은 평가 아니야?라고 반응하기 때문이에요. 평가라고 생각하는 순간 너도 나도 내가 하는 일들이 티켓으로 명확히 정의할 수 없으며, 설령 티켓을 만들 수 있다 한 들 그 티켓의 크기가 업무의 크기와 일치하지 않을 수많은 케이스들을 예로 들며 팀의 소화력을 정의할 수 없다고 해요. 모두 맞는 말이에요. 티켓의 수와 크기는 절대적으로 한 사람의 역량과 퍼포먼스를 대변할 수 없어요. 그렇기 때문에 더 큰 단위, 더 러프한 범위의 팀의 소화력을 측정하는 것이 필요해요. 소화력은 단순히 티켓의 수를 의미하는 것이 아니기 때문이에요. 즉, 개인이 처리한 티켓의 수가 아닌 우리 팀에서 일주일 동안 얼마만큼의 어떤 사이즈, 어떤 난이도의 티켓을 처리하는지 돌아본다는 의미예요.
3. 소화력 측정을 위해서는 최소 5번 이상의 릴리즈를 해야 해요. 회사의 일이 대부분 동일한 사이즈의 일이 주어지지 않고 난이도도 측정 불가능한 것들이 많기에 우리 팀의 소화력을 러프하게나마 알려면 최대한 많은 릴리즈 경험이 필수예요. 그렇다고 너무 많은 릴리즈를 기준으로 판단하면 소화력 측정이 그만큼 늦어지게 돼요. 일반적으로 5번 정도의 릴리즈를 해보면 개발자, 디자이너, 기획자, PM/PO 모두가 했던 일들에 대한 대략적인 사이즈와 난이도에 대해 상대 평가할 수 있는 기준이 생기 때문입니다.
2️⃣ 측정 방법
1. 스프린트 플래닝을 통해 할 일 크기와 예상 시간을 정하기
그럼 진짜 본론인 측정 방법이에요. 측정을 하기 위해서는 스프린트 플래닝 시간이 무조건 있어야 해요. 스프린트 플래닝은 이거 하자, 저거 하자의 방식으로 진행되는 것이 아닌 우리가 이번 스프린트 때 무엇을 할 것이며, 어떤 결과가 나와야 하는지를 같이 이야기 나누면서 전체적인 구현 사항들의 윤곽을 잡는 시간이에요.
단순히 기획자가 기획안을 가져와서 읽는 자리가 아닌 고객이 필요로 하는 것이 무엇인지를 공유하고, 최고의 결과를 만들기 위해 어떤 것을 해야 하는지 이야기하는 시간으로 진행되어야 해요. 이 과정 속에서 결정된 세부 내용들을 기획하고 디자인하고 구현하는 것이죠. 추가적으로 어떻게 구현할지에 대해서 논의할 때는 플래닝 포커를 활용하면 더욱 좋아요. 플래닝 포커는 HIPPO(Highest Paid Person's Opinion)를 막아주는 강력한 도구입니다.
추가로 일을 논의할 때는 정말 작은 단위로 나눠서 이야기해야 해요. 로그인만 보더라도 구글 로그인, 이메일 로그인, 카카오톡 로그인 등으로 여러 개로 나뉘니까요. 만약 시간이 없다면 큰 단위로 이야기를 나누는 대신 Task Management Tool에 작은 단위로 나눠서 등록해야 해요. 여기서 작은 단위는 테스트가 가능한 가장 작은 단위로 생각하면 돼요.
스프린트 플래닝을 통해 정해진 것들을 Task Management Tool에 등록하면 돼요. Task Management Tool에 등록할 때는 반드시 플래닝 포커에서 이야기 나눈 예상 크기(L, M, S)와 소요 시간(1/2, 1, 2, 3, 5, 8, 13, 21)을 작성해야 해요. 이것이 없으면 의미가 없어집니다.
2. 대시보드 만들기
스프린트 플래닝이 완료되면 시간과 이슈 간의 상관관계를 알 수 있는 대시보드를 만들어 놓으세요. 스크럼을 운영한다면 Burn-down 차트를, 칸반으로 운영된다면 Lead time 차트를 만드는 것을 추천드립니다. 이 대시보드는 리뷰할 때 반드시 활용될 예정이라 꼭 미리 만들어 놓으셔야 해요.
3. 최신 상황 업데이트 하기 & 연관된 일만 하기
스프린트가 진행되는 동안 제일 중요한 것은 이슈들이 항상 최신의 상태로 유지되어야 한다는 점이에요. 어제 완료한 것, 오늘 할 것, 현재 병목 상태인 것들을 공유하면서 진행 상황을 서로 점검하는 것이 제일 좋아요. 스크럼에서 데일리 미팅을 하는 가장 중요한 이유죠. 만약 중간에 새로운 일이 생기면 추가하고, 특정 일이 사라지면 지우면 돼요. 하지만 추가되는 새로운 일은 반드시 스프린트에서 구현해야 하는 사항과 연관이 있어야 해요. 다음 스프린트를 위해 미리 관련 없는 일을 하게 되면 측정하는 의미가 사라지게 돼요.
3️⃣ 리뷰하고 개선하기
1. 대시보드를 통해 리뷰하기
스프린트 내 일정 주기마다 대시보드를 통해 리뷰를 진행합니다. 저는 보통 목요일 오후로 진행하는 편이었어요. 금, 월, 화, 수 이렇게 4일을 일한 내용을 목요일 오후에 다 같이 모여서 이야기 나눈 것이죠. 스프린트 주기가 2주라고 할 때 1주 동안 어떤 일을 했고 플래닝 포커로 세운 계획 대비 얼마나 차이가 났는지를 이야기하면서 나머지 1주를 어떻게 보낼지를 논의해요. 이런 과정이 반복되면서 실제 우리 팀의 소화력을 점점 정확하게 만들어 가는 것이죠.
2. 상대 평가를 기본으로 한 다음 일정 수립
이번 리뷰를 통해 다음 스프린트 플래닝을 할 때 일정을 고민하는 방식이 변경되어야 좋은 방향으로 가고 있는 것이에요. 예를 들어 이번 스프린트 때 로그인 구현을 4시간으로 잡았다고 할게요. 근데 실제 구현 시간은 8시간이 걸리게 되었어요. 그럼 다음 스프린트 플래닝 때는 로그인 구현을 기준으로 해당 기능이 얼마나 걸릴지 고민해야 해요. 반대로 로그인 구현을 4시간으로 생각했는데 실제 2시간 만에 끝났다고 하면 비슷한 기능도 2시간이면 된다는 결과가 나와야 해요.
보통 일정을 계산할 때 자신을 과대평가하거나 과소평가하는 것이 일반적이에요. 그렇기 때문에 항상 일 중 가장 명확하게 했던 일을 기준으로 얼마 걸릴지 고민하는 상대 평가를 해야 점점 감을 익혀 나갈 수 있어요.
이렇게 5번의 릴리즈 과정을 통해 우리 팀의 소화력을 측정한다면, 어떠한 일이 오더라도 꽤나 비슷하게 일정을 계산할 수 있어요. 눈치 빠르신 분들은 이미 느끼셨을 텐데, 이게 바로 스크럼을 운영하는 방식입니다. 핵심은 스프린트 플래닝 방식과 리뷰예요. 한 번에 이 모든 것을 정립하기보다는 이번에는 스프린트 플래닝을 해보고 다음에는 리뷰까지 해보고 하는 등 천천히 하나씩 적용하면서 변경해 보는 것을 추천해요.
추가 궁금한 것이 있다면 언제든 오픈채팅방으로 연락 주세요.
PM/PO/제품 개발에 대한 인사이트를 얻고 싶다면, 오픈채팅방에 참여해 주세요!
https://open.kakao.com/o/g7XO1A5g 참여코드 : til2025
Threads : https://www.threads.net/@lbyd_learning.by.doing
뉴스레터 구독하기 : https://maily.so/marcus.lee
유튜브 구독하기 : www.youtube.com/@LbyD_HJ?sub_confirmation=1
커피챗 및 멘토링 신청하기 : https://inf.run/GRTee
팀 코칭 신청하기 : https://open.kakao.com/o/sh47Hq4g
