추정은 해악이다

Estimation is Evil

추정(Estimation)에 대한 강박 극복하기

많은 애자일 팀들(대부분의 애자일 팀이라 생각합니다)은 애자일의 가치, 원칙, 실천 방법을 적용함으로써 어느 정도의 개선을 얻습니다.

이 팀들은 언제 작업이 완료될지 더 잘 예측하고, 예측한 시간에 맞춰 작업을 완료하는 데 있어서도 더 나은 성과를 보입니다. 그들은 요구사항을 백로그(backlog)로 나누고, 각 항목이 얼마나 걸릴지 추정하며, 그 백로그를 꽤 잘 처리해 나갑니다. 보통 프로젝트의 예상 종료 시점에 도달했을 때, 애자일을 도입하기 전보다는 '완료'에 더 가까운 상태가 됩니다.

애자일 팀은 업무를 2주 단위로 나누고, 종종 그 업무에 대해 추정(estimate)을 합니다. 그들은 보통 그 반복 주기(Iteration) 내에 완료하겠다고 예측한 것의 대부분을 끝냅니다. 결함이 다시 돌아오는 경우도 많지 않으며, 정기적으로 모여 개선을 논의합니다.

이러한 팀들은 팀 내부적으로, 그리고 경영진 및 이해관계자들과의 관계에서 더 나은 투명성을 확보합니다. 예전보다 배포 일정을 더 잘 맞추며, 배포 시 결함도 적습니다. 경영진은 상황을 더 잘 통제하고 있다고 느낍니다.

애자일 아이디어를 적용하는 팀은 거의 항상 어느 정도의 개선을 이룹니다. 가장 인기 있는 애자일 접근법인 스크럼(Scrum)으로 인한 전반적인 개선 효과는, 이전 방식보다 약 20% 정도 더 나은 수준일 것이라 짐작합니다.

어떤 팀들은 훨씬 더 잘하기도 하는데, 그들이 어떻게 하는지는 나중에 이야기하겠습니다. 여기서 우리의 주된 관심사는 '좋은 결과를 내지만 위대하지는 않은' 팀들입니다. 왜냐하면 그들이 하는 방식에는 공통적인 요소들이 있고, 바로 그 공통적인 요소들이 그들의 발목을 잡고 있기 때문입니다.

이 팀들은 예전보다는 낫지만, 여전히 '두드러지지 않는(Undistinguished)' 수준입니다. 이런 팀들은 종종 다음 중 하나 이상에 대해 과도한 관심을 보입니다.

사전에 정의된 업무 백로그를 완료하는 것

요청받은 모든 것을 고정된 날짜까지 전달하는 것

2주 동안 할 수 있는 일을 추정하고 그 약속을 지키는 것

추정의 품질(정확도)을 높이는 것

추정치와 실제 결과 사이의 차이를 설명하는 것

기능 생산 속도(Velocity)를 높이는 것

한마디로, 이 팀들은 추정(Estimation)과 그 추정치를 지키는 것에 지나치게 집착합니다.

이러한 우려는 이해할 만합니다. 대부분의 조직이 겪은 소프트웨어 개발 경험은 좋지 않았으니까요. 약속은 지켜지지 않았습니다. 특정 날짜에 끝나기로 했던 프로젝트는 계속 지연되며 소중한 시간과 돈을 태워버렸습니다. 제품이 겨우 배포될 수준이 되었을 때, 그것은 애초에 요청한 사람들의 비전에 미치지 못했습니다. 사용자들이 사용하기 시작했을 때, 그들은 어처구니없는 오류와 누락을 발견했습니다.

소프트웨어 개발은 이를 접하는 거의 모든 사람에게 꽤나 실망스러운 일이었습니다. 그래서 우리는 항상 "소프트웨어 위기" 같은 이야기를 듣게 됩니다.

그러니 우리가 소프트웨어 개발자들에게 "언제 끝날지 더 잘 예측하라"고 요구하는 것은 꽤 자연스러운 일처럼 보입니다. 애자일 방법론의 투명성을 이용해 개발 진행 상황을 감시하고, 그들이 약속한 것을 반드시 해내도록 다그치는 것도 이치에 맞아 보입니다. 그들에게 추정을 더 잘하고 그 추정을 맞추라고 요구하는 것은 합리적입니다. 더 빨리 하라고 요구하는 것은 좋은 비즈니스입니다.

자연스럽고, 이치에 맞고, 합리적이며, 좋은 비즈니스처럼 보입니다. 유일한 문제는, 그것이 '틀렸다'는 것입니다. 이것들이야말로 애자일 프로젝트가 이전보다 겨우 20% 정도만 나아지게 만드는 원인입니다. 왜 이런 것들이 우리의 발목을 잡는지, 그리고 대신 무엇을 해야 하는지 살펴봅시다.

모든 요구사항을 가지고 시작하는 것은 잘못됐다

우리 대부분은 프로젝트의 맨 처음에 모든 요구사항을 적으라고 배웠습니다. 여기에는 딱 세 가지 잘못된 점이 있습니다. 바로 "요구사항", "맨 처음", 그리고 "모두"입니다. 맨 처음은 우리가 프로젝트에 대해 앞으로 알게 될 그 어느 때보다 가장 모르는 시기입니다. 이때가 우리가 무엇을 "요구"할지 확정하기에 가장 최악의 순간입니다.

"요구사항" 목록을 본 적이 있는 사람이라면 누구나, 매우 중요한 항목과 별로 중요하지 않은 항목이 섞여 있는 것을 보았을 것입니다. 별로 중요하지 않은 것은 가장 중요한 것의 1/100도 안 되는 가치를 가지거나, 심지어 아주 나쁜 아이디어일 수도 있습니다. 요구사항 목록에는 강력한 "80-20 법칙"이 작용합니다. 가치의 대부분은 소위 요구사항이라 불리는 것들의 아주 작은 부분에서 나옵니다. 그러니 이것들은 전혀 "요구사항(필수조건)"이 아닙니다. 그저 아이디어일 뿐이며, 그중 일부는 별로 좋지도 않습니다. 어떻게 모든 아이디어가 다 좋을 수 있겠습니까? 우리는 프로젝트를 시작하기도 전, 가장 무지할 때 이것들을 만들어냈는데요.

설상가상으로, "요구사항"을 적을 때 우리는 이것이 무언가를 요청할 마지막 기회인 것처럼 행동합니다. 그래서 생각할 수 있는 모든 것, 필요할지도 모르는 모든 것을 요청합니다. 어차피 다 받지는 못할 거라고 생각하니, 일단 많이 요청하고 감내할 수 있는 수준의 무언가를 얻기를 바라는 것입니다.

언제 완료될지 추정하는 것은 잘못됐고, 답을 강요하는 것은 더 나쁘다

그러고 나서 우리는 개발자들에게 이 모든 것을 언제 끝낼 수 있는지 "추정"하라고 요구합니다. 그들 역시 이 제품에 대해 앞으로 알게 될 것보다 지금 가장 모르고 있으며, 요구사항의 대부분을 잘 이해하지 못합니다. 하지만 그들은 최선을 다해 날짜를 내놓습니다. 비즈니스 측에서 이 날짜를 받아들일까요? 당연히 아닙니다! 첫째, 이건 단지 추정일 뿐이니까요. 둘째, 개발자들은 분명 여유 시간을 넉넉히 잡았을 겁니다(항상 그러니까요). 셋째, 우리가 원하는 날짜가 아닙니다. 우리는 더 빨리 원합니다.

그래서 우리는 개발자들의 추정을 거부하고, 그들이 남겨둔 여유(fat)를 모두 짜냈다고 확신할 때까지 더 세게 밀어붙입니다. 때로는 그냥 언제까지 끝내야 한다고 통보해버리기도 합니다.

어느 쪽이든, 개발자들은 고개를 떨구고 방을 나갑니다. 또 다시 불가능한 일을 요청받았다는 것을 확신하면서요. 그리고 비즈니스 담당자들은 날짜를 적습니다. "개발팀이 11월 13일 오후 12시 25분까지 완료하겠다고 맹세했음."

저는 그 방에 있는 누구도 그 날짜를 믿지 않는다고 확신합니다. 만약 믿는 사람이 있다면, 저는 그 날짜에 반대하는 내기를 하러 다니고 싶습니다. 저는 곧 페라리를 몰게 될 겁니다. 왜냐하면 그 날짜는 맞을 리가 없으니까요. 그것은 비현실적인 요구사항 목록에 기초하고, 가장 무지한 순간에 만들어진 취약한 추정을 사용했으며, 자신의 능력에 대해 항상 낙관적인 사람들에 의해 만들어졌습니다. 게다가 강해져야 한다고 생각하는 관리자들에 의해 쥐어짜졌거나, 윗선에 성급한 약속을 해버린 누군가에 의해 무시당한 결과물입니다.

하지만 괜찮습니다. 계속 압박하면 그들이 잘 해낼 테니까요. 그들이 거의 잘 해내지 못한다는 점만 빼면 말이죠. 심지어 애자일 환경에서도요. 무슨 일이 벌어지는지 봅시다.

애자일 팀은 짧은 주기로 일하며, 수행할 수 있다고 '예측'한 양의 업무를 선택한다

애자일 프로세스는 보통 2주 정도의 반복 주기(또는 "스프린트")로 진행됩니다. 매 반복 주기마다 팀은 "제품 책임자(Product Owner)"와 협력하여 다가올 주기에 할 일을 선택합니다. 그들은 그 기간 안에 달성할 수 있다고 예측(forecast)하는 업무량을 선택해야 합니다. 여기서 강조점은 '선택(choose)'에 있습니다.

너무나 자주, 제품 책임자나 경영진은 팀이 선택한 양에 실망감을 표하며, 더 많은 일을 맡도록 격려하거나, 재촉하거나, 요구합니다. 제가 왜 그랬냐고 물었을 때 그들 중 한 명은 "사람들에게는 도전적인 목표(stretch goals)가 필요해요"라고 말했습니다.

팀이 감당할 수 있다고 생각하는 것보다 더 많은 일을 떠맡게 되면, 일반적으로 목표에 미달한다는 사실이 놀라운가요? 그렇지 않을 겁니다. 누군가가 더 많은 일을 밀어붙인 지 불과 2주 만에, 바로 그 사람이 팀이 "약속을 어겼다"며 실망감을 표하는 것이 흔한 일이라는 사실이 놀라운가요? 그렇지 않을 겁니다.

불가능을 요구해놓고, 경영진은 더 나은 추정을 요구한다

놀랍지도 않게, 과부하가 걸린 팀은 목표에 미달합니다. 그럼에도 경영진은 팀에게 추정 능력을 향상시켜야 한다고 말합니다. 경영진이 진짜 의미하는 바는 추정이 곧 약속(심지어 강요된 추정이라도)이며, 팀은 약속하지도 않은 그 "약속"을 지켜야 한다는 것입니다. 팀은 할 수 있는 만큼의 일을 해냅니다. 그러면 경영진은 팀이 할 수 있는 것보다 더 많은 것을 하라고 강요하며, "생산성을 높이라"고 요구합니다. 이는 "더 빨리 하고, 더 많이 약속하고, 끝내라"는 뜻입니다.

능력 밖의 일을 요구받은 팀은 "노력해보겠습니다"라고 말할 것입니다. 그리고 그들은 노력할 것입니다. 하지만 이것이 좋은 결과로 이어지는 경우는 드뭅니다. 완료를 확신하기 위해, 그들은 모든 것을 과대 추정하기 시작할 것입니다. 빨리 끝내기 위해, 그들은 눈에 보이지 않는 중요한 업무들을 축소할 것입니다. 이것은 먼지를 양탄자 밑으로 쓸어 넣는 것과 같습니다. 그들은 필요한 것보다 테스트를 조금 덜 할 것입니다. '괜찮아, 버그 리포트가 오면 그때 고치지 뭐.' 그들은 코드를 필요한 만큼 깨끗하게 유지하지 않을 것입니다. '괜찮아, 나중에 정리하면 돼. 속도도 별로 안 느려질 거야.'

왜 이것을 신경 써야 할까요? 왜냐하면 결함들은 프로젝트가 거의 끝날 때쯤이나, 심지어 사용자에게 배포된 후에야 나타날 것이기 때문입니다. 그러면 코드가 제대로 작동하게 만들기 위해 이미 끝냈어야 할 작업을 다시 해야 합니다. 코드가 엉망이 될수록 작업은 더 어려워지고 팀 속도는 느려지기 때문에 신경 써야 합니다. 게다가 코드가 나빠질수록 더 많은 결함이 숨어듭니다.

이 모든 것의 결과는 늦어지고, 가능한 것보다 더 적은 기능을 제공하며, 필요 이상으로 결함이 많고, 유지보수 비용이 더 많이 드는 제품입니다.

"좋아요, 부정적인 대장님(Captain Negative). 그런 건 악용 사례겠죠. 하지만 추정과 예측에 대한 합당한 필요성도 있잖아요. 그러니 악용 사례만 비난하지 말고 좋은 측면에 동참하는 건 어때요?"

"그 좋은 측면이 뭐라고 했죠? 까먹어서요."

"음, 그러니까. 우리는 프로젝트가 끝나는 데 얼마나 걸릴지 알아야 해요. 비용이 얼마나 들지도 알아야 하고요. 그래서 모든 요구사항을 추정해서 얼마나 많은 사람이 필요한지, 시간과 돈이 얼마나 필요한지 봐야 해요. 그래야 늦어질 때 우리가, 음, 조치를 취할 수 있으니까요."

"그리고, 음. 우리 팀은 반복 주기로 일해요. 그들은 얼마나 많은 일을 맡을지 알아야 하고, 그러려면 추정이 필요해요. 당연히 우리는 그들이 업무량을 파악하는 능력이 좋아지길 바라니까, 추정 대비 성과를 측정해서 부족하면 개선하게 할 거예요."

여기에 문제가 있습니다. 이것은 매우 미끄러운 비탈길(slippery slope)입니다. 먼저 장기 계획을 살펴보고, 그 다음 단기 계획을 봅시다.

장기 계획: 크라이슬러 C3 프로젝트의 교훈 가장 잘 알려진 장기 애자일 프로젝트 중 하나는 최초의 익스트림 프로그래밍(XP) 프로젝트였던 크라이슬러 C3 급여 시스템이었습니다.

저는 당시 크라이슬러의 CIO이자 제가 만난 IT 임원 중 가장 고위직이었던 수 엉거(Sue Unger)가 C3 팀과 만나는 자리에 있었습니다. 켄트 벡(Kent Beck)은 우리가 어떻게 "고객"인 마리(Marie DeArment)가 요청하는 것을 만들며 몇 주 단위의 반복 주기로 일할 것인지 설명했습니다. 엉거 씨는 물었습니다. "당신들이 궤도에 올라와 있는지 아닌지 제가 어떻게 알죠?"

켄트 벡은 급여 시스템을 위한 스토리 카드 뭉치를 들어 올렸습니다. "여기 우리가 해야 할 모든 일이 있습니다. 우리는 발견하는 대로 일을 추가할 것이고, 할 필요가 없는 일은 제거할 것입니다. 매달 우리를 방문해 주세요. 이 카드들을 보여드리고, 몇 개가 완료되었고 몇 개가 남았는지 보여드리겠습니다. 진척 상황이 만족스럽지 않다면, 프로젝트를 취소하십시오."

최고위 IT 임원인 수 엉거는 말했습니다. "그렇게 하죠." 그녀가 할 수 있다면, 당신도 할 수 있습니다.

C3 프로젝트는 급여 프로그램이었고, 마리는 급여 전문가였기에 무엇을 해야 할지 정확히 알고 있었습니다. 그럼에도 불구하고 프로젝트 과정에서 우리는 일을 추가하고 제거했으며, 불필요한 작업은 미루고 새로운 항목을 채택했습니다. 이것은 제가 본 가장 잘 계획된 프로젝트 중 하나였지만, 요구사항의 최소 3분의 1은 추가되거나, 제거되거나, 크게 변경되었습니다.

그럼에도 불구하고 팀과 엉거 씨는 완료된 작업 뭉치와 남은 작업 뭉치를 보며 상황이 잘 돌아가고 있는지 알 수 있었습니다.

하지만 애자일 역사를 아는 분들은 C3 프로젝트가 완전히 성공적이지는 않았다는 것을 알 겁니다. 여러 버전을 제때 배포했음에도 불구하고, 프로젝트는 결국 취소되었습니다. 이유는 주로 정치적인 것이었지만, 프로젝트가 완벽했다면 그런 일은 없었을 것입니다. 그 역사 속에 큰 교훈이 숨어 있다는 것을 깨닫는 데는 시간이 좀 걸렸습니다.

C3 프로젝트의 목적은 크라이슬러의 급여 프로그램 '전체 제품군'을 대체하는 것이었습니다. 그것은 달성되지 못했습니다. 수년 후, 전체 급여 프로그램을 대체하려던 후속 프로젝트 역시 달성하지 못했습니다. 우리는 이제 무엇을 했어야 했는지 깨닫습니다.

고장 난 조각들을 하나씩, 가장 가치 있는 순서대로 교체했어야 했다 '급여와 관련된 모든 것'의 목록을 만들고 하나씩 지워나간다는 근본적인 아이디어 자체가 잘못된 것이었습니다.

기존 급여 프로그램의 어떤 부분은 아주 멀쩡해서 교체할 필요가 없었습니다. 어떤 부분은 애초에 급여 시스템에 속하지도 않았습니다. 세금 같은 부분은 외부 프로그램으로 처리되었습니다. 하지만 다른 부분들은 급여 시스템의 일부로 간주되었고, 따라서 새로운 급여 시스템은 그 모든 부분이 포함되기 전까지는 배포될 수 없었습니다.

이것은 올바른 생각이 아니었습니다. 우리가 보지 못한 훨씬 더 좋고 단순한 아이디어가 있었습니다. 크라이슬러가 기존 급여 시스템에서 싫어했던 부분들이 있었습니다. 이 부분은 너무 느리다, 저 부분은 유지보수가 어렵다 등등. 우리는 모든 것을 지배하는 거대한 새 급여 프로그램을 만드는 것이 임무라고 생각했습니다. 틀렸습니다.

우리가 했어야 했고, 할 수 있었던 일은 마리와 다른 급여 담당자들이 해결되길 원하는 순서대로 문제를 하나씩 해결하고, 해결되는 즉시 배포하는 것이었습니다.

C3 급여 시스템은 모든 것이 언제 완료될지 예측하거나 추적하는 것이 일이 아니라고 생각했다면 더 성공적이었을 것입니다. 진짜 임무는 급여 부서의 문제를 해결하기 위해 팀을 소집하고, 투자 수익이 감소하면 다른 일로 넘어가는 것이었습니다.

우리의 제품을 '해야 할 일의 긴 목록'으로 생각하는 것은 이상적이지 않습니다. 언제 다 끝날지 예측하거나 계획하는 것도 최선이 아닙니다. 애자일 선언문은 '작동하는 소프트웨어(Working Software)'를 요구합니다. 다음 문제를 집어 들고, 작동하는 소프트웨어로 해결하십시오. 진짜로 해결한다는 것은 그 솔루션을 필요로 하는 사람들의 손에 쥐여주는 것을 의미합니다. 계획하고, 예측하고, 투영하는 것이 아닙니다. 선택하고, 만들고, 제공하는 것입니다.

물론 추정을 사용하는 좋은 방법들도 있습니다. 몇 가지를 소개합니다.

이 프로젝트는 얼마나 큰가?

"그들(경영진)"은 종종 어떤 일이 얼마나 걸릴지, 비용이 얼마나 들지 알고 싶어 합니다. 제 생각에 "그들"은 자신들이 무엇을 원하는지도 모르기 때문에, 우리는 그것이 얼마나 걸릴지 도무지 알 수가 없습니다. 하지만 "그들"은 권력과 돈을 쥐고 있으니, 우리는 불가능하더라도 대답을 해야 합니다.

만약 '얼마나 오래', '얼마나 많이'를 정확히 추정하는 방법을 알고 있다면, 그냥 하세요. 그리고 남는 시간에 우리를 위해 그것을 글로 써주세요. 그 방법으로 추정한 프로젝트에서 실제로 일어난 일들, 겪었던 변경 사항들, 그리고 파괴된 삶에 대한 실화도 포함해서요. 그동안 우리는 여기서 계속 이야기하겠습니다.

대부분의 경우 "그들"은 이미 몇 명을 줄지, 얼마나 시간을 줄지 알고 있습니다. 그들은 우리가 그들이 생각한 숫자를 "추정"해낼 때까지 고개를 젓습니다. 그러니 질문을 뒤집어야 합니다. "얼마나 쓰고 싶으신가요? 그리고 언제 제품을 보기를 희망하시나요?" 그들이 말해주면, 우리는 그 예산 안에서 합리적인 무언가를 할 수 있을지 결정합니다. 할 수 있다면 진행합니다. 아니라면 정중하게 거절합니다.

아무도 모르고 아이디어도 없다면, 프로젝트가 너무 모호하고 큰 것입니다. 도망치세요. 하지만 절벽에서 뛰어내리며 내려가는 길에 계획을 세우는 것을 즐긴다면, "5장 카드 기법(Five Card Method)"을 시도해 보세요.

제품 비전을 약 5개의 주요 주제로 나눕니다. 기술적인 분류가 아니라 비즈니스적인 의미가 있어야 합니다. (예: "방대한 도서 정보 보유", "책 검색 및 추천", "장바구니 및 청구", "배송 처리", "보고 및 회계")

이 중 지금 추정할 수 있는 것이 있나요? 장바구니에 대해 잘 안다면 추정하세요.

추정할 수 없는 항목은 다시 약 5개의 더 작은 아이디어로 나누세요.

보통 두어 단계만 나누면 추정할 수 있는 것들이 나옵니다. 원하는 방법으로 추정하세요.

숫자를 모두 더한 다음, e(약 2.718)와 파이(π, 약 3.14) 사이의 정수(즉, 3)를 곱하세요. 아니면 당신만의 마법의 주문을 사용하세요. 거의 상관없습니다.

거의 상관없는 이유는 이것이 여전히 추정이기 때문입니다. 매우 취약한 추정이고 틀릴 것이 확실합니다. 하지만 시작하고, 다음에 무엇을 할지, 무엇을 미룰지 세부적인 결정을 내리기에는 충분할 수 있습니다. 애자일하게 행동하여 2주마다 작동하는 시스템을 만드세요.

이번 주기에는 얼마나 많은 일을 맡아야 할까?

애자일 팀은 다음 반복 주기에 얼마나 많은 일을 맡을지 결정해야 합니다. 한 가지 방법은 각 항목의 소요 시간을 추정하고 더해보는 것입니다.

하지만 단순히 시간을 더하는 것은 까다롭습니다. 하루 8시간 온전히 업무에 집중하는 팀은 없으니까요. 한 가지 방법은 실제 업무에 쓴 시간과, 그 4시간을 채우기 위해 얼마나 많은 시간이 흘렀는지를 추적하는 것입니다. 때로는 4시간짜리 일을 하는 데 며칠이 걸리기도 합니다.

여기서 주의해야 합니다. 사람들은 왜 4시간짜리 일을 하는 데 이틀이 걸리냐고 묻고 싶어질 것이고, 더 열심히 하라고 요구하고 싶어질 것입니다. 이게 바로 우리가 우려하는 절벽의 가장자리입니다. 분석은 팀 내부에서만 하세요.

시간 이외의 것으로 추정하는 아이디어들도 있습니다. 포인트(Points), 젤리곰(Gummi Bears), 피보나치 수, 티셔츠 사이즈 등입니다. 이것들은 원래 시간적인 측면을 모호하게 만들어 경영진이 추정치를 오용하지 못하게 하려고 발명된 것입니다. (제가 압니다. 그게 발명될 때 제가 거기 있었거든요. 어쩌면 제가 포인트를 발명했을 수도 있어요. 그랬다면 지금 사과드립니다.)

이 방법들 안에 숨겨진 좋은 아이디어는, 기능들을 서로 비교하여 "더 큰지" "작은지" 분류하는 것입니다. 비슷한 항목들이 얼마나 걸리는지 몇 번 측정해보면, 팀은 꽤 빠르고 효과적으로 추정하는 법을 배울 수 있습니다.

하지만 기억하세요. 우리가 이 모든 것을 하는 이유는 이번 반복 주기에 얼마나 많은 일을 가져올지 결정하기 위해서입니다. 업무를 보고, 토론하고, 서로 눈을 맞추며 "이만큼 하자"라고 말하는 팀이 숫자 놀음(numerology)에 많은 시간을 쓰는 팀만큼 잘 해냅니다. 종종 더 잘합니다. 왜냐하면 팀워크와 헌신(commitment)은 숫자 계산보다 강력하기 때문입니다.

그래서 제 조언은 무엇일까요? 정말 간단합니다. 아마 실행하기는 어려울 겁니다. 당신만의 방법을 찾아야 하겠지만, 여기 두 가지 괜찮은 방법이 있습니다. 두 번째가 첫 번째보다 훨씬 낫습니다.

1. 좋지만, 이상적이지는 않은 방법: 배포 날짜를 정하고, 그때까지 매주 배포하라

"높으신 분들"은 마음속에 날짜가 있습니다. 드물게 없는 경우라면, 직접 정하세요. 아무도 기다리다 지치지 않을 만큼 가까운 날짜로요. 인원수를 세고, 가용 시간을 곱하세요. 그 때까지 가질 수 있는 것을 5가지 주요 항목 정도로 추측하세요. 필요하다면 쪼개되, 모호하게 유지하세요. 운전할 공간이 필요하니까요. 자! 이제 추정치가 포함된 예산이 생겼습니다.

이제 다음에 무엇을 하고 무엇을 미룰지 결정할 수 있는 "고객"이나 "제품 책임자"를 구하세요. 매우 짧은 주기로 일하세요. 2주. 혹은 1주. 한 번에 기능 하나씩. 가장 중요한 기능부터. 기능이 완료될 때마다, 혹은 적어도 2주마다 통합되고 테스트된 소프트웨어 버전을 만드세요. 모두에게 보여주세요. 가능하다면 필요한 사용자에게 전달하세요.

당신은 이제 1~2주마다 완전한 제품을 배포하고 있습니다. 마감일이 되면, 그건 그냥 또 하나의 배포일 뿐입니다. 모두가 만족한다면(아마 그럴 겁니다), 멈추세요. 더 원한다면, 당신은 이미 2주마다 더 만들 준비가 되어 있습니다.

2. 이상적인 방법: 추정을 건너뛰고, 당장 무언가를 만들어라 (Skip Estimating. Just Build Something Now.)

모든 제품을 간단한 실험으로 시작하는 건 어떨까요? 제품 비전이 있는 책임자와 개발자 몇 명이 1~2주 동안 앉아서 무언가를 만들어보는 겁니다. 그러고 나서 진행할지 말지 자문해 보세요. 더 큰 프로젝트인가요? 6개월이나 1년? 그렇다면 2주 단위 반복 주기로 몇 번 더 만들어보세요. 어디쯤 와 있는지 확인하세요. 좋다면 계속하고, 아니면 멈추세요.

진지하게 하는 말입니다. 문제를 이해하는 사람을 문제를 해결할 줄 아는 사람들과 함께 두세요. 가장 중요해 보이는 순서대로 문제를 해결하세요. 한 모든 것을 즉시 배포하세요. 사용자가 뭐라고 하는지, 시장이 뭐라고 하는지 보세요. 조정하세요.

이 접근법에 "이슈"가 있을까요? 물론입니다. 이걸 하려면 아주 잘해야 합니다. 무엇이 필요한지 잘 추측할 수 있는 사람과, 사용자에게 매우 빠르게 전달할 수 있을 만큼 높은 품질로 신속하게 만들 수 있는 팀이 필요합니다. 그리고 필요에 따라 부드럽게 성장할 수 있는 유연한 소프트웨어를 만드는 법을 알아야 합니다. 기술적인 측면은 이미 잘 알려져 있습니다. 결정 측면(고객 측면)은 그렇지 않지만, 기다린다고 나아지지 않습니다. 제품을 세상에 내놓고 무슨 일이 일어나는지 보세요.

이 접근법은 가치 전달을 지연시키는 모든 사이클을 단축합니다. 원하는 사람과 하는 사람 사이의 의사소통 라인을 단축합니다. 만드는 사람과 쓰는 사람 사이의 라인을 단축합니다. 가장 중요한 아이디어를 취하고, 빨리 만들고, 내보내세요.

네, 하기 어렵습니다. 그래서 이게 최고인 겁니다.

추정을 멈추세요. 배포를 시작하세요.