제품개발에 대한 6가지 미신 Six Myths of Product Development

회사의 많은 관리자들이 제때 예산에 맞추어 프로젝트를 끝내려고 노력한다. 리소스가 부족하지만, 보스는 예상가능한 일정과 산출물을 요구한다. 그래서 관리자들은 팀들이 더 보수적으로 세부적 계획을 세우고 일정변경과 낭비를 최소화할 수 있도록 압박한다. 하지만, 이런 접근은 회사를 비효율적으로 만들며, 제품개발 노력을 상쇄시킨다.

하버드비즈니스리뷰 원문보기

오류1. 높은 리소스 사용율(High Resource Utilization)이 성능을 향상시킬 것이다.

우리 연구와 컨설팅에 따르면, 매우 많은 회사들이 제품개발을 위해 리소스들을 투입하려고 혈안이 되어 있다. 그 회사들의 논리는 분명하다. 사람들이 자기 시간의 100% 만큼 일하지 않을 때 프로젝트가 더 길어진다고 생각한다. 그래서, 인력들을 충분히 활용하지 않는 조직보다 100% 활용하는 조직들이 더 빠르고 효율적이라고 생각한다. 그러나, 우리는 연구를 통해 그런 것들이 프로젝트 속도, 효율성, 결과물 품질 등을 명백히 낮아지게 한다는 것을 알게 되었다. 높은 리소스 사용률은 심각하게 부정적인 파급효과를 낳는데, 관리자들은 세가지 이유로 과소평가한다. 그들은 개발이라는 작업의 본질적인 다양성에 대해 충분한 주의를 기울이지 않는다. 예상 가능한 일상적이고 반복적인 일들의 경우는 정상적인 방법으로 동작한다. 

5% 일이 증가하면, 시간이 5% 증가한다. 그러나, 각기 다른 다양한 프로세스들을 가진 경우라면 좀 다르게 동작한다. 활용성이 높아지면, 시간은 기하급수적으로 증가한다. 5%의 일이 증가하면, 시간이 2배로 들어난다. 대부분의 사람들은 이걸 이해하지 못한다. 우리는 수백번의 연구에서 제 때 일을 끝내려면, 그들이 가진 리소스의 50% 이상을 추가로 투입해야 한다는 것을 알 수 있었다. 그들은 Queue가 어떻게 경제적 성능에 영향을 미치는지 이해하지 못한다. 높은 리소스 사용율은 Queue를 만들어내게 된다. Queue가 생기면, 전체 시간이 길어지고 피드백이 지연된다. 그렇게 되면 개발자들이 제 때에 시장에 대응할 수 없게 된다. 아이러니컬하게도 많은 관리자들은 이런 이유로 리소스 사용율을 높이려고 한다. 사전에 전체 비용을 계산해볼 수 있는데도, 계산없이 섣부른 의사결정을 하기도 한다.전체비용의 관점에서 선택을 해야 한다. 

제품개발에서, work-in-process inventory 는 대부분 보이지 않는다. 제조업에서는 Queue가 발생되면 바로 보인다. 그러나, 제품개발 공정에서는 설계나 테스트 등에서 발생되는 Queue는 보이지 않는다. 특히 R&D 프로젝트들은 재무적 수단으로는 Queue를 확인할 수 없다. 해결책은 개발 프로세스 내에 버퍼를 산정해서 넣는 것이다. 3M은 전통적으로 리소스의 85%만을 사용하고 있다. 구글의 20% 제도는 유명하다. 즉, 20%란 평상시에는 자기계발의 시간이지만, 프로젝트가 지연되었을 때 사용되는 버퍼이기도 한다.아래에 실행가능한 솔루션들이 몇 가지 있다.

1) 관리컨트롤 시스템을 변화시켜라.

2) 때에 맞추어 수용량을 늘려라.리소스 사용률이 70% 이상일 때 추가 리소스를 투입시키는 것은 대기시간을 대폭 감소시킨다.

3) 진행중인 프로젝트 수를 제한하라.4) 프로세스 진행상태가 보이게 하라.

오류2. 큰 Batch 프로세스가 경제성을 향상시킬 것이다.

제품개발 상에서 Queue가 발생되는 두번째 원인은 Batch size(일 단위의 크기)이다. 새로운 제품이 200개의 컴포넌트로 구성된다고 하자. 만일 테스트를 하기 전에 20개의 부품만 먼저 만들어본다면, 배치의 크기는 90% 이상 줄어들 것이다. 그것은 대기시간 감소에 엄청난 효과를 준다. 프로세스 상에서 평균적인 Queue Size는 Batch Size에 직접 비례하기 때문이다. Batch Size를 줄이는 것은 Lean Development의 중요한 원칙이다. 작은 배치들은 제작자들이 프로세스 상의 일을 대폭 줄여주고, 피드백을 가속화시킨다. 그것이 점차 싸이클 시간과 품질, 효율성을 향상시킨다. Batch Size가 자꾸 커지는 이유는 “일의 본성” 때문이다. 다시 말하면, 자신들이 하고 있는 일이 잘 보이지 않기 때문에, Batch Size가 자꾸 커진다.그리고, 개발자들은 큰 Batch들을 사용하고자 하는 잠재적 편견들을 가지고 있다. 아마도, 그들은 큰 Batch들이 규모의 경제를 만들어 낸다고 생각하는 것 같다. 잘 관리되는 프로세스에서 Batch Size는 거래비용과 보유 비용의 균형을 맞추어 준다. 가게에서 계란을 사는 것을 생각해보자. 만일 당신이 한 번에 12개월치를 구입한다면, 전체의 거래 비용은 낮다. 그러나, 일년동안 계란이 상하게 하지 않기 위해 보유비용은 올라간다. 만일 한 번에 하루치만 구입한다면, 상할 가능성은 낮아지지만 전체 거래 비용은 올라간다. 당신은 본능적으로 두가지 사이의 균형을 유지하려고 할 것인다. 

- 최적의 Batch Size를 결정하는 방법 Batch Size의 변화는 두가지 기초 비용에 영향을 준다.

- “거래비용”과 “보유 비용.”Batch Size가 커질수록, 평균 재고 수준은 올라간다. 

그것은 보유 비용을 높인다. 이것을 잘 이해하는 회사들은 Batch Size를 줄이기 위해 IT를 잘 활용하고 있고, 놀랄만한 결과를 얻어내기도 한다. 어떤 소프트웨어 회사는 90일단위로 큰 Batch들을 테스트 하던 것을, 하루에 여러번 작은 Batch 테스트하는 것으로 바꿈으로써 전체 테스트 시간의 95%를 줄였다. (48개월에서 2.5개월로) 효율을 220% 향상시켰고, 33%의 결함을 개선했다.Batch Size 를 줄이는 것은 개발 프로젝트에서 매우 중요하다.

오류3. 우리의 개발계획은 훌륭하다. 

이제 만들기만 하면 된다.우리는 여러 번의 조사에서, 설계를 거치면서 요구사항이 그대로 남아있는 프로젝트를 단 하나도 발견하지 못했다. 하지만, 많은 조직들이 자신들이 세운 계획을 과도하게 믿고 있다. 그들은 오류나 오차를 관리의 실패나 실행 부족 탓으로 돌린다. 그리고, 오차를 줄이기 위해 목표 및 마일스톤 사이의 모든 스텝을 세밀하게 추적한다. 그런 일들은 안정된 프로세스 상에서 고도로 반복적인 작업을 하는 경우 매우 좋다. 그러나, 새로운 insight를 가지고 매일 새로운 발견을 해야 하고, 상황이 계속해서 변하는 제품혁신에 있어서는 나쁜 결과를 초래할 수 있다. MIT 토마스 앨런 교수가 한 “기술문제를 푸는 해법에 대한 전통적인 연구”에서 “개발과정의 유동적 성질”을 이야기했다. 우주공학에서 Sub system을 개발하는 엔지니어들은, 최고의 솔루션을 선택하기 전에 설계수준의 수많은 제품을 만들고 평가한다. 혁신 프로젝트에서 이런 것은 매우 일반적인 일이다.테스트하고 실험하는 것은 “무엇을 해야하고, 무엇을 하지 말아야할지”를 알려준다. 이를 통해 비용과 가치에 대한 초기 가정들을 검증한다. 고객의 요구를 정의하는 것은 제품개발 프로젝트 초반에 정해지기 힘들다.생각해보면, 놀라운 일도 아니다.  고객들이 존재하지 않는 솔루션에 대한 자신들의 요구사항을 명확히 정의하는 것은 쉽지 않다. 새로운 제품에 대한 특징을 잘 표현하는 것은 정말 개인의 능력이다. 경쟁자들이 새로운 기능을 출시하거나 새로운 트렌드를 좇기 시작하면, 고객들의 우선순위는 개발 프로젝트를 하는 동안에도 갑자기 변경될 수 있다. 그런 모든 이유로, 원래 계획에 집착하는 것은 컨셉이 아무리 훌륭하고, 기술이 훌륭했다고 하더라도 재앙을 부르게 된다. 계획을 세우지 말라고 하는 것은 아니다. 제품개발은 아주 작은 디테일까지 주의를 기울여야하고, 섬세한 코디네이션을 요구하는 복잡한 활동들의 집합이다. 

계획은 증거(evidence)들이 나타나면 지속적으로 바뀌어야하는 가설처럼 취급되어야 하고, 경제적 가정들은 바뀌어야 하고, 기회들은 재평가 되어야 한다. 

-(The Value Captor’s Process)-

오류4. 프로젝트를 빨리 시작하면 빨리 끝날 것이다.

우리가 이미 논의했듯이, 노는 시간은 관리자들이 아주 싫어하는 것이다. 그들은 새로운 프로젝트를 시작해서라도 노는 시간을 줄이려고 한다.심지어 사람들이 다른 프로젝트로 복귀해야 하는데도, 관리자들은 신규 프로젝트의 모든 일들이 나중에 해서는 안된다고 이유를 대어서 사람을 잡는다.그것은 회사가 능력치 이상으로 많은 프로젝트를 하게 만들고, 리소스를 얇게 만든다. 이것은 매우 위험하다. 만일 리소스가 확보되기 전에 프로젝트를 시작한다면, 개발하는 동안 프로젝트는 점차 휘청거리게 될 것이다. 왜냐하면, 제품개발이라는 일은 매우 변하기 쉽고 상하기 쉬운 성질이 있기 때문이다. 기술과 시장에 대한 가정(Assumption)들은 매우 빠르게 구식이 되어버린다. 프로젝트 진행이 느리다면 중간에 진행이 수정되어야 할 가능성이 크다. 한 군사분과에서 연구를 통해 프로젝트 비용과 일정이 지연기간에 비례해서 기하급수적으로 증가한다는 사실을 발견해 내었다. 원래 지연기간이 두배 늘어나면, 비용과 전체 일정은 16배수로 증가한다. 프로세스 상에서 일의 양을 줄이는 것은, 우리가 전통적인 대기이론공식 중의 하나를 살펴볼 때 매우 중요하다.(리틀의 법칙)

단순하게 말하자면, 평균 시간은 처리속도별로 나뉘어진 대기행렬의 크기에 비례한다. 어떤 경우는 일을 시작하는 시점과 속도를 엄격하게 통제하는 것이 해법이 된다. 즉, 일이 현실적으로 종료되는 시점에 일을 시작하게 한다. 조심스럽게 진행 중인 프로젝트 수를 관리하라. 

프로젝트가 런칭되면, 그것이 끝날 때까지 충분히 지원 되는지 확인하라.  진행중인 프로젝트에서 사람을 빼서 새로운 프로젝트에 넣으려 하는 유혹을 이겨내야 한다.

오류5. 우리가 제품에 기능을 더 많이 넣을 수록, 더 많은 고객이 좋아할 것이다.

제품 개발팀은 기능을 추가하는 것이 고객가치를 만들고, 기능을 빼는 것이 고객가치를 파괴한다고 믿는 것처럼 보인다. 이런 경향은 왜 제품이 복잡해지는지 알게 해준다. 리모콘은 사용하기 불가능한 것처럼 보이고, 컴퓨터는 세팅하는데 많은 시간이 걸린다.자동차는 항공기 계기판을 닮은 수많은 스위치와 노브를 가지고 있다. 심지어 단순한 토스터기까지 매뉴얼과 LCD창까지 달고 나온다. 더 많은 것이 더 좋다라는 믿음에 대해 도전하는 회사들은 단순하면서 우아한 제품을 만들어 낸다. 덴마크 전자제품 제조사 Bang&Olufen는고객이 음악을 듣기 위해 이퀄라이저를 조율하거나, 최적의 값을 찾기 위한 다른 컨트롤을 원하지 않는다는 것을 잘 이해하고 있었다. 그래서 그들은 그것을 삭제했다. 회사가 더 적은 것이 더 많은 것일 수 있다는 원칙을 채택하고 구현하는 것은 다음과 같은 두가지 노력을 요구한다는 점에서 어렵다.

“문제를 정의하기”

풀려고 하는 문제점을 드러내는 것은 혁신에서 가장 간과된다. 많은 회사들이 그것을 하는데 거의 시간을 쓰지 않는다. 이 단계는 매우 중요한데, 이 단계를 통해 팀이 목표를 분명히 이해하고, 가설을 세우고 실험을 통해 정제되어지기 때문이다. 문제를 정의하는 능력은 정말 중요한 기능에 집중하는 팀 능력의 키 포인트이다. 월트 디즈니가 디즈니랜드를 만들때, 그는 다른 놀이공원보다 더 많은 기능(탈 것, 음식, 주차장 등)을 급하게 넣으려고 하지 않았다. 오히려 더 큰 질문을 하기 시작했다. 방문자들에게 환상적인 경험을 주려면 어떻게 해야 할까? 대답은 하루아침에 만들어지지 않았다. 면밀한 조사, 지속적인 실험과 디즈니와 고객들에게 “환상적인”것이 의미하는 것에 대해 지속적으로 고민을 했다. IDEO 와 여러 회사들은 가시적인 제품이나 서비스들에 사용되어지는 컨텍스트에 완전히 집중할 수 있도록 특화된 Step들을 가지고 있다. 개발자들은 시장에 대한 것들에 대한 모든 것을 읽고, 관찰하고 미래의 사용자들과 인터뷰하고, 새로운 재품과 경쟁할 것들에 대해 조사한다. 그리고, 그들이 배운 모든 것을 모아서, 그림이나 모델, 다이어그램으로 표현한다. 반복적 개발을 통해 폐기되거나, 테스트되고 결과가 개선되면서 고객에 대한 깊은 통찰력을 기른다. 

“감출것과 뺄 것”을 결정하라.

팀들은 종종 동료들이나 경영진들을 깜짝 놀라게할 눈부신 기술적 성과를 만들어내어 자랑하고 싶어한다. 그러나, 종종 고객들은 노력없이 단지 그냥 작동하는 제품들을 더 좋아한다. 고객관점에서 가장 좋은 솔루션은 가장 간단한 방법으로 문제를 풀어버리면서, 개발자들이 자랑스러워하는 그런 작업들을 보여주지 않는 것이다. 이것을 이해한 오직 한 회사가 있는데, “애플”이다. 많은 것들 혁신적인 제품, 쌔끈한 디자인, 요령있는 마케팅 등으로 잘 알려져 있지만, 아마도 가장 큰 장점은 문제의 중심에 직접 접근하는 능력일 것이다. 잡스가 이런 말을 했다.

“당신이 문제를 바라보기 시작했을 때 그것이 정말 간단해 보인다면, 당신은 문제의 복잡성을 전혀 이해하고 있지 못한 것이다. 당신의 솔루션들은 지나치게 단순화된 것이다. 만일 문제 속으로 들어간다면 그것이 얼마나 복잡한지 알게된다.그러면 당신은 자연스럽게 복잡한 솔루션들을 제시하게 된다. 

하지만, 애플은 그러지 않았다.우리는 자꾸 기능을 뺐다. 정말 위대한 사람이라면 계속 그렇게 할 것이다. 그리고, 문제의 핵심 기본원칙을 알아내서 아름답고 우아한 솔루션을 내놓을 것이다. ”기능을 뺀다는 것은 무엇을 포함시킬 것인지 이해하는 만큼 중요하다. 아마 더 중요할 것이다.불행히도 많은 회사가 혁신적인 노력을 기울이고 있지만, 고개가치와 사용편의성과 같은 중요한 요인을 충분히 생각하지 않고, 모든 기능을 넣는다.그런 회사들이 계획된 기능들을 빼는 경우는 비용을 절감하거나, 일정에 뒤쳐졌거나, 유사한 방식으로 실행한 팀이 실패했을 경우이다. 관리자들은 어떤 기능을 빼면 제품을 개선할 수 있는지를 집중적으로 고민해야 한다. 팀이 전반적인 고객 경험을 높여줄 수 있도록 집중하게 해주어야 한다. 이것은 요구사항들을 가설로 생각하고, 작게 실험하고 테스트함으로써 결정될 수 있다. 개발팀은 더 이상 새로운 기능들을 더할 것이 없을 때, 제품이 완성되었다고 가정하기도 한다. 아마도, 성공비결은 정반대이다. 제품은 어떤 기능이 더이상 제거되어질 수 없을 때 더 완성에 가까와진다. 

레오나르도 다빈치는 말했다.‘단순함은 최고의 세련됨이다.

’오류6. 처음에 제대로 하기만 하면, 우리는 성공할 수 있을 것이다.

많은 프로젝트가 예산, 일정, 기술적 성능에 대한 목표를 만족시키지 못한다. 의심할 여지도 없이, 형편없는 계획, 혹독한 프로세스들, 나약한 리더쉽 모두가 역할을 한다. 그러나, 자주 간과되는 다른 원인은 “매니저가 그들의 팀이 처음부터 올바로 하기를 요구한다는 것”이다. “처음에 성공하기를 원하는 것”은 팀이 최소한의 위험만 감수하도록 몰고간다. 비록, 고객들이 이미 필요한 것 이상의 큰 효과들을 원하고 있지 않더라도....더 나쁜 것은 팀이 고객의 문제에 대한 혁신적인 솔루션을 추구할 동기가 없어져 버린다는 것이다. 실수를 회피하기 위해 팀은 순차적 진행절차(설계, 개발, 테스트, 런칭)를 따르려 하게 된다. 각 단계별로 “관문”이라는 검토과정을 통해 조심스럽게 모니터링된다. 다음 단계의 일들은 그 “관문”을 통과하기 전에는 시작되지 않는다. 프로젝트가 방침에 따라 움직이면서 중요한 의사결정들이 내려지게 된다. 새로운 발견에 대응하기 위해서 비용은 몇십 배씩 뛰게 된다. 최종 관문에서 성공적인 테스트가 행해지고 나면, 가치가 어떻든 새롭게 나타난 모든 것들은 지연으로 생각되어 진다. 불행히도, 그런 순차적 플로우는 프로젝트를 지치게 만들 수 있다. 왜냐하면, 테스트 피드백들은 지연되어지고, 팀은 더욱 더 나쁜 생각에 빠지게 된다.그리고, 문제는 밝혀지지 않고 더 비싼 값을 치르게 된다. “처음에 틀리는 것”을 인내해주는 것은 사람들이 빠르고 자주 반복하고, 그들의 실패로부터 빨리 배울 수 있도록 하는 더 좋은 전략이다. 시뮬레이션과 빠른 프로토타이핑 기술을 통한 발전은 운영을 대단히 쉽게, 그리고 더 저렴하게 만든다.

# 요약

1. Queue와 정보흐름이 보이게 하라.

2. 지연비용을 가시화하고, 의사결정에 반영하라.

3. 리소스 사용률이 높은 곳에 여유 리소스를 투입하라.

4. 컨트롤시스템의 초점을 효율성에서 응답시간으로 옮겨라.

5. 배치 크기를 작게하고, 더 빠른 피드백을 얻기 위해 트랜잭션 비용을 낮추어라.

6. 더 작은 배치들로 실험하라.

7. 개발계획을 새로운 정보가 들어 올 때마다 진화하는 “가설”처럼 취급하라.

8. 당신이 전체적인 의사결정을 내릴 준비가 되었을 때 프로젝트를 진행하라.

9. 단순함을 추구하라.

10. 컴퓨터나 프로토타입을 통해 실생활에 가까운 환경 속에서 자주 작고 빠르게 실험하라.

11. 반복적이고 상호 중첩된 프로세스로 설계하라.

12. 한 번에 통과하기보다 자주 피드백 받는 것에 집중하라.