En Por dónde comenzar, hablando de gestión de requerimientos, Improbable ha dado a luz un párrafo genial que le da de lleno a mi falta de paciencia para con el área de análisis funcional (por lo menos con la que me toca convivir). Dice:
[…] recuerdo los valores ágiles de responsabilidad, honestidad, y demás virtudes. Pero ocurre que la gente es gente, y cuando las papas queman y alguien pregunta por determinados retrabajos o por qué se ha invertido seiscientas horas de desarrollo en algo que debería haber tardado doscientas, no es descabellado esperar que quien nos ha guiado a través de un camino sinuoso intente endilgarle la responsabilidad a otro. Quiero decir: que un Product Owner que nos ha hecho trabajar y retrabajar haciendo una cosa y luego la contraria continuamente intente explicar el poco valor conseguido luego de un tiempo considerable hablando de la falta de habilidades técnicas de los programadores.
#define evil_mode=1;
Pocas cosas son más molestas que cuando, sin haber cometido ninguna falta –condición más que fundamental para lo que sigue-, la gente se preocupa más por cubrirse que por hacer el trabajo, con actitudes como cambios que no se pasan por escrito, horas que se distribuyen entre otras tareas para ocultar retrabajos, olvidos sugerentes y demás.
Y es porque me da la sensación de que esto genera espejismos hacia la gestión del proyecto, que a falta –razonable y esperable- de conocimientos técnicos se guía por la percepción del desarrollo que nosotros exponemos, acumulada en forma de experiencia. Espejismos que luego nos juegan en contra.
Así, si nos “da vergüenza” pasar una semana con una funcionalidad que parece trivial y para la que estimamos dos horas, y en vez de poner el esfuerzo en explicar lo sucedido distribuimos esas horas en otras tareas, estamos fortaleciendo la imagen, por ejemplo, de que somos buenos estimando y de que lo que parece fácil es fácil. Estamos fijando un piso que difícilmente podamos mantener.
Pero una cosa es “distribuir horas” y otra es tirar la basura al patio del vecino (como describe el párrafo citado), siendo más conveniente (aunque harto más difícil) explicar a la gestión que los requerimientos no eran claros y que por presiones de tiempo se comenzó a programar lo antes posible, por lo que buena parte del tiempo de desarrollo fue en realidad tiempo de aprendizaje, prueba y error, ajuste y corrección sobre la marcha… una situación que simplemente se dio así y que no tiene nada de malo per sé…
…a menos que creamos que no somos tan buenos como deberíamos en lo que hacemos.
#define evil_mode = 0;
No hay comentarios.:
Publicar un comentario