(요약 1편) 한계를 넘어서: 크리티컬 체인

  • Post author:
  • Post category:
  • Post comments:6 Comments
  • Post last modified:February 8, 2020

6장

프로젝트 실패의 공식적인 이유

늘 외부 세계(예기치 못한 문제, 악천후 등의 불확실성) 탓으로 돌린다.

프로젝트 실패의 비공식적인 이유

하위직에 있는 사람일수록 외부보다는 내부를 향해 손가락질 한다. 다음과 같은 이유를 예로 들 수 있다.

  • 실현가능성이 없는 일정
  • 품질보다는 가격 중시: 불확실성에 대처할 수 있는 납품업자의 능력은 선정기준이 아니었다.

대부분의 문제는 직접 또는 간접적으로 불확실성의 결과이며, 그로 인한 문제와 그에 따른 지연으로 인해 발생한 문제들을 다시 동기화하기 위하여 끊임없이 애를 써야 한다.

불확실성에 대한 고려

사람들은 불확실성에 대비하여 프로젝트 단계마다 여유시간을 추가한다. 즉 사람들은 가장 안 좋았던 과거 경험을 토대로 현실적인 예측값을 찾아낸다.

추정 시간

크게 보기

확률 분포도 중앙값과 실제 예측 시간과의 차이가 바로 우리가 추가하는 여유시간이다. 어떤 한 단계를 50퍼센트의 실현 가능성으로 예측했을 때, 일반적으로 200퍼센트 이상의 여유 시간을 둔다.

위의 분석이 사실이라면 상당수의 단계는 예측 시간보다 일찍 완료될 것이다. 그러나 대부분의 경우에 예측 시간만큼 소요된다. 예측에는 추정된 시간을 모두 사용하게 하려는 자체 충족 능력(self-fulfilling prophecy)가 있다.

9장

Critical Path

연결 단계가 가장 긴 패스를 의미한다.

비크리티컬 패스는 언제 시작해야 하나?

재정적인 측면보다는 오히려 관리적인 측면에서 고려해야 할 문제다.

  1. 모든 패스를 가장 빨리 시작한다.
    -> 프로젝트 리더가 신경써야 할 일이 많아진다.
    -> 리더가 집중력을 잃게 되면서 프로젝트가 지연된다.
    -> 프로젝트 완료 지연으로 인해 수입 발생까지 지연된다.
  2. 늦게 시작한다.
    -> 모든 게 중요해진다.
    -> 모든 걸 집중관리해야 하는데, 이것은 집중관리가 안 된다는 것을 의미한다.
    -> 프로젝트 완료 지연
    -> 수입발생 지연

프로젝트 통제를 위해서는 진행 상태를 측정해야 한다.

문제는 프로젝트 현황 보고서에 무언가 잘못되었다고 보고가 될 때는 이미 너무 늦었다는 것이다. 프로젝트 현황 보고서에서는 프로젝트의 90%를 끝내는 데 1년이 걸렸다고 되어 있다 하더라도, 그 나머지 10%를 끝내는 데 꼬박 1년이 걸릴 수도 있기 때문이다.

왜 이런 일이 발생하는가? 크리티컬 패스를 기준으로 측정하지 않았기 때문이다.

11장

성공적인 관리의 두 가지 필수조건

  1. 비용 통제
  2. 쓰루풋(throughput) 보호

원가 세계

어떤 부분적인 개선도 자동적으로 조직의 개선으로 간주된다. 즉 조직의 개선을 이룩하기 위해서는 많은 부분적인 개선을 유도해야 한다.

쓰루풋 세계

체인의 강도를 결정 짓는 것은 가장 약한 연결 고리 하나이다. 한 부서의 경쟁력이 세 배 향상되었더라도 전체 조직의 경쟁력은 그대로일 수 있다.

원가 세계와 쓰루풋 세계의 절충 – 월말 증후군

월초에는, 자니가 설명을 시작했다. 우리는 비용을 통제합니다. 야근도 엄격히 통제하죠. 배치 싸이즈도 최적으로 유지하려 합니다. 그러나 월말이 되면, 이런 것들은 다 잊혀집니다. 빌어먹을 제품들을 출하시키기 위해 무엇이든 합니다. 이 제품 세 개를 서둘러 끝내시오. 주말 내내 야근을 해서라도 출하시키시오. 출하!

자니는 목소리를 낮추었다. 무슨 일이 일어나고 있습니까? 이 회사들은 지금 월초에는 원가 세계에 따라 관리를 하다가, 월말이 되면 쓰루풋 세계에 따라서 관리를 하고 있는 겁니다.

원가 세계와 쓰루풋 세계는 타협할 수 없다. – 파레토의 법칙에 대한 비판

20-80 법칙은 독립 변수로 이루어진 시스템에만 적용된다. 즉 각 연결 고리가 개별적으로 관리되는 원가 세계에만 적용된다는 뜻이다. 쓰루풋 세계의 조직들은 다섯 개 이상의 연결 고리로 이루어져 있기 때문에, 20%를 개선한다고 해도 그 대부분은 전체적인 조직 성과를 개선하는 데 도움이 되지 못한다. 변수들이 상호의존적이기 때문에 파레토의 법칙은 적용되지 않는다.

쓰루풋 향상을 위한 프로세스

  1. 시스템의 제약들을 찾는다. (Identify the system’s constraints)
  2. 가장 약한 연결고리를 강하게 만든다.
    • 물리적인 제약

      수요를 충족시킬만한 충분한 능력이 없는 자원, 즉 병목 현상이 일어나는 작업장 같은 물리적인 제약.

      • 작업 능력의 증가 (추가 고용 및 시설 투자)
      • 갖고 있는 능력에서 최대한 쥐어짜내기
    • 정책적인 제약: 정책의 변화 (주의! 잘못된 정책을 더 강화해서는 안 된다.)
  3. 윗 단계에서 내린 결정에 다른 모든 것을 종속시킨다. (SUBORDINATE everything else to the above decision)

    병목 작업장의 생산능력 = 10개/시간
    비병목 작업장의 생산능력 = 20개/시간

    이와 같은 조건일 때 비명목 작업장은 시간당 10개를 생산해야 한다. 생산능력의 한계만큼 생산하면 불필요한 재고가 쌓이고, 그에 따라 비용은 상승한다. 원가 세계에선 이런 경우의 생산효율을 50%로 볼 것이다.

  4. 시스템의 제약들을 향상시킨다. (ELEVATE the system’s constraints)

13장

5 + 5 = 13

만일 어떤 사람이 자기 작업이 5일 걸린다고 예측하고, 또 같은 팀에서 이루어지는 그 다음 작업도 5일 걸린다고 예측되면, 책임자는 총 13일이 걸린다고 예측한다. 여기에 최고 경영자가 프로젝트 기간 단축 요구를 예상한 값까지 고려하게 된다.

여유 시간 책정의 메커니즘

  1. 사람들은 실패했던 경험을 토대로 여유 시간을 예측하는데, 이는 분포 곡선 오른쪽 끝쪽에 해당한다.
  2. 프로젝트 관리 레벨이 많아지면 많아질수록, 총 예측 시간도 길어진다. 왜냐하면 각 레벨마다 자체적으로 여유 시간을 끼워넣기 때문이다.
  3. 예측 작업을 하는 사람들이 예측 기간이 전체적으로 잘릴 것에 대비해 아예 미리 여유 시간을 추가한다.

만일 프로젝트 총 예측 기간에 그렇게 많은 여유 시간이 포함되어 있다면, 도대체 어째서 그 많은 프로젝트들이 제때에 끝나지 못하는 것일까?

연속된 작업 단계에서는 지연된 시간과 일찍 끝나 절약된 시간의 편차는 평균화되지 않는다. 지연된 시간은 누적되지만, 일찍 끝나 절약된 시간은 누적되지 않는 것이다.

  1. 학생 증후군
    처음엔 여유 시간을 가지려고 투쟁한다. 그러다 일단 시간이 확보되면, 시간이 충분한데 서두를 필요가 없다.
  2. 멀티 태스킹에 의한 리드 타임 증가

    리드 타임

    크게 보기

  3. 각 단계 간에 존재하는 의존성 때문에, 지연된 시간은 누적되지만, 일찍 끝내 절약한 시간은 낭비만 된다.
Author Details
Kubernetes, DevSecOps, AWS, 클라우드 보안, 클라우드 비용관리, SaaS 의 활용과 내재화 등 소프트웨어 개발 전반에 도움이 필요하다면 도움을 요청하세요. 지인이라면 가볍게 도와드리겠습니다. 전문적인 도움이 필요하다면 저의 현업에 방해가 되지 않는 선에서 협의가능합니다.
0 0 votes
Article Rating
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

6 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
kingori
17 years ago

듣고있는 수업의 기말 발표 주제가 Applying TOC in S/W Development 라서 무척 반가운 내용이네요. 제가 읽고 정리하고 있는 책은 Agile Management for S/W engineering 이라는 책인데, 이 책도 나름대로 괜찮은 것 같습니다. 너무 많은 내용을 우겨넣으려는 경향이 보이긴 하지만요.

최재훈
17 years ago

답글 보고 kingori님에 대해 정보 수집을 해 봤습니다. 스토킹은 아니고 단순히 블로그 들어가서 어떤 분야에 종사하시나 알아본 수준입니다. 같은 학교 대학원에 계시네요. 저도 가을학기에 학부생으로 복학합니다. 복학하면 오프라인에서 뵐 수도 있겠습니다. ^_^

어떤 과목을 수강하시는지 몰라도 기말 발표 주제만 봐선 저도 그 수업을 듣고 싶어집니다. 엘리 골드렛이 쓴 4권 중 처음 세 권을 읽었는데, The GoalIt’s Not Luck은 생산공정에 TOC를 적용한 책입니다. “TOC를 프로젝트에 적용할 수 있을 것 같은데…”라고 생각했었는데, 한계를 넘어서에 와서 드디어 궁금증이 해결됐습니다.

요약 2편을 쓰고 난 뒤 추천 도서를 쓰려고 했는데, Agile Management for S/W engineering 이야기가 나왔으니 미리 한 권 추천해 드릴께요. 피플웨어의 저자들이 쓴 소프트웨어 프로젝트에서의 리스크 관리를 읽어보셨나요? 불확실성에 적극적으로 대비해야 한다는 것이 주제라고 할 수 있는데, 한계를 넘어서와 유사한 부분이 많습니다. 두 권을 함께 놓고 보면 도움이 될 것 같습니다.

kingori
17 years ago

네, 그 책도 이미 가지고는 있는데 저는 잘 진도가 안나가더라고요. 중간 이후로 답보상태입니다. 그 책에서 이야기하는 “확률로서 프로젝트 일정을 조율하라”와 같은 부분에 대해서는 많이 공감을 하게 되더군요. 얼렁 마저 읽어봐야겠습니다.
@저는 CS는 아니고 SEP라는 과정입니다. “소프트웨어전문가과정”이죠. 수업 내용들이 CS와 같은 학문적 접근보다는 실무와 관련된 부분이 많아서 저는 더 좋은것 같습니다. 나중에 청강할 기회가 되신다면 몇몇과목은 추천해드리고 싶네요. ^^;

짱똘
17 years ago

재훈님과 재호님 블로그를 알게되면서 책 읽는 재미가 쏠쏠하네요.
요즘 이런저런 일로 마음이 심란한데 산에 들어가 한달쯤 있다 내려왔으면 좋으련만…

최재훈
17 years ago

re kingori14: 사실 저도 SEP 과정에 관심은 있습니다. 입학 요건을 갖추려면 몇 년이나 기다려야 하겠지만, 꼭 필요한 교육이라고 생각하거든요. 개인적인 생각엔 화학과와 화공과처럼 전산과도 CS와 SE로 나눠야 하지 않나 생각합니다.

re 짱돌: 그렇게 재미있는 이야기도 없는데요. 하하. 어떤 일이 짱돌님을 괴롭히는지 모르겠지만, 하루 빨리 즐거운 삶으로 돌아가시길 빕니다.

trackback

[…] 개발의 적용은 한마디로 표현하자면, 감동이다. 제약조건이론을 다룬 한계를 넘어서 이후로 통찰력이 가장 빛나는 책이었다. 이런 책은 내가 번역해야 […]