archivo

Archivo de la etiqueta: análisis

Como comenté en el antipatrón “Escuela de traductores” se espera por parte del proveedor que aporte valor a la solución, no por su cuenta, sino enriqueciendo las soluciones que especifican desde el área funcional, así como asesorando, mirando por los intereses del cliente (por encima de los suyos propios).

Se nota mucho cuando un equipo de proyecto incurre en ese antipatrón, un caso concreto lo tenemos en aquellos casos donde los requisitos recogidos no proporcionen una especificación completa de una determinada funcionalidad, donde las culpas siempre se dirigirán al usuario, aunque sean de materias de preescolar de programación o de análisis funcional.

Ahí es donde está la diferencia entre “equipos grandes” y “equipos pequeños” en el desarrollo de software, entre ser de primera división o de tercera, ¿con quién prefieres trabajar tu?.

Es más, es posible que el que conozcas o que el que se defina en un análisis de un sistema de información no te lleve a ella. Es más, es posible que tengas que coger diferentes rutas para alcanzarla, que muchas de ellas se descubran por el camino, que incluso tengas que desandar parte de lo avanzado o que tal vez, tengas que conformarte con un objetivo más acorde al contexto en que se ha desarrollado el proyecto. Y en otras muchas ocasiones te termines quedando en el camino.

Eso es el desarrollo de software, saber a dónde se quiere ir, aceptar la incertidumbre y estar lo más preparado posible para adaptarse al cambio y que dicha adaptación requiera el menor esfuerzo posible.

En estos caminos habrá obstáculos, eso es seguro, unos serán sorteables (no sin esfuerzo), a veces nos encontraremos con otros que obligarán a abandonar parte del equipaje y no podremos llegar tan lejos como quisiéramos y en otros los obstáculos no nos permitirán llegar siquiera a un destino aceptable o nos dejarán tirados en medio del camino o de la nada.

Así es el desarrollo de software.

No contar con los interlocutores adecuados es una causa muy común de fracaso en un proyecto de desarrollo de software.

Entre los principales errores que se suelen cometer en este sentido se encuentra la selección de interlocutores que no participan en el día a día de la ejecución de un proceso. Esto normalmente lleva a soluciones que están alejadas de las necesidades reales de los usuarios reales del sistema de información.

¿Y si se quiere aprovechar el nuevo sistema para hacer cambios en el proceso? Mi consejo es que esos cambios se realicen siempre que sea posible antes de que la aplicación se haya puesto en marcha, recordemos el mantra de que “la informática y el software no resuelven problemas organizativos” y que en el caso de que sea a la vez, todo el mundo tenga muy claro previamente la dirección a la que nos dirigimos.

En cualquier caso, con cambio de proceso o sin cambio de proceso, en la definición de las funcionalidades de un sistema de información, así como para la transmisión de las expectativas en relación a la experiencia de usuario tienen que intervenir representantes de los que van a utilizar el sistema de manera cotidiana, sin que ello suponga restricción alguna a que puedan intervenir, incluso coordinando todas las consultas a las diferentes áreas usuarias, personas que tengan un perfil orientado más a la gestión, es más, alguien al final tendrá que resolver posibles situaciones de conflicto en cuanto a la visión de los procesos y establecer prioridades, lo que hará necesario a que de manera directa o delegada tenga la suficiente autoridad para hacerlo.

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.

Lo he vivido ya en más de una ocasión y lo he sufrido no durante semanas, sino meses y en algún caso hasta años.

Poner en marcha un sistema de información en su totalidad o en gran parte sin que ningún usuario lo haya utilizado en un entorno o contexto real es una condena para el propio sistema de información y para quienes lo gestionan.

Llegarán peticiones de mejora e incidencias superiores a la capacidad que se tendrá para dar respuesta (si es que dispones de esa capacidad, ya que pocas veces se prevé que lo que se desarrolla hay que mantenerlo, de hecho los responsables o directores funcionales del sistema es lo que pensarán si no se les explica de manera adecuada y con carácter previo qué es un desarrollo de software y qué consecuencias tiene los cambios en las especificaciones sobre el coste del proyecto) y la puesta en marcha del sistema se convertirá en una cuesta arriba que no parece tener fin a la vez que no termina de aflojar su pendiente.

Es la consecuencia de la aplicación de metodologías clásicas y del efecto bola de cristal donde se piensa que todo lo definido hace meses (cuando no años) por personas que lo mismo ya no trabajan en la organización o están en otro departamento sigue siendo válido cuando se pone en marcha el sistema. Esto sucederá en la mayoría de los casos incluso habiendo realizado un análisis muy riguroso (en todo caso, la calidad del análisis reducirá los problemas, algo que, sin duda, se agradece, pero que no resuelve el problema de fondo).

Los enfoques clásicos se basan en una especificación detallada de requisitos para, a partir de la misma, proceder al desarrollo del producto, de manera que la relación con los usuarios es más intensa en ese momento y vuelve a recobrar importancia cuando se acerca la implantación del sistema.

Mientras tanto, habrá reuniones de seguimiento para informar al área usuaria del estado del proyecto, en las que se podrían mostrar incluso funcionalidades del producto ya implementadas. Estas reuniones sirven sobre todo para mantener tranquilo al cliente, ya que el tiempo que transcurre entre el análisis y la entrega puede ser significativo.

Esta estrategia de desarrollo supone que las especificaciones se van a mantener estables durante el proceso de construcción.

Ahí acaba la teoría porque todos sabemos lo que pasa en estos casos: los requisitos permanecen abiertos hasta el final porque el usuario se irá dando cuenta de funcionalidades que no ha descrito de manera adecuada o de nuevos módulos que quiere incorporar al sistema.

Por tanto, se ha realizado un esfuerzo importante en tener unos requisitos al detalle y lo normal es que más adelante un buen número de los mismos se tengan que redefinir. Ojalá el problema solo fuera ese, ya que el principal es que en muchos casos, estos cambios se solicitan demasiado tarde, cuando buena parte del producto ya está construido, por lo que el coste de hacer las modificaciones suele ser importante.

Y ahí es donde entran en conflicto desarrolladores y área usuaria porque los segundos entienden de manera equivocada y por regla general, que los cambios son de escasa entidad y que el proveedor debe soportarlos.

Las estrategias, enfoques y metodologías ágiles parten de la visión del producto, de tal forma que no es necesario tenerlo especificado al detalle sino de tener presente qué se tiene y a dónde se quiere ir. En este contexto, solo es necesario tener especificada la materia prima de la siguiente iteración (aunque normalmente se trabaja mirando un poco más hacia adelante).

Por tanto, no se define el sistema por completo, sino que vamos trabajando con las funcionalidades más prioritarias (sin perder la visión del producto) y al final de cada sprint se obtiene el feedback del usuario que le permitirá ir haciendo ajustes sobre lo definido.

De esta forma, se hace el esfuerzo que necesita el sistema, no requiere esos largos períodos de análisis que terminan en documentación en donde buena parte de ella no termina ajustándose al producto final (salvo que se haya hecho el esfuerzo considerable de ir actualizándola). Y no solo eso, permite incrementar el valor del producto conforme se desarrolla, a diferencia del enfoque clásico que limita el valor (teóricamente) al que existe en el momento en que se aprueba el análisis.

Comenta Jay Elliot en el libro “El camino de Steve Jobs” que gran parte de la culpa de los fracasos o errores que tuvo Steve Jobs a lo largo de su trayectoria profesional fueron debidos a su creencia de que era infalible.

Precisamente uno de los mayores riesgos del éxito es creerse que uno es infalible y que ha encontrado las recetas para todo.

Creernos infalibles afecta a nuestra capacidad de análisis de las situaciones (total, ya sabemos la respuesta de todo), a nuestra capacidad de análisis del riesgo (total, no nos vamos a equivocar) y a nuestra capacidad de escuchar.

Conozco a mucha gente que se dedica al desarrollo de software, muchos de ellos excepcionales profesionales y con una gran aptitud y actitud, sin embargo no conozco a nadie que sea infalible, por eso si en algún momento te lo llegas a creer, te aconsejo que adquieras un enfoque más humilde.

Ser infalible en el desarrollo de software implica, entre otros muchísimos factores, dominar la incertidumbre y eso no se puede conseguir.