archivo

Archivo de la etiqueta: análisis del sistema de información

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.

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.

Incluso en aquellos proyectos donde más complicado puede resultar la aplicación de principios ágiles siempre existen oportunidades en donde podremos aplicarlos, si bien su efectividad dependerá mucho del contexto del proyecto, la metodología aplicada y los procesos en torno a los cuales se realiza el desarrollo de un software para una organización.

Independientemente de la metodología que se aplique resulta de gran importancia la participación activa de los interlocutores, sin eso, en el mejor de los casos el proyecto irá a trompicones y en los peores la especificación de requisitos se encontrará llena de huecos que en unos casos tendrán reflejo directo en el producto final y en otros serán cubiertos por el propio equipo de desarrollo, en base a su interpretación del proceso que se informatiza y de la experiencia precia.

El problema en esos últimos casos es que incluso acertando en una solución aceptable, la misma no tiene por qué coincidir realmente con lo que el usuario quiere y además, siempre tendrá la oportunidad de decirte que quién te ha comentado a ti que hayas optado por hacerlo de esa manera.

Sí, lo has hecho de buena fe, lo has hecho pensando en lo mejor para el proyecto y para el usuario, pero después te encontrarás con determinados individuos que cargarán contra ti su propia irresponsabilidad y lo peor de todo, tendrás pocos argumentos de defensa más allá de reprochar su falta de implicación en el proyecto, la cual negará o minimizará, quedando ante personal directivo la palabra de uno contra la de otro y con unas funcionalidades en el desarrollo que no puedes justificar su origen.

Se dice que en contextos donde va a resultar complicado encontrar agilidad en la interlocución no es posible aplicar metodologías ágiles, vale, pero, ¿acaso sirve cualquier otra metodología?, ¿acaso esa otra metodología puede garantizar mejores resultados?, ¿acaso va a conseguir que los interlocutores participen más y mejor?.

Se podría responder que puede ser más sencillo conseguir un compromiso por parte de los interlocutores si se les dice que su participación se reducirá a un espacio concreto de tiempo, es decir, lo que dure el análisis.

Si el usuario no es bueno, hasta lo anterior será complicado de conseguir, pero incluso en el caso de que se logre, estaremos dejando el proyecto a merced de que se haya acertado en los requisitos y a todos los inconvenientes que tras de sí tiene el ciclo de vida en cascada.

Por tanto, independientemente de la metodología o enfoque a utilizar, siempre hay que solicitar y exigir la participación del área usuaria.

Aceptar un contexto en el que no exista agilidad en la interlocución por parte del usuario debe ser la última vía. Incluso si se aprecia que puede existir hostilidad en los mismos, lo mejor para todos es no abordar el proyecto.

En el caso de que se acepte el proyecto tenemos que adaptarnos a las circunstancias y resulta a priori complicado indicar si la mejor solución pasa por un enfoque ágil o clásico, será necesario evaluar el contexto y en base a eso tomar una decisión.

Defiendo absolutamente la posibilidad de que en una organización se pueda progresar horizontalmente de manera que técnicos que disfruten con la programación y con la ingeniería del software puedan tener la oportunidad de conseguir mejores condiciones laborales si su desempeño, experiencia y conocimientos les hace merecedores de ello.

Lo anterior es absolutamente compatible con una carrera profesional de índole más técnica orientada a la arquitectura del software.

Es posible que a un programador solo lo puedas vender dentro de un umbral precio/hora (es el reverso tenebroso de los proyectos tipo taxímetro o bolsa de horas), pero en proyectos donde prestas un servicio tener a desarrolladores altamente cualificados, motivados y productivos puede ser la diferencia entre ganar o perder dinero.

Un apunte: No hablo de sobredimensionar la cualificación de los equipos, ya que eso puede jugar incluso en contra del proyecto ya que puede provocar en algunos casos (proyectos de complejidad medio o baja) pérdida de motivación y de rendimiento, lo que unido a mayores costes, puede hacer que el proyecto no sea tan rentable como cabría pensar y encima tienes ocupado en el mismo a gran parte del potencial de tu organización.

Cuando el coste/hora y no la productividad es la que marca los pasos, se pueden llegar a tomar decisiones poco comprensibles como que arquitectos software o analistas orgánicos centren su esfuerzo en definir arquitecturas, frameworks o diseños y dejen a un lado el día a día de la programación.

Todos sabemos como evoluciona el mundo del desarrollo de software y eso hace que ese tipo de decisiones se consideren un antipatrón, ya que cuanto más alejado esté un arquitecto de la realidad de la codificación, más alejadas se encontrarán sus soluciones de las necesidades que pueda tener el equipo de programadores y el proyecto.

La creatividad desmesurada que nos caracteriza puede provocar que el arquitecto elija soluciones más teóricas (cuando no experimentales) que prácticas, alejando al proyecto del objetivo de simplicidad máxima que cumpla las expectativas del usuario. Este defecto lo tiene cualquiera que realice análisis, diseños o arquitecturas y empeora sensiblemente cuando se está alejado del día a día de los proyectos (un analista que no trata con usuarios y con sus problemas, tenderá a hacer soluciones más complejas).

Tal vez sea más conocido por “Esto no es la NASA”.

Alcanzar el justo medio en el análisis de una solución (ya sean requisitos, modelado de datos, arquitectura, etc…) no es sencillo, tanto es así que lo más normal es que en la mayoría de los casos nos aproximemos al mismo y exista una desviación en defecto o en exceso.

Este antipatrón se produce cuando ante una situación que requiere un análisis y en la que hay que dedicar un tiempo y esfuerzo para realizarla de manera adecuada se decide prescindir del mismo, ya que al fin y al cabo “esto no es la NASA” y tampoco es necesario una solución prácticamente perfecta.

Tan malo es intentar alcanzar algo que no se puede conseguir (la perfección) como prescindir del estudio de un problema, asumiendo que las diferentes contingencias que nos vayamos encontrando las iremos superando y que cualquier aspecto que no se haya definido tendremos conocimientos y bagaje suficiente como para completarlos por nosotros mismos (aplicando por ejemplo otros antipatrones como “el martillo de oro“, “bala de plata” o “introducción de dificultad por analogía“).

En el antipatrón “Requisitos esparcidos por la pared” nos encontrábamos en una situación de desorden general en los requisitos: podían encontrarse en distinto grado de acabado, no existía priorización de los mismos o la misma era demasiado general como para poder hacer una ordenación adecuada por ese criterio, etc…, circunstancia que normalmente era provocada por una colaboración (si es que existe) inadecuada por parte del área usuaria.

En el caso de los requisitos ocultos, el origen puede ser el equipo de proyecto o el área usuaria:

– El equipo de proyecto conocedor de la dificultad o coste de implementar un determinado requisito lo obvia dentro del catálogo de requisitos, le asigna una prioridad muy baja o lo engloba dentro de un requisito de mayor nivel quedando difuminado en el mismo. En este caso, el equipo de proyecto es el que origina el antipatrón, pero también tiene responsabilidad el área usuaria y/o el área técnica del cliente por no haber revisados los mismos de manera adecuada.

– El área usuaria no especifica un requisito o no lo especifica de manera adecuada, en algunos casos con el objeto de obstaculizar (o sabotear) el desarrollo del sistema de información y/o el trabajo del equipo de proyecto y en otros simplemente por no haber dedicado la atención adecuada en la etapa o distintas etapas (en función de la metodología) de especificación de requisitos, solicitando explicaciones a posteriori por la no implementación de ese requisito o por su comportamiento incorrecto.

Se trata de iterar en el lugar equivocado.

Iterando en el análisis lo único que estaremos haciendo será depurar cada vez más unos requisitos que no son más que meras hipótesis (con más o menos fundamento) de lo que quiere el usuario.

Un prototipo, otro prototipo, tal vez algún esqueleto andante, una nueva versión del catálogo de requisitos, otra, otra, para que después, cualquier circunstancia (cambio de interlocutores, cambio de prioridades, cambio de los procesos que se pretenden informatizar, etc…), todo se pueda desmoronar y el proyecto, con una gran cantidad de esfuerzo invertido se quede sin nada o casi nada.

Para que la iteración tenga utilidad requiere de una entrega completa, que pueda ser usada por el usuario y de ahí obtener el feedback necesario para obtener una versión y más completa en el siguiente incremento.

Es la evolución natural de los desarrolladores que han trabajado con el ciclo de vida clásico o en cascada y de las organizaciones que han venido utilizando esa metodología.

Está comprobado que la cascada no produce buenos resultados ya que se ajusta a un modelo ideal de desarrollo de software en el cual las especificaciones de los usuarios son las adecuadas (para lo cual el usuario tiene que tener perfectamente claro qué es lo que quiere y cómo lo quiere ver plasmado en un sistema de información y, por otro, que el equipo de proyecto capte de la mejor manera posible esas expectativas) y que no cambian durante el proceso de diseño y construcción.

El desarrollo de software tiene una naturaleza adaptativa, evolutiva, no predictiva y por tanto el ciclo de vida en cascada no se ajusta a ese patrón.

Por ese motivo, el primer paso que suelen dar los desarrolladores y organizaciones habituados a ese esquema de desarrollo es dividirlo en fases y convertirlos en desarrollos incrementales. El siguiente paso que se suele dar es revisar al final de cada fase las desviaciones respecto a las expectativas, de manera que se tenga en cuenta para la siguiente fase la cual además de funcionalidades nuevas tendrá los desarrollos necesarios para realizar los ajustes de la fase anterior, pasándose de esta forma a un ciclo de vida iterativo incremental.

Una vez llegado a ese punto el salto a una metodología ágil es cuestión de tiempo.