study Shape 예시 - Basecamp의 캘린더 기능 캘린더 기능 추가을 만들어달라는 고객요청이 많았음 제대로 된 캘린더를 만드려면 6달정도의 시간이 소요됨. 우리는 6주의 시간만 들여 고객의 문제를 해결하고 싶었음. 그래서 캘린더가 고객에게 전달해야 할 핵심가치에 집중하기로 함. 고객은 캘린더를 통해, 일정을 쉽게 확인할 수 있기를 원함 고객이 원하는 핵심 기능은 ‘Dot Grid’라는 결론 도달 2달치 달력만 보이는 읽기전용 캘린더를 고안. 이벤트는 날짜 밑에 점으로만 표시 그 외 캘린더로서의 기능은 모두 무시
to shaping 1. 경계를 정한다 (Set Boundaries) 2. 필수요소들을 다듬는다 (Rough out the elements) 3. 리스크를 파악한다 (Address risks and rabbit holes) 4. 피치를 작성한다 (Write the pitch)
Boundaries 멀리서 보기(포커페이스 유지) 아이디어가 나왔을 때, 잠깐 멈춰서 이 아이디어가 얼마나 가치 있는지 생각하자. - 너무 빨리 아이디어를 실행하면, 자칫 리소스를 낭비할 수 있다. - 너무 솔루션을 길게 생각하면 쓸모없는 아이디어에 너무 긴 논의 할 수 있다. appetite: 아이디어가 어느정도 가치가 있는지 판단하는 기준 appetite는 팀의 시간 리소스로 생각할 수 있으며 두 가지 크기로 설정한다. small batch(1~2주짜리 프로젝트)
“Estimates start with a design and end with a number. Appetites start with a number and end with a design” Shaping - Set Boundaries 일자를 먼저 정하고, 그 안에서 할 수 있는 일의 범위를 정하는 것 장점 1. 설계하는 솔루션의 종류를 제한한다. 2. 고정시간은 팀에게 정말 중요한것과 불필요한 것을 걸러내는 것을 강요할 수 있다. 절대적인 best solution은 없다. 여러개의 상대적인 good 만 있을 뿐.. 우리는 시간제약을 걸어 더 나은 ‘good’을 찾을 수 있다.
the Elements BreadBoarding - Place: 화면, 대화 상자, 팝업 메뉴 같은 탐색할 수 있는 항목 - Affordance: 사용자가 작업할 수 있는 항목(버튼이나 필드 등) - Connection Line: 어포던스로 사용자가 이동하는 것 Place Affordance Connection Line
and Rabbit Holes 토끼굴 찾는법 - 빠진 부분이 없는지 사용자 경험을 처음부터 끝까지 따라가본다. - 처음 해보는 기술적일인지 자문해본다. - 미리 내려야 할 결정이 없는지 자문해본다. - 포함하지 않을 범위를 명시하고 발라낸다. - 엔지니어들에게 의견을 구한다. - 구체적인 피피티나 문서보단, 화이트보드로 컨셉을 공유 - “X를 할 수 있습니까?” 라고 묻지 말고 “6주 안에 가능합니까?” 라고 물어보자 - 아이디어의 가능성이 아니라 위험요소를 찾고 있다는 점을 강조하자 - “ we’re really hunting for time bombs that might blow up the project once it’s committed to a team.”
Not Backlogs No Backlogs - 백로그는 시간낭비다. - 백로그에 쌓인 수많은 일들을 다 할 수 없다는 걸 모두가 안다. - 백로그에 일이 쌓이면 항상 뒤쳐진다는 느낌을 받게 된다. - 오래된 아이디어를 다시 검토하고, 정리하는데 소요되는 시간은 지금 당장 중요하고 적절한 프로젝트를 진행하는데 방해가 된다.
Not Backlogs Betting table 잘 shaped된 피치 몇 개만 가지고 와, 그 중에서 다음 6주동안 할 일을 고른다. 베팅된 일을 진행하고, 선택받지 못한 피치는 하지 않는다. 꼭 해야 한다면 다음 베팅 테이블 때 다시 제안한다. “Important ideas come back” 아이디어는 과대평가하기 쉽다. 하지만 사실 아이디어는 값싸다. 정말 중요한 아이디어라면 다시 나온다. 한번 듣고 백로그로 가는 아이디어는 별로 중요한 문제가 아닐 수 있다.
Betting Table 6주 주기 프로젝트 사이클 프로젝트 계획이 캘린더 테트리스가 되지 않도록, 표준 프로젝트 크기를 제공해야 한다. 왜 6주인가? - 의미 있는 일을 하기에 2주(스프린트)는 너무 짧다. 플래닝 오버헤드 대비 2주동안 해내는 성과는 그다지 많지 않다. - 실험을 거쳐, 프로젝트를 마무리하기까지 충분히 길면서 데드라인이 적절히 쪼아줄 수 있는 주기가 6주라고 결론지었다.
Betting Table Cool-down 6주 주기 후에 2주의 쿨다운 기간을 갖는다. 이 때는 팀원들이 원하는 어떤일이든 해도 좋다. 버그를 고치거나, 기술을 공부하는 등 자신이 통제할 수 있는 시간을 즐긴다. 쿨다운 기간에 다음 6주 주기에 어떤 일을 진행할지 결정하는 Betting이 진행된다.
Betting Table 베팅의 의미 1. 모든 베팅에는 지불금이 있다. 우리의 경우엔 6주라는 시간이다. 2. 베팅은 약속이다. 우리가 6주를 베팅한다면, 팀이 방해 없이 오로지 그 일에 전념할 수 있도록 전체 6주를 보장해주기로 약속한다. a. 모든 인터럽트에서 자유로워야 한다. 인터럽트에 한 시간을 쓰면 그것은 한시간만 쓴게 아니다. 모멘텀을 잃어버리기 때문이다. 3. 베팅에 실패시 지불금 만큼으로 손해를 통제한다. a. 서킷 브레이커를 통해 프로젝트가 예상시간 이상으로 소요되는 것을 막는다. 우리는 appetite를 통해 프로젝트가 6주의 가치가 있다고 정의했다. 프로젝트가 늘어진다고 해서 2배, 3배를 투자하는건 어리석은 일이다. b. 실패했을 때 shaping이 잘못됐다는 걸 깨닫게 하고, 다음 shaping때 개선할 수 있게 한다. c. 서킷 브레이커를 통해 팀원들은 정말 중요한 일에만 집중하게 된다.
Betting Table 그러면 버그는 어떻게 처리해야 할까 모든 버그를 고칠 필요는 없다. 문제는 얼마나 심각한 버그인가이다. 정말 중요한 버그라면 당장 고쳐야 겠지만 그런 위기는 드물다. 대다수의 버그는 6주를 기다릴 수 있다. 버그 처리 전략 1. 작은 버그는 쿨다운 기간을 이용한다. 2. 중요한 버그라면 베팅 테이블로 가져와 다른 피치들과 경쟁한다. 3. 버그 스매시 기간을 가진다. a. 1년에 한 번 버그 수정만 6주간 할애하는 기간을 만든다.
When to Stop circuit breaker를 사용하기 애매할 때 정말 부득이하게 6주 이상으로 프로젝트를 연장해야 할 경우 쿨다운 기간까지만 프로젝트 연장을 허용한다. 이 때는 몇 가지 조건이 있다. 1. 남은 작업이 모두 필수사항이어야 한다 2. 불확실한 과제가 없어야 한다. (well-known 상태)
Shaped versus unshaped work 2. Setting appetites instead of estimates 3. Designing at the right level of abstraction 4. Concepting with breadboards and fat marker sketches 5. Making bets with a capped downside (the circuit breaker) and honoring them with uninterrupted time 6. Choosing the right cycle length (six weeks) 7. A cool-down period between cycles 8. Breaking projects apart into scopes 9. Downhill versus uphill work and communicating about unknowns 10. Scope hammering to separate must-haves from nice-to-haves
못한 부분들 1. 실무진이 참여하지 않는 shaping이 좋은 솔루션을 제시할 수 있을까? 2. 프로젝트 회고에 대한 내용이 없었다. 쿨다운 기간동안 챙기는 것인지 궁금 3. 프로젝트 시작 전엔 Rabbit hole을 절대 다 알지 못할 것 4. 모든 팀에 적용하기 어려워보임