3장 — 경계 정하기 (Set Boundaries)

원문: Set Boundaries — Shape Up

한 줄 요약

해법을 논하기 전에 이 아이디어가 우리 시간을 얼마나 받을 자격이 있는지(appetite)를 먼저 정하고, “무엇을 만들까”가 아니라 “정확히 무엇이 잘못되고 있나”로 문제를 좁혀야 생산적인 셰이핑이 가능하다.

핵심 내용

식욕 설정 (Setting the appetite)

모든 기능 논의는 “고객이 그룹 알림을 요청한다” 같은 날것의 아이디어(raw idea)에서 시작한다. 신나는 아이디어든 내키지 않는 요청이든, 해법 논의로 빠지기 전에 이 주제가 우리의 시간과 관심을 얼마나 받을 자격이 있는지 명시적으로 정한다. 이것이 appetite(식욕)이며, 표준 팀 규모 기준의 시간 예산이다. 보통 두 크기로 정한다: Small Batch — 디자이너 1명 + 프로그래머 1-2명이 1-2주에 만드는 프로젝트(여러 개를 한 사이클에 묶는다), Big Batch — 같은 팀이 6주를 꽉 채우는 프로젝트. 6주로도 안 되는 큰 스코프는 문제 정의를 좁혀 두드려 줄이고, 그래도 안 되면 6주 식욕으로 셰이핑할 수 있는 의미 있는 일부를 떼어낸다.

고정 시간, 가변 스코프 (Fixed time, variable scope)

appetite는 견적(estimate)과 완전히 다르다. 견적은 디자인에서 시작해 숫자로 끝나고, appetite는 숫자에서 시작해 디자인으로 끝난다. appetite는 디자인 과정의 창의적 제약이다. 저자는 이 책 자체를 예로 든다 — 마감 일주일 전, 오타 수정과 새 섹션 추가 중 하나를 골라야 한다면 스코프를 줄여(섹션 포기) 품질을 지킨다. 고정 마감이 없으면 이런 트레이드오프 자체를 하지 않게 된다. 이 원칙은 셰이핑부터 빌드·출시까지 전 단계에 적용된다.

좋음은 상대적이다

절대적인 “최선의 해법”은 없다. 최선은 제약에 상대적이다. 시간 제한이 없으면 언제나 더 나은 버전이 존재한다. 최고의 식사는 열 코스 정찬일 수 있지만, 배고프고 바쁠 땐 핫도그가 완벽하다. 얼마나 시간을 쓰고 싶은지, 얼마나 중요한지의 맥락 안에서만 “좋은” 해법을 판단할 수 있다.

날것의 아이디어에 응답하기

들어오는 아이디어에 대한 기본 응답은 “흥미롭네요. 언젠가는요(Interesting. Maybe some day)” — 모든 옵션을 열어 두는 아주 부드러운 거절이다. 백로그에 넣지 않고, 정말 중요한지 스스로 드러날 시간을 준다. 첫 접촉에서 yes/no를 말하기엔 이르다. 매번 yes라고 하면 일 더미만 자라고, 반대로 이해 못 한 아이디어를 성급히 차단해서도 안 된다. 지나친 열의는 “된다”는 기대를 심어버리므로 포커페이스를 유지한다.

문제 좁히기 (Narrow down the problem)

appetite와 함께 문제의 이해도 좁혀야 한다. 복잡한 권한 규칙을 요청한 고객 사례: 요청을 액면대로 받으면 6주짜리지만, 파고들자 실제 문제는 파일 아카이브가 다른 사용자에게도 사라지는 걸 몰랐다는 것 — 아카이브 액션에 경고 문구를 붙이는 하루짜리 변경으로 해결됐다. “무엇을 만들 수 있나”에서 “정확히 무엇이 잘못되고 있나”로 질문을 뒤집는다.

사례: 캘린더 정의하기

캘린더를 요청한 고객에게 왜, 어떤 모습을 원하는지가 아니라 언제 캘린더가 필요했는지 물었다. 사무실 칠판 벽 캘린더에 회의실 예약을 적어 두는데, 재택 중 고객 전화를 받고 빈 시간대를 확인하러 차를 몰고 사무실까지 가야 했다는 이야기였다. 교훈은 “캘린더를 전산화하자”가 아니라, 이 사용 사례의 핵심이 “빈 자리 보기(see free spaces)“라는 것. “캘린더가 하는 모든 것”에서 “언제 잡을지 알 수 있게 빈 자리를 보여 달라”로 좁혔고, 이것이 Dot Grid 컨셉으로 이어졌다. 구체적 페인포인트를 못 찾겠으면? appetite가 리서치에 쓸 가치도 알려 준다 — 지금 급하지 않으면 걸어 나와 다른 일을 한다.

grab-bag을 조심하라

가장 나쁜 것은 단일 문제나 사용 사례 없이 추진되는 “리디자인”이나 “리팩토링”이다. “Files 섹션을 리디자인하자”는 프로젝트가 아니라 잡동사니 주머니(grab-bag)다 — 어디서 시작하고 끝나는지 알 수 없다. “여러 파일 공유에 단계가 너무 많아서 Files 섹션을 다시 생각해야 한다”가 생산적인 출발점이다. 전형적 징후는 “2.0” 라벨. Basecamp도 “Files 2.0”을 저질렀다가 “done”이 뭔지 몰라 엉망이 됐고, “더 나은 파일 미리보기”, “커스텀 폴더 색상” 같은 작은 프로젝트로 쪼개 각각 appetite를 정해서야 수습했다.

경계 완성

날것의 아이디어 + appetite + 좁혀진 문제 정의, 세 가지가 갖춰지면 해법의 요소를 정의하는 다음 단계로 넘어간다.

실무 포인트

• 해법 논의 전에 appetite부터 선언한다 — Small Batch(1-2주)인가 Big Batch(6주)인가
• 견적을 묻지 말고 “이 문제에 얼마를 쓸 가치가 있나”를 묻는다
• 새 요청의 기본 응답은 “흥미롭네요, 언젠가는” — 백로그에 넣지 않는다
• 기능 요청은 액면대로 받지 말고 “언제 그게 필요했나”로 실제 붕괴 지점을 찾는다
• “리디자인”, “2.0” 류 grab-bag은 단일 문제 단위의 작은 프로젝트로 쪼갠다