Como trabalhar remotamente e ainda ser o melhor

O cinto de ferramentas do trabalhador remoto

Começar um novo trabalho remoto ou trabalhar em casa, seja um projeto de contrato ou um emprego em tempo integral, pode ser um pouco intimidante se você estiver acostumado a entrar em um escritório dia após dia.

Mas esse estilo de emprego está crescendo em popularidade, com algumas empresas muito notáveis ​​emprestando seus endossos.

Eu tenho trabalhado remotamente usando essas ferramentas há anos em projetos de várias escalas e durações. Com este post, espero enumerar algumas das melhores práticas que aprendi para trabalhar em uma variedade de situações. O guia remoto e de trabalho remoto aqui varia de recomendações específicas para software e hardware a dicas para cumprir os prazos de sua equipe.

A configuração remota ou de home office

Eu não posso enfatizar o suficiente a importância de ter a configuração certa do escritório. Isso o tornará mais produtivo e parecerá mais profissional. Por exemplo, um fone de ouvido é crucial para evitar o eco durante as chamadas online; pequenas coisas como esta percorrem um longo caminho quando se trabalha como controle remoto.

Aqui estão algumas ferramentas para trabalhar remotamente que considero essenciais dentro do meu próprio home office:

• Fone de ouvido. Eu realmente gosto de fones de ouvido com fio em particular porque eles não ficam sem bateria em momentos críticos. Você vai usá-lo muito, então certifique-se de obter algo confortável. Tenho dois fones de ouvido iMicro: um para minha mesa e outro que levo na bolsa do laptop. Como um fone de ouvido de bolsa para laptop, ele tem duas grandes qualidades: por ser alimentado por USB, não preciso me preocupar em manter as baterias carregadas e é muito barato substituí-lo se quebrar na minha bolsa. Na verdade, acho esse fone de ouvido um pouco desconfortável para longas chamadas de conferência; se você estiver fazendo muitos desses, recomendo o Corsair Vengeance 2000: um fone de ouvido sem fio confortável com capacidade de bateria, permitindo que você trabalhe o dia todo. (A propósito: nenhum destes são links de referência.)
• Lugar tranquilo para pensar , com uma porta que fecha – principalmente se você mora com outras pessoas, e principalmente se você tem uma família.
• Conexão de Internet estável ou boa conexão de backup. Por exemplo, eu tenho DSL e configuro o tethering no meu telefone se o DSL sair. Se você está constantemente tendo problemas com o Skype ou desconectando chamadas, está se tornando menos confiável e menos profissional aos olhos de outras pessoas que podem estar tentando gerenciar vários funcionários remotos.
• Skype . Isso é bom para teleconferências ad hoc, mensagens instantâneas com clientes ou até mesmo para criar salas de bate-papo com cerimônias baixas.
• SkypeOut , que permite atender e fazer chamadas do seu telefone para os contatos do Skype. Isso é incrível, especialmente para momentos em que você está longe do seu computador e (você calculou mal um tempo, o cliente tem uma emergência, etc.).
• Chaleira elétrica . Às vezes eu quero café quente, mas não quero atrapalhar meu fluxo para conseguir um pouco.
• Jarro de galão de água . Para a chaleira, ou para beber. Para longas sessões de codificação ou longas chamadas de conferência.

Alguns deles parecem óbvios, mas você ficaria surpreso com o número de controles remotos que não atingem todas as marcas aqui. Como desenvolvedores, precisamos de um espaço tranquilo para pensar, sem interrupções. E, como trabalhadores remotos, precisamos de um lugar tranquilo para realizar teleconferências, reuniões, sessões de programação em pares, etc., ininterruptamente. Apenas trabalhar no seu sofá provavelmente não é uma boa solução de trabalho remoto a longo prazo.

Ferramentas de software

Existem várias boas ferramentas de software disponíveis para complementar seu ambiente de desenvolvimento típico e ajudá-lo a superar os desafios associados ao trabalho remoto. Aqui estão alguns que eu realmente gosto:

• AwayFind , que é bom para e-mails urgentes, especialmente mensagens de última hora de um participante de uma reunião, pois encaminha suas mensagens para você via SMS.
• Conversor de fuso horário , para trabalhar com clientes e colegas em todo o mundo. Eu gosto de Time And Date's World Time Clock, Every Time Zone, World Time Buddy ou The Time Now para uma versão mais acessível para deficientes visuais.
• Salas de chat/IRC para todos da equipe. Isso pode ser formal (por exemplo, uma sala Campfire) ou apenas uma sala de bate-papo do Skype (no estilo Keep It Simple, Silly).
• Bug tracker – isso merece sua própria seção, então veja abaixo.

Eu estava em uma equipe Rails de tamanho decente há alguns anos. Vários membros da equipe trabalhavam remotamente por pelo menos parte do tempo, e a cultura da equipe era de que muito trabalho seria feito à noite. Propus a criação de uma sala de bate-papo por meio do líder da equipe oficial na época, apontando para o Campfire ou algum outro serviço de bate-papo pago. Várias semanas se passaram sem nenhuma ação e decidi montar uma sala de bate-papo no Skype apenas com os desenvolvedores, para testar minha teoria de que uma sala de bate-papo seria um trunfo para a equipe. Esse experimento foi muito bem-sucedido - tão bem-sucedido que continuamos usando o bate-papo do Skype em vez de outra solução. Essa sala de bate-papo do Skype ainda estava em uso quando deixei o projeto quase um ano depois. Às vezes, o simples pode ser a melhor opção.

Mais tarde, durante um prazo crítico para o mesmo projeto, montamos uma sala de bate-papo no Skype que incluía os desenvolvedores, analistas de negócios, os gerentes de projeto e o cliente, para que as perguntas pudessem ser respondidas rapidamente pelo grupo em geral. Embora não seja tão ativo quanto a sala de bate-papo exclusiva para desenvolvedores, ainda funcionou muito bem. Os bate-papos do Skype podem ser moderados e controlados por alguns comandos de bate-papo em grupo, definindo funções de bate-papo e definindo permissões de acesso, o que permite realmente personalizar a sala de bate-papo para seu caso de uso. Mesmo uma configuração de tal simplicidade pode melhorar a produtividade remota.

Práticas recomendadas de trabalho remoto: rastreamento de bugs

Eu gosto de saber três coisas de um rastreador de bugs que estou usando:

• No que estou trabalhando agora?
• O que está no meu prato para a próxima versão deste software?
• Quais são as entregas de toda a equipe para esta versão do software?

Cada um deles tem um propósito.

Primeiro, “No que estou trabalhando agora?”: Quando você trabalha em um escritório tradicional, você tem conversas de fundo – isso lhe dá uma ideia geral do que todo mundo está fazendo. Um marcador explícito no sistema do rastreador de bugs afirmando: “Sim, estou trabalhando ativamente nisso agora”, pode introduzir um padrão e sensação semelhantes ao trabalho remoto.

Em segundo lugar, "O que está no meu prato para o próximo lançamento?" significa, “Por quais bugs sou responsável” ou “Quais bugs estou lidando”. Há certamente algumas idas e vindas em todas as equipes, mas também é bom saber a quem perguntar se você quiser pegar um bug ou precisar de ajuda para finalizar seus bugs para o lançamento.

Também é possível que sua equipe não funcione assim: por exemplo, seu fluxo de trabalho pode ser onde cada desenvolvedor recebe apenas um bug para começar e escolhe a pilha não atribuída quando seu único bug é concluído. Isso pode ser produtivo também.

O "próximo lançamento do software" não precisa ser nada grande - eu estive em equipes onde o "próximo lançamento" significava "daqui a três dias, vamos lançar uma nova versão alfa para o cliente ”. Mas ainda é bom para todos saberem o que está por vir nesta nova versão. Especialmente se você retirar tickets não atribuídos quando seu ticket atual estiver completo.

Incluí algumas recomendações para rastreadores de bugs específicos na parte inferior do post.

Práticas recomendadas de trabalho remoto: comunicação em equipe

Para alguns, a comunicação em equipe é a parte mais intimidadora de trabalhar remotamente ou em casa. Mas isso só será um problema se você permitir .

Em um escritório, enquanto você passa por todos no caminho para o seu lugar, há um pouco de brincadeira, pessoas dizendo “Olá”. Seus colegas de trabalho sabem que você está no trabalho porque eles o veem, ali, em sua mesa, trabalhando.

Os trabalhadores remotos precisam ser um pouco mais explícitos – ninguém sabe que você está trabalhando a menos que você diga a eles . Mas se você estabelecer as práticas de comunicação corretas, seus colegas estarão disponíveis ao pressionar um botão, em vez de caminhar pelo escritório, descer o elevador etc.

Essas dicas se aplicam mais a um funcionário gerenciado remotamente como parte de uma equipe maior, mas podem ser úteis se você for o único desenvolvedor.

Fazendo sua presença ser sentida: não fique invisível

Peguei várias dessas ideias no episódio 48 do Wide Teams Podcast.

No início do dia, entre no IRC (ou qualquer ferramenta que sua equipe use) e diga “Olá” , converse sobre como estão os dias das pessoas, etc., etc. Mesmo que isso signifique entrar no IRC e perguntar sobre crianças, fins de semana, equipes esportivas ou hacking de fim de semana. Quando as pessoas sabem que você está trabalhando duro em casa, você não fica invisível. Construa um relacionamento e deixe as pessoas saberem que você está lá .

Converse com pessoas no chat e certifique-se de se envolver com seus colegas. Isso é diferente de quando você esbarra em pessoas na sala de café, etc., etc. Você precisa explicitamente entrar em contato e manter contato para que, quando você enviar código ou precisar de assistência, as pessoas estejam prontas.

Mensagens 'Dia de início', 'Hora do almoço' e 'Volto'

Além de fazer sua presença ser sentida, você também deve informar seus colegas de equipe remotos quando não estiver trabalhando. Assim como em um ambiente de escritório tradicional, você não quer desaparecer pelo resto do dia e deixar seus colegas pendurados.

Se você estiver em uma equipe com vários outros desenvolvedores ou gerenciando funcionários remotos, faz sentido fazer o check-in quando começar seu dia de trabalho. Um simples “Bom dia a todos” para que as pessoas saibam que você está em sua mesa pronto para começar a trabalhar no projeto, e não mais em casa ou na cama.

Enviar mensagens “Volto em 1 hora” para almoço ou pausas de trabalho durante o dia também é bom. O trabalho remoto é ótimo para muitas coisas, mas um cenário preocupante é que você faz uma pergunta ao seu colega e não recebe resposta. Eles não estão respondendo porque estão ausentes por 30 minutos? Ou porque eles estão no fundo da zona e não ouvem o bate-papo? Talvez em uma reunião? As mensagens “Volte em…” podem aliviar essas preocupações e suavizar o fluxo de trabalho.

Quando terminar a tarde, avise as pessoas quando voltará. Talvez seja "Vejo vocês todos de manhã", ou "Volto mais tarde esta noite para fazer [x]". Mas, assim como as mensagens “De volta em 1 hora”, elas definem uma certa expectativa à qual sua equipe pode se adaptar.

Existe uma startup interessante chamada Sqwiggle que pode resolver alguns desses problemas (embora eu ainda não tenha tentado). Além de tirar uma foto sua a cada poucos segundos, ele também permite que os membros da equipe cliquem na sua foto para iniciar o bate-papo por vídeo/áudio, além de fornecer um componente de bate-papo por texto. A ideia por trás da imagem é ver, de relance, se você está no computador ou não. (Não há nada pior do que tentar conversar com alguém online e não ouvir de volta rapidamente. Eles estão envolvidos com outra coisa? No fundo da zona? Não vê a notificação de bate-papo? No banheiro agora?). Ouvi falar do Sqwiggle no Wide Teams Podcast Episódio 83.

Em projetos onde você pode configurar as melhores práticas

Os shows de freelancer remotos são sempre diferentes. (Isso é parte do apelo!) Às vezes, você é trazido para uma equipe existente de desenvolvedores apenas para aumentar a equipe. Talvez essa equipe esteja junta há algum tempo e, nesse caso, já tenham estabelecido práticas de comunicação.

Por outro lado, às vezes você é o único desenvolvedor do projeto, trabalhando com um cliente não técnico. Você pode configurar suas próprias práticas recomendadas de desenvolvimento de software e ter algum controle sobre como executar a operação. Abaixo estão algumas práticas recomendadas da minha década ou mais de experiência de trabalho remoto. Principalmente, estes são direcionados para horários de meia semana (20 horas/semana) ou semana inteira (40 horas/semana).

Reuniões Stand Up

Há algo a ser dito sobre a realização de reuniões em pé para falar sobre o estado do projeto. Eles são muito comuns em escritórios tradicionais, mas não há motivo para não serem produtivos para a equipe remota: são apenas mais uma maneira de impor a comunicação entre as duas partes: cliente e desenvolvedor.

Uma reunião em pé tradicional pergunta no que você estava trabalhando ontem, no que vai trabalhar hoje e se há algum obstáculo em seu caminho. Esse formato pode ou não funcionar devido ao tamanho da sua equipe: se for um único projeto de desenvolvedor, essas perguntas reais não fazem sentido.

A frequência com que você deve ter uma reunião em pé depende muito do tamanho e da cultura da equipe. No entanto, aqui estão as minhas recomendações:

• 1-3 desenvolvedores: 2 reuniões em pé por semana
• 4+ desenvolvedores: reuniões diárias em pé

Com 1-3 desenvolvedores, essas perguntas são mais evidentes: você sabe o que cada desenvolvedor está fazendo porque é fácil acompanhar seu trabalho individual enquanto eles vasculham os tickets: todo mundo sabe o que todo mundo está fazendo, porque não há muitas pessoas fazendo trabalhar.

Com equipes remotas maiores, há mais partes em movimento: você quer ter certeza de que ninguém está pisando no calo de ninguém ao replicar o trabalho ou fazer alterações incompatíveis.

As equipes remotas avançadas podem ter outros métodos para manter todas as partes interessadas na mesma página sem agendar uma reunião real enquanto trabalham em casa. Eu ainda gosto de falar por telefone/Skype/Hangouts com alguém e ter uma reunião dessa maneira.

Para equipes pequenas, duas reuniões em pé por semana funcionam muito bem: as correções de curso são feitas rapidamente, mas os desenvolvedores ainda têm algo substancial para relatar durante cada reunião.

Entregando na próxima versão remotamente

Dependendo do tamanho do projeto, gosto de entregas enviadas ao cliente semanalmente para projetos pequenos (1-2 desenvolvedores) e quinzenalmente para projetos maiores (3+ desenvolvedores). Esse ritmo dá aos desenvolvedores tempo suficiente para concluir partes consideráveis ​​do trabalho, incluindo uma interface (ou experiência de usuário aprimorada) para o cliente ver.

É importante que os desenvolvedores lembrem, especialmente com clientes não técnicos, que o progresso que você pode visualizar com uma interface de usuário geralmente é a única coisa que importa para o cliente. Clientes não técnicos não se importam que você tenha enviado 500 linhas de código esta semana ou que tenha tido dificuldade em interagir com algum serviço da web; a única métrica pela qual eles podem avaliar o progresso é o que eles podem ver na tela . Isso não quer dizer que fazer um bom trabalho no back-end seja irrelevante, mas sim que você precisa tornar todo esse bom trabalho tangível aos olhos do cliente.

É por isso que gosto de entregas semanais ou quinzenais. Qualquer coisa menor do que isso muitas vezes coloca o desenvolvedor em uma situação difícil: talvez ele fique preso no trabalho de back-end por dois dias e não tenha tempo para terminar a interface, então não tem nada para mostrar ao cliente.

Dependendo do tipo de projeto de software, nem todas essas versões de cliente serão lançadas ao público. Por exemplo, se você estiver trabalhando em um projeto Rails, você pode querer implantar as alterações aprovadas imediatamente; por outro lado, com um aplicativo móvel, você pode chamar uma versão “1.3a10”, mas a versão atual é apenas parte do conjunto maior de recursos de uma nova versão 1.3 do software que será implantada posteriormente.

É aqui que as práticas recomendadas do rastreador de bugs remotos entram em ação. Com o rastreamento de bugs, o cliente sabe:

1. O que está no prato da equipe para esta entrega
2. Se foi concluído
3. Se o trabalho foi aprovado pelo cliente.

O cliente sabe o que esperar desta versão e os desenvolvedores sabem que trabalho está à sua frente.

Se sua equipe remota tiver maturidade suficiente para usar implantação contínua e/ou Kanban, tudo bem. No entanto, essas são técnicas muito avançadas que são mais adequadas para organizações com uma cultura forte baseada no desenvolvedor. A maioria das organizações, onde o desenvolvimento de software personalizado é considerado necessário, mas caro, provavelmente não está pronta para nenhuma dessas técnicas. Por que isso? Duas coisas que tenho visto é que o cliente não consegue acompanhar o número de mudanças que os desenvolvedores querem que eles revisem , ou as prioridades mudam muito rapidamente para que o desenvolvimento faça qualquer coisa .

Recomendações

Se por acaso você entrar em uma equipe onde estabelecerá as melhores práticas, listei algumas ferramentas abaixo para gerenciar seu trabalho remoto. Tenha em mente que estas são apenas minhas recomendações: certamente, este guia não é para todos; e se você não gosta dessas ferramentas, provavelmente existe uma ferramenta que se adapta melhor às suas necessidades.

• Planscope.io , no modo semanal. Este é um rastreador de tempo + rastreador de bugs + ferramenta de estimativa de projeto que envia e-mails diários aos clientes quando você trabalha em seu projeto e permite que eles vejam como as coisas estão indo em termos de progresso e orçamento. Isso é ótimo para projetos de 1-4 desenvolvedores/meses de tamanho.
• App Trajectory é um rastreador de bugs para equipes pequenas com foco em estimar e dividir o projeto em partes de uma a duas semanas (iterações). A Trajetória do Aplicativo pode informar quanto trabalho você está concluindo em uma iteração e quantas iterações até que todo o trabalho conhecido seja concluído. Isso é ótimo para projetos de 2 a 12 desenvolvedores/meses de tamanho.
• O Pivotal Tracker é uma ferramenta de rastreamento de bugs para clientes com foco em metodologias ágeis. Isso é ótimo se você estiver fazendo iterações formais do Agile ou tiver um tamanho de projeto medido em desenvolvedores/anos.
• FlowDock para bate-papo. O Flowdock oferece algumas vantagens em relação ao chat simples de IRC ou Skype: além de integrar-se a serviços populares, também permite marcar conversas para referência rápida posterior. O FlowDock também mantém uma lista de atividades de status (checkins de código, etc.) que são separadas dos chats gerais. (Ou seja, na interface da web, as atualizações de status automatizadas estão à esquerda, enquanto os bate-papos estão à direita.)
• Novamente, Campfire também é ótimo para bate-papo.

Conclusão

Começar a trabalhar remotamente ou em casa pode ser um ajuste e tanto, tanto para você quanto para o cliente. Eu tive que dar muito certo, e muito errado. Mas, quando der certo, pode ser uma excelente maneira de clientes ou empregadores resolverem o problema da “crise de talentos” e criar uma gama mais ampla de oportunidades para desenvolvedores que moram fora dos grandes centros tecnológicos ou hubs de “startup”. Há todo um mundo de eficiência a ser obtido com desenvolvedores trabalhando juntos remotamente com as melhores práticas corretas no local.