archivo

Archivo de la etiqueta: prototipos

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.

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.

El feedback permite ajustar el sistema a las expectativas del usuario. Por un lado hemos podido interpretar erróneamente las especificaciones del usuario, haber realizado una ejecución no adecuada de la misma, haber detalles que no hemos resuelto correctamente o bien el usuario tras ver las especificaciones implementadas (y estar bien) darse cuenta de que su idea inicial era incorrecta, que es mejorable o darse cuenta de posibilidades que previamente no había contemplado.

Este feedback lo podemos obtener tanto de versiones utilizables del producto (en un entorno de producción) que sería lo ideal ya que los usuarios adquieren un rodaje y una visión de la aplicación totalmente diferente a cualquier otra estrategia que se utilice, pero también lo podemos obtener a través de versiones en un entorno de preproducción o de demostración, a través de esqueletos andantes o revisando con ellos prototipos de pantallas ya sean dinámicos o en cartón piedra.

Revisaréis cien veces (o mil) una pantalla con un usuarios y en todas ellas saldrán cambios. Es importante saber cuándo hay que parar y pasar página (es el usuario el que debe autolimitarse y ser él el que tome la decisión, para ello es importante que entienda y que le expliquemos qué es el desarrollo de software, cuál es el presupuesto y cuáles son los plazos) sobre todo si estamos trabajando con prototipos porque de lo contrario habremos agotado el presupuesto y no habremos avanzado casi nada, con el peligro añadido de que conforme el producto vaya madurando el usuario añadirá nuevos cambios, estos generalmente con más acierto al estar trabajando a un nivel de abstracción menor.

Tenemos que asumir que en cada revisión los usuarios sugerirán cambios, esto es así y es bueno que suceda, ¿queremos desarrollar un producto que no le sirva al usuario?, pero en el horizonte debe estar siempre, como decía antes, el estado presupuestario del proyecto, de ahí la necesidad de que los usuarios también pidan con intención (previa priorización de lo que les resulta más importante), pensando qué piden y para qué lo piden y nosotros proporcionarles las herramientas y el soporte para ayudarles a ello.

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.

En el ciclo de vida en cascada, por su naturaleza, por el hecho de que el usuario empieza a ver las funcionalidades implementadas muy tarde (poco antes de la entrega) existe la tendencia a querer abrir puertas que ya se consideraban cerradas, es decir, a retocar especificaciones, en algunos casos serán cosas menores e incluso asumibles y en otros casos, se requerirá un trabajo muy importante realizar su implementación.

Y eso sucederá por muchos prototipos con los que hayas trabajado con el usuario. Es cierto, que el uso de prototipos disminuye el riesgo de posibles discrepancias entre el producto final y las expectativas del usuario, pero también lo es que durante el proceso de desarrollo pueden pasar muchas cosas que hagan que algunas (siendo generoso) especificaciones iniciales ya no valgan, que el usuario que te las haya definido se haya ido de la organización o se haya cambiado de departamento y sobre todo que hasta que no se trabaja con el producto el usuario no termina de ver claro lo que necesita (e incluso requerirá varias iteraciones hasta alcanzar con una solución que empiece a satisfacerle).

¿Qué hacemos entonces?, ¿dejamos las puertas abiertas o cerradas?. Probablemente si se dejan cerradas el producto desarrollado fracase porque por muy bien que se haya hecho, no hará o funcionará como el usuario quiere que lo haga.

Ahora bien, lo que no puede ser es que el proveedor asuma con la carga. ¿Se han desarrollado todas las funcionalidades pactadas de la manera en que está recogida en los diferentes items documentales del proyecto que a su vez ya han sido aprobados por sus responsables? Sí, pues entonces el proveedor no puede, ni debe asumir esa carga.

Debe asumir lo que no haya hecho y los errores de lo que haya hecho, pero no debe asumir errores de terceros.

El problema de todo esto es que cuando esto ocurre, en lugar de asumir lo que hay, de responsabilizarse de lo hecho y de aplicar un mayor presupuesto al proyecto, se recurre al desgaste cliente (área técnica)/proveedor para intentar que esas funcionalidades se hagan, mientras que el área usuaria, suele salir impune, actuando como un espectador que ve una película en la mejor localidad, con palomitas y refresco gratis y que actúa como un crítico implacable.

Estas situaciones son demasiado frecuentes y dan lugar a proyectos que no dejan satisfechos a nadie, que no producen buenos resultados económicos y que han originado un gran desgaste entre las partes. Por motivos como este, es necesario huir de las cascadas como metodología y por otro hace necesario un proceso de educación importante en el área usuaria antes de iniciar el proyecto para que entiendan cuál es su papel en el mismo y la responsabilidad de las decisiones que toman.

El ciclo de vida clásico o en cascada tiene el problema de que el producto final tarda mucho en ser visto (o utilizado aunque sea en un entorno que no sea de explotación) por el usuario final, tal vez demasiado tarde y que eso puede dar lugar a sorpresas muy desagradables, como el hecho de que lo que el usuario se encuentre con algo que está lejos de sus expectativas y eso se puede producir aunque se siga el análisis al pie de la letra.

Esto es una constante en este ciclo de vida, si bien, la experiencia de los desarrolladores en el mismo, lleva al uso de prototipos, a realizar presentaciones al usuario sobre módulos ya terminados, etc…

Barry Boehm cita una anécdota que ilustra muy a las claras el inconveniente de esta metodología de desarrollo. En ella un general de la fuerza aérea americana indicaba lo siguiente sobre la incertidumbre que tenía sobre el producto final que se iba a tener en un proyecto desarrollado con este ciclo de vida (traducción libre): “Tus desarrolladores son como los sastres en la historia del Emperador y su nueva ropa. Cada vez que vengo a ver cómo van las cosas, los sastres me comentan que están tremendamente ocupados tejiendo la ropa mágica y que estaré estupendo cuando la lleve en el gran desfile. Pero sin embargo, no hay nada que pueda ver y no hay forma de saber si cuando yo vaya al frente del gran desfile me encontraré sin nada encima”.

En su día describí en que consistía el ciclo de vida en cascada y las consecuencias del mismo. Podría ponerme a escribir mil artículos sobre el tema y no llegaría a expresar todo lo perjudicial que ha resultado y resulta para el desarrollo de software.

Cierto es que todos los desarrollos son cascadas, en el sentido de que en mayor o menos medida hay un análisis, un diseño, una construcción y una implantación, pero también lo es que la secuencia de fases sean esas u otras no son las responsables del problema (salvo que la elección no sea adecuada para el proyecto).

El problema es la duración de cada ciclo completo y el ciclo de vida tradicional o en cascada se basa en el desarrollo del sistema completo o la mayor parte del mismo en una iteración y esto es ir contra la naturaleza de los proyectos donde el trabajo es adaptativo y no puede estar basado en la predecibilidad de un análisis que se ha realizado desde la abstracción y desde la interpretación de un problema por parte de usuarios y de los analistas.

Es inevitable la abstracción y la interpretación y pese a que se pueden aplicar diferentes técnicas (prototipado, casos de uso, historias de usuario, etc…) que ayudan a que las distintas partes a homogeneizar la interpretación de las funcionalidades, cuanto mayor sea el abanico de las mismas con las que se trabaja, mayor será la posibilidad de que se hayan escapado detalles (que pueden ser más o menos importantes) o que simplemente cambien, aparezcan otras nuevas o se cambien las prioridades en medio del proyecto.

Si en un desarrollo en cascada de un tamaño medio o superior, a lo largo del desarrollo no se presentan cambios en las especificaciones resulta casi peor que el hecho de que no aparezcan, ya que probablemente los problemas se presenten de golpe cuando los usuarios empiecen a utilizar el sistema, lo que puede resultar crítico para la propia subsistencia del sistema y por tanto para la inversión realizada (sin embargo en función del tipo de procesos que se haya informatizado la pérdida puede ir más allá de la inversión, sobre todo si hay en juego otros aspectos que dependen del buen funcionamiento de la aplicación).

No quiero decir que un proyecto desarrollado con un ciclo de vida en cascada no pueda tener éxito, lo puede tener en mayor o menor medida, sin embargo su propia dinámica de funcionamiento, su propia naturaleza, son un obstáculo muy complicado de solventar y una fuente continua de problemas y desgaste entre las diferentes partes que participan en un proyecto y probablemente ninguno termine de estar satisfecho porque todos deberán haber dado concesiones para sacarlo adelante.