Comprendiendo el Concepto de Tiempo hasta la Calidad
Hoy en día existen muchas métricas para hacer seguimiento al progreso de QA. La mayoría son bastante útiles, pero suelen ser unidimensionales, en el sentido de que son instantáneas de un momento o sprint específico en el tiempo. Esto es cierto incluso para las métricas de tasas y tendencias, que son sumamente importantes, pero, nuevamente, solo capturan un instante.
Cuando trabajé en Symantec, noté lo siguiente:
Había muchas métricas empleadas para determinar el *nivel* de calidad alcanzado (supuestamente) para la fecha de entrega. Pero no se recolectaban métricas, ni en proceso ni retrospectivas, para medir el *costo* de alcanzar esa calidad.
En otras palabras, no nos importaba cuán eficientemente se alcanzaba esa calidad a lo largo del ciclo de vida del proyecto.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Puede que tu producto se haya lanzado con alta calidad, pero ¿realmente era necesario dedicar tanto tiempo y esfuerzo para lograrlo?
Esta es una cuestión de eficiencia, no de calidad en sí misma, pero ambas están muy relacionadas.
La Intersección entre Calidad y Eficiencia
Calidad y eficiencia se cruzan porque una de las principales razones por las que los proyectos de software suelen exceder significativamente su cronograma comprometido (y esto suele aparecer como una sorpresa en la fase final del proyecto) es la mala calidad del código. No solo la calidad inicial, sino la calidad a lo largo de todo el proyecto.
Otra razón, que realmente es solo una consecuencia inevitable de la mala calidad del código, son los defectos que requieren varios ciclos de corrección, abarcando varios pases de prueba o sprints antes de que el defecto sea realmente resuelto. Si es que alguna vez se arregla.
Estas interminables iteraciones de corregir, probar y volver a fallar, suman incontables semanas-persona a casi todos los proyectos de software.
Sin embargo, curiosamente, este patrón de fallas no queda reflejado de forma única en ninguna otra métrica de proyecto o calidad que haya visto. Porque, como se mencionó antes, todas esas métricas son instantáneas que no logran capturar este fenómeno.
Se me ocurrió que había una forma sencilla de capturar este patrón de fallas. Ideé una métrica que llamé «Tiempo hasta la Calidad» o TTQ.
Presentando una nueva métrica: Tiempo hasta la Calidad (TTQ)
La métrica en sí es bastante simple. Funciona así:
Para cada pase de prueba (como se defina), haz seguimiento no solo de cuántas pruebas pasaron o fallaron, sino cuántas pasaron en el primer intento. Y cuántas requirieron dos, tres o más intentos antes de que finalmente pasaran las mismas pruebas.
Como ejemplo simple, si ejecutaste 20 pruebas y 5 pasaron al primer intento, tu proporción TTQ es 25%. Mientras más alto sea el número, mejor. Es un indicador simple, calculable y fácilmente accesible de la calidad general de tu código.
Esta métrica es un excelente indicador de la calidad inicial del código.
Esto se debe a que, cuanto más alta es la calidad del código, menos veces tendrás que repetir una prueba antes de que pase. Y viceversa. Esta métrica es mucho más precisa que los recuentos de errores y sus tendencias.
TTQ también es una métrica increíblemente útil para el seguimiento de proyectos.
Por ejemplo, si en el primer pase de pruebas el 70% pasó y el 30% falló, puedes asumir razonablemente que tu proyecto aún está encarrilado en cuanto a plazos. Pero si, por ejemplo, solo el 20% de tus pruebas pasaron al primer intento, entonces, para decirlo en términos técnicos, «Chica, ¡estás en problemas! »
Esto significa que de hecho no realizaste un primer pase exitoso. Y que hay que volver a sumar ese tiempo a un pase futuro como deuda de calidad.
La métrica TTQ es sumamente útil como lo que me gusta llamar una métrica de "alarma temprana".
Si la usas de forma consistente, proporciona datos muy precisos que permiten al PM saber si el proyecto se está descarrilando mucho antes de que el tren realmente se salga de la vía.
Esto permite tomar medidas proactivas mucho antes para recuperar el control. Evitando admisiones embarazosas muy avanzado el proceso, cuando el cronograma del proyecto ya está hecho trizas. En otras palabras, utiliza un umbral TTQ para definir si el proyecto sigue en verde, en amarillo o a punto de pasar a rojo. Haz que sea parte integral del estatus general del proyecto.
Porque seamos honestos, una de las patologías constantes en el desarrollo de software es la negación persistente de que las cosas van mal, y que el problema es grave, justo cuando se vuelve evidente que es así. Todos temen ser etiquetados como “negativos”, o que simplemente son perezosos o poco comprometidos para solucionar las cosas, o que no son "jugadores de equipo". El paralelismo con familias disfuncionales es inquietantemente obvio.
Esta negación y el hecho de reprimir lo que todos realmente saben que está sucediendo genera el patrón de falla de rehusarse a reconocer que el proyecto está, de hecho, muy pero muy retrasado, hasta el último instante.
Cuando ya no se puede ocultar esto frente a la alta dirección, la desagradable sorpresa que les genera solo sirve para minar, a veces de forma permanente, su confianza en los equipos de desarrollo. Y ¿quién puede culparlos?
Pero si incorporas TTQ de forma consistente en tus métricas y gestión de proyectos—y actúas en función de lo que esa métrica indica—puedes evitar eso.
Medir el Tiempo Hasta la Calidad despersonaliza la decisión de reconocer que los riesgos de cronograma y calidad se están acumulando en el proyecto desde sus primeras fases.
Se vuelve una cuestión muy clara y objetiva, simplemente de números. No es una cuestión de heroísmo personal, que frecuentemente tiene un gran costo para la persona.
La métrica TTQ también es muy útil para el retrospectivo/post mortem de un proyecto.
Permitirá al equipo identificar exactamente qué secciones del código eran, y siguieron siendo, débiles durante el proyecto. Y, por extensión, qué tan eficiente fue el equipo generando calidad como tal. O lo costoso que fue.
Esta es una pregunta que normalmente se evita en las retrospectivas de proyectos. En parte porque los equipos no tienen el vocabulario conceptual para formularla, y en parte porque a menudo es políticamente delicado señalar la baja calidad de código de los ingenieros de manera sostenida.
En Resumen
TTQ brindará una enorme transparencia y previsibilidad a tus proyectos con casi ningún costo en tiempo o esfuerzo, ya que es simplemente un meta-análisis de métricas que ya estás reuniendo.
Llevo usando TTQ en mis proyectos de QA durante dos décadas y ha ganado amplia aceptación entre los gerentes de proyectos a quienes he capacitado en ello, por todas las razones señaladas anteriormente.
Pruébalo, y lo comprobarás por ti mismo. Realmente será un cambio de juego para tu equipo. Como siempre, te deseo el mejor de los éxitos.
PD: Si quieres escuchar más anécdotas y razones detrás del TTQ, hablé con Jonathon Wright en el Podcast de QAL.
