En Agile Software Development, Alistair Cockburn comenta que uno de los criterios que él utiliza para considerar exitosa la aplicación de una metodología en un proyecto es que las personas del proyecto piensen que trabajarían de la misma manera otra vez. Por otro lado, Scott Berkun en The Art of Project Management lista los atributos de buenos procesos, aquellos que benefician la ejecución de un proyecto e incluye el siguiente:
“Las personas impactadas por los procesos están a favor de ellos. A las personas les gustan los procesos útiles. Un buen proceso sera visto como algo deseable por aquellos que lo necesitan. Si se está proponiendo un nuevo proceso que impacta a testers y programadores, y el proceso es valioso para el proyecto, no debería ser muy difícil convencerlos de probarlo.”Mi experiencia en proyectos utilizando procesos definidos no cumplen esos criterios en general.
Quiero decir que las personas no trabajarían de la misma manera si pudieran elegir y en gran parte no estaban a favor de los procesos al momento de aplicarlos. Déjenme plantearlo de manera más personal: hoy estoy trabajando de una manera que en esencia no volvería a utilizar si pudiera elegir y, en muchas ocasiones, no estoy a favor de los procesos que debo aplicar.
Detallando un poco más, me refiero a procesos que no agregan valor, a la generación de documentación que nadie lee, a la producción indiscriminada de evidencia con poco sentido practico, a los pasos que pretenden brindar seguridad sobre los resultados y mas bien obstaculizan su concreción. Mi sensación es que mi experiencia no es aislada, parece ser más la regla que la excepción. Si esto es así, ¿qué es lo que está mal entonces?
Cuando se usan procesos definidos en una empresa, existen personas que se encargan de definirlo. Calidad, Proceso, Organización y Métodos son nombres usualmente asignados a este tipo de grupos. Es raro que estas personas dediquen su tiempo a crear procesos para torturar al resto de la gente. Todos apreciamos el respeto de nuestros compañeros y poseemos un sentido de logro. Por más incómodo, incoherente o inadecuado que parezca un proceso, alguien en algún momento lo creo con objetivos valorables y con buenas intenciones.
Mi impresión es que una de las razones de estos males es que la ejecución de los proyectos de creación de procesos adolecen de muchos de los problemas de los proyectos de software mal gestionados. Se define una fecha de fin para la definición del proceso, posiblemente atada a una auditoria o assesment que permita una certificación o evaluación de una norma de calidad. A las personas encargadas de llevarlo adelante les encantaría poder charlar con las personas que ejecutan proyectos para relevar necesidades, estudiar distintas herramientas o técnicas para incluir en el proceso, investigar practicas aplicadas en otros lugares, elaborar propuestas para ver como será este nuevo proceso.
Pero sucede que las personas que debían hacer todo este trabajo tienen otras asignaciones, las personas de los proyectos no tienen tiempo para discutir sobre estos temas y la fecha de entrega se acerca. Así los planes para hacer procesos útiles, valiosos y prácticos se diluyen, y se ve reemplazados por un esfuerzo para generar documentos para tapar huecos en el proceso que puedan afectar los resultados de la auditoria o assesment.
Es como esa pequeña funcionalidad implementada contra reloj que requiere que el usuario haga 3 clics adicionales en una lugar completamente inesperado, y que internamente requirió agregar el metodo CalcularInteres en la clase ConexionBaseDatos y la declaración de tres variables globales. Uno siente que un cosquilleo recorre la espina dorsal cada vez que piensa en como soluciono el problema pero es lo que se podía hacer con el tiempo disponible.
De todas maneras siempre hay tiempo para mejorar. Mientras esas mejoras llegan, uno debe lidiar con una realidad algo frustrante, muchas veces llamada madurez.
