Page History
...
처음에는 애자일 방법론중 하나인 스크럼을 도입하여스프린트를 2~3주 정하고 백로그를 관리하면서 릴리즈하였고
소규모일때는 잘작동하는것으로 보여 졌지만 4명에서 50명으로 늘어나면서 다음과같은 문제에 직면했다.
...
사람 수가 늘어나면서창업자들의 직관을 전달하기가 어려워졌다. 그래서 새로운 스케일에 맞는 구조가 필요했으며
다음과 같은것을 같은 원칙을 세우고 개발방법론을 조금씩 프로덕트의 성장과함께 개발방법론도 함께 개선을 시도 하였다.
- 기한 내에 리스크 최소로 구현을 완료하자
- 집중과 휴식을 번갈아가며 6주-2주 주기로하자
- 기한 내 못할 것은 현명하게 포기하고 필수적인 것을 만들자
- 개발자, 디자이너가 자율성 높게 일할 수 있게하자.
그리고 이것은 Shpe UP이란 우리만의 방법론을 출시하고 공유하기 시작했다.
BaseCamp가 만든 ShpeUP을 ShapeUP을 요약하여 살펴보겠습니다.
...
Shape UP Life Cycle
| draw.io Board Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Shpe UP의 사이클우리의 개발 사이클은 집중과 휴식을 번갈아가며 6주-2주 이다.
SHAPE를 지속적으로 하는팀과 Build를 지속적으로 해야하는 팀이 역할로 구분되어 있습니다.
- Out Of Cycle : Shape에 대한 아이디어를 지속 발굴해야하는 제너럴리스트(PM/기획)및 벳팅을 결정하는 C레벨이 포함될수 있습니다. 또한 핵심문제발견시 해결방법을 찾아야하는 스페셜리스트(아키텍트/DBE)가 포함될수도 있습니다.동시에 이것이 잘작동하게해야하는 사이클에 영향없는 제너럴리스트로 구성되어 있습니다.
- In Cycle : 사이클에 직접 영향을 받는 팀이며 개발 실무진이 해당할수 있습니다. 빌드를 해야하는 구성원입니다.
우리의 결정은 시간을 세세하게 관리하는 것이 아니라 향후 6주 내에 제품을 발전시키는 것을 기반으로 합니다.
이 기능이 6주후 출시되면 행복한것이며 , 못했을때 가장 큰 리스크역시 6주입니다.
- BET : 벳팅단계에서는 taskTask/Epic등 백로그에서 선택하는것이 아닌 어느정도 모습이 갖춰진 SHAPE를 벳팅테이블에 올려놓고 선택합니다올려놓습니다. C레벨에서는 TASK/EPIC이 아닌 어느정도 모습이 갖춰진 Shape를 선택할수 있습니다.
- BUILD : 베팅이 되었다면 SHAPE 는 6주내에 꼭 배포가 되어야합니다. 작은기능인경우 2주내에 배포될수도 있습니다. 꼭 6주뒤 모두배포해야함을 의미하지는 않습니다.배포가 되지 않으면 이것은 중단됩니다.
- COOL DOWN : SHPAE가 SHAPE가 런칭이 되면 COOL DOWN시간을 가집니다. 다음 SHAPE를 점검하거나 자기개발을 하거나 자신이 스스로 통제하여 자유의 시간을 가집니다.
일감을 측정하기 - 언제까지 되나요?
| draw.io Board Diagram | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
여기서 우리는 이것을 또 할지 말지결정합니다.
- 6개월동안이나 만들어야하는가? 우리는 구글캘린더와 경쟁을 하나?
우리는 6주라는 시간을 정해놓고 필요한것만 하기로 하였습니다. 그러다보니 고객이 진짜 원했던것은 자신이 등록한 스케쥴을 확인하는 것이였으며
그러다보니 이 시간내에 할수 있는 가장 중요한 아이디어가 나왔습니다.불필요한 나머지를 모두 제거하여 6주내에 출시하였습니다.
이것은 빠르고 완벽하하게 일해야하기가아닌
일해야하기가아닌~ 불필요한 일을 안하고 중요한 일만 일을 시간내에 꼭 해야하는것에 가깝습니다.
기획여정
| draw.io Board Diagram | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
문장은 아이디어를 빠르게 던질수 있지만 너무 추상적이고 Wireframe은 이 기능을 만들지 말지
결정하지도 못했는데 엄청난 시간을 들이며 결정적으로 최종으로 만들어야할 제품과 일치하지 않습니다못했는데 초본이 나오기까지 오랜시간이 걸리고 최종의 모습이 되기까지 수정또한 오랜시간이 걸리게됩니다.
그래서 우리는 너무 추상적이지도 않고 그렇다고 디자인적으로 너무 구체적이지는 않는 중간지점에 있는
우리의 프로덕트가 변화해야할 SHAPE에 대해 고민을 하였습니다.
Wireframe이 나쁘다라는것이아닌 여기에 우리의 아이디어를 즉각반영하고 수정하기에 너무 많은 시간이 걸린다란 점입니다.
Shape 주요 3단계 절차및 속성, 3단계를 통해 모습을 만들어갑니다.
- Rough
- 러프한것은 누구든 미완성이란것을 알고 있습니다. 너무 구체적이지 않아도 이것으로 충분합니다.미완성인 내용으로 얼마나 소요될지 추정할 필요가 없습니다.
- Sloved
- 우리가 만드려는 기능의 핵심(Core)에 대한 해결방법이 존재해야합니다. 그것이 없으면 Shape는 완성될수 없습니다.
- WireFrame단계에서 가능한지 안가능한지 검토하는것이 아닌 그 이전에 해결방법을 찾아야함을 의미합니다.
- Bounded
- 우리의 시간은 제약적입니다. 이것을 시간내에 해야할 경계를 정하는것이 중요합니다.
- 꼭 해야할것과 했으면 좋은것을 분리합니다. 하지만 중요한것은 하지말아야할것을 정의함으로 경계를 만듭니다.
- 하지말아야할것이 꼭 불필요한것은 아닙니다. 이것을 정의하지 않으면 우리의 상상력으로 수많은 하지말아야할것을 만들기때문입니다.
- 했으면 하는것을 우리는 백로그에 쌓지 않습니다. 중요한것은 언젠가 다시 할수 있습니다.
위 3단계가 완성되었을때 Shape가 완성됨을 의미하고 벳팅 테이블에 테이블에 올려놓습니다.
백로그를 선택하고 시간을 러프하게 추정하고 그 이후 해결방법을 찾는 일하는 방식과의 차이가 있습니다.
...
장기 계획은 세우지마라 ( 1년로드맵과 같은것 )
사업 계획이라는 말 자체가 어불성설이다. 사업추측이라면 또 모를까. 재무계획은 재무 추측으로
전략 계획은 전략 추측으로 바꿔야 옳다. 이렇게 명칭을 바꾸고 나면 얼마나 편한지 모른다.
계획을 세우면 그 계획에 질질 끌려다니지만 , 추측은 기회를 잡기위해 다음과 같이 조정할수도 있다.
"이제 보니가 이쪽이 아니라 저쪽이 맞는군." 때로는 이렇게 되어야한다.
이것이 미래에 대해 생각하지 말라는 말은 아니며 장애물을 어떻게 다룰지 고민을 하라는 이야기다.
-Rework 중
WireFrame을 작성하고 고치는 시간은 오래걸리기 때문에 Shape단계에서 아이디어 스토밍을 위해
WireFrame의 대안으로 BreadBoarding / FetMerket Sketch 방법도 소개합니다.
...