Wie Ivan die Standumwandlung untersuchte

Nachdem Ivan die Kohortenanalyse kennengelernt hatte , hasste er jede Art von zuckerhaltigen Metriken.

Aber die Ironie war, dass die Führung nichts anderes wusste und kategorisch nichts wissen wollte. Ich musste über mich selbst treten und dumm gehen, um den „Bitten“ des Chefs nachzukommen, um nicht den Ruf eines schlechten Menschen zu erlangen, der den Anweisungen der Weisen nicht gehorchte.
Manchmal wurden daraus sogar interessante Ergebnisse erzielt. Ein solcher Fall wird nun diskutiert.

Einmal bat der Manager Ivan, herauszufinden, warum die Umstellung des Passierens des Standes durch die Teams seit 3 ​​Wochen kontinuierlich zurückgegangen ist:



Ich muss sagen, dass es in der Abteilung von Ivan viele, Dutzende von Teams gab, die jeden Tag Hunderte von Versammlungen ihrer Verteilungen machten und sie an den Ständen überprüften.
Bei der Konvertierung wurde das Verhältnis der Anzahl der von Teams in einer Woche erstellten Builds zur Anzahl der Assemblys berücksichtigt, die den Zielstand überschritten haben.

Einer der Hauptmängel von zuckerhaltigen Metriken ist, dass es unmöglich ist, etwas daraus zu bestimmen. Die vom Kopf von Ivan verwendete Umrechnung erwies sich als typische zuckerhaltige Metrik. Die Umstellung ging zurück, aber es war völlig unklar, warum.

Natürlich wurden alle Teams auf die Ohren gelegt, um die Leistung der Stände um jeden Preis zu verbessern. Zu diesem Zweck wurde sehr schnell eine weitere zuckerhaltige Metrik mit einer Liste von "bösen Jungs" erstellt:



Unter jeder Spalte im Bild sind die Namen der Teams in der Realität geschrieben.
Die Teams heulten und bemühten sich, sich von dem neuen Unglück zu lösen, das auf sie fiel.
Der Anführer war es leid, Teams zu jagen, und forderte Ivan auf, die Gründe für den Rückgang der Konversion zu klären.
Und was kam daraus ...

Verstehen Sie die Essenz von Metriken

Metriken müssen verstanden werden. Verstehe zumindest, wie sie berücksichtigt werden. Dann können Sie tiefer graben und es herausfinden. Also tat Ivan:

Conversion = Builds erstellt / von ihnen hat den Stand bestanden

Ivan verstand die Formel und zeigte zunächst zwei Komponenten der Konvertierung in der Tabelle an:



Es wurde sofort klar, dass sich die Anzahl der erstellten Builds praktisch nicht änderte, aber gleichzeitig die Anzahl der Baugruppen, die den Stand passierten, abnahm und in dem Moment abnahm, in dem die Konvertierung abnahm.

Die Konvertierung hat sich aufgrund der Tatsache geändert, dass der Unterschied zwischen der Anzahl der erstellten Baugruppen und der Anzahl der vergangenen Stände zugenommen hat und seitdem Die Umwandlung ist das Ergebnis der Division untereinander. Mit zunehmender Differenz ändert sich auch der Umrechnungswert synchron (nimmt ab).

Der Unterschied zwischen den Werten in der Grafik ist eine dunkle Linie.

Das heißt, Die Zunahme der Differenz zwischen den roten und blauen Spalten in der Grafik zeigte eine automatische Abnahme der Conversion an.

Denken Sie über die Ergebnisse nach

Ivan verstand, dass die Ergebnisse immer noch nicht ausreichten, um die Ursache zu bestimmen.
Die bisherigen Erfahrungen mit Metriken gaben ihm eine wichtige Idee: Sie müssen zur Wurzel graben, zur wahren Grundursache eines Problems.

Der Grund für Änderungen an der DevOps-Konvertierung sind tatsächlich ... Personen. Entwickler und Entwickler von Teams. Es war Ivan, der am Ende zu ihnen wollte.

Als er den wachsenden Unterschied zwischen den Baugruppen, die erstellt wurden, und dem Passieren des Standes betrachtete, fragte er sich: Warum geschieht dies und wer ist der „Generator“ von Baugruppen, die den Stand nicht erreicht haben?

Das gelesene Buch „Toyota Tao“ gab einen Hinweis: Es ist notwendig, sich „Restbestände“ oder „in Arbeit“ anzusehen.

Weil Die Versammlungen gingen durch mehrere Stände und konnten dort bleiben. Ivan beschloss, nicht nur die Versammlungen eines Standes zu zählen, sondern auch das wahre „echte Gleichgewicht“ zu sehen, d. h. um zu zählen, wie viele Baugruppen von keinem Stand verwendet wurden und wie viel Eigengewicht liegen gelassen wurden:



Die dunkle Linie zeigt die Anzahl der Rückstände, gelb - die Anzahl der Baugruppen, die den Zielstand passiert haben, berücksichtigt im anfänglichen Konvertierungsplan.

Ich musste nicht einmal raten. Die offensichtliche synchrone Bewegung der beiden Linien wurde auch durch Berechnung der Korrelation bestätigt:



Es stellte sich heraus, dass die gewünschte Umwandlung umso geringer ist, je mehr Assemblierungsrückstände verbleiben.

Finden Sie die Grundursache

Es war nicht schwer zu bestimmen, wer die Reste anhand der einfachsten Tabelle erstellt:



In der linken Spalte steht der Name des Teams. Hervorgehobene Spalte - Die Anzahl der von diesem Team in einer Woche erstellten Rückstände.

Die Anführer der TOP-2 krochen sofort heraus und Ivan rannte sofort los, um sich um sie zu kümmern.
Der Grund erwies sich natürlich als banal: Die Teams starteten einfach einen neuen Entwicklungszyklus und begannen, Funktionen zu erstellen, um deren Richtigkeit zu überprüfen.

Der Hauptnachteil von zuckerhaltigen Metriken

Tatsächlich war die Änderung der Umwandlung eng mit dem zyklischen Entwicklungsprozess verbunden und nicht tödlich oder schlecht.



In der Umrechnungstabelle sind drei Entwicklungswellen (Zyklen) sichtbar.
Dies ist ein natürlicher Prozess, der diesen Weg gehen sollte.

Und die Teams, die mit dem Marktführer schworen, hatten absolut Recht: Mit dem aktuellen Entwicklungsprozess des Unternehmens wäre eine Erhöhung der Conversion nicht nur eine „unverständliche“ Maßnahme, sondern könnte den Prozess vollständig zerstören und zu erheblichen Verzögerungen bei der Bereitstellung von Software führen.

Dies ist der Hauptnachteil von zuckerhaltigen Metriken - sie verwandeln positive Aspekte in negative und anstatt die Situation zu klären, verwirren und verschlechtern sie sie nur.

Schlussfolgerungen

Im Allgemeinen war die Erfahrung für Ivan interessant, so dass er selbst mit einiger Freude eine Präsentation für die Führung vorbereitete, in der er erklärte, dass die verwendete Metrik nicht für die Verwaltung der Abteilung geeignet sei, irreführend sei und große Probleme verursachen könne.

Das ist alles

Wenn Ivan's Erfahrung für Sie interessant erschien, wird er für Ihr Feedback sehr dankbar sein.
Übrigens möchte Ivan sich und sein Wissen jetzt in ein inspirierendes und brandaktuelles Projekt einbringen, damit er interessante Angebote in PM annimmt.