Desarrollo de software. Sacar requisitos a la superficie

Existen requisitos que tardan en salir a la luz. A veces el usuario lo da por entendidos, en otros casos se da cuenta más tarde o bien se trata de ajustes sobre alguno de los ya especificados.

Es complicado traducir la imagen abstracta del sistema de información que el usuario tiene en la cabeza que en la mayoría de los casos está como cubierta con niebla y que solo se empieza a ver con claridad cuando nos aproximamos a ella (conforme el usuario tenga más claro el producto final con el que se va a encontrar).

Es importante sacar cuanto antes estos requisitos ocultos a la superficie porque a su vez pueden sacar a la luz otros requisitos ocultos y porque pueden tener importancia en el resultado final del producto. Para ello es importante aplicar enfoques iterativos incrementales para que en cada iteración el usuario esté más cerca del producto final y empiece a ver con mayor nitidez determinados aspectos del producto que está esperando así como aplicar otras estrategias o instrumentos como puede ser el prototipado.

Si el usuario no solicita cambios sobre las especificaciones iniciales es una señal de alarma ya que lo más probable es que no haya dedicado suficiente atención a la especificación de los requisitos, a la revisión de los mismos o a las diferentes iteraciones del producto que se están liberando. ¿Es posible que se haya acertado a la primera? Sí, es posible pero yo por si acaso pondría un intensa luz parpadeante de color rojo como alarma.

Desarrollo de software. ¿Por qué es mejor tener esa visión más global del negocio?

Sin esa visión global estás construyendo el sistema a base de retales de manera que funcionalidades que podrían tener una solución general, la tienen de manera particular y eso de lugar a más pantallas, más tablas, más código. Si el sistema es grande y se produce muchas veces este problema estamos haciendo un sistema más complejo, con un mayor coste, más difícil de mantener y más complicado de administrar (a nivel de aplicación).

Como decía en el artículo de ayer, no se trata de hacer un análisis completo del sistema, no me refiero a eso, sino a tener una visión global de qué es lo que se quiere hacer, no se requiere por tanto la formalidad de un análisis de un ciclo de vida clásico y tampoco seguir sus etapas.

Se puede analizar y empezar a construir, así vamos obteniendo feedback del usuario que nos será de mucha utilidad porque esa visión global que nos la da el usuario y el estudio de sistemas de información que viniera utilizando antes para ese mismo proceso (u otro similar existente en otra organización) sigue estando basada en un concepción abstracta del sistema y hasta que el usuario no empieza a ver cosas tangibles no saldrán a la luz comportamientos y funcionalidades que formaban parte de sus expectativas pero que todavía no habían salido a la superficie.

Desarrollo de software. Metas, caminos, incertidumbres

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.

Desarrollo de software. La importancia de la opinión de quien está a pie de obra

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.

Desarrollo de software. Feedback y expectativas

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.

Desarrollo de software. Sistemas de información grandes, puesta en marcha, metodologías clásicas

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).

Desarrollo de software. Requisitos detallados o visión del producto

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.

Desarrollo de software. Agilidad en la interlocución

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.

Desarrollo de software. Antipatrón. Los arquitectos no programan

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).

Desarrollo de software. Antipatrón. Esto no es ciencia de cohetes

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“).