AXENTED — Blog Article

Cómo Realizar un Health Check de tu Equipo de Ingeniería

Los equipos de ingeniería no anuncian cuando están luchando. Las señales son indirectas: los plazos de entrega se retrasan unos días, luego unas semanas. Los reportes de bugs aumentan ligeramente. Algunos ingenieros experimentados comienzan a pasar más tiempo en Slack que en el código. Para cuando el problema es visible a nivel ejecutivo, lleva meses acumulándose.

Un health check del equipo de ingeniería es una forma estructurada de hacer visibles esas señales antes de que se conviertan en crisis. Este es el marco que hemos refinado ejecutando evaluaciones en equipos de ingeniería en empresas en etapa temprana y de crecimiento.

Velocidad de Entrega

La señal más objetiva de la salud del equipo es la velocidad de entrega: cuánto trabajo se completa por sprint o por semana, y si ese número está en tendencia ascendente, plana o descendente. La velocidad bruta no te dice mucho por sí sola — un equipo que termina menos story points este mes que el mes pasado podría estar tomando trabajo más difícil, no estando en dificultades. Lo que importa es la tendencia y la proporción de trabajo comprometido a trabajo completado.

Un equipo que consistentemente completa el 60–70% de lo que se compromete en la planificación del sprint no está en crisis, pero tiene un problema de previsibilidad. Las partes interesadas no pueden depender de sus estimaciones. Un equipo que completaba el 80% hace seis meses y ahora completa el 50% tiene un problema de velocidad que vale la pena diagnosticar.

Proporción de Deuda Técnica

La deuda técnica es normal. Cada base de código funcional la tiene. El indicador de salud no es la presencia de deuda técnica sino si el equipo la está gestionando activamente o ignorándola. Un indicador simple: ¿qué porcentaje de la capacidad de ingeniería en los últimos tres meses fue para mantenimiento, correcciones de bugs y reducción de deuda versus nuevas funcionalidades?

Un rango saludable es aproximadamente 70% trabajo nuevo, 30% mantenimiento. Los equipos que pasan más del 50% de su tiempo en mantenimiento están en una espiral de deuda: la deuda se está acumulando más rápido de lo que pueden pagarla, y la situación empeorará a menos que la proporción cambie deliberadamente.

Tiempo de Incorporación

¿Cuánto tiempo le toma a un nuevo ingeniero hacer su primera contribución significativa? El tiempo de incorporación es un indicador poco usado de la salud del código, la calidad de la documentación y la transferencia de conocimiento del equipo. Un equipo donde los nuevos ingenieros son productivos en dos semanas tiene buena documentación, una base de código limpia y una cultura de compartir contexto. Un equipo donde los nuevos ingenieros necesitan seis semanas para ser útiles tiene lo contrario.

Mide esto preguntándole a los ingenieros que se unieron en los últimos seis meses: ¿cuándo sentiste que entendías la base de código lo suficientemente bien como para trabajar de forma independiente? Las respuestas generalmente son honestas y casi siempre son diagnósticas.

Tasa de Incidentes y Tiempo de Resolución

Los incidentes de producción son inevitables. Lo que importa es la tasa, la gravedad y la respuesta. Un equipo saludable tiene un proceso claro de respuesta a incidentes, resuelve los incidentes dentro de los SLAs definidos y realiza post-mortems que producen mejoras accionables. Un equipo poco saludable tiene incidentes recurrentes del mismo tipo, tiempos de resolución largos y post-mortems que producen informes extensos que nadie implementa.

Mira los últimos 90 días: cuántos incidentes, cuál fue el tiempo promedio de resolución y ¿alguna clase de incidente ocurrió más de una vez? Si el mismo tipo de incidente está ocurriendo repetidamente, el health check debe centrarse en por qué no se está abordando la causa raíz.

Satisfacción del Equipo

Los ingenieros que no están contentos con su entorno de trabajo se van. Los indicadores anticipados son generalmente visibles antes de que alguien presente su renuncia: menor participación en las reuniones del equipo, menos actividad de revisión de código, más respuestas de "está bien" en las sesiones 1:1. Un health check estructurado debe incluir encuestas anónimas que pregunten directamente sobre la satisfacción con el trabajo técnico, la confianza en la dirección técnica y si los ingenieros recomendarían el equipo a un amigo.

Qué Hacer con los Resultados

Un health check sin acción es solo una auditoría. Una vez que las señales son visibles, prioriza los dos o tres factores con la mayor brecha entre el estado actual y la línea base saludable. Para la mayoría de los equipos, eso suele ser la previsibilidad de entrega (tasa de completación del sprint) y la proporción de deuda técnica. Estas se acumulan, y se acumulan más rápido de lo que la mayoría de los equipos espera.

Establece un objetivo de 90 días para cada métrica con un dueño nombrado. Revisa el health check a los 90 días para medir el delta.