Inspired Summary
해당 글은 Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group) by Marty Cagan을 읽고 요약한 글입니다.
- 회사의 목표, 각 제품 팀의 목표에 맞게 구성
- 조직 차원에서 정돈된 일련의 목표를 성취하기 위해 만들어진 것
- 사적/개별적이거나 기능적인 차원 수준의 목표가 섞여 희석되지 않도록 주의
목표 (Objective)
- 질적(qualitative)으로 서술되어야함
핵심 결과 (Key Results)
- 양적(quantitative)으로 서술되어야 하며, 측정 가능해야 함
1. 적합한 주기(cadence)를 찾을 것
- 일반적으로 조직의 목표는 1년, 팀의 목표는 3개월 기준으로 잡음
2. 각 목표에 맞는 적당량의 핵심 결과를 설정 할 것
- 일반적으로 1~3개의 목표, 각 목표에 1~3개의 핵심 결과를 잡음
3. 설정한 목표에 대한 진전 사항을 꾸준히 추적할 것
- 일반적으로 주간 단위로 측정
4. 목표는 이루고자 하는 바를 확실하게 포함할 것
- 사소한 업무들도 관리하고자 하는 마이크로 매니징의 목적이 아님
5. 팀원이 설정한 목표에 대해 책임감을 가질 수 있을 것
- 목표를 이루는 것을 실패한다면, 동료끼리 부검(post-mortem, 포스트모템) 혹은 회고(retrospective)를 통해 실패의 이유를 분석해볼 것
6. 설정한 핵심 결과를 측정하는 방법에 대해 합의할 것
- 성과 측정 방법의 일관성은 조직 내의 팀간 신뢰에 중요한 역할을 함
- 일반적으로 0점~1.0점의 척도로 측정
- 0점 = 진척을 이루지 못함 / 0.3점 = 최소한의 요구사항만을 수행 / 0.7점 = 원하는 바를 이룸 / 1.0점 = 엄청난 성과를 거둠
7. 설정한 핵심 결과가 완전한 의무(high-integrity commitments)인 경우, 성과 측정은 수치가 아닌, ‘예’와 ‘아니오’로 측정됨
완전한 의무:
효과적인 사업 성과를 만들어 낼 수 있는 해결책을 구상했을 때, 제품팀은 자신감을 갖고 명료하게 어떻게 그 해결책을 시장에 전달할지, 어떤 성과를 만들어낼 수 있을지, 그리고 언제 그것을 완료할 수 있을지에 대한 것을 다루는 것을 의미함
High-integrity commitments:
Once we have come up with a solution that works for our business, we now can make an informed and high-confidence statement about when we could deliver this, and what type of business results we can expect. We can also decide if it’s even worth doing.
출처: https://www.svpg.com/managing-commitments-in-an-agile-team/
- 완전한 의무가 된 안건(high-integrity commitments)의 경우는 성과를 달성했느냐, 못 했느냐가 중요한 부분
8. 목표를 위해 하고 있는 업무와 진척 사항에 대해 투명할 것
- 조직내 팀간 서로의 진행 상황에 대해 투명하게 공유하며 목표를 이뤄나갈 것
9. 각자 맡은 부분에 대한 목표와 핵심 결과를 효과적으로 설정할 것
- 경영진은 조직의 목표와 핵심 결과를 설정
- CPO와 CTO는 제품의 목표들을 설정
- 각 프로덕트 팀원들은 부여받은 목표를 이루기 위한 핵심 결과를 설정
문제가 발생하는 경우
제품팀 목표
이번 분기는 ABC 기능 출시 목표
UX 디자인 팀장
이번 분기는 반응형 디자인으로 바꾸는 것이 목표
UX 디자인팀의 실무진의 상황
(제품팀 목표) 이번 분기는 ABC 기능 출시 목표
(기능팀 목표) 반응형 디자인으로 변경 완료
(개인적 목표) 디자인 지식 늘리기
'이걸 어떻게 다해...?'
1. 기능적(functional) 단위의 업무의 사업적 성과에 대해 판단할 것
- 많은 회사들은 교차기능(cross-functional)적 업무를 가진 팀원들로 구성되어 있음
- 회사와 제품의 존재 목적은 사업의 문제나 고객의 문제를 푸는 것 → 기능 단위의 업무 수행도 물론 중요하지만, 사업적 성과면에서는 대부분의 경우 중요하지 않음
- 예를 들어, ‘리플랫포밍(replatforming)’ 업무를 받은 엔지니어, ‘반응형 디자인’ 업무를 받은 디자이너, ‘리툴링(retooling)’ 업무를 받은 QA 매니저들의 각 업무는 중요하지만, 이 업무들이 시장에서 사업적으로 큰 성과를 만들 수는 없음
2. 팀원들이 제품 팀의 목표에 집중할 수 있도록 할 것
- 정돈되지 않은 OKR 시스템 내에서 빈번하게 일어나는 문제는, 팀원들이 어디에 시간을 할애해야할 지 혼란스러워하는 것 → 이것이 해결되지 않으면 모든 결과가 파국으로 이어짐
- 이 문제의 근본적인 원인은 팀원들이 ‘기능적이거나 개인적인 차원의 OKR에 휩쓸리는 상황’임
- 기능팀의 OKR이 제품 차원의 OKR과 충돌하거나 기능팀의 OKR이 비대해지는 경우, 리더급들이 논의를 통해 우선순위를 정해 제품팀의 OKR와 관련되도록 정렬 및 정돈할 것
3. 제품팀의 OKR에 대한 신속한 전달(cascading)은 교차기능팀부터 사업부문/전사적 차원으로 빠르고 명확하게 이뤄져야 함
목표는 이루고자 하는 질적인 선언, 핵심 결과는 목표를 이루기 위해 만들어 내야하는 수치적 결과
제품팀 차원의 OKR을 면밀히 만들고, 전사적으로 전파하여 투입할 리소스를 정돈하는 것이 매우 중요