이 글은 "Critical Chain(한계를 넘어서)"를 읽고 정리한 내용이다. 책 내용 중에 볼 것이 많아 리뷰 하나로는 부족할 듯 하여 몇 개로 나누어서 정리한다.
불확실성이 높을수록 그림과 같이 확률 분포도의 꼬리는 길어진다는 것이다. 롱테일? ^^ 불확실성이 높을수록 평균은 가장 확률이 높은 곳의 오른쪽으로 점점 멀어진다. 즉 여유 시간을 두는 것이다. 어떠한 불확실성에 대한 여유 시간.
프로젝트 예상 시간을 예측할 때도 이와 비슷하나 차이점이 있다면 여유 시간을 많이 둔다는 것이다. 보통 확률 80~90% 정도 수준에서 예상 시간을 잡는다. 다음 그림과 같이 말이다.
문제는 시간이다. 확률 80~90% 정도 수준에서 예상 시간을 잡으면 평균 확률보다 시간은 두 배가 증가한다는 것이다. 위의 그래파 X축을 보라.
여유 시간의 책정의 허
그럼 왜 여유 시간을 추가하는가? 거야 당연히 여유 시간을 두어야 불확실성에 대비할 수 있고 시간 내에 완료하기 위해서일 것이다. 책에서는 다음과 같이 세 가지 이유를 들고 있다.
1) 실패 경험을 토대로 여유 시간을 예측하는데, 분포 곡선 오른쪽 끝(80~90%수준)에서 잡는다.
2) 관리 레벨이 많아지면 예측시간이 길어지는데 그것은 각 레벨마다 여유 시간을 두기 때문이다.
3) 예측 작업을 하는 사람들이 전체 시간이 단축될 것을 감안하여 여유 시간을 추가한다.
아주 설득력 있는 얘기다. 가만히 보면 프로젝트가 소규모가 아니라 대규모일 경우에는 여유 시간이 매우 늘어난다는 것을 알 수가 있는데, 각 단위별로 여유 시간을 두고 그 단위의 총합에서 또 여유 시간을 두기 때문이다.
그럼 왜 여유 시간이 이렇게 적당히 두는데도 프로젝트가 시간 내에 완료가 되지 않을까? 업체측의 빈번한 요구 사항 또는 내부 기획의 수정으로 인한 작업 수정 때문일까?
왜 여유 시간을 두고도 여유가 안 생기는가?
1) 학생 증후군
이 부분은 부연 설명이 필요할 것 같다. 멀티 태스킹으로 인해 리드 타임이 증가하는 것은 A, B, C 별개로 보면 충분히 이해가 되는 부분이다. 위의 그림으로는 A가 끝나는 데는 10 만큼의 시간이 걸리고 아래 그림으로는 A가 끝나는 데는 20 만큼의 시간이 걸린다. 그러나 전체적으로 보면 60으로 같지 않은가? 어찌보면 멀티 태스킹이 더 효율적일 수 있지도 않을까?
이런 상황을 잘 생각해봐야 한다. 책에서는 Bottleneck이 발생하는 전산부서의 얘기를 하고 있는데 A, B, C라는 전체 프로젝트 중에서 전산부서에서 해야할 부분들이 있고 갑작스럽게 세 개의 프로젝트들을 수행해야 하는 상황에서는 멀티태스킹을 할 수 밖에 없는 것이다. 이것은 부서간에 자기네 프로젝트가 더 중요하다고 외치는 상황을 곰곰히 생각해보면 충분히 수긍이 갈 듯.
그러면 전산부서에서는 효율적인 업무를 수행하기 위해서 멀티 태스킹을 하게되는 것이고 결국 이것인 리드 타임 증가라는 결과를 초래하게 된다는 것이다. A는 10 만큼의 시간에 끝낼 수 있었는데, 20이 되어서야 끝났고, B 는 20 이라는 시간이 흐르면 끝날 수 있었는데 25 시점에서 끝났고 C 하나만 제대로 끝났을 뿐이다.
그러나 A, B, C가 모두 다 중요하다고 하니 전산부서에서는 멀티 태스킹을 할 수 밖에 없는 것이다. 모든 프로젝트가 중요하다는 것은 어느 것도 중요하지 않다는 뜻이다. 위와 같이 멀티 태스킹을 해서 리드 타임이 증가할 것 같으면 우선 순위를 두고 하나씩 끝내는 것이 더 효율적이라는 것이다. 일을 하다보면 이런 경우는 정말 많이 생기는 듯.
3) 단계 간의 의존성
왼쪽에 있는 일들이 끝나야 다음 단계의 작업을 할 수 있는 의존성 관계가 있을 때, 왼쪽의 4가지 일 중에 세 작업은 시간보다 5 만큼 빨리 끝냈고 한 작업은 시간보다 15 만큼 늦게 일을 끝냈다면 전체적으로 예상 시간은 15 - 5 - 5 - 5 = 0 인가? 아무도 그렇게 생각하는 사람은 없을 것이다. 한 개의 늦은 작업 때문에 전체적으로 15 만큼 늦어졌다.
결국 이런 의존성 문제 때문에 지연된 시간은 누적되지만 일찍 끝내 절약한 시간은 낭비가 된다는 것이다. 이런 문제는 기존의 저서 "The Goal"에서 프로젝트가 아닌 제조에서 재고라는 문제와 유사하다. 단지 프로젝트에서는 시간을 제조에서는 재고라는 것으로 바뀌었을 뿐인데 단순히 개념만 바뀐 것은 아니라는... 왜? 재고는 시간이 흘러도 남아 있지만 시간은 없어지기 때문...
이 책은 통계 자료를 통해서 얘기를 하지는 않는다. 그러나 논리적인 맥락에서 설득력을 갖고 있다. 시스템, 구조화, 체계화라는 것에 익숙한 우리가 핵심을 놓치고 있는 것은 아닌가 하는 생각이 들게 만든다. 위의 얘기를 읽다보면 정말 그럴 듯 하지 않은가?
프로젝트의 여유 시간
우리가 보통 어디까지 가는 데에 걸리는 시간을 말할 때 일반적으로 평균을 쓴다. 상황에 따라 더 걸릴 수도 있고, 더 빨리 갈 수도 있지만 일반적으로 얘기를 할 때는 가장 확률적으로 높거나 걸리는 평균 시간을 얘기한다. 그것을 그래프로 그린 것이 다음이다.
불확실성이 높을수록 그림과 같이 확률 분포도의 꼬리는 길어진다는 것이다. 롱테일? ^^ 불확실성이 높을수록 평균은 가장 확률이 높은 곳의 오른쪽으로 점점 멀어진다. 즉 여유 시간을 두는 것이다. 어떠한 불확실성에 대한 여유 시간.
프로젝트 예상 시간을 예측할 때도 이와 비슷하나 차이점이 있다면 여유 시간을 많이 둔다는 것이다. 보통 확률 80~90% 정도 수준에서 예상 시간을 잡는다. 다음 그림과 같이 말이다.
문제는 시간이다. 확률 80~90% 정도 수준에서 예상 시간을 잡으면 평균 확률보다 시간은 두 배가 증가한다는 것이다. 위의 그래파 X축을 보라.
여유 시간의 책정의 허
그럼 왜 여유 시간을 추가하는가? 거야 당연히 여유 시간을 두어야 불확실성에 대비할 수 있고 시간 내에 완료하기 위해서일 것이다. 책에서는 다음과 같이 세 가지 이유를 들고 있다.
1) 실패 경험을 토대로 여유 시간을 예측하는데, 분포 곡선 오른쪽 끝(80~90%수준)에서 잡는다.
2) 관리 레벨이 많아지면 예측시간이 길어지는데 그것은 각 레벨마다 여유 시간을 두기 때문이다.
3) 예측 작업을 하는 사람들이 전체 시간이 단축될 것을 감안하여 여유 시간을 추가한다.
아주 설득력 있는 얘기다. 가만히 보면 프로젝트가 소규모가 아니라 대규모일 경우에는 여유 시간이 매우 늘어난다는 것을 알 수가 있는데, 각 단위별로 여유 시간을 두고 그 단위의 총합에서 또 여유 시간을 두기 때문이다.
그럼 왜 여유 시간이 이렇게 적당히 두는데도 프로젝트가 시간 내에 완료가 되지 않을까? 업체측의 빈번한 요구 사항 또는 내부 기획의 수정으로 인한 작업 수정 때문일까?
왜 여유 시간을 두고도 여유가 안 생기는가?
1) 학생 증후군
과제를 받았을 때, 우리는 모두 2주는 부족하다고 주장했습니다. 그리고 과제를 연기하는데 성공했습니다. 하지만 시간이 더 필요하다고 소리소리 질러댄 우리들 가운데, 집에 돌아가자마자 곧장 과제에 매달리기 시작한 사람이 과연 몇이나 될까요? 그런 사람은 아무도 없었을 거라고 저는 장담합니다.
처음엔 여유 시간을 가지려고 투쟁하지요. 그러다 일단 시간이 확보되면, 이제 시간이 충분한데 뭣 때문에 서두르겠습니까? 언제 숙제를 하려고 자리에 앉을까요? 시간이 거의 다 되어서입니다. 인간의 본성이죠.
일단 일을 시작해야, 무슨 문제가 있는지를 알 수 있죠. 만일 문제가 있다면, 우리는 미친듯이 일을 하기 시작합니다. 하지만 이미 여유 시간은 낭비해 버렸습니다. 그러니 일은 늦어질 수밖에 없지요. 그래요, 바로 이게 그 많은 여유 시간에도 불구하고 많은 단계에서 일이 조금씩 늦어지는 것에 대한 답입니다.
2) 멀티 태스킹
이 부분은 부연 설명이 필요할 것 같다. 멀티 태스킹으로 인해 리드 타임이 증가하는 것은 A, B, C 별개로 보면 충분히 이해가 되는 부분이다. 위의 그림으로는 A가 끝나는 데는 10 만큼의 시간이 걸리고 아래 그림으로는 A가 끝나는 데는 20 만큼의 시간이 걸린다. 그러나 전체적으로 보면 60으로 같지 않은가? 어찌보면 멀티 태스킹이 더 효율적일 수 있지도 않을까?
이런 상황을 잘 생각해봐야 한다. 책에서는 Bottleneck이 발생하는 전산부서의 얘기를 하고 있는데 A, B, C라는 전체 프로젝트 중에서 전산부서에서 해야할 부분들이 있고 갑작스럽게 세 개의 프로젝트들을 수행해야 하는 상황에서는 멀티태스킹을 할 수 밖에 없는 것이다. 이것은 부서간에 자기네 프로젝트가 더 중요하다고 외치는 상황을 곰곰히 생각해보면 충분히 수긍이 갈 듯.
그러면 전산부서에서는 효율적인 업무를 수행하기 위해서 멀티 태스킹을 하게되는 것이고 결국 이것인 리드 타임 증가라는 결과를 초래하게 된다는 것이다. A는 10 만큼의 시간에 끝낼 수 있었는데, 20이 되어서야 끝났고, B 는 20 이라는 시간이 흐르면 끝날 수 있었는데 25 시점에서 끝났고 C 하나만 제대로 끝났을 뿐이다.
그러나 A, B, C가 모두 다 중요하다고 하니 전산부서에서는 멀티 태스킹을 할 수 밖에 없는 것이다. 모든 프로젝트가 중요하다는 것은 어느 것도 중요하지 않다는 뜻이다. 위와 같이 멀티 태스킹을 해서 리드 타임이 증가할 것 같으면 우선 순위를 두고 하나씩 끝내는 것이 더 효율적이라는 것이다. 일을 하다보면 이런 경우는 정말 많이 생기는 듯.
3) 단계 간의 의존성
왼쪽에 있는 일들이 끝나야 다음 단계의 작업을 할 수 있는 의존성 관계가 있을 때, 왼쪽의 4가지 일 중에 세 작업은 시간보다 5 만큼 빨리 끝냈고 한 작업은 시간보다 15 만큼 늦게 일을 끝냈다면 전체적으로 예상 시간은 15 - 5 - 5 - 5 = 0 인가? 아무도 그렇게 생각하는 사람은 없을 것이다. 한 개의 늦은 작업 때문에 전체적으로 15 만큼 늦어졌다.
결국 이런 의존성 문제 때문에 지연된 시간은 누적되지만 일찍 끝내 절약한 시간은 낭비가 된다는 것이다. 이런 문제는 기존의 저서 "The Goal"에서 프로젝트가 아닌 제조에서 재고라는 문제와 유사하다. 단지 프로젝트에서는 시간을 제조에서는 재고라는 것으로 바뀌었을 뿐인데 단순히 개념만 바뀐 것은 아니라는... 왜? 재고는 시간이 흘러도 남아 있지만 시간은 없어지기 때문...
이 책은 통계 자료를 통해서 얘기를 하지는 않는다. 그러나 논리적인 맥락에서 설득력을 갖고 있다. 시스템, 구조화, 체계화라는 것에 익숙한 우리가 핵심을 놓치고 있는 것은 아닌가 하는 생각이 들게 만든다. 위의 얘기를 읽다보면 정말 그럴 듯 하지 않은가?
