Si pues, de momento dejaremos nuestra tónica habitual dedicada a la nube y DevOps para comentar algo que, junto a la cuarentena, ha sido uno de los tópicos en estas semanas: el teletrabajo, trabajo remoto, home office, y similares, que no son lo mismo, hay matices, pero no son sujetos de lo que vamos a ver.

Digo de vuelta, porque para mi no es la primera vez que tengo que pasar por estas circunstancias de desarrollar mi trabajo lejos de mis colegas/clientes/proveedores etc, que es básicamente la situación en la que nos encontramos ahora, para lo cual me basare en mi experiencia personal, que si bien no es la fuente de la verdad única me ha permitido extraer algunas conclusiones que espero sean de utilidad.

Mi primera experiencia fue cuando, transicionando entre proyectos, se me pidió hacer una propuesta comercial para la consultora española en la que me encontraba, me tomo alrededor de una semana el completarla, y la primera vez si que fue complicado, pues estar en mi habitación ponía cerca la disponibilidad de reposar un rato y no enfocarme en mis responsabilidades, pero aun así el documento salió adelante y le gusto a mis jefes, pero desde ese entonces me quedo clara la importancia de separar el ambiente de trabajo del de tu reposo, solo que entonces no era posible pues alquilaba habitación.

La segunda situación, intermedia, correspondió a cuando, al regresar a España desde Sudafrica, tuve que hacerme cargo de un equipo de desarrollo en Madrid, pero por la naturaleza del proyecto, se tenían que hacer coordinaciones con el equipo en Joburg, en ese momento las cosas estaban bastante limitadas:

• No había nube
• Las transferencias por VPN eran lentísimas
• Los servicios de voz por IP eran poco fiables

Aun así, logramos adaptarnos, los correos eran muy fluidos, y eventualmente tenia llamadas interdiarias con el QA en Joburg, pero lo de compartir pantalla sencillamente no era viable. Felizmente esas limitaciones ya son historia, pero queda como punto claro la importancia de la disponibilidad de buenos canales de comunicación para los equipos.

La tercera experiencia fue cuando me tuve que hacer cargo de gestión y mantenimiento de varias aplicaciones para la sede española de una multinacional de investigación de mercado, en este caso sí que estaba en la sede del cliente coordinando con la gente de infraestructura y los usuarios, pero tenía que coordinar y asignar tareas a alguien trabajando en la India, el problema es que las formas de asegurar el entendimiento por ambos lados nunca se formalizaron, ya que tiempo después me di cuenta de que cuando preguntaba “Do you understand?” la respuesta de “yes” casi nunca era cierta, amén de que habiendo posibilidad de usar Webex para efectuar las comunicaciones, o chat para cosas urgentes, mi contraparte prefería llamadas por teléfono convencional (con menor calidad de audio), lo cual sumado al hecho de que estaba en un proceso cross o multiprojecto, no permitía un flujo adecuado en el desarrollo de nuestras actividades, esto, en retrospectiva hace clara la importancia de definir o setear los “protocolos” y canales que se usaran para las comunicaciones, y en todo caso generar “actas” que aseguren el entendimiento común de las conclusiones de la reunión.

En los siguientes años la experiencia fue mas frecuente, de la mano con mi regreso al Perú y al trabajar en la mayoría de los casos en proyectos que trataban de seguir marcos agiles, pero con la peculiaridad de que nuestros clientes estaban fuera del Perú, no siendo raro que la mitad del equipo estuviera en Lima, y el resto en otro país (Costa Rica, Argentina, España, USA) solo que en este caso se mezclaba la peculiaridad de ir unos días a la oficina, y a veces trabajar desde casa, por lo que las lecciones en este caso son variadas:

• Si quieres poner a tu equipo en una sala (para hablar con la otra mitad del equipo), asegúrate que has validado bien el alcance de tus dispositivos para no tener a tu gente gritando.
• Tener dos pantallas es bueno, pues por un lado ves a tu contraparte, y en la otra pantalla están ambos haciendo el code review o similar.
• Por otro lado, una segunda pantalla también tiene el riesgo de que ayuda a no ponerle total atención a la reunión en curso.
• Saber que tienes a tu contraparte a un clic de distancia para tener un chat, y de ser necesario una llamada, ayuda mucho a generar una sensación de equipo pese a la distancia.
• Una cultura de Pull Request y aprobación/rechazo rápido ayuda mucho, mucho.

Mención aparte es un problema sobre el cual no he tenido mucha respuesta que ayudara en algo, y es el tema de las Retrospectivas cuando tienes equipos distribuidos (ya sea en casa o en distintas sedes de trabajo), pues cuando empecé con esto de los marcos ágiles, casi todas las dinámicas que se enseñaban o comentaban partían del supuesto de tener todo el equipo en un mismo sitio (recuerdo un libro de varias dinámicas muy interesantes, pero ninguna orientada a equipos distribuidos), que si, que habían herramientas para ayudar en el tema, que básicamente te permitían escribir tus comentarios (Que se hizo mal, Que se hizo bien, Como mejorar) de manera oculta y luego destaparlos, lo que ocasionaba que las retros terminaran convirtiéndose en un Dia de la Marmota.

Si recordamos lo que aprendimos en agilidad, mucho se basa en el ir aprendiendo, evolucionando, mejora continua y todo eso, siendo que si una actividad se vuelve repetitiva… poca ganancia se puede sacar. Una de las pocas mejoras que conseguí en un equipo fue que se rotara al facilitador, lo cual logro que el diferente “estilo” cada vez lograra un mayor dinamismo por parte del equipo, pero eso no es suficiente; así que en esa época en la comunidad consulte a diversos coaches, y gurúes que venían a compartir sus conocimientos y experiencia (en algunos caso muy valiosos), obteniendo generalmente miradas al techo… y alguno en algún arranque de sinceridad me dijo que siempre en sus clientes había trabajado con todo el equipo de manera presencial, y claro es que los equipos que trabajamos offshore nunca habíamos sido el “blanco” de sus actividades, situación que ahora veo que cambia a toda prisa, debiendo improvisar en campos en los que no habían incursionado, ojala que en esta ocasión se escuche a quienes han tenido experiencia real en este aspecto y que hayan podido resolver este impedimento (*).

En todo caso, lo que he comentado hasta el momento tenia una peculiaridad muy muy fuerte, y es que estos equipos en los que participaba estaban orientados hacia un único proyecto/producto, por lo que siempre se tenia el foco de manera clara, pero mi situación actual es diferente, y se podría decir que estoy en un proceso de aprendizaje.

¿Por qué? Desde hace un tiempo he asumido un rol de arquitecto cloud, lo cual por su naturaleza obliga a trabajar en varios frentes de batalla a la vez: revisión de iniciativas para su aprobación, apoyar proyectos en curso, coordinar actividades con otras áreas para establecer algo en conjunto, etc., un reto interesante que obliga a tener otro tipo de orden, en el cual te acostumbras a las charlas de pasillo y a sacarle partido a ellas para aprender mas de los distintos contextos con los que hay que lidiar.

El detalle es que cuando pasas de golpe a un escenario de Home Office colectivo, todos pasamos a un proceso de aprendizaje, reinventando reglas, nuevas formas de coordinar, a lidiar de otra manera con el context switch, con la gestión de las agendas, es un camino que vamos empezando, del cual espero dar conclusiones u opiniones mas definitivas como las he dado para mis escenarios anteriores.

¿Y uds? ¿Qué experiencia o buenas practicas pueden compartir respecto al trabajo distribuido o remoto?

(*) Me comentan que en los últimos dos años han surgido herramientas que ahora si apoyan el poder hacer una buena retro con los equipos distribuidos, soy todo oídos.