1장 — 서론 (Introduction)

원문: Introduction — Shape Up

한 줄 요약

Shape Up은 Basecamp의 제품 개발 방식으로, 6주 사이클·사전 셰이핑(shaping)·소규모 팀 전권 위임이라는 세 축이 선순환을 이루며 “제때 출시하지 못하는 리스크”를 매 단계에서 제거한다.

핵심 내용

성장통 (Growing pains)

소프트웨어 팀이 커지면 공통 증상이 나타난다. 프로젝트가 끝없이 늘어지고, 프로덕트 매니저는 전략을 생각할 시간이 없으며, 창업자는 “왜 초창기처럼 기능을 빨리 못 내지?”라고 묻게 된다. Basecamp도 4명에서 50명 이상으로 크며 똑같이 겪었다. 2003년 첫 버전은 프로그래머(DHH)가 주당 10시간만 일하는 제약 속에서 만들어졌고, 그 제약이 “정해진 시간 예산에 스코프를 두드려 맞추는(hammering)” 습관을 낳았다. 2009년 4개 제품의 스위트 통합, 2012년 Basecamp 2.0 전면 재설계에서 breadboarding과 scope mapping 기법이 검증됐고, 2015년 제품 팀이 4배로 커지고 전원 원격이 되자 직관을 전수할 언어와 구조가 필요해졌다. 이때 반복 사이클로 전환하고 피칭·베팅 프로세스를 공식화했으며, 베팅 전에 경계를 긋고 리스크를 줄이는 사전 디자인 작업을 가리키는 “셰이핑(shaping)“이라는 말이 생겼다.

6주 사이클 (Six-week cycles)

6주는 의미 있는 것을 처음부터 끝까지 만들 만큼 길고, 시작부터 마감을 체감할 만큼 짧다. 신기능 대부분이 한 사이클 안에 만들어져 출시된다. 시간을 세거나 하루 단위를 따지지 않고, 데일리 미팅도 없고, 2주마다 로드맵을 다시 짜지도 않는다. “이 프로젝트가 6주 뒤에 나가면 정말 기쁘겠다” 싶으면 6주를 커밋하고 팀을 내버려 둔다.

일을 셰이핑하기 (Shaping the work)

소수의 시니어 그룹이 사이클 팀과 병렬로 움직이며, 베팅할 만한 프로젝트가 되기 전에 해법의 핵심 요소를 정의한다. 프로젝트는 팀이 뭘 할지 알 만큼 구체적이면서, 흥미로운 세부는 스스로 풀 여지가 있을 만큼 추상적인 수준으로 정의된다. 셰이핑에서는 견적(estimate)보다 식욕(appetite)에 집중한다 — “얼마나 걸릴까?”가 아니라 “얼마나 쓰고 싶은가? 이 아이디어는 그만한 가치가 있는가?”를 묻고, 그 제약 안에 들어가도록 문제를 좁히고 해법의 윤곽을 설계한다.

팀에 책임을 맡기기 (Making teams responsible)

디자이너와 프로그래머로 구성된 작은 통합 팀에 전적인 책임을 준다. 팀이 스스로 태스크를 정의하고 스코프를 조정하며 제품의 수직 조각을 하나씩 만든다. 매니저가 일을 쪼개고 프로그래머가 티켓을 받아가는 방식과 정반대다. 팀이 자율적일수록 시니어의 관리 시간이 줄고, 그 시간으로 더 나은 셰이핑을 하며, 잘 셰이핑된 프로젝트는 경계가 명확해 팀이 더 자율적으로 일한다 — 선순환이다.

리스크 겨냥 (Targeting risk)

이 책은 “잘못된 것을 만드는 리스크”가 아니라 “제때 출시하지 못하고 발이 묶이는 리스크”를 다룬다. 세계 최고의 전략도 실행하지 못하면 소용없다. 셰이핑에서는 rabbit hole과 얽힌 의존성을 베팅 전에 제거하고, 플래닝에서는 베팅을 6주로 상한한다 — 기한을 넘기면 기본적으로 연장이 없는 “서킷 브레이커”로, 재고가 필요한 컨셉에 원래 식욕의 몇 배를 쏟는 일을 막는다. 빌딩에서는 디자인과 프로그래밍을 초기부터 통합해, 가장 불확실한 조각부터 하나의 의미 있는 조각을 끝까지 만들어 보며 배운다.

책의 구성

1부 셰이핑(스케줄 전 사전 작업 — appetite 설정, 해법 스케치, 피치 작성), 2부 베팅(피치 중 무엇을 6주 단위로 할지 선택), 3부 빌딩(팀에 거는 기대와 실행 관행), 부록(첫 6주 실험, 회사 규모별 조정, Basecamp로 구현하기).

실무 포인트

• “얼마나 걸릴까” 대신 “이 아이디어에 얼마나 쓰고 싶은가”(appetite)부터 묻는다
• 프로젝트 정의는 구체성과 추상성의 중간 — 뭘 만들지는 명확히, 어떻게는 팀에 맡긴다
• 사이클을 커밋했으면 중간에 시간 사용을 캐묻지 말고 팀을 내버려 둔다
• 기한을 넘긴 프로젝트는 기본 연장 없음(서킷 브레이커) — 연장 대신 재셰이핑을 검토한다
• 부품을 따로 만들어 막판에 조립하지 말고, 불확실한 것부터 끝까지 통합된 조각을 만든다