archivo

Archivos diarios: mayo 1, 2012

Me parece muy interesante la siguiente cita del que fuera presidente y general américano Dwight David Eisenhower: “En la preparación para la batalla siempre he encontrado que los planes son inútiles, pero la planificación es indispensable”.

¿Por qué? Pues porque el establecimiento de objetivos y metas y la definición de escenarios son elementos puramente teóricos y que se pueden desmoronar cuando determinados detalles inesperados entran en escena.

La planificación es la capacidad de distribuir tus recursos y tu esfuerzo en función del escenario en que te encuentras en ese momento, de lo que has hecho hasta ahora y de lo que pretendes conseguir. No es una visión cortoplacista sino adaptativa.

El usuario va a evaluar si sus expectativas se encuentran satisfechas: que la aplicación cumpla su propósito y que su experiencia en el uso de la misma sea buena (en términos de manejo, productividad de uso y que el número y naturaleza de errores que se encuentre es reducido (o inexistente) y que no le bloquea o afecta al trabajo).

Resulta complicado que el usuario entienda, por ejemplo, que el software que has desarrollado tiene una deuda técnica baja o que el framework en el que has basado los trabajos sea el más adecuado a la naturaleza del producto que se implementado.

Como he comentado en repetidas ocasiones en el blog, si quieres que te entiendan y que tu mensaje llegue al destinatario hay que adaptar el lenguaje al interlocutor.

Si quieres que valore que tu software tiene una gran calidad técnica, enfócalo de manera diferente, no hables de deuda técnica, indícale que el software está diseñado y desarrollado para tener una rápida respuesta al cambio al menor coste posible y que cuando llegue el momento lo podrá comprobar. Una vez dicho eso y que lo entienda utilizando para ello todos los ejemplos que se te puedan ocurrir, podrás dar si lo deseas un paso más y empezar a mostrarle comparativas de diversas métricas, explicándole además en qué consiste cada una (mejor mostrar pocas y que se entiendan).

Si ese usuario o ese cliente trabaja con varios sistemas, no tardará en darse cuenta que el tuyo marca diferencias cuando se trate de continuar con la evolución del mismo.

Hasta que el usuario no interacciona con el producto software no comprueba si sus expectativas están satisfechas.

Las expectativas van más allá de una visión funcional del software ya que es absolutamente fundamental que el usuario tenga una buena experiencia de uso. Tal vez usuarios con una gran capacidad de abstracción y que hayan dedicado mucho tiempo al proyecto puedan atisbar antes de interactuar con el producto si funcionalmente les satisface, pero la experiencia de uso no se tiene hasta que se utiliza.

Por ese motivo las metodologías clásicas no terminan de producir buenos resultados, ya que entienden que es posible acertar con todo desde el análisis y que si no, ya vendrá el mantenimiento. El problema que suele producirse en estos casos es que el presupuesto de mantenimiento no existe o de existir suele ser inferior a la envergadura de los cambios que van a ser necesarios.

El feedback del usuario es fundamental desde las etapas más tempranas posibles del desarrollo, de ahí la necesidad de ir construyendo y liberando el producto de manera progresiva.