효과적인 지표 관리: 통제 가능한 인풋 지표에 집중하라
인풋 지표를 명확히 정의한 뒤, OKR의 형태로 직원들에게 공유하기
최근 팀 기획 방식을 바꿨다.
AS-IS:
1) PM이 이번 스프린트의 목표를 제시
2) 다같이 회의해서 기획안 정리하기
TO-BE:
1) 스프린트 회고/플래닝 회의에서 스프린트의 목표를 제시, 각 목표별 담당자 확정
2) PM이 각 목표 별 담당자에게 이번 목표의 요구사항을 정리한 문서를 전달
3) 각 목표 별 담당자는 요구사항을 반영한 기획안을 구체화하여 문서로 전달
4) 다같이 피드백, 이후 디자인, 이후 개발
이를 통해, 기존의 문제점들이 해결되었다.
AS-IS:
1) 우리 팀은 말이 많다 — 그래서 다들 말하다보면 회의가 산으로 가기도 …
2) 그렇게 구두로 이야기가 전개되다보니, 다들 머릿속으로 그리고 있는 청사진이 다르기도.
3) 기획안에 누락된 부분이 개발 도중에 발견되어, 스프린트 마감일이 늦어지기도.
TO-BE:
1) 텍스트로 (지난 챕터의 내러티브 기술을 적극 활용함) 전달되니, 핵심 가치를 잊지 않게 됨
2) 기획안 중 실제 구현에 누락된 부분을 빠르게 캐치할 수 있게 됨
하지만 이 방식이 정말로 최선의 해결책이었을까?
이 방식을 통해 1) 작업자들 만족도가 상승했고, 2) 실제로 퍼널 개선도 상당히 많이 이루어졌으며, 3) 문서화의 장점을 만끽했다. 그럼에도 의심하게 된 이유는,
1) 최초 작성자(= PM 본인)의 의견이 너무 많이 반영됨 (우리 팀은 기획에 다들 진심인 초기 창업팀이고 & 다들 본인 의견을 아주 매우 많이 말하며, 그 이야기들을 통해 유의미한 문장들이 쏟아져나온다는 것이 최고의 장점인데도 — 팀원 일부가 요구사항문서&기획안&결과지표해석자료를 보고도 유의미한 회고가 나오지 않는 모습이 보였다.)
2) 문서를 통한 피드백을 실시간 오프라인 미팅을 통해 진행할 수 없었는데, 이 때문에 실제 작업(디자인, 개발 등)이 너무 많이 딜레이됐다.
3) 추가로, 작성하는 과정에서 나는 현재의 요구사항 문서가 정말로 핵심적인 지표를 담아, 작업자에게 전달되고 있는지를 확신할 수 없었다. (명확한 목표지표가 무엇인지-what 보다는, is it right?에 가까운 질문이다.) (목표 달성을 위한 다음 스텝을 어느 수준으로 적어야 하는지)
❏ Solution
현재 부족한 점은 1) 어떤 목표가 좋은 목표인가, 2) 그 목표를 작업자들에게 어떻게 전달해야하는가, 라고 인지했다.
그래서 지난 챕터의 회고에서 추천받았던 [순서 파괴], [OKR]을 레퍼런스로 삼았다. 유명한 책이다보니, 책을 통해 습득한 지식보다는 책을 통해 했던 회고와 이를 통해 수정하게 된 요구사항 전달 방식에 초점을 맞추어 글을 작성했다.
reference 1 | [도서] 순서 파괴: 지구상 가장 스마트한 기업 아마존의 유일한 성공 원칙, 콜린 브라이어,빌 카
6장. 성과지표: 아웃풋이 아닌 인풋을 관리하라
� 스스로 통제할 수 있는 일에 매달릴 것!
① 중요한 것은, 아웃풋 지표(주가)에 결과적으로 영향을 미치는 통제 가능한 인풋 지표, 직접 통제 가능한 활동에 초점을 맞추는 것이다.
1) 통제 가능한 인풋 지표: 고객의 이익을 얼마나 잘 충족시키는지, 그래서 회사가 원하는 방향으로 아웃풋 지표를 창출할 수 있을지 측정하는 정량적이고(=데이터로 깊이 파고들기) 정성적인(= 일화와 고객의 이야기) 방법이다. (*고객들은 아웃풋 지표에 별로 관심을 두지 않는다.)
2) 정확하고 효과적인 지표를 설정하고, 이를 효과적으로 관리하기 위해 아마존은 WBR을 시행한다.
② WBR(weekly business review, 주간 비즈니스 검토)는 아마존에서 지표가 행동으로 옮겨지는 과정이다.
목적은 여느 기업의 회의와 같이, 종합적인 시각에서 비즈니스를 바라보는 것이다. WBR의 라이프사이클은 DMAIC(define, measure, analyze, improve, control) (정의, 측정, 분석, 개선, 통제)이며, 이 사이클을 통해 효과적인 개선을 이루어낸다.
1) D, 정의: 어떤 시스템이든, 개선 전에 인풋이 아웃풋에 어떤 영향을 미치는 지 이해해야 한다.
- 원하는 결과를 얻기 위해 인풋을 변경할 수 있어야 한다.
- 이를 위해서는, 지속적인 노력 & 변함없는 목적 & 지속적인 개선을 운영철학으로 삼아야 한다.
- 플라이휠: 통제 가능한 인풋 지표가 어떻게 하나의 아웃풋 지표를 끌어올리는지를 보여주는 모델 (어느 하나의 요소, 모든 요소에 에너지를 주입할 수록 플라이휠이 더 빨리 회전한다.)
- 인풋 지표를 잘못 고르면 아웃풋 지표에 아무 변화가 없다. (ex, 신규 상세 페이지 — 를 인풋 지표로, 판매라는 아웃풋 지표를 늘리고자 했으나, 상세 페이지 증가를 위해 신규 제조업체와 관계를 맺고, 재고를 사들이고, 페이지를 추가하는 작업에만 몰두하게 된다.)
- 시행착오는 지표 선정 과정에서의 필수요소다. (더 많은 데이터를 수집하고 비즈니스를 면밀히 관찰해애함.)
2) M, 측정: 지표 수집 과정을 정의하는 것 역시 중요하다. 같은 지표도 고객 경험을 고려하여 설정한다면, 고객으로부터 출발하는 워킹 백워드를 실천하여 더욱 효과적인 개선을 이루어낼 수 있다.
3) A, 분석: 데이터 잡음 속에서 신호를 분리하고, 근본 원인 규명하고 대처하는 과정이다. (COE, cause of errror: 오류를 가진 팀이 그 설명문을 작성, 이후 5번은 왜 — 를 물어본다.)
4) I, 개선: 앞에서 찾은 잡음이 아니라, 신호에 대응하기
5) C, 통제
많은 팀이 DMA를 패스하고, IC로 넘어가려 했다. 이 경우, 그래프 상 일시적인 변화를 쫒아가느라 노력 대비 별다른 소득을 얻지 못할 수 있다. 저자는 진짜 신호를 찾는 것을 강조한다.
reference 2 | [도서] OKR 전설적인 벤처투자자가 구글에 전해준 성공 방식, 존 도어
OKR : Objective Key Result
1) OKR은 목표(=O)를 성취하고/정의하는(=KR) 방식이다.
2) OKR은 무엇(=what)을 원하고 & 어떻게(=why) 얻을지에 관한 것이다.
3) OKR은 상향식 + 수평식이다.
만일 하향식이라면?
(+) 명료하다.
(- ) 임원들은 구체적인 전술을 알지 못한다. 임원의 KR이 작업자의 O가 되는 구조가 그들에게 동기부여를 제대로 해주지 못할 수 있다. ‘직원들은 자신의 목표가 기업 사명과 어떻게 연결되어 있는지 이해하길 원한다.’, ‘말하기가 싫증날 즈음에 직원들은 귀를 기울이기 시작한다.’
(- ) 목표가 수정되기 어렵다. 애초의 취지(= KR)가 사라지고, 실행(= what에 집중할 수 없다는 뜻)은 정체된다.
OKR을 선택하는 과정에서, 탁월한 성과와 밀접하게 관련되는 목표의 우선순위를 높인다. (팀 → 기업으로 격상시키는 등)
4) OKR은 모두 같은 목적지를 바라보게 한다.
5) OKR은 도전적이어야 한다.
1) O 1개 당, KR은 3–5개 (per week) 로 제한한다. 모든 KR의 완성은 곧 O의 달성이다.
2) 구글은 평균 40%는 실패한다. 그렇다 해도 실패로 여기지 않는다!
- 반드시 달성해야할 목표(필수적인 OKR)
- 크고 위험하고 대담한 목표(도전적인 OKR)를 구분하자.
3) ‘마이크로매니지먼트는 곧 미스매니지먼트다.’
- 엄격한 성과기준 + 높은 목표 수준을 제시하고, 업무 방식은 자율에 맡기며, 각 구성원 모두 각각의 OKR을 적게 하고 이 목표를 전 사원에게 공개한다.
6) OKR은 받아들이는 데에 오래 걸린다. 4–5분기 정도는 예상하길!
❏ Retrospect
Keep
✔︎ 01 어떤 목표가 좋은 목표인가
아웃풋 지표에 집중하지 않고, 실제 사용자의 움직임을 통해 조정가능한 인풋 지표를 잡을 것.
O — KR로 나누어 작업자들에게 더 명료하게 전달할 것. 상위 KR이 작업자들의 O가 된다는 점을 요구사항으로 전달. (그 KR이 어떤 경로로 나왔는지를 작업자들에게 잘 설명하는 것이 PM의 역량이 아닐까?)
︎ ︎ ︎︎︎✔︎ 엄청나게 많은 사례집…!
공감도 되고, 혼나기도 하고, 인사이트도 얻게 되는 것 같다.
Problem
올바른 인풋 지표를 찾기 위해서는 정말 잘 들여다보는수밖에 없어보인다.
실무 팁이 많다기보다는, 그냥 읽으면서 많이 반성하고 생각하게 됨 (다양한 사례들을 통해)
Try
O = 아웃풋 지표, KR = 인풋 지표로 생각해도 될 것 같다. 기존의 O는 스프린트/스토리 네이밍, KR은 인수조건으로 치환가능해보인다.
최상위 O에 대해 작업자들과 이야기하는 시간을 가지고, 이를 기반으로 KR을 구체화하는 것을 PM의 작업으로 두는 것은 어떨까? 그 KR을 O로 가지는 작업자들이 생각한 그들의 KR을 미리 적게 하고, 이를 기반으로 실제 행동 = 기획안을 적도록 하면 기획안을 피드백하는 모두가 같은 비전을 가지고 기획안을 평가할 수 있을 것 같다.
(이 글은 SW마에스트로 14기 수료생들과 함께 운영하는 PO Chapter에서 공유한 내용이며, 2024.09.16. 에 Medium에서 작성된 글임을 밝힙니다.)
