archivo

Archivo de la etiqueta: esfuerzo

La regla del 80-20 o principio de Pareto es peligrosa si nos dejamos contagiar por el optimismo que nos trae un progreso rápido en el desarrollo del producto.

No debemos olvidar que el avance es rápido porque no es necesario que se cierren todos los detalles y porque tareas problemáticas o que no terminan de salirnos se terminan dejando para más adelante.

Cuando crees que ya tienes casi todo y te olvidas de que todavía te queda mucho trabajo por hacer, corres el riesgo de caer en este antipatrón.

¿Cuándo surge? En el momento en que se pierde la tensión por parte del equipo (o del área usuaria) y/o cuando se decide dedicar menos esfuerzo al proyecto (porque, al fin y al cabo, está casi listo).

La consecuencia suele hacer mucho daño, porque ese 20% de ejecución restante se termina eternizando, requiriendo mucho más esfuerzo y afectando a las relaciones entre desarrolladores y usuarios, ya que la frustración será cada vez más evidente y las expectativas de cliente y proveedor cada vez estarán más lejos.

El prototipado puede ir desde fórmulas muy simples como dibujos realizados a mano alzada a desarrollos que tienen una cierta lógica implementada. Son muy útiles ya que permiten trabajar sobre algo material y no sobre ideas de carácter abstracto. Nunca van a poder sustituir a la funcionalidad una vez implementada en toda su extensión pero sí que permiten desarrollar con más intención.

Este antipatrón surge cuando no se hace un uso adecuado del prototipo, no se interpreta o se comunica adecuadamente su función y utilidad, pudiendo abarcar diferentes áreas:

– El responsable funcional aprueba el prototipo pero no se ha llegado a un suficiente nivel de detalle en el comportamiento, esto puede provocar que una vez implementado no se alcancen (incluso nos hayamos quedado bastante lejos) las expectativas puestas en la funcionalidad. También puede pasar que se piense que el desarrollo es más simple o más complejo que lo que realmente es.

– En entornos de negociación cerrados, en los que solo existe el contrato como objeto de debate, si se cierran términos del mismo (alcance y coste) en base a un prototipo con muchos detalles por concretar, se corre el riesgo de que las estimaciones realizadas sean fallidas y el cliente se niegue a replantear el alcance del proyecto alegando que se conocía perfectamente el alcance ya que había un prototipo que respondía a todas las dudas.

– Los clientes también incurren en un riesgo importante si consideran un prototipo como la base fundamental para realizar una valoración del alcance, sin haber evaluado si el conocimiento que proporciona es suficiente como para hacerla reduciendo la probabilidad de que haya desviaciones sensibles.

En los dos casos anteriores, el problema lo tenemos por un lado en la falta de flexibilidad a la hora de abordar cambios en el alcance y/o de aportar más recursos económicos al proyecto (y esto ocurre trabajando con o sin prototipos) y por considerar los prototipos como una versión real pero de juguete del producto final, algo que no será así porque a lo largo del proceso de desarrollo los usuarios cambiarán de prioridades, descubrirán nuevas funcionalidades a implementar, etc…, es más, incluso en el caso de que el prototipo sea de una funcionalidad, la implementación real sacará a la luz problemas: de carácter tecnológico, de integración, funcional, etc…, muchos de los cuales son complicados de prever cuando se está trabajando con el prototipo.

Es decir, el prototipo es un facilitador para desarrollar con intención pero nadie (cliente y proveedor) debe tomarlo como la verdad absoluta y que en base a ellos se tomen decisiones inamovibles.

– Si se dedica mucho esfuerzo al prototipo es posible que se caiga en la tentación de convertirlo en el producto definitivo. Esto supone un riesgo importante porque lo más posible es que su desarrollo se haya realizado sin tener en cuenta aspectos relacionados con la calidad y mantenibilidad del software, lo que después puede dar lugar a importante costes de evolución del producto, falta de robustez, efectos colaterales en cada versión, etc…

Contar con presupuesto te permite el suficiente margen de maniobra para solucionar los posibles problemas que puede tener un sistema de información. Sin embargo, el dinero por sí mismo no arregla nada si las decisiones que se toman son incorrectas, si no se desarrolla con intención o no se resuelven los problemas que existen de raíz.

Puedes echar decenas y decenas de miles de euros a un sistema y no incrementar proporcionalmente su valor.

Este antipatrón surge cuando se cuenta con un importante presupuesto que bien utilizado podría mejorar el producto pero que en lugar de centrarse en los problemas existentes en el sistema, se invierte en un crecimiento desproporcionado y/o difícil de controlar del sistema que mezcla la resolución de esos problemas con una ampliación funcional generalmente de aspectos secundarios.

En esta situación se divide el enfoque y el presupuesto entre lo principal y lo accesorio poniendo ambos al mismo nivel, a la que vez que se dota de una mayor complejidad al sistema, generándose resistencias que afectan al directamente al esfuerzo (y coste) necesario para desarrollar. Por tanto, el presupuesto para arreglar los verdaderos problemas del sistema queda debilitado a la vez que la deuda técnica va creciendo y en consecuencia los costes de desarrollo.

Llegado a un extremo (y a veces no es necesario escorarse tanto) nos habremos “comido” el presupuesto y los problemas (o la mayoría de ellos) seguirán ahí, y lo que es todavía peor, con otros nuevos que posiblemente se han añadido, con un producto más complejo de evolucionar y con una confianza muy erosionada por parte del cliente o del área usuaria (independientemente de que ellos hayan tenido mucho o poco que ver en la priorización de las tareas y en la estrategia utilizada).

El triángulo de hierro delimita la calidad final del producto software siempre y cuando las variables que lo componen den la oportunidad de que por lo menos el proyecto tenga alguna oportunidad.

Los enfoques clásicos de desarrollo están orientados al cumplimiento de una agenda, lo que no quita que en los enfoques ágiles se tengan en cuenta también esos parámetros, la diferencia se encuentra principalmente en el grado de flexibilidad que se aplica a los mismos.

Una de las variables es el alcance. Conforme se va avanzando en el proceso de desarrollo, el usuario se empezará a dar cuenta de especificaciones que ha realizado y que son incorrectas o mejorables, así como de nuevas funcionalidades que entienden que serán necesarias. El usuario presionará para que se incorporen todas, incluso en aquellos casos en los que se tenga que “tirar” desarrollo ya realizado.

Si no se gestiona adecuadamente el alcance y en consecuencias, las expectativas, del usuario, el proyecto correrá un riesgo importante. Si se dice a todo que sí y no se ajusta la carga de trabajo a la capacidad que se puede asumir: tanto en tiempo como en presupuesto, el producto se resentirá (reducción de la calidad) y las relaciones entre las partes también (desgaste como consecuencia de condiciones impuestas sin negociación, como consecuencia de expectativas insatisfechas, como consecuencia de la presión, etc…).

De tanto tensar la cuerda termina por romperse lo que puede dar lugar a un proyecto que se quede a medias en el que funcionalidades importantes se han quedado fuera o sin rematar, motivado principalmente por el hecho de no haberse realizado una adecuada gestión de prioridades, ya que el cliente daba por hecho de que todo lo que estaba pidiendo iba a entrar.

Este es un antipatrón para clientes y proveedores. Ambos pierden, los primeros por no buscar un equilibrio entre lo que se quiere y lo que se puede y los segundos por no saber o querer gestionar estas situaciones.

La microgestión o gestión orientada al detalle tiene un importante overhead tanto por parte de quiénes realizan las tareas como por parte de quien las supervisa. Trabajar de esta manera requiere una gran disciplina de manera que solo se tiene actualizado el estado de las tareas si quienes se encargan de su ejecución tienen muy asimilada esta forma de trabajar.

Otro inconveniente importante es que se crea un contexto de escasa flexibilidad ya que los objetivos se equivocan: lo importante es realizar las tareas asignadas a tiempo sean o no lo que convenga al proyecto o aunque hayan cambiado las circunstancias. ¿Que no hay problemas en cambiar la planificación? Pues nada, a actualizar se ha dicho y el tiempo invertido en ese ajuste dependerá del cambio realizado en la planificación y de la cantidad de trabajo planificado. Este trabajo es a veces tan ingente que con tal de no tener que hacerlo se realiza la tarea y punto.

Pero de todos los posibles inconvenientes el más significativo y con diferencia es que la microgestión no se lleva bien por las circunstancias indicadas: excesivo overhead y falta de flexibilidad con una situación de incertidumbre como rodea a los proyectos de desarrollo de software.

No se trata de no saber qué es lo que se va a hacer hoy o de que podamos seguir como va evolucionando el proyecto pero la verificación del cumplimiento de los objetivos se debe realizar a más largo plazo, ¿cuánto? dependerá del contexto de la actividad, de la tarea o del proyecto.

Con la microgestión se crea una falsa sensación de control: “tengo todo planificado, al detalle, si surge un imprevisto siempre podré reaccionar a tiempo porque sé como va todo y qué está haciendo cada uno”, ¿alguien se cree que de esta forma se tiene un mayor control? Yo no digo que no, dependerá del gestor y del equipo, pero lo que no creo es que de esta manera se responda mejor al cambio, es decir, no creo que el esfuerzo que requiere (y si la gente es sincera indicando el estado real de las tareas) merezca los resultados que, por regla general, va a ofrecer.

Hay un aspecto importante a tener en cuenta, un software que no tiene prevista una evolución ya sea porque el proceso o procesos que informatiza ya están consolidados en la herramienta o porque no merece la pena ya que la tecnología está obsoleta (y resulta más adecuado, por tanto, hacer un nuevo desarrollo) no debería ser tenido en cuenta a la hora de plantear un programa progresivo de reducción de la deuda técnica en una aplicación.

Que no se tenga prevista una evolución no quiere decir que no vaya a surgir nunca esa necesidad, ya que basta con que lo pienses como para que mañana mismo te vengan con una petición de cambio. Ahora bien, se trata de sacar el mayor provecho posible a los medios que tengamos y para ello es necesario priorizar dónde realizar este tipo de actuaciones.

Lo normal es que si tienes previsto un plan de evolución de un producto y el mismo presenta una deuda técnica inadecuada se intente dedicar parte del esfuerzo a mejorar la misma de manera que vaya mejorando la mantenibilidad del sistema. Lo mismo no hay posibilidad de hacer un cambio en profundidad del sistema ya sea porque el esfuerzo que se puede invertir esté bastante limitado y/o porque existen fuertes restricciones temporales pero siembre cualquier mejora que se pueda aplicar se agradecerá después.

En la mayoría de los casos la instalación de una versión del sistema en el entorno de producción es realizada por un personal distinto al que desarrolla y que se encargar de administrarlo.

También antes de proceder a la instalación en producción se realizan pruebas específicas ya sean por parte del usuario, por parte de personal de equipo de proyecto y/o por parte de un equipo de personas que realizan este tipo de tareas.

Básicamente (dependiendo de la organización con la que se trabaje estos requisitos podrán ser mayores) una entrega consistirá en la entrega del código fuente, en un sistema de control de versiones, la incorporación de las librerías dependientes en un repositorio de artefactos y la documentación necesaria para la instalación del producto y la realización de pruebas.

No es mucho, ¿verdad?, pues incluso en este tipo de circunstancias los desarrolladores realizan con demasiada frecuencia entregas deficientes que provocan retrasos en el proceso de paso a producción (vueltas a atrás por entregas defectuosas ya sea del producto y/o de la documentación) e incidencias sobre funcionalidades ya existentes en el sistema y que funcionaban bien (efecto colateral) o funcionalidades nuevas que fallan.

Esto tiene un coste importante para el proveedor y también para el cliente. En algunas ocasiones este coste puede ser incluso mayor cualitativamente y/o cuantitativamente que el esfuerzo que ha sido necesario para desarrollar esta iteración.

¿Por qué estas malas entregas? Principalmente por la falta de atención. A los desarrolladores no les motiva esos preparativos y hacer esa documentación, les aburre y mientras están trabajando en la misma en lugar de enfocar su atención a esa tarea se ponen a pensar en otra cosa o simultanearla con otros asuntos.

Con respecto a esto yo solo digo que un muy buen trabajo en el desarrollo puede quedar arruinado por una mala gestión de la entrega lo que realmente es una pena porque es como fallar un gol desde el área pequeña y sin portero.