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.

En el momento en que el enfoque no está orientado según la perspectiva o la misma no es adecuada (pueden existir diferentes causas: no se tiene en cuenta las expectativas del cliente o de los usuarios o no se han comprendido, no se interpreta correctamente o se ignora el contexto del proyecto, clientes o usuarios presionan para conseguir ciertos hitos en plazos muy complicados de conseguir, etc…), estamos llevando el proyecto hacia un final alternativo que no es válido (de ahí el nombre del antipatrón), ya que se aleja de los objetivos y expectativas reales.

Las circunstancias que pueden dar lugar a este antipatrón son diferentes, como distintas son también sus consecuencias (si bien, tienen en común el hecho de que llegará un punto donde no se verá el final del proyecto, no tanto porque esté lejos sino por el esfuerzo dedicado a llegar a supuestos finales que no lo eran):

- No cumplir con las expectativas del cliente o de los usuarios, trae problemas sobre todo si se ha actuado de manera irresponsable (acotación no pactada del alcance, calidad del software deficiente, múltiples bugs, etc…), por lo que la entrega del producto no es el final, ahora tocará una larga travesía en el desierto haciendo todo aquello que no se hizo cuando se debía.

- Ignorar el contexto o circunstancias que rodean al proyecto puede dar lugar a decisiones incorrectas o falsas expectativas del desarrollador. Si no te quieres dar cuenta de lo que hay, si no reaccionas, probablemente lleves al proyecto a un lugar equivocado.

- El cortoplacismo es agotador, hace perder cualquier perspectiva (para recoger en el futuro hay que sembrar en el presente y eso es complicado cuando todas tu esfuerzo está dirigido a cumplir con hitos intermedios) y crea la sensación de que nunca se va a llegar al final porque por cada obstáculo que se supera llega a continuación otro igual o peor.

El problema no es tanto acertar o equivocarse en la decisión, sino en el hecho de haberla aplicado sin entrar en un análisis objetivo de la misma.

Es decir, ante una circunstancia en un proyecto podemos tomar la decisión de que realmente no es un problema o que la probabilidad de ocurrencia es muy baja como para ser tenida en cuenta y que después la realidad nos demuestre que estábamos equivocados, es decir, se puede producir un error, pero es algo con lo que tenemos que convivir, nadie es infalible, pero lo que multiplica el error (y no porque se multiplique su impacto) es haber tomado una decisión sin haber realizado el más mínimo análisis (y todavía peor resulta, si después de todo, no se termina de aprender la lección).

Motivos:

- Coste. Será más barato hacerse con la licencia de un producto (o todavía más si es gratuito) o contratar servicios para adaptarlo a tus necesidades (es un desarrollo a medida pero partiendo de un producto, es decir, de una base sólida a partir de la cual realizar las adaptaciones y evoluciones que se necesiten) que desarrollar desde cero una solución que hace lo mismo o prácticamente lo mismo.

Existen muchas empresas que han ganado mucho dinero con el desarrollo a medida, en unos casos aplicando internamente políticas orientadas a productos (esto que hemos hecho allí, lo aplicamos aquí haciendo un par de retoques y lo vendemos como si lo hubiéramos desarrollado desde cero), en otros sobredimensionando costes (que después no se correspondían a la calidad de los resultados) y en otros rehaciendo lo que deberían haber hecho bien antes (mantenimientos perpetuos).

Sin embargo, la crisis del software pasa factura y los clientes de estos servicios están cansados de no obtener unos resultados acordes con el dinero que pagan. Si a esto le sumamos la crisis económica actual donde no se pueden (o no se deben) cometer los dispendios de antaño, el impacto sobre el desarrollo a medida resulta evidente.

- Riesgo. Embarcarse en un proyecto de desarrollo de software presenta riesgos, porque desde que se contratan los servicios hasta que se obtiene la versión definitiva del producto, pueden pasar muchas contingencias que supongan un incremento de los costes, un retraso en la planificación o incluso que finalmente el proyecto termine en un cajón.

Con la que está cayendo, tener certeza de que lo que necesito lo voy a tener prácticamente de inmediato y con un presupuesto controlado, es un argumento de mucho peso a la hora de elegir entre un producto o un desarrollo a medida.

Los desarrollos a medida seguirán existiendo, tanto en la vertiente de adaptación de productos como en la de desarrollos de soluciones desde cero, ya que existirán necesidades no cubiertas por soluciones ya existentes o se quiera tener un control total sobre el proceso de desarrollo del producto.

Este antipatrón se produce cuando ante la presión del área usuaria o del cliente se toma la decisión de aplicar medidas desesperadas para intentar cumplir plazos prácticamente imposibles:

- Reducir los controles de calidad del software tanto en testing como en la propia calidad del código (deuda técnica), priorizando la ejecución de los trabajos por encima de todo. Esta circunstancia es la que da nombre al antipatrón.

En este caso, en el caso de que se lleguen a cumplir los plazos no será más que un espejismo porque probablemente el producto se encuentre inestable durante un tiempo, sea necesario seguir trabajando en el mismo y lo que se quería tener con tanta urgencia siga sin estar al 100% disponible.

- A lo anterior se le suma en la mayoría de los casos el overtime al que se someterá al equipo de proyecto, que en muchos casos no se tratará de un pico de trabajo puntual, sino que será sostenido durante bastante tiempo. Esto impactará también en la calidad de los resultados y la productividad del equipo, dando lugar a que en ocasiones, algunos de ellos, decidan buscarse otras opciones fuera de la empresa, impactando su marcha en la evolución de los trabajos.

- En otros casos, se recurrirá a meter más personal en el proyecto, produciéndose antipatrones como el de “programador con productividad neta negativa“, “otro programador más“.

De eso trata este antipatrón, de nuestra tendencia a complicar proyectos sin necesidad, veamos algunos ejemplos:

- Con el objeto de superar las expectativas del usuario o sorprenderle, se deciden afrontar funcionalidades con prioridad muy baja que se consideran poco complejas, aprovechando los remanentes de tiempo en el desarrollo normal del proyecto.

En muchos casos, lo que parecía simple no lo es tanto y se terminan desechando (muchas veces de manera poco limpia, antipatrón “lava seca“), lo que ha supuesto un esfuerzo que no ha servido para nada, además de una pérdida de enfoque en los objetivos principales del proyecto

- Se aplican soluciones experimentales (prueba de una nueva tecnología, un nuevo framework, unos nuevos componentes) en lugar de aplicar soluciones conocidas.

- Sin entrar en un análisis riguroso del sistema o de determinadas funcionalidades, nos aventuramos a dar unos plazos muy exigentes (sin que nadie no los haya impuesto).

No es así, es adaptarse al cambio, que es algo absolutamente diferente.

Los bandazos los pueden dar los directores usuarios o las propias contingencias que afecten al proceso de desarrollo y que están por encima de éste: cambios normativos, cambios en los procesos, etc… y eso es inevitable sea cual sea la metodología que utilices y forma parte de la propia incertidumbre de este tipo de trabajos.

Lo que sí permite la agilidad es reaccionar más rápido ante estas situaciones ya sean más o menos bruscas.

La agilidad no es una generadora de milagros por lo que si el proyecto tiene bandazos significativos, el proyecto, los resultados y todos los participantes sufrirán por ellos pero las posibilidades de supervivencia serán mayores que en contextos menos flexibles.

Por ese motivo, existe mucha reticencia en estas personas a documentar lo que hacen o a compartir con otros sus conocimientos.

Este antipatrón se produce cuando una organización siendo consciente de que esta problemática existe no toma medidas para evitar o por lo menos reducir esta cautividad o dependencia con determinados trabajadores.

Hay que tener en cuenta que el problema no es solo que determinadas tareas o proyectos queden desprotegidos, sino que la actitud de los Job Keeper resulta absolutamente negativa dentro de las actividades diarias dentro de una organización, porque esta persona no colaborará con otros compañeros cuando esto suponga compartir parte de la información o conocimientos que él considera valiosos y puede comprometer el funcionamiento de la misma cuando no estén presentes en su puesto de trabajo (vacaciones, visitas a clientes, etc…).

Después de analizar con el usuario, los pros y los contras (incremento de la complejidad del sistema, esfuerzo (dinero) necesario para llevarlo a cabo, etc…), dijo finalmente “es cierto que si estos casos se producen se van dar en contadas ocasiones y no merece la pena hacer los cambios en la aplicación”.

Por tanto, en este caso, lo más productivo fue tomar la decisión de no implementar funcionalidades que no eran absolutamente necesarias (y no caer en antipatrones como por ejemplo “funcionalitis acechante“) y dedicar la atención y esfuerzo a aquellas que sí eran importantes.

Existe mucho respeto en entrar a valorar con los usuarios sus propias peticiones, pero es algo que es necesario y que el mismo usuario o cliente agradecerá en la mayoría de los casos (le ahorrarás dinero y tendrá un producto de mayor calidad). Es cierto que muchas veces no te harán caso, incluso en otras les podrá sentar mal, pero poniendo en una balanza beneficios y riesgos, merece mucho la pena intentarlo.

Es cierto que todos podemos tener momentos de debilidad en los que de alguna u otra forma necesitamos desahogarnos, pero hay que tener mucho cuidado con quién se hace y qué es lo que se dice, porque puede ser que más adelante nos tengamos que arrepentir.