15장 — 다음으로 넘어가라 (Move On)

원문: Move On — Shape Up

한 줄 요약

출시(ship)는 새 요청과 반발을 낳는다. 폭풍이 지나가게 두고, 피드백에 “예”라고 약속해 부채를 지는 대신 셰이핑을 거쳐 다음 베팅 테이블에서 다른 안건들과 경쟁하게 한다.

핵심 내용

폭풍이 지나가게 하라 (Let the storm pass)

조심하지 않으면 출시가 오히려 새 일거리를 만든다. 기능 출시는 기능 요청을 낳는다 — “좋네요, 그런데 우리가 요청했던 그건요?” 버그가 나오고 개선 제안이 들어오고, 모두가 새것에 반응한다. 기존 워크플로를 바꾸는 출시라면 피드백이 특히 격해질 수 있고, 순수한 비주얼 변경조차 “망쳤어요! 되돌려요!” 같은 소수 고객의 과잉 반응을 부르기도 한다. 냉정을 유지하고 무릎반사식 대응을 피하라. 며칠 시간을 주고 가라앉게 두고, 애초에 왜 이 변경을 했고 누구를 돕는 변경인지 기억하며 단호하게 버틴다.

부채 없이 지내라 (Stay debt-free)

피드백에 대응해 변경을 약속하고 싶어지지만, 그러면 다음 사이클의 깨끗한 출발선이 사라진다. 들어오는 것들은 아직 가공되지 않은 날 아이디어일 뿐이다. 다루는 방법은 부드러운 “no”다. “no”라고 해도 계속 숙고하다가 미래 프로젝트로 셰이핑하는 것을 막지 않지만, “yes”는 미래의 자유를 빼앗는다 — 빚을 지는 것과 같다. 방금 출시한 것은 6주짜리 베팅이었다. 이 부분에 시간이 더 필요하다면 새 베팅이 필요하다. 방금 나온 요청과 버그는 다음 베팅 테이블에서 다른 모든 안건과 경쟁시켜 전략적으로 중요한지 확인한다.

피드백도 셰이핑이 필요하다 (Feedback needs to be shaped)

여기서 프로세스가 한 바퀴 돈다. 고객 피드백으로 들어온 날 아이디어는 아직 실행 가능하지 않다 — 셰이핑이 필요하다. 이것들이 곧 셰이핑 1단계(경계 설정, Set Boundaries)에서 말한 원료 입력이다. 정말 중요한 요청이라면 다음 사이클의 셰이핑 트랙에서 최우선으로 다루면 된다. 그 6주 동안 팀은 다른 것을 빌드하게 베팅하고, 그 시간에 새 아이디어를 제대로 셰이핑한 뒤 베팅 테이블에서 셰이핑된 버전을 올려 성공 확률을 최대로 만든다.

실무 포인트

• 출시 직후 며칠은 반발·요청에 즉각 대응하지 않고 폭풍이 가라앉기를 기다린다.
• 들어오는 요청에는 기본값으로 부드러운 no — 즉석 약속(yes)은 미래의 부채다.
• 후속 작업이 필요하면 자동 연장이 아니라 새 베팅으로 취급해 베팅 테이블에서 경쟁시킨다.
• 중요한 피드백은 다음 사이클의 셰이핑 트랙에 올려 셰이핑을 거친 뒤 베팅한다.