archivo

Archivos diarios: abril 24, 2014

Contra esta situación no hay metodología o estrategia que la resista, sin buenas especificaciones el producto final se encontrará lejos de las expectativas del usuario, sin colaboración efectiva de un responsable del producto por parte del área usuaria no habrá un buen feedback ni una buena priorización en la línea de desarrollo de la aplicación, sin un usuario que esté accesible se producirán fases de bloqueo en el proyecto que en muchos casos (la mayoría) solo se resolverán tirando hacia adelante.

Y no es que no puedas hacer un buen análisis, ni siquiera vas a poder hacer una buena definición de sprint. ¿Qué pasa al final? El presupuesto se ha esfumado y el producto está todavía a medias o no hace lo que el usuario quiere, esto es igual a mucho desgaste y a pérdidas de dinero por ambas partes.

Es cierto que los desarrolladores hemos hecho mucho daño al negocio del desarrollo de software pero las personas que se han designado como responsables del producto por parte de los clientes también.

Y este problema lo tenemos tanto en enfoques clásicos como en enfoques ágiles de desarrollo de software porque en ambos casos necesitamos al usuario.

Un proyecto de desarrollo de software requiere que los responsables del producto estén muy implicados y con una alta dedicación al mismo, si la persona designada no puede dedicar ese tiempo necesario lo mejor es que delegue el día a día en otra persona dándole autonomía para la toma de decisiones (independientemente de que determinadas cuestiones las deba consultar).

Si no es posible de ninguna forma asegurar esa dedicación habría que pensarse muy seriamente por ambas partes si merece la pena afrontar el trabajo y si por el motivo que fuera se tuviera que llevar a cabo habría que explicar muy claramente los riesgos y las consecuencias de esta incertidumbre y falta de implicación en los costes finales.