El playbook de GitHub para el éxito de los sistemas de ingeniería

• Para lograr el éxito en ingeniería, es importante equilibrar tres áreas: calidad (Quality), velocidad (Velocity) y satisfacción de los desarrolladores (Happiness)
• ESSP (Engineering System Success Playbook) ofrece un framework de tres pasos para mejorar estos aspectos de forma integral y maximizar los resultados del negocio
• A través de 12 métricas clave diseñadas con base en varios frameworks como SPACE, DevEx, DX Core 4 y DORA, permite entender la situación actual de la organización, establecer prioridades según los objetivos de mejora e implementar y ajustar cambios de forma gradual
  • Estas 12 métricas están pensadas para seguir cada área de forma cuantitativa y pueden personalizarse según el contexto de cada organización
• Todas las mejoras se basan en la sostenibilidad a nivel de equipo y el pensamiento sistémico, y enfatizan un enfoque equilibrado que considera tanto indicadores adelantados como rezagados
• Se busca una transformación sostenible a largo plazo en lugar de mejoras rápidas
• ESSP puede comenzar a aplicarse incluso sin herramientas propias de medición, y un diagnóstico inicial mediante métodos cualitativos como encuestas también resulta útil
• GitHub destaca, con casos propios, que las mejoras centradas en la calidad terminan teniendo un efecto positivo también en la velocidad y la satisfacción de los desarrolladores

Métricas de éxito de ingeniería de GitHub

• Quality
  • Change failure rate: tasa de fallas por cambio
    → Proporción de cambios que causaron incidentes o problemas
    • Cálculo: (número de despliegues fallidos / número total de despliegues) × 100
    • Tip: acordar claramente dentro del equipo qué se considerará una falla (por ejemplo, rollback, alertas de monitoreo, etc.)
  • Failed deployment recovery time: tiempo de recuperación de un despliegue fallido
    → Tiempo que toma revertir un despliegue fallido o restaurarlo a un estado normal
    • Cálculo: mediana de momento de recuperación completa − momento en que ocurrió la falla para cada despliegue fallido
    • Tip: se recomienda extraerlo automáticamente desde el sistema de alertas o los logs. Se recomienda usar la mediana en vez del promedio para evitar el efecto de valores extremos
  • Code security and maintainability: seguridad y mantenibilidad del código
    • Cálculo: evaluación integral de cantidad de vulnerabilidades, complejidad, cobertura y más, usando herramientas de análisis estático, GitHub Advanced Security, CodeQL, etc.
    • Tip: configurar escaneos automáticos periódicos. Útil para medir el efecto de refactorizaciones o cambios en políticas de seguridad
• Velocity
  • Lead time: lead time
    → Tiempo que tarda un cambio de código en reflejarse en producción
    • Cálculo: tiempo desde que se crea el PR hasta su despliegue después del merge
    • Tip: usar la mediana en lugar del promedio reduce distorsiones. Si el lead time es largo, conviene medir por separado el tiempo de espera del PR o los retrasos en revisión
  • Deployment frequency: frecuencia de despliegue
    → Qué tan seguido se realizan despliegues a producción
    • Cálculo: número de despliegues durante un período determinado (por día o por semana)
    • Tip: hay que definir claramente si se incluirán también los despliegues automatizados; para equipos pequeños, una medición semanal puede ser más adecuada
  • PRs merged per developer: PR fusionados por desarrollador
    • Cálculo: número total de PR fusionados / número de desarrolladores que contribuyeron
    • Tip: usarlo no como herramienta de comparación, sino para medir la eficiencia del workflow del equipo. Debe interpretarse junto con el tamaño o la complejidad de los PR
• Developer Happiness
  • Flow state experience: experiencia de estado de flujo
    • Cálculo: evaluar mediante encuestas a desarrolladores la “frecuencia/duración reciente de experiencias de concentración profunda”
    • Tip: se recomienda una medición periódica de al menos una vez al mes. Incluir respuestas abiertas también puede aportar insights cualitativos
  • Engineering tooling satisfaction: satisfacción con las herramientas de ingeniería
    • Cálculo: recopilar mediante encuestas la satisfacción con el uso de herramientas y las mejoras deseadas
    • Tip: si se separa por categorías de herramienta (IDE, CI, seguimiento de issues, etc.), es posible detectar puntos de mejora más concretos
  • Copilot satisfaction: satisfacción con el uso de Copilot
    • Cálculo: encuesta de satisfacción a usuarios con licencia de Copilot (NPS o puntuación)
    • Tip: se recomienda comparar distintos momentos, como justo después de la adopción y tres meses después. El feedback puede servir para mejorar la capacitación y los casos de uso
• Business Outcomes
  • AI leverage: aprovechamiento de la IA
    • Cálculo: proporción de commits con Copilot, tasa de adopción de sugerencias de código de IA, tiempo de uso, etc.
    • Tip: se puede usar Copilot Telemetry API de GitHub o instrumentación interna. El análisis es más útil si se combina con feedback cualitativo
  • Engineering expenses to revenue: proporción entre gastos de ingeniería e ingresos
    • Cálculo: gastos relacionados con ingeniería / ingresos totales
    • Tip: es necesario alinear los criterios contables internos. Se recomienda analizar tendencias mensuales o trimestrales para comparar
  • Feature engineering expenses to total engineering expenses: proporción del costo de desarrollo de funcionalidades sobre el gasto total de ingeniería
    • Cálculo: (gastos relacionados con desarrollo de funcionalidades / gasto total de ingeniería)
    • Tip: para medirlo con precisión, hay que definir de antemano criterios claros para clasificar los costos no relacionados con funcionalidades, como mantenimiento, infraestructura o testing

[Tres pasos para el éxito de ingeniería]

Step 1: Identify the current barriers to success

• Identificar los problemas del proceso de desarrollo actual y las barreras que bloquean el éxito de la ingeniería es clave
• Esto sirve como línea base (baseline) para definir la dirección de mejoras futuras y sus prioridades
• Enfoque
  • Analizar todo el flujo del SDLC (Software Development Life Cycle) para detectar cuellos de botella
  • En GitHub analizan con base en 12 métricas estándar, pero se puede usar solo una parte según las características de la organización
• Participación del equipo
  • No debe definirlo una sola persona líder; todo el equipo debe definir en conjunto el proceso de mejora
  • Incluso empezar una conversación significativa con solo unas pocas métricas es suficiente
• Metodología

  • 1. Entender el flujo base

    • Revisar el flujo completo de ingeniería dividiéndolo así:
      • Planificar (Plan) → Desarrollar (Develop) → Revisar (Review) → Compilar (Build) → Probar (Test) → Liberar (Release) → Operar (Operate)

  • 2. Recopilar señales cuantitativas

    • Se analizan datos cuantitativos como los siguientes:
      • Frecuencia de despliegue: qué tan seguido se despliega
      • Lead time: tiempo desde que se escribe el código hasta que se despliega
      • Tasa de fallas por cambio: proporción de errores que ocurren después del despliegue
      • MTTR (tiempo medio de recuperación): tiempo que toma recuperarse después de que ocurre un problema

  • 3. Recopilar señales cualitativas

    • Recopilar feedback basado en la experiencia de desarrolladores y equipos:
      • Cuándo sienten ineficiencia los miembros del equipo
      • Qué herramientas o procedimientos causan problemas de forma repetida
      • Qué actividades generan la mayor carga psicológica
    • Método:
      • Usar encuestas, retrospectivas e entrevistas 1:1
      • También se puede usar una lista predefinida de preguntas de ESSP

  • 4. Definir los problemas clave

    • Definir las barreras (Barrier) a partir de los datos recopilados
    • Ejemplos:
      • "El lead time es largo y retrasa el desarrollo de nuevas funciones"
      • "Las fallas de build son frecuentes y reducen la confiabilidad del despliegue"
      • "Los desarrolladores sufren con frecuencia cambios de contexto (Context switching)"
    • Los problemas deben expresarse de forma específica y observable

  • 5. Priorizar métricas

    • En lugar de intentar mejorar todas las métricas al mismo tiempo, enfocarse en una o dos métricas con el mayor impacto
    • Esta prioridad se convierte luego en el criterio para intentar mejoras y medir resultados en el Step 2 y el Step 3
• Consejos para ejecutar con éxito el Step 1
  • 1. Enfocarse en la causa raíz, no en la apariencia superficial
    • No hay que juzgar solo por los síntomas visibles; hay que profundizar hasta la raíz del problema
      • Ejemplo: puede parecer que la lentitud se debe a las 'pruebas manuales', pero la causa real podría ser la falta de confianza en las pruebas automatizadas
    • Para esto, es útil tomar como referencia los antipatterns (antipatrones) que suelen aparecer en ingeniería de software
  • 2. Tomar como referencia los antipatterns
    • Un antipattern es una solución usada con frecuencia que en realidad no resuelve el problema y hasta puede generar efectos secundarios
    • GitHub ofrece como recurso aparte ejemplos de antipatterns que pueden existir en un equipo, por lo que pueden usarse como herramienta de autoevaluación
  • 3. Involucrar a las personas adecuadas
    • En la Task 1 del Step 1, es importante recibir aportes de personas con distintos roles
      • Ejemplo: desarrolladores, testers, operaciones, seguridad, product managers, etc.
    • Esto permite entender el workflow completo de forma multidimensional y evitar pasar por alto perspectivas específicas
  • 4. Usar en equilibrio datos cuantitativos y cualitativos
    • Las métricas por sí solas no permiten entender todo el contexto
    • Además del análisis cuantitativo, también hay que recopilar feedback cualitativo sobre problemas psicológicos, culturales y de colaboración del equipo
    • Ejemplo: baja moral del equipo, falta de comunicación o quejas en retrospectivas no se reflejan en cifras
  • 5. No elegir demasiadas barreras
    • No intentes resolver todos los problemas de una vez; enfócate en las barreras más urgentes y de mayor impacto
    • Si al inicio se asumen demasiadas tareas de mejora, existe el riesgo de perder capacidad de ejecución y momentum
  • 6. Asegurar la seguridad psicológica
    • Hay que crear un entorno donde los miembros del equipo puedan expresar sus opiniones con honestidad sin temor a desventajas o represalias
    • Esta es una condición clave para sacar a la luz los problemas reales y aumenta la confiabilidad y la efectividad de las actividades de mejora
  • 7. Comparar es para aprender, no para evaluar
    • Las comparaciones de métricas entre equipos o las diferencias de workflow deben usarse para obtener insights, no para evaluaciones cuantitativas de desempeño
    • Como cada equipo tiene contextos, objetivos, stack tecnológico y restricciones distintas, las comparaciones simples pueden llevar a malentendidos
    • En cambio, se debe fomentar una cultura de aprendizaje que comparta qué está funcionando bien y extraiga lecciones

Paso 2: Evaluar qué se necesita hacer para alcanzar tu objetivo

• Propósito
  • Etapa en la que se analiza qué cambios deben implementarse para resolver la barrera principal (Barrier) definida en el Paso 1
  • Va más allá de introducir una función o cambiar una herramienta; busca identificar las causas raíz y las soluciones a nivel organizacional, técnico y cultural

• 1. Análisis de las causas raíz del estado actual

  • En lugar de quedarse solo con resultados como "la velocidad es lenta" o "la satisfacción es baja", hay que ir más allá para entender:
    • por qué es lento,
    • qué razones estructurales u organizacionales existen,
    • y distinguir entre lo que se puede cambiar y lo que no
  • Herramientas disponibles:
    • técnica de los 5 Whys
    • diagrama de espina de pescado (causa-efecto)
    • análisis de retroalimentación cualitativa en las retrospectivas del equipo

• 2. Generación de posibles soluciones

  • Hacer una lluvia de ideas de soluciones técnicas, culturales y de proceso para el problema
  • Ejemplos:
    • Técnico: mejorar la velocidad de las pruebas, optimizar el pipeline de CI/CD
    • Cultural: ajustar las prácticas de code review, mejorar el onboarding
    • Proceso: limitar el tamaño de los PR, cambiar los criterios de merge
  • Técnica recomendada por GitHub:
    • combinar soluciones basadas en la observación con mejoras centradas en las personas

• 3. Evaluación del impacto y los riesgos

  • Para cada solución, evaluar los siguientes elementos:
    • impacto esperado: en qué métricas de mejora puede influir
    • viabilidad: recursos del equipo y capacidad realista de ejecución
    • aceptación organizacional: nivel de resistencia al cambio
    • diferencia entre efectos de corto y largo plazo: si genera resultados rápidos o un cambio sostenible
  • Para esto, se recomienda un pilot (prueba piloto)
    • probarlo primero en un equipo pequeño y, tras recopilar feedback, decidir si se amplía

• 4. Priorización y comunicación

  • Entre varias soluciones, priorizar con base en los siguientes criterios:
    • la que pueda generar el mayor impacto
    • la que sea más factible de ejecutar
    • la que resuelva el punto de dolor más urgente
  • Esta decisión debe compartirse con el equipo y lograr su acuerdo, y
    • conviene dejarla claramente expresada en forma de OKR o metas de mejora
• Consejos para ejecutar con éxito el Paso 2
  • 1. Considerar siempre la sostenibilidad a largo plazo
    • centrarse solo en resultados de corto plazo puede terminar provocando problemas a largo plazo
      • Ejemplo: introducir una herramienta nueva puede mejorar la velocidad de inmediato, pero si no viene acompañada de capacitación, soporte y gestión del cambio, puede terminar generando errores y confusión
    • Por eso, cualquier intento de mejora debe ser una estrategia que también considere el mantenimiento y la posibilidad de escalarla
  • 2. Considerar los trade-offs entre cada área (zone)
    • Hay que cuidar que un cambio para mejorar un área (por ejemplo, la velocidad) no sacrifique otra (por ejemplo, la satisfacción de los desarrolladores o la calidad)
      • Ejemplo: flexibilizar los criterios de revisión puede aumentar la velocidad, pero empeorar la calidad del código o el cansancio de los desarrolladores
    • Siempre hace falta un enfoque equilibrado, teniendo en cuenta que el impacto puede extenderse a varias áreas
  • 3. Involucrar al equipo desde el principio
    • cuando el equipo participa directamente y construye el cambio en conjunto, la probabilidad de éxito es mayor
    • recoger la opinión de los miembros para que el cambio pueda darse de forma bottom-up
    • un cambio impuesto de forma unilateral y top-down puede provocar resistencia y desinterés
  • 4. Definir con claridad las métricas de éxito
    • Antes de implementar el cambio, hay que acordar qué significa el éxito
    • Ejemplo: si el objetivo es “reducir el tiempo de despliegue”,
      • métrica rezagada: disminución real del tiempo de despliegue
      • métrica adelantada: reducción del tiempo de espera de los PR, aumento en las respuestas de encuestas de desarrolladores sobre “percibir una mejora en la velocidad de los PR”
    • Lo ideal es definir tanto leading indicators como lagging indicators
  • 5. Priorizar experimentos rápidos sobre planes perfectos
    • Un enfoque iterativo de probar incluso cambios pequeños con rapidez y mejorarlos a partir del feedback resulta efectivo
      • Al inicio, aunque el intento sea imperfecto, conviene probar en pequeño y ampliar solo si su efectividad queda demostrada
    • Esto ayuda a reducir la probabilidad de fracaso y fortalece la agilidad y capacidad de adaptación del equipo frente al cambio
  • 6. Empezar por cambios de gran impacto con poco esfuerzo
    • Cuando hay muchos cambios y son complejos, conviene empezar por mejoras de “alto impacto y bajo costo”
    • Ejemplo: introducir una guía simple de revisión o eliminar notificaciones innecesarias puede aplicarse rápido y aun así tener un gran efecto en la satisfacción
    • Las primeras experiencias de éxito dan confianza al equipo y aportan el impulso para avanzar hacia problemas más difíciles

Paso 3: Implementa tus cambios, monitorea los resultados y ajusta

• Ejecutar dentro de la organización el intento de mejora (Intervention) derivado en el Step 2,
  medir sus resultados y, si hace falta, ajustarlo o iterarlo para buscar un éxito de ingeniería continuo

• 1. Implementación (Implement the change)

  • Antes de implementar, se debe dejar claro lo siguiente:
    • ¿Qué cambio se va a realizar?
    • ¿Quién será responsable?
    • ¿Con qué métricas se evaluará?
    • ¿Desde cuándo y hasta cuándo se medirá?
  • Consideraciones durante la implementación:
    • Asignar responsables: dejar claro el ownership
    • Onboarding y capacitación del equipo: todos los integrantes deben entender por qué el cambio es necesario y qué va a cambiar
    • Documentar el cambio: dejar registro para futuras retrospectivas e iteraciones
  • Ejemplos de adopción:
    • Cambiar la estrategia de build cache para mejorar la velocidad de CI/CD
    • Cambiar la política de code review (por ejemplo, introducir la regla de responder en menos de 1 día)

• 2. Monitoreo (Monitor the change)

  • Después de implementar la mejora, hacer seguimiento de sus efectos con las métricas definidas de antemano
    • Si se redujo el lead time
    • Si disminuyó la tasa de fallos
    • Si mejoró la satisfacción de los desarrolladores, etc.
  • Herramientas:
    • GitHub Insights, Copilot Telemetry, sistemas internos de BI
    • Dashboards de reportes semanales/mensuales
    • Encuestas a desarrolladores o feedback de retrospectivas
  • Puntos importantes:
    • Debe ser posible compararlo con la línea base (baseline)
    • Es importante observar la tendencia, no solo un valor aislado

• 3. Recolección de feedback (Collect feedback)

  • Además de las métricas cuantitativas, es necesario recoger feedback sobre si el cambio realmente ayudó desde la perspectiva de los desarrolladores
    • Usar retrospectivas, encuestas anónimas, reuniones 1:1, etc.
    • Verificar si la mejora realmente se percibe como útil o si, por el contrario, genera fatiga
  • Los cambios implementados apresuradamente sin consenso organizacional pueden provocar resistencia y rechazo

• 4. Ajustar o iterar (Adjust as needed)

  • Si el resultado del intento de mejora no cumple las expectativas o trae efectos secundarios, se puede responder así:
    • Revertir o complementar el cambio
    • Mantener solo algunos elementos y reducir el alcance
    • Expandir su aplicación a una escala mayor
  • Independientemente de si el cambio fue un éxito o un fracaso, siempre se debe aprender lo siguiente:
    • ¿Qué elementos fueron efectivos?
    • ¿Qué factores actuaron como obstáculos?
    • ¿Qué habría que cambiar la próxima vez?
• Consejos para ejecutar con éxito el Step 3
  • 1.No esperar perfección inmediata
    • No todos los cambios generan una mejora visible de inmediato
      • Puede tomar tiempo para que los efectos aparezcan
      • Como el equipo también necesita un proceso de adaptación al cambio, la paciencia y la observación continua son importantes
    • Al inicio, puede ser útil usar herramientas de feedback cualitativo, como encuestas, para entender cómo se percibe el cambio
  • 2.Seguir iterando y mejorando el cambio
    • Aunque algo haya funcionado una vez, no se trata de dejarlo igual, sino de que el cambio también debe evolucionar y ajustarse de forma constante
    • Ante nuevos problemas o cambios en el entorno externo, también puede ser necesario revisar de nuevo las mejoras existentes
    • Hay que alentar al equipo a verlo como una actividad regular y a mantener el ciclo de mejora
  • 3.Prestar atención a efectos secundarios no intencionales
    • Algunos cambios pueden generar fricciones inesperadas en otras áreas
      • Ejemplo: mejorar la velocidad de despliegue es positivo, pero si la validación de calidad es débil, puede terminar aumentando los bugs
    • Además de las métricas, también hay que revisar los cambios en el flujo general del workflow, y si aparecen señales anómalas, actuar de inmediato
  • 4.Seguir revisando el estado de seguridad psicológica
    • Incluso después del cambio, debe mantenerse un entorno donde el equipo pueda plantear problemas libremente
    • Para evitar que se acumulen problemas que nadie dice, hace falta crear un ambiente donde los integrantes puedan dar feedback honesto
    • Inconformidad con el proceso cambiado, aumento excesivo de carga de trabajo, estrés inesperado, etc.
  • 5.Evaluar continuamente los efectos a largo plazo
    • La clave no es el resultado de corto plazo, sino el rendimiento sostenido y la mejora de la moral del equipo
    • Con el paso del tiempo:
      • si el cambio ya se asentó
      • si no surgieron nuevos efectos secundarios o problemas
      • si hay mantenimiento o caída del rendimiento, todo esto debe revisarse continuamente
  • 6.Usar el feedback como oportunidad de aprendizaje
    • Incluso los cambios fallidos son activos de aprendizaje valiosos
    • Hay que analizar qué salió mal con base en datos y feedback e incorporarlo al siguiente intento
    • También es importante fomentar una cultura en la que el equipo vea el fracaso como una oportunidad de aprendizaje

Beyond the steps: Make the playbook work for you

• Adaptación

  • Elegir las métricas y los métodos de medición (telemetría vs. encuestas) según las características de la organización
  • No se debe medir por medir, sino usarlo como herramienta para una mejora real

• Gestión del cambio

  • Es importante usar frameworks de gestión del cambio como ADKAR o el modelo de Kotter para ayudar a que la organización se adapte bien al cambio

• Mentalidad de crecimiento

  • Ver cada intento como una oportunidad de aprendizaje, y una actitud que acepta el fracaso es clave para la mejora continua

• Gamificación

  • Diseñar recompensas basadas en motivación puede tener efectos positivos, pero si se diseña mal, puede incluso provocar baja calidad o desequilibrios

Alternatives to the GitHub Engineering System Success Playbook

• Según la situación, en lugar de ESSP también se puede optar por análisis simples centrados en el uso de features o estrategias de mejora basadas en herramientas individuales
• Lo importante es un enfoque realista adecuado para el equipo y la organización, junto con un esfuerzo continuo de mejora