Desarrollo de software. Verdades absolutas

En el desarrollo de software no existen verdades absolutas, ni tan siquiera esas que tienes tan arraigadas basadas en tu formación, conocimiento y experiencia.

A lo largo de la realización de un proyecto se parte de un contexto inicial que va a ir evolucionando y esos contextos probablemente serán diferentes a los de tu proyecto anterior y siguiente. Tenemos que adaptarnos a las circunstancias porque lo más probable es que las circunstancias no se puedan adaptar a nosotros.

Solo es posible la adaptación si estamos dispuesto a ello.

Si creemos que determinados procesos, metodologías y prácticas garantizan el éxito nos estamos creando una resistencia para la adaptación al cambio que nos condicionarán en el caso de que tengamos que aplicar estrategias que se salgan de esa norma.

No se trata de cambiar por cambiar, sino de hacerlo con intención y con sentido en el contexto del proyecto. Ambos factores (intención y sentido) lo son si analizamos y entendemos por qué es necesario salirnos del guión (siempre en relación a un contexto).

Y esta idea es extensible a ámbitos más allá de un proyecto por ejemplo al de la propia gestión de un departamento de desarrollo a la hora de eligir un framework o background base de funcionamiento, ¿debe funcionar una gestión de procesos que ha funcionado en otra organización?, ¿acaso su contexto es el mismo? No se trata de reinventar la rueda o aplicar de base el no inventado aquí, sino de interpretar esas estrategias acorde a la realidad de la organización, del Departamento, de los objetivos que se quieren lograr, del negocio y todos los factores que se consideren relevantes.

Tal vez la única verdad absoluta es que no hay verdades absolutas, o tal vez no.

Si los procesos no funcionan hay que cambiarlos

Mientras un proceso esté implantado hay que respetarlo y solo aplicar excepciones cuando sea absolutamente necesario. La solución no es entrar en una situación de conflicto cada vez que se quiera pasar por encima de los procesos, sino de si no funcionan, cambiarlos.

En caso contrario se entra en una espiral de desgaste que no lleva a nada bueno, ya que frente a los procesos habrá siempre un conjunto de personas encargadas de que se respeten y otro conjunto de personas que tendrán que sufrirlos.

Los procesos no son de nadie en concreto sino que son de todos, por tanto, no se deben defender como algo propio sino que se debe buscar una versión de los mismos que se ajuste a las necesidades y contexto real de la organización, siendo lo suficientemente flexibles a las casuísticas que se pueden producir en el día a día y en los proyectos y dejando una puerta abierta a su modificación ya sea por el objetivo de la mejora continua o porque el proceso deba adaptarse a un cambio de contexto.

Por tanto, los procesos son instrumentos, no lo olvidemos, si son demasiado rígidos o si no cumplen su propósito deben cambiarse, en caso contrario suponen un lastre y consiguen precisamente el objetivo contrario al que se persigue, es decir, en lugar de conseguirse un orden y una armonización en las actuaciones se llega a un orden y armonización prácticamente ficticios (se buscará cumplir con el proceso independientemente de la calidad de los trabajos) y a una reducción de la calidad final y/o de la productividad.