인간 활용도를 측정하는 방법?

에서 피닉스 프로젝트 가 높은 90 %로 사람의 워크로드 증가로 전체 책 쇼에서 하나의 그래프는 그들에 대기 시간이 기하 급수적으로 증가이야. 실제로이 책에서는 다음과 같이 주장합니다.

대기 시간 = (비지 백분율 / 비율)

따라서 리소스가 주당 40 시간 중 35 시간 동안 사용량이 많은 경우 :

Wait Time = 0.875/0.125  = 8

그러나 자원이 주당 40 시간 중 39 시간 동안 사용 중이면 다음을 수행하십시오.

Wait Time = 0.975/0.025  = 39

워크 플로의 대기 수를 곱한 것입니다. 분명히 우리가 지켜보고 싶은 것입니다!

따라서이 모든 것을 감안할 때 사람들의 이용률을 합리적인 수준으로 유지하는 것이 매우 중요합니다. 이 공식의 중요성에 대한이 책의 주장을 감안할 때이 값을 측정하는 방법에 대한 실질적인 조언은 거의 제공하지 않습니다. 제 질문은 바쁘신 분의 비율을 어떻게 실제로 측정 할 수 있습니까?

TL; DR : 측정 하는 것이 잘못 되었습니다. 전반적으로 직원의 활용도를 측정하고 늘리면 시스템에 문제가 발생 하고 전체 처리량이 줄어 듭니다 .

처리량 회계

실제로 측정하고자하는 것은 처리량, 재고 및 운영 비용을 모두 합한 것이며 동시에 재고량을 줄이고 운영 비용을 줄이면서 동시에 처리량을 최대화하려고합니다. 이 방법을 처리량 계산이라고 합니다.

소프트웨어 개발에서 인벤토리는 아직 고객에게 이익을 가져 오지 않는 진행중인 작업입니다. 완료되었지만 릴리스되지 않은 모든 것. 처리량은 릴리스중인 고객에게 유용한 작업량입니다. 고객에게 직접적으로 유용하지 않은 모든 작업은 운영 비용으로 회계 처리됩니다.

단식

A의 간단한 시스템 으로 하나의 사람 또는 여러 사람이 작업을 독립적으로 각자가 직접 증가 않는만큼 독립적 인 장비 처리량 전체의 시스템을 . 이로 인해 사람의 이용률이 증가하면 모든 시스템에서 처리량이 증가 할 것이라는이 질문의 기초가 되는 일반적인 오해 가 발생 합니다. 그러나 여전히 시스템 처리량 , 재고 및 운영 비용을 측정합니다 .

복잡한 시스템

복잡한 시스템에서는 최소한 두 개의 종속성이 있더라도 시스템의 한 부분의 사용률이 증가하여 병목 현상의 사용률이 직접 감소하여 전체 시스템의 처리량이 줄어 듭니다. 병목 현상을 벗어난 생산성 증가는 신기루 입니다.

예:소프트웨어 엔지니어 팀은 소프트웨어 아키텍트가 모든 코드를 검토하고 새로운 기능을 계획하고 있습니다. 이 사람은 병목 현상이며, 건축가가 검토하지 않은 코드는 단순히 인벤토리를 늘리고, 건축가가 시간이 없으면 새로운 기능이 제대로 계획되지 않습니다. 소프트웨어 엔지니어의 활용도를 측정하기 시작하면 각 엔지니어는 더 나은 변경보다는 더 많은 변경을 시도합니다. 설계자가 각 변경에 소비해야하는 시간이 증가하고 새로운 변경을 계획 할 시간이없는 시점까지 변경 횟수가 늘어남에 따라 검토에 소요되는 총 시간이 더 늘어납니다. 결국 전체 시스템이 정지합니다. 반면에 활용도를 낮추고 유휴 시간을 소비하더라도 각 변경 또는 동료 검토에 더 많은 시간을 소비합니다. 이로 인해 검토에 필요한 시간이 줄어들고 처리량이 증가 할 수 있습니다. 이것은 2 개의 의존성을 가진 단일 팀입니다. 엔지니어는 새로운 변경 사항을 계획하고 변경 사항을 검토하기 위해 설계자에게 의존합니다.

분명 장점이 제대로 병목 현상을 관리하고 얻으려고에서 얻은되어야하는 병목에서 생산성 , 시간이되었습니다 의 시간입니다 전체 시스템의 처리량은 .

이것은 Phoenix 프로젝트 의 실제 메시지이며 Eliyahu M. Goldratt 의 제약 이론 에서 직접 제공됩니다 . 사용률 사고와 처리량 사고 에 관한 기사를 읽을 수도 있습니다 . 또한 Critical Chain Process Management 에 대한 자세한 내용을 읽어보십시오 .

기억하십시오 : 측정하는 것은 얻는 것 입니다. 그리고 개인 이용률을 높이고 싶지 는 않습니다 . 지옥으로가는 길은 좋은 의도로 포장되어 있습니다.