Como las características del proceso son tan importantes cuando tomamos este enfoque, es lógico que una vez adoptado el mismo, miremos con una lupa los rastros del proceso, las evidencias que el uso de procedimientos y herramientas definidas dejan en su camino. Así uno captura estos rastros, los clasifica, los guarda, los cuenta, y analiza cual es el estado actual y cómo se puede mejorar. Para la persona que analiza un proyecto de desarrollo de software desde la perspectiva del proceso, las métricas, los rastros, las evidencias son la realidad. Son estos elementos los que dibujan el perfil del proyecto, a veces saludable, a veces agonizante, a veces ordenado, a veces caótico.
Las evidencias y los rastros no surgen en la ejecución de un proyecto necesariamente como las olas vienen con el mar y las golondrinas con la primavera. Muchas veces el rastro que algo sucedió en proyecto sólo queda porque es un agregado ajeno al fin específico de una tarea. Muchas veces este rastro o evidencia se debe generar como una extensión de la actividad, variando su camino natural con el fin de otorgar información relevante para otra audiencia.
Así dadas las cosas puede suceder que un proyecto ejecute un proceso efectivamente pero que no deje rastros. Tomemos un ejemplo porque la dicusión se torna muy abstracta. Supongamos que estamos utilizando Scrum como metodología. Una práctica de Scrum es la Daily Scrum meeting:Cada equipo se junta diariamente para una reunión de estado de 15 minutos llamada Daily Scrum. Durante la reunión, el equipo explica que ha terminado desde la última reunión, que va a terminar antes de la próxima reunión, y que obstáculos tiene en su camino.Agile Software Development with Scrum por Ken Schwaber y Mike Beedle
En este contexto, el siguiente dialogo entre una persona de Proceso y una del proyecto es posible:
- ¿Dónde están las evidencias que se están reuniendo todos los días? ¿Existe alguna minuta de estas reuniones?
- No, en realidad no tomamos minutas de estas meetings.
- Entonces, ¿cómo se yo si ustedes realmente se están reuniendo tal como dice nuestro proceso?
- Podés venir cualquier día a las 9:30 que es la hora de la meeting y vas a ver que estamos todos reunidos cumpliendo con esa práctica.
- Mmm, pero no está en un documento como evidencia.
- Si querés te saco una foto de la meeting con algún miembro del equipo sosteniendo el diario del día, como hacen los secuestradores para dar una prueba de vida.
- ¿Me estas tomando el pelo?
- Por supuesto.
El punto es que las personas que prestan atención al proceso tienen un aprecio especial por la persistencia de información que para otros ojos carece de utilidad, pero a ellos le permiten dibujar esa realidad que quieren mejorar. Ellos no pueden mejorar basándose en comentarios. Hay mucho análisis cuantitativo entre sus funciones que no funcionan bien fundamentados sólo en comentarios como “Estamos bastante bien creo yo“.
Cosiderando este tipo de casos donde se ejecuta un proceso que no deja rastros, es que se comienzan a definir los pasos adicionales ajenos a una tarea para dejar esos pistas que esta gente espera. Por ej. “Todos los días se realizarán reuniones Daily Scrum y se tomarán minutas que dejan constancia de los temas tratados y la duración de la reunión.“
Esa última frase no tiene ningún sentido práctico para la persona que ejecuta la actividad, tiene sentido para la persona que observa el proyecto desde la perspectiva de las evidencias y caracteriza así el proyecto.
Esto es entendible y tiene un fin respetable. Pero no resulta fácil destinar respeto a estas tareas cuando se llaman “mejores prácticas“ livianamente a estos pasos adicionales para generar evidencia.
En el caso de las minutas de reunión, un miembro de un departamento de Calidad podría decir que es parte de las "mejores prácticas" tomar minutas de las reuniones.
No. No lo es.
De hecho, en una situación como la planteada puede ser una mala práctica.
En general, coincido con el pensamiento de James Bach:
No hay mejores practicas. Con esto quiero decir que no hay una práctica que es mejor que todas las otras posible, sin importar el contexto..No Best Practices, por James Bach
Cuando dices que algo es una "mejor práctica, puedes impresionar al principiante, o intimidar al falto de experiencia, pero solo puedes lucir tonto para las personas que creen en la posibilidad de la excelencia.
Esto puede derivar en nuevos pasos en cada actividad que parecen inútiles y sin sentido, que se hacen sin saber porque, que no tienen contenido porque se hacen siempre igual, un copy and paste constante de reglas que suponen que fuerzan una ejecución más efectiva y solo entorpecen el camino.
También es posible la variante donde se generan los rastros sin que se realice realmente lo que se debe hacer o que no refleje lo que se está haciendo. Por ejemplo, que no se hagan reuniones diarias pero que se generen minutas para que nadie se alarme y diga “¿Por qué no hacen reuniones?“. O que se generen minutas que nada tengan que ver con lo discutido en las reuniones. La esencia de una práctica es completamente cambiada por el uso y por el énfasis en la documentación.
Cada documento que se escribe, cada tarea que se realiza debe tener un objetivo, una audiencia definida. Muchas veces esta audiencia es un departamento de Calidad buscando elementos para mejorar los aspectos del desarrollo de la manera que juzgan adecuada. Y eso esta bien.
Es necesario comprender que muchas veces se requiere dar visibilidad en determinados aspectos a interesados en el proceso para poder mejorar. Necesitan que registre el tiempo asignado a tal o cual tarea. Esta bien, espero que noten en donde podemos mejorar y lo hagamos en el futuro.
Pero es bueno tener algunos puntos en cuenta para mantener cierto equilibrio: los pasos adicionales para generar evidencia adicional tienen un costo y un beneficio. Implementarlos requiere evaluar ambos. Considerar que un documento podría ser evidencia útil en el futuro, no transforma la actividad de completarlo en una “mejor práctica“.
No hay comentarios.:
Publicar un comentario