archivo

Archivos diarios: agosto 5, 2013

Las metodologías y prácticas son modelos teóricos que si bien han podido ser probados con éxito en situaciones particulares, difícilmente resultan exportables, tal cual, a todo el conjunto de proyectos. Por ese motivo, la adaptación al contexto y la adaptación al cambio resulta fundamental a la hora de seleccionar el método de trabajo.

Por este motivo, cuando se trata de imponer ciertas dinámicas de trabajo suelen no conseguir resultados porque muchos proyectos o situaciones dentro de los mismos no terminan por encajar y al final no se consigue ni respetar esa dinámica, pero tampoco esquivarlas completamente afectando directamente al proyecto y con ello, muy probablemente, a sus resultados.

¿Quién está libre de no haber caído en ese error? Yo he sido el primero que ha caído en ello, empezando en la aplicación de metodologías de enfoque clásico e incluso con las metodologías aǵiles (algo que va contra natura de lo que el agilismo pretende y en lo que se cae con demasiada frecuencia).

Como decía Séneca: “Largo es el camino de la enseñanza por medio de teorías; breve y eficaz por medio de ejemplos”.

Por este motivo es difícil acertar a la primera porque al principio te basas en fundamentos teóricos: lo que leiste en un libro o lo que escuchaste en aquella conferencia, etc… Al final, la experiencia te pondrá en tu sitio, siempre y cuando decidas aprender algo de la misma.

En un proyecto de desarrollo de software se manejan multitud de variables y una gran cantidad de tareas que son realizadas por personas de los diferentes equipos de trabajo que intervienen en el proyecto, algunos de ellos de departamentos distintos o incluso de organizaciones distintas (cuando se trabaja con un cliente externo, en una unión temporal de empresas o con alguna subcontratación).

Para que todo vaya bien no solo es necesaria la colaboración sino también la sincronización con que se realizan las tareas porque, de no ser así, las desviaciones provocadas por un equipo impactarán directamente en otros, teniendo en cuenta que el que pierde siempre con todo esto es el proyecto y a la larga, si el proyecto sale mal, todos salen perdiendo.

Este espíritu de colaboración, esa intención de conseguir que toda la “maquinaria” funcione de manera adecuada solo es posible si se ha conseguido forjar una relación de confianza (después influirán otros factores, como la capacitación del personal, del impacto de los errores, etc…).

Al principio cuesta un poco (sobre todo en aquellos casos donde los equipos no se conocen) pero sirve como contramedida el hecho de que se parte de cero y todavía no han existido fricciones (otra cosa es que se parta con equipos que se conocen del pasado, que no terminaron de funcionar y que erosionaron su confianza, en estos casos habría que plantearse si la situación es reconducible o no).

Sin embargo, conforme se avanza en el proyecto y algo no va como a los responsables de algunos de los equipos quiere (o a sus jefes) o bien, se decide cambiar de prioridades, la confianza empieza a resquebrajarse, a una velocidad vertiginosa en comparación con lo que costó construirla y mantenerla.

Ya lo decía Séneca: “Una era construye ciudades. Una hora las destruye”.

Partamos de la base que en un juego con tantos intereses es muy complicado, por no decir imposible, mantener un equilibrio. El objetivo no es que siempre sea todo un camino de rosas, sino que cuando haya problemas, que los habrá, se atajen pronto, antes de que la pérdida de confianza sea prácticamente irreversible.