Seguimiento de lo que importa: KPI y paneles de control

En nuestro capítulo anterior, Diseño para la Testabilidad: Rompiendo la Siguiente Barrera, exploramos cómo la testabilidad se convirtió en un enfoque clave después de resolver los cuellos de botella iniciales en la configuración del equipo y las pruebas manuales. Ese capítulo marcó un punto de inflexión en nuestra transformación DevOps, ya que cambiamos la atención a principios de diseño de software más profundos que permitieron pruebas más fluidas y rápidas.

Ahora, en el Capítulo 4, pasamos a una siguiente fase crítica: definiendo y haciendo seguimiento de los KPI correctos y configurando paneles de control para medir nuestro progreso. Con prácticas fundamentales ya establecidas y una mejora en la capacidad de prueba, necesitábamos formas objetivas y basadas en datos para visualizar el flujo, identificar las limitaciones y mejorar continuamente.

¿Por qué los KPI y los cuadros de mando son importantes en DevOps?

A medida que avanzamos en nuestro camino para optimizar la entrega End-to-End, reconocimos la necesidad de un mecanismo visual y objetivo para seguir el trabajo y descubrir cuellos de botella. Esto significó definir KPI que no solo se trataran de números, sino de resaltar conocimientos prácticos e impulsar los comportamientos correctos.

Al establecer KPIs, es esencial reconocer que los equipos y las organizaciones tienden a optimizar las métricas que supervisan. Esto se alinea con la Ley de Goodhart, que establece:

Cuando una medida se convierte en un objetivo, deja de ser una buena medida.

Este principio subraya la importancia de seleccionar KPIs que guíen a los equipos hacia los resultados correctos en lugar de animarlos a simplemente alcanzar objetivos. El propósito de estos KPIs es medir el progreso hacia nuestro objetivo general. Pero, ¿cuál es exactamente ese objetivo?

Definición del objetivo

Como se discute en La Meta de Eliyahu M. Goldratt, el objetivo de un negocio es aumentar el beneficio neto mientras se mejora simultáneamente el ROI y el flujo de caja. Trasladando esto a nuestro contexto de desarrollo de software, donde actualmente nos encontramos en la fase de inversión, identificamos el objetivo como:

 “Desarrollar y entregar un producto de software comercializable que genere ingresos sostenibles.”

Para lograr este objetivo se requiere cumplir varias condiciones necesarias, incluyendo:

• Tiempo de Comercialización → Entrega rápida de características y productos para aprovechar las oportunidades del mercado.
• Escalabilidad futura → Garantizar que el software esté diseñado para crecer con la demanda sin comprometer el rendimiento.
• Optimización de costos → Equilibrar los gastos de desarrollo mientras se maximiza la entrega de valor.
• Retorno de la Inversión (ROI) → Asegurar que el producto genere beneficios financieros a largo plazo que justifiquen la inversión.

Estas condiciones guiaron cómo definimos nuestros KPIs, centrándonos no solo en la velocidad y eficiencia, sino también en la creación de un producto escalable y rentable que ofrezca valor comercial a largo plazo.

Visualizando el flujo: Configuración de paneles de control

Según se describe en Accelerate de Nicole Forsgren, Jez Humble y Gene Kim, nuestro objetivo era configurar un panel de control que pudiera visualizar y hacer un seguimiento de las cuatro métricas clave de DevOps:

• Frecuencia de despliegue → Con qué frecuencia los equipos despliegan código en producción.
• Tiempo de entrega para cambios → Cuán rápido el código pasa de la confirmación a la producción.
• Tasa de fallos de cambio → El porcentaje de implementaciones que causan fallos.
• Tiempo medio de recuperación (MTTR) → La rapidez con la que los equipos se recuperan de los fallos.

Sin embargo, generar estas métricas de una manera significativa fue inicialmente un desafío debido a la falta de un seguimiento sistemático del trabajo entre los equipos. Aquí es donde la adopción de Azure DevOps como una única solución común de gestión del trabajo para todos los equipos marcó una diferencia significativa.

Empezamos configurando paneles de control específicos para cada equipo para hacer un seguimiento de:

• Todos los elementos de trabajo asignados por equipo.
• Trabajo actualmente en curso.
• Trabajo completado.
• Defectos categorizados por etapa y prioridad.

Primer desafío: Uso inconsistente

Incluso con directrices claras, los equipos utilizaban los estados y las categorías de defectos de manera diferente. Esta inconsistencia hizo que el análisis del flujo entre equipos fuera casi imposible.

El primer desafío que encontramos fue el uso inconsistente de los estados de los elementos de trabajo y las clasificaciones de defectos, a pesar de contar con directrices claras. Diferentes equipos utilizaban los estados de manera distinta, lo que dificultaba la identificación de problemas de flujo entre equipos. Lograr la coherencia en el seguimiento del trabajo se volvió fundamental, asegurando que los paneles de control pudieran utilizarse no solo para equipos individuales, sino para la optimización del flujo en toda la organización.

Luego nos centramos en definir correctamente los elementos de trabajo, asegurando que pudieran reflejar con precisión dónde se encuentra el trabajo en la cadena de valor, sin dejar de ser lo suficientemente genéricos como para ser utilizados por varios equipos. La mayoría de las herramientas ofrecen categorías de estado predeterminadas, pero estas no siempre eran suficientes. Era importante definir categorías de estado que se alinearan con nuestra estructura de equipo, la forma en que fluía el trabajo y nuestros cuellos de botella conocidos.

Análisis del flujo de trabajo para identificar cuellos de botella

Los primeros paneles de control se configuraron principalmente para visualizar el trabajo en curso, con el fin de obtener una imagen clara de lo que estaba sucediendo en todos los equipos. Esto incluía historias de características, historias de usuarios, defectos y planes de prueba. Estos proporcionaron una instantánea del trabajo en curso, pero aún no ofrecían una imagen clara del flujo general de trabajo y valor.

Tener visibilidad del trabajo en curso fue un primer paso importante, pero el siguiente desafío fue conectar esta visibilidad con métricas basadas en el flujo que pudieran resaltar dónde se atascaba el trabajo y dónde necesitábamos mejorar.

Utilizando el estado de los elementos de trabajo, creamos métricas para mostrar su número en cada fase. Inicialmente, solo disponíamos de información sobre la cantidad de elementos de trabajo en diferentes estados. Un análisis más avanzado, como el seguimiento del tiempo que los elementos de trabajo permanecían en cada fase, requirió herramientas adicionales que introdujimos posteriormente. No obstante, en esta etapa inicial, comenzamos nuestro análisis basándonos únicamente en los recuentos.

Incluso con estos datos básicos, los paneles de control resultaron valiosos para identificar cuellos de botella clave:

• Demasiados elementos de trabajo en curso en comparación con el número de elementos completados en un período determinado.
• Una creciente acumulación de nuevos elementos de trabajo que superaba con creces lo que podíamos completar de forma realista en los próximos 3 a 6 meses.
• Equipos con la mayor acumulación de elementos de trabajo sin terminar, lo que indica dónde se necesitaba un enfoque y apoyo adicionales.

Cada una de estas ideas requería una solución diferente, pero la capacidad de visualizar el flujo de trabajo fue un gran avance. Esta mejora llevó el aspecto de Herramientas de nuestro Triángulo DevOps más allá, impulsando el progreso en los otros dos aspectos: Arquitectura y Personas.

Uso de KPIs para impulsar la mejora continua

Retomamos el tema de los KPIs en varias etapas a lo largo de nuestra transformación DevOps. A medida que nuestras capacidades de seguimiento mejoraron, pudimos generar métricas más detalladas que nos ayudaron a:

• Medir el progreso a lo largo del tiempo para asegurar que avanzábamos hacia nuestro objetivo de desarrollar un producto de software comercializable.
• Identificar las dependencias y los traspasos que causaban retrasos en el flujo de trabajo.
• Identificar las áreas donde los equipos necesitaban apoyo adicional o mejoras en los procesos.
• Alinear nuestros KPIs más estrechamente con las cuatro métricas clave de DevOps de Accelerate, proporcionando una medida objetiva de nuestro éxito.

Al alinear Herramientas, Arquitectura y Personas con los KPI correctos, creamos un sistema que proporcionó una visibilidad clara de nuestro progreso, nos ayudó a identificar y eliminar cuellos de botella, y aseguró que nos mantuviéramos enfocados en aportar valor empresarial a largo plazo.

¿Qué sigue? Ramificación y despliegue continuo

Con nuestros KPI y paneles de control implementados, ahora estamos listos para optimizar el flujo de código a través de los entornos y hasta la producción. En el Capítulo 5, profundizaremos en cómo abordamos la ramificación y el despliegue continuo, y los cambios culturales y técnicos que nos permitieron desplegar de forma más rápida y segura.

¡Manténgase atento!