Documentos del Proyecto · Serie 15 · Semana Planificación · Tema 200
Una métrica de calidad es la traducción de un adjetivo a un número que alguien puede medir sin discutir. «Rápido» no es una métrica. «El 95 % de las consultas responden en menos de dos segundos con 200 usuarios concurrentes» sí lo es.
Para qué sirve, en una línea
Convierte un criterio de aceptación en algo comprobable, y por tanto en algo que se puede aceptar o rechazar sin que dependa de quién mire.
Qué lleva cada ficha
Una por métrica. Seis campos y ninguno sobra:
| Campo | Ejemplo |
|---|---|
| Qué se mide | Tiempo de respuesta de la consulta de saldo |
| Cómo se mide | Percentil 95 sobre 1.000 peticiones, con 200 usuarios concurrentes |
| Valor objetivo | Menos de 2 s |
| Tolerancia | Se acepta hasta 2,5 s en un máximo del 5 % de las mediciones |
| Cuándo se mide | En cada entrega a preproducción |
| Quién mide | El área de sistemas, no el equipo que construyó |
El campo de tolerancia es el que evita la discusión más tonta del proyecto: si 2,1 segundos pasa o no pasa.
La regla de la medición independiente
Quien mide no debería ser quien construye. No por desconfianza: porque quien construye conoce el camino feliz y lo recorre sin darse cuenta.
Si no hay más remedio que medir uno mismo, entonces al menos que el método esté escrito antes de construir. Un método definido a posteriori se parece sospechosamente a lo que el sistema ya hace.
Cuántas hacen falta
Menos de las que se ponen. Una métrica que nadie va a mirar el día del arranque es trabajo de medición que se paga y no informa.
La prueba para decidir si una métrica se queda: ¿alguien tomaría una decisión distinta según su resultado? Si la respuesta es no, sobra, por interesante que sea el dato.
En un proyecto mediano suelen bastar entre cinco y ocho, repartidas entre rendimiento, corrección y operación. Veinte métricas significan casi siempre que se midió lo que era fácil medir.
Qué la vuelve papel mojado
- Mide lo fácil. Número de defectos encontrados, líneas de código, tareas cerradas. Se miden porque se pueden contar, no porque digan algo.
- Sin condiciones de medición. «Responde en menos de dos segundos» sin decir con cuánta carga no significa nada.
- Sin tolerancia. Entonces cada medición al límite es una negociación.
- Se define después de construir. El error más común y el más difícil de ver desde dentro.
Y si me falta lo que pide
El usuario no sabe darme un número. Dale tú tres opciones: «¿uno, tres o diez segundos?». Elegir es fácil; inventar, no.
No tengo forma de medirlo. Entonces no es una métrica todavía. O consigues cómo medirlo o lo bajas a criterio de aceptación cualitativo, pero no lo dejes escrito como si fuera medible.
Son demasiadas métricas. Quédate con las que alguien miraría el día del arranque. Suelen ser entre cinco y ocho para un proyecto entero.
Caso práctico: los dos segundos que no eran dos segundos
Escenario construido con patrones habituales; las cifras son ilustrativas.
Un proyecto define como métrica «tiempo de respuesta menor a 2 segundos». Se mide en cada entrega y se cumple siempre: 1,4 s de media.
El sistema arrancó un lunes. El martes, el área de atención llamó para decir que era inusable.
Las tres cosas que la métrica no decía:
- Con cuánta carga. Se medía con tres usuarios; en producción eran 180.
- Qué estadístico. Se medía la media. El percentil 95 era de 11 segundos, y ese percentil es justo el que la gente recuerda.
- Con qué datos. Se medía sobre una base de pruebas de 5.000 registros; la real tenía 2,3 millones.
Nadie hizo trampa. La métrica se cumplió tal como estaba escrita, y estaba escrita de forma que era imposible incumplirla.
Una métrica sin condiciones de medición no mide el sistema: mide el escenario que eligió quien la ejecutó.
La versión corregida ocupaba dos líneas más y era, esencialmente, la misma métrica con las tres condiciones dentro. Esas dos líneas habrían costado diez minutos en la semana dos.
Checklist
- ¿Cada métrica dice con qué carga, con qué datos y qué estadístico?
- ¿Tiene tolerancia declarada?
- ¿Mide alguien distinto de quien construye?
- ¿Se definieron antes de construir?
- ¿Alguna métrica mide lo fácil en vez de lo importante?
- ¿Cuántas hay? Si son más de diez, ¿se miran todas?
Para cerrar
Una métrica bien escrita se puede incumplir. Esa es la prueba: si tu métrica es imposible de fallar, no está midiendo nada.
Te leo en los comentarios: de tus métricas de calidad, ¿alguna ha salido en rojo alguna vez?
Referencias
- Project Management Institute, Guía del PMBOK, sobre métricas de calidad y planificar la gestión de la calidad.
- Juran, J. M., Juran's Quality Handbook, sobre la definición operativa de una característica de calidad.
- Wiegers, K. y Beatty, J., Software Requirements, sobre requisitos no funcionales verificables.
← Anterior en la serie: La curva S no se mira sola
Siguiente en la serie: Cada nueve de disponibilidad se paga →
Este artículo forma parte de Documentos del Proyecto, una serie de 73 artículos. Ver todos los de esta serie · Índice completo por materia.