Shape up 방법론

By Joel

Transcript

1. Vision Mission Grow together to Change the world Spread Rewards, Spark Engagement Shape Up Method 작은 조직에서 효과적으로 일하기 Joel Lim 2022. 2. 25 Copyright ⓒ All Right Reserved by Buzzvil
2. Copyright ⓒ All Right Reserved by Buzzvil 들어가기 전에
3. Copyright ⓒ All Right Reserved by Buzzvil What is the Shape Up method Basecamp에서 사용하는 개발 방법론 6주 주기의 사이클로 제품을 개발 생산성 소프트웨어을 만드는 회사
4. Copyright ⓒ All Right Reserved by Buzzvil 배경 팀이 성장하며 몇 가지 어려움이 발생 1. 팀원들은 끝이 안보이는 프로젝트가 계속되는 것처럼 느낌 2. 제품 관리자는 제품에 대해 전략적으로 생각할 시간이 없음 3. 초기 시절처럼 빠르게 기능을 출시할 수 없음 4. 창업자들의 직관을 전달하기 점점 어려워짐
5. Copyright ⓒ All Right Reserved by Buzzvil 그래서 만들게 된 일하는 방식 - Shape Up 1. 6주 주기로 일한다. 2. 할 일을 Shaping 한다. 3. 실무자에게 전권을 위임한다. 4. 리스크를 사전에 추적해 줄인다.
6. Copyright ⓒ All Right Reserved by Buzzvil 목차 1. Shaping ◦ 원시 아이디어를 다듬고, 위험요소를 찾고, 얼마나 시간을 투입할지 결정하는 단계 2. Betting ◦ Shaping 된 과제 중 다음 주기에 무엇을 할지 결정하는 단계 3. Building ◦ 실제 제품 개발 단계
7. Copyright ⓒ All Right Reserved by Buzzvil Shaping
8. Copyright ⓒ All Right Reserved by Buzzvil Shaping Shaping 이란? - 문제를 정의하고, 해결방법을 찾고, 다듬는 일련의 작업
9. Copyright ⓒ All Right Reserved by Buzzvil Shaping Shaping 원칙 • 팀의 창의력을 저해하지 않도록 너무 구체적이면 안된다. ◦ 와이어 프레임은 너무 구체적이다. • 반대로 너무 추상적이면 안된다… ◦ e.g. 캘린더 보기 만들기, 그룹 알림 추가, 시스템 리팩토링 등 • 그러면서 반드시 문제를 해결해야 한다.
10. Copyright ⓒ All Right Reserved by Buzzvil Shaping - case study Shape 예시 - Basecamp의 캘린더 기능 캘린더 기능 추가을 만들어달라는 고객요청이 많았음 제대로 된 캘린더를 만드려면 6달정도의 시간이 소요됨. 우리는 6주의 시간만 들여 고객의 문제를 해결하고 싶었음. 그래서 캘린더가 고객에게 전달해야 할 핵심가치에 집중하기로 함. 고객은 캘린더를 통해, 일정을 쉽게 확인할 수 있기를 원함 고객이 원하는 핵심 기능은 ‘Dot Grid’라는 결론 도달 2달치 달력만 보이는 읽기전용 캘린더를 고안. 이벤트는 날짜 밑에 점으로만 표시 그 외 캘린더로서의 기능은 모두 무시
11. Copyright ⓒ All Right Reserved by Buzzvil Shaping - case study Shape된 스케치 실제 결과물
12. Copyright ⓒ All Right Reserved by Buzzvil Shaping - case study 1. 적절히 추상적인가? Yes 2. 문제가 해결됐는가? Yes 3. 경계가 있는가? Yes
13. Copyright ⓒ All Right Reserved by Buzzvil Shaping - steps to shaping 1. 경계를 정한다 (Set Boundaries) 2. 필수요소들을 다듬는다 (Rough out the elements) 3. 리스크를 파악한다 (Address risks and rabbit holes) 4. 피치를 작성한다 (Write the pitch)
14. Copyright ⓒ All Right Reserved by Buzzvil Shaping - Set Boundaries 문제의 범위를 좁히고, 얼만큼의 시간을 투입할지 결정한다.
15. Copyright ⓒ All Right Reserved by Buzzvil Shaping - Set Boundaries 멀리서 보기(포커페이스 유지) 아이디어가 나왔을 때, 잠깐 멈춰서 이 아이디어가 얼마나 가치 있는지 생각하자. - 너무 빨리 아이디어를 실행하면, 자칫 리소스를 낭비할 수 있다. - 너무 솔루션을 길게 생각하면 쓸모없는 아이디어에 너무 긴 논의 할 수 있다. appetite: 아이디어가 어느정도 가치가 있는지 판단하는 기준 appetite는 팀의 시간 리소스로 생각할 수 있으며 두 가지 크기로 설정한다. small batch(1~2주짜리 프로젝트)
16. Copyright ⓒ All Right Reserved by Buzzvil appetite != estimate “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’을 찾을 수 있다.
17. Copyright ⓒ All Right Reserved by Buzzvil Shaping - Set Boundaries narrow down - 문제 범위 좁히기 캘린더 사례 1. 실제 고객과 컨택 2. 고객은 캘린더를 통해 팀 일정과 회의실 사용여부를 확인하고 싶었음. 3. 캘린더의 모든 기능 -> 날짜별 빈 스케줄을 확인할 수 있는 기능으로 범위를 좁힘
18. Copyright ⓒ All Right Reserved by Buzzvil Shaping - Find the Elements BreadBoarding - Place: 화면, 대화 상자, 팝업 메뉴 같은 탐색할 수 있는 항목 - Affordance: 사용자가 작업할 수 있는 항목(버튼이나 필드 등) - Connection Line: 어포던스로 사용자가 이동하는 것 Place Affordance Connection Line
19. Copyright ⓒ All Right Reserved by Buzzvil Shaping - Find the Elements Before After
20. Copyright ⓒ All Right Reserved by Buzzvil Shaping - Find the Elements Fat marker sketches
21. Copyright ⓒ All Right Reserved by Buzzvil Shaping - Risks and Rabbit Holes 잘 shape된 프로젝트 Rabbit hole이 많은 경우 (기술적 문제, 잘못된 디자인, 미스 커뮤니케이션…)
22. Copyright ⓒ All Right Reserved by Buzzvil Shaping - Risks 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.”
23. Copyright ⓒ All Right Reserved by Buzzvil Shaping - Write the Pitch 피치의 목적은 잠재력있는 내기(프로젝트)를 베팅 때 제시하는 것 피치에 포함되야 할 다섯가지 1. Problem 2. Appetite 3. Solution 4. Rabbit holes 5. No-gos
24. Copyright ⓒ All Right Reserved by Buzzvil Shaping - Write the Pitch
25. Copyright ⓒ All Right Reserved by Buzzvil Shaping - Write the Pitch
26. Copyright ⓒ All Right Reserved by Buzzvil Betting
27. Copyright ⓒ All Right Reserved by Buzzvil Betting - Bets, Not Backlogs No Backlogs - 백로그는 시간낭비다. - 백로그에 쌓인 수많은 일들을 다 할 수 없다는 걸 모두가 안다. - 백로그에 일이 쌓이면 항상 뒤쳐진다는 느낌을 받게 된다. - 오래된 아이디어를 다시 검토하고, 정리하는데 소요되는 시간은 지금 당장 중요하고 적절한 프로젝트를 진행하는데 방해가 된다.
28. Copyright ⓒ All Right Reserved by Buzzvil Betting - Bets, Not Backlogs Betting table 잘 shaped된 피치 몇 개만 가지고 와, 그 중에서 다음 6주동안 할 일을 고른다. 베팅된 일을 진행하고, 선택받지 못한 피치는 하지 않는다. 꼭 해야 한다면 다음 베팅 테이블 때 다시 제안한다. “Important ideas come back” 아이디어는 과대평가하기 쉽다. 하지만 사실 아이디어는 값싸다. 정말 중요한 아이디어라면 다시 나온다. 한번 듣고 백로그로 가는 아이디어는 별로 중요한 문제가 아닐 수 있다.
29. Copyright ⓒ All Right Reserved by Buzzvil Betting - The Betting Table 6주 주기 프로젝트 사이클 프로젝트 계획이 캘린더 테트리스가 되지 않도록, 표준 프로젝트 크기를 제공해야 한다. 왜 6주인가? - 의미 있는 일을 하기에 2주(스프린트)는 너무 짧다. 플래닝 오버헤드 대비 2주동안 해내는 성과는 그다지 많지 않다. - 실험을 거쳐, 프로젝트를 마무리하기까지 충분히 길면서 데드라인이 적절히 쪼아줄 수 있는 주기가 6주라고 결론지었다.
30. Copyright ⓒ All Right Reserved by Buzzvil Betting - The Betting Table Cool-down 6주 주기 후에 2주의 쿨다운 기간을 갖는다. 이 때는 팀원들이 원하는 어떤일이든 해도 좋다. 버그를 고치거나, 기술을 공부하는 등 자신이 통제할 수 있는 시간을 즐긴다. 쿨다운 기간에 다음 6주 주기에 어떤 일을 진행할지 결정하는 Betting이 진행된다.
31. Copyright ⓒ All Right Reserved by Buzzvil Betting - The Betting Table 전체 사이클
32. Copyright ⓒ All Right Reserved by Buzzvil Betting - The Betting Table 베팅의 의미 1. 모든 베팅에는 지불금이 있다. 우리의 경우엔 6주라는 시간이다. 2. 베팅은 약속이다. 우리가 6주를 베팅한다면, 팀이 방해 없이 오로지 그 일에 전념할 수 있도록 전체 6주를 보장해주기로 약속한다. a. 모든 인터럽트에서 자유로워야 한다. 인터럽트에 한 시간을 쓰면 그것은 한시간만 쓴게 아니다. 모멘텀을 잃어버리기 때문이다. 3. 베팅에 실패시 지불금 만큼으로 손해를 통제한다. a. 서킷 브레이커를 통해 프로젝트가 예상시간 이상으로 소요되는 것을 막는다. 우리는 appetite를 통해 프로젝트가 6주의 가치가 있다고 정의했다. 프로젝트가 늘어진다고 해서 2배, 3배를 투자하는건 어리석은 일이다. b. 실패했을 때 shaping이 잘못됐다는 걸 깨닫게 하고, 다음 shaping때 개선할 수 있게 한다. c. 서킷 브레이커를 통해 팀원들은 정말 중요한 일에만 집중하게 된다.
33. Copyright ⓒ All Right Reserved by Buzzvil Betting - The Betting Table 그러면 버그는 어떻게 처리해야 할까 모든 버그를 고칠 필요는 없다. 문제는 얼마나 심각한 버그인가이다. 정말 중요한 버그라면 당장 고쳐야 겠지만 그런 위기는 드물다. 대다수의 버그는 6주를 기다릴 수 있다. 버그 처리 전략 1. 작은 버그는 쿨다운 기간을 이용한다. 2. 중요한 버그라면 베팅 테이블로 가져와 다른 피치들과 경쟁한다. 3. 버그 스매시 기간을 가진다. a. 1년에 한 번 버그 수정만 6주간 할애하는 기간을 만든다.
34. Copyright ⓒ All Right Reserved by Buzzvil Betting - The Betting Table 베팅 테이블에서 논의해야 할 사항들 • 진짜 그 문제가 중요한지 • 6주 내에 완료하기 적절한지 • 솔루션이 매력적인지 • 문제를 해결하기 적절한 시기인지 • 문제를 해결하기에 적합한 사람이 있는지
35. Copyright ⓒ All Right Reserved by Buzzvil Building
36. Copyright ⓒ All Right Reserved by Buzzvil Building - Hand Over Responsibility 태스크를 나눠 분배하지 마라 - 알아서 하게 둬라 팀 스스로 태스크를 나눈다. 세부사항은 자율적으로 구현한다. 재능있는 사람은 코드몽키가 되고 싶어하지 않는다.
37. Copyright ⓒ All Right Reserved by Buzzvil Building - Hand Over Responsibility 며칠간의 침묵을 존중하라 팀 내부적으로 세부구현에 대한 방향성을 잡기 위한 시간이 필요하다. 이 기간동안 아무일도 하지 않은 것 처럼 보일 수 있으나, 관리자는 이 기간을 존중해 줘야 한다.
38. Copyright ⓒ All Right Reserved by Buzzvil Building - Hand Over Responsibility 일의 완료시점은 배포를 뜻한다. 6주안에 배포가 되지 않으면 의미가 없는 것이다. 이 경우 기간을 연장하지 말고, 프로젝트를 취소한다. (circuit breaker)
39. Copyright ⓒ All Right Reserved by Buzzvil Building - Get One Piece Done 통합된 하나의 기능단위로 작업을 해 나가라 첫 시작지점 찾기 1. 핵심적이고 2. 충분히 작으면서 3. 이전에 하지 않은 부분
40. Copyright ⓒ All Right Reserved by Buzzvil Building - Map the Scopes Scope map 프로젝트 시작 단계 작업 발견 단계 Scope 정의단계
41. Copyright ⓒ All Right Reserved by Buzzvil Building - Map the Scopes
42. Copyright ⓒ All Right Reserved by Buzzvil Building - Show Progress
43. Copyright ⓒ All Right Reserved by Buzzvil Building - Decide When to Stop 주기가 끝날 쯤에 릴리즈 여부를 결정해야함. 이 때 베이스라인과 비교해 릴리즈를 결정하자. - 현재보다 나아진다면 릴리즈
44. Copyright ⓒ All Right Reserved by Buzzvil Building - Decide When to Stop Scope는 항상 자란다. 모든 프로젝트는 불필요한 scope로 가득 차 있다. scope가 계속 자라지 않도록 팀에서 조정할 수 있는 권한을 주자 scope를 줄여도 품질은 낮아지지 않는다. 중요한 것에 집중해 오히려 좋은 제품을 만든다.
45. Copyright ⓒ All Right Reserved by Buzzvil Building - Decide When to Stop circuit breaker를 사용하기 애매할 때 정말 부득이하게 6주 이상으로 프로젝트를 연장해야 할 경우 쿨다운 기간까지만 프로젝트 연장을 허용한다. 이 때는 몇 가지 조건이 있다. 1. 남은 작업이 모두 필수사항이어야 한다 2. 불확실한 과제가 없어야 한다. (well-known 상태)
46. Copyright ⓒ All Right Reserved by Buzzvil Key concept 1. 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
47. Copyright ⓒ All Right Reserved by Buzzvil Review 좋았거나 인상깊었던 부분 1. appetite 2. 6주간의 완전한 몰입. (싱글 스레드 팀) 3. “베팅”이 가지는 비장함 4. 러프한 피치와 전권위임 5. 정말 중요한 아이디어는 알아서 돌아온다
48. Copyright ⓒ All Right Reserved by Buzzvil Review 별로거나 동의하지 못한 부분들 1. 실무진이 참여하지 않는 shaping이 좋은 솔루션을 제시할 수 있을까? 2. 프로젝트 회고에 대한 내용이 없었다. 쿨다운 기간동안 챙기는 것인지 궁금 3. 프로젝트 시작 전엔 Rabbit hole을 절대 다 알지 못할 것 4. 모든 팀에 적용하기 어려워보임
49. Copyright ⓒ All Right Reserved by Buzzvil Review 1. user side 제품보단 내부제품을 만들 때 도입 할 것 같음 2. 적용했을 때 놀라운 제품 보단 무난한 제품이 나올 것 같다 3. appetite, marker sketches 같은 컨셉이 개인적으로 좋았고, 적용해 볼 만할 것 같다.
50. Copyright ⓒ All Right Reserved by Buzzvil Thank you Joel Lim 2022. 2.25