Trabalho remoto não precisa significar chamadas de vídeo o dia todo

A crise da Covid-19 distanciou as pessoas do local de trabalho, e os empregadores, de modo geral, embora às vezes com relutância, aceitaram que as pessoas podem trabalhar efetivamente 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 aterem ao dia de trabalho convencional. A mensagem é que trabalhar em casa não tem problema e pode até ser muito eficiente, desde que as pessoas participem de chamadas de vídeo com todos os outros durante o dia. No entanto, os funcionários costumam ter dificuldades com o "dia de trabalho" quando trabalham em casa, porque muitos precisam lidar com as solicitações conflitantes de seus familiares, que também estão em casa. Então, qual é a eficácia do trabalho em casa se todos ainda estão trabalhando de acordo com o relógio? É possível se livrar do 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 vínculos com o local de trabalho físico. O desafio para o GitLab Desde sua fundação em 2014, o GitLab mantém uma equipe totalmente remota que agora conta com mais de 1.300 funcionários espalhados por mais de 65 países. A maneira "git" de trabalhar usa ferramentas que permitem que os funcionários trabalhem em projetos em andamento onde quer que estejam no mundo e no horário que preferirem. A ideia é que, como as "9 às 5" estão sempre 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 exclusivos com implicações organizacionais abrangentes. A maneira mais natural de distribuir o trabalho entre os locais é torná-lo modular e independente, de modo que haja pouca necessidade de coordenação direta - os trabalhadores 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 em atividades relacionadas ao desenvolvimento e à inovação, em que 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, pois oferece duas virtudes: sincronicidade e riqueza de mídia. O intervalo de tempo na interação entre duas ou mais pessoas é quase zero quando elas estão localizadas e, embora o conteúdo da conversa possa ser o mesmo tanto em ambientes presenciais quanto virtuais, a tecnologia pode não ser totalmente capaz de transmitir dicas sociais suaves e contextuais 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 a simples tentativa de replicar on-line (por meio de vídeo ou bate-papo por voz) o que aconteceu naturalmente em ambientes presenciais provavelmente não será uma estratégia vencedora ou completa. No entanto, essa abordagem de "ver o rosto" é a que as pessoas parecem adotar quando são forçadas a trabalhar remotamente, conforme revelou nossa pesquisa sobre práticas de trabalho remoto logo após os lockdowns em todo o mundo. Coordenação tácita Há uma maneira de superar esse dilema. Nossa pesquisa anterior sobre a terceirização no exterior do desenvolvimento de software mostrou que o uso de mecanismos de coordenação tácitos, como a compreensão compartilhada das normas e do contexto de trabalho, permite a coordenação sem comunicação direta. A coordenação, nesse caso, ocorre por meio da observação da ação de outros funcionários e da capacidade de prever o que eles farão e precisarão com base em normas compartilhadas. Isso pode ocorrer de forma síncrona (quando, por exemplo, duas pessoas podem trabalhar no mesmo documento do Google durante o mesmo período) ou assíncrona (quando as pessoas fazem transferências claras do documento e não trabalham nele quando a outra pessoa está trabalhando). As organizações de desenvolvimento de software geralmente optam por essa solução e tendem a confiar amplamente em repositórios compartilhados e ferramentas de criação de documentos, com sistemas para coordenar as contribuições (por exemplo, integração contínua e ferramentas de controle de versão). No entanto, o GitLab é único no setor com fins lucrativos no que se refere à extensão da dependência desse terceiro caminho, não apenas para sua codificação, mas para o funcionamento da própria organização. A TI se apóia particularmente 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 reuniões por vídeo. 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. Nesse processo, um programador que faz uma contribuição para um código "bifurca" (copia) o código, para que ele não fique bloqueado para outros usuários, trabalha nele e, em seguida, faz uma "solicitação de mesclagem" para que a versão editada substitua a original, e essa 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. Totalmente eletrônico (o que viabiliza o trabalho remoto) 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 ambiguidade e incerteza. Por exemplo, o chefe de marketing do GitLab recentemente delineou uma visão para a integração de vídeo na estratégia anual da empresa. Ele solicitou feedback assíncrono de toda a empresa dentro de uma janela de tempo fixa e, em seguida, agendou uma única reunião síncrona para chegar a um acordo sobre a versão final da visão. Essa visão desencadeou mudanças assíncronas de entrada de vários colaboradores nas páginas do manual da empresa relacionadas aos objetivos de marketing e aos principais resultados que foram mesclados após a conclusão. O alto grau de confiança do GitLab no trabalho assíncrono é possível graças ao respeito às três regras a seguir, até o nível da tarefa: 1. Separar a responsabilidade de realizar a tarefa da responsabilidade de declará-la concluída. Em ambientes co-localizados, onde os funcionários estão no mesmo escritório, a facilidade de comunicação e os sinais sociais permitem que eles resolvam ambiguidades de forma eficiente e gerenciem conflitos em torno de responsabilidades e atribuições de trabalho. Em ambientes remotos, no entanto, isso pode ser difícil. No GitLab, portanto, espera-se que cada tarefa tenha um Indivíduo Diretamente Responsável (DRI), que é responsável pela conclusão da tarefa e tem liberdade sobre como ela deve ser executada. O DRI, no entanto, não decide se a tarefa foi concluída. Essa função é de responsabilidade de um "Mantenedor", que tem autoridade para aceitar ou rejeitar as solicitações de mesclagem do DRI. A clareza dessas funções para cada tarefa ajuda a reduzir confusões e atrasos e permite que vários DRIs trabalhem em paralelo, da maneira que quiserem, em diferentes partes de um código, fazendo cópias locais ("forking"). A função do Mantenedor é evitar alterações 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, por exemplo, no desenvolvimento da página do manual do GitLab sobre políticas de despesas, os DRIs individuais, que poderiam ser qualquer pessoa da empresa, escreveriam políticas específicas da maneira que desejassem, e suas contribuições seriam aceitas ou rejeitadas pelo CFO, agindo na capacidade de Mantenedor, que também poderia oferecer feedback (mas não direção) aos DRIs. Uma vez ativa, a página mesclada serve como a única fonte de 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 esse, esperamos que pessoas em cargos de gerência tradicionais atuem como Mantenedores. 2. Respeitar o princípio da "mudança mínima viável". Quando a coordenação é assíncrona, existe o risco de que as falhas de coordenação não sejam detectadas por muito tempo - por exemplo, duas pessoas podem estar trabalhando em paralelo no mesmo problema, tornando um dos esforços redundante, ou uma pessoa pode estar fazendo alterações incompatíveis com os esforços de outra. 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 das 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 acompanhada de uma política de "não ter vergonha" de entregar um resultado temporariamente imperfeito. Em ambientes remotos, 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ós não enviamos e-mails internos aqui". Em vez disso, os funcionários publicam 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 ficar permanentemente visíveis para os outros. Se for o caso, elas são armazenadas em um local disponível para todos na empresa, em um documento de "problema" ou em uma página do manual on-line 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 até mesmo destruir inadvertidamente o trabalho de seus colegas. Os gerentes dedicam muito tempo à curadoria das informações geradas pelo 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 equipe futura ou que seriam úteis para pessoas de fora da empresa. Reconhecendo os limites da abordagem do 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 falha importante, pois a interação social não é apenas uma fonte de prazer e motivação para a maioria, mas também é onde os "encontros aleatórios", as trocas de ideias nas máquinas de café e nos saguões dos elevadores, criam oportunidades para que ideias e informações fluam e se recombinem. Para minimizar essa limitação, o GitLab oferece ocasiões de interação não relacionadas à tarefa. Todos os dias, os membros da equipe podem participar de uma das três chamadas sociais opcionais - escalonadas para incluir os fusos horários. As chamadas consistem em grupos de 8 a 10 pessoas em uma sala de bate-papo com vídeo, onde podem discutir o que quiserem (o GitLab fornece uma pergunta inicial diária como quebra-gelo, caso necessário, como: "O que o senhor fez no fim de semana?" ou "Qual foi o lugar mais legal que o senhor já viajou e por quê?"). Além disso, o GitLab tem grupos sociais no Slack: salas de bate-papo temáticas das quais os 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 que estranhos que tenham um interesse mútuo em ter uma conversa de café se reúnam. É claro que os gerentes do GitLab não têm a ilusão de que esses grupos substituem perfeitamente os tipos de interações sociais ricas fora do trabalho que as pessoas consideram gratificantes. Mas eles ajudam a manter os funcionários conectados e, em um momento em que muitos funcionários estão trabalhando sob regras de confinamento, isso tem se mostrado muito útil para manter o moral. *** Trabalhar em casa de forma eficaz vai além de apenas dar aos funcionários um laptop e uma conta Zoom. TI engloba práticas destinadas a compensar ou evitar as principais limitações do trabalho remoto, bem como aproveitar totalmente a flexibilidade que o trabalho remoto pode oferecer - trabalhar não apenas de qualquer lugar, mas em qualquer horário desejado. 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 contratar em todo o mundo) não possam ser totalmente reproduzidos no curto prazo em empresas que serão apenas temporariamente remotas, há outros que qualquer empresa pode implementar facilmente.

Trabalho remoto não precisa significar chamadas de vídeo o dia todo

Resumo.

Partner Center