archivo

Archivo de la etiqueta: usuarios

La iteración favorece la evolución del producto. Mediante el feedback tratamos de aproximarnos cada vez más a la solución que satisfaga las expectativas del usuario, por tanto, en cada iteración se le trata de dar un mayor valor al producto.

En un enfoque clásico o predictivo el feedback se obtiene principalmente en la fase de análisis cuando el producto sigue siendo una idea abstracta en la que se pueden imaginar sus formas pero donde la mayor parte del mismo está cubierto por niebla. Después se pueden realizar ajustes, claro que sí, pero no con agilidad ya que en este tipo de enfoques tiene especial importancia el cumplimiento de la agenda establecida: costes y plazos.

El feedback continuo favorece la evolución del producto de manera que teóricamente en cada iteración vamos adaptando las características del producto al contexto existente y a las expectativas que se tienen puestas en él. Cuanto más real sea el entorno en que se realiza el feedback, cuanto más cerca esté el usuario del producto con mayor intención se realizará la siguiente iteración y más efectivo será el resultado.

Es razonable pensar, por tanto, que en un contexto de evolución rápida del producto existirán más posibilidades de que el mismo tenga éxito.

Hablo de posibilidades, la realidad es otra cosa porque el éxito no se consigue a través del proceso (en este caso iteraciones más o menos frecuentes) sino a través de la correcta y adecuada ejecución de las acciones en el proyecto.

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.

No hay mejor formar de gestionar las expectativas del área funcional o del cliente que evitando las sorpresas. Es como jugar a las cartas conociendo las del resto de jugadores y eso debería ser un proyecto de desarrollo de software, un conjunto de personas, equipos y organizaciones que trabajan con respecto a los demás de forma transparente (y esto es perfectamente compatible con los intereses particulares o de empresa que puedan existir).

En los proyectos en los que trabajo tengo como objetivo minimizar las sorpresas, gestionando de esta forma las expectativas del área usuaria desde el mismo momento en que puede haber un cambio en las mismas. Casi nunca gusta que acortes alcances pero te aseguro que es mucho mejor negociar en esas circunstancias que cuando, sin margen de reacción, no cumples los compromisos con el usuario.

La confianza es fundamental en el desarrollo de software y más en proyectos con la intensidad que requieren los enfoques iterativos incrementales, por ese motivo es absolutamente necesario gestionar las expectativas, modularlas a la realidad del proyecto.

Ocultar el estado real del proyecto o de un sprint no sirve para nada porque al final, más pronto o más tarde se termina descubriendo el pastel, tal vez todo salga a la luz después de haber terminado los trabajos, pero esa huida hacia adelante termina pasando factura si quieres volver a seguir trabajando con ese cliente.

Comenta Mary Poppendieck que: “Si quieres saber lo que el cliente quiere, dale lo que crees que quieren y escucha lo que te tienen que decir al respecto”.

Esa es la esencia del feedback: el usuario da una especificación, ejecutas según la interpretación que has hecho de la misma, obtienes un resultado y el usuario opina sobre el mismo, solicitando aquellos ajustes que consideres necesario.

En el caso de que desarrolles un producto y no te bases en especificaciones directas, el proceso es el mismo.

Recuerda que el sistema que desarrollas no es para ti. Tal vez las decisiones del usuario no te gusten, tal vez pienses que hay otras soluciones más adecuadas, si es así, exponlas, porque lo mismo ese punto de vista no se ha tenido en cuenta, pero no las impongas o manipules para que ese sea el camino elegido. Todos tenemos derecho a equivocarnos, pero más quien paga.

El objetivo es incrementar el valor del producto y la mejor forma de hacerlo es centrarnos en quiénes van a ser sus usuarios porque son ellos los que van a tener que convivir con él todos los días.

La siguiente cita de Bertrand Meyer puede crear algo de controversia (traducción libre): “Que esté correcto es claramente la primera calidad. Si un sistema no hace lo que se supone que debe hacer, entonces todo lo demás importa poco”.

¿Por qué digo que es controvertida? Si se entiende a partir de ella que el fin último es satisfacer las necesidades de los usuarios a través de un producto que se aproxime a lo que estaban esperando y que para eso todo vale, puede considerarse como polémica porque la calidad del software va más allá de eso, es más, probablemente sin esos otros ingredientes resulta mucho más complicado conseguir ese objetivo.

De hecho, si en el software se va acumulando tanta deuda técnica que hace prácticamente inmanejables las tareas de evolución del producto, tenemos un problema importante porque si bien se ha podido conseguir un producto del que estén satisfecho los usuarios, es posible que esa satisfacción sea efímera porque lo más probable es que el producto tenga que modificarse en un futuro, sea a corto, medio o largo plazo y si como consecuencia de las dificultades para adaptar el sistema al cambio no es posible en forma y/o en tiempo (y/o en la cantidad de dinero que es posible invertir), el éxito inicial se habrá convertido en un espejismo.

Como es lógico, Bertrand Meyer pone sobre la mesa algo muy importante y que los desarrolladores a veces perdemos de vista y es que, por regla general, desarrollamos un software para que lo utilice un tercero y no para:

– Seguir procesos por el simple hecho de seguirlos, sin tener en cuenta la realidad y contexto del proyecto y producto en el que estamos trabajando.

– Seguir determinadas técnicas que pudiendo ser beneficiosas no resultan prácticas para este proyecto concreto.

– Ponernos a hacer experimentos que si no tienen como fin obtener un aprendizaje que permita dar un mayor valor al producto directa o indirectamente, se deberían evitar.

El método MoSCoW es una técnica de priorización de requisitos basada en el hecho de que aunque todos los requisitos se consideren importantes es fundamental destacar aquellos que permiten darle un mayor valor al sistema, lo que permite enfocar los trabajos de manera más eficiente.

Lo que la diferencia de otras técnicas tradicionales como por ejemplo calificar los requisitos como de prioridad alta, media o baja es que en este caso la escala utilizada tiene un significado intrínseco, de manera que el usuario responsable de asignar la prioridad conoce el efecto real que producirá su elección.

M (Must): Requisito que tiene que estar implementado en la versión final del producto para que la misma pueda ser considerada un éxito.

S (Should): Requisito de alta prioridad que en la medida de lo posible debería ser incluido en la solución final, pero que llegado el momento y si fuera necesario, podría ser prescindible si hubiera alguna causa que lo justificara.

C (Could): Requisito deseable pero no necesario, se implementaría si hubiera posibilidades presupuestarias y temporales.

W (Won’t): Hace referencia a requisitos que están descartados de momento pero que en un futuro podrían ser tenidos de nuevo en cuenta y ser reclasificados en una de las categorías anteriores.

Esta clasificación puede ser modificada durante el proceso de desarrollo y definirse, en el caso de desarrollos iterativos incrementales, prioridades a nivel de iteración.

No digo nada nuevo si os comento que las mejores especificaciones de los usuarios van surgiendo conforme se va avanzando en el proyecto y se les empieza a despejar la niebla que se extiende por su visión de lo que debe ser el sistema de información.

En un enfoque clásico, pretender acertar desde una fase de análisis que se encuentra muy lejos del momento en que se va a poner el producto en producción es casi una quimera por mucho que se haya trabajado con prototipos y los desarrolladores conozcan bien al negocio y a los usuarios.

¿Cómo mantener una agenda de plazos y presupuesto si me cambian los requisitos? No se puede salvo que termines reventando al equipo y/o recortando el alcance (y calidad) del sistema de información y aún así probablemente te termines desviando en ambos.

Si nos quedamos con las especificaciones iniciales no se puede esperar un producto con un mayor valor que el que nos ofrecen las mismas porque estamos limitando el valor al no permitir cambios propiciados por el feedback usuario.

Por tanto, no solo nos estamos encontrando con una estrategia de desarrollo de software que se aleja de la realidad de los proyectos sino que, además, su orientación a la agenda, ofrece menos flexibilidad para incorporar valor al producto a lo largo del proceso de desarrollo.