CCPM에 대한 단상

'린 소프트웨어 개발의 적용'이라는 책을 보면 뒷부분에 제약이론에 대해 소개하고 있다.

그 중에는 제약이론의 CCPM에 대하여 아래와 같은 문구가 있다.

'소프트웨어 개발에 에로사슬을 사용하는데 있어서의 부가적인 문제는, 개발을 완료할 모든 업무를 사전에 알고 있어야하고 그들 간의 의존관계를 잘 파악하고 있어야 한다는 가정에 있다. 앞서 살펴본 바와 같이 이러한 가정들은 대다수 소프트웨어 개발에 적절치 않다.'

- 린 소프트웨어 개발의 적용 -

나도 처음에 CCPM을 배울 때 위와 같은 생각을 했었다. CCPM을 하려면 프로젝트 전체 기간의 모든 작업과 모든 일정을 모두 알아야 하는 것이 아닌가? 그런게 정말 가능하긴 한걸까? 우리의 추정이 과연 그 먼 기간까지 유효할 수 있을까?

표면적인 CCPM의 모습은 기존의 PERT/CPM이나  Gantt chart와 별반 다를바가 없어 보인다.

CCPM이라는 것이 기존의 WBS 관리 방법의 제약을 해소하고자 하는 사고 프로세스의 산물이기 때문에 CCPM을 작성하기 위해서는 기본적으로 최소한 Gantt chart와 같은 방법으로 WBS를 관리하고 있어야 한다. 이것은 기존의 일정관리가 안고 있던 여러 가정들을 그대로 승계하게 된다.

하지만 CCPM에서 정작 가장 중요하게 강조하는 것은 자원 경합의 해소이다. 기계이든 사람이든 작업을 수행하는 주체가 하나의 작업에 온전히 집중할 수 있도록 일정을 관리하고자 하는 것이 CCPM의 핵심이다.

만약 Agile 방법론에서 말하는 것과 같이 팀의 모든 구성원들이 모든 역할을 수행할 수 있다면 자원의 경합은 더 이상 문제가 되지 않을 것이다.

하지만 실제 프로젝트에서 그런 경우는 거의 없다. 자원의 경합은 언제 어디서나 쉽게 찾아볼 수 있다.

CCPM에 문제가 있다면 우리는 그것을 더욱 더 개선할 수 있다. TOC의 입장에서 본다면 Agile 은 폭포수 모델에서 TOC를 적용하여 궁극적으로 도달하는 하나의 지향점이라고 할 수 있다. 하지만 또 다르게 생각한다면 전혀 다른 방법론을 만들어 낼 수도 있을 것이다.

그것이 TOC의 힘이다. 그리고 그러한 작업을 꼭 한번 해보고 싶다.

혹시 나와 같은 생각으로 폭포수 모델도 Agile도 아닌 제 3의 방법에 대해 생각해 보고자 하시는 분이 있다면

IT와 TOC의 융합을 연구하는 사람들

에 참여해 주시기 바란다.