Basecamp의 제품 개발 프로세스, Shape Up

이번주 가장 많이 읽은 브런치스토리 Top 5!

Intro

안녕하세요!

"이렇게 만들어졌어요" 뉴스레터는 IT 스타트업들이 어떻게 제품을 만들었는지, 팀 구성은 어땠는지 살펴보며 성공 요인을 알려드려요!

이번 주에는 Basecamp의 제품 개발 프로세스인 Shape Up에 대해 이야기해볼게요.

이번 뉴스레터는 아래 내용을 바탕으로 작성했어요.

A better way to plan, build, and ship products | Ryan Singer (creator of “Shape Up,” early employee at 37signals)

Shape Up

일정 계획 없이 상품 개발하는 법 — Shape Up

Relate 팀 제품 개발 프로세스, Shape Up

함께 읽고 싶은 글이 있다면 언제든 pm.marcus0218@gmail.com 으로 보내주세요.

여러분의 피드백과 참여가 이 뉴스레터를 더욱 풍부하게 만들어 줄 것입니다.

많은 관심과 응원 부탁드립니다!

✍️ 한 줄 요약

제품을 개발하는 방법론은 정말 많은 것 같아요. Waterfall, Agile, Lean,… Shape up은 원래 생산성 소프트웨어를 만드는 Basecamp에서 사용하는 제품 개발 방법론을 담은 책이에요. 이 방식은 2주 단위의 스프린트와 다르게 총 6주 기간으로 유의미한 기능을 만들어 낼 수 있을 만큼 긴 시간을 제공하면서 각자에게 자율성을 부여하는 방식으로 생각하면 이해하기 쉬워요. Shaping, Betting, Building의 과정을 거치기 때문에 단순히 2주 단위의 스프린트를 3번 운영하는 것과는 차이가 있어요.

📌 핵심 내용

1️⃣ Shape Up 이해하기

Basecamp 창업자 중 한 명 Ryan Singer는 Basecamp를 만들 당시, 팀 내 개발자가 일주일 동안 개발할 시간이 10시간 밖에 없었다고 해요. 그렇기 때문에 정말 필요한 것만 개발했어야 했었고, 이에 대한 우선순위를 깊이 고민했다고 해요. 그 이후 회사가 커지면서 사람들도 많아지게 되었는데 신규 사원은 적응을 잘 못했고, 사람이 늘어남에도 일도 줄지 않았고, 그로 인해 몰입할 시간도 줄어드는 현상을 경험했다고 해요.

이러한 경험을 바탕으로 Shape Up 방식을 만들었다고 해요. Shape Up은 4가지 특징이 있어요.

Six-week cycles + Two-week cool-downs

6주의 제품 개발 과정과 2주의 쿨다운 기간은 적절한 휴식과 적절한 긴장감을 준다고 해요. 이는 Product Lead, PM에게 무엇을 할지에 대해 집중할 시간을 주면서 개발 진행상태를 확인하기 위해 마이크로매니징하는 습관을 없애 주는 효과가 있다고 해요.

Shape, not Specifications

Shape이라는 뜻처럼 개발팀에 개발을 요청하기 전에 무엇을 할지 형상을 만든다고 해요. 근데 특이한 점이 하나의 아이템 혹은 기능에 대해 구체적으로 명세를 작성하지 않고, 러프하게 이야기 나눈다고 해요. 또한 얼마 걸릴지 확인하지도 않는다고 해요. 말 그대로 형상만 전달한다고 해요. 이는 해당 업무의 가치를 강조하고 현재 상황에 맞게 문제의 범위를 좁혀 생각하게 만들기 위해서라고 해요.

Making teams responsible

실제 일이 진행되면 팀 전체 구성원들에게 각자 맡은 일에 대해 전권을 준다고 해요. 스스로 할 일을 정하도록 해서 Product Lead나 PM이 제품의 전략을 고민할 시간을 만들기 위함이라고 해요.

Targeting risk

어떠한 프로젝트라도 6주 안에 끝나지 못했다면 문제가 있었다는 전제를 기준으로 기간 내 목표 달성을 위해 개발 기간을 6주로 보장, 구현 전 의존성 확인 등으로 위험 요소를 줄여나간다고 해요.

2️⃣ Shape Up 프로세스

Shaping

Shaping은 문제를 정의하고 핵심 요소를 파악하는 단계예요. 이 때 3가지를 충족해야만 해요.

이 단계의 핵심은 “해결 범위를 제한할 수 있도록 구체적으로 문제를 정의하고, 창의적으로 문제 해결을 할 수 있도록 가치에 집중한 추상적인 해결방안을 바탕으로 문제를 해결해 나간다”예요. 조금 더 쉽게 풀어 쓰면, 유저 입장에서 러프하게 스케치를 하고 개발자와 이야기 나누며 플래닝을 하는 것이죠. 그렇기 때문에 Shape하는 사람은 유저 입장과 개발 입장을 바탕으로 전략을 세울 수 있는 제너럴리스트와 1~2명의 스페셜리스트로 구성한다고 해요. 이들이 스케줄링까지 하는 것은 아니라고 해요. 불확실성을 인정하는 것이죠. 이 과정의 산출물은 피치덱이에요. 이 피치덱을 바탕으로 Betting 과정에 들어가게 돼요.

Betting

이 과정은 다음 주기에 우리가 할 일을 정하는 시간이에요. 어떤 프로젝트를 진행할 것인지 Shaping된 것들(피치덱)을 바탕으로 이야기를 나누는 것이죠. 다른 개발 방법론과 다른 점은 백로그를 두지 않는다는 점이에요. Shape Up 프로세스 상 백로그를 사용하면 백로그가 많이 쌓일 수 밖에 없게 되는데 이는 오히려 뒤쳐지는 느낌을 주고 오래된 아이디어들이 많아질 수 밖에 없는 구조라서 재검토하는데 시간이 오래 걸리기 때문이에요. 대신 Betting에서 선정되지 못한 아이템들은 필요하다면 다음 Betting 때 다시 발의할 수 있다고 해요.

이 과정에서 가장 중요한 것은 Betting하는 시간을 공식적으로 보장하는 것이에요. 이는 구성원들에게 우리가 앞으로 할 일에 대해 투자를 하고 있음을 명시적으로 느끼게 해준다고 해요. 그래서 5개 질문을 던진다고 해요.

Building

마지막으로 구현, Building이에요. 피치덱에 설정된 범위 안에서 자율성을 가지고 구현하는 과정으로 이 과정의 결과물은 반드시 배포(deploy)예요. 실제 고객에게 딜리버리되는 것을 목표로 진행하는 것이죠. 이 과정에서 제일 중요한 점은 한 개를 완벽히 끝내고 다음으로 넘어간다는 것이에요. 예를 들어 로그인 기능과 회원 가입 기능을 구현해야 한다고 하면, 로그인 기능의 프론트엔드와 백엔드를 모두 구현하고 다음 회원가입 구현으로 넘어간다는 것이에요. 이는 언제든 고객에게 딜리버리 될 수 있는 상태로 만들어주고, 리스크를 줄이기 위함이라고 해요.

📝 읽은 내용에서 배운 점

1️⃣ 제품 개발 방법론은 회사와 제품에 맞는 것을 찾아야 한다.

Shape Up에 대해 공부하면서 느낀 점은 초기 스타트업에게는 6주라는 기간이 정말 길게 느껴질 것이라는 점이에요. 회사와 제품의 상황에 따라 4주로 진행하거나 팀 구성에 따라 베팅은 생략하는 것이 현실적이란 생각이 들었어요.

2️⃣ 모든 장단점이 있다.