Shape UP

과거 몇년간 어떻게 작은 팀으로, 높은 품질의 소프트웨어를 그렇게 빨리 개발해내는지 물어보곤 했다. 또, 개발자들을 오랫동안 유지하는지도.

• 첫째 우리는 워터폴, 애자일, 스크럼같은 프로세스에 얽매이지 않았다.
• 둘째, 우리는 벽에 포스트잇을 줄세우지 않았다.
• 셋째, 우리는 데일리 스탠드업, 스프린트, 백로그, 칸반, 벨로시티 체킹등 어느 것도 하지 않았다.

우리는 우리의 길을 만들었다. 

기존 일하는 방식의 한계

소프트웨어팀이 성장하면서 유사한 문제점들이 생겨난다.

- 팀원들은 프로젝트가 끝없는 행군처럼 느껴진다.

- 프로덕트 매니저들은 프로덕트에 대해 전략적으로 생각할 시간을 낼 수가 없다.

- 창업자들은 자문한다. 왜 우리는 예전에 했던 것처럼, 신속하게 기능을 출시할 수가 없을까?

처음에는 애자일 방법론중 하나인 스크럼을 도입하여스프린트를 2~3주 정하고 백로그를 관리하면서 릴리즈하고

우리의 프로덕트가 지속 발전한다고 느꼇다. 이것은 워터폴과도 상관없다

우리의 일하는 방식의 문제이며 다음과 같은 문제들이 있었다.

•  관리
  • PM은 관리하느라 바빠서 전략적 생각 못함
• 기획
  • 치밀하지 못한 기획으로 지연됨
• 개발
  • 제대로 한경우 : 끝없는 행군으로 느껴짐
  • 제대로 하지못한경우 : 사일로 문제에 직면할때 스프린트내에 아무런 일이 없을수 있습니다. 
• 종합
  
  • 정신없고 일이 끝없다 느낌
  • 2주는 의미있는 것을 구현하기 기간이 짧음

우리는 4명에서 50명으로 늘어나면서 이런 문제에 직면했다. 사람 수가 늘어나면서창업자들의 직관을 전달하기가 어려워졌다. 그래서 새로운 스케일에 맞는 구조가 필요했으며

다음과 같은것을 시도 하였다.

• 기한 내에 리스크 최소로 구현을 완료하자
• 집중과 휴식을 번갈아가며 6주-2주 주기로하자
• 기한 내 못할 것은 현명하게 포기하고 필수적인 것을 만들자
• 개발자, 디자이너가 자율성 높게 일할 수 있게하자.

Shpae UP Life Cycle

SHAPE를 지속적으로 하는팀과 Build를 지속적으로 해야하는 팀이 있습니다.

• Out Of Cycle : Shape에 대한 아이디어를 지속 발굴해야하는 제너럴리스트(PM/기획)및 벳팅을 결정하는 C레벨이 포함될수 있습니다. 또한 핵심문제발견시 해결방법을 찾아야하는 스페셜리스트(아키텍트/DBE)가 포함될수도 있습니다. 
• In Cycle : 사이클에 영향을 받는쪽이며 개발 실무진이 해당할수 있습니다. 

우리의 결정은 시간을 세세하게 관리하는 것이 아니라 향후 6주 내에 제품을 발전시키는 것을 기반으로 합니다. 이 기능이 6주후 출시되면 행복한것이며 , 못했을때 가장 큰 리스크역시 6주입니다.

• BET : 벳팅단계에서는 task/Epic등 백로그에서 선택하는것이 아닌 어느정도 모습이 갖춰진 SHAPE를 벳팅테이블에 올려놓고 선택합니다.
• BUILD : 베팅이 되었다면 SHAPE 는 6주내에 꼭 배포가 되어야합니다.  작은기능인경우  2주내에 배포될수도 있습니다. 꼭 6주뒤 모두배포해야함을 의미하지는 않습니다.
• COOL DOWN : SHPAE가 런칭이 되면 COOL DOWN시간을 가집니다.

일감을 측정하기 - 언제까지 되나요?

• Estimate : 이것이 언제까지 될까요? 러프하게 추정
• Appetite : 시간을 정해놓고 우리가 꼭해야할것이 무엇인가? 조정

ShapeUp에서는 Appetite방식을 사용하여 해야할 일을 조정합니다.

Calendar View 기능을 출시하기

고객이 캘린더 뷰를 원했다. 구글캘린더 처럼 만들면 되겠지하고 하고 접근하였다.

구글캘린더에는 좋은 기능들이 많았고  다음과 같은 예상기능들이 있었다.

• 등록 이벤트를 드래그앤 드랍으로 이동하기
• 스케쥴을 월별 주별 비교하기
• 스케쥴의 기간을 보기
• 이벤트마다 색상을 입히기
• ...... 그리고 차별성을 위한 

구글캘린더처럼 만들지도 못하는데 이것을 만드는데는 6개월이상이나 측정이 되었고

여기서 우리는 이것을 또 할지 말지결정합니다.

• 6개월동안이나 만들어야하는가? 우리는 구글캘린더와 경쟁을 하나?

우리는 6주라는 시간을 정해놓고  필요한것만 하기로 하였습니다. 그러다보니 고객이 진짜 원했던것은 자신이 등록한 스케쥴을 확인하는 것이였으며

불필요한 나머지를 모두 제거하여 6주내에 출시하였습니다.  

기획여정

문장은 아이디어를 빠르게 던질수 있지만 너무 추상적이고 Wireframe은 이 기능을 만들지 말지

결정하지도 못했는데  엄청난 시간을 들이며 결정적으로 최종으로 만들어야할 제품과 일치하지 않습니다.

그래서 우리는 너무 추상적이지도 않고 그렇다고 디자인적으로 너무 구체적이지는 않는 중간지점에 있는

우리의 프로덕트가 변화해야할 SHAPE에 대해 고민을 하였습니다.

Shape 주요 3단계 절차및 속성

1. Rough
   1. 러프한것은 누구든 미완성이란것을 알고 있습니다.  너무 구체적이지 않아도 이것으로 충분합니다.
   2. 미완성인 내용으로 얼마나 소요될지 추정할 필요가 없습니다.
2. Sloved
   1. 우리가 만드려는 기능의 핵심(Core)에 대한 해결방법이 존재해야합니다. 그것이 없으면 Shape는 완성될수 없습니다.  
   2. WireFrame단계에서 가능한지 안가능한지 검토하는것이 아닌 그 이전에 해결방법을 찾아야함을 의미합니다.
3. Bounded
   1. 우리의 시간은 제약적입니다. 이것을 시간내에 해야할 경계를 정하는것이 중요합니다.
   2. 꼭 해야할것과 했으면 좋은것을 분리합니다. 하지만 중요한것은 하지말아야할것을 정의함으로 경계를 만듭니다.
   3. 하지말아야할것이 꼭 불필요한것은 아닙니다. 이것을 정의하지 않으면 우리의 상상력으로 수많은 하지말아야할것을 만들기때문입니다.
   4. 했으면 하는것을 못했을때 우리는 백로그에 쌓지 않습니다. 중요한것은 언젠가 다시 할수 있게됩니다.  

위 3단계가 완성되었을때 Shape가 완성됨을 의미하고 벳팅 테이블에 올려놓습니다.

백로그를 선택하고 시간을 러프하게 추정하고 그 이후 해결방법을 찾는 일하는 방식과의 차이가 있습니다.

백로그는 우리가 짊어질 필요가 없는 무거운 것이다. 수십개에서 시작해서 결국 수백개에 이르는 우리 모두 절대 할 일이 없어보이는 태스크들이다. 쌓여가는 무더기는 실제로는 그렇지 않음에도 우리가 늘 뒤쳐져가는 느낌을 준다. 누군가가 한분기 전에 중요하다고 생각했던 아이디어라고 할지라도, 그게 우리가 매번 들여다보고 또 볼 필요가 있다는 걸 의미하지 않는다. 백로그는 엄청난 시간 낭비를 초래한다. 지속적으로 리뷰하고 우선순위를 매기는 일들이 지금 정말 중요한 일을 진행하는 것을 방해한다.

장기 계획은 세우지마라 ( 1년로드맵과 같은것 )

사업 계획이라는 말 자체가 어불성설이다. 사업추측이라면 또 모를까. 재무계획은 재무 추측으로 

전략 계획은 전략 추측으로 바꿔야 옳다. 이렇게 명칭을 바꾸고 나면 얼마나 편한지 모른다.

계획을 세우면 그 계획에 질질 끌려다니지만 , 추측은 기회를 잡기위해 다음과 같이 조정할수도 있다.

"이제 보니가 이쪽이 아니라 저쪽이 맞는군." 때로는 이렇게 되어야한다.

이것이 미래에 대해 생각하지 말라는 말은 아니며 장애물을 어떻게 다룰지 고민을 하라는 이야기다.

-Rework 중 

WireFrame을 작성하고 고치는 시간은 오래걸리기 때문에  Shape단계에서 이벤트스토밍을 위해

BreadBoarding / FetMerket Sketch  방법도 소개합니다.

BreadBoarding

산업디자인이 포함되지 않은 전기 공학의 브레드보드의 아이디어를 사용합니다. 이것은 재질이 뭔지 손잡이가 뭔지를 이야기하는것과 다릅니다.

어떻게 키고 켜고 그다음 어떻게 작동하는지 인터페이스에대한 아이디어입니다. 그리고 이것은 UX고려없이 빠르게 프로토타입화 될수 있습니다.

Fat Market Sketch

우리가 염두에 두고 있는 아이디어는 시각적인 것입니다. 브레드보드에서는 요소의 2D 배열이 근본적인 문제이기 때문에 요점을 놓칠 수 있습니다. 이 경우에도 우리는 와이어프레임이나 불필요한 충실도에 시간을 낭비하고 싶지 않습니다. 대신 우리는 두꺼운 마커 스케치를 사용합니다. 굵은 마커 스케치는 세부 사항을 추가하는 것이 어렵거나 불가능할 정도로 넓은 획으로 만든 스케치입니다. 우리는 원래 종이에 더 큰 끝이 있는 Sharpie 마커를 사용하여 이 작업을 수행했습니다.

Risk And Rabbit Holes

토키굴에 빠지지 않기~ 이상한 나라 엘리스에의 토키굴을  의미하며 한번빠지면 나오는데 너무 오랜 시간이 걸림을 의미합니다.

우리가 원했던것

실제

• 토키굴을 찾지 못하면 우리의 릴리즈는 더 늘어나게됩니다. 이때 과부하가 되지 않도록 Circuit Breaker를 발동합니다.

The Betting Table

6주동안 무엇을 할지 벳팅을 하고, 이것이 성공하면 2주간의 CooDown시간을 가집니다.

이 기간에는 자유롭게 일을 수행합니다.  새로운 아이디어를 탐구하거나 새로운 기술적 가능성을 시험할수 있습니다.

이것이 꼭 휴식을 의미하지 않으며 정비에 가깝습니다.

기업은 경쟁을 좋아한다. 밟고 이기고, 1 or 0으로 만들길 원한다. 스포츠처럼 이기고 지고를 비교하면 우리는 항상 지는 게임을 하고 있으며 패배자 이다.

즉 우리가 가진 이메일 솔루션인 hey를 구글의 gmail의 사용자수와 비교하지 않는다. 하지만 우리는 장님은 아니여서 언제든 알수는 있고 누구든 열람할수 있다.

나는 다른 누군가와 경쟁하는 것에 흥미가 없다. 그리고 우리는 경쟁적인 관점에서 결정을 내리지도 않는다.

내 마음속엔 중요한 지표가 하나 있다. 이건 숫자가 아니라 느낌이라고 표현할 수 있다.

'나는 이것을 또다시 하고 싶을까? (Would I want to do that again?)'

이 단순한 질문 하나로 수많은 질문은 의미가 없어진다. 그리고 이에 대한 심플한 답 하나가 다른 모든 것에 해답이 된다.

상황에 따라 다양한 형태로 답할 수 있겠지만 결국 심플한 YES or NO Question이다. 물론 가장 좋은 대답은 Hell Yeah! 와 Hell No! 다.

이렇게 질문하는 것은 빠르게 핵심을 꿰뚫고 실체를 드러나게 만든다.

회사의 성장을 위해 중요한 가치나 품질을 희생하는 것은 위험하며 성공한 회사란 꼭 큰 회사를 의미하지 않는다.

올바른 규모의 회사를 만드는 것이 중요하다. 우리는 회사에 꼭 필요할 때만 채용을 하고, 조심스럽게 성장을 통제하는 방향을 선택하였다. 

남들에게 실패일지라도 은퇴할때까지 우리의 제품을 작게 유지할수 있어도 우리에게는 이것도 성공이라고 본다. 

• 베이스 캠프의 벳팅 철학 

NewProduct

새로운 제품은 다릅니다. 기존 제품에 추가하는 것은 고정된 치수의 방에 소파를 구입하는 것과 비슷하지만, 신제품 개발은 건물이 서 있을 수 있도록 벽과 기초가 어디로 가야 하는지 파악하는 것과 같습니다. 우리는 처음부터 새로운 제품을 만들 때 세 가지 작업 단계를 살펴보았습니다. 각 단계마다 우리가 형성하는 방식과 주기 동안 팀이 어떻게 협력할 것인지에 대한 기대치가 다릅니다. 이러한 단계는 여러 사이클에 걸쳐 전개되지만 우리는 여전히 한 번에 하나의 사이클만 베팅합니다.

ShapeUP은 주로 기존 프로덕트에서 성장하는 과정에서 신규기능을 확장하는 방법에 관한것이며

새로운 프로덕트의 경우 베팅방식이 달라야하며 R&D모드로 전환되게 됩니다.  첫 출시이후 ShapeUP의 과정으로 전환됩니다.

새로운 팀을 빌드하고 새로운 방식을 채택 할수도 있는 부분이여서 이 부분에대한 부분은 다루지 않았습니다.

대기업 고객은 매력적일 수 있지만 제품, 직원 및 비즈니스 안정성을 뒤집어 놓을 수 있습니다. 수년에 걸쳐 우리는 우리가 깊이 존경하는 여러 회사에 거절을 했습니다. 우리는 소수의 대기업에 모든 위험을 투자하고 싶지 않습니다. 우리는 하나의 큰 계정이 없어져도 비즈니스의 20%를 잃고 싶지 않습니다.  우리는 우리가 그토록 사랑하는 중소기업을 희생시키면서 대기업이 선호하는 방향으로 제품을 밀어붙이고 싶지 않습니다.

• Base캠프의 제품방향에 대한 철학

The circuit breaker

팀은 우리가 베팅한 시간 내에 배포를 해야합니다. 이것이 지켜지지 않으면 우리는 더이상 프로젝트를 확장하지 않습니다.

프로젝트의 가치를 6주로 생각하고 시작하였는데 그 2배~3배~10배로 소비하는것은 어리석은 일입니다.

"어떤 대가를 치르더라도 이 프로젝트를 수행해야해"와 같은 유형의 프로젝트는 대부분 없으며

우리의 프로덕트개발에  과부하를 주는것입니다. 새로운 프로젝트를 못할수도 있고더 중요한 일을 못하게 할수도 있기때문입니다.

원문링크 :

• https://basecamp.com/shapeup
• https://world.hey.com/jason