A la hora de satisfacer las necesidades de información de la gestión de un proyecto informático podemos aplicar esfuerzo adicional (una serie de acciones para recabar esa información intercaladas en el trabajo diario) pero difícilmente logremos mantenerlo durante mucho tiempo.
Sobre todo cuando por “esfuerzo adicional” entendemos hacer una parada en el desarrollo, revolver dolorosamente viejos papeles desordenados (a veces ni eso) y rellenar agujeros de memoria para terminar garabateando con desgano un par de números más o menos dibujados en forma de informe de avance.
Una solución sistémica para esas necesidades requiere una visión más amplia y más esfuerzo inicial pero logra que la información surja naturalmente del flujo de trabajo e incluso que lo acompañe de forma tal que en lo sucesivo el esfuerzo sea menor.
Estuve jugando mucho con esa idea, enfocándola primero hacia el tema de los errores en Parches y soluciones y relacionándola después con el conocimiento que aportan a la organización (plasmado en circuitos administrativos estables), en Implementando y manteniendo soluciones.
Hoy encontré en Ideas + Ingeniería del Software (aunque llego con un poco de atraso) un artículo sobre trazabilidad que tiene mucho que ver con esto y del que me ha quedado especialmente la frase final:
“¿Moraleja? Si tienes que forzar a tu equipo a algo, la culpa no es del que no te hace caso, sino tuya. Las herramientas adecuadas para las tareas adecuadas.”
Hay que tener en cuenta que no es necesario inventar nada, la solución y las herramientas ya están ahí afuera (aunque habrá que hacer algún ajuste, eso seguro).
Al fin y al cabo son necesidades comunes a todos los equipos de desarrollo –a la gestión de cualquier proyecto-, por lo que en la práctica han surgido muchas alternativas y varias de ellas han sido formalizadas en metodologías. ¿Por qué no utilizar esa experiencia?
No hay comentarios.:
Publicar un comentario