Why planning fails

계획과 추정에 대한 연구결과

• 2/3 가량의 프로젝트는 추정된 비용 이상으로 많은 돈이 든다.
• 최종 제품에 포함된 기능들 중 64 퍼센트 가량은 거의 혹은 결코 쓰이지 않는다.
• 평균적인 프로젝트는 계획된 일정을 두 배 정도 초과한다.

왜 이런 결과가 나왔을까? 왜 계획법은 실패했을까?

활동이냐 기능이냐

• 활동: 특정 팀이 어떤 행위를 하는가?
• 기능: 특정 팀이 어떤 결과를 내는가?

간트 차트, 작업 분해도는 기본적으로 활동 기반 계획법이다. 이런 활동 기반 계획법은 그 자체로 한계를 가지고 있다.

1. 활동의 종료를 통해 고객이 어떤 가치를 획득하는지 알수가 없다.
   • 고객은 “기능” 위주로 가치를 산정한다.
2. 계획을 검토시 “어떤 기능을 빠트렸지?”가 아닌, “계획에 적힌 무엇을 하지 않았지?”로 검토한다.
   • 즉, 활동 기반으로 작성된 계획서에 매몰되게 된다. 역시나 고객 관점에서 생각하지 않게 된다.

위의 이유는 어떻게 보면, 근본적인 문제점에 대해서 고찰하고 있다. 좀더 구체적으로 왜 전통적인 계획법이 실패할 수 없는지에 대해 알아보자.

예정된 일정을 어기게 되는 일이 빈번히 발생한다

이런 일정 문제 때문에, 제품의 질을 포기하는 일까지 발생하곤 한다.

활동이 일정보다 일찍 끝나지 않는다

• A라는 기능을 5일 안에 만들라는 활동 계획이 있었다고 해보자.
• 해당 개발자는 5일 이전에 더 빠릴 일을 마치려고 할까?
• 빨리 마쳤다면, 자료 조사 정도는 할 수 있겠지만 보통은 웹서핑하면서 쉬려할 것이다.
• 이렇듯 간트 차트에 작업 소요시간 자체를 적는 것은, 빨리 종료될 경우 뭘하든 상관 안하겠다는 의지의 표명이다.
• 그리고, 그 시간에 인간은 가치를 생산적인 일을 하지 않는다.

한 활동의 지연은 뒤이은 활동들에게도 영향을 준다

전통적인 계획법은 “활동 중심적”으로 구성되어 있기 때문에 활동간의 의존성에 주목한다.

위와 같은 상황에서 테스트를 일찍 수행하고 싶다면 어떤 것들이 충족되어야 할까?

• 미들 티어 부분이 일찍 마무리되어야 한다.
  • 그리고 이 부분은 데이터베이스 작업에 의존적이다.
• UI 코딩이 일찍 종료되어야 한다.
• 테스터도 일찍 데려와서 가용할 수 있어야 한다.

위와 같은 의존 구조에서도 테스트 일정을 앞당기기 위해 고려해야하는 점이 세가지나 된다. 반면 그 반대는 하나라도 틀어지면 바로 일정이 늦어진다.

• 데이터 베이스 작업이 늦어진다.
• 미들 티어 작업이 늦어진다.
• UI 작업이 늦어진다.
• 테스터를 쓸 수 없다.

활동 중심적으로 작성한 계획이 일찍 종료되는 것은 기대하기 힘들다.

활동들은 서로 독립적이지 않다

• 소프트웨어 개발 프로젝트를 구성하는 활동들은 상호 종속적인 경우가 많다.
• 개발 과정에서 수행되는 활동들간에 독립성이 없으면 활동은 이후에 영향을 준다.

멀티태스킹은 또 다른 지연을 발생시킨다

• 전통적인 계획법이 실패한 이유로 멀티 태스킹이 있다.
• 위의 그림은, 각 개인이 가치 창조를 위해 쓰는 시간의 양이 세 가지 이상의 작업을 할 때 급감하는 것을 보여준다.
• 즉, 서로 상이한 성격의 작업을 왔다 갔다하는데서 오는 Overhead가 있다. (Context Switching)

프로젝트가 지연되고, 의존성이 짙게 깔려있으며, 일정이 다가오는 상황일 때, 어떤일이 벌어지는지 확인해보자. 위의 상황은 정상적인 계획을 말한다. DB, API, UI 개발이 순차적으로 이루어질 것이라 예상한 활동 계획이다. 한 개발자는 각 기능에 대해 10일을 산정하여 작업을 하고 있다.

1. 10일 동안 DB 개발을 해야하는 상황인데, B 개발자가 연락이와서 API를 뚫어달라고 부탁한다.
2. API 작업을 그래서 해주고 있는데, 테스터가 UI를 구현해달라고 부탁한다.
3. UI 작업을 마치고 DB로 돌아왔더니 1, 2가 반복된다.

즉, 3개의 작업을 멀티 태스킹하고 있다. 위의 그림을 보면, 그 멀티태스킹의 결과로 DB작업은 결과적으로 20일이 소요된 후에야 완료될 수 있었다. API, UI도 마찬가지다. 이 단계에서 Context Switching 비용은 생각도 안했다는 것을 기억하자.

우선순위에 따른 기능 개발이 이루어지지 않는다

• 전통적인 계획법은 고객에게 전달될 가치에 따른 우선순위대로 작업을 진행하지 못한다.
• 하기로한 모든 활동들이 제때 끝나는 것을 중요하게 여기기 때문이다.
• 실제 제품을 만드는 개발자들의 편의대로 계획은 재조정되고, 결정된다.
• 이러한 실상에, “활동만 다 마치면 되는거 아님? 순서는 고객이 별 신경안쓸거야~“라고 생각하기 마련이다.
• 하지만 고객 입장에서는 “계획성이 없어보이는 순서”로 작업이 진행되는 것을 보게 된다.
• 그러다가 일정이 임박하면 일정을 맞추기 위해 기능을 제거한다.
• 그리고 그 와중에는 필수적으로 들어가야하는 기능도 있다.
• 즉, 기능 기준으로 생각하지 않기 때문에, 우선순위대로 기능 개발 역시 이루어질 수 없다.

불확실성을 무시한다

• 애초에 계획을 짤 때, 불확실성을 인정하지 않고 만든다.
• 진행도중 고객이 마음을 바꾸거나, 더 세밀한 의견을 내놓거나 하는 일이 발생하지 않을 것이라고 가정한다.
• 실제로 진행도 안해보고서 “2주 소요”와 같은 딱지를 붙여놓고 진행될 거라고 막연히 믿는 것은 상당히 비합리적이다.
• 1장에서 본 “불확실성 원추”처럼, 실제로 진행하면서, 그 예상치의 편차가 줄어들게 되는 것이다.
• 불확실성을 제어하는 가장 좋은 방법은 **반복(Iteration)**이다.
  • 이를 도입하게 되면, 비로소 “계획”자체보다, 어떻게 계획 과정을 수립할지에 대해 생각하게 된다. (계획 system)

추정치가 서약으로 변한다

• 계획시 작성한 시간은 추정치이다. 절대값이 아니다.
• 그럼에도 불구하고, 이 추정치를 책임자가 약속으로 받아들이는 순간 문제가 발생한다.
• 추정치는 확률적인 값이다. 약속은 절대적인 값이다. 이 둘은 엄연히 다르다.

요약

전통적인 계획법이 실패하는 이유는 다음과 같다.

• 예정된 일정을 어기게 되는 일이 빈번히 발생한다.
• 멀티태스킹은 또 다른 지연을 발생시킨다.
• 우선순위에 따른 기능 개발이 이루어지지 않는다.
• 불확실성을 무시한다.
• 추정치가 서약으로 변한다.

전통적인 계획법은, 완벽할 것이라 가정하는 “계획”에 지나치게 치중하여 고객의 “만족도”와 프로젝트 “완성도”를 해친다. 프로젝트를 수행하는 이유는, 누군가에게 가치를 전달해주기 위함이다. 그것에 집중하기 위해서는 인사(人事)가 가진 본성인 “불확실성”에 대해 인정하고, 이를 다룰 수 있는 방법에 대해 고민하는 것이 옳다. 그리고 이는 Iteration이라는 반복과정을 통해 효과적으로 제어할 수 있으며, 이를 통해 기민한 계획 수정을 통해 고객 중심으로 프로젝트를 관리할 수 잇다.

토론거리

1. 고객에게 전달할 기능 대신 활동에 집중하는 계획을 따르면 어떤 문제가 발생할 수 있을까?
2. 지금 업무환경에서 추정치 == 약속 인가? 그랬다면 어떤 문제가 발생하는가?
3. 2번의 잘못된 이해를 바로 잡으려면 어떤 일을 할 수 있을까?
4. 본인에게 멀티 태스킹은 어떤 영향을 미쳤는가?
5. 멀티 태스킹이 주는 악영향을 어떻게 감소시킬 수 있을까?

Reference

• 불확실성과 화해하는 프로젝트 추정과 계획
• Agile Estimating and Planning