A crise da Covid-19 distanciou as pessoas do local de trabalho, e os empregadores geralmente, embora às vezes com relutância, aceitam que as pessoas podem trabalhar com eficiência em casa. Como que para compensar esse distanciamento e manter o local de trabalho vivo em um sentido virtual, os empregadores também incentivaram as pessoas a se manterem firmes na jornada de trabalho convencional. A mensagem é que trabalhar em casa é bom e pode até ser muito eficiente – desde que as pessoas participem de videochamadas junto com todas as outras durante o dia.

Mas os funcionários muitas vezes lutam com a “jornada de trabalho” quando trabalham em casa, porque muitos têm que lidar com os pedidos concorrentes vindos de suas famílias, também que ficam fora de casa. Então, quão eficaz é realmente trabalhar em casa se todos ainda estão trabalhando incessantemente? É possível abandonar o relógio?

A resposta parece ser que sim. Desde antes da pandemia, temos estudado as práticas de trabalho remoto da empresa de tecnologia GitLab para explorar como seria se as empresas quebrassem as cadeias cronológicas de seus funcionários, bem como seus laços com o local de trabalho físico.

O desafio para GitLab

Desde sua fundação em 2014, o GitLab manteve uma equipe totalmente remota que agora compreende mais de 1.300 funcionários espalhados por mais de 65 países. A forma “git” de trabalhar usa ferramentas que permitem aos funcionários trabalhar em projetos em andamento onde quer que estejam no mundo e no horário de sua preferência. A ideia é que, como é sempre “das 9h às 17h” em algum lugar do planeta, o trabalho pode continuar 24 horas por dia, aumentando a produtividade agregada. Isso parece bom, mas uma força de trabalho escalonada no tempo e no espaço apresenta desafios de coordenação únicos com implicações organizacionais abrangentes.

A maneira mais natural de distribuir o trabalho pelos locais é torná-lo modular e independente, de modo que haja pouca necessidade de coordenação direta – os funcionários podem ser eficazes sem saber como seus colegas estão progredindo. É por isso que o trabalho distribuído pode ser tão eficaz para call centers e na avaliação de patentes. Mas essa abordagem tem seus limites nas atividades relacionadas ao desenvolvimento e à inovação, onde as interdependências entre os componentes do trabalho nem sempre são fáceis de ver com antecedência.

Para esse tipo de trabalho complexo, a co-localização com comunicação contínua costuma ser uma abordagem melhor, porque oferece duas virtudes: sincronicidade e riqueza de mídia. O lapso de tempo na interação entre dois ou mais indivíduos é quase zero quando eles estão co-localizados e, embora o conteúdo da conversa possa ser o mesmo tanto face a face quanto em ambientes virtuais, a tecnologia pode não ser totalmente capaz de transmitir sugestões contextuais sociais e de fundo – quão fácil é sentir as reações de outras pessoas em uma reunião de zoom em grupo?

Tudo isso implica que simplesmente tentar replicar online (por vídeo ou chat de voz) o que aconteceu naturalmente em ambientes co-localizados dificilmente será uma estratégia vencedora ou completa. No entanto, essa abordagem de “ver o rosto” é aquela que as pessoas parecem adotar quando são forçadas a trabalhar remotamente, como revelou nossa pesquisa de práticas de trabalho remotas imediatamente após bloqueios em todo o mundo.

Coordenação tácita

Existe uma maneira de superar esse dilema. Nossa pesquisa anterior sobre offshoring de desenvolvimento de software mostrou que recorrer a mecanismos de coordenação tácita, como um entendimento compartilhado de normas de trabalho e contexto, permite a coordenação sem comunicação direta.

A coordenação, nesse caso, acontece por meio da observação da ação dos demais funcionários e da capacidade de prever o que farão e precisarão com base em normas compartilhadas. Pode ocorrer de forma síncrona (onde, por exemplo, duas pessoas podem trabalhar no mesmo documento do Google durante o mesmo período) ou de forma assíncrona (quando as pessoas fazem transferências claras do documento e não trabalham nele quando o outro está).

As organizações de desenvolvimento de software frequentemente optam por esta solução e tendem a confiar amplamente em repositórios compartilhados e ferramentas de autoria de documentos, com sistemas para coordenar contribuições (por exemplo, integração contínua e ferramentas de controle de versão). Mas o GitLab é bastante único no setor com fins lucrativos na medida em que depende amplamente desse terceiro caminho, não apenas para sua codificação, mas para como a própria organização funciona. Ele se baseia principalmente no trabalho assíncrono porque seus funcionários estão distribuídos em vários fusos horários. Como resultado, embora a empresa use videoconferência, quase nenhum funcionário enfrenta um dia cheio de videoconferências.

Como funciona no GitLab

No centro do trabalho de engenharia que impulsiona o desenvolvimento de produtos do GitLab está o processo de fluxo de trabalho “git” inventado pelo fundador do Linux Linus Torvalds. Neste processo, um programador que faz uma contribuição para um código “bifurca” (copia) o código, de modo que não seja bloqueado para outros usuários, trabalha nele e então faz uma “solicitação de mesclagem” para que a versão editada substitua o original, e esta nova versão fica disponível para outras contribuições.

O processo combina a possibilidade de trabalho assíncrono distribuído com uma estrutura que verifica possíveis falhas de coordenação e garante clareza nos direitos de decisão. Completamente eletrônico (o que torna o trabalho remoto viável) e totalmente documentado, ele se tornou uma estrutura importante para o desenvolvimento de software distribuído em contextos com fins lucrativos e de código aberto.

O GitLab levou o git um passo adiante, aplicando-o também ao trabalho gerencial que envolve ambigüidade e incerteza. Por exemplo, o chefe de marketing do GitLab recentemente delineou uma visão para integrar o vídeo à estratégia da empresa para o ano seguinte. Ele solicitou feedback assíncrono de toda a empresa em uma janela de tempo fixa e, em seguida, agendou uma única reunião síncrona para concordar com uma versão final da visão. Essa visão desencadeou alterações de entrada de forma assíncrona de vários colaboradores nas páginas do manual da empresa relacionadas aos objetivos de marketing e resultados-chave que foram combinados na conclusão.

O alto grau de confiança do GitLab no trabalho assíncrono é possível ao respeitar as três regras a seguir até o nível da tarefa:

1. Separe a responsabilidade de fazer a tarefa da responsabilidade de declará-la realizada.

Em ambientes co-localizados, onde os funcionários estão no mesmo escritório, a comunicação fácil e as dicas sociais permitem que eles resolvam ambigüidades com eficiência e gerenciem conflitos em torno das responsabilidades e atribuições de trabalho. Em configurações remotas, no entanto, isso pode ser difícil. No GitLab, portanto, espera-se que toda tarefa tenha um Indivíduo Diretamente Responsável (IDR), que é responsável pela realização da tarefa e tem liberdade de como ela deve ser realizada.

O IDR, entretanto, não consegue decidir se a tarefa foi concluída. Essa função é responsabilidade de um “Mantenedor”, que tem autoridade para aceitar ou rejeitar as solicitações de mesclagem do IDR. A clareza sobre essas funções para cada tarefa ajuda a reduzir confusões e atrasos e permite que vários IDRs trabalhem em paralelo da maneira que quiserem em diferentes partes de um código, fazendo cópias locais (“bifurcação”). É função do mantenedor evitar mudanças desnecessárias e manter a consistência na versão de trabalho do documento ou código.

Em um contexto que não seja de software, digamos, no desenvolvimento da página do manual do GitLab sobre políticas de despesas, IDRs individuais, que poderiam ser qualquer pessoa na empresa, escreveriam políticas específicas da maneira que escolherem e suas contribuições seriam aceitas ou rejeitadas pelo CFO agindo na qualidade de mantenedor, que também poderia oferecer feedback (mas não direção) aos IDRs. Uma vez ao vivo, a página mesclada serve como a única fonte da verdade sobre as políticas de despesas, a menos ou até que outra pessoa faça uma nova proposta. Mais uma vez, o mantenedor aprovaria, rejeitaria ou ofereceria feedback sobre a nova proposta. Em contextos como este, esperaríamos que pessoas em cargos de gestão tradicionais servissem como mantenedores.

2. Respeite o princípio de “mudança mínima viável”.

Quando a coordenação é assíncrona, existe o risco de que as falhas de coordenação possam passar despercebidas por muito tempo – por exemplo, dois indivíduos podem estar trabalhando em paralelo no mesmo problema, tornando um de seus esforços redundante, ou uma pessoa pode estar fazendo alterações que são incompatíveis com os esforços de outro. Para minimizar esse risco, os funcionários são incentivados a enviar a alteração mínima viável – um estágio inicial, uma versão imperfeita de suas alterações sugeridas no código ou nos documentos. Isso torna mais provável que as pessoas percebam se o trabalho é incompatível ou está sendo duplicado. Obviamente, uma política de mudanças mínimas viáveis deve vir com uma política “sem vergonha” na entrega de uma saída temporariamente imperfeita. Em configurações remotas, o valor de saber o que o outro está fazendo o mais rápido possível é maior do que obter o produto perfeito.

3. Sempre se comunique publicamente.

Como os membros da equipe do GitLab costumam dizer, “não enviamos e-mail interno aqui”. Em vez disso, os funcionários postam todas as perguntas e compartilham todas as informações nos canais do Slack de suas equipes e, posteriormente, os líderes de equipe decidem quais informações precisam estar permanentemente visíveis para os outros. Em caso afirmativo, ele fica armazenado em um local disponível a todos na empresa, em um documento de “emissão” ou em uma página do manual online da empresa, que pode ser acessado por qualquer pessoa, dentro ou fora da empresa. Essa regra significa que as pessoas não correm o risco de duplicar ou mesmo destruir inadvertidamente o trabalho de seus colegas. Os gerentes dedicam muito tempo à curadoria das informações geradas por meio do trabalho dos funcionários que supervisionam e espera-se que saibam melhor do que os outros quais informações podem ser amplamente necessárias para uma futura equipe ou que seriam úteis para pessoas de fora da empresa.

Reconhecendo os limites da abordagem GitLab

Por mais bem implementado que seja, o trabalho remoto assíncrono desse tipo não pode fornecer muito em termos de interação social. Essa é uma grande falha, porque a interação social não é apenas uma fonte de prazer e motivação para a maioria, é também onde os “encontros aleatórios”, as trocas serendipitosas pelas máquinas de café e lobbies dos elevadores, criam oportunidades para que ideias e informações fluam e recombinem.

Para minimizar essa limitação, o GitLab fornece ocasiões para interação não relacionada à tarefa. A cada dia, os membros da equipe podem participar de uma das três reuniões sociais opcionais – escalonadas para incluir os fusos horários. As chamadas consistem em grupos de 8 a 10 pessoas em uma sala de chat de vídeo, onde são livres para discutir o que quiserem (o GitLab fornece uma pergunta inicial diária como quebra-gelo, caso seja necessário, como: “O que você fez no fim de semana?” ou “Qual foi o lugar mais legal que você já viajou e por quê?”).

Além disso, o GitLab tem grupos de folga social: salas de bate-papo temáticas das quais funcionários com interesses semelhantes podem participar (como: #cat, #dogs, #cooking, #mental_health_aware, #daily_gratitude, #gaming) e um canal #donut_be_strangers que permite estranhos que têm interesse mútuo em bater um café para se reunir.

Obviamente, os gerentes do GitLab não têm a ilusão de que esses grupos substituam perfeitamente os tipos de ricas interações sociais fora do trabalho que as pessoas consideram gratificantes. Mas eles ajudam a manter os funcionários conectados e, em uma época em que muitos funcionários trabalhavam sob regras de confinamento, isso se mostrou muito útil para manter o moral.

***

Trabalhar em casa de maneira eficaz vai além de apenas dar aos funcionários um laptop e uma conta do Zoom. Abrange práticas destinadas a compensar ou evitar as principais limitações do trabalho remoto, bem como aproveitar totalmente a flexibilidade que o controle remoto pode oferecer – trabalhando não apenas de qualquer lugar, mas a qualquer hora desejada. Nós nos concentramos no GitLab porque ele não apenas tem uma vasta experiência em trabalho remoto, mas também porque busca um modo incomum de resolver os desafios intrínsecos do trabalho remoto. Embora alguns dos principais processos do GitLab (como seu longo processo de integração remota para novas contratações) e vantagens (como a possibilidade de contratação em todo o mundo) não possam ser totalmente reproduzidos no curto prazo em empresas que serão apenas temporariamente remotas, existem outros que qualquer empresa pode implementar facilmente.

Artigo Traduzido da Harvard Business Review. Fonte Original: https://hbr.org/2020/09/remote-work-doesnt-have-to-mean-all-day-video-calls