Shape Up 프로세스에 대한 생각
2023년 07월 15일 작성TL;DR
큰 자유도는 큰 책임을 수반하며, 현실적으로 일반적인 스타트업은 그것을 감당할 능력이 없다.
일반적인 스타트업이라면 린 스타트업에 스크럼이나 칸반 정도를 섞어서 시작하자.
시작하며
최근 프로세스를 개선하기 위해서 여러 책과 문서들을 읽다가 쉐이프 업(Shape Up) 이라는 책을 알게 되었다.
현재 프로토타이핑 팀은 4주간 요구사항을 분석하고, 4~6주간 빌드를 하는 식으로 빌드를 하고 있다. 쉐이프 업은 이 방식과 거의 동일하게 설명하면서도 좀 더 체계적이라 엄청 흥미가 생겼다.
프로토타이핑 팀에서 일하는 방식을 프로덕션 개발에도 적용할 수 있다면 고객의 문화나 조직구조를 바꾸는 데도 영향을 끼칠 수 있지 않을까 하는 기대로 책을 읽게 되었다.
본 글에서는, 조직에서 쉐이프 업을 도입하려고 할 때 생각해볼만한 내용만 몇가지 적어본다.
쉐이프 업 요약
개인적으로 라이언 싱어의 원래 영상1 보다 위의 영상이 좀 더 쉽게 설명한거 같다.
쉐이프 업은 애자일을 쓰고 있는 스타트업에서 초기 스타트업의 역동성을 회복하기 위한 방법으로 나왔다.
초기 스타트업은 소수의 인원이 문제에 대해 완전한 컨텍스트를 공유한 상태로 프로세스 없이도 빠른 시간안에 빌드가 가능했다. 이를 가능하게 하는 것은 완전한 컨텍스트 공유를 기반으로 한 높은 자유도 이다.
쉐이프 업은 fixed time, variable scope 이라는 원칙으로 프로세스를 구성하여, 높은 자유도를 기반으로 한 프로세스의 리스크를 관리하려고 한다.
쉐이프 업은 쉐이핑(Shaping), 베팅(betting) 그리고 빌딩(building) 단계로 이뤄지고, 크게 아래와 같이 설명할 수 있을 것 같다.
- 주어진 비즈니스 문제에 대해 6주간 분석하고(쉐이핑) 피치(pitch)라는 형태의 문서로 만들어낸다.
- 이 피치 문서를 기반으로 얼마만큼의 시간을 할애해서 풀지 (혹은 안풀지) 베팅을 한다.
- 베팅된 피치를 팀에서 가져가서 6주간 빌딩하여 결과물을 만든다.
생각해볼 점
앞서 말한대로, 쉐이프 업은 현재 사용 중인 프로토타이핑 프로세스와 거의 일치하기 때문에 기존 프로세스에 적용할 수 있거나 개선할 수 있는 인사이트를 얻기를 원했다.
이런 관점에서 생각해볼만한 점들을 정리해 봤다.
배경
- 쉐이프 업은 디자이너로 시작한 개발자 겸 프로덕트 매니저가 Basecamp 의 상황에 맞춰 발전시킨 프로세스를 정리한 내용이다.
- 개인적으로 다른 애자일 프로세스들 보다 쉐이프 업에서의 디자이너 역량이 훨씬 더 중요해보인다. 쉐이프 업에서 디자이너는 다루는 제품과 UX 에 대한 기본적인 이해를 가지고 있어야 한다. 따라서 경력이 없는 디자이너는 어떤 페이즈에도 단독으로 참여할 수 없다.
- 디자이너 센트릭한 프로세스 이므로 기술문서들에 대한 내용이 빠져있다. 실제 장기 프로젝트 운영시 팀간의 소통이나 새로온 사람이 기능을 파악하기 위한 기술문서는 매우 중요하다.
- 또한 피치 문서는 드래프트에 가까우며 현실적으로는 빌드 페이즈에 새롭게 수정되거나 발견되는 내용들은 빠질 수 밖에 없는데, 이런 부분은 다루지 않는다.
- Appetite 는 프로세스를 위해 의도해서 만든 것이 아니라 현실과의 타협에 대한 결과이다.
- 개발자가 유명인 (루비온 레일즈 창시자)이라 쓸 수 있는 시간에 제약이 있었기 때문에 시간을 커밋하는 Appetite 라는 방식을 도입하게 되었다.
- 따라서 풀타임으로 개발자들을 보유하는 회사에서는 해당 방식에 대한 저항이 있을 수 있다.
- 또 37signals 라는 회사는 리워크, 리모트 라는 책을 쓴 회사이다. 리모트는 업무에 대한 자율성이 매우 중요한 업무 방식이며, 이미 회사의 문화가 그런 부분에 충분히 성숙해있다는 점도 고려해야한다.
- 소규모 스타트업의 장점을 대규모에서 되살리기 위한 방식이기 때문에, 대규모 서비스를 만드는 엔터프라이즈 급 회사에서는 적용하기 어렵다.
- 초기 스타트업은 소규모 팀이 작은 컨텍스트를 공유하면서 일하기 때문에 문서나 티켓을 거의 만들지 않고도 작업이 완료될 수 있다. 규모가 커져도 계속 이렇게 일 할수 없을까?
- 회사가 커질수록 다루는 문제가 더 복잡해지고 커지기 때문에 쉽지 않은 경우가 많다. 팀의 구성과 코드 베이스가 모두 autonomous 할 수 있게 지원되지 않으면 불가능하다.
- 또한 완벽한 설계는 없기 때문에, 종종 디펜던시 문제가 생길 수 밖에 없다. 대규모 시스템은 그럴 가능성이 더욱 높다. 책에서 말한대로 버그는 천천히 대응할 수 있지만, 다른 팀의 디펜던시는 그렇지 않을 수 있다. 이런 부분을 사전에 파악하지 못하면 빌드 페이즈에 인터럽트가 많이 발생할 수 밖에 없고, 원하는 결과를 빌드할 수 없게 된다.
회사의 특성
- 먼저 Basecamp 는 bootstrapped 회사다. 즉 일반적인 회사들과 다르게 VC 투자를 받지 않았다.
- 따라서 피쳐를 개발하는 프로세스를 매우 자유롭게 정할 수 있다. VC 투자를 받은 회사(대부분의 한국 회사)는 2주 쿨다운 등의 여유(?) 를 부릴 수가 없다.
- 꽉꽉 짜여서 움직이는 스크럼 방식이 훨씬 회사 입장에서 효과적으로 보일수 밖에 없다.
- Basecamp 는 20년된 회사다. 애초에 본인들의 문제를 해결하기 위해 만든 협업툴이므로 스스로가 고객이기도 하다. 따라서 일반적인 스타트업과 다르게 고객전문가를 보유하고 있다.
- 애자일 프로세스가 전제하는 것도 고객전문가를 보유하고 있다는 점이다. 만약 고객전문가를 회사가 보유하고 있지 않다면(대부분의 스타트업) 린 스타트업을 사용하는 것이 훨신 유효한 전략일 것이다.
- 여튼 이런 전제 때문에 요구사항 분석에 대해 잘못된 제품을 만드는 부분은 커버하지 않는다.
- 쉐이프 업은 애자일을 대체할 수 있는 프로세스이며, 린 스타트업과 함께 써볼 수 있는 보완재라고 볼 수 있다.
- Basecamp 는 개발자와 디자이너 비율이 거의 1:1에 가까운데, 이는 Autonomous Team 을 만들기 위해서 필수적인 내용이다.
- 실제로 프로젝트 진행할 때도 개발자 2, 디자이너 1 정도의 비율로 팀이 구성되어서 빌드한다고 한다.
- Basecamp 는 시니어와 주니어의 비율이 비슷하거나, 시니어의 비율이 높다. 이는 Autonomous 해야하는 쉐이핑과 빌드 페이즈에 큰 영향을 끼친다.
기타
- 꼭 쉐이핑을 한 사람이 빌드를 할 필요는 없다.
- 책에서도 시니어 개발자와 디자이너들이 모여서 쉐이핑을 충분히 하고 팀에게 할당한다고 되어 있다.
- 시니어의 매니지먼트 부담을 줄여준다고 주장한다.
- 태스크 단위로 개발하는 것이 아니라 컨텍스트를 완전히 공유한 상태로 작은 팀이 작은 문제를 해결하는 솔루션을 개발하기 때문에, 마이크로매니지먼트를 하지 않아도 된다고 한다.
- 하지만 실제로는 팀의 결과물을 책임지는 것이 시니어이므로 부담이 없을 수 없다.
- 특히 팀 구성원이 주니어가 껴 있으면 주니어의 문제를 같이 봐주면서 개발하게 되면 속도가 같이 느려질 수 밖에 없는데, 베팅 시점에 기간이 이미 결정되었기 때문에 시니어가 팀원의 능력을 어느정도 파악하고 있지 않으면 무조건 일정이 지연된다.
마치며
잡 플래닛의 많은 스타트업 리뷰에서 체계가 없다는 이야기를 많이 본다.
그러나 해당 회사들은 사실 슬랙, 지라, 컨플루언스 등을 쓰고 업무의 프로세스가 있고, 실제로 뭔가 일이 진행되고 있는 회사들이다.
하지만 구성원들은 여기에서 일하면서 체계가 없다는 평가를 한다. 왜일까?
여러가지 이유가 있겠지만, 개인적으로는 아래 문제가 제일 크지 않을까 한다.
일을 할때 기존 프로세스를 무시하고 맘대로 하는 사람이 있지만(특히 높은 사람들) 아무런 불이익이나 제재가 가해지지 않는다.
프로세스는 각 구성원들이 각자가 다루는 다양한 변수들을 예측 가능한 상수로 만들기 위해, 커뮤니케이션을 용이하게 해주는 회사내의 합의이다.
그리고 이 프로세스에서의 합의는 교차로의 신호등과 같이 어느정도의 유연함을 가진 규칙이기 때문에 단순히 합의를 종종 어기는 것 만으로는 체계가 없다는 느낌을 받지는 않는다고 생각한다.
예를 들어, 교통체증이 심하지 않을땐 노란불일 때 꼬리를 살짝 물어도 전체 트래픽에 영향을 주지 않지만, 어떤 경우에는 꼬리물기한 몇대의 차량 때문에 전체 교차로가 차로 가득찰 수도 있다.
후자와 같이 막힌 트래픽을 적절히 관리해야하는 신호체계의 수호자 같은 사람들이, 아무런 역할을 하지 못하거나 오히려 적극적으로 트래픽을 방해하는 경우에, 구성원들은 체계가 없다는 평가를 하게 된다.
프로세스는 어떠한 의도를 가지고 만들어진다. 의도를 명확히 이해하고 있으면 어떤 경우에 프로세스를 지키고 어떤 경우에 어느정도 어겨도 되는지를 확신을 가지고 판단할 수 있다.
따라서 단순히 좋은 프로세스를 복붙해서 써서는 원하는 효과를 얻을 수 없다. 모든 구성원에게 특정 프로세스를 사용하는 의도를 이해시키는 것이 먼저이고, 이 의도는 회사차원에서 중요하게 여기는 가치와 부합해야만 비로소 체계가 없는 회사에서 벗어날 수 있을 것이다.