27. 프로젝트의 우선 순위
무엇을 먼저 할 것인가?
테슬라가 2011년에 세상에 내놓은 첫 모델 스포츠카 로드스터.테슬라가 2011년에 세상에 내놓은 첫 모델은 가장 많이 팔릴 것 같은 테슬라 3가 아니라 가장 안 팔릴 것 같고 비싼 스포츠 로드스터였다.
시장 규모가 큰 중소형 자동차 테슬라 3는 럭셔리 세단 S, 럭셔리 SUV X를 시장에 내 놓은 지금에서 양산을 시작하였다. 큰 규모의 자본과 현금 흐름을 자랑하는 GM이나 Nissan의 경우에는 시장 규모가 큰 세단이나 컴팩트 크로스오버 시장을 겨냥한 제품들을 먼저 내놓았다. 시장에서 가장 많이 팔릴 전기 자동차를 만들겠다고 했다면 아마도 지금 많은 사람들이 $1,000의 예약금을 걸어놓고 기다리고 있는 Tesla 3를 가장 먼저 만들어야 했을 것이다.
50만대 이상 예약 판매된 보급형 테슬라 3. 스포츠카에 비해 이 차가 더 많이 팔리는 것은 당연하지만 테슬라는 이 차를 마지막에 내놓았다.위키피디아의 테슬라 페이지의 설명에 따르면 이는 전형적인 하이테크 제품 시장의 라이프사이클을 따른 것이라고 한다. 처음에는 여유있는 고객을 대상으로 제품을 만들어 기술 개발에 집중하고, 생산시설이나 판매망을 서서히 확장하면서 이미 개발된 기술을 더 큰 시장에 적합한 제품에 적용한다는 것이다.
이러한 프로젝트 우선순위 전략은 워터폴 전략과 애자일 전략의 차이를 보여준다. 한번에 계획해서 처음부터 끝까지 만드는 워터폴 전략에서는 경쟁이 좀 있더라고 이미 검증 되어 있고 많이 팔리는 시장을 노리는, 즉 레드오션을 저렴한 가격으로 노리는 것이 유리하다. 그러한 경우에 세일즈와 고객 지원 등에 운영 비용이 많이 들어간다. 그래서 작은 기업들은 워터폴 전략으로 시장에 진입하기가 어렵다.
반면 연구에 연구를 거듭하여 진화해 나가는 애자일의 경우 최소한의 투자로 시장에 파고 들 수 있는 제품을 먼저 만든다. 세일즈와 고객 지원 등에 들어가는 비용을 최대한 아끼고 소수의 마니아에게만 최소로 판매하며 기초를 다져나간다.
이러한 애자일 방법론에서도 무엇을 먼저 해야 하는 가는 어려운 문제이다. 다음의 예를 통해 살펴보면 같은 프로젝트들을 순서만 바꾸어도 총 수익이 확연히 달라짐을 확인할 수 있다. 또한 그것을 최적화 할 수 있는 “우선 순위 공식"에 대해서도 살펴보자.
프로젝트의 비교
회사의 비즈니스팀과 개발팀이 모여서 다음과 같은 단순화된 비교표를 작성했다고 가정하자. 이 회사의 개발팀에는 10명의 인력이 있다.
프로젝트 A: 개발비용 10MM, 운영수익 10$/M
프로젝트 B: 개발비용 20MM, 운영수익 40$/M
프로젝트 C: 개발비용 30MM, 운영수익 20$/M
프로젝트 D: 개발비용 100MM, 운영수익 120$/M
프로젝트 E: 개발비용 200MM, 운영수익 200$/M
* 각 프로젝트는 상호 시너지 효과나 의존성이 없다고 가정한다.
* 개발 비용은 개발 인력의 MM (Man-month)로 계산한다. 10MM은 10명의 인력이 한달동안, 또는 한달의 인력이 10개월동안 개발하는 비용이다. 개발에 필요한 모든 인력은 동일한 능력치로 상호의존성이 없으며, 예측 속도에 맞춰 개발을 진행한다고 가정한다.
* 각 프로젝트별 매출의 성장률이나 사용자가 늘어나면서 생기는 가변비용과 고정비용의 분리 등의 복잡한 내용을 모두 단순화해서 월별 운영 수익이라는 숫자로 표현했다고 가정한다.
이 회사는 어떤 프로젝트를 먼저 진행 하는 것이 좋을까?
옵션1: 수익 우선으로
"가장 많은 고객이 원하는 순서대로 하자"라고 결정했다면 어떻게 될까? 가장 많은 고객이 원했다면, 가장 많은 월별 수익을 낼 것이므로 다음과 같은 순서로 프로젝트를 진행하면 된다.
E → D → B → C → A
프로젝트 E는 200 Man-month가 소요되므로, 10명으로 구성된 개발팀은 20개월간 일해야 완성할 수 있다. 다행히 21개월부터는 월별 $200 이라는 큰 수익을 낼 수 있다. 다섯개의 프로젝트를 끝내는 데에는 36개월이 걸리므로 37개월 후를 관측해 보자.
초반에 가장 비용도 많이 들어가지만 기대 수익도 큰 프로젝트를 수행하여 월 수익 $200를 꾸준히 유지하였다. 37개월째에는 누적수익 $4,490을 달성하였다.
옵션 2: 가장 쉬운 순서대로
"가장 빨리 마칠 수 있는 것부터 하자"라고 결정했다면 어떻게 될까? 개발비용이 가장 적게 드는 것이 가장 빨리 마칠 수 있을 것이므로 다음과 같은 순서로 프로젝트를 진행하면 된다.
A → B → C → D → E
프로젝트 A는 10 Man-month가 소요되므로 첫달에 끝내고 두번째 달부터 $10의 수익을 꾸준히 내면서 다른 프로젝트를 진행할 수 있다. 프로젝트 B는 세번째 달에 끝나며, 4번째 달부터 A와 B로부터 $50의 수익이 꾸준히 들어온다. 가장 수익이 많은 프로젝트 E는 아쉽지만 37개월째부터 $200이라는 큰 수익을 올리기 시작한다.
큰 수익이 나는 프로젝트 E가 37개월째에서야 가동이 시작되었지만, 37개월째부터의 월별 수익은 옵션1과 동일하다. 놀라운 것은 37개월째의 누적수익이 $5,060으로 '가장 수익이 많은' 프로젝트 E부터 시작한 옵션1의 $4,490보다 더 크다는 점이다.
옵션 3: 균형분배
어떤 회사에서는 프로젝트를 작은 팀으로 쪼개서 진행하기도 한다. 우선 순위 없이 10명의 개발자들이 2명씩 팀을 만들어 동시에 진행했다면 어떻게 될까. 프로젝트 A, B, C, D, E는 동시에 시작하고 대신 2명씩 나누어 진행하므로 각 프로젝트별 완성 시간이 조금씩 더 늦어질 것이다.
프로젝트 A는 2명이 10 Man-month를 해결하기 위해 5개월이 소요될 것이고, 프로젝트 B는 10개월이 걸린다. 5개월 후 프로젝트 A를 끝낸 개발자 2명은 나머지 프로젝트에 고르게 분배되어야 하겠지만, 편의상 A를 끝낸 2명은 가장 큰 E에, B를 끝낸 2명은 그다음으로 큰 D에, C를 끝낸 2명은 1명씩 D와 E에 배당된 것으로 계산해보자. D를 끝낸 개발자들은 모두 E에 편입된다.
결과적으로 36개월만에 5개의 프로젝트를 마쳤지만 누적수익은 $3,240으로 옵션1, 옵션2의 수익에 크게 모자란다. 사실 이와같은 실험은, 상황을 많이 단순화 시켜서 과장된 감이 없지는 않다. 팀의 크기가 작아질 수록 커뮤니케이션 오버헤드가 작아지기 때문에 10 Man-month 크기의 프로젝트를 10명이 1달에 할 수 있었다면, 2명이 5달보다 더 짧은 시간에 끝낼 수 있을 가능성도 크기 때문이다.
옵션 4: 우선순위 공식
옵션 1은 운영수익 위주로, 옵션 2는 개발비용 위주로 우선순위를 선정하였다. 내가 인터뷰를 본 어떤 회사에서 프로덕트 매니저에게 '어떤 방법으로 우선순위를 선정합니까'라고 물었더니, 훌륭하게도 다음과 같은 답을 얻었다.
"우리는 X축에 Level of Effort를, Y축에 Business Value를 놓고 각 프로젝트들이 어떤 4분면에 드는지 검사합니다. 노력이 많이 들고 비즈니스 효과가 적은 오른쪽 아래 사분면에 드는 Theme은 하지 않는게 좋겠죠. 가능하면 왼쪽 위부터 시작하려고 노력합니다."
위의 철학을 한 줄로 요약하면 아래의 공식이 된다.
Priority = Business Value / Level of Effort
이 우선순위 함수대로 우리의 5개 프로젝트를 나열하면 B (40/20=2.0) > D (120/100=1.2) > A (10/10=1.0) == E (200/200=1.0) > C (20/30=0.67) 의 순서가 된다. 여기에서 A와 E는 같은 우선순위를 가지지만 작은 것을 먼저 하는 것으로 실험을 해보면 아래와 같은 결과를 얻게 된다.
이 실험에서 A와 E를 바꾸어 보아도 결과는 같다 (B → D → E → A → C)
실제로는 E와 A와 같이 비슷한 우선순위 값을 얻었다면 크기가 작은 A를 먼저하는 것이 현금 흐름상 안전한 방법이 될 수 있다.
위에서 설명한 4개의 옵션에서의 누적 수익을 그래프로 보면 다음과 같다.
37개월째를 보면, 우선순위 공식을 사용한 4번째 옵션이 가장 이익을 많이 남긴 것을 볼 수 있다. 5개 프로젝트 이후에 다른 프로젝트가 없다면 위의 차트에서처럼 37개월 이후의 월수익이 같겠지만, 실제 상황에서 두 회사가 균형분배와 우선순위 공식을 사용하여 경쟁하고 있었다면 이 누적수익의 차이는 다음 프로젝트를 진행하기 위한 새로운 인력이나 시설투자에 사용될 수 있을 것이므로 이런 식으로 몇 해가 지난 후의 경쟁력 차이는 크게 날 것이다.
팀 전체의 의견
만약 이 공식을 현실에 대입하려면 이 공식을 크게 확장하거나 각 변수를 얻는 방법에 대한 팀의 합의가 필요할 것이다. 예를 들어 기반기술을 개발하는 프로젝트를 수행하여 다른 프로젝트들의 전반적인 개발비용을 줄일수 있다고 한다면 이 프로젝트의 운영수익은 어떻게 계산해야 할 것인가. 프로젝트간의 의존성이나 시너지 효과, 특정한 기술을 가진 개발 인력의 희소성, 각 프로젝트 성격에 따른 개발기간에 대한 리스크, Time-to-market에 대한 예상 수익의 휘발성 등 실제의 상황은 이와 같은 간단한 공식으로 표현하기에 너무나도 복잡하게 얽혀있다.
하지만 위에서 정해서 이유 없이 해야 하는 타임라인보다는 이러한 우선순위 결정 과정을 투명하게 결정하고 팀원 모두가 이해할 수 있는 원칙에 따라 결정을 하는 것은 동기 부여에 있어 매우 중요하다. 한 목표를 위해 '스크럼'을 짜고 전진할 수 있는 기반은 충성심과 애정보다는 다수가 납득한 원칙에 의한 합의가 효과적이다.
글: Aiden. 엔지니어링 매니저. 데이터 수집을 통한 프로세스 개선에 관심이 많음.
그림: Chili. 디자이너. 생각을 그림으로 요약하는데 관심이 많음.
Project Group 실리콘밸리를 그리다 / 페이스북
