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

Lo más habitual en las organizaciones es que cada gestor tenga un equipo de personas a su cargo más o menos fijo (su personal de confianza) y otro grupo de técnicos que colaboran en proyectos que se estén ejecutando pero que su adscripción al gestor es coyuntural, salvo que de alguna u otra forma destaque en una o más variables valoradas por el gestor y éste decida la inclusión en su equipo (si hay hueco).

Los gestores suelen pelear por mantener a su equipo fijo como sea, para lo cual se requiere la existencia de carga de trabajo. En ocasiones aceptarán compartirlo con otros gestores de manera parcial o total (se marcha a otro proyecto durante un tiempo con compromiso de volver cuando termine o cuando sea posible), con tal de no perderlos definitivamente, pero si no entra trabajo suficiente pasarán a formar parte del equipo de confianza de otro gestor y se perderá la posibilidad de recuperarlo.

Hasta ahí, todo normal en lo que es una empresa de desarrollo de software. El problema viene y de ahí este antipatrón, cuando un gestor impone su fuerza (ya sea por su mayor grado de influencia con la dirección o por tener a su cargo proyectos importantes) para quitarle a otros gestores a técnicos de su equipo, cuando estos los tienen asignados a proyectos. Es decir, se quita capacidad a otros gestores para que tu equipo gane capacidad.

Los desarrolladores no son todos iguales, en productividad, conocimientos, experiencia, adaptación a un entorno, contexto o cliente, etc…, por lo que si a un proyecto le quitan alguno de sus baluartes, indudablemente le afectará (a lo que hay que sumar el tiempo necesario para que un posible sustituto pueda adquirir un nivel productivo aceptable), afectando también a la productividad del equipo de proyecto en su conjunto sobre todo si el mismo estaba bien consolidado.

A eso hay que sumar el deterioro de la relación entre los gestores y el hecho de que concentrar mucho talento en un equipo no necesariamente garantiza nada.

Siempre he defendido que una organización debe intentar asignar a cada proyecto al mejor conjunto posible de personas para poder realizarlo dentro del conjunto de técnicos que puedan estar disponibles (estén o no asignados a proyectos, es decir, se puede estar asignado a un proyecto y por la naturaleza del mismo o su estado, puedan ser sustituido sin mucha pérdida por otras personas).

Ahora bien, también defiendo que si hay equipos que funcionan bien, no hay por qué romperlos, de manera que el mejor conjunto posible de personas que indicaba en el párrafo anterior no lo será si para ello se fractura a un equipo que produce buenos resultados, están contentos y trabajan eficientemente.

Pero para que sea efectiva es necesario conocer por qué este enfoque del desarrollo de software (y en otros muchos ámbitos de la vida) se adapta a la realidad de los proyectos, fuera de ese mundo ideal teórico que nos vendieron en nuestra formación.

Para ser ágil hay que tener actitud ágil y eso está por encima de cualquier circunstancia en la que se encuentre tu proyecto o tu. Por muy atado de pies y manos que estés, siempre existe la posibilidad de tomar decisiones o plantear un enfoque ágil, aunque solo sea para las tareas que desempeñas y tu relación con los demás.

¿Qué mucha gente no ha conocido otros enfoques de desarrollo de software y solo han conocido este? Son tantos los proyectos en los que trabajaremos, tantos usuarios, tantas circunstancias que terminarás conociendo de todo, donde te impondrán una dinámica de trabajo, una metodología, donde el corto plazo te hará perder la perspectiva y el enfoque en el proyecto, que no habrá problema en que termines teniendo experiencias que te permitan comprender mejor los fundamentos de esta forma de entender el desarrollo de software.

No obstante, aunque la experiencia te ayude, es muy interesante conocer y entender sus fundamentos.

¿Qué mucha gente lo único que ha hecho ha sido seguir una tendencia? También, pero como decía antes, tarde o temprano conocerán por qué surgió y por qué llegó para quedarse.

Atajar estos problemas implica en muchos casos tomar decisiones difíciles, políticamente incorrectas, las cuales se intenta eludir (es lo más cómodo), aplicando en su lugar otro tipo de medidas, menos comprometidas y de menor impacto que tal vez consigan buenos resultados a corto plazo pero que no resuelven el problema de fondo que existe.

A veces, las tiritas funcionan, pero dependerá de la naturaleza del problema y del tamaño de la herida.

Los gestores deben asumir su rol, está en su sueldo, está en su responsabilidad, ¿qué no lo quieren asumir? Lo mejor es no aplicar sobre él una tirita.

Estamos trabajando en nuestro proyecto cuando de pronto, nuestro superior, el superior del superior (o en general, a alguien que manda) necesita para ya, que hagamos una tarea, dentro o fuera del ámbito de nuestro proyecto y que rompe con nuestra planificación.

Es posible que en ocasiones exista una justificación, sin embargo el problema no es ese, el problema es que se cae en la dinámica de interrumpir periódicamente el núcleo central de trabajo de un equipo, sometiéndolo a picos de trabajo con alta presión, muy exigentes y que probablemente requieran overtime, de manera que a la pérdida de productividad por los cambios de contexto hay que sumar la propia del desgaste y cansancio.

Es una buena foto de la realidad, no lo puedo negar, pero también es la evidencia del triunfo de la mediocridad, que ha sumido nuestro sector en una espiral que entre todos tenemos que parar, antes de que nuestras condiciones laborales sean todavía más precarias.

Dado que las reglas del juego son esas, si queremos cambiar las cosas debemos aceptar la situación tal como es. Puedes ser una empresa de servicios de desarrollo de software excepcional pero para que te conozcan de verdad te tienen que contratar (o por lo menos que lo haga otra entidad muy allegada a aquella) y si la deriva actual ha llevado a una política de precios agresiva tendrás que convivir con ella.

Es conveniente analizar en primer lugar si es posible bajar precios minimizando el impacto sobre la masa laboral, ¿es posible reducir alguna de las partidas de gastos fijos?, ¿es posible mejorar la productividad?, ¿es posible enfocar parte de nuestro negocio a la instalación, soporte y adaptación de productos propios o libres?. Es más que probable que sea posible, en época de bonanza se cometen excesos que se institucionalizan.

Tal vez, si el cliente al que se quiere llegar es interesante, a lo anterior se pueda sumar una reducción de las expectativas de beneficio (siempre de manera sensata, teniendo en cuenta la naturaleza y complejidad del proyecto a realizar).

Otras estrategias interesantes puede ser ofrecer pilotos a precio de coste o a coste cero (sobre todo si nos basamos en la utilización de productos).

Ahora bien, una vez que llegamos al cliente, es nuestra oportunidad. Si queda satisfecho, es más que probable que en el futuro se acuerde de nosotros o que incluso quiera continuar la relación con otro tipo de proyectos. Es en este momento donde podemos empezar a ajustar la política de precios a unos términos más razonables, aunque sea poco a poco, proyecto a proyecto.

¿Estamos condicionados por el mercado? Sí, pero no hay que olvidar que somos en gran parte culpables que el mercado se haya vuelto así y que para darle la vuelta, tenemos que adaptarnos a las reglas del juego, para desde dentro y poco a poco, empezar a revertir la situación.