Après qu'Ivan ait
rencontré l'analyse de cohorte , il détestait tout type de mesures sucrées.
Mais l'ironie, c'est que les dirigeants ne savaient rien d'autre et catégoriquement ne voulaient pas savoir. J'ai dû me dépasser et aller bêtement à la rencontre des «demandes» du patron, pour ne pas me faire une réputation de mauvaise personne qui a désobéi aux instructions des sages.
Parfois, même des résultats intéressants ont été obtenus à partir de cela. Un tel cas sera maintenant discuté.
Une fois, le manager a demandé à Ivan de savoir pourquoi la conversion du passage du stand par les équipes ne cesse de baisser depuis 3 semaines:
Je dois dire qu'il y avait beaucoup, des dizaines d'équipes dans le département d'Ivan, chaque jour ils faisaient des centaines d'assemblages de leurs distributions et les vérifiaient sur les stands.
La conversion a pris en compte le rapport entre le nombre de builds créés par les équipes en une semaine et le nombre d'assemblages qui ont passé le stand cible.
L'une des principales lacunes des indicateurs sucrés est qu'il est impossible de déterminer quoi que ce soit à partir d'eux. La conversion utilisée par le chef d'Ivan s'est avérée être une métrique sucrée typique. La conversion était en baisse, mais on ne savait pas pourquoi.
Naturellement, toutes les équipes ont été mises sur leurs oreilles avec pour objectif d'améliorer à tout prix les performances des stands. Pour ce faire, une autre métrique sucrée avec une liste de "méchants" a été compilée très rapidement:
Sous chaque colonne de l'image, les noms des équipes sont écrits en réalité.
Les équipes ont hurlé et ont commencé à lutter pour rompre avec le nouveau malheur qui leur est tombé dessus.
Fatigué de courir après les équipes, le leader a exhorté Ivan à trier les raisons de la baisse de conversion.
Et donc, qu'est-ce qui en est sorti ...
Comprendre l'essence des métriques
Les paramètres doivent être compris. Comprenez au moins comment ils sont considérés. Ensuite, vous pouvez creuser plus profondément et le découvrir. Ivan a donc fait:
Conversion = Builds créés / d'entre eux ont passé le standComprenant la formule, Ivan a d'abord affiché deux composants de la conversion sur le graphique:
Il est immédiatement devenu évident que le nombre d'assemblages en cours de création ne changeait pratiquement pas, mais en même temps le nombre d'assemblages qui passaient sur le stand diminuait, et il a commencé à diminuer au moment même où la conversion commençait à diminuer.
La conversion a changé du fait que la différence entre le nombre d'assemblages créés et le nombre de peuplements passés a augmenté, et depuis la conversion est le résultat de la division de l'un par l'autre, puis avec l'augmentation de la différence, la valeur de conversion change également de façon synchrone (diminue).
La différence entre les valeurs sur le graphique est une ligne sombre.
C'est-à-dire l'augmentation de la différence entre les colonnes rouge et bleue du graphique indique une diminution automatique de la conversion.
Réfléchissez aux résultats
Ivan a compris que les résultats n'étaient toujours pas suffisants pour déterminer la cause.
L'expérience précédente en métrique lui a donné une idée importante: vous devez creuser à la racine, à la véritable cause racine de tout problème.
La raison de tout changement de conversion DevOps est en fait ... les gens. Développeurs et devopsers d'équipes, c'est finalement Ivan qui a voulu les atteindre.
Regardant la différence grandissante entre les assemblées en cours de création et le passage du stand, il se demande: pourquoi cela se passe-t-il et qui est le «générateur» d'assemblages qui n'ont pas atteint le stand?
Le livre lu "Toyota Tao" a donné un indice: il faut se pencher sur le "stock restant" ou le "travail en cours".
Parce que les assemblées étant passées par plusieurs stands et pouvant y rester, Ivan a décidé de compter non seulement les assemblées d'un stand, mais de voir le véritable `` véritable équilibre '', c'est-à-dire pour compter le nombre d'assemblages qui n'ont pas du tout été utilisés par un stand et laissés pour poids mort:
La ligne sombre indique le nombre de résidus, jaune - le nombre d'assemblages qui ont franchi le peuplement cible, pris en compte dans le calendrier de conversion initial.
Je n'avais même pas à deviner. Le mouvement synchrone évident des deux lignes a également été confirmé par le calcul de la corrélation:
Il s'est avéré que plus il restait de résidus d'assemblage, moins la conversion souhaitée était importante.
Trouvez la cause profonde
Il n'a pas été difficile de déterminer qui crée les restes à l'aide du tableau le plus simple:
Dans la colonne de gauche se trouve le nom de l'équipe. Colonne surlignée - le nombre de résidus créés par cette équipe en une semaine.
Les leaders du TOP 2 ont immédiatement rampé et Ivan a immédiatement couru pour les gérer.
La raison, bien sûr, s'est avérée être banale: les équipes ont simplement commencé un nouveau cycle de développement et, en créant des fonctionnalités, ont commencé à construire pour vérifier son exactitude.
Le principal inconvénient des mesures sucrées
En fait, le changement de conversion s'est avéré être étroitement lié au processus de développement cyclique et n'était ni fatal ni mauvais.
Sur le tableau de conversion, trois vagues de développement (cycles) sont visibles.
Il s'agit d'un processus naturel qui devrait suivre cette voie.
Et les équipes jurant avec le leader avaient absolument raison: avec le processus de développement actuel utilisé par l'entreprise, une augmentation de la conversion serait non seulement une action «incompréhensible», mais pourrait complètement détruire le processus et entraîner des retards importants dans la fourniture de logiciels.
C'est le principal inconvénient des paramètres sucrés - ils transforment les aspects positifs en aspects négatifs, et au lieu de clarifier la situation, ils ne font que la confondre et l'aggraver.
Conclusions
En général, l'expérience était intéressante pour Ivan, donc il a même préparé avec plaisir un exposé pour la direction, dans lequel il expliquait que la métrique utilisée n'était pas appropriée pour gérer le département, qu'elle était trompeuse et pouvait causer de gros problèmes.
C’est tout.
Si l'expérience d'Ivan vous a semblé intéressante, il vous sera très reconnaissant de vos commentaires.
Soit dit en passant, Ivan veut maintenant mettre lui-même et ses connaissances dans un projet inspirant et incendiaire, alors il accepte des offres intéressantes dans PM.