Gracias a @UPV, @DOE, @VPT, y @Dadelos Charter el día 16 de junio 2022 participé en un evento de exteriores para reforzamiento de equipos de proyectos.

He intentado «aterrizar» lo observado durante la actividad de una de las tripulaciones para llevarlo al terreno del día a día de los proyectos en los que participo (muchos de ellos en la UPV; en todos ellos influyendo, tanto si lidero formalmente, como si influyo desde un rol menos destacado). Os comparto algunas reflexiones que espero que sirvan como lecciones aprendidas de la actividad. 

En primer lugar, quiero contextualizar la actividad en el marco de participación en proyectos. Quizás algunas cosas de lo que hayamos aprendido se pueda aplicar a cualquier actividad laboral. No obstante, haré mis reflexiones pensando en proyectos que cumplan estas características:

•  Aunque parezca obvio, que sea un proyecto (no la cosas que se hacen en el día a día normal para hacer funcionar el servicio). Es decir, una agrupación de recursos (personas y otros recursos) durante un tiempo definido, con la finalidad de entregar uno o más «productos» (en el sentido más amplio de la palabra) que cumplan o superen las expectativas de las personas usuarias.
• Tienen una duración de más de 4 semanas y necesitan la implicación de 3 o más personas
• Afectan a un conjunto de personas interesadas y/usuarias internas (y puede que también externas)
• Se llevan a cabo dentro de la UPV y pueden ser objeto de auditorias internas o externas
• Precisan de una estructura de gobernanza y de unos roles y responsabilidades claramente establecidos
• Requieren de una aprobación del alcance y del presupuesto del proyecto
• Necesitan cierto nivel de control y trazabilidad
• Puede ser necesaria la colaboración de varias organizaciones, o varias unidades organizativas
• Incluye actividades adicionales a las de simple construcción/entrega

He agrupado las reflexiones en varios epígrafes.

Tantear el nuevo entorno

Los grupos estaban compuestos por personas que no todas se conocían. La UPV es una organización muy grande y muchas de ellas nunca habían interactuado entre sí. Otras no se habían visto nunca cara a cara, aunque podían haber intercambiado correos o hablado alguna vez por teléfono. De hecho, es posible que durante algún tiempo no sepas el nombre  de las personas que te acompañan o la unidad en la que trabajan o las tareas que realizan (una ronda de presentaciones breves suele resolver esta situación).

Esto condiciona las primeras intervenciones en el grupo. Es más probable que haya gente reticente a dar su opinión, o a asignarse un rol, o prestarse voluntaria para responsabilizarse de una tarea. Esto se nota aún más si los roles o las tareas no están muy bien definidas o nadie se siente especialmente capacitado para llevarlas a cabo.

La inercia

Los equipos, como los barcos, tienen su inercia. Cuesta arrancarlos, cuesta pararlos y tardan cierto tiempo en responder a las señales de cambio. Tienes que tener en cuenta esos tiempos de reacción.

Pero la inercia es asimétrica. Las cosas malas, abandonadas a la rutina, tienden a ir a más. Las cosas buenas, abandonadas a la rutina, tienden a ir a menos. O dicho de otro modo. No necesitas esforzarte para que una cosa mala vaya a peor. Sin embargo, tienes que esforzarte continuamente para que algo bueno simplemente se mantenga siendo bueno y no se degrade.

Relacionado con esto, el estilo con el que las personas del grupo se comunican (tanto la persona responsable como todos los participantes) debe adaptarse a la situación. Cuando todo va bien y el grupo experimenta orgullo y satisfacción por estar en el proyecto, es mucho más sencillo. Quizás no tengas que preocuparte demasiado por el estilo que usas porque casi todos se toleran y se integran bien dentro de un ambiente positivo (incluso ciertas ironías o estilos un poco más bruscos). Sin embargo, cuando las cosas se tuercen y el grupo se enfrenta a la frustración de no avanzar al ritmo o en la dirección deseada, es preciso usar estilos que no levanten ampollas en «pieles» que se han convertido en ultrasensibles. Considero que los estilos asertivos funcionan siempre bien en ambas situaciones, pero en las malas, seguramente hay que añadir mas palabras de lo habitual para que el mensaje se entienda y se interprete del modo adecuado.

Comunicación

Una de las barreras de comunicación que se ha visto muy claramente durante la travesía es el empleo de jerga específica y desconocida para muchas de las personas participantes. El uso de terminología específica es muy útil cuando todas las personas la pueden entender porque permite que con una palabra clave se transmita mucho significado. Pero cuando carece de significado para las personas que tienen que intervenir genera confusión. Virar, orzar, trasluchar, escorar tienen un significado claro para las personas habituadas a navegar. Son una barrera infranqueable para las que no están acostumbradas («Órzale…Pero…¡¿Por qué me viras?!»)

En nuestros proyectos debemos hablar en el lenguaje que nos permita a todos entendernos. Si es relevante el conocimiento de una jerga específica se tiene que aprender e interiorizar. Pero hasta que no se consiga interiorizarla debemos aplicar la frase con la que se inicia este párrafo.

Además, en los proyectos los problemas de jerga no son solo de lenguaje… también son de puntos de vista (las diferencias experiencias de uso de la persona responsable funcional, de la usuaria, de la analista, de la programadora…).

Otra barrera es la comunicación incompleta porque damos por supuesto que todas las demás personas pueden completar las frases o descripciones de tareas, porque en el contexto donde la comunicamos es «evidente» que no hay otras opciones. Pero nos olvidamos que es «evidente» solo para personas con cierta experiencia que son capaces de interpretar la situación y filtrar de todas las posibilidades la única que aplica con ese mensaje en ese contexto. Por ejemplo, en una maniobra de viraje, con tres personas sujetando tres cabos distintos, una orden como «afloja» puede significar muchas cosas para personas inexpertas: que afloje la persona A, la B o la C. O que aflojen dos de ellas o que la aflojen las tres. Sin embargo, si las tres son expertas, sabiendo la maniobra que se está realizando y de donde viene el viento, «afloja» solo significa una sola cosa, porque en ese contexto solo hay una opción razonable y descartan cualquier otra opción.

Por lo tanto, debemos acompañar a nuestra «tripulación» del proyecto dando las instrucciones en el formato y con la cantidad de palabras necesarias para que se puedan procesar adecuadamente. Por ejemplo: «Carmen afloja un poco el cabo» o «Manolo y Carmen liberad completamente el cabo».

Un último detalle sobre comunicación. Los «plops». Esas comunicaciones que son como pompas de jabón que chocan contigo, explotan y desaparecen y ni te enteras. Por ejemplo: «¡que alguien me diga algo!» tic, tac, tic, tac, tic tac… y nadie dice nada.

Implicación y aprendizaje organizativo

En los primeros 7-8 minutos de de la tercera regata (desde la preparación para la salida) han aprendido más que toda la hora anterior (o por lo menos han experimentado que tenían ese aprendizaje). Y sin duda han disfrutado más (se notaba en el tono de la voz, actitud y como se animaban entre ellos). En esos minutos han estado pilotando la nave ellos solos, tomando decisiones (más o menos correctas) y poniéndolas en marcha (con más o menos eficiencia).

Tras unos minutos de trabajo intenso y comprometido, ha habido unos minutos de de diversión hablando y bromeando con las tripulaciones de otros barcos. Se trataba de un momento de transición donde estaba todo el trabajo hecho y donde solo se necesitaba la atención de dos o tres tripulantes hasta que llegara el momento de un nuevo viraje. En el momento que se ha solicitado la atención toda la tripulación  ha vuelto a su concentración de antes. Eso me lleva a pensar en la importancia de celebrar los hitos intermedios. Un proyecto tiene varias fases y es bueno identificar los momentos donde se han conseguido resultados intermedios y aprovechar para felicitar, animar y distender. Eso no solo recarga las energías para los momentos más intensos, también ayuda al equipo a disfrutar del proceso y no solo de los resultados finales del proyecto.

También he podido observar lo complicado que es recuperarse de un «jarrazo de agua fría». Cuando mejor iba el barco, pilotado por los participantes en posiciones intermedias y luchando por situarse en cabeza, a punto de llegar a la boya de mitad de la manga… Justo en ese momento, una mezcla de decisiones no acertadas junto con una ejecución no muy brillante hacen que el barco pierda viento y se genere una sensación de caos e impotencia. Agravada por el hecho de que el patrón toma las riendas y desplaza al equipo de su posición de «autonomía».

Es como cuando en los proyectos aparece alguien que bloquea el proyecto o cuando, tras muchas horas de trabajo intenso, presentas orgulloso tu trabajo al cliente y te dice que eso no se parece en nada a lo que esperaba y cuando te dice lo que quiere te das cuenta que no es lo que te había dicho, o tu habías interpretado, seis meses antes).

Pero la reflexión que yo me hago es. Si han podido tener momentos buenos alguna vez, esos se pueden repetir. Descubramos las cosas que nos han permitido lograr esos momentos.

Exceso de información vs aprendizaje

En varios momentos de la actividad me ha dado la sensación de que el equipo estaba desbordado de información que no se transformaba en aprendizaje. Por un lado no se digería tanta información de golpe: más de dos o tres instrucciones no se recuerdan si no las conviertes en habito y para convertirla en hábito debes ejecutarlo/ponerlo en acción varias veces. Una vez asentado algo (por ejemplo el efecto de virar de una forma u otra, o el de cazar un cabo mas o menos rápido), puedes pasar a entender y practicar el siguiente aspecto.

Por otro lado, parecía como que la información que llegaba a la tripulación no estaba filtrada por importancia/necesidad para el éxito de la travesía. Por ejemplo, se aportaban muchos datos de cultura general náutica o anécdotas irrelevantes para las tareas a realizar. La tripulación novata estaba 100% atenta intentando recordar cada palabra y darle sentido práctico, pero el continuo chorreo de contenidos irrelevantes hace que se pierda la capacidad de atención para las cosas importantes. Cuando llegaba la instrucción útil, las mentes estaban agotadas y, además, no había tiempo para repetir y asentar la práctica del conocimiento.

Esto es algo que veo en muchas reunión de proyectos. No se va al grano, divagamos y nos perdemos en detalles no urgentes o no relevantes y cuando llega el momento de la información importante ya hemos perdido la atención del equipo o no queda tiempo para asentar esa información de manera adecuada y terminamos la reunión abruptamente confiando en que el equipo sabrá usar la información recibida para trabajar autónomamente hasta la siguiente reunión (la realidad nos suele sacar de ese sueño, una semana o quince días más tarde).

También me puedo aplicar esta regla a mis clases. Todos sabemos que el aprendizaje no consiste en embutir más conocimientos de los que el estudiante puede procesar, practicas e integrar en sus conexiones con conocimientos previos o creando nuevos conocimientos. Por eso dar una lección magistral vomitando aceleradamente la mayor cantidad de conocimientos posibles por minuto, no suele dar mejores resultados que otras formas de instrucción. Ni siquiera cuando los conocimientos «vomitados» hayan sido adecuadamente filtrados e incuestionablemente relevantes, esenciales y pertinentes. Mucho menos si, encima, no se ha hecho un esfuerzo por filtrar aquello que es realmente necesario para el éxito y desarrollo de la persona que aprende.

Aprender a Mirar

Si no somos capaces de fijar un punto que nos sirva de referencia es muy fácil perder el rumbo, ir dando bandazos e, incluso, frenar el barco porque acabas perdiendo grados respecto al viento y te quedas justo en la dirección del viento. Del mismo modo en los proyectos debemos tener señalas claras de los puntos intermedios de llegadas. Por ejemplo pantallas, pequeños desarrollos, prototipos funcionales, etc. En este sentido la metodología scrum/sprints puede ser de gran ayuda al marcar revisiones frecuentes (una, dos o tres semanas) con implementación modular de las funcionalidades.

Las entregas intermedias o los prototipos son como las «lanas» de la Génova. Te dan señales sobre si está alineado o si necesitas hacer unos ajustes finos para optimizar los resultados.

Lecciones aprendidas

Los trabajos de plegar las velas y dejar el barco preparado para el atraque son también funciones esenciales para poder salir a navegar en condiciones la próxima vez. Puede parecer que no es navegar, pero lo es y se nos olvida.

Es lo mismo que pasa en los proyectos, cuando hacemos un cierre adecuado del proyecto (revisando las expectativas cumplidas de las personas usuarias, el esfuerzo y el dinero invertido), extraemos unas lecciones aprendidas y celebramos que se ha completado el proyecto. Todo esto nos permite aprender de la experiencia y abordar el siguiente proyecto con más energía, entusiasmo, seguridad, eficacia y eficiencia.

Si no lo hacemos es probable que se cuelen pensamientos como los que se verbalizaron en mi equipo al acabar la regata: «está claro que navegar no es lo nuestro». Cuando mi visión como observador era radicalmente diferente:

• En una hora, un conjunto de novatos habían aprendido a navegar y pilotar un barco
• Han descubierto que cosas tienen que practicar para mejorar
• Y si hubieran contado con más tiempo para «iterar» el conocimiento, habrían aprendido a navegar con autonomía en mares en calma con poco viento (seguirían siendo novatos en otras condiciones, pero autónomos en esta)

En definitiva, sea cual sea el resultado de un proyecto (incluso si se tiene que cancelar a mitad, o si tardamos mucho más de lo previsto o nos gastamos mucho más dinero del esperado o si no se logra cumplir las expectativas de las personas usuarias), solo se puede considerar un fracaso si no hemos aprendido nada de él. Si, a pesar de no tener éxito, conseguimos aprender cosas para no cometer los mismos errores en el futuro, ya ha sido útil en algún sentido. Obviamente esto no puede servir de excusa para incumplir expectativas continuamente, entonces tendríamos un problema y realmente no habríamos aprendido nada. Pero debemos asumir como normal cierto numero de proyectos sin el éxito esperado, siempre que podamos obtener lecciones aprendidas útiles de ellos.

Otros aprendizajes

El anticiparse (como cuando no esperas a que la vela o la botavara cambie de lado por su cuenta e intentas forzarla con los cabos) frena el proyecto. Tienes que dejar que los usuarios digan lo que quieren y no anticipar soluciones si aún no tienes la información (forzar a que el usuario te diga lo que quiere ayuda a avanzar -es como iniciar una maniobra de viraje o de trasluchada-, pero intentar programar cosas antes de que te digan lo que necesitan o lo que quieren, es como tirar de los cabos antes de tiempo… luego tienes que deshacer el camino, y has perdido tiempo y energías).

Algunas metáforas/analogías entre navegación y proyectos

El viento son los estudiantes y/o empresas (las personas usuarias externas a las que proporcionamos servicio de aprendizaje o transferencia), las velas son el personal que ofrece el servicio directamente (normalmente PDI o personal de investigación), el resto es barco.

La sensación de ir deprisa (el viento en la cara) es una ilusión. Vamos más deprisa cuando nos desplazamos más rápido, no cuando tenemos sensación de ir rápido (o hacemos muchas cosas que en el fondo no generan ningún movimiento).

A veces nuestra única función es hacer peso para que el barco vaya más equilibrado (es una función que puede parecer aburrida o que no haces nada o que, aparentemente, no aporta, pero es necesaria para ganar algo de velocidad extra).

Asumir el trabajo del día a día de otra persona, para que esa otra persona –con capacidades diferentes a las mías- haga lo que sólo ella sabe/puede hacer, también es ayudar a que salga adelante un proyecto (que es necesario para nuestra unidad). A veces mi papel en el equipo es permitir que otra persona libere el tiempo para poder hacer otras cosas por el equipo.

Visitas: 70