archivo

Archivo de la etiqueta: colaboración

Prever contractualmente todo lo que puede pasar en un proyecto de desarrollo de software es muy complejo, acentuándose en proyectos de envergadura y/o de larga duración.

Precisamente ese es uno de los problemas que provoca desgaste en las relaciones cliente/proveedor salvo que las dos partes entiendan que por encima de todo está la colaboración entre las partes.

Sin esa colaboración el proyecto irá mal para ambos, ya que pequeñas victorias relacionadas con aspectos económicos después se terminan difuminando porque si los resultados finales no son los esperados, todos van a perder. Es cierto que es difícil que todos pierdan por igual, pero creo que el objetivo de un proyecto o de una colaboración entre entidades y equipos de trabajo no debe ser tratar de perder menos que el otro.

El objetivo debe ser ganar y ese objetivo se consigue si se establece un objetivo común entre todos los participantes en el proyecto. Es cierto que después habrá otra multitud de intereses tanto a nivel de organizaciones como de las personas que participan, pero si se consigue establecer la cultura de que si el proyecto sale bien lo más probable es que la mayoría de esos otros objetivos también se conseguirán de manera transitiva, las posibilidades de colaboración entre todos se incrementarán.

Y no solo se trata de ganar, se trata también de trabajar en un ambiente más adecuado, con menos desgaste, esto redundará en la calidad del trabajo de las personas y en consecuencia, del proyecto.

El prototipado, el cartón piedra, el mockup en definitiva, es una herramienta muy poderosa. En el desarrollo de software existe desde tiempos inmemoriales y, desde mi punto de vista, no se le da la importancia que se merece.

Parece que resulta más interesante trasladar requisitos, especificaciones o historias de usuario al lenguaje natural que tener testimonios gráficos de lo que se desea obtener.

Y no solo se trata de tener los requisitos acompañados por un prototipo, lo realmente interesante es que el desarrollador lo explique al responsable funcional, product owner o usuarios implicados, de esta forma se puede comprobar, en primera instancia, que el desarrollador ha entendido el comportamiento y en segunda instancia permite ofrecer una perspectiva menos abstracta de la solución a las personas que deben definirla, algo que agradecerán y agradareceremos porque se conseguirá obtener una descripción más real de lo que se pretende obtener, gracias a esa colaboración que se consigue a través de un instrumento intermedio que las diferentes partes entienden.

No se trata de acertar a la primera, algo que sabemos que es complicado, con y sin estas técnicas, sino de tratar que el desarrollo tenga la mayor intención posible, es decir, que nos ahorremos iteraciones que podían haber sido evitadas.

Teniendo en cuenta que el desarrollo de software tiene una naturaleza colaborativa (participan personas y se necesita de todas ellas para sacar el trabajo adelante) se entiende que cuanto menor sea la separación (y no hablo de distancia física) entre las diferentes personas que participan en el proyecto, mayor probabilidad de éxito tendremos.

Por eso soy de la opinión de que los desarrolladores deben tratar con los usuarios en todas las etapas o ciclos de desarrollo de un producto. El feedback no solo se trata de palabras sino también de sensaciones y esto último te lo pierdes si no tratas con las personas que van a usar la aplicación. Por mucho que te lo cuenten no es lo mismo.

Es posible que existan proyectos donde la relación entre las partes sea tan mala que tal vez lo mejor sea utilizar intermediarios, en cualquier caso debería tratarse de una situación transitoria porque normalmente la mejor decisión que se puede tomar en estos casos, si no se consigue reconducir, es llegar a un acuerdo para dar por terminada la relación contractual.

Crear barreras e interfaces artificiales entre personas solo originan distancia y ese incremento de la misma afecta inversamente al conocimiento. Deja que el desarrollador tenga su propia perspectiva, deja que los usuarios interaccionen con los desarrolladores, dejan que compartan opiniones, deja que aprendan juntos.

Recordemos que se trata de ir eliminando esa distancia entre lo que los desarrolladores creen que hay que hacer y lo que los usuarios creen que quieren. Las diferentes versiones del producto irán aproximando esas visiones a la del producto que se espera y, como es lógico, es más efectivo si todas las partes contrastan sus perspectivas.

Una cita de Jerome Bruner dice lo siguiente (traducción libre): “La profundidad se aprecia mejor al mirar desde dos puntos a la vez”.

Añádele más puntos y se verá todavía mejor.

En algo tan complejo como es el desarrollo de software en el que existen infinidad de variables que afectan al trabajo del día a día, contar con diferentes puntos de vista ayuda a tomar mejores decisiones.

Incluso opiniones que puedan estar equivocadas te pueden dar la oportunidad de revisar y mejorar tu propia percepción.

Déjate asesorar, confía en la visión de otras personas ya que no se trata de ser el que metió el gol de la victoria sino de conseguir la victoria.

En el momento en que entiendas eso verás como consigues mejores resultados.

Es compatible tener una equipo de proyecto que comparta una misma visión con el hecho de que las diferentes personas que lo conforman puedan tener distintos puntos de vista sobre cómo se debe afrontar la realización de determinadas tareas o sobre el enfoque que hay que aplicar al proyecto.

Si todo el mundo de tu equipo piensa igual o si teniendo opiniones divergentes no la expresan, tienes un equipo plano y lo plano no funciona. Precisamente lo que enriquece una toma de decisiones son las diferentes percepciones que aportan cada una de las personas persona y en un entorno colaborativo como es el desarrollo de software eso resulta esencial.

Es mucho más complicado tener un equipo plano que no tenerlo. Si es plano, analiza las causas, ya que tal vez no se ha creado el contexto adecuado para que las personas que lo componen puedan expresarse o de tantas veces que se ha hecho caso omiso a sus opiniones han optado, por falta de motivación para hacerlo, por quedarse callados.

El desarrollo de software tiene una naturaleza evolutiva: ir de lo más simple a lo más complejo (tratando de que la solución compleja sea lo más simple posible), adaptándose al cambio ante un entorno lleno de incertidumbre, plasmando en realidad ideas abstractas que deben ir perfilándose.

Conseguir buenos resultados es más probable si se trabaja en un contexto de colaboración, cercanía (que no tiene nada que ver con la distancia) y confianza entre todas las partes involucradas en el proyecto.

Cuando el proveedor solo ve desde el minuto uno la necesidad de convertir el proyecto en beneficios, no por la vía de conseguir un buen producto, sino por la vía de la disminución de la calidad de los resultados, de los alcances, por la realización de sobreestimaciones, etc… no está creando un contexto favorable para la colaboración entre los implicados.

Estas prácticas equivocadas puede que tarden en detectarse en algunos proyectos pero lo normal es que terminen saliendo a la luz y cuando lo hacen se crean situaciones de desgaste que dan lugar a una pérdida de confianza y con ella a un distanciamiento entre las partes y a la creación de muros de defensa. En esos momentos la probabilidad de que el valor del resultado final del proyecto sea acorde con la inversión realizada es prácticamente nulo.

Pero también el cliente puede crear situaciones tan perjudiciales como la anterior. Basta con que empiece a no ser justo, a no asumir responsabilidades, a no poner en el proyecto el interés que éste demanda .

El cliente se siente más fuerte, por regla general, (si bien también existen situaciones de cautividad con respecto al proveedor en donde se produce exactamente todo lo contrario y con una intensidad, en ocasiones, incluso superior), si las personas que el cliente dedican al proyecto en lugar de asumir sus responsabilidades: decisiones equivocadas, demasiadas iteraciones para alcanzar una solución, soluciones demasiado complejas sin haber pasado por etapas intermedias, etc…, deciden que sea el proveedor el que cargue con ellas, volveremos a la situación en la que la confianza entre las partes se resquebraja y se crean muros de defensa.

La siguiente cita de Parker Palmer me hizo reflexionar sobre la esencia de lo que es un equipo de proyecto: “Cuando no dependemos el uno del otro, la comunidad no puede existir”.

El desarrollo de software debe ser colaborativo porque el conocimiento está repartido por todo el equipo y porque la visión del conjunto mejora la suma de las visiones individuales.

No todo el mundo se adapta a trabajar de esta forma porque muchos desarrolladores tienen una visión orientada al cumplimiento: “estas son mis tareas, las termino, cumplo y a otra cosa”, el desarrollador puede ser excepcional y lo mismo encaja en tareas donde trabaje solo pero si no es así deberías plantearte si efectivamente quieres a personas así en proyectos en donde sea necesario su cooperación y colaboración con otros. Es cuestión de crear equipo, sí, pero también de crear una cultura.

Precisamente la principal culpable de que prolifere la figura del cumplidor es la propia organización cuando no entiende de la importancia del trabajo en equipo, de manera que en su funcionamiento general y más específicamente en los diferentes proyectos lo que hace es reunir/juntar a una serie de personas en lugar de hacer que las mismas funcionen bajo un esquema de colaboración y cooperación.