Comment mesurer l'utilisation humaine?

15

Dans The Phoenix Project, le graphique unique dans tout le livre montre que lorsque la charge de travail d'une personne augmente dans les 90%, le temps d'attente augmente de façon exponentielle. En fait, dans le livre, il affirme que:

Temps d'attente = (pourcentage occupé / pourcentage libre)

Donc, si une ressource est occupée pendant 35 heures sur 40 par semaine, alors:

Wait Time = 0.875/0.125  = 8

Cependant, si une ressource est occupée pendant 39 heures sur 40 par semaine, alors:

Wait Time = 0.975/0.025  = 39

Ceci est multiplié par le nombre d'attentes dans le workflow. C'est évidemment quelque chose que nous voulons surveiller!

Donc, étant donné tout cela, il est évidemment vital que nous maintenions l'utilisation des gens à un niveau raisonnable. Étant donné l'insistance du livre sur l'importance de cette formule, il offre peu de conseils pratiques sur la façon de mesurer ces valeurs. Ma question est, comment pouvez-vous pratiquement mesurer le pourcentage d'une personne occupée?

Liath
la source
2
Cela mérite une réponse qui cite le livre Slack amazon.com/dp/0767907698 . Le mythe de l'efficacité en brûlant les ressources à 100% est également le sujet principal de la théorie des contraintes.
Evgeny
2
Avant d'avoir le temps d'écrire une réponse complète, j'ajouterai simplement que dans ToC, vous abandonnez les efficiences partout, pour vous concentrer sur l'efficacité uniquement sur la contrainte. Parce que cela permet partout ailleurs d'absorber la variété et d'éviter de créer du gaspillage (citez Lean ici.
Evgeny
2
La contrainte est rarement un être humain, même dans The Phoenix Project, Bret a d'abord été une contrainte - mais son «son travail» qui est la véritable contrainte.
Evgeny
1
@Evgeny attend avec impatience la réponse complète!
Liath
2
Une réponse ici devrait également utiliser "Vous ne pouvez pas mesurer la productivité" de Martin Fowler - martinfowler.com/bliki/CannotMeasureProductivity.html
David Bock

Réponses:

6

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.

Jiri Klouda
la source