archivo

Archivos diarios: enero 13, 2012

Los gestores del proyecto, los directores usuarios, etc… tienen en muchas ocasiones ideas equivocadas de cómo va el proyecto, ya sea porque no se han preocupado por el estado real del mismo, porque han analizado mal la situación o porque le han vendido la moto (ver antipatrón “Humo y espejos“).

En cualquiera de los tres casos se tiene un miedo exacerbado a contarles la realidad del proyecto (en el caso de no haberles contado exactamente la realidad puede ser comprensible, pero ten en cuenta que si no lo haces al final será peor) y eso alimenta una falsa expectativa del mismo o lo que es lo mismo se pone al proyecto un listón tan alto que difícilmente podremos superar.

Una mala gestión de expectativas al final se termina volviendo en contra de quien no ha sabido transmitir de manera adecuada la situación del proyecto o de quien no ha corregido a tiempo una impresión equivocada del mismo porque te terminarán exigiendo lo que no vas a poder dar con el agravante de que ya lo daban por hecho y pensaban, por tanto, que lo tenían en la mano (si hay algo peor a no tener algo es creer que lo vas a tener y al final no conseguirlo) y lo que es peor, es posible que ellos mismos a otros departamentos de la organización o a sus superiores trasladasen unas expectativas que no se van a ver cumplidas (en este caso, no lo dudes, el tortazo será inversamente proporcional a tu posición en la jerarquía de la organización).

Recomiendo también leer el artículo: “Desarrollo de software. Barry Boehm. Ciclo de vida en cascada y la incertidumbre del producto final“.

Este antipatrón es el resultado general de “Reinventar la rueda” o directamente el resultado de intentar implementar o desarrollar una solución desde cero a sabiendas de que no voy a mejorar una solución que está en el mercado y al alcance de la mano, ya sea porque es libre, gratis o a un precio razonable.

Tenemos la manía de pensar de que lo que hacemos nosotros es lo mejor o que nuestros productos, metodologías, procesos, etc… pierden valor si parte de ellos (o de manera completa) no han sido el resultado de nuestro esfuerzo, sin embargo, en la mayoría de los casos nos equivocamos porque por mucha capacidad que tengamos poco podemos hacer contra productos extendidos en el mercado y que están sustentados por comunidades de desarrolladores o por una empresa que lo considera un producto dentro de su portfolio y que por tanto, tiene que cuidar si quiere seguir haciendo negocio con él.

Antipatrón muy conocido y sin embargo muy presente en nuestro día a día.

Se trata de implementar o desarrollar una solución desde cero, ya sea de un producto, una metodología, de la definición de unos procesos, etc…, obviando la existencia de otras posibles soluciones ya disponibles.

Es cierto que a veces será necesario adaptar soluciones existentes en el mercado pero el esfuerzo será mucho menor que tener que empezar desde el principio y las probabilidades de éxito mucho mayores, ya que tenemos buena parte del trabajo hecho y más que probado por terceros.

Pese a esto, es frecuente encontrarnos con organizaciones, equipos de proyecto o desarrolladores que toman la decisión de que lo que está fuera no es bueno por el simple hecho de que no controlan su desarrollo, sus especificaciones, etc…, por el hecho de que no se les haya ocurrido a ellos hacerlo antes (ver antipatrón “No inventado aquí“) o bien puede ser provocado (también muy típico) de no haber estudiado diferentes alternativas de solución, antes de afrontar desde el principio una nueva.

Muchos de los productos que hoy conocemos de código abierto serían hoy infinitamente mejores de lo que son, si muchas organizaciones en lugar de intentar realizarlos ellas mismas desde cero, hubieran invertido en su desarrollo, con el beneficio añadido de que en la mayoría de los casos, dichas organizaciones además, hubieran obtenido un mejor rendimiento de su inversión.

La torre de vudú como antipatrón es consecuencia de la siguiente práctica de programación:

Se tiene un código que se sabe que funciona (aunque generalmente no se sabe muy bien cómo) y se pretende añadir algún tipo de funcionalidad adicional, en ocasiones no muy cohesionada con la ya implementada y se le coloca un envoltorio (wrapper) proporcionando una nueva interfaz de acceso a ese nuevo componente. Se puede considerar, por tanto, una extensión del antipatrón “Voodoo chicken coding“.

Recibe el nombre de torre de vudú porque todo parte de un código correcto a la que se le van añadiendo diferentes capas de abstracción que van proporcionando funcionalidades adicionales a la original, de manera que al final tenemos un módulo que puede funcionar pero que tiene como punto débil la parte de código que no comprendemos de manera adecuada (y que está en la base de la torre, es decir, fue la semilla a partir de la cuál se construyó la misma) y/o de código que a través de sucesivas abstracciones resulta complicado de entender al ir extendiéndose su funcionalidad para realizar tareas muy diferentes a la inicialmente prevista.

Hay empresas de desarrollo de software que solo buscan historias de una noche con el cliente. Consiguen el contrato y después el objetivo es ejecutar, pase lo que pase, caiga quien caiga. La satisfacción del cliente pasa a un segundo plano, lo importante es ganar dinero o, al menos, no perderlo.

Los clientes no quieren eso, quieren poder confiar en un proveedor, saber que con ellos el servicio contratado estará cubierto y se desarrollará conforme a lo pactado.

Tal vez, antes de la crisis, había tanto mercado que daba igual que tu relación con el cliente quedase echa trizas tras esa primera noche, pero ahora, cuando el mercado no es lo que era, se hecha en falta todas aquellos negocios que se tiraron por la borda por tener una visión cortoplacista de lo que es este negocio.

Tal vez, hace unos años, tu organización fuera la más guapa de la clase y se pudiera permitir actuar de esta forma, pero el contexto ha cambiado, hay mucha más competencia que, además, se ha sabido adaptar a la nueva situación o han nacido incluso en este entorno y que han entendido lo que realmente demanda el cliente.

Este antipatrón es reflejo del ego de una organización o del nuestro, negándonos a utilizar soluciones, metodologías, prácticas, herramientas, etc… procedentes de fuera por el simple hecho de que no se nos haya ocurrido a nosotros previamente.

Esto nos lleva a reinventar ruedas (intentar buscar una alternativa desde cero), reinventar ruedas cuadradas (crear una alternativa, inferior a otra ya existente) o bien a un rechazo al cambio.

Es el caso opuesto, por ejemplo a “Blowhard Jamboree” y es que generalmente a las soluciones le gustan más los tonos grises.