'워터폴'이면서 '애자일'이라 칭하는 불상사에 대하여
Inspired Summary
해당 글은 Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group) by Marty Cagan을 읽고 요약한 글입니다.
많은 제품이 실패하는 이유 (The root causes of why so many product efforts fail)
많은 기업들이 애자일이라고 ‘주장’하지만, 총체적인 과정은 워터폴에 가깝습니다. (While almost everyone today claims to be Agile, what I’ve just described is very much a waterfall process.)
'애자일'인 줄 알았던 '워터폴' 방식
많은 기업들은 린과 애자일 방법론을 기반으로 제품을 개발하고 관리한다고 생각하지만, 사업 전반적인 프로세스는 워터폴 방식에 갇혀버리면서 껍데기만 애자일이거나, 애자일을 효과적으로 사용하지 못하는 경우가 많습니다. 문제되는 사업 프로세스는 다음과 같습니다.
1. 아이디어 단계 (Ideas)
2. 비즈니스 케이스 단계 (Biz case)
3. 로드맵 제작 단계 (Roadmap)
4. 요구사항 분석 단계 (Requirements)
5. 디자인 단계 (Design)
6. 개발 단계 (Build)
7. 시험 단계 (Test)
8. 출시 단계 (Deploy)
1. 아이디어 단계 (Ideas)
사업화시킬 아이디어는 임원급 인사의 결정이나 시장 상황을 기반으로 결정
2. 비즈니스 케이스 단계 (Biz case)
각 아이디어들을 상세화시켜, 아이디어 하나가 얼만큼의 수익을 낼 수 있을지와 얼만큼의 비용이 들지에 대해서 분석하는 단계
3. 로드맵 제작 단계 (Roadmap)
아이디어를 로드맵화 시키는 단계, 비즈니스 케이스를 기반으로 결정
사업화 시키기 위해서 가장 중요한 것이 무엇인지 파악하고 언제 사업을 실질적으로 수행할 수 있을지 예측하기 위함
4. 요구사항 분석 단계 (Requirements)
로드맵을 바탕으로 프로덕트 매니저가 유저 스토리(user story), 기능 명세서(functional specificaiton) 등의 문서를 작성하는 단계
5. 디자인 단계 (Design)
요구사항을 바탕으로 UX 디자인팀이 디자인 스펙을 작성
6. 개발 단계 (Build)
애자일(Agile)이라는 개념이 실질적으로 처음 적용되는 단계
문서상의 업무들을 스프린트(sprint)의 이터레이션(iteration) 단위로 나눈 스크럼(scrum) 과정을 기반으로 개발자들이 문서상의 요구사항들을 개발
7. 시험 단계 (Test)
QA팀이 아이디어가 제대로 구현됐는지 확인하는 단계
8. 출시 단계 (Deploy)
겉핥기식 애자일의 문제점 10가지
위와 같은 린과 애자일을 빙자한 워터폴 프로세스는 제품 전달(product delivery)에 갇혀있다는 점에서 수많은 문제를 파생시킵니다. 자세한 문제들은 다음 10가지로 요약됩니다.
1. 아이디어의 출처
1단계(아이디어 단계)는 매출 중심(sales-driven) 혹은 이해관계자 중심(stakeholder-driven)의 관점으로 수행됨
해당 관점으로 나온 아이디어들을 기반으로 제품을 만들게 되면 팀 구성원들의 자율성을 저하(lack of empowerment)시켜 단순히 ‘업무’만을 하는 존재(just there to implement)가 됨
2. 비즈니스 케이스의 치명적 결함
제품을 만들 때 가장 중요한 것은 ‘우리가 알 수 없는 것들을 아는 것(knowing what we can’t know)’
얼마나 돈을 벌지, 얼마나 비용이 들지 계산하는 것은 상상에 불과하며(we have no clue about either of these), 계산하는 것 자체가 불가능한 일
아이디어의 수익성은 아이디어 자체가 아니라, 아이디어를 통해 나온 솔루션(프로덕트)이 얼마나 좋게 나오느냐에 달린 것
아이디어의 비용을 측정하는 것은 마치 티셔츠를 던져주고 사이즈를 정확하게 맞춰보라고 하는 것과 같음
많은 회사들은 이게 실질적인 효용이 없음에도 불구하고, 비즈니스 케이스 게임을 즐기고 있음
3. 제품 로드맵의 한계
제품 로드맵에 나온 아이디어의 대부분은 시장에서 작동되지 않음
쓸만한 아이디어를 발견하더라도 여러 반복(several iterations)을 통해 실질적인 사업적 가치를 전달할 수 있을지 검증해야함 (to the point where it delivers the ncessary buinsess value) ⇒ 사업적 가치를 검증하는 과정 (Time to money)
TIME-TO-MONEY: getting the right products to the right customers at the earliest possible moment, and thereby making the most of short-lived sole-sourcing opportunities. (https://www.eetimes.com/time-to-money-five-keys-to-success/)
시장의 고객들은 우리가 아이디어에 대해 짜릿하다고 생각한 만큼 반응해주지 않을 것
4. 제한된 제품 관리의 역할
프로덕트 매니저는 단순히 요구사항을 모아 문서화하는 역할만을 수행
5. 제한된 디자인의 역할
디자이너는 요구사항을 기반으로만 디자인 결과물을 만들어 냄
‘호박에 줄긋기(lipstick on a pig)’ = 엉망진창인 제품을 그럴듯하게 꾸며내는 역할이 되어버림
6. 제한된 기술의 역할
개발자들도 요구사항을 기반으로만 결과물을 제작하게 됨
7. 겉핥기식의 애자일
제품 전달(product delivery)에서만 애자일을 적용하여 제품 발견(product discovery)에서의 비효율 발생
8. 프로젝트 중심적 사고
프로젝트 중심적 사고는 결과 중심적으로 귀결되며 성과로 이어지기 힘들며, 한 회사 내의 프로젝트들이 서로 파편화되는 결과를 초래
결과 (Output): 프로젝트를 통해 만들어진 산출물
성과 (Outcome): 산출물을 통해 나온 실질적인 결과나 변화
9. 너무 늦은 고객 검증
린 프로세스(Lean process)의 핵심은 낭비(waste)를 줄이는 것
대부분의 회사들은 린하고 애자일하게 수행하고 있다고 믿지만, 실제로는 ‘가장 비용이 많이 들고, 가장 느린 방법’인 위의 과정을 수행하고 있음
10. 너무나 큰 기회비용
더 효율적인 방법을 통해 빨리 검증할 수 있었음에도 불구하고 느린 과정을 채택한 것이 대부분 회사들의 가장 큰 비용
Comment
1. 제품을 만들 때 가장 중요한 것은 ‘우리가 알 수 없는 것들을 아는 것(knowing what we can’t know)’
2. Prove, Iterate, Money: 빠르게 아이디어를 검증 → 반복적인 재검증 → 사업화에 대한 확신
3. Agile for all the process: 애자일은 사업의 처음과 끝에 모두 있어야 함
