El trabajo remoto no tiene por qué significar videollamadas todo el día

La crisis del Covid-19 ha distanciado a la gente del lugar de trabajo, y los empresarios han aceptado en general, aunque a veces a regañadientes, que la gente pueda trabajar eficazmente desde casa. Como para compensar este distanciamiento y mantener vivo el lugar de trabajo en un sentido virtual, los empresarios también han animado a la gente a ceñirse estrechamente a la jornada laboral convencional. El mensaje es que trabajar desde casa está bien e incluso puede ser muy eficaz, siempre y cuando la gente se una a las videollamadas junto con los demás a lo largo del día. Sin embargo, los empleados suelen tener problemas con la "jornada laboral" cuando trabajan desde casa, porque muchos tienen que atender las peticiones contrapuestas de su familia, también confinada en casa. Entonces, ¿hasta qué punto es realmente eficaz trabajar desde casa si todo el mundo sigue trabajando al ritmo del reloj? ¿Es posible prescindir del reloj? La respuesta parece ser que sí. Desde antes de la pandemia hemos estado estudiando las prácticas de trabajo a distancia de la empresa tecnológica GitLab para explorar cómo podría ser si las empresas rompieran las cadenas cronológicas de sus empleados, así como sus vínculos con el lugar de trabajo físico. El reto para GitLab Desde su fundación en 2014, GitLab ha mantenido una plantilla totalmente remota que ahora cuenta con más de 1.300 empleados repartidos en más de 65 países. El modo de trabajo "git" utiliza herramientas que permiten a los empleados trabajar en proyectos en curso en cualquier lugar del mundo y a la hora que prefieran. La idea es que, al ser siempre "de 9 a 5" en algún lugar del planeta, el trabajo puede continuar las 24 horas del día, lo que aumenta la productividad agregada. Eso suena bien, pero una mano de obra escalonada tanto en el tiempo como en el espacio presenta retos de coordinación únicos con implicaciones organizativas de gran alcance. La forma más natural de distribuir el trabajo entre distintas ubicaciones es hacerlo modular e independiente, de modo que haya poca necesidad de coordinación directa: los trabajadores pueden ser eficaces sin saber cómo progresan sus colegas. Por eso el trabajo distribuido puede ser tan eficaz en los centros de llamadas y en la evaluación de patentes. Pero este enfoque tiene sus límites en las actividades relacionadas con el desarrollo y la innovación, donde las interdependencias entre los componentes del trabajo no siempre son fáciles de ver con antelación. Para este tipo de trabajo complejo, la coubicación con comunicación permanente suele ser un enfoque mejor porque ofrece dos virtudes: sincronicidad y riqueza de medios. El desfase temporal en la interacción entre dos o más individuos es casi nulo cuando están coubicados y, aunque el contenido de la conversación puede ser el mismo tanto en entornos presenciales como virtuales, es posible que la tecnología no sea totalmente capaz de transmitir las suaves señales sociales y contextuales de fondo: ¿hasta qué punto es fácil percibir las reacciones de los demás en una reunión de zoom en grupo? Todo esto implica que intentar simplemente reproducir en línea (mediante vídeo o chat de voz) lo que ocurrió de forma natural en entornos presenciales es poco probable que sea una estrategia ganadora o completa. Sin embargo, este enfoque de "ver la cara" es el que la gente parece adoptar por defecto cuando se ve obligada a trabajar a distancia, como ha revelado nuestra encuesta sobre las prácticas de trabajo a distancia inmediatamente después de los cierres patronales en todo el mundo. Coordinación tácita Existe una forma de superar este dilema. Nuestra investigación anterior sobre la deslocalización del desarrollo de software demostró que recurrir a mecanismos de coordinación tácitos, como una comprensión compartida de las normas y el contexto de trabajo, permite la coordinación sin comunicación directa. La coordinación en este caso se produce a través de la observación de la acción de otros empleados y pudiendo predecir lo que harán y necesitarán basándose en normas compartidas. Puede producirse de forma sincrónica (cuando, por ejemplo, dos personas pueden trabajar en el mismo documento de Google durante el mismo periodo de tiempo) o asincrónica (cuando las personas se reparten claramente el documento y no trabajan en él cuando lo hace la otra). Las organizaciones de desarrollo de software suelen optar por esta solución y tienden a depender en gran medida de repositorios compartidos y herramientas de creación de documentos, con sistemas para coordinar las contribuciones (por ejemplo, herramientas de integración continua y de control de versiones). Pero GitLab es bastante único en el sector lucrativo por lo mucho que confía en esta tercera vía no sólo para su codificación, sino para el funcionamiento de la propia organización. Se apoya especialmente en el trabajo asíncrono porque sus empleados están distribuidos en múltiples zonas horarias. Como resultado, aunque la empresa utiliza videoconferencias, casi ningún empleado se enfrenta nunca a un día lleno de reuniones por vídeo. Cómo funciona en GitLab En el corazón del trabajo de ingeniería que impulsa el desarrollo de productos de GitLab se encuentra el proceso de flujo de trabajo "git " inventado por el fundador de Linux, Linus Torvalds. En este proceso, un programador que realiza una contribución a un código "bifurca" (copia) el código, de modo que no quede bloqueado para otros usuarios, trabaja en él y, a continuación, realiza una "solicitud de fusión" para que la versión editada sustituya a la original, y esta nueva versión quede disponible para otras contribuciones. El proceso combina la posibilidad del trabajo asíncrono distribuido con una estructura que comprueba los posibles fallos de coordinación y garantiza la claridad de los derechos de decisión. Completamente electrónico (lo que hace factible el trabajo a distancia) y totalmente documentado, se ha convertido en un marco importante para el desarrollo de software distribuido tanto en contextos lucrativos como de código abierto. GitLab ha llevado el git un paso más allá, aplicándolo también al trabajo de gestión que implica ambigüedad e incertidumbre. Por ejemplo, el jefe de marketing de GitLab esbozó recientemente una visión para integrar el vídeo en la estrategia anual de la empresa. Solicitó comentarios asíncronos de toda la empresa en un plazo de tiempo determinado y, a continuación, programó una única reunión síncrona para acordar una versión final de la visión. Esta visión desencadenó cambios de entrada asíncronos de múltiples colaboradores en las páginas del manual de la empresa relativas a los objetivos de marketing y los resultados clave que se fusionaron al finalizar. El alto grado de confianza de GitLab en el trabajo asíncrono es posible gracias al respeto de las tres reglas siguientes hasta el nivel de las tareas: 1. Separe la responsabilidad de realizar la tarea de la responsabilidad de declararla realizada. En los entornos coubicados, en los que los empleados se encuentran en la misma oficina, la facilidad de comunicación y las señales sociales les permiten resolver eficazmente las ambigüedades y gestionar los conflictos en torno a las responsabilidades y los cometidos del trabajo. En entornos remotos, sin embargo, esto puede resultar difícil. En GitLab, por lo tanto, se espera que cada tarea tenga un Individuo Directamente Responsable (DRI), que es el responsable de la realización de la tarea y tiene libertad sobre cómo debe llevarse a cabo. Sin embargo, el DRI no puede decidir si la tarea se ha completado. Esa función es responsabilidad de un "Mantenedor", que tiene autoridad para aceptar o rechazar las solicitudes de fusión del DRI. La claridad en estas funciones para cada tarea ayuda a reducir las confusiones y los retrasos y permite que varios DRI trabajen en paralelo de la forma que deseen en diferentes partes de un código haciendo copias locales ("bifurcación"). La función del mantenedor es evitar cambios innecesarios y mantener la coherencia en la versión de trabajo del documento o código. En un contexto ajeno al software, por ejemplo al desarrollar la página del manual de GitLab sobre políticas de gastos, los DRI individuales, que podrían ser cualquier persona de la empresa, redactarían políticas específicas de la forma que eligieran, y sus contribuciones serían aceptadas o rechazadas por el CFO actuando en calidad de Mantenedor, que también podría ofrecer comentarios (pero no indicaciones) a los DRI. Una vez en vivo, la página fusionada sirve como única fuente de verdad sobre las políticas de gastos, a menos o hasta que alguien haga una nueva propuesta. Una vez más, el mantenedor aprobaría, rechazaría u ofrecería comentarios sobre la nueva propuesta. En contextos como éste, esperaríamos que personas en puestos de gestión tradicionales actuaran como mantenedores. 2. Respete el principio del "cambio mínimo viable". Cuando la coordinación es asíncrona, existe el riesgo de que los fallos de coordinación pasen desapercibidos durante demasiado tiempo - por ejemplo, dos personas pueden estar trabajando en paralelo en el mismo problema, haciendo que uno de sus esfuerzos sea redundante, o una persona puede estar realizando cambios que sean incompatibles con los esfuerzos de otra. Para minimizar este riesgo, se insta a los empleados a que presenten el cambio mínimo viable, es decir, una versión imperfecta y en fase inicial de los cambios que sugieren en el código o los documentos. Esto hace más probable que la gente se dé cuenta de si el trabajo es incompatible o se está duplicando. Obviamente, una política de cambios mínimos viables debería ir acompañada de una política de "no avergonzarse" de entregar un resultado temporalmente imperfecto. En entornos remotos, el valor de saber lo que el otro está haciendo lo antes posible es mayor que obtener el producto perfecto. 3. Comuníquese siempre públicamente. Como suelen decir los miembros del equipo de GitLab, "aquí no enviamos correo electrónico interno". En su lugar, los empleados publican todas las preguntas y comparten toda la información en los canales de Slack de sus equipos, y más tarde los jefes de equipo deciden qué información debe estar permanentemente visible para los demás. Si es así, se almacena en un lugar disponible para todos en la empresa, en un documento de "asunto" o en una página del manual en línea de la empresa, al que puede acceder cualquiera, dentro o fuera de la empresa. Esta regla significa que la gente no corre el riesgo de duplicar, o incluso destruir inadvertidamente, el trabajo de sus colegas. Los directivos dedican mucho tiempo a conservar la información generada a través del trabajo de los empleados que supervisan y se espera que sepan mejor que los demás qué información puede ser ampliamente necesaria para un futuro equipo o que sería útil para personas ajenas a la empresa. Reconocer los límites del enfoque GitLab Por muy bien implementado que esté, el trabajo a distancia asíncrono de este tipo no puede aportar mucho en cuanto a interacción social. Eso es un fallo importante, porque la interacción social no sólo es una fuente de placer y motivación para la mayoría, sino que también es donde los "encuentros al azar", los intercambios serendípicos junto a las máquinas de café y los vestíbulos de los ascensores, crean oportunidades para que las ideas y la información fluyan y se recombinen. Para minimizar esta limitación, GitLab ofrece ocasiones para la interacción no relacionada con las tareas. Cada día, los miembros del equipo pueden asistir a una de las tres llamadas sociales opcionales, escalonadas para tener en cuenta las zonas horarias. Las llamadas consisten en grupos de 8-10 personas en una sala de videochat, donde son libres de hablar de lo que quieran (GitLab proporciona una pregunta inicial diaria para romper el hielo en caso necesario, como por ejemplo: "¿Qué hiciste el fin de semana?" o "¿Cuál es el lugar más chulo al que has viajado y por qué?"). Además, GitLab cuenta con grupos sociales en Slack: salas de chat temáticas en las que pueden participar empleados con intereses similares (como: #cat, #dogs, #cooking, #mental_health_aware, #daily_gratitude, #gaming) y un canal #donut_be_strangers que permite reunirse a desconocidos que tengan un interés mutuo para tomar un café. Por supuesto, los responsables de GitLab no se hacen ilusiones de que estos grupos sustituyan perfectamente al tipo de interacciones sociales enriquecedoras fuera del trabajo que la gente encuentra gratificantes. Pero sí ayudan a mantener a los empleados conectados y, en un momento en el que muchos empleados han estado trabajando bajo normas de confinamiento, esto ha demostrado ser muy útil para mantener la moral. *** Trabajar desde casa de forma eficaz va más allá de dar a los empleados un ordenador portátil y una cuenta Zoom. Abarca prácticas destinadas a compensar o evitar las principales limitaciones del trabajo a distancia, así como a aprovechar plenamente la flexibilidad que éste puede ofrecer: trabajar no sólo desde cualquier lugar, sino en cualquier momento que se desee. Nos hemos centrado en GitLab porque no sólo tiene una amplia experiencia en el trabajo a distancia, sino también porque persigue un modo poco habitual de resolver los retos intrínsecos del trabajo a distancia. Si bien algunos de los procesos fundamentales de GitLab (como su largo proceso de incorporación remota para los nuevos empleados) y sus ventajas (como la posibilidad de contratar en todo el mundo) no pueden reproducirse plenamente a corto plazo en empresas que vayan a trabajar a distancia sólo temporalmente, hay otros que cualquier empresa puede aplicar fácilmente.

El trabajo remoto no tiene por qué significar videollamadas todo el día

Resumen.

Partner Center