archivo

Archivos diarios: marzo 28, 2013

Yamamoto Tsunetomo fue un conocido samurai en la segunda mitad del S.XVII y las dos primeras décadas del S.XVIII. En su retiro, un joven samurai llamado Tashiro Tsuramoto transcribió las conversaciones que tuvo con él, dando lugar al Hagakure, en el que se describe por primera vez el código guerrero de los samurai.

Une reflexión sobre la intención que aparece en ese libro es la siguiente: “Si uno lanza sin vigor, siete de cada diez acciones no llegan a término”.

Me habéis leído escribir muchas veces sobre la intención, como el deseo real convertido en acciones fundamentadas que pretenden conseguir un objetivo. El fundamento de la acción viene dado por un análisis objetivo de la misma, tratando de reducir en lo posible actuaciones basadas en el prueba y error o sin suficiente conocimiento como para esperar que se obtengan los resultados esperados.

Precisamente es una de las causas principales de que un desarrollo iterativo incremental no sea efectivo, dando lugar a más iteraciones de las necesarias y a un mayor coste que si no se puede asumir puede dar lugar a que el proyecto fracase.

No se trata de tener toda la información, de tener completa seguridad de que la decisión que se toma es la correcta, porque pocas veces vamos a encontrarnos con esa situación de partida o tras un trabajo más o menos elaborado, sino de entender que tenemos más posibilidades de acertar si se han realizado las tareas y acciones oportunas que permitan elegir el camino más adecuado.

Ese es el desarrollo de la intención, antes hay que querer alcanzar el objetivo y estar dispuesto a invertir el esfuerzo que sea necesario, precisamente muchas de las decisiones que se toman en el transcurso de una reunión se quedan en nada, solo en palabras, debido a que parece que la energía se queda en la mesa una vez que todos (o por lo menos, los que tienen que desarrollar las acciones) se levantan de la mesa.

Uno de los problemas que nos podemos encontrar con frecuencia en un proyecto de desarrollo de software lo tenemos cuando el desarrollador piensa que sabe tanto del negocio como los usuarios y se olvida de que el producto no es para él sino para los usuarios.

Que un desarrollador conozca el negocio muy bien es algo muy interesante para el proyecto siempre y cuando no se caiga en el error de empezar a tomar decisiones sobre lo que le gustaría a él que hiciera el producto sin contar con la aprobación del usuario.

Siempre hay que contar con los usuarios. Un producto desarrollado a sus espaldas difícilmente se ajustará a sus necesidades reales. Generalmente cuando esto sucede es por culpa del área usuaria que se niega a dedicar al proyecto los recursos que son necesarios, dejando todo el peso a los desarrolladores. Esta situación es necesario revertirla cuanto antes y en caso contrario intentar cerrar el proyecto con el menor daño posible entre las partes, si bien, no siempre será posible una cosa o la otra porque el nivel de toma de decisiones al respecto se situará en otra escala de la organización que tendrán sus propias políticas y criterios.

Si contamos con la ayuda y dedicación del usuario y sin embargo tomamos decisiones funcionales por él, estamos cometiendo un grave error.

Al respecto me parece interesante la siguiente reflexión de Donald Norman: “Los diseñadores no son usuarios típicos. Llegan a ser tan expertos en el uso de los objetos que se han diseñado que no pueden creer que alguien más pueda tener problemas. Sólo la interacción y pruebas con usuarios reales en todo el proceso de diseño puede evitar eso”.