TL; DR : è la cosa sbagliata da misurare. Misurando e aumentando l'utilizzo nei dipendenti su tutta la linea, si creano problemi nel sistema e si riduce la produttività complessiva .
Throughput Accounting
Ciò che si desidera effettivamente misurare è la produttività, l'inventario e le spese operative tutti insieme e cercare di ridurre l'inventario e ridurre le spese operative massimizzando al contempo la produttività. Questo metodo è noto come contabilità del throughput .
Nello sviluppo del software, l'inventario è il lavoro in corso che non sta ancora portando benefici al cliente. Tutto ciò che è stato fatto, ma non rilasciato. La velocità effettiva è la quantità di lavoro utile per il cliente che viene rilasciato. Qualsiasi lavoro svolto non direttamente utile per il cliente viene contabilizzato come spesa operativa.
Sistema semplice
In un sistema semplice con singoli umani o più umani che lavorano in modo indipendente con apparecchiature indipendenti tanto quanto ognuna aumenta direttamente il rendimento dell'intero sistema . Ciò porta al malinteso comune che è alla base di questa domanda che l'aumento dell'utilizzo umano porterà ad un aumento della produttività in tutti i sistemi. Ma si misura ancora il throughput del sistema, l' inventario e le spese operative .
Sistema complesso
In un sistema complesso, anche con un minimo di due dipendenze, un maggiore utilizzo di una parte del sistema può portare direttamente a una riduzione dell'utilizzo nel collo di bottiglia, che riduce il rendimento dell'intero sistema. Qualsiasi aumento della produttività al di fuori del collo di bottiglia è un miraggio .
Esempio:Il team di ingegneri del software ha esaminato tutto il codice dall'architetto software, che pianifica anche nuove funzionalità. Questa persona è un collo di bottiglia, il codice non rivisto dall'architetto aumenterà semplicemente l'inventario, se l'architetto non ha tempo, nessuna nuova funzionalità verrà pianificata correttamente. Se inizi a misurare l'utilizzo degli ingegneri del software, ognuno proverà a apportare più modifiche, anziché modifiche migliori. Il tempo che l'architetto dovrà dedicare a ciascuna modifica aumenterà e il tempo totale impiegato per la revisione aumenterà ulteriormente con l'aumentare della quantità di modifiche fino al punto in cui non rimarrebbe tempo per pianificare nuove modifiche. Alla fine l'intero sistema si ferma. Se, d'altro canto, riducono l'utilizzo, trascorrono addirittura il tempo al minimo, trascorrono più tempo su ogni modifica o peer review, ciò potrebbe comportare una riduzione del tempo richiesto per le revisioni e infine un aumento della produttività. Questo è solo un team con 2 dipendenze. Gli ingegneri dipendono dall'architetto per la pianificazione delle nuove modifiche e la revisione delle modifiche.
Chiaramente i vantaggi devono essere ottenuti nella corretta gestione del collo di bottiglia e nel tentativo di aumentare la produttività nel collo di bottiglia , dove l' ora guadagnata è l'ora della produttività dell'intero sistema .
Questo è il vero messaggio di The Phoenix Project e proviene direttamente dalla teoria dei vincoli di Eliyahu M. Goldratt. È inoltre possibile leggere un articolo sul pensiero di utilizzo e il pensiero di throughput . Vorrei anche suggerire di leggere di più su Critical Chain Process Management .
Ricorda: ciò che misuri è ciò che ottieni . E sicuramente NON VUOI ottenere un maggiore utilizzo individuale. Una strada per l'inferno è lastricata di buone intenzioni.