TL; DR : Ce n'est pas la bonne chose à mesurer. En mesurant et en augmentant l'utilisation de l'ensemble des employés, vous créez des problèmes dans le système et réduisez le débit global .
Comptabilité de débit
Ce que vous voulez réellement mesurer, c'est le débit, l'inventaire et les dépenses d'exploitation tous ensemble et essayez de réduire l'inventaire et les dépenses d'exploitation tout en maximisant le débit. Cette méthode est connue sous le nom de comptabilité de débit .
Dans le développement de logiciels, l'inventaire est le travail en cours qui n'apporte pas encore d'avantages au client. Tout ce qui a été fait, mais pas publié. Le débit est la quantité de travail utile au client qui est libérée. Tout travail effectué qui n'est pas directement utile au client est comptabilisé en charges d'exploitation.
Système simple
Dans un système simple avec un seul humain ou plusieurs humains travaillant indépendamment avec un équipement indépendant, chacun augmentera directement le débit de l'ensemble du système . Cela conduit à l' idée fausse commune qui est à la base de cette question selon laquelle l'augmentation de l'utilisation humaine entraînera une augmentation du débit dans tous les systèmes. Mais vous mesurez toujours le débit du système, les stocks et les dépenses d' exploitation .
Système complexe
Dans un système complexe, même avec seulement deux dépendances, une utilisation accrue d'une partie du système peut directement entraîner une diminution de l'utilisation dans le goulot d'étranglement, ce qui diminue le débit de l'ensemble du système. Toute augmentation de la productivité en dehors du goulot d'étranglement est un mirage .
Exemple:L'équipe d'ingénieurs logiciels a fait réviser tout le code par l'architecte logiciel, qui prévoit également de nouvelles fonctionnalités. Cette personne est un goulot d'étranglement, le code non examiné par l'architecte augmentera simplement l'inventaire, si l'architecte n'a pas le temps, aucune nouvelle fonctionnalité ne sera correctement planifiée. Si vous commencez à mesurer l'utilisation des ingénieurs logiciels, ils essaieront chacun d'apporter plus de changements, plutôt que de meilleurs changements. Le temps que l'architecte devra consacrer à chaque modification augmentera et le temps total passé en revue augmentera encore par l'augmentation du nombre de modifications à un point où il ne restera plus de temps pour planifier de nouvelles modifications. Finalement, tout le système s'arrête. Si d'un autre côté, ils diminuent l'utilisation, passent même du temps à tourner au ralenti, ils passent plus de temps à chaque changement ou examen par les pairs cela pourrait entraîner une diminution du temps requis pour les révisions et éventuellement une augmentation du débit. Il s'agit d'une seule équipe avec 2 dépendances. Les ingénieurs dépendent de l'architecte pour que de nouveaux changements soient planifiés et pour que les changements soient examinés.
Il est clair que les avantages doivent être obtenus en gérant correctement le goulot d'étranglement et en essayant de gagner en productivité au niveau du goulot d'étranglement , où l' heure gagnée est l'heure de débit de l'ensemble du système .
C'est le vrai message du projet Phoenix et vient directement de la théorie des contraintes par Eliyahu M. Goldratt. Vous pouvez également lire un article sur la pensée d'utilisation contre la pensée de débit . Je suggère également d'en savoir plus sur la gestion des processus de la chaîne critique .
N'oubliez pas: ce que vous mesurez, c'est ce que vous obtenez . Et vous ne voulez certainement pas obtenir une utilisation individuelle accrue. Une route vers l'enfer est pavée de bonnes intentions.