일기장/2007-08-28

며칠 전에 한계를_넘어서를 다시 읽었다. 그리고 요 며칠 생각을 하다보니 상세한 일정이 왜 나쁜지를 좀더 명확히 설명할 수 있을 것 같다.

보통 일정 관리란 걸 강하게 하는 조직들을 보면 일을 작은 Task로 쪼개고 그 Task별로 사람을 할당하고 Task별 일정을 잡는다. 그래서 Task들이 chain처럼 이어지게 만든다. 이런 식의 일정 압박이 주어지기 시작하면 일정을 지키지 못했을 때 죄인 취급을 당할 수 있기 때문에 자신의 Task를 정해진 시간에 끝마치는데 주력하게 된다. 그러면 두 가지 문제가 발생한다. 하나는 다른 사람의 업무에 관심을 끊게 되는 것이다. 커뮤니케이션 비용도 더 부담이 되기 때문에 커뮤니케이션을 더 하지 않으려는 경향이 생기고 그러다보면 conflict가 커져서 나중에 더 큰 커뮤니케이션 비용을 치르거나, 혹은 결함을 덮어두고 지나가게 된다. 협업이 깨지는 것이다.

또 다른 문제는 원래 일정을 상세하게 잡았던 목적을 달성할 수 없다는 것이다. 보통 일정을 상세하게 잡는 이유는 프로젝트를 빨리 완성하기 위한 것이다. 팀원들이 최선을 다할 것이라는 믿음이 없기 때문에 일정을 압박해서 열심히(?) 일하게 만들면 빨리 끝낼 수 있을 것이라고 기대하는 것이다. 그러나, 이런 일정 압박에 시달리는 팀원들은 개별 Task에 대한 예측에 여유 시간을 많이 포함하게 된다. 이것이 한계를_넘어서에서 말하고 있는 것이다. 예를 들어 어떤 일이 10시간에 끝낼 가능성이 50% 정도라고 하자. 그러면 대개 95%의 확률로 끝낼 수 있는 시간은 30시간 이상이다. 만약 일정을 정하는 것이 아니라 단순히 예측만 하라고 한다면 대부분의 사람들은 50% 지점, 혹은 6~70% 지점 정도로 예측값을 내놓을 것이다. 아마 10~15시간 정도일 것이다. 그런데 일정에 대한 압박이 심하다면 대부분 95% 지점의 예측치, 즉 30시간을 내놓게 된다. 만약 이런 일들이 5개가 chain으로 연결되어 있다고 해보자. 이 일들을 task별로 쪼개서 일정 관리를 하지 않는다면 아마 50%의 확률로 50시간에 끝날 것을 예측할 수 있을 것이다. 하지만 task별로 쪼개서 심한 일정 압박을 넣는다면 다들 30시간으로 예측할 것이고 이 프로젝트는 최소한 150시간이 걸릴 것이다. 각각의 task에서 잡은 buffer가 합쳐지지 않으면 buffer로 기능하지 못하고 실제 작업 시간이 되어 버리는 것이다.

여기에 연관되는 또 하나의 부작용이 있다. 예를 들어 일정이 30일 남았다고 하자. 근데 10일 걸리는 어떤 일이 있다. 근데 이 일은 22일째부터 시작할 수 있을 것으로 예상되지만 더 늦게 시작할 수도, 더 일찍 시작할 수도 있다. 그러면 가장 합리적인 선택은 상황을 봐가면서 22일째를 전후해서 그 10일짜리 일을 하는 것일 것이다. 그러면 아마 일정이 2일 정도 미뤄질 수는 있겠지만 10일 짜리 일이 그만한 가치가 있다면 좋은 선택이 될 것이다. 근데 30일이라는 일정이 못 박혀 있다면 어떻게 될까. 아마도 팀원들은 최악의 경우를 산정해서 22일 이전에 시작할 가능성을 염두에 두지 않을 것이다. 그럼 10일 짜리 일은 다음 텀으로 미뤄진다. 그러면 실제로 여유 시간이 8일치만큼 남더라도 활용할 수 없고 10일 짜리 기능이 고객에게 전달되는 것은 2일이 아니라 10일이 미뤄질 것이다. 아니, 어쩌면 30일이 더 미뤄질 것이다.

이런 일이 반복되다보면 고객의 만족은 뒷전이 될 수 밖에 없다. 아니면 팀원들의 삶이 뒷전이 되거나. 아니, 보통은 둘 다일 것이다. 거기에 더 나쁜 것은 일정에 대한 압박이 일정은 맞추게 하지만 TimeToMarket은 더 커지게 만든다는 것이다.

그래서일까, BUILT_to_LAST에서는 상세한 계획은 반드시 실패한다라고 말하고 있다. 상당히 설득력이 있는 주장인 것 같다.