13장 — 진행 상황을 보여줘라 (Show Progress)

한 줄 요약

일은 언덕과 같다 — 접근법을 알아내는 오르막(uphill)과 실행하는 내리막(downhill). 힐 차트(hill chart)에 스코프들을 올려놓으면 관리자가 상태를 묻지 않고도 무엇이 움직이고 무엇이 막혔는지 볼 수 있다.

핵심 내용

거기 없는 태스크들 (The tasks that aren’t there)

투두 리스트로는 상태를 판단할 수 없다. 미완료 항목이 없는 리스트는 다 끝났다는 뜻일 수도, 아직 태스크를 발견하지 못했다는 뜻일 수도 있다. QA를 돌리면 끝났던 스코프에 새 태스크가 채워지기도 한다. 상상한 태스크 vs 발견한 태스크의 원리대로 실제 투두 리스트는 진척할수록 오히려 자라며, 밖에서는 남은 태스크 수가 줄어들지 늘어날지 알 방법이 없다.

추정치는 불확실성을 보여주지 못한다 (Estimates don’t show uncertainty)

둘 다 4시간짜리로 추정된 두 태스크가 있어도, 하나는 열 번 해본 일이라 확실하고 다른 하나는 처음 해보는 일이라 잘 풀리면 4시간, 미지수가 터지면 2-3일이 될 수 있다. 4시간 혹은 3일이라는 추정치는 무의미하다. 그래서 무엇이 done인가 대신 무엇이 미지(unknown)이고 무엇이 해결(solved)됐는가로 초점을 옮긴다. 그 도구가 언덕의 은유다.

일은 언덕과 같다 (Work is like a hill)

모든 일에는 두 단계가 있다. 접근법을 알아내는 오르막과, 해야 할 일이 다 보인 뒤 실행하는 내리막이다. 저녁 파티 준비로 비유하면, 무슨 요리를 할지 모르는 상태는 언덕 왼쪽 아래다. 인도 요리로 좁혔지만 레시피가 없는 상태에서는 몇 퍼센트 완료냐는 질문 자체가 성립하지 않고 시간 추정도 불가능하다. 레시피를 정하고 장보기 목록을 만들면 이제 뭘 해야 할지 안다로 느낌이 바뀐다 — 언덕 꼭대기다. 남은 단계가 다 보이고 추정도 타당해지며, 장보기·요리·정리로 내려가며 일이 끝난다. 오르막은 불확실성·미지·문제 해결의 구간, 내리막은 확신·전체 조망의 구간이다.

언덕 위의 스코프들 (Scopes on the hill)

언덕과 스코프를 결합한다. 스코프가 프로젝트의 언어(Locate, Reply)를 주고, 언덕이 각 스코프의 상태(uphill, downhill)를 말해준다. 스코프마다 색이 다른 점으로 언덕 위에 찍으면 어떤 스코프에 미지수가 남았고 어떤 스코프가 완성에 가까운지 한눈에 보인다.

묻지 않고 보는 상태 (Status without asking)

팀원들은 자기 맥락을 바탕으로 점을 끌어다 놓고 업데이트를 기록한다. 관리자에게 킬러 기능은 과거 상태와의 비교다 — 일이 어디 있는지만이 아니라 어떻게 움직이는지가 보여, 무엇이 진행 중이고 무엇이 막혔는지 판단할 수 있다. 프로젝트가 불안할 때 팀을 방해하며 묻는 대신 이 리포트를 먼저 보고, 이상한 지점이 있으면 그 작업에 대해서만 바로 대화하면 된다(“Autosave가 오르막에 오래 있네요. 발목 잡는 미지수가 뭔가요?”).

아무도 모르겠다고 말하지 않는다 (Nobody says I don’t know)

이 문제를 어떻게 풀지 모르겠다고 경영진에 손들고 싶은 사람은 없다. 그래서 팀은 불확실성을 숨기고 리스크를 쌓는다. 누군가 막혀서 제자리를 도는 순간이야말로 가장 큰 리스크와 기회가 있는 지점이고, 일찍 잡으면 시니어의 도움이나 콘셉트 재작업으로 대응할 수 있다. 힐 차트에서는 움직이지 않는 점이 곧 올라간 손이다 — 말하지 않아도 뭔가 이상할 수 있음이 보인다. 그리고 오르막/내리막의 언어 덕분에 대화가 사람(막혔네요!)이 아니라 일(무엇을 풀면 언덕을 넘을까?)에 대한 것이 된다.

스코프 재분할의 신호 (Prompts to refactor the scopes)

막힌 것처럼 보이는 스코프를 파보면 실제로는 경계가 잘못 그려진 경우가 있다. 오래 멈춰 있던 Notify 스코프는 알고 보니 이메일 디자인, 백엔드 발송, 인앱 표시라는 진행도가 다른 세 부분의 묶음이었다. 해법은 독립적으로 움직일 수 있는 작은 스코프들로 쪼개는 것 — 분리하면 각 점이 따로 움직여 더 자주 진척을 보여줄 수 있다.

오르막은 손으로 지어 올려라 (Build your way uphill)

스코프를 꼭대기에 올렸다가 미지수를 만나 뒤로 미끄러지는 백슬라이딩은 오르막 작업을 손이 아니라 머리로만 했을 때 생긴다. “그 API 쓰면 되지”라는 이론은 첫걸음일 뿐이다. 오르막의 첫 3분의 1은 생각해 봤다, 둘째는 접근법을 검증했다, 마지막은 만들어 본 결과 다른 미지수는 없다고 믿는다로 여기는 것이 좋다.

올바른 순서로 풀어라 (Solve in the right sequence)

힐 차트는 풀 순서를 정하는 데도 쓰인다. 시간이 모자랄 때 금방 해치울 수 있는 스코프와 생각보다 어려울 수 있는 스코프를 가려, 가장 무서운 작업을 먼저 언덕 위로 올린다. 오르막을 넘기면 거기 두고 마무리 조이기는 나중으로 미룬다. 일은 주어진 시간을 채우도록 팽창한다 — 이메일 템플릿은 몇 주든 다듬을 수 있지만 마지막 주에 하루면 충분한 버전이 있고, 처음 해보는 지오코딩은 사이클 말미에 터지면 안 된다. 기자들의 역피라미드처럼 미지수가 많은 중요한 문제를 먼저 꼭대기에 올리고 일상적인 일을 마지막에 남기면, 사이클 끝에는 중요한 것들이 끝나 있고 nice-to-have만 남는다.

실무 포인트

상태 보고를 태스크 완료율이나 시간 추정이 아니라 스코프별 힐 차트 위치로 한다.
오래 안 움직이는 점을 올라간 손으로 간주하고, 사람 아닌 일 중심으로 개입한다.
점이 멈춘 스코프는 실제로는 여러 스코프의 묶음이 아닌지 의심하고 쪼갠다.
검증 없이 머리로만 스코프를 꼭대기에 올리지 않는다 — 만들어 봐야 오르막을 넘은 것이다.
가장 미지수가 많고 무서운 스코프를 먼저 언덕 위로 올리고, 루틴한 일은 뒤로 미룬다.