archivo

Archivo de la etiqueta: usuario

Comenta Pete McBreen que: “Con un ciclo corto de feedback es fácil aprender qué funciona y qué no”.

Los usuarios no tienen claro que es lo que quieren hasta fases muy avanzadas del proyecto. Al principio del mismo tienen ideas generales (por mucho que digan que lo tienen clarísimo ya que una cosa es la teoría y otra la realidad) relacionadas con el problema que quiere solucionar o con el proceso que quiere informatizar.

Si esperamos demasiado, si el paso a producción se eterniza o si el usuario no tiene posibilidad de trabajar con el sistema que se está desarrollando nos encontraremos con que su feedback vendrá muy tarde precisamente cuando el presupuesto esté prácticamente agotado y cuando el coste el cambio sea importante. No me invento nada, lo hemos vivido (y vivimos) prácticamente todos.

Hay que intentar conseguir ese feedback cuanto antes, tiene más intención si el sistema está en producción (aunque sea solo con una parte del sistema en funcionamiento) ya que ahí se puede apreciar el impacto real que tiene en el negocio, es decir, se puede ver qué ha funcionado y qué no.

Si son necesarias varias iteraciones para tener pasar el producto a producción (aunque sea parcialmente) utilicemos otras estrategias (que requerirán una colaboración y un compromiso fuerte del usuario) para obtener ese feedback al final de cada iteración.

En los enfoques clásicos los cambios tardíos en los requisitos suponen un golpe muy duro al proyecto porque suelen llegar cuando se están mostrando los avances en la construcción del proyecto, en las pruebas de aceptación o con el sistema en producción.

Ese feedback dará lugar a nuevas peticiones de cambio por parte del usuario ya advertirán aspectos que no han tenido en cuenta, otros que son mejorables y otros que son incorrectos (ya sea por una mala especificación del usuario, por una mala interpretación de la misma por parte del desarrollador o por una mala ejecución de los trabajos). Como el desarrollo del producto está tan avanzado el coste de estos ajustes será importante en muchos casos, sobre todo si se plantean cambios severos en el núcleo de la aplicación (teniendo en cuenta que la deuda técnica va creciendo conforme crece el tamaño del producto).

En otras palabras, que te cambien los requisitos tarde es un marrón y lo peor de todo es cuando esto sucede en un enfoque predictivo como el clásico en el que teóricamente se espera que esto no suceda (aunque hasta el mayor defensor a ultranza de los enfoques clásicos sepa que esto va a pasar) y en donde resultará complicado hacer ajustes en el presupuesto (algo que habría que hacer cuando los cambios no sean motivados por fallos o negligencia del desarrollador).

¿Es un marrón en un enfoque de carácter evolutivo? No puedo decir que este enfoque sea a prueba de cambios porque no lo es. Si pese a que se ha seguido un desarrollo iterativo incremental en donde el usuario ha aportado su feedback desde etapas tempranas resulta que en fases muy tardías hay cambios severos en el proceso o procesos que se implementan o se descubre que el usuario ha sido negligente te revienta el proyecto, quieras o no, y darle la vuelta al calcetín resulta complicado cuando no imposible si no se ajusta el presupuesto y se resuelven determinados problemas que han dado lugar a esta situación (por ejemplo si el usuario ha sido negligente será necesaria su sustitución).

Partamos de la base de que los cambios son ajustes, unos más grandes que otros pero moderados, y que el objetivo es, como no podría ser de otra manera, desarrollar un producto de calidad que satisfaga las expectativas del usuario, si el usuario detecta que es necesario hacer cambios sobre un producto maduro (incluso con varias iteraciones en producción) se hacen, recordemos que no desarrollamos para nosotros sino que desarrollamos para el usuario y él sabe mejor que nadie qué es lo que necesita y más en estas etapas donde ya están trabajando sobre algo real y en producción.

Lo complicado de esto es que el usuario entienda que todo ajuste tiene un coste, ahí es donde se sustancia el problema, en querer que con un presupuesto inicial realizado desde la más absoluta incertidumbre y con gran desconocimiento del resultado final del producto se cubra todo el trabajo. Si se supera esa resistencia, bienvenidos sean los cambios siempre que los mismos den lugar a una mejor versión de la aplicación.

Caso particular del antipatrón “Trampas evitables” y consecuencia en muchas ocasiones de “Al servicio de Pareto“.

A veces por exceso de optimismo y otras por presiones del área usuaria, del cliente o de tus jefes, se tiende a mencionar la fatídica frase del: “Esto está casi”, cuando realmente no es esa la realidad.

No olvidemos que la curva de progreso en el proyecto es pronunciada al principio pero que el final se tuerce mucho porque es necesario alinear todos los detalles para poder hacer una entrega en condiciones y sabemos lo complicado que resulta (hablo de hacer una entrega con garantías no de entregar por entregar).

En el momento en que pronuncias “Esto está casi”, estás generando una expectativa (y mucho peso). Cuidado con eso, ya que es absolutamente necesario hacer una buena gestión de las mismas, de lo contrario se pierde confianza y credibilidad, que son piezas fundamentales en las relaciones entre los diferentes implicados que participan en el proyecto.

No digo que no se deba ser transparente, al contrario, si no lo eres te estás equivocando, lo que sí estoy comentando es que hay que ser prudente y medir bien qué se dice, a quién se dice y en qué momento.

Llegado un momento se toma la decisión de hacer una nueva versión de un sistema de información porque se entiende que está obsoleto tecnológicamente (resulta complicado encontrar desarrolladores para ese lenguaje de programación, el sistema de gestión de base de datos o el servidor de aplicaciones ha quedado sin soporte, etc…) o porque el coste de mantenimiento es muy alto y es necesario hacer modificaciones sobre funcionalidades ya existentes o el desarrollo de otras nuevas, etc…

Ese producto de partida conseguía su propósito y era utilizado de manera productiva por los usuarios y por la organización (lo cual no quiere decir que todo su camino para llegar a esa situación fuera sencillo o que nunca hubiera problemas).

Este antipatrón surge cuando se quiere aprovechar el nuevo sistema para incluir todas (muchas) las “cartas a los Reyes Magos” que usuarios, gestores y desarrolladores habían estado guardando todos estos años (más otras que se le ocurran sobre la marcha).

Una mala selección de las mismas dará lugar a un nuevo sistema que habrá sobrepasado con creces el presupuesto de partida, sin que exista un incremento de valor proporcional, mucho más grande que el que realmente se necesita, igual o más complejo de mantener que el anterior, en el que que tendrá problemas a la hora de implantarse porque será mucho más difícil de utilizar y administrar y con una más que probable importante tasa de errores y deficiencias funcionales de partida.

Arreglar esta situación es muy complicado, en algunos casos casi que lo más recomendable es empezar de nuevo.

A todo esto hay que añadir que el sistema anterior pesará como una losa sobre los desarrolladores porque los usuarios (los del día a día, más que aquellos que han intervenido en la definición de la nueva versión) siempre lo tendrán como referencia y lo estarán comparando continuamente y además, y sobre todo, los gestores verán como procesos que antes se desarrollaban de manera eficiente ahora cuesta más trabajo hacerlos, con el consiguiente coste económico que eso tiene, y pedirán cuentas por no tener un retorno de la inversión a la altura del desembolso realizado. Todo esto creará una situación de presión y unas prisas que poco bien harán para la mejora paulatina del sistema.

El término “Efecto segundo sistema” fue utilizado por primera vez por Frederick Brooks en su libro “The Mythical Man-Month”.

Es un caso específico del antipatrón “desfactorización“.

Puestos a priorizar, los usuarios querrán que se desarrolle primero las funcionalidades principales del sistema, dejando al desarrollo de las pantallas de administración (algunas simples, otras más complejas) para más adelante porque siempre existe la posibilidad de precargar los valores en base de datos y porque no se prevé que el grado de actualización sea elevado.

Por otro lado, los usuarios querrán flexibilidad y autonomía, de manera que no tengan que acudir a un desarrollador para modificar ciertos aspectos de funcionamiento e incluso comportamiento del sistema. Esta situación hace que proliferen más funciones de administración.

Tenemos una paradoja: los usuarios quieren ser autosuficientes y sin embargo no priorizan el desarrollo de pantallas que les permitan esta posibilidad.

Como siempre existirán funcionalidades que evolucionar u otras que implementar, estas pantallas siempre serán candidatas a quedarse fuera en cada sprint. Llegado el momento el presupuesto se agotará y la mayoría de ellas seguirán sin implementarse y se tendrá que recurrir al departamento TIC para que gestione la administración de esas aplicaciones trabajando directamente contra la base de datos, responsabilidad ésta que no debería recaer sobre ese departamento sino en el área usuaria, la cual a su vez se quejará de los tiempos de respuesta por parte de informática y por no poder ser ellos mismos quienes lo gestionen.

Los responsables técnicos del proyecto por parte del departamento TIC deben dejar claro al usuario que estas pantallas deben desarrollarse, que elijan el momento que consideren más adecuado, pero que finalmente tienen que construirse porque es su competencia y responsabilidad administrar la aplicación desde el punto de vista funcional y que la dependencia de informática en ese sentido solo debe y puede ser transitoria.

La mejor forma de gestionar expectativas es poniendo todas las cartas sobre la mesa y contar la realidad, guste o no guste lo que hay que decir. Un proyecto de desarrollo de software es dinámico y está sujeto a incertidumbre por lo que cada poco tiempo es necesario actualizar las expectativas en función del contexto y de las contingencias que hayan podido ocurrir.

Este antipatrón se produce cuando quien gestiona las expectativas se guarda ases en la manga. Un caso muy común es exponer un estado de avance del proyecto o una situación más pesimista que la real, preparando de esta forma a la otra parte en el caso de que no se cumplan los compromisos.

¿Cuál es el inconveniente? La otra parte (usuarios, responsable técnico del cliente, etc…) puede tomar decisiones en base a una información que no es del todo cierta, así como trasladar la misma a terceras personas y así convertirse en cómplice accidental de este antipatrón.

Cuando se aplica de forma sistemática este antipatrón, los afectados (usuarios) terminan por modular sus expectativas de manera que si te dicen que lo mismo no se llega es que se llega y que si los desarrollos van mal es que van regular. El problema es que cuando se termine diciendo la verdad, se produzca un desgaste fuerte con el usuario porque tendrán las expectativas altas como consecuencia de haber modulado la información recibida.

Existen muchas formas de modelar la realidad, todas ellas válidas. Sin embargo el hecho de que sea válida no quiere decir que el modelo de datos sea bueno.

Un modelo de datos más complejo de lo necesario será a la larga una fuente de problemas porque aunque esté escondido en las capas más profundas de la aplicación condiciona sin lugar a dudas todo lo demás.

A veces el modelo lo hace complejo el desarrollador, otras muchas veces el usuario que pretende almacenar información o relacionar entidades que después no va a poder mantener. Es conveniente hacerle ver al usuario si efectivamente esa complejidad adicional que va a introducir le va a aportar algún valor y si incluso aportándole van a tener recursos suficientes para mantener los datos actualizados y con calidad.

El desarrollo de software requiere cooperación e interacción, no se trata en este caso de contaminar al usuario sino de hacerle reflexionar sobre la situación, a veces una segunda o tercera pensada evita malgastar esfuerzos presentes y futuros.

Los modelos de datos deben ser lo más simples posibles sin que se pierda información que el usuario necesita (realmete) para su gestión. Si hay que dedicar algo más de tiempo en él es una inversión que al final será amortizada.