과거 몇년간 어떻게 작은 팀으로, 높은 품질의 소프트웨어를 그렇게 빨리 개발해내는지 물어보곤 했다. 또, 개발자들을 오랫동안 유지하는지도.
첫째, 우리는 워터폴, 애자일, 스크럼같은 프로세스에 얽매이지 않았다. 둘째, 우리는 벽에 포스트잇을 줄세우지 않았다. 셋째, 우리는 데일리 스탠드업, 스프린트, 백로그, 칸반, 벨로시티 체킹등 어느 것도 하지 않았다. 우리는 우리의 길을 만들었다.
1. 소개
이 책은 basecamp 에서 어떻게 제품을 개발하는지 가이드를 제공하기 위한 것이다.
문제점
소프트웨어팀이 성장하면서 유사한 문제점들이 생겨난다.
- 팀원들은 프로젝트가 끝없는 행군처럼 느껴진다.
- 프로덕트 매니저들은 프로덕트에 대해 전략적으로 생각할 시간을 낼 수가 없다.
- 창업자들은 자문한다. 왜 우리는 예전에 했던 것처럼, 신속하게 기능을 출시할 수가 없을까?
우리는 4명에서 50명으로 늘어나면서 이런 문제에 직면했다.
사람 수가 늘어나면서, 창업자들의 직관을 전달하기가 어려워졌다. 그래서 새로운 스케일에 맞는 구조가 필요했다.
6주 사이클.
새 스케일에 맞는 매니지를 위해, 프로젝트 길이가 그때그때 달랐던 것에서, 반복적인 사이클로 변경했다. 6주는 뭔가 의미있는 것을 만들기에 충분히 길었고, 마감일이 눈앞에 보이기 때문에 시간을 효과적으로 계획하게 만들었다.
우리의 의사결정은 시간을 마이크로매니지하는 것이 아니라, 다음 6주간 제품을 어떻게 발전시킬 것인지에 대한 것이 되었다.우리는 개별 기능에 몇시간을, 또는 며칠을 썼는지 세지 않았고, 일일 미팅도 하지 않았다. 우리의 로드맵을 2주마다 새로 생각하지 않았다. 우리의 촛점은 좀 더 상위에 있었다. 우리는 스스로에게 얘기했다. "이 제품이 6주 후에 업데이트되면 우리는 시간을 잘 쓴게 될 거야". 이후에 우리는 6주를 팀에게 보장하고, 해내도록 내버려두었다.
shaping 하기.
우리는 팀에게 일을 주기 전에 모양을 만들었다. 적은 수의 시니어그룹이 사이클 팀과 병렬로 작업했다. 그들이 솔루션의 핵심 요소를 정의하여, 우리가 베팅을 할 것인지 결정할 수 있게 해 주었다. 프로젝트는 사이클팀이 일할 수 있을정도로 구체적이었지만, 그들이 흥미로와하는 디테일을 작업할 수 있는 룸을 남길 수 있을정도로는 덜 구체적이었다.
shaping 할 때 우리는 이 일을 하기 위해 얼마나 걸리는지를 물어보기보다는, 이 일에 얼마나 시간을 쓰고 싶은지, 이 아이디어가 얼마나 가치있는지를 먼저 생각했다. shaping 작업은 문제를 구체화시켜, 우리의 입맛에 맞는 솔루션을 그리는 것이다.
팀에게 책임을 주기.
우리는 디자이너와 프로그래머로 이루어진 팀에게 모든 책임을 준다. 스스로 태스크를 정의하고, 범위를 조절하고, 협업하여 한번에 하나의 릴리즈를 만들어낸다. 이것은 매니저들이 일을 조각내고 프로그래머들이 티켓을 가져가는 형태의 다른 방법론과 전혀 다른 것이다.
이 컨셉들은 조화되어 상승곡선을 그린다. 팀이 능동적이 될 수록, 시니어들은 매니지에 시간을 쓰지 않아도 된다. 매니지에 시간을 덜 쓰게 되니, 시니어들은 더 나은 프로덕트를 shaping 하는데 시간을 쓸 수 있다. 더 잘 shaping 되어 있는 프로젝트라면, 팀은 더 명확한 범위를 갖고 더 능동적으로 일할 수 있게 된다.
SHAPING
1. 범위 정하기. 어느 아이디어에 얼마나 시간을 투입할 것인지. 문제를 어떻게 정의할 것인지를 정한다.
"유저들이 그룹 notification 을 원한다" 라는 정도의 아이디어로 시작한다. 이후 이것을 2단계정도로 욕구를 설정한다. small batch 는 프로그래머 1,2명이 1~2주에 일할 수 있는 정도이고, big batch 는 같은 사이즈의 팀이 6주간 일하는 정도다. 6주 이상 걸릴 것 같으면 마일스톤으로 나눈다 : fixed time, variable scope 원칙.
2. 솔루션을 스케치하는 창의적 작업이다. 와이어프레임보다 더 추상화된 낙서 형태로 만든다.
3. 개발팀의 시간을 낭비하게 할 수 있는 숨겨진 기획 구멍이 있는지 신중하게 살펴본다. 6주 이상이 걸리게 할 수 있는 요소가 있다면
4. 우리가 베팅할 수 있는 형태로 shaping 이 끝나면 pitch 라는 문서로 작성한다. 문제, 제약, 솔루션, 래빗홀 - 구현상에서 예상되는 문제점을 해결할 방법 제안, No-gos - 하지 않을 것 - 까지 요약한 문서다. 이 pitch 는 betting table 에 올려진다. pitch 가 선택되면, 팀에게 전달된다.
예를 들어, 아이디어를 거칠게 생각해냈다고 하자.
이것만으로는 기존의 요소들과 어떻게 어울리는지 모를 수 있으므로, 이런 형태로 꾸밀 수 있다.
실제 작성한 pitch 의 사례이다.
pitch를 작성하면 어디로 보낼까? 백로그는 아니다.
백로그는 우리가 짊어질 필요가 없는 무거운 것이다. 수십개에서 시작해서 결국 수백개에 이르는 우리 모두 절대 할 일이 없어보이는 태스크들이다. 쌓여가는 무더기는 실제로는 그렇지 않음에도 우리가 늘 뒤쳐져가는 느낌을 준다. 누군가가 한분기 전에 중요하다고 생각했던 아이디어라고 할지라도, 그게 우리가 매번 들여다보고 또 볼 필요가 있다는 걸 의미하지 않는다.
백로그는 엄청난 시간 낭비를 초래한다. 지속적으로 리뷰하고 우선순위를 매기는 일들이 지금 정말 중요한 일을 진행하는 것을 방해한다.
그러면 어떻게 할 수 있을까? 각 6주 사이클을 시작하기 전에, 우리는 베팅 테이블을 열어 무엇을 다음 사이클에 진행할 것인지를 결정한다.
베팅 테이블에는 지난 6주간 작성된 피치만이 올라온다. 예전 피치를 새로 업데이트한 것이 올라올 수도 있다. 리뷰할 엄청난 양의 백로그 리스트가 있는 것이 아니다. 테이블 위에는 잘 shaping 된, 리스크를 줄여둔 옵션들이 있을 뿐이다.
단 몇개의 옵션과, 6주간의 사이클의 조합이라면 이런 미팅은 자주 있는 것도 아니고 짧아 매우 생산적이다. 우리가 어떤 피치에 베팅하기로 결정하면 다음 사이클에 제작에 들어간다. 베팅하지 않기로 하면 추적하거나 쌓지 않고 그냥 버린다. 만약 피치가 훌륭했지만 더 중요한것이 있다면? 그 피치를 대변하고 싶은 사람이 keep 하고 있다가 다음번 사이클에 다시 로비한다.
아이디어를 높게 평가하는 경향이 있지만, 팩트는 아이디어는 싼 것이다. 언제나 튀어나와서 거대하게 쌓여버린다.
정말 중요한 아이디어라면 지금 하지 않아도 다시 돌아온다. 다시 생각나지 않게 하는 아이디어는 대단치 않은 것일 공산이 크다.
어떤 회사들은 2주 스프린트를 채택한다. 우리는 2주는 의미있는 일을 하기에 너무 짧고, 플래닝 오버헤드때문에 시간낭비가 크다고 생각한다. 그래서 우리는 사이클이 처음부터 끝까지 보일 수 있는 기간을 택했다. 멤버들이 트레이드오프를 결정하기 위해서는 데드라인이 느껴져야 한다. 몇년간 실험을 거친 결과, 6주에 정착하게 되었다. 6주는 뭔가를 끝내기에 충분히 길고, 마감을 시야에 둘만큼 충분히 짧다.
6주 사이클을 계속해서 돌릴 수는 없다. 마감에 가까와지면 바빠지기 때문에 그 다음 플랜을 의논할 여유가 없다. 그래서 6주 후에 쿨다운 2주를 두었다. 이때는 스케줄된 업무가 없어 다음에 무슨 일을 할 것인지 의논할 수 있다. 쿨다운 기간에 프로그래머와 디자이너들은 그들이 하고 싶은 일을 할 수 있다. 버그를 수정하거나, 새로운 아이디어를 실험해보곤 한다.
팀과 프로젝트 사이즈.
사이클을 표준화할 뿐 아니라, 프로젝트의 타입과 팀 사이즈도 표준화한다.
우리 프로젝트 팀들은 보통 디자이너 1, 프로그래머 1, 또는 디자이너 1, 프로그래머 2로 이루어진다. 사이클 후반에는 QA 인력이 추가된다.
이 팀들은 한 피치를 한 사이클동안 작업하거나, 한 사이클동안 작은 여러 피치를 작업한다. 전자를 big batch 팀, 후자를 small batch 팀이라고 부른다. small batch 프로젝트는 보통 1주나 2주 걸리는 작업들이다. 순서는 해당 팀이 알아서 진행한다.
베팅 테이블.
베팅 테이블은 쿨다운 시기에 이루어지는 미팅으로, 참여자들이 다음 사이클에 무엇을 할지 결정하는 미팅이다. 베팅 후보는 지난 6주간 새로 작성된 피치 또는 누군가가 부활시키기로 한 한두세대 전 피치다. 이전에 얘기했듯, 백로그를 다시 재정리하는 일은 하지 않는다. 테이블 위엔 정리된 몇개의 옵션만 올려진다. 우리 basecamp 의 베팅 테이블에는 CEO, CTO, 시니어 프로그래머, Product Stategist 4명이 앉는다. C레벨의 시간은 늘 부족하므로, 의사결정은 길어야 2시간 이내에 이루어진다. 사전에 피치에 대해 읽고 참석한다. 원온원 미팅 때도 어느정도 이 내용이 공유된다.
회사에서 가장 고위 직책들이 모여있다. 승인절차가 따로 필요없다. 확정되면 누군가 방해할 수도 없다. 이것이 사이클이 돌아가는데 필수적인 요소다. 참석자는 적고, 옵션이 잘 정리되어 있고, 회의시간은 짧다. 이런 제약요건이 갖춰지면, 베팅 테이블은 자원 경쟁이나 우선순위를 높여달라는 요구를 듣는자리가 아니라, 제품의 디렉션을 컨트롤하는 자리가 된다. 충분한 진척을 만들만큼 긴 사이클과 함께 이 제품이 릴리즈되면, 베팅 테이블을 통해 C 레벨들은 한동안 잊고 살았던 "직접 운전하는" 느낌을 받을 수 있게 된다.
우리는 플래닝이라는 단어 대신 "베팅"이라는 단어를 의도적으로 사용한다.
첫째, 베팅에는 "당첨금"이 있다. 우리는 시간을 태스크로 채우는 짓을 하지 않는다. 우리는 어떤 기능을 향해 2주를 주고 약간의 개선을 바라지 않는다. 우리는 의도적으로 일을 6주 박스만큼 shaping 하므로, 최후에는 의미있는 분량의 작업물이 있다. 피치에는 베팅할만 가치가 있는 당첨금의 내용이 정의되어있다.
둘째, 베팅은 보장이다. 우리가 6주를 베팅하면, 해당 팀에게 다른 일 없이 그 일에만 6주를 일할 수 있도록 보장한다. 우리는 프로그래머의 모든 시간을 최적화하려고 노력하지 않는다. 우리는 6주 후의 전체 프로덕트의 진척에 대한 큰 움직임을 바라본다.
셋째, 베팅을 스마트하게 하면 다운사이드가 제한적이다. 우리가 어느 일에 6주를 베팅하면, 우리가 잃는 최대한의 것은 6주다.
마지막 두 포인트를 더 자세히 설명한다.
인터럽트하지 않아야.
6주를 보장한다고 말해놓고, 다른 일이 생겼을 때 주는 것은 베팅이 아니다. 어떤 사람이 작업팀에 요청을 하게 되면, 우리는 보장을 깬 것이 된다. 어떤 사람이 "몇시간만" 또는 "하루만"할 때 속지 말라. 모멘텀은 쉽게 얻어지는 것이 아니다. 인터럽트 되지 않는 시간을 연속적으로 주어야만 한다. 버그를 수정하거나 다른 팀을 돕느라 하루를 빼게 되면, 하루만 잃는 것이 아니다. 그 동안 쌓았던 모멘텀을 날리고 다시 시간을 들여 쌓아야 한다. 한 시간을 잘못 쓰면 하루를 날리고, 하루를 잘못 쓰면 일주일을 날린다.
어떤 중요한 아이디어가 새로 나타나면? 여전히 우리는 팀을 인터럽트하지 않고 기다린다. 6주만 기다리면 새로운 아이디어도 베팅 테이블에 올라올 수 있다. 그래서 바로 다음사이클만 베팅하는 것이 중요하다. 그래야 새로운 이슈도 베팅할 수 있는 룸이 열려있게 된다.
물론 엄청난 위기라면 브레이크를 밟긴 하지만, 매우 드물다.
서킷 브레이커.
프로젝트가 제때 끝나지 못하면, 연장은 없다.
우리는 인터럽트 없는 시간과, 이 서킷브레이커를 매우 중요한 정책으로 두었다.
첫째, 피치마다 욕구를 정해두었는데, 6주짜리 욕구에 12주를 쓸 수는 없는 일이다. 기간과 상관없이 무조건 해내야하는 프로젝트는 거의 없다.
둘째, 6주에 끝내지 못했다는 것은 우리가 shaping 을 잘못했다는 의미이다. 서킷브레이커는 잘못된 접근방식에 시간을 더 쓰기보다, shaping 을 다시 하게 강제한다.
셋째, 서킷브레이커는 팀에게 오너십을 갖도록 한다. 팀은 구현의 디테일에 있어 트레이드오프 의사결정을 하고, 범위를 축소할 수 있는 권한과 책임을 모두 가진다. 누구도 언제 멈출지, 어느 부분을 타협할지, 무엇을 내버려둘지 힘든 결정없이 제품을 출시할 수는 없다. 정해진 데드라인과, 릴리즈를 못할 수 있는 상황이 팀을 생각하게 한다.
인터럽트가 없다면, 버그는?
버그가 다른 것들보다 중요하다고 생각해야 할 이유는 전혀 없다. 모든 소프트웨어는 버그가 있다. 데이터를 잃거나, 앱이 중단되거나, 유저 대부분이 엉뚱한 것을 보고 있다면, 즉 엄청난 위기 상황이라면 모든 것을 포기하고 그것부터 고칠 것이다. 하지만 그런 경우는 드물다. 대부분의 버그는 6주는 기다릴 수 있다. 많은 버그들은 고치지 않아도 된다. 우리가 모든 버그를 제거하려고 한다면, 그 일만 해도 끝이 나지 않을 것이다. 우리의 버그 대처 전략은 이렇다.
1. 쿨다운 시기를 이용한다.
2. 베팅테이블에 가져온다. 쿨다운시기에 고치기엔 너무 크다면 다른 피처들과 경쟁해볼 수 있다.
3. 버그 때려잡기 스케줄을 잡는다. 보통 연휴 부근에 6주 전체를 버그 잡기로 1년에 한번 계획한다. 우리는 bug smash 라고 부른다. 연휴 주변이 좋은 이유는 휴가 때문에 일반적 6주 프로젝트를 진행하기가 어렵기 때문이다.
슬레이트를 깨끗하게 유지한다.
각 사이클에서 깨끗한 슬레이트를 유지하는 것이 개발역량을 관리하는 데 있어 핵심요소다. 한번에 한사이클에만 베팅하는 것, 잘 shaping 한 신선한 베팅 후보 외에는 백로그를 짊어지고 다니지 않는 것이 그것이다.
신제품 개발시.
새로운 제품을 개발할 때는 벽과 기둥을 세워야 하는 시기라 모든 것이 가변적이다. 그래서 "이것이 우리가 원하는 것이다. 6주 후에 출시하자"라고 단정하기 어렵다. 만들어가면서 우리가 원하는 것이 무엇인지 학습해야 한다.
우리는 이 시기를 R&D모드라고 부르고, 3가지 방식으로 조정한다.
1. 새 제품 아이디어의 핵심 조각들에 대해 베팅하는데, shaping 이 더 구체적이지 않다. 왜냐하면 만들어가면서 배울 수 밖에 없기 때문이다.
2. 개발팀을 선발하지 않고, 시니어들이 개발한다. CTO가 개발하고 CEO가 설계한다. 무엇을 원하는지 정확하게 알 수 없는 것을 위임할 수가 없고, 둘쨰로는 아키텍처적 의사결정이 해당 제품의 미래를 결정하기 때문이다.
3. 마지막으로 우리는 R&D 사이클 후에 제품 출시를 기대하지 않는다. 목적은 스파이킹하는데 있지, 릴리즈하기 위함이 아니다.
이후 Production mode 로 이어진다.
R&D 사이클을 몇차례 지나면, 가장 중요한 아키텍처적 의사결정이 확정된다. 구조가 자리잡으면, 시니어팀이 다른 멤버들을 동원하여, 앞서 언급한 6주 사이클을 돌기 시작한다.
이후 Cleanup mode 가 진행된다.
새 제품을 만들면, 늘 우리가 빼먹은 것이나, 들어맞지 않는 디테일, 버그들이 많이 나타난다. 이런 것들을 해결하기 위해, 여유분을 두는 것이다. bug smash 비슷하게 shaping 없이 출시 준비를 진행한다. 최대 2 사이클을 넘지 않도록 한다.
사이클이 시작될 때는?
우리는 개개인에게 업무를 나누어주지 않는다. 팀내 누구도 일을 나누어주는 역할을 맡는 사람은 없다. 프로젝트를 태스크로 나누는 것은 피치를 파쇄기에 넣는 것과 비슷하게 느껴진다. 모두 단절된 조각을 나눠가진다. 우리는 프로젝트가 전체로 남아 사람들이 더 큰 그림을 볼 수 있기를 원한다.
작업 완료란 배포를 의미한다.
사이클의 마감에 이르면, 팀은 작업을 배포한다. small batch 팀의 경우, 하나씩 완료될때마다 배포한다. 사이클 내에 QA까지 포함된다는 의미이다. 하지만 문서, 마케팅 업데이트, 공지까지 사이클 내에 이루어지기를 기대하지는 않는다. 이런 일들은 보통 쿨다운 시기에 진행한다.
시작점 잡기.
첫 며칠동안은 사람들이 일하지 않는 것처럼 보인다. 배포는 물론 대화도 별로 없다.
모두 현재 시스템이 어떻게 되어 있는지, 어디서부터 시작하는게 옳을지 생각하고 있기 때문이다. 매니저들이 이 단계를 존중하는 것이 중요하다. 팀원들이 바로 일에 뛰어들어 개발을 시작할 수가 없다. 관련된 코드를 살펴보고, 새 피치를 이해하고, 시작점을 찾아야 한다. 이 때 눈에 보이는 결과물을 요구하는 것은, 어차피 필요한 이 단계를 수면아래로 내려보낼 뿐이다. 프로젝트를 투명하게 보려면 팀원들에게 "어디서 시작할지 찾아보고 있어요"라고 대놓고 이야기할 수 있게 하는 것이다. 일반적으로 3일이 지나도 침묵이 깨지지 않으면, 진척을 물어보아도 좋은 시기다.
'개발 프로세스' 카테고리의 다른 글
| 스크럼 프로세스 - 액티비티 위주 정리. (0) | 2020.08.31 |
|---|
