archivo

Archivo de la etiqueta: parálisis del análisis

Otro de los grandes problemas que nos encontramos en este negocio es el miedo que existe a asumir responsabilidades o errores lo que puede provocar todo tipo de situaciones:

– Inacción o parálisis. El proyecto queda bloqueado ya sea porque no se toman decisiones que permitan resolver los problemas que provocan esta circunstancia (el área usuaria se desentiende del proyecto o no participa con la dedicación que se requiere, enfrentamientos personales, existen problemas relacionados con el alcance del proyecto, la calidad de los trabajos, etc…), porque no se tiene claro hacia donde tirar y para que parezca que hay movimiento se opta por enfocar el trabajo a perfeccionar una situación que no lo requiere o a tareas de poco impacto, sin atacar el problema de fondo o porque se teme que tras la realización de una tarea el proyecto entre en una fase que sea complicada de controlar (por ejemplo que tras un paso a producción serio que afecte al núcleo de la funcionalidad del sistema, que la acogida no sea la deseada, que aparezcan infinidad de errores, que el rendimiento no sea aceptable, etc…).

Esta situación no solo afecta a los proyectos sino a los propios procesos de la organización o a las relaciones entre departamentos o equipos de trabajo. En lugar de mejorar aquellos procesos que no terminan de funcionar bien, implantar un proceso que cubra un área que hasta ahora no estaba organizada o resolver problemas entre personas o entre equipos, se decide no hacer nada no vaya a ser que la solución ponga la cosa aún peor o por el simple hecho de evitar la circunstancia de asumir decisiones que provoquen un desgaste personal.

Algunos antipatrones asociados: “Parálisis del análisis“, “miedo al éxito“, “requisitos esparcidos por la pared“, “arquitectura o programación orientada a obstáculos“, “morir planificando“, “tirita“, “chivo expiatorio“, “otra reunión más lo resolverá“, “la disputa familiar“, “caballero de tres cabezas“, “corncob“, “proyecto del día de la marmota“, “callejón sin salida“, “responsable ausente“, “rodeos improductivos

– Yo no he sido (versión activa). Una persona o un grupo de personas, toman una decisión, se realiza un trabajo en base a la misma y una vez ejecutado no se hacen responsables de los resultados. Esto sucede si los mismos no han sido buenos. Si hubiera sido al revés, faltaría metal para construir tantas medallas.

Lo peor de todo es que en más ocasiones de las que sería deseable los “yo no he sido” se aprovechan de que muchos de los acuerdos son verbales y lo que queda es la palabra de uno contra la de otro (y ya sabemos lo que se valora nuestra palabra).

– Yo no he sido (versión pasiva). A una persona o un grupo de personas, se les comunica que se van a llevar a cabo una serie de actuaciones. Después, una vez realizadas, si el resultado no es satisfactorio, empiezan a decir que quién ha autorizado esa actuación.

Es pasivo, porque en este caso, pese a que se les informó y tenían la oportunidad de interrumpir los trabajos, no lo hicieron y ahora piden explicaciones.

Este antipatrón puede considerarse una ocurrencia concreta de otros antipatrones, como por ejemplo “morir planificando” o “parálisis del análisis“.

A mi me parecería más apropiado llamarlo “ingeniería orientada a papel”.

Es muy común encontrarlo en metodologías clásicas como el ciclo de vida en cascada en el que el desarrollo está completamente dirigido por la documentación y en el que se invierte una cantidad de tiempo muy importante en generar la misma, la cual queda obsoleta ante el primer cambio que ocurra en los requisitos, algo que sucederá antes o después (y en repetidas ocasiones) a lo largo del proceso de desarrollo.

Con esto no quiero decir que la documentación en un proyecto sea algo malo, lo que es malo realmente son los excesos o los defectos y es complicado determinar a priori, sin entrar a analizar un proyecto concreto y su contexto qué es mucho y qué es poco.

A este antipatrón se llega por el exceso:

– Cuando se trata de llegar a una solución depurada del sistema de información mediante un feedback basado en la documentación.

– Cuando se dedica tiempo a perfeccionar documentos invirtiendo más esfuerzo que el valor que se obtiene de la realización de esa actividad.

– Cuando se rompe el principio ágil de valorar más “El software que funciona, por encima de la documentación exhaustiva”.

Este antipatrón se produce cuando ante un problema en la planificación del proyecto, generalmente por la existencia de retrasos respecto a la consecución de determinados hitos, se convocan reuniones para intentar dar una solución al problema. En dichas reuniones participará también miembros del equipo de proyecto que al estar en las mismas tendrán que dejar su trabajo habitual, produciéndose nuevos retrasos.

Cuando se producen estos nuevos retrasos, se vuelven a realizar reuniones para analizar la situación y así sucesivamente.

Se diferencia del “Parálisis del análisis” en que este último no se centra en aspectos de planificación, sino en la realización de sucesivas iteraciones para refinar los requisitos.

También resulta conveniente diferenciarlo del antipatrón “Morir planificando” ya que este último se centra por un lado en la planificación inicial del proyecto y por otro en la falta de flexibilidad en la adaptación de esa planificación a la realidad del proyecto. Bien es cierto que también podría extenderse al propio proceso de desarrollo, pero tendría un enfoque más generalista que la gestión de plazos (que es donde se centraría el antipatrón objeto de este artículo).

Ante situaciones de incumplimiento de plazos, claro que es necesario realizar un análisis con el objeto de detectar la naturaleza del problema y poder establecer medidas correctivas, pero el mismo no se puede basar exclusivamente en una sucesión de reuniones y las buenas intenciones que por regla general se declaran en las mismas y que después se quedan en solo eso, buenas intenciones.

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.