archivo

Archivos diarios: enero 12, 2012

Debería estar, tal cual, incluido en la relación de antipatrones, de hecho tiene muchos aspectos en común con algunos como: “Cargo cult” o “Blowhard Jamboree“.

Algunas situaciones donde nos podemos encontrar con la gran ganga:

– Nos pondrán encima de la mesa ofertas muy económicas con recursos que probablemente sobrepasen las necesidades del proyecto y asegurando que el nivel de calidad final será excelente.

– Escucharemos a una persona con reconocido prestigio en el sector o mediática (que no es lo mismo) indicar las bondades de tal o cual solución que revolucionará la forma en que venimos haciendo las cosas, sin prácticamente esfuerzo y con unos beneficios sorprendentes.

– Nos cuentan que determinadas organizaciones de la competencia han aplicado cambios en sus procesos que les ha hecho más competitivas, todo ello también sin grandes esfuerzos y prácticamente de la noche a la mañana.

No digo que siempre que se produzca ese tipo de circunstancias no sea verdad, lo que sí quiero comentar es que muchas veces las cosas que parecen demasiado buenas como para ser ciertas generalmente son eso, demasiado buenas para ser ciertas.

Lo importante no es lo que te cuenten lo importante es analizar si lo que te cuentan es aplicable a tu ámbito de actuación, qué consecuencias tiene aplicarlo, qué riesgos y qué espero obtener con ello.

Este antipatrón hace referencia a cambios que introducimos en el código de la aplicación o a código que directamente se añade en la misma y después se adapta, que no entendemos muy bien cómo funciona pero que al final resuelven el problema o la funcionalidad en la que estábamos trabajando (como si fuera por arte de magia o de un sortilegio).

En ocasiones, este antipatrón, coincidirá con otros como, por ejemplo, “Programación por permutación” o “Cargo cult“, ya que al final tendremos una situación que resuelve una contingencia y no sabes ni cómo ni por qué.

Si el producto software fuera algo estático, podríamos considerar que ya, efectivamente hemos resuelto el problema, pero nos volveremos probablemente a encontrárnoslo de nuevo más adelante, cuando se tenga que realizar un mantenimiento del componente afectado y tengamos que tocar ese “código mágico”. Lo mismo se consigue resolver de nuevo la situación, se incrementa la cantidad de código afectada o se tiene que buscar una nueva solución, ahora sí, que se entienda como funciona.

Es cierto que a veces nos podemos encontrar con determinadas incidencias que no hay forma de solucionar, que no siguen una lógica y que tras prueba y error se consigue dar con la solución aunque no entendamos muy bien por qué. Esto implica que en circunstancias excepcionales sí que puede resultar práctico tener voodo chicken coding en el sistema, teniendo en cuenta que el mismo será siempre un punto débil en nuestra aplicación y que si se dispusiera de tiempo y medios sería necesario seguir investigando el motivo del error que dio lugar a esa solución (el problema lo tenemos en que aunque existan esos medios, no se invertirán en esto, alegando el famoso “si funciona, no lo toques”).

Se llega a este antipatrón cuando en un equipo de proyecto (se puede generalizar a un grupo de personas que han participado o han tenido influencia en una serie de resultados, como puede ser los stakeholders, un grupo de jefes de proyecto o gerentes, etc…) se llega a la conclusión de que la mejor forma de analizar las causas de la no consecución de los objetivos es que se discuta quiénes internamente han tenido la culpa.

Se piensa que de esta forma, diciendo cada cual lo que siente, los problemas salen a relucir.

Es muy posible que entre grito, reproche y ataque salgan a la luz problemas (de hecho, que se grite, reproche o ataque ya resulta suficientemente significativo del ambiente y relación de confianza que se ha vivido en el proyecto) pero entre los participantes (al menos, en la mayoría), lo dicho no quedará en la mesa de reuniones (creando un poso que dependiendo del carácter de cada individuo, tardará más o menos en eliminarse), porque en este tipo de circunstancias se llegan, además, a decir cosas absolutamente fuera de lugar y bastante ofensivas.

A este antipatrón se llega cuando de manera interna en un equipo de trabajo o en una reunión con el cliente y/o con usuarios se empiezan a utilizar términos, generalmente técnicos, que no son comprendidos o conocidos por la mayoría de los interlocutores.

Esta situación se produce a veces de manera involuntaria (no se tiene en cuenta que la mayoría de los interlocutores no tienen por qué conocer la terminología, conceptos o materia de la que se habla) y en otras se hace de manera voluntaria, para tratar de impresionar (esto sale, a veces, al revés, ya que es complicado impresionar a alguien que no te entiende), para dar un mensaje confuso (en lugar de tratar directamente un posible problema).

En muchas ocasiones, cuando se realiza de forma involuntaria pasa desapercibida por parte de quien la ha provocado porque en contadas ocasiones, ya sea en el ámbito de tu equipo de proyecto (sobre todo), cliente o usuarios, pocos van a admitir que no entienden lo que le estás contando.

La comunicación es muy importante en el proceso de desarrollo por lo que resulta fundamental que los mensajes sean claros y que se entiendan, por eso resulta fundamental modularlos a la audiencia que se tiene en cada momento. No hacerlo dará lugar precisamente a que no llegue a los interlocutores la información que deseas transmitir o que la misma llegue de manera parcial, tendiéndose a cubrir los huecos con la más que posible mala interpretación del receptor.

Esto resulta especialmente grave dentro de un equipo de proyecto, pero también tiene mucha importancia en la comunicación con clientes o usuarios, los cuales además, pueden ponerse a la defensiva si de manera reiterada se produce este tipo de situación.