우리나라는 외국에 비해 일상생활에서 ‘빨리빨리’ 문화가 확산되어 있습니다. 음식 배달, 새벽 배송, 인터넷 설치 등이 그 예입니다. 이러한 빨리빨리는 회사의 업무에서도 예외가 아닙니다. 오히려 더 심해집니다. 빨리빨리를 관리하기 위한 지표도 많습니다. ‘리드타임 단축’ 같은 업무를 더 빨리 하는 것을 목표로 하고, ‘생산성 향상’은 같은 시간 동안 더 많이 만드는 것을 목표로 합니다. 

대개의 경우 빠른 속도는 좋습니다. 그러나 빠른 것보다 중요한 것은 ‘올바른 일을 빨리 하는가?’입니다. 개발생산성을 ‘생산량/시간’으로 측정하지만 진정한 개발생산성은‘가치/시간’이 맞지 않을까요? 같은 시간에 보고서를 많이 작성하는 것이 기획의 생산성이라고 하면 모두 말도 안 된다고 생각합니다. 그러나 그 말도 안 되는 주장이 소프트웨어 개발에서는 일상적입니다. 같은 시간 동안 더 많이 개발하는 것을 우대하는 분위기를 조성합니다. 상품개발 또는 학습의 속도와 관련하여 유의할 사항은 다음과 같습니다.

1. 빠른 속도를 무리하게 밀어붙이면 다음과 같은 부작용이 발생할 수 있습니다. 

• 결과물의 품질이 나빠집니다. 

  
  

속도를 높이는 손쉬운 방법은 품질을 희생하는 것입니다. 품질은 일정만큼 눈에 띄지 않아 속이기 쉽기 때문입니다. 기본적인 기능은 작동하지만, 예외사항을 고려하지 않는 개발이 대표적인 예입니다. 품질저하는 지뢰에 비유할 수 있습니다. 지뢰가 작으면 리스크를 감내할 수 있지만, 지뢰가 많아지면 지뢰를 피하기 위해 노력하는 시간이 증가할 뿐 아니라 지뢰를 밟아서 피해를 입을 가능성도 높아집니다. 결과적으로 빨리 개발하기 위한 노력이 오히려 개발을 지연시킵니다.  

• 프로젝트 팀원의 자존감을 떨어뜨립니다.  

  
  

완성도 낮은 코드를 개발하고 싶은 개발자는 없습니다. 시간이 부족하고, 무리한 일정준수(또는 단축)를 요구하는 분위기 때문에 개발 완성도가 낮아도 완료했다고 보고할 뿐입니다. ‘납기는 생명, 품질은 자존심’이라는 구호는 두 가지 모두를 강조하고자 만든 구호이지만 자존심(품질)을 위해 생명(납기)을 포기할 사람은 많지 않습니다. 프로젝트 팀원들의 자존심이 낮아지면 프로젝트 팀의 활력이 없어집니다. 

• 번 아웃 되는 팀원이 증가합니다.

  
  

속도를 높이기 위해 팀원들은 품질을 희생하지만 관리자들은 잔업을 요구합니다. 시간으로 결과를 통제하려는 시도는 아주 짧은 기간은 효과가 있지만 장기적으로는 대부분 실패합니다. 그러나 주변 사람들에게 보여주기 식으로 잔업을 하는 경우도 많습니다. ‘개발속도를 높이기 위해 우리가 이렇게 헌신하고 있다’는 것을 과시하는 것입니다. 이렇게 하는 이유는 빨리 못해도 면죄부를 받기 위해서입니다. 그러나 그 과정에서 영혼을 갈아 넣는 팀원이 한 명 두 명 늘어납니다. 영혼을 갈아 넣을 가치가 있는 일인지 없는지는 팀원들이 자발적으로 결정할 사항이지 관리자가 요청해서는 안됩니다. 

• ‘빨리’가 조직의 문화로 자리 잡습니다. 

  
  

보다 빠른 개발에만 집중하다 보면 주변을 살펴보지 않고 빨리 달려가는 것에 집중하는 조직문화가 형성되기 쉽습니다. ‘일단 방향을 정하면 경주마처럼 주변은 쳐다보지 않고 빨리 달려가기’가 조직 내에 만연하게 됩니다. 그렇게 되면 빠른 속도의 부작용이 발생할 가능성이 높습니다. 

2. 프로젝트에서는 ‘많은 개발’보다 ‘많은 가치제공’에 집중해야 합니다. 

프로젝트에서 부작용 없이 일정을 당기는 가장 확실한 방법은 적게 개발하는 것입니다. 100개의 기능(feature)보다 50개의 기능만 개발하면 훨씬 짧은 기간 내에 프로젝트를 완료할 수 있습니다. 프로젝트 팀은 고객들이 가치를 느끼지 못하는 기능들을 많이 개발합니다. 따라서 빨리 개발하라고 상품개발팀을 압박하기 전에 개발할 기능들의 가치를 평가해야 합니다. 

같은 기간 동안 얼마나 많은 양을 개발하는가에 집중하는 대신 같은 기간 동안 얼마나 많은 가치를 제공할 지에 집중해야 합니다. 고객이나 이해관계자들은 상품개발팀이 얼마나 열심히 일하고 얼마나 효율적으로 일하는지 관심 없습니다. 그들이 관심 있는 것은 ‘개발의 속도’보다 ‘가치를 제공하는 속도’입니다.  

가치를 제공하는 속도를 결정하기 위해서는 각 상품기능에 대해 세 가지 요소를 고려해야 합니다. 

- 비즈니스 가치  또는 고객가치 (A)

- 빠른 출시의 필요성 (B)

- 개발기간 또는 개발비용 (C)

가치를 제공하는 속도를 결정하는 식은 ‘(A+B)/C’입니다. 즉 비즈니스 가치가 높고, 빠른 출시가 필요하고, 개발기간이 짧을수록 가치를 제공하는 속도가 빨라집니다. 각 항목의 측정단위는 다르기 때문에 실제의 측정단위가 아니라 사용자 스토리(user story)처럼 개념적인 측정단위인 피보나치수열(1,2,3,5,8,13,21…)의 값을 사용하면 가치를 제공하는 속도를 쉽게 측정할 수 있습니다.  

3. 잦은 릴리즈보다 적정한 주기로 상품을 릴리즈 하는 것이 좋습니다.  

상품개발속도에 집중하면 상품의 릴리즈 주기가 짧아집니다. 릴리즈 주기와 기업의 이익은 어떤 관계가 있을까요? 극단적으로 매주 릴리즈 하면 이익은 어떻게 될까요? 릴리즈 주기가 너무 길어도 문제가 되겠지만 릴리즈 주기가 너무 짧아도 문제가 됩니다.

물론 적정 릴리즈 횟수는 기업에 따라 상품에 따라 달라집니다. 적정 릴리즈 횟수는 새로운 기능에 대한 고객과 기업의 수용능력에 달려 있습니다. 새로운 기능을 제공하는 기업의 관점에서는 기존에 릴리즈한 상품에서 고객들이 어떤 경험을 하는지 정확하게 이해한 뒤 다음 릴리즈에 반영할 기능을 결정해야 합니다. 

기존 상품에서 교훈을 얻기도 전에 속도전에 밀려 새로운 기능을 개발하면 그 기능을 고객이 좋아할 가능성이 낮습니다. 부실한 기능을 개발하는 문제만 있는 것이 아닙니다. 릴리즈가 잦아지면 개발 비용, 마케팅 비용도 증가합니다. 즉 상품개발과 마케팅에 투입되는 비용이 많아져 상품의 수익성에도 부정적인 영향을 미치게 됩니다.   

잦은 릴리즈는 고객관점에서도 부담이 됩니다. 기능 개선을 포함하는 정기 릴리즈를 자주 하는 것이 능사는 아닙니다. 예를 들어 아이폰은 매년 9월에 1회 신상품을 릴리즈하고 세일즈포스닷컴도 년 3회만 기능 개선 릴리즈를 제공합니다. 특히 모바일 앱과 같은 SaaS 상품은 잦은 기능개선이 사용자들에게 부담이 될 수 있습니다. 하드웨어 상품은 고객이 구매를 결정하지만 SaaS 서비스는 고객이 새로운 기능을 강제로 구매당하기 때문입니다. 

<인스파이어드, 2018>의 저자 마티 케이건은 잦은 릴리즈를 ‘사용자 학대’라고도 했습니다. 특히 B2B SaaS 상품은 신규기능이 릴리즈 되면 기존의 업무 프로세스가 변경되는 경우가 많기 때문에 직원들이 새로운 기능에 적응하기 위해 불편을 감수해야 합니다. 물론 신규기능이 고객에게 혜택을 제공하면 일시적인 불편은 의미가 있습니다. 그러나 고객은 별 불편 없이 특정 상품을 잘 사용하고 있는데 새로운 기능이 릴리즈 되면 다음의 불편을 겪습니다. 

- 새로운 기능을 학습하여 기존 업무에 어떻게 적용할지 결정해야 합니다.

- 새로운 기능을 적용할 때 기존 기능에 미치는 부정적인 영향은 없을지 테스트해야 합니다. 

- 변경된 기능을 설명하는 문서를 작성해야 하고, 사용자들을 교육해야 합니다. 

- 새로운 기능에 대한 문의에 대응하기 위해 고객지원 센터의 상담사들을 교육시켜야 합니다. 

지금까지는 기존에 출시된 상품의 기능을 개선하는 속도에 대한 이야기를 했습니다. 그러나 고객이 처음 접하는 상품(제품과 서비스)은 무조건 빠른 것보다 릴리즈의 타이밍(적기)이 중요합니다. 고객이 해당 상품을 받아들일 수 있는 준비가 되지 않는 상태에서는 빠른 릴리즈가 실패로 이어질 수 있습니다. 아이폰의 최초 릴리즈는 2007년 1월이었습니다. 만일 아이폰을 2000년 1월에 릴리즈했어도 성공했을까요? 사용자의 수용능력도 부족하고 사회의 네트워크 인프라가 부실하여 실패했을 가능성이 높습니다. 

=======================================================
제가 삼성 SDS에서 30년동안 경험하고 체득한 교훈을 정리한 <슬기로운 PM 생활>을 25년 1월 출간한 소식을 공유합니다.

https://product.kyobobook.co.kr/detail/S000215148133