archivo

Archivo de la etiqueta: síndrome de la última versión

El proyecto se queda sin presupuesto, al menos, a corto y medio plazo y los responsables funcionales entienden que existen funcionalidades que son necesarias para que el producto sea de utilidad o para que la productividad en el uso del mismo sea aceptable.

¿El problema? No hay dinero para hacer todo lo que necesitan, ¿cuál es la primera consecuencia? Desgaste, incluso en situaciones donde el desarrollo haya sido fluído. A los usuarios les entra el síndrome de la última versión y el proveedor de servicios de desarrollo por muy flexible que sea tendrá que mirar por los resultados económicos del proyecto.

Gestionar bien esa circunstancia tanto por parte del cliente como del proveedor es esencial ya que se puede tirar por tierra todo el esfuerzo de meses de trabajo. No es sencillo porque todos sabemos lo complicado que resulta cerrar un proyecto.

No existen fórmulas mágicas, solo el sentido común, la búsqueda del beneficio mutuo y un autoanálisis crítico del trabajo que se ha realizado en el proyecto con el objeto de asumir responsabilidades (si existen). Si ambas partes quieren se puede alcanzar un acuerdo satisfactorio, si una de ellas se resiste probablemente terminen perdiendo ambas.

Además de lo anterior, la solución ideal pasaría por dotar al proyecto del presupuesto adicional necesario para terminar de manera adecuada los trabajos, si bien pueden existir circunstancias que lo impidan o, al menos, que lo impidan temporalmente.

Recordemos que lo realmente importante es el valor del proyecto y su relación adecuada con la inversión realizada y no acertar con una estimación inicial que todos sabemos (cliente y proveedor) cómo está hecha. Si tu objetivo es hacer que la estimación sea acertada tal vez te lleves ese logro pero tal vez, también, el proyecto se quede a medias o se entregue un producto deficiente,

Si un proyecto puede presentar problemas presupuestarios cuando se prevé un alcance y una complejidad mayor que cuando se hizo su estimación económica, la solución debería pasar, no por intentar meter todas las funcionalidades con calzador, sino por tratar de buscar una solución más racional que permita obtener un producto que satisfaga las prioridades que se han establecido con un alto nivel de calidad, aunque esto implique dejar fuera o para más adelante (en muchos casos es necesario gestionar con los responsables funcionales el síndrome de la última versión), otra serie de funcionalidades que pueden resultar interesantes.

El primer paso debería consistir en dividir el proyecto en diferentes entregas, siendo conscientes todas las partes de que el desarrollo será iterativo incremental porque del feedback de cada versión vendrán, muy probablemente, solicitudes de mejora por parte del área usuaria.

Si se trata hacer todo de golpe se correrá el riesgo de que se agote el presupuesto y que en medio del proceso de desarrollo se entre en un conflicto entre las partes sobre cuál será el alcance final.

La experiencia dice que por muy buen acuerdo que se alcance se verá afectada la calidad del software porque el proveedor tratará de minimizar pérdidas, porque los desarrolladores tendrán overtime y llegado a un punto el cansancio y las ganas de terminar darán lugar a precipitación que se traduce en deuda técnica y en un producto menos probado.

Por otro lado, el cliente tendrá una mayor desconfianza y la comunicación entre las partes, tan necesaria en un proyecto de desarrollo de software, perderá fluidez y en función del grado de desgaste en las relaciones podría dar lugar a situaciones del antipatrón “arrojar al otro lado del muro“.

También se puede agotar el presupuesto con el enfoque iterativo incremental, la diferencia está en que al reestructurar el proyecto de esta manera todas las partes conocen las reglas del juego: se trabaja así no solo porque sea el enfoque que mejor pueda convenir al proyecto sino porque permite gestionar de manera adecuada las prioridades, el seguimiento y consumo económico del proyecto.

El siguiente paso consiste en trabajar con pila de producto e historias de usuario. Los responsables funcionales priorizan estas historias que una vez tasadas y ajustadas a la capacidad del sprint, se convierten en lo que será el resultado final de la entrega.

Si no lo ves claro (y también si lo ves claro), no dudes en dividir el proyecto en partes y cada parte en componentes o trabajos más simples (historias de usuario). Será más manejable, te beneficiarás el feedback y la gestión económica será mucho más transparente y mejor entendida entre las partes.

Decía Nicolás Maquiavelo que: “no puede haber grandes dificultades cuando abunda la buena voluntad”.

En el desarrollo de software es esencial la buena voluntad de las partes para tratar de conseguir buenos resultados, es cierto que después, podrán ser mejores o peores, pero en ese contexto el trabajo es mucho más fácil porque independientemente de los objetivos individuales de cada persona o de cada equipo, habrá un objetivo general que todos querrán alcanzar.

Con buena voluntad aumenta la empatía, se empieza a cimentar la confianza, se eliminan trabas a la comunicación y mejora la interacción entre las personas, algo fundamental para llevar adelante un proyecto de desarrollo de software en el que lo más importante para conseguir los objetivos son las personas.

En el momento en que las personas dejan de colaborar, empiezan a poner resistencias, a crear muros, a no cumplir con sus compromisos, la dificultad crece exponencialmente. Esto hace daño dentro de un equipo pero se convierte en insufrible cuando los equipos se enfrentan (por ejemplo desarrolladores y área usuaria) porque todo se ralentiza, se convierte en más burocrático, se multiplican las explicaciones, se incrementa o aparece el síndrome de la última versión, cada parte radicaliza sus posturas, los desarrolladores querrán salir cuanto antes del proyecto y el área usuaria si entiende que no se han alcanzado los objetivos no querrán que salgan nunca (un error, desde mi punto de vista por ambas partes, que deberían tratar de dar una salida lo más digna posible al proyecto).

La buena voluntad puede ser un estado inicial pero no es un estado permanente, todos son responsables de mantenerla independientemente de que haya (que los habrá) momentos de crisis.

Llegar a producción da miedo. El área usuaria siempre tendrá el “síndrome de la última versión” y, por tanto, querrá incluir toda la funcionalidad que puedan y pondrán los umbrales de aceptación muy altos.

A los desarrolladores también les entra el pánico porque por muchas pruebas que se hayan realizado al producto es en producción donde se pasa el examen final, todo lo anterior son exámenes parciales que si bien hay que superarlos no tienen más trascendencia (y no con ello quiero quitale importancia) que crisis puntuales en el proceso de desarrollo.

Si hay presión en el desarrollo, no es comparable con la que se recibe si el producto llega a producción y es un desastre.

Esta situación puede eternizar el paso a producción en muchos proyectos de desarrollo de software.

Ante esto hay que reflexionar (usuarios y desarrolladores) sobre las características del sistema de información que vamos a poner en producción, si se trata del software de una central nuclear o un software crítico que puede poner en riesgo vidas humanas, la salud de las personas, el medio ambiente o la continuidad de la organización se puede entender que toda precaución es poca, pero fuera de ese círculo (que es la inmensa mayoría de los sistemas que se desarrollan) hay que evaluar el coste real que implica retrasar sistemáticamente un paso a producción por el intento de alcanzar una perfección que nunca se va a conseguir.

Ya lo dice Kent Beck: “No estar en producción es gastar dinero sin hacer dinero”.

Afecta sobre todo a los usuarios pero también a los desarrolladores y nos lo encontramos tanto en enfoques clásicos como ágiles.

Cuando nos aproximamos a al definición de la primera entrega que va a producción (en el caso de un enfoque iterativo incremental se han podido liberar previamente versiones parciales que no han llegado a producción), el usuario empezará a querer incorporar funcionalidades que considera necesarias aún sabiendo que no son imprescindibles (los desarrolladores que en esto no deberían intervenir, pero que ya conocen el negocio, se convierten incluso en cómplices), sin tener en cuenta que tras esta versión, vendrán otras en las que podrán ir incorporando estas funcionalidades según las prioridades que establezcan.

Si este antipatrón se materializa presenta como inconveniente que se asuma una mayor capacidad de trabajo que la que el equipo puede soportar, lo que provocará, además del correspondiente overtime, una versión del producto con un peor acabado: más errores y más deuda técnica, y que no se cumplan los compromisos adquiridos ya que probablemente alguna funcionalidad no de tiempo a tenerla lista (esto último puede parecer menos importante pero no lo es, ya que la confianza está muy ligada al cumplimiento de los compromisos).

Es un ejemplo claro de que más es menos cuando se toman decisiones que no son compatibles con las posibilidades del equipo de proyecto.