Por que as equipes distribuídas são importantes e como construir uma

“Suponha que você está sozinho em uma startup e quer um parceiro. Você levaria muito tempo para encontrar o parceiro, certo? Ele seria metade da sua empresa. Por que você deveria levar menos tempo para encontrar um terço de sua empresa ou um quarto de sua empresa ou um quinto de sua empresa? Quando você está em uma startup, as dez primeiras pessoas determinarão se a empresa terá sucesso ou não. Cada um é 10% da empresa. Então, por que você não levaria o tempo necessário para encontrar todos os jogadores A? Se três não fossem tão bons, por que você iria querer uma empresa onde 30% do seu pessoal não fosse tão bom?” - Steve Jobs

Em 2003, o autor Michael Lewis publicou um livro chamado Moneyball: The Art of Winning an Unfair Game. À primeira vista, o livro é uma história clássica de azarão: um time de beisebol em dificuldades percebe que caçadores de talentos que confiam na sabedoria de décadas estão perdendo oportunidades de construir equipes vencedoras. Ao evoluir suas táticas de observação para incorporar ferramentas e práticas modernas, a equipe identifica e contrata uma lista de jogadores subestimados, alcançando um recorde de vitórias contra adversários com folhas de pagamento muito maiores.

A verdadeira lição do Moneyball é clara: seja você uma grande corporação ou um iniciante inexperiente procurando uma vantagem sobre um titular que pode gastar mais do que você, você tem a oportunidade de adaptar suas táticas e contratar reservatórios inexplorados de talentos de alta qualidade, reconhecendo quando a sabedoria convencional sobre a construção de equipes não reflete mais a realidade.

Empresas Jogam Moneyball Usando Equipes Distribuídas

Em nossa opinião, há uma clara oportunidade para as organizações jogarem “moneyball” em sua busca por talentos de alto ROI: capacite sua equipe para contratar funcionários remotos.

Mais de 43% dos trabalhadores dos EUA trabalharam remotamente no ano passado, um aumento substancial em relação aos 9% que disseram o mesmo em 1995.

Em 2016, a empresa de engajamento de funcionários TinyPulse realizou uma pesquisa com mais de 500 funcionários remotos e descobriu que eles estavam mais felizes, se sentiam mais valorizados e eram extremamente mais produtivos do que seus colegas locais. Mais de 43% dos trabalhadores dos EUA trabalharam remotamente no ano passado, um aumento substancial em relação aos 9% que disseram o mesmo em 1995. No total, as empresas que permitem o trabalho remoto demonstraram menos estresse, maior eficiência e menor rotatividade de sua força de trabalho.

Adaptar sua organização para acomodar equipes distribuídas não é tarefa fácil. Mas, em nossa opinião, manter o status quo apresenta um risco ainda maior. Acreditamos que as empresas que resistem à mudança para o controle remoto são como caçadores de talentos da velha guarda: estão fazendo um excelente trabalho seguindo bons conselhos de vinte anos atrás. Por outro lado, as organizações que adotam o trabalho remoto estão jogando dinheiro: todos seguirão seu exemplo em um futuro próximo, mas por enquanto são recompensados ​​com uma vantagem competitiva substancial.

Neste artigo, apresentamos as objeções comuns às equipes distribuídas e compartilhamos nossa experiência em lidar com essas armadilhas com cinco recomendações que abrangem as melhores práticas na contratação, medindo as métricas, gerenciamento, ferramentas e cultura corretas.

Preocupações comuns com equipes distribuídas

Executivos experientes podem ter um medo residual de equipes de desenvolvimento distribuído que decorre da experiência no início da era da terceirização. Executivos mais novos podem ser tentados a confiar na sabedoria convencional para dispensar equipes remotas. Ambos os grupos tendem a citar as seguintes preocupações:

• Qualidade: Há quase vinte anos, a primeira exposição a equipes distribuídas ocorreu no contexto de um modelo tradicional de terceirização, impulsionado inteiramente pela economia de custos. A colaboração parecia impossível: ferramentas que damos como garantidas hoje, como Slack ou GitHub, não existiam, as trocas de e-mail levavam dias por causa de problemas de fuso horário, a largura de banda era cara e, por algum motivo, todos ficaram surpresos quando o software criado pelo mais barato desenvolvedores que encontramos se mostraram péssimos.
• Visibilidade: Os gerentes de projeto odeiam surpresas. Esta é a razão pela qual um gerente de fábrica inspeciona a linha de produção regularmente, ou um capataz de construção se senta em uma mesa em um trailer no local de trabalho. É claro que não há muitos casos em que você precisa de proximidade física para inspecionar o progresso em um produto de software ou contratação de serviço profissional - além da proximidade de uma boa conexão Wi-Fi ou torre móvel - mas a presença manteve sua importância entre os gerentes de todos os tipos.
• Ortodoxia Ágil: Vemos muitas empresas considerando ou implementando ativamente uma transformação ágil. Como parte dessa transformação, eles tendem a buscar orientação para seus executivos em livros, coaches e empresas de consultoria Agile. Quando se trata de construir equipes, esses especialistas tendem a dizer a mesma coisa: “Suas equipes devem ser co-localizadas”. Este foi um bom conselho quinze anos atrás - de muitas maneiras, o Agile foi uma reação às condições acima que tornavam a colaboração quase impossível a distância e tornavam necessárias práticas rígidas de gerenciamento de projetos em cascata.

Graças em grande parte à tecnologia aprimorada para colaboração e comunicação, as condições que levaram a essas preocupações não existem mais. Ao empregar as cinco melhores práticas descritas abaixo, as organizações estarão bem equipadas para construir equipes distribuídas de alto desempenho e maximizar o potencial transformador do trabalho remoto.

1. Contrate para compatibilidade remota

Nem todo mundo é feito para o trabalho remoto. Pense nas características que você valoriza em um desenvolvedor de ponta: excelência em engenharia e técnica, capacidade de trabalhar bem em equipe, comunicação aberta e honesta. Avaliar como as habilidades sociais em particular se traduzirão em um ambiente remoto é um desafio, então aqui estão algumas características a serem observadas:

• Proativo: A proximidade física facilita a realização de check-ins frequentes; excluindo esse recurso, as melhores contratações são auto-iniciadas que não precisam de tarefas atribuídas ou orientação constante para fazer as coisas.
• Implacável na priorização: bons trabalhadores remotos têm um senso intuitivo do que é importante e do que não é em um determinado projeto, limitando-se ao que importa.
• Habilidades de escrita proficientes: A comunicação em equipes remotas geralmente é escrita, o que torna as habilidades de escrita especialmente cruciais para equipes remotas.

Onde você encontra essas superestrelas remotas? Pessoas com os atributos acima geralmente têm experiência em startups ou compromissos freelance anteriores que lhes permitem construir um histórico de conquistas em ambientes não estruturados.

2. Para gerenciar equipes distribuídas, crie um sandbox

Uma preocupação frequente que ouvimos sobre equipes de desenvolvimento distribuídas é a dificuldade de aplicar as normas da equipe, padrões e práticas de codificação e processos de gerenciamento de projetos. Em nossa experiência, as equipes produtivas são capacitadas e autogovernadas, com bastante liberdade para estabelecer padrões por conta própria.

As equipes remotas não são exceção, mas a gerência deve ter um cuidado especial para garantir que os controles estejam em vigor. Como princípio geral para gerenciar equipes distribuídas, gostamos de usar a analogia de um sandbox. As bordas da caixa representam limites para a equipe: restrições acordadas, como cerimônias de sprint, ferramentas e estruturas a serem usadas, expectativas de cobertura de código etc.

Em outras palavras, a estrutura e os processos de colaboração devem ser definidos com firmeza, mas o desenvolvimento de software é tanto arte quanto ciência, por isso é importante que os funcionários remotos tenham liberdade para serem criativos dentro da sandbox.

3. Treine os gerentes para acompanhar os resultados, não os resultados

Conscientemente ou não, alguns gerentes medem a produtividade pelo número de horas passadas em uma mesa em oposição aos resultados desse trabalho. Mas um desenvolvedor que gera milhares de linhas de código abaixo da média não deve ser considerado mais produtivo do que aquele que gera algumas centenas de linhas de código excelente no mesmo período de tempo.

Para equipes remotas em particular, é crucial que as métricas de produtividade meçam a qualidade dos resultados em vez de mera produção: quanto software bom enviamos no mês passado? Nossa velocidade de desenvolvimento é estável, previsível e acelerada ao longo do tempo? A equipe está demonstrando melhoria contínua? As equipes remotas devem ser avaliadas em relação às métricas corretas, pois os gerentes têm menos visibilidade do processo de fazer o trabalho em si e não têm como dar crédito parcial observando seus funcionários “mostrando o trabalho”.

4. Use as ferramentas certas

As ferramentas são a principal razão pela qual o trabalho remoto está prosperando hoje. Os aplicativos modernos de comunicação e colaboração são o suporte que dá suporte às equipes distribuídas para lidar com as armadilhas de eras anteriores. Gostamos de dizer que quando as pessoas estão no Slack, elas estão no escritório — aqui está nossa lista de ferramentas essenciais:

• Bate-papo em tempo real: o bate-papo em tempo real é uma ferramenta vital para uma equipe remota. Você deseja replicar a interação e a colaboração imediatas que você teria em uma equipe alocada. O bate-papo em tempo real não é apenas essencial para a comunicação, mas também é útil para construir uma cultura remota. Para que isso seja bem-sucedido, é vital que toda a comunicação da equipe seja centralizada em um único local – lembre-se, a sandbox precisa de paredes. Na Toptal, usamos o Slack, mas as alternativas incluem HipChat, Flowdock e Skype.
• Radiadores de informações: sem interações pessoais para socializar informações, você precisará de um wiki online e um mural de histórias para irradiar informações para a equipe. No desenvolvimento Agile ou Kanban, toda a equipe e todas as partes interessadas associadas devem ter acesso a informações imediatas sobre o status do desenvolvimento - histórias em andamento, aguardando testes, defeitos etc. A equipe também deve ter acesso a painéis para o pipeline de construção e status, cobertura de código e outros dados importantes. Como gerente remoto, você deseja uma única fonte de verdade para cada área de informação na qual a equipe e as partes interessadas confiam para obter o status.
• Videoconferência: o bate-papo por vídeo em tempo real é um complemento essencial para mensagens instantâneas — em nossa experiência, não há nada como conversar com outro ser humano. Na Toptal, usamos o Zoom, as chamadas Slack e, ocasionalmente, o Skype para reuniões individuais, reuniões de status e apresentações de código. As reuniões diárias de scrum por videoconferência são uma ótima maneira de construir a cultura e a confiança da equipe.

5. Cerimônias de Abraço

Você provavelmente tem várias cerimônias de equipe ocorrendo em pontos fixos em cada sprint – reuniões de planejamento e estimativa, revisão de código, demonstrações de software. Programe-os de forma que todos os membros da equipe, independentemente da localização, possam participar. Idealmente, a equipe terá várias horas por dia em que todos estarão online e trabalhando.

Embora seja natural se preocupar com fusos horários ao construir equipes distribuídas, em nossa experiência, uma pluralidade de pessoas que escolheram carreiras em desenvolvimento de software remoto prefere trabalhar fora do tradicional dia de trabalho das 9h às 17h - e geralmente são muito mais produtivas quando permitido fazer isso. Na medida do possível, permita que a equipe defina os horários que funcionam melhor para eles.

Conclusão: você já pode confiar em equipes distribuídas

Mesmo que sua organização não tenha utilizado diretamente um modelo de desenvolvimento distribuído, você provavelmente está aproveitando seus benefícios em um grau significativo: as chances são de que você esteja usando software de código aberto.

Por sua própria natureza, o desenvolvimento de código aberto foi distribuído desde o início. A inovação no mundo de código aberto ocorre em um ritmo impressionante, e as práticas de engenharia em evolução ajudam a impulsionar esse ritmo: um dos primeiros desafios que os primeiros projetos de código aberto resolveram foi a colaboração online e a transparência do processo para equipes distribuídas.

Esteja você seguindo a liderança do mundo do código aberto ou seguindo a sugestão de Michael Lewis para jogar "moneyball" no mundo do desenvolvimento de software e serviços profissionais orientados por talentos, considere as restrições que você impõe à sua organização, insistindo que eles só pode contratar de pools de talentos locais.

Uma mudança cultural dessa magnitude é um empreendimento significativo, mas você pode iniciar a transição imediatamente: deixe de lado a ortodoxia no escritório, dê boas-vindas às equipes distribuídas e permita que elas atinjam seu potencial fornecendo aos membros da equipe as métricas, gerenciamento , ferramentas e cultura para realizar o trabalho onde quer que estejam trabalhando.