archivo

Archivo de la etiqueta: expectativas

Si el usuario no termina de tenerlo claro o nosotros no terminamos de entender o captar lo que quiere necesitamos ir puliendo la funcionalidad a través del feedback. En este caso no es recomendable huir hacia adelante y esperar al feedback tras la nueva versión del producto, ya que estaríamos ante una situación de prueba y error, alejándonos del background en el que debe basarse toda iteración: la intención.

Es una generalización, lo mismo si el desarrollo no requiere mucho esfuerzo y el ciclo es corto se puede optar por obtener el feedback tras la construcción de la funcionalidad, como digo siempre: analiza el contexto, las necesidades y decide.

Lo más recomendable en estos casos es trabajar la funcionalidad con prototipos (utilizarlos como un canal de aprendizaje) que requieran el menor esfuerzo posible ya que interesa obtener el feedback cuanto antes y seguir trabajando a partir de él.

Es importante que entendamos lo que quiere el usuario y que el propio usuario traspase a un plano más real lo que tiene en la cabeza. El prototipo no cubrirá toda la distancia entre lo abstracto y la solución final pero si se trabaja bien y el usuario muestra interés ofrece una aproximación interesante que después se puede seguir trabajando a través del feedback de las distintas versiones del producto.

Se ha hablado tanto, se ha escrito tanto, son tantos años aplicando ese esquema de trabajo, enseñando ese paradigma como el único camino para el desarrollo de software que desgraciadamente seguimos encontrando casos y casos en los que se sigue pensando que el ciclo de vida clásico o en cascada es el único camino para desarrollar software y que cualquier fisura sobre esa idea es provocada por personas que no creen que el software es un producto de ingeniería.

Me mantengo en lo que digo siempre, cada proyecto requiere su medicina y es posible que en algún caso, la estrategia más adecuada sea la cascada, si bien lo más normal es que lo más adecuado sea tender hacia un enfoque iterativo e incremental y a partir de ahí aplicar los enfoques, estrategias, actitudes, prácticas, instrumentos y herramientas más apropiadas. Pero como decía si crees que la cascada es lo mejor para el contexto del proyecto, aplícala.

Lo que no voy a compartir nunca es que la ingeniería del software está en el lado de las cascada y no existe fuera de él. No es así, es otra forma de entender el desarrollo de software más ajustada, a mi entender, a su propia naturaleza, a la propia naturaleza de los desarrollos, personas y organizaciones.

Querer capturar todos los requisitos a la primera y aceptar es muy complicado porque requiere por un lado que el usuario sea capaz de materializar en palabras una idea abstracta como la que es un producto software y por otro que el desarrollador sea capaz de captar la visión del usuario, todo ello prácticamente a la primera y que después no surjan cambios en los procesos, en la organización, en las personas o en las prioridades que echen parte o todo al traste.

Lo peor de lo que acabo de contar es que en muchas ocasiones pese a que se conoce que hay errores en las especificaciones o que es necesario realizar correcciones motivadas por cambios de contexto no se llevan a cabo las modificaciones necesarias porque ya existe un compromiso entre las partes basado en un catálogo de requisitos inicial. Generalmente no nos encontramos con situaciones de tanta inflexibilidad sino que se llegan a soluciones intermedias que no dejan de ser parches que impiden que el producto final satisfaga las expectativas que se tenían puestas en él.

Me parece muy interesante la reflexión que hace Mike Cohn sobre este tema (traducción libre): “Queremos animar al enfoque de proyectos en los que la inversión, planificación y decisión sobre las funcionalidades sean periódicamente revisados. Un proyecto que cumple con todas las especificaciones del plan inicial no tiene por qué ser necesariamente un éxito. Los usuarios y el cliente probablemente no se sentirán satisfechos cuando vean que nuevas ideas en las especificaciones han sido rechazadas en favor de otras mediocres por el simple hecho de que estaban en el plan inicial”.

Se tiene en mente que un producto equivocado es aquel que no cumple las especificaciones funcionales del área usuaria, sin embargo, podemos encontrarnos con aplicaciones que satisfaciendo eso son productos equivocados. ¿Qué cómo es posible eso? Pues todos esos sistemas que son inmanejables (mala experiencia de usuario y/o baja productividad de uso), que tienen infinidad de errores (o los suficientes para hacerlo insufrible)o que tienen otro tipo de deficiencias no funcionales relevantes.

Por eso cuando se esté definiendo un producto no solo se debe hacer desde el punto de vista funcional también hay que tener en cuenta y mucho la visión no funcional. La suma de una cosa y la otra son las expectativas del usuario (si bien hay cierta parte no funcional que no valorará, al menos, de primera mano) y todos sabemos que lo más complicado de capturar.

Me gusta mucho la siguiente cita de Mike Cohn porque refleja un riesgo real existente en todos los proyectos de desarrollo de software y que no se valora como se debiera (tal vez por el hecho de que se piensa de que siempre se va a acertar con el resultado): “El error más crítico en la mayoría de los proyectos es el riesgo de desarrollar el producto equivocado. Pese a eso este riesgo es prácticamente ignorado en la mayoría de los proyectos”.

Precisamente porque ese riesgo existe es otra de las razones que empujan a pensar que en la mayoría de los proyectos el enfoque más adecuado para su desarrollo es el iterativo e incremental a ser posible con ciclos cortos y visto desde una perspectiva ágil.

Cuando se entiende un problema es mucho más sencillo encontrar una solución simple, en caso contrario se tenderá a soluciones más complejas y/o a una mayor carga de tareas de proceso (en cualquiera de los casos se requiere mucho más esfuerzo).

Soluciones más complejas porque al no entender completamente el problema tenderemos a atacarlo por donde sabemos, descartando posibilidades más simples.

Soluciones con una mayor carga de proceso porque se espera que con ello se adquiera el conocimiento que falta y para dar una sensación de que el proyecto sigue progresando aunque eso no implique un avance real o proporcional en la comprensión del problema.

Ya sea por el incremento de la complejidad o por el aumento de la carga de proceso, nos estamos alejando del ideal de la solución más simple y cuanto más lejos estemos de él más probabilidades existen de que el proyecto no satisfaga las expectativas del usuario y se aleje del presupuesto y plazos iniciales.

Hay una reflexión de Jerry Weinberg sobre los gestores y las consecuencias de que no entiendan el problema que es perfectamente aplicable a lo que he comentado, ya que es extrapolable a cualquier perfil dentro del proyecto: “Cuando los gestores no entienden el trabajo tienden a compensarlo con la apariencia de trabajo (más horas, más papel,…)”.

El usuario, el grupo de usuarios o el Product Owner pueden tener en mente a grandes rasgos qué es lo que quieren pero lo normal es que les cueste tomar decisiones sobre el detalle e incluso no tengan clara la definición de una determinada funcionalidad.

También hay que tener en cuenta que hay usuarios más decididos que otros (lo cual no es ni bueno ni malo en sí, sino una actitud) que necesitan más tiempo para tomar las decisiones o bien necesitan pasar de lo abstracto a lo concreto para tener más claro el problema.

Al final, en uno u otros casos, es el feedback el que finalmente termina ajustando el producto a las expectativas del usuario.

Ahora bien, el feedback no es gratis ya que si se ha desarrollado una funcionalidad o un boceto de la misma, realizar modificaciones sobre la misma tiene un coste. Por eso digo siempre que las iteraciones deben realizarse con intención y que cuanta menos intención tenga y más peso tenga el prueba y error, más iteraciones se necesitarán y más coste tendrá el desarrollo.

No obstante hay que tener en cuenta un aspecto importante, hablo de coste pero es interesante verlo más como una inversión que como un gasto, porque siempre será mejor darle varias vueltas a una funcionalidad importante para dejarla conforme a las expectativas del usuario que obtener un resultado final que no sirva o no sea útil (nos hemos gastado menos dinero pero al final resulta más caro).

Si al usuario le cuesta detallar lo que quiere tendremos que apoyarnos en lo concreto y aplicar todas las técnicas que sean adecuadas para incrementar la intención de la iteración, como por ejemplo un prototipado rápido, teniendo en cuenta que será el resultado de la iteración el que le permitirá obtener un feedback de mayor valor. En estas circunstancias es fundamental que el usuario sea absolutamente consciente (y el responsable final del área usuaria) que cada evolución tiene un coste y para ello además de haberlo hablado (y escrito) antes de empezar a trabajar, es necesario que sepan cuanto les cuesta cada iteración y el saldo restante en el proyecto.

Las expectativas del usuario y la calidad del software están muy por encima de las especificaciones funcionales, por eso que el producto final termine satisfaciendo el catálogo de requisitos funcionales (por mucho que se hayan refinado) no asegura ni el éxito del producto ni su calidad final.

Si solo pensamos en requisitos funcionales estamos limitando nuestra visión sobre lo que debe ser el producto final. Cada uno puede tener una definición de lo que considera calidad del software, en la mía no es condición suficiente la verificación de los requisitos funcionales (y probablemente muchos de vosotros estéis de acuerdo conmigo). Son importantes, no digo lo contrario, pero no es lo único.

Por un lado tenemos las expectativas que, si bien podría englobar los aspectos funcionales, contiene ingredientes adicionales como son la experiencia de usuario y la productividad en el uso de la herramienta (muy ligado a la anterior).

Y por otros los requisitos no funcionales (algunos de ellos serán detectados de manera temprana por los usuarios y podrían afectar a las expectativas del usuario sobre el producto), como por ejemplo, la mantenibilidad (deuda técnica), la disponibilidad, el rendimiento, los recursos que requiere y consume, etc…

Comenta Jim Highsmith que: “Los clientes definen el valor y son los jueces de la experiencia de usuario”.

Y por supuesto que es así, al final son ellos (o los usuarios en última instancia) los que determinan si el producto cumple o no sus expectativas y las mismas no solo se centran en aspectos funcionales, sino también en términos de productividad y experiencia de usuario.

Desarrollamos software para ser utilizado por lo que es razonable que en la medida del éxito participen (el éxito tiene otros factores adicionales como por ejemplo la mantenibilidad del sistema) quienes van a ser usuarios del mismo. Es cierto que hemos podido trabajar bien, habernos dejado la piel, pero estas son las reglas.

Claro que es posible que el área usuaria (o el cliente en general) sea el principal culpable en muchísimos proyectos de que el producto final no sea bueno y no le satisfaga, pero eso no cambia la realidad y es que además de parte, también es juez en toda esta historia. Cuando esto sucede (dependiendo de muchos factores) en unos casos saldrá más perjudicado el cliente o el proveedor (no suele haber ganadores reales en estas situaciones de conflicto).