Page History
...
- 첫째 우리는 워터폴, 애자일, 스크럼같은 프로세스에 얽매이지 않았다.
- 둘째, 우리는 벽에 포스트잇을 줄세우지 않았다.
- 셋째, 우리는 데일리 스탠드업, 스프린트, 백로그, 칸반, 벨로시티 체킹등 어느 것도 하지 않았다.
우리는 우리의 길을 만들었다.
...
경영철학 기반으로 스몰비즈니스대상으로 B2B SaSS를 10년간 운영하면서 만든 개발방법론인점이 여타 다른 실리콘밸리의 성공 문화와 차별성이 있으며
...
| draw.io Board Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
경영및 제품철학 기반으로 경험베이스로 개발철할및 방법론이 태생하였으며 개발방법론과 연관된 경영철학인 경우 Rework(번역본)에서 발췌하였습니다.
오역과 경험에의한 추가적인 개인 해석본이 있을수있으며 ShapeUp에대한 자세한 내용은 참고링크에 있는 원문 아티컬을 권장합니다.
- 지속 연구중에 있으며 B2B 비즈니스 대상, 중소 IT기업규모 인점을 참고하면 좋을것같습니다.
|
|
|---|
...
...
기존 일하는 방식의 한계
소프트웨어팀이 성장하면서 유사한 문제점들이 생겨난다.
...
- 기한 내에 리스크 최소로 구현을 완료하자
- 집중과 휴식을 번갈아가며 6주-2주 주기로하자
- 기한 내 못할 것은 현명하게 포기하고 필수적인 것을 만들자
- 개발자, 디자이너가 자율성 높게 일할 수 있게하자.
BaseCamp가 BaseCamp(37signals)가 만든 ShapeUP을 요약하여 살펴보겠습니다.
Shape UP Life Cycle
| draw.io Board Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
| draw.io Board Diagram | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
- Estimate : 이것이 언제까지 될까요? 러프하게 추정러프하게 추정하다보면 기간이 계속 늘어난다. 작은 Task를 러프하게 추정하고 테트리스하다보면 어느순간 의미없는 일이 3개월이상 눈덩이처럼 불어나있다.
- Appetite : 시간을 정해놓고 우리가 꼭해야할것이 무엇인가? 일을조정
ShapeUp에서는 Appetite방식을 사용하여 해야할 일을 조정합니다.
그래서 꼭 해야되는 일을 찾아내는것이 중요합니다.
- 꼭필한것을 고민한다. 그리고 이 기간안에 할수있게 일을조정 한다. 여기서 제외되는것은 덜 중요한 일이다.
ShapeUp에서는 기간을 정해놓고 꼭 필요한 일을 하는 Appetite방식을 사용합니다.
Calendar View는 실제로 우리가 출시한 기능이며~ Appetite방식으로 일을 결정한 한가지 심플한 예입니다.
...
- 등록 이벤트를 드래그앤 드랍으로 이동하기
- 스케쥴을 월별 주별 비교하기
- 스케쥴의 기간을 보기
- 이벤트마다 색상을 입히기
- ...... 그리고 차별성을 위한
구글캘린더처럼 만들고 추가 아이디어를 와이어프레임으로 만든다고 1개월이 이미 걸렸고
완성되는것에 6개월 이상이 필요하다고 측정되었습니다.구글캘린더처럼 만들지도 못하는데 이것을 만드는데는 6개월이상이나 측정이 되었고
여기서 우리는 이것을 또 할지 말지결정합니다.
...
그러다보니 이 시간내에 할수 있는 가장 중요한 아이디어가 나왔습니다아이디어와 함께
고객이 가장 원하는 한가지 기능을 알게되었습니다.
고객은 그저 자신이 등록한 스케줄이 뭔지 알기를 원했을뿐입니다.
이것은 빠르고 완벽하하게 일해야하기가아닌
불필요한 일을 안하고 중요한 일을 시간내에 꼭 해야하는것에 가깝습니다하고 고객에게 기능을 빠르게 제공하는것입니다.
기획여정
| draw.io Board Diagram | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Wireframe이 나쁘다라는것이아닌 여기에 우리의 아이디어를 즉각반영하고 수정하기에 너무 많은 시간이 걸린다란 점입니다.
Shape 주요 3단계 절차및 속성, 3단계를 통해 모습을 만들어갑니다.
- Rough
- 러프한것은 누구든 미완성이란것을 알고 있습니다. 너무 구체적이지 않아도 이것으로 충분합니다.
- Sloved
- 우리가 만드려는 기능의 핵심(Core)에 대한 해결방법이 존재해야합니다. 그것이 없으면 Shape는 완성될수 없습니다.
- WireFrame단계에서 가능한지 안가능한지 검토하는것이 아닌 그 이전에 해결방법을 찾아야함을 의미합니다.
- Bounded
- 우리의 시간은 제약적입니다. 이것을 시간내에 해야할 경계를 정하는것이 중요합니다.
- 꼭 해야할것과 했으면 좋은것을 분리합니다. 하지만 중요한것은 하지말아야할것을 정의함으로 경계를 만듭니다.
- 하지말아야할것이 꼭 불필요한것은 아닙니다. 이것을 정의하지 않으면 우리의 상상력으로 수많은 하지말아야할것을 만들기때문입니다.
- 했으면 하는것을 우리는 백로그에 쌓지 않습니다. 중요한것은 언젠가 다시 할수 있습니다.
위 3단계가 완성되었을때 Shape가 완성됨을 의미하고 벳팅 테이블에 올려놓습니다.
6주간의 벳팅테이블에 올려놓기위해 아래 4가지 Shape를 완성시키는 과정을 거치게됩니다.
Setboundaries.
경계를 설정하세요. 먼저 우리는 원시 아이디어의 가치와 문제를 정의하는 방법을 파악합니다. 이는 우리에게 형성할 기본 경계를 제공합니다. 요소를 대략적으로 다듬습니다.
Rough out the elements
그런 다음 솔루션을 스케치하는 창의적인 작업이 시작됩니다. 우리는 빠르게 움직이고 충분히 넓은 범위의 가능성을 탐색하기 위해 와이어프레임보다 더 높은 수준의 추상화에서 이를 수행합니다.
이 단계의 결과는 세부적인 사항이 모두 해결되지 않지만 우리가 하고싶은것(식욕)에 대한 문제를 해결하는 아이디어입니다.
Address risks and rabbit holes
위험과 토끼굴을 해결하세요. 해결책이 있다고 생각되면, 팀을 혼란에 빠뜨릴 수 있는 허점이나 답이 없는 질문을 찾기 위해 열심히 조사합니다. 우리는 팀이 막히거나 시간을 낭비하는 것을 방지하기 위해 솔루션을 수정하고, 내용을 잘라내고, 특정 까다로운 부분에 세부 사항을 지정합니다.
피치를 작성합니다. 잠재적으로 베팅할 수 있을 만큼 충분히 구성되었다고 생각되면 이를
피치라는 공식 문서로 패키지화합니다.
Write the pitch
피치에는 문제해결방법, 제약, 솔루션, 토끼 구멍 및 한계가 요약되어 있습니다. 피치까지 완성되면 베팅 테이블로 이동합니다
DDD(도메인 주도 개발)에서 보편언어로 이벤트 스토밍을 통해 도메인을 발견하고 경계(Bounded)를 나누고
컨텍스트를 맵핑하는 방식과 비교해도 도움될것 같습니다.
접근방식과 순서에는 약간 차이가 있습니다.
백로그를 선택하고 시간을 러프하게 추정하고 그 이후 해결방법을 찾는 일하는 방식과의 차이가 있습니다.
...
토끼굴에 빠지지 않기~ 이상한 나라 엘리스에의 토끼굴을 의미하며 한번빠지면 나오는데 너무 오랜 시간이 걸림을 의미합니다.
우리가 원했던것예측한시간
실제
실제작동되는 시간
토끼굴을 찾지 못하면 우리의 릴리즈는 더 늘어나게됩니다.
...
예상된 문제들은 벳팅테이블에서 고려할수 있게 함께 올라갑니다.
The
...
6주동안 무엇을 할지 벳팅을 하고, 이것이 성공하면 2주간의 CooDown시간을 가집니다.
이 기간에는 자유롭게 일을 수행합니다. 새로운 아이디어를 탐구하거나 새로운 기술적 가능성을 시험할수 있습니다.
circuit breaker
팀은 우리가 베팅한 시간 내에 배포를 해야합니다. 이것이 지켜지지 않으면 우리는 더이상 프로젝트를 확장하지 않습니다.
프로젝트의 가치를 6주로 생각하고 시작하였는데 그 2배~3배~10배로 소비하는것은 어리석은 일입니다.
"어떤 대가를 치르더라도 이 프로젝트를 수행해야해"와 같은 유형의 프로젝트는 대부분 없으며
이것을 계속 연장하는것은 우리의 프로덕트개발에 과부하를 주는것입니다.
중단하지 못하는경우 새로운 프로젝트를 못할수도 있고더 중요한 일을 못하게 할수도 있기때문입니다.
The Betting Table
Shape가 완성되면 우리는 이것을 할지 말지 또는 6주내에 할수 있을지를 2주간 고민을 합니다이것이 꼭 휴식을 의미하지 않으며 정비에 가깝습니다.
기업은 경쟁을 좋아한다. 밟고 이기고, 1 or 0으로 만들길 원한다. 스포츠처럼 이기고 지고를 비교하면 우리는 항상 지는 게임을 하고 있으며 패배자 이다.
즉 우리가 가진 이메일 솔루션인 hey를 구글의 gmail의 사용자수와 비교하지 않는다. 하지만 우리는 장님은 아니여서 언제든 알수는 있고 누구든 열람할수 있다.
나는 다른 누군가와 경쟁하는 것에 흥미가 없다. 그리고 우리는 경쟁적인 관점에서 결정을 내리지도 않는다.
내 마음속엔 중요한 지표가 하나 있다. 이건 숫자가 아니라 느낌이라고 표현할 수 있다.
'나는 이것을 또다시 하고 싶을까? (Would I want to do that again?)'
이 단순한 질문 하나로 수많은 질문은 의미가 없어진다. 그리고 이에 대한 심플한 답 하나가 다른 모든 것에 해답이 된다.
상황에 따라 다양한 형태로 답할 수 있겠지만 결국 심플한 YES or NO Question이다. 물론 가장 좋은 대답은 Hell Yeah! 와 Hell No! 다.
이렇게 질문하는 것은 빠르게 핵심을 꿰뚫고 실체를 드러나게 만든다.
회사의 성장을 위해 중요한 가치나 품질을 희생하는 것은 위험하며 성공한 회사란 꼭 큰 회사를 의미하지 않는다.
올바른 규모의 회사를 만드는 것이 중요하다. 우리는 회사에 꼭 필요할 때만 채용을 하고, 조심스럽게 성장을 통제하는 방향을 선택하였다.
남들에게 실패일지라도 은퇴할때까지 우리의 제품을 작게 유지할수 있어도 우리에게는 이것도 성공이라고 본다.
- 베이스 캠프의 벳팅 철학
NewProduct
새로운 제품의 경우 ShapeUP 방식과 약간다릅니다. ShapeUP은 프로덕트가 있는 상황에서 기능(또는 프로젝트)을 추가하는 방법입니다.
제품은 다릅니다. 기존 제품에 추가하는 것은 고정된 치수의 방에 소파를 구입하는 것과 비슷하지만, 신제품 개발은 건물이 서 있을 수 있도록 벽과 기초가 어디로 가야 하는지 파악하는 것과 같습니다. 우리는 처음부터 새로운 제품을 만들 때 세 가지 작업 단계를 살펴보았습니다. 각 단계마다 우리가 형성하는 방식과 주기 동안 팀이 어떻게 협력할 것인지에 대한 기대치가 다릅니다. 이러한 단계는 여러 사이클에 걸쳐 전개되지만 우리는 여전히 한 번에 하나의 사이클만 베팅합니다.
ShapeUP은 주로 기존 프로덕트에서 성장하는 과정에서 신규기능을 확장하는 방법에 관한것이며
새로운 프로덕트의 경우도 동일하게 베팅을 하지만 베팅테이블에 올려놓을수 있지만 베팅이 결정 되면 R&D모드로 전환되게 됩니다.
새로운 팀을 빌드하고 새로운 방식을 채택 할수도 있는 부분이여서 이 부분에대한 부분은 다루지 않았습니다.
대기업 고객은 매력적일 수 있지만 제품, 직원 및 비즈니스 안정성을 뒤집어 놓을 수 있습니다. 수년에 걸쳐 우리는 우리가 깊이 존경하는 여러 회사에 거절을 했습니다. 우리는 소수의 대기업에 모든 위험을 투자하고 싶지 않습니다. 우리는 하나의 큰 계정이 없어져도 비즈니스의 20%를 잃고 싶지 않습니다. 우리는 우리가 그토록 사랑하는 중소기업을 희생시키면서 대기업이 선호하는 방향으로 제품을 밀어붙이고 싶지 않습니다.
- Base캠프의 제품방향에 대한 철학
The circuit breaker
팀은 우리가 베팅한 시간 내에 배포를 해야합니다. 이것이 지켜지지 않으면 우리는 더이상 프로젝트를 확장하지 않습니다.
프로젝트의 가치를 6주로 생각하고 시작하였는데 그 2배~3배~10배로 소비하는것은 어리석은 일입니다.
"어떤 대가를 치르더라도 이 프로젝트를 수행해야해"와 같은 유형의 프로젝트는 대부분 없으며
우리의 프로덕트개발에 과부하를 주는것입니다. 새로운 프로젝트를 못할수도 있고더 중요한 일을 못하게 할수도 있기때문입니다.
Build
벳팅이 결정되면 빌드가 시작됩니다. 이때 우리는 Task가 아닌 프로젝트만 할당합니다.
6주치의 Shape를 기반으로 개발/디자이너에가 자율적으로 일을할수 있습니다. 중요한것은 빌드가 시작되고 완료될때까지 어떠한 방해요소가 없는 환경이 중요하며
이것이 릴리즈가 안되면 Shape과정에 문제가 있나? 검토는 할수 있겠지만
원칙은 더이상 진행하지 않고 중단이 되기때문에 빌드에 참여하면 완수하기위해 모두가 개발해야할 기능에대해 오너쉽을 가져야합니다.
회의는 독이다.
최악의 방해 요소는 회의다. 이 유는 다음과 같다.
- 말과 추상적인 개념뿐 실질적인 것이 없다.
- 들인 시간에 비해 전달되는 정보량이 지극히 적다.
- 삼천포로 빠질 때가 너무 많다.
- 일에 차질을 빚을 만큼 준비 시간이 오래 걸린다.
- 도대체 무엇을 위한 회의인지 모를 정도로 의사의정이 불분명할 때가 많다.
- 얼토당토않은 말로 시간을 낭비하는 사람이 꼭 한명씩 있다.
- 회의는 회의를 낳는다. 회의에 회의가 꼬리를 문다
회의의 숨은 비용까지 다 따지면 실로 엄청나다. 10명이 1시간회의를 하면 10시간의 생산성을 포기하는 셈이다.
그리고 하던 일을 멈추고 회의장으로 갔다가 다시 돌아오는 시간까지 계산하면 15시간 이상의 손해일수 있다.
15시간은 2md에 해당하며 이것을 포기할 만한 가치가 있을까? 때로는 그럴 수도 있다. 하지만 대가가 너무 비싸다.
사업주로서 저는 직원들의 시간과 관심을 보호하는 것이 제가 할 수 있는 가장 중요한 일 중 하나라는 것을 깨닫게 되었습니다.
예를 들어 Basecamp에는 상태 회의가 없습니다. 우리 모두는 이러한 회의를 알고 있습니다. 한 사람이 잠시 이야기하고 몇 가지 계획을 공유한 다음 다음 사람이 같은 일을 합니다. 그들은 시간 낭비입니다. 왜? 모든 사람을 동시에 모으는 것이 효율적인 것처럼 보이지만 그렇지 않습니다. 한 방에 8명이 한 시간 동안 머무르는 데에는 한 시간의 비용이 들지 않습니다. 8시간이 소요됩니다.
대신, 우리는 사람들에게 Basecamp에 매일 또는 매주 업데이트를 작성하여 다른 사람들이 여유 시간이 있을 때 읽을 수 있도록 요청합니다. 이를 통해 일주일에 수십 시간이 절약되고 사람들에게 중단 없이 더 많은 시간을 제공할 수 있습니다. 회의는 시간을 "이전"과 "이후"로 나누는 경향이 있습니다. 그러한 회의를 없애면 사람들은 갑자기 업무에 몰입할 수 있는 충분한 시간을 갖게 됩니다.
나는 사람들에게 실제로 일주일에 40시간을 할애한다면 일주일에 40시간이면 훌륭한 일을 완수하기에 충분하다고 믿습니다. 40달러를 받고 그들에게 12달러만 주는 것은 누군가에게서 일주일에 28시간을 훔치는 것과 같습니다. Basecamp에서는 40시간이 40시간을 의미하도록 하는 방향으로 상당한 진전을 이루었습니다.
누군가를 고용한다고 해서 그 사람을 소유하는 것은 아니라는 점을 기억하십시오. 근무 주간을 "회사 시간"으로 생각하면 이를 회사 소유의 시간으로 바꾸는 것입니다. 하지만 실제로는 회사 시간이 아닙니다. 회사를 위해 일하는 것은 직원의 시간입니다. 회사는 회사의 시간을 빌리는 것이 아니라 사람들의 시간에 대한 대가를 지불하는 것입니다. 의미론처럼 들릴 수도 있지만 실제로는 사고에 있어 꽤 급진적인 변화가 필요합니다.
- REWORK중
CoolDown
빌드가 완성되면 빌드에 참여한 담당자는 2주간의 휴식기를 가지게 됩니다. 휴가를 의미한다기보다 정비에 가까우며
개인의 통제된 환경에서 자기개발을 할수도 있고 Shape를 작성하는 제너럴리스트의 벳팅이 진행중이기 때문에
다음에 해야할것에 대해 기술준비를 할수도 있습니다. 이 기간이 끝나면 다시 Build가 시작됩니다.
여기 저기 몇 가지 참고자료 외에 Shape Up의 쿨다운에 대한 전체 설명은 다음과 같습니다. 6주 주기를 연속으로 실행한다면 숨을 쉬고 다음 단계에 대해 생각할 시간이 없을 것입니다. 주기의 끝은 회의를 하고 계획을 세우기에 최악의 시간입니다. 왜냐하면 모두가 제 시간에 맞춰 배송하기 위해 프로젝트를 끝내고 막판 결정을 내리느라 너무 바쁘기 때문입니다. 따라서 각 6주 주기가 끝나면 2주간의 휴식 시간을 계획합니다. 정해진 일 없이 숨을 쉬고, 필요에 따라 만나고, 다음에 무엇을 할지 고민할 수 있는 기간입니다. 휴지 기간 동안 프로젝트 팀의 프로그래머와 디자이너는 원하는 작업을 자유롭게 수행할 수 있습니다. 6주간의 프로젝트를 출시하기 위해 열심히 일한 후 그들은 자신이 통제할 수 있는 시간을 보내는 것을 즐깁니다. 버그를 수정하고, 새로운 아이디어를 탐구하거나, 새로운 기술적 가능성을 시험하는 데 이를 사용합니다.
Shape Up에는 와일드 사이클 길이를 위한 공간이 많지 않으므로
4주 주기마다 1주간의 쿨다운 또는 6주 주기마다 2주간의 쿨다운이 합리적으로 보입니다.
회복 시간은 사이클의 에너지 출력 기대치와 일치해야 합니다.
8주간의 주기를 가지지만 휴지 기간은 1주일뿐이라면 팀은 대신 해변에서 시간을 보내는 것이 좋습니다!
BaseCamp의 일하는방식인 ShapeUp에 대해 간략하게 알아보았습니다. 작은기업을 사랑한다는 문구가 홈페이지 있으며
중소기업규모 정도이며 B2B 스몰비즈니스 대상 Sass제품의 개발방법론인점을 참고하면 더 도움될것같습니다.
B2B Small비즈니스에 성공경험을 가진 방법론으로 규모및 환경과 성장에따라 적합한 방식이 각각 있을것으로 여겨지며
유니콘이 등장하면 성공방적식인것처럼 유행처럼 따라가게 되는데 다양한 규모, 다양한 비즈니스 타켓에 대한 개발방법론이 등장해
선택지가 다양해졌으면 좋겠습니다. 선택지라기보다 성장하면서 우리만의 방식을 찾아가는것이 더 어울릴것같습니다.
도메인은 발명이 아니라 발견이다. - DDD중
좋은팀이 오래가는것이 아니라, 오랫동안 성장한 팀이 좋은팀이다. - 애자일중
Part 3 Building단계에 대한 세부적인 내용은 제외되었으며 자세한 내용은 참고링크에 있는 원문 아티컬을 권장하며 마칩니다.ShapeUp에대한 자세한 내용은 참고링크에 있는 원문 아티컬을 권장합니다.
원문링크 :
...