10장 — 책임을 통째로 넘겨라 (Hand Over Responsibility)
원문: Hand Over Responsibility — Shape Up
한 줄 요약
섹션 제목: “한 줄 요약”베팅이 끝나면 팀에게 태스크 목록이 아니라 프로젝트 전체를 넘긴다. done은 배포(deployed)를 뜻하고, 팀은 실제 작업을 하면서 스스로 태스크를 발견해 나간다.
핵심 내용
섹션 제목: “핵심 내용”태스크가 아니라 프로젝트를 배정한다 (Assign projects, not tasks)
섹션 제목: “태스크가 아니라 프로젝트를 배정한다 (Assign projects, not tasks)”프로젝트를 시작할 때 누군가가 태스크마스터나 아키텍트 역할을 맡아 일을 잘게 쪼개 나눠주지 않는다. 프로젝트를 미리 태스크로 분해하는 것은 피치(pitch)를 파쇄기에 넣는 것과 같다 — 모두가 서로 연결되지 않은 조각만 받게 되고 큰 그림을 잃는다. 대신 팀이 피치의 경계 안에서 프로젝트 전체를 맡는다. 태스크 정의와 접근 방식은 팀이 스스로 정한다.
이렇게 하는 이유는 두 가지다. 첫째, 유능한 사람들은 티켓 처리 기계 취급을 싫어하고 재량이 있을 때 더 잘 일한다. 둘째, 프로젝트 시작 시점에는 조각들이 제대로 맞물리려면 정확히 무엇이 필요한지 아무도 예측할 수 없다. 종이 위의 계획은 실제로는 그대로 작동하지 않으며, 실무를 하는 디자이너와 프로그래머가 조정하고 빠진 조각을 발견하기에 가장 좋은 위치에 있다. 각자 작은 조각만 배정받으면 전체가 어떻게 맞물리는지 판단할 책임감을 아무도 느끼지 않게 된다.
단, 백지 위임이 아니다. 셰이핑으로 경계는 이미 정해져 있고, 팀은 그 윤곽 안을 실제 디자인 결정과 구현으로 채운다.
done은 배포를 뜻한다 (Done means deployed)
섹션 제목: “done은 배포를 뜻한다 (Done means deployed)”사이클이 끝날 때 팀은 작업을 배포한다. 이 제약이 베팅과 서킷 브레이커(circuit breaker)를 유효하게 만든다 — 예산한 시간 안에 끝나지 않으면 애피타이트(appetite)와 예산이 무의미해진다. 따라서 테스트와 QA도 사이클 안에서 끝나야 하며, 팀은 핵심 부분을 먼저 스코프로 잘라 일찍 끝내고 QA와 조율한다. 반면 도움말 문서, 마케팅 업데이트, 고객 공지는 리스크 꼬리가 짧아(예상의 5배로 늘어지는 일이 없어) 사이클 안에 강제하지 않고, 보통 쿨다운(cool-down) 기간에 처리한다.
킥오프 (Kick-off)
섹션 제목: “킥오프 (Kick-off)”프로젝트용 Basecamp 프로젝트를 만들고 팀을 초대한 뒤, 셰이핑된 콘셉트(원본 피치 또는 요약본)를 가장 먼저 게시한다. 이어 킥오프 콜을 잡아 글로는 불분명한 질문을 해소하고, 팀은 대략적인 이해를 갖고 출발한다.
방향 잡기 (Getting oriented)
섹션 제목: “방향 잡기 (Getting oriented)”처음 며칠은 겉보기에 일처럼 보이지 않는다. 체크되는 태스크도, 배포되는 것도, 산출물도 없고 팀 내 소통조차 뜸한 침묵기가 온다. 각자 기존 시스템이 어떻게 동작하는지, 어디서 시작하는 게 최선인지 파악하느라 몰두하는 시기이기 때문이다. 관리자는 이 단계를 존중해야 한다. 너무 일찍 진행 상황을 물으면 팀이 최선의 접근을 찾는 시간을 빼앗고, 탐색을 지하로 숨게 만들 뿐이다. 팀이 아직 시작점을 찾는 중이라고 떳떳하게 말할 수 있게 하는 편이 낫다. 다만 침묵이 3일이 지나도 깨지지 않으면 그때는 개입해 확인해 볼 만하다.
상상한 태스크 vs 발견한 태스크 (Imagined vs discovered tasks)
섹션 제목: “상상한 태스크 vs 발견한 태스크 (Imagined vs discovered tasks)”팀은 처음에 머리로 상상한 태스크(imagined tasks)로 출발하지만, 실제 작업에 손을 대면서 미리 알 수 없던 태스크들을 발견(discovered tasks)한다. 이 예상 밖의 디테일이 프로젝트의 진짜 몸통이고 가장 어려운 과제인 경우가 많다. 데스크톱에 버튼을 추가하니 모바일 웹뷰에 놓을 자리가 없다는 걸 알게 되거나, 마이그레이션 작업 중에 나중에 고쳐야 할 메서드를 발견하는 식이다. 무엇을 해야 하는지 진짜로 알아내는 방법은 실제 작업을 시작하는 것이다. 그렇다고 아무거나 만드는 게 아니라, 프로젝트의 중심이면서도 며칠 안에 UI와 코드가 함께 동작하는 상태로 끝낼 수 있을 만큼 작은 것을 골라야 한다.
실무 포인트
섹션 제목: “실무 포인트”- 팀에 태스크 목록이 아니라 피치와 경계를 넘기고, 태스크 분해는 팀이 직접 하게 한다.
- done의 정의를 배포로 못 박고, QA·테스트를 사이클 안에 배치한다.
- 킥오프에서 셰이핑 문서를 먼저 공유하고 질문을 해소한 뒤 시작한다.
- 시작 후 첫 2-3일의 침묵(탐색기)에는 상태 보고를 요구하지 않는다. 3일이 지나도 침묵이면 그때 확인한다.
- 첫 작업 대상은 중심적이면서 며칠 안에 끝낼 수 있는 작은 조각으로 고른다.