회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
국내 유명 IT 기업은 한국을 넘어 세계를 무대로 할 정도로 뛰어난 기술과 아이디어를 자랑합니다. 이들은 기업 블로그를 통해 이러한 정보를 공개하고 있습니다. 요즘IT는 각 기업의 특색 있고 유익한 콘텐츠를 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하는 걸까요?
회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
국내 유명 IT 기업은 한국을 넘어 세계를 무대로 할 정도로 뛰어난 기술과 아이디어를 자랑합니다. 이들은 기업 블로그를 통해 이러한 정보를 공개하고 있습니다. 요즘IT는 각 기업의 특색 있고 유익한 콘텐츠를 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하는 걸까요?
이번 글은 스타트업과 프리랜서들이 쉽고 간편하게 고객과 영업을 관리할 수 있는 CRM 소프트웨어를 서비스하는 ‘릴레잇(Relate)’이 제품 개발 프로세스를 운영하는 방법에 대한 이야기입니다.
Basecamp(전 37Signals)는 동명의 프로젝트 매니지먼트 소프트웨어 Basecamp를 서비스하는 회사이다. 최근에는 HEY라는 이메일 서비스도 출시하였으며 역시 빠른 속도로 성장하고 있다.
릴레잇(Relate) 팀의 문화와 업무방식은 Basecamp의 영향을 많이 받았다. 대표적으로 Relate 팀은 창업 당시부터 100% 원격으로 일하고 있는데, 리모트 팀이 협업하는 방식에 있어서 Basecamp에서 저술한 책 중 하나인 REMOTE: Office Not Required(한국어 제목 - 리모트 : 사무실 따윈 필요 없어!)를 많이 참고하였다.
Relate 팀은 새 팀원에게 회사의 핵심가치 세 가지(3Fs: Freedom, Flow, Friendship)에 대응하는 세 권의 책을 선물하는데, 그중 한 권이 바로 이 책이다.
<Shape Up>은 바로 그 Basecamp에서 2020년에 출간한 가장 최근의 저술 제목이자, Basecamp의 제품 개발 프로세스이다. 사실 내가 Shape Up을 읽은 것은 2021년 말로 비교적 최근이다. 그간 우리 팀은 애자일(Agile) 방법론인 스크럼(Scrum)과 칸반(Kanban)의 방식을 일부씩 섞고, (리모트 팀에 맞게 비동기 커뮤니케이션을 할 수 있도록) 프로젝트의 큰 틀과 방향은 초기에 협의 후 세부적인 내용은 개발자가 자율적으로 결정하도록 하는 프로세스로 제품을 개발하고 있었다.
Shape Up을 읽으면서 신기했던 것은 우리 팀의 프로세스가 자연스럽게 Shape Up 프로세스와 비슷한 방향으로 변화되어 왔다는 부분이었다.
아마도 위에 언급되었듯 Basecamp의 이전 책들이 우리 팀의 문화와 업무방식에 영향을 미쳤기 때문이기도 할 것이고, 회사의 분야 역시 B2B SaaS로 일치하며, 기술 스택 역시 공통점을 많이 공유하고 있다는 점도 영향을 주었으리라고 생각한다. Relate은 Basecamp의 DHH가 창시한 Ruby on Rails를 백엔드에서 사용하고 있으며, 프론트엔드에서 사용하고 있는 Vue.js 또한 Ruby on Rails의 핵심 신조인 ’Convention over Configuration’에 유리한 구조를 가지고 있다.
덕분에 Shape Up을 읽으면서 제품 프로세스에 대해 고민하고 있던 부분들에 대해 어느 정도 답을 찾을 수 있었고, Shape Up 프로세스를 기반으로 팀에 맞게 조정하여 Relate 제품팀의 프로세스를 업데이트하게 되었다.
이 글은 Shape Up 프로세스를 요약하면서, 동시에 Relate 팀에서 Shape Up을 어떻게 적용하고 있는지에 관해 설명한다.
Shape Up 프로세스는 ‘프로덕트 리더(Product Lead)’ 혹은 ‘프로덕트 매니저(Product Manager)’가 개별 제품 팀(디자이너와 개발자로 구성된, 하나의 프로젝트를 완성할 수 있는 작은 단위의 팀)에게 프로젝트의 방향을 전달하는 수단으로 ‘Shape’이라는 아주 새로운 형태의, 일종의 프로젝트 가이드라인을 제안한다.
기본적으로 Shape Up 프로세스의 목표는 자율성을 기반으로 프로젝트의 세부사항에 대한 결정 권한을 폭넓게 위임함으로써 커뮤니케이션 코스트를 낮추는 것이다. 이를 통해 Product Lead나 Product Manager는 장기적인 관점에서 제품의 전략적인 방향을 고민하는 데에 더 많은 시간을 들일 수 있다.
Shape Up은 다음과 같은 몇 가지 특징을 가지고 있다.
프로젝트 주기를 스크럼에 비해 더 길게 잡는다. 유의미한 기능을 만들 수 있을 만큼 충분히 길면서도, 시간을 관리할 수 있을 정도로 충분히 짧은 기간을 정한다.
개별 제품 팀에게 구체적인 명세를 전달하는 것이 아닌, 적절히 추상적인 수준의 제품 방향을 담은 Shape을 전달한다.
제품 팀에게 Shape의 배정되고 나면, 해당 Shape에 대한 실행과 진행 상황 커뮤니케이션에 대한 책임은 제품 팀이 가지게 된다.
Shape Up 프로세스는 1) Shaping – 2) Betting – 3) Building의 세 과정을 통해 진행된다.
Shape의 단위는 프로젝트와 같다. 하지만 Shape은 일반적인 프로젝트와 달리 솔루션의 큰 틀을 제안하되, 디테일한 디자인이나 세부사항까지는 제시하지 않는다. 이를 통해 개별 제품 팀은 프로젝트의 완성과 성공에 대한 명확한 기준을 가지면서도, 자율적으로 창의성과 문제 해결 역량을 발휘할 수 있다.
좋은 Shape는 다음의 세 가지 조건을 만족한다.
1) It's rough
2) It's solved
3) It's bounded
4.0K
It's rough
Shape는 문제 해결을 위한 전반적인 방식이나 큰 방향 외의 세부적인 명세를 제시하지 않는다. 개별 제품팀은 독립적으로 문제 해결 역량을 가지고 있으므로, 이 역량을 발휘할 기회를 제공한다.
그러기 위해서 Shape는 ‘와이어프레임(wireframe)’이 아닌 ‘하이-레벨 앱스트랙션(high-level abstraction)’의 형태를 가진다. Basecamp에서는 ‘Breadboard(화면의 이름과 상호작용 대상을 선으로 연결한 단순한 형태의 스토리보드)’나 ‘Fat marker sketches(말 그대로 세부 사항을 묘사할 수 없도록 마커로 디자인한 스케치)’를 사용한다.
It's solved
그럼에도 불구하고 Shape는 문제를 해결해야 한다. Shape을 기준으로 완성된 기능 자체가 문제를 해결하지 못하는 상황까지 개별 제품 팀이 책임지지 않는다. 개별 제품 팀에게 무리한 책임이 전가되거나, 계획에 큰 구멍이 있다는 것을 프로젝트 진행 중에 알게 되지 않도록 shaping의 단계에서 ‘리스크 팩터(risk factor)’를 제거하는 과정을 거친다.
일반적으로 주요한 risk factor에는 이전에 구현해 본 적 없는 새로운 기술을 필요로 하거나, 개별 제품 팀 단위에서 결정하기 어려운 의사결정 사항들이 있다.
It's bounded
Shape은 무엇을 해야 할지가 아닌 무엇을 하지 않아야 할지를 명확히 하며, 이를 통해서 프로젝트가 무한히 확장하는 것을 막는다.
Shaping의 과정에 있어서, 일반적인 프로젝트들의 estimation과 대비되는 매우 독특한 개념으로 ‘Appetite’이 있다. Shape은 일반적인 프로젝트와 달리 명세를 제시하지 않기 때문에 estimation이 애초에 불가능하다.
대신 Shape는 Appetite를 정한다. Appetite는 단어가 의미하는 식욕, 욕구의 의미처럼 이 문제를 해결하는 게 얼마나 중요한지, 즉 어느 정도의 시간을 투자할 정도로 중요한지에 대한 개념이다. Appetite이 2주라면, 해당 문제는 해결하는 데에 총 2주 정도의 시간을 투입할 정도의 중요성을 가진다는 의미이다.
Appetite는 프로젝트가 지속해서 확장하거나, 출시가 계속 미뤄지는 것을 방지한다. 대신 개별 제품팀은 산출물이 Shape가 제시하는 기준을 만족하는 한에서 세부적인 기능을 제거하거나 더 빠르게 개발할 수 있는 형태로 다시 디자인할 수 있는 권한을 가진다.
Shaping이 끝난 프로젝트들은 다음과 같은 다섯 가지 요소들로 구성된 ‘피치(Pitch)’라는 형태로 정리되어 ‘베팅 테이블(betting table)’에 올라가게 된다. Pitch는 슬라이드는 아니고 자유로운 형식의 포스팅 형태를 띄고 있으며, 팀에서 사용하는 프로젝트 관리 소프트웨어에 따라 다른 형태를 띨 수 있다.
1) Problem
2) Appetite (Constraints)
3) Solution
4) Rabbit holes (Risks)
5) No-gos (Limitations)
팀의 주요 의사결정자들은 betting table에 올라온 Shape들의 우선순위를 평가하여, 어떤 프로젝트에 betting 할 것인지를 결정하게 된다.
Relate 팀에서는 매주 화요일에 ‘프로덕트 싱크 미팅(Product sync meeting)’과 ‘그로우 싱크 미팅(Growth sync meeting)’을 진행하고 있는데, 매달 첫 주의 Product sync meeting에서 한 달간 진행할 프로젝트를 함께 결정하고 있다.
Basecamp의 제품개발 프로세스는 8주 주기이며, 이는 6주간의 프로젝트 진행 기간과 2주간의 쿨다운으로 구성된다.
Relate 팀은 초기 스타트업인 만큼 제품이 개선되는 ‘케이던스(cadence)를 높일 필요가 있으므로 8주 단위의 배포는 선택하기는 어렵다고 판단되어, 3주 프로젝트 진행 및 1주 쿨다운으로 구성된 한 달 주기의 제품 사이클을 적용하고 있다.
2주에 비해 좀 더 긴 제품개발 주기를 적용하는 것은 100% 리모트 팀에 특히 유리하다. 리모트 팀은 실시간 커뮤니케이션에 비해 비동기 커뮤니케이션의 비중이 높을수록 효율적으로 협업이 가능한데, 제품개발 주기가 길어지게 되면 프로젝트의 불확실성이 높은 초기에 실시간 커뮤니케이션을 몰아서 하고 나면 이후에는 당장 해야 할 일이 어느 정도 명확해지므로 비동기로도 충분히 커뮤니케이션이 가능해지기 때문이다.
Relate 팀 역시 세부적인 기획을 위한 실시간 커뮤니케이션은 4주 주기 중 첫 주에 몰아서 하고 있다.
Shape Up 프로세스의 또 하나의 중요한 차이점 중 하나는 ‘백로그(Backlog)’가 없다는 것이다. 이것이 의미하는 것은, 진행이 결정되지 않은 프로젝트가 다음 제품 주기의 betting 과정에서 자동으로 높은 우선순위를 가지게 되지는 않는다는 것이다.
새로운 제품 주기에서 기존의 Shape들은 새로운 Shape들과 함께 우선순위를 평가받게 되어 있으며, Basecamp에서는 심지어 의도적으로 다시 평가가 요청되는 프로젝트가 아니라면 평가 자체에서 제외한다.
제품을 둘러싼 환경은 지속해서 변화하게 마련이며, 한 달(Basecamp의 경우에는 8주)이라는 시간은 우선순위에 영향을 주는 요인들이 바뀌기 충분한 시간이기에, 어찌 보면 당연한 이야기일 수 있다.
Betting을 거쳐서 진행이 결정된 프로젝트는 Building의 과정을 통해 실행에 옮기게 된다.
Building에서 가장 중요한 것은 개별 제품 팀에 책임과 권한을 전적으로 넘기는 것이다. Shape에 제품의 명세가 포함되지 않았던 것처럼, Shape된 프로젝트에 구체적인 task를 추가하는 것은 개별 제품 팀의 권한이자 책임이다.
개별 제품팀은 Shape의 범위 안에서 실행을 위한 구체적인 ‘태스크(task)’를 떠올리고 정리하는 것부터, 개발을 완료하고 테스트하여 실제 제품에 반영시키는 지점까지의 모든 과정을 직접 결정하고 책임진다.
다만 프로젝트를 진행하면서 작업의 우선순위와 일하는 방식을 결정하는 과정에서 프로젝트의 risk를 낮추기 위해 공유된 기준이 있다.
디자인과 프론트엔드에 있어서는 세부적인 디테일에 대한 디자인에 앞서 기본적인 ‘아포던스(affordance, 폼이나 버튼 등의 구성요소)’들을 먼저 배치하고 그 상태로 공유하도록 한다. 그렇게 함으로써 백엔드 개발자들이 더 이른 시점에 세부 사항에 대하여 더 많이 이해하고 개발을 진행할 수 있다. 백엔드 개발자들이 업무를 진행하는 데에 있어서 디테일이 얼마나 잘 디자인되었는지는 크게 중요하지 않다.
반대로 백엔드에서는 권한과 보안에 대해서 디테일하게 챙기기 전에 우선 실제 데이터베이스에 값을 넣어보고 화면에 해당 데이터를 활용해 볼 수 있도록 하는 모델 설계부터 진행하여 공유하도록 한다. 프론트엔드에서 실제 데이터를 활용해서 화면을 설계할 수 있도록 함으로써 여러 가지 생각지 못한 리스크를 줄일 수 있다.
마지막으로 프로젝트를 완성하기 위해서 개발해야 하는 여러 가지 feature 혹은 task 중에서는 가장 핵심이 되는 부분을 먼저 개발해야 한다. 회원제 게시판을 만들고자 한다면 로그인 화면부터 만들게 아니라 글을 읽고 쓰는 기능을 먼저 만들어야 한다.
시작 지점으로서 좋은 기준은 core / small / novel이다. 처음 시도해 보거나 핵심적인 기능을 좁게 정의해서 먼저 구현하게 되면 ‘언노운 언노운(unknown unknown, 모르는 것이 있다는 것을 모르고 있음)’을 더 빨리 발견할 수 있다.
프로젝트의 진행 상황을 지속적이고 효과적으로 팀에 공유하는 것 역시 개별 제품 팀의 책임이다. 다만 프로젝트의 초기에 구체적인 task 목록이 정리되거나, 이 목록이 변하지 않을 것이라고 기대하는 것은 현실적이지 않다.
개별 제품 팀에서는 task를 쳐내면서 동시에 task를 추가하고, 이 task 중 관계있는 것들을 ‘스코프(scope)’로 묶는다. 위에서 언급된 것처럼 risk가 높은 (unknown unknown이 많은 / 많을 것으로 예상되는) 부분의 우선순위를 높이면서 진행하게 되면, 어느 시점에는 더 이상 task가 증가하지 않고 줄어들기만 하는 시점에 도달한다.
Basecamp(회사)에서는 이 과정을 시각적으로 표현하기 위해서 ‘힐 차트(Hill chart)’라는 독특한 시각화를 사용하며, Basecamp(제품)에는 이 기능이 녹아 있다. ‘업힐(Uphill)’에 있는 프로젝트는 아직 unknown unknown이 존재하여 task가 계속 추가되고 있다는 것을 의미하고, ‘다운힐(downhill)’에 있는 프로젝트는 남아있는 task만 끝내면 프로젝트가 완성되는 상태를 의미한다.
프로젝트의 ‘에스티메이션(estimation)’이 항상 틀리는 이유는 (그리고 대개 underestimate하게 되는 이유는) 불확실성이 표현되어 있지 않기 때문이다. 개별 제품 팀의 입장에서 unknown unknown이 남아있는 상태에서 estimation의 정확도를 높이는 유일한 방법은 감에 의존하여 ‘오버에스티메이트(overestimate)’하는 것이다. Risk의 존재를 온전히 받아들이는 (embrace) 것은 Shape Up이 다른 프로세스와 매우 구분되는 특징이다.
모든 프로젝트는 작든 크든 불확실성을 가지고 있으며, 애초에 estimation을 하지 않으면서 정해진 주기를 어기지 않고 제품을 출시하는 유일한 방법은 어느 시점에서 개발을 멈추는 것이다.
그렇기 때문에 프론트엔드와 백엔드가 우선순위를 함께 결정하여 기능을 하나씩 개발해야 한다. 각자의 우선순위를 가지고 개발하여 프론트엔드만, 혹은 백엔드만 개발되어 있는 부분이 남아있는 상태에서는 프로젝트의 진행을 멈출 수가 없다. 가장 중요한 부분부터 개발하고 잘게 쪼개서 개발해야 하는 이유 또한 여기에 있다.
멈추는 시점의 기준은 appetite이다. Estimation을 하지 않고 appetite를 결정하는 이유 역시, 애초에 scope이 명확히 정해져 있지 않고, 사실은 정해질 수도 없기 때문이다.
Relate 팀의 개발자들은 프로젝트를 진행하는 과정에서 중요한 문제를 대체로 해결하는 한, 일부 scope를 진행하지 않을 권한을 가진다. 사용하기 좀 더 불편하지만, 더 빨리 개발할 수 있는 경우 세부적인 인터페이스를 변경할 권한도 가진다. 제외된 기능이나 UX 개선과 같은 프로젝트는 다시 새로운 Shape에 포함되어 이후의 다른 프로젝트들과 함께 다시 우선순위를 가리게 된다.
당연히 모든 팀이 이런 식으로 일할 수는 없다. 일반적으로 B2B 제품의 경우, 우선 문제를 해결하는 것이 사용하기 편리한 것보다 더 우선하기 때문에 이런 방식으로 일하는 것이 말이 되는 경우가 많다.
마지막으로 프로젝트의 완성은 배포와 테스트, 발생하는 버그의 수정과 리팩토링을 모두 포함한다. Shape Up 프로세스는 프로젝트의 종료가 정말로 종료를 의미하기 때문에, 그 자체로 완결성이 있어야만 한다. 다행히 이를 위해 cool-down의 시간을 활용할 수 있다.
Shape Up은 자유와 몰입(3Fs중 Freedom, Flow)을 추구하는 우리 팀에게는 상당히 말이 되는 방식이지만, 절대로 모든 제품과 모든 팀에 맞는 방식이 아니다. 우리 역시 우리 여건에 맞게 일부 방식을 조정하여 적용하고 있다.
Shape Up의 여러 구성요소 중 특히 우리 팀과 align이 잘 되는 것들은 다음과 같다. 추상화된 프로젝트로서의 Shaping 실력이 뛰어난 개발자일수록 자율성을 추구하므로 더 몰입하고 온전히 즐기면서 제품을 만들 수 있으면서도, alignment가 부족하여 제품이 실제로 개선되지 않는 위험을 낮출 수 있다.
우리 팀은 Hill chart를 그리지는 않지만, unknown unknown의 유무를 기준으로 uphill과 downhill로 프로젝트의 상태를 구분하고 있다. 이 방식은 내가 아는 한 프로젝트의 상황을 가장 적절하게 표현하는 방식이다.
제품 팀의 목적은 기능의 개발이 아니라 고객의 문제를 해결하는 것이다. 특히 제한된 리소스를 가진 팀에서 문제 해결과 상관없는 세부 사항에 에너지를 들이는 것은 고객 입장에서도 진짜 문제를 해결할 수 있는 중요한 기능 한 가지를 덜 개발한다는 의미와 같다.
우리 팀의 스테이지와 인적 구성 측면에서 Shape Up을 그대로 적용하지 못하고 일부 수정한 내용은 다음과 같다.
6주 개발 + 2주 쿨다운 대신 3주 개발 + 1주 쿨다운 초기 스타트업의 입장에서 제품의 출시 주기가 2개월이 넘어가는 것은 현실적이지 못했다.
Relate 팀의 제품개발팀은 현재 3명의 개발자로 구성되어 있어서, 한 사람이 좀 더 작게 쪼개진 Shape의 프로젝트를 각자 맡아서 진행하는 식으로 일하고 있다.
Shape의 수준
Shape는 더 rough하게 (때로는 대충 이러이러한 기능이 필요하다 정도) 시작하여 solution을 구체화하는 시점부터 함께 논의하여 결정하고 있다. 더 앞단의 책임을 함께하는 대신 Shape의 형태도 구두로만 하는 경우가 많아서 속도가 좀 더 빠르다. 다만 이 때문에 alignment가 부족하여 방향이 의도와 다르게 진행되는 경우가 있고, 이 부분은 상대적으로 잦은 (하지만 비동기적인) 커뮤니케이션을 통해 해결하고 있다.
중간중간에 거듭 강조하였듯, Shape Up은 결코 모든 팀에게 맞는 프로세스가 아니다. 팀 차원에서가 아닌 팀의 구성원 차원에서도 마찬가지다.
Shape Up은 높은 자율성을 추구하므로, 자연스럽게 높은 실력을 요구한다. 기술적인 의사결정 측면에서 적은 숫자로 구성된 팀에서 직접 의사결정을 내려야 하므로 기본적으로 실력이 뛰어나거나 빠르게 학습하고 성장할 수 있어야 책임을 감당할 수 있다.
Shape Up은 개발자에게 코드를 넘어서서 제품과 사용자, 고객에 대해 관심을 가지고 이해하도록 요구한다. 누군가 대신 명세(product specification)를 정리해서 공유해 주지 않기 때문에 문제를 이해하고 직접 해결할 수 있어야 한다. 어찌 보면 Shape Up을 도입하는 팀에 소속된 개발자에게 개발은 정말로 수단일 뿐이고, 실제로 하는 일은 무언가를 만들어 내고 문제를 해결하는 일이다.
한 사람의 소프트웨어 엔지니어로서 개발에 흥미를 느끼고 지속하게 된 이유는, 실제로 동작하는 무언가를 만드는 것 자체에서 느끼는 순수한 즐거움과 내가 만든 무언가를 누군가 실제로 사용할 때 (심지어 나아가서 누군가 가치를 느끼고 기뻐할 때) 느끼는 기쁨이 있다는 것을 기억하고 있다. Shape Up은 개발자로서 이러한 즐거움과 기쁨을 공유하고 기억하는 사람들에게 맞는 프로세스다.
<원문>
좋아요
댓글
공유
공유
