Qué métricas técnicas debería conocer un founder

Un founder que no programa suele medir el avance del producto con la métrica más intuitiva: ¿está funcionando lo que pedí? Es una pregunta razonable, pero insuficiente. Un producto digital puede estar funcionando y al mismo tiempo estar acumulando problemas que en tres meses lo van a dejar fuera de servicio. O puede estar avanzando a un ritmo mucho más lento del que podría, y nadie se da cuenta porque "las cosas se entregan".

No necesitás leer código para detectar estas situaciones. Necesitás seguir un puñado de métricas técnicas que, bien interpretadas, te cuentan más sobre la salud de tu producto que cualquier reunión de avance. Estas son las cinco que todo founder debería conocer.

1. Velocidad real de entrega

La pregunta no es "¿están trabajando?". La pregunta es "¿cuánto valor nuevo llega a los usuarios por mes?".

Medir la velocidad de un equipo de desarrollo es más difícil que contar funcionalidades entregadas, porque no todas las funcionalidades pesan lo mismo. Pero hay dos indicadores que, combinados, te dan una buena aproximación:

• Cuántas cosas se terminan por mes. Contá funcionalidades, mejoras o correcciones que efectivamente llegaron a producción —no las que están "casi listas"—. La tendencia importa más que el número absoluto: si el equipo entregaba ocho cosas por mes y ahora entrega cuatro, hay un problema. Puede ser que las tareas sean más complejas, pero también puede ser que el sistema se haya vuelto tan frágil que cada cambio requiere el triple de validación.

• Cuánto tiempo pasa entre que se pide algo y se entrega. No todo lo urgente es importante, pero si sistemáticamente los pedidos tardan el doble que hace seis meses, algo está frenando al equipo. Puede ser un problema de procesos, una arquitectura que se resiste a los cambios, o simplemente que el equipo está haciendo más cosas de las que puede.

2. Estabilidad del sistema

Un sistema estable es uno que se comporta de forma predecible la mayor parte del tiempo. La estabilidad no se mide en ausencia total de errores —todo sistema tiene errores— sino en frecuencia e impacto de los que ocurren.

Dos indicadores simples:

• Frecuencia de caídas totales o parciales. Si tu aplicación queda fuera de servicio una vez por mes, es preocupante. Si queda fuera una vez por semana, es una emergencia. No hace falta un tablero de control sofisticado: si los usuarios te avisan antes de que el equipo lo detecte, el sistema no está siendo monitoreado adecuadamente.

• Cantidad de errores que llegan a los usuarios. No todos los errores son iguales. Un botón que no responde en una pantalla poco usada no es lo mismo que un error que impide completar una compra. Pero si el volumen total de errores visibles para el usuario crece mes a mes, el sistema se está deteriorando y el equipo está dedicando más tiempo a apagar incendios que a construir cosas nuevas.

3. Velocidad de recuperación ante fallos

Más importante que evitar todos los errores —eso es imposible— es saber cuánto tarda el equipo en resolverlos cuando aparecen. Un sistema que se cae una vez por mes pero se recupera en diez minutos es, en la práctica, más estable que uno que se cae dos veces por año pero tarda tres horas en volver.

Preguntale a tu equipo: ¿cuánto tardamos en promedio en resolver un incidente desde que se detecta? Si la respuesta es "depende", pedí que midan los últimos cinco. Vas a obtener un número que probablemente te sorprenda. Muchas empresas descubren que el tiempo de resolución es alto no por falta de capacidad técnica, sino porque nadie tiene claro qué hacer cuando algo falla.

Si este tema te preocupa, el artículo sobre qué hacer si tu aplicación queda fuera de servicio ofrece un protocolo paso a paso para actuar durante una caída.

4. Proporción entre construir y mantener

Todo producto digital divide el tiempo del equipo entre dos tipos de trabajo: construir cosas nuevas y mantener lo que ya existe. Lo que cambia con el tiempo es la proporción.

En un producto joven, el equipo dedica quizás un 80% a construir y un 20% a mantener. A medida que el sistema crece, la proporción se invierte: cada vez se gasta más tiempo en corregir errores, actualizar dependencias, optimizar partes lentas y reescribir código que quedó desordenado.

Cuando el equipo pasa más de la mitad del tiempo manteniendo en lugar de construyendo, el producto entró en una meseta de velocidad. No es necesariamente una señal de alarma —es esperable en sistemas maduros—, pero deberías saberlo. Porque si estás planeando un crecimiento agresivo para los próximos meses y tu equipo ya está dedicando el 60% del tiempo a mantenimiento, algo tiene que cambiar antes de que el plan sea viable.

El artículo sobre cómo evitar que la deuda técnica frene tu empresa explica cómo gestionar ese deterioro progresivo antes de que se vuelva una crisis.

5. Cobertura de monitoreo

El monitoreo es lo que permite detectar problemas antes de que los detecten los usuarios. La métrica no es si tenés monitoreo —casi todos dicen que sí—, sino qué porcentaje de las funciones críticas están efectivamente cubiertas.

Hacé este ejercicio con tu equipo: enumeren las cinco cosas que, si fallan, más daño le hacen al negocio —que los clientes no puedan pagar, que no se puedan registrar, que los datos se pierdan, lo que aplique a tu caso—. Después pregunten para cada una: ¿nos enteraríamos en menos de cinco minutos si esto falla? Si la respuesta es no para alguna de las cinco, el monitoreo tiene un agujero.

Cómo usar estas métricas sin volverte un micro-manager

El objetivo de seguir métricas técnicas no es controlar al equipo ni justificar despidos. Es tener una conversación informada sobre la salud del producto. Cuando un founder pregunta "¿por qué tardamos tanto en sacar esta funcionalidad?" y el equipo responde "porque el sistema está cada vez más frágil y cada cambio requiere el doble de pruebas", ambos necesitan datos para pasar de las percepciones a los hechos.

La forma correcta de usar estas métricas es revisarlas una vez por mes con el equipo, preguntar qué historia cuentan, y decidir juntos si hay que hacer algo distinto. La forma incorrecta es pedirlas todas las semanas, compararlas contra metas arbitrarias sin contexto, y usarlas para presionar.

Empezá por una sola

Si nunca seguiste métricas técnicas, no intentes implementar las cinco al mismo tiempo. Elegí una —velocidad de entrega es la más directa para empezar—, pedile al equipo que la mida durante tres meses, y usá esos datos para tener una conversación distinta sobre el avance del producto. Una sola métrica bien usada vale más que cinco que se miden pero no se miran.