¿Cómo enfocar los esfuerzos en lo importante?

Al inicio de un proyecto de software se establecen plazos de tiempo, presupuesto estimado y niveles mínimos de calidad esperados. Y en el día a día de su ejecución, se usan varias métricas para controlar su avance y tener la oportunidad de corregir cualquier desviación de los objetivos iniciales. De aquí surge la importancia de que los objetivos sean alcanzables, medibles y correctamente enfocados a la finalidad del proyecto. 

Las dos primeras características (alcanzables y medibles), aunque no son triviales, por lo general son decisiones binarias que se pueden responder unívocamente. Es decir, un objetivo bien acotado tras un análisis del equipo de proyecto, puede determinarse si es alcanzable en el tiempo o no. Lo mismo pasa con la capacidad de medir estos objetivos. Basta con hacer un ejercicio o revisar los sistemas o instrumentos necesarios para validar la factibilidad de la medición. Pero no pasa lo mismo con la capacidad de establecer las características de calidad esperadas y saber si están bien enfocados con el objetivo que persigue el proyecto. Y la situación se torna peligrosa aún más si un objetivo errado o incompleto se asocia a un incentivo.

Pondré un ejemplo de la cotidianidad para ejemplificar cuando un objetivo no está alineado a la finalidad de un proyecto y se asocia a un incentivo de cualquier clase. Recientemente escuché que un equipo de bomberos tenía asociado un incentivo directamente proporcional a la cantidad de fuegos que apagaba. Eso quiere decir que el objetivo de ese grupo es claramente apagar fuegos pero al asociarle un incentivo a ese hecho, se cae en el riesgo de propiciar un comportamiento no deseado como lo fue que ese grupo iniciaba el fuego para luego tener un incremento en su paga. Algo similar se produce cuando se asocia un incentivo proporcional a las líneas de código que escriba un desarrollador o el número de casos de prueba que se pueda ejecutar. Hacerlo de una forma general sin condicionar la situación esperada en términos de calidad, no es recomendable.

Como muchas cosas en la vida, todo parte de la definición correcta de un objetivo. En algún momento de mi carrera escuché que un buen ejemplo de definición de proyecto fue el que John F. Kennedy  anunció al congreso de los Estados Unidos acerca del viaje del hombre a la luna. Dijo según palabras textuales: “Antes de que acabe esta década,  llevaremos a un hombre a la luna y lo traeremos de vuelta sano y salvo a la tierra”. Este proyecto está acotado en tiempo y describe el resultado esperado.

El proceso de decantar la visión de una organización al objetivo de sus departamentos y por consiguiente, sus proyectos, termina cuando se evalúa el alcance, tiempo y calidad a bajo nivel. En los proyectos de desarrollo de software las características de calidad se traducen en las especificaciones y criterios de aceptación que guían el desarrollo y las pruebas. Luego de tener en claro el alcance del proyecto, de él se desprende  el resto de los objetivos secundarios, tareas y métricas de calidad. Tmap ₁ (Test Management Approach) usa las características de calidad para entender cómo se puede definir la calidad de un producto y por lo tanto las métricas asociadas a cada característica. Cuando pensamos en características de calidad tenemos una variedad como rendimiento, portabilidad, seguridad, funcionalidad y mantenibilidad entre muchas otras.

Priorizar las características de calidad de un producto que se desea atender es de vital importancia en los proyectos de software. Algunas veces, la seguridad implica que la aplicación se degrade un poco en rendimiento. A nivel de interfaz de usuario, ocurre que a veces la eficiencia del diseño de los flujos  priva un poco la experiencia de usuario satisfactoria en términos de usabilidad. Esta priorización y balance se logra solamente si se tiene claro a donde apuntar según el objetivo general del proyecto.

Cuando se deben tomar decisiones entre dos opciones es necesario evaluar las ventajas y desventajas de cada una con la información que se tiene y con la base de la esencia personal y hacia dónde quieres ir o llegar a ser. Pues igual pasa en la definición de los objetivos del proyecto de software, es necesario aclarar muy bien expectativas y puntos de vistas para alinearlos a la razón de ser de la organización en consecuencia poder atinar bien y enfocar los esfuerzos en lo importante. De esta manera,  todo fluirá mejor y en el momento de presentarse problemas o conflictos, pues todos los involucrados recurrirán a la esencia de la organización para encontrar las soluciones.

_________

₁ https://www.sogeti.es/soluciones/calidad-de-software/metodologias-de-pruebas/tmap/

Autor | Gloriana Aguirre – Ingeniera de Pruebas Senior