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.

Se trata de aceptar proyectos que se venden (es curioso, pero muchas veces es el cliente el que vende al proveedor) como algo muy simple (solo hay que…), en los que no se realiza un análisis a alto nivel de su complejidad o viabilidad y que después resulta que es mucho más complejo y que requerirá mucho más esfuerzo que el inicialmente previsto.

Como decía en el primer párrafo, también se puede producir dentro de una organización cuando el gestor de turno te pide el favor de que le dejes un hueco a un nuevo proyecto que es muy sencillito y que apenas le va a quitar tiempo…

Se le llama Guerra de Vietnam por su analogía con la misma: guerra supuestamente fácil y corta que se cobra una alta tasa de víctimas.

Es muy parecido al patrón “Blowhard Jamboree“, con la diferencia de que este último está más orientado a seguir los criterios de una determinada persona o actor importante o de prestigio (al menos para el que lo sigue, mientras que “anunciado en televisióń” no está tan centrado en la persona que lo cuenta.

Estar al día en las tendencias tecnologícas, de ingeniería del software, etc…, resulta muy interesante ya que en muchas ocasiones ser un early adopter proporciona una ventaja competitiva interesante y en otras probablemente se pueda mejorar la forma en la que se está trabajando.

En el caso de conferencias, cursos, certificaciones, etc…, pasa exactamente lo mismo, si han sido interesantes seguro que has adquirido una serie de conocimientos que pueden ser muy provechosos.

El problema no es aprender, no es conocer nuevos contextos o enfoques, el problema es aplicarlos a ciegas.

Lo anterior es absolutamente compatible con una carrera profesional de índole más técnica orientada a la arquitectura del software.

Es posible que a un programador solo lo puedas vender dentro de un umbral precio/hora (es el reverso tenebroso de los proyectos tipo taxímetro o bolsa de horas), pero en proyectos donde prestas un servicio tener a desarrolladores altamente cualificados, motivados y productivos puede ser la diferencia entre ganar o perder dinero.

Un apunte: No hablo de sobredimensionar la cualificación de los equipos, ya que eso puede jugar incluso en contra del proyecto ya que puede provocar en algunos casos (proyectos de complejidad medio o baja) pérdida de motivación y de rendimiento, lo que unido a mayores costes, puede hacer que el proyecto no sea tan rentable como cabría pensar y encima tienes ocupado en el mismo a gran parte del potencial de tu organización.

Cuando el coste/hora y no la productividad es la que marca los pasos, se pueden llegar a tomar decisiones poco comprensibles como que arquitectos software o analistas orgánicos centren su esfuerzo en definir arquitecturas, frameworks o diseños y dejen a un lado el día a día de la programación.

Todos sabemos como evoluciona el mundo del desarrollo de software y eso hace que ese tipo de decisiones se consideren un antipatrón, ya que cuanto más alejado esté un arquitecto de la realidad de la codificación, más alejadas se encontrarán sus soluciones de las necesidades que pueda tener el equipo de programadores y el proyecto.

La creatividad desmesurada que nos caracteriza puede provocar que el arquitecto elija soluciones más teóricas (cuando no experimentales) que prácticas, alejando al proyecto del objetivo de simplicidad máxima que cumpla las expectativas del usuario. Este defecto lo tiene cualquiera que realice análisis, diseños o arquitecturas y empeora sensiblemente cuando se está alejado del día a día de los proyectos (un analista que no trata con usuarios y con sus problemas, tenderá a hacer soluciones más complejas).

Nadie es imprescindible, pero si cada uno desempeña su rol en el proyecto de manera adecuada existirán más posibilidades de que todo salga bien.

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”.