archivo

Archivo de la etiqueta: arquitectura o programación orientada a obstáculos

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.

Es frecuente encontrarnos en proyectos de desarrollo de software con obstáculos que de alguna y otra forma impiden la correcta ejecución del mismo.

Algunos de ellos se pueden sortear o solventar de manera más o menos rápida pero existen otros que persisten en el proyecto y cuya solución requiere en muchos casos de bastante diplomacia, en otros de la intervención de niveles superiores en la organización.

En otros casos una solución no es viable, ya sea por el tiempo o esfuerzo que requeriría, porque otra parte implicada no quiere que haya solución, etc…

Algunos ejemplos de obstáculos que pueden complicar el desarrollo de un proyecto y soluciones que se suelen aplicar:

– El área usuaria no participa, no lo hace en el tiempo que sería necesario o no terminan de implicarse.

Una solución que se suele aplicar es que todos los demás tiren para adelante con lo que hay.

– Se necesita la integración con un tercer sistema y los responsables del mismo no quieren proporcionar la interfaz de comunicación necesaria o no lo consideran prioritario y lo planifican en un plazo no compatible con los plazos en el proyecto.

En este caso salvo que sea una integración imprescindible, en cuyo caso bloquearía el proyecto, se obvia la funcionalidad que puede proporcionar ese componente o se reinventa la rueda.

¿Cuándo tenemos este antipatrón? Pues cuando ante un problema de estas características se decide rodearlo sin intentar encontrar una solución.

Claro que habrá veces que no sea posible (aunque si el inconveniente es grave, habría que pensarse muy seriamente dar por finalizado el proyecto y resolver el contrato, antes de que todos pierdan más dinero) y no tendremos más remedio que buscar una alternativa que permita continuar los trabajos. Procura que todos estos problemas sean conocidos cuanto antes a nivel de dirección y que tengan constancia escrita.

Pero en muchos casos llegar a terminar un proyecto a través de esa alternativa puede requerir mucho esfuerzo (y disgustos), no solo por el necesario para sortear el obstáculo y buscar la solución tal vez por un camino más largo, sino porque el resultado final puede que se aleje de las expectativas del usuario.