Cómo Ivan investigó la conversión de stands

Después de que Ivan conoció el análisis de cohortes , odiaba cualquier tipo de métrica azucarada.

Pero la ironía era que el liderazgo no sabía nada más, y categóricamente no quería saber. Tuve que pasar por encima de mí y estúpidamente ir a cumplir con las "solicitudes" del jefe, para no ganarme la reputación de ser una mala persona que desobedecía las instrucciones de los sabios.
A veces incluso se obtuvieron resultados interesantes de esto. Uno de estos casos será discutido ahora.

Una vez, el gerente le pidió a Ivan que descubriera por qué la conversión de pasar el stand por los equipos ha estado disminuyendo continuamente durante 3 semanas:



Debo decir que había muchos equipos en el departamento de Ivan, varias docenas, todos los días hacían cientos de ensambles de sus distribuciones y los revisaban en las gradas.
La conversión consideró la relación entre el número de compilaciones creadas por los equipos en una semana y el número de ensamblajes que pasaron el stand objetivo.

Una de las principales deficiencias de las métricas azucaradas es que es imposible determinar nada a partir de ellas. La conversión utilizada por el jefe de Ivan resultó ser una métrica azucarada típica. La conversión estaba cayendo, pero no estaba completamente claro por qué.

Naturalmente, a todos los equipos se les puso las orejas con la orden de mejorar el rendimiento de las gradas a toda costa. Para hacer esto, se compiló muy rápidamente otra métrica azucarada con una lista de "tipos malos":



Debajo de cada columna de la imagen, los nombres de los equipos están escritos en realidad.
Los equipos aullaron y comenzaron a luchar para escapar de la nueva desgracia que les cayó.
Cansado de perseguir equipos, el líder instó a Ivan a resolver las razones de la caída en la conversión.
Y entonces, qué salió de eso ...

Comprender la esencia de las métricas.

Las métricas deben ser entendidas. Al menos entiendo cómo se consideran. Entonces puedes cavar más profundo y resolverlo. Entonces Ivan hizo:

Conversión = Construcciones creadas / De ellas pasaron el stand

Al comprender la fórmula, Ivan primero mostró dos componentes de la conversión en el gráfico:



Inmediatamente se hizo evidente que el número de compilaciones creadas prácticamente no cambió, pero al mismo tiempo el número de ensamblajes que pasaron por el stand disminuyó, y comenzó a disminuir en el mismo momento en que la conversión comenzó a disminuir.

La conversión ha cambiado debido al hecho de que la diferencia entre el número de conjuntos creados y el número de soportes anteriores ha aumentado, y desde la conversión es el resultado de dividir uno por otro, luego, con el aumento de la diferencia, el valor de conversión también cambia sincrónicamente (disminuye).

La diferencia entre los valores en el gráfico es una línea oscura.

Es decir El aumento en la diferencia entre las columnas roja y azul en el gráfico indica una disminución automática en la conversión.

Medita sobre los resultados

Ivan entendió que los hallazgos aún no eran suficientes para determinar la causa.
La experiencia previa en métricas le dio una idea importante: debe profundizar en la raíz, en la verdadera causa raíz de cualquier problema.

La razón de cualquier cambio de conversión de DevOps es en realidad ... personas. Desarrolladores y devotos de equipos. Fue Ivan quien quiso llegar a ellos al final.

Al observar la creciente diferencia entre las asambleas que se crean y pasar el stand, se preguntó: ¿por qué sucede esto y quién es el "generador" de las asambleas que no han llegado al stand?

El libro leído "Toyota Tao" dio una pista: es necesario mirar el "stock sobrante" o "trabajo en progreso".

Porque las asambleas pasaron por varios stands y pudieron quedarse allí, Ivan decidió contar no solo los montajes de un stand, sino también ver el verdadero "equilibrio real", es decir para contar cuántos ensambles no fueron utilizados en absoluto por ningún soporte y se dejaron para colocar peso muerto:



La línea oscura muestra el número de residuos, amarillo: el número de ensamblajes que han pasado el stand objetivo, tenidos en cuenta en el programa de conversión inicial.

Ni siquiera tuve que adivinar. El movimiento sincrónico obvio de las dos líneas también se confirmó calculando la correlación:



Resultó que cuanto más residuos de ensamblaje permanecen, menor es la conversión deseada.

Encuentra la causa raíz

No fue difícil determinar quién crea las sobras usando la tabla más simple:



En la columna izquierda está el nombre del equipo. Columna resaltada: la cantidad de residuos creados por este equipo en una semana.

Los líderes de TOP-2 salieron de inmediato e Ivan corrió inmediatamente para tratar con ellos.
La razón, por supuesto, resultó ser banal: los equipos simplemente comenzaron un nuevo ciclo de desarrollo y, creando funcionalidad, comenzaron a construir para verificar su corrección.

La principal desventaja de las métricas azucaradas

De hecho, el cambio en la conversión resultó estar estrechamente relacionado con el proceso de desarrollo cíclico y no fue fatal ni malo.



En la tabla de conversión, son visibles tres ondas de desarrollo (ciclos).
Este es un proceso natural que debería ir por ese camino.

Y los equipos que juraron con el líder tenían toda la razón: con el proceso de desarrollo actual utilizado por la compañía, aumentar la conversión no solo sería una acción "incomprensible", sino que podría destruir completamente el proceso y provocar demoras significativas en el suministro de software.

Este es el principal inconveniente de las métricas azucaradas: convierten los aspectos positivos en negativos y, en lugar de aclarar la situación, solo la confunden y empeoran.

Conclusiones

En general, la experiencia fue interesante para Ivan, por lo que incluso con cierto placer preparó una presentación para la gerencia, en la que explicó que la métrica utilizada no era adecuada para administrar el departamento, era engañosa y podía causar grandes problemas.

Eso es todo

Si la experiencia de Ivan le pareció interesante, él estará muy agradecido por sus comentarios.
Por cierto, Ivan ahora quiere ponerse a sí mismo y su conocimiento en un proyecto inspirador e incendiario, por lo que acepta ofertas interesantes en PM.