Ryan Wilcox prosperou como um funcionário remoto por quase 10 anos e agora trabalha como consultor e desenvolvedor para empresas em todo o mundo como engenheiro do ApeeScape e fundador de sua própria firma . Ele está atualmente trabalhando em tempo integral para Fanzter , uma empresa de produtos da Web e iOS.
Começar um novo trabalho remoto ou trabalho em casa, seja um projeto de contrato ou um trabalho em tempo integral , pode ser um pouco intimidante se você está acostumado a ir ao escritório dia após dia.
Mas este estilo de emprego é crescendo em popularidade , com alguns muito empresas notáveis emprestando-lhe seu endosso.
Já trabalhei com sucesso remotamente usando essas ferramentas por anos em projetos de várias escalas e durações. Com esta postagem, espero enumerar algumas das melhores práticas que aprendi para trabalhar em uma variedade de situações. O guia remoto e trabalho de casa aqui varia de recomendações específicas para software e hardware a dicas para cumprir os prazos de sua equipe.
Eu não posso enfatizar o suficiente a importância de ter a configuração de escritório certa . Isso o tornará mais produtivo e parecerá mais profissional. Por exemplo, um fone de ouvido é crucial para evitar eco durante chamadas online; pequenas coisas como essa são muito úteis quando se trabalha como um controle remoto.
Aqui estão algumas ferramentas para trabalhar remotamente que considero essenciais dentro do meu próprio escritório em casa:
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 silencioso para hospedar teleconferências, reuniões, sessões de programação em pares etc., sem interrupções. Trabalhar apenas no sofá provavelmente não é uma boa solução de trabalho remoto de longo prazo.
Existem várias boas ferramentas de software 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:
Ao planejar reuniões, sempre confirme os dois fusos horários. E quando você receber um convite, você deve sempre fazer as contas de trás para frente e ter certeza de chegar aos mesmos números. Se a reunião envolve vários fusos horários, gosto de incluir também o horário UTC. Como todos devem saber seu deslocamento em relação ao UTC, esta é mais uma verificação para garantir que todos estejam na mesma página.
Eu estava em um tamanho decente Trilhos equipe há alguns anos. Vários membros da equipe trabalharam remotamente por pelo menos parte do tempo, e a cultura da equipe era que muito trabalho seria feito à noite. Eu propus a criação de uma sala de chat por meio do líder oficial da equipe na época, apontando para Campfire ou algum outro serviço de chat pago. Várias semanas se passaram sem nenhuma ação e eu decidi configurar uma sala de chat do Skype apenas com os desenvolvedores, para testar minha teoria de que uma sala de chat seria uma vantagem para a equipe. Esta experiência foi muito bem-sucedida - tão bem-sucedida que continuamos usando o bate-papo do Skype em vez de outra solução. Esta sala de chat do Skype ainda estava em uso quando deixei o projeto quase um ano depois. Às vezes, simples pode ser a melhor opção.
Posteriormente, durante um prazo crítico para o mesmo projeto, montamos uma sala de chat no Skype que incluía os desenvolvedores, analistas de negócios, os gerentes de projeto e o cliente, para que as dúvidas pudessem ser respondidas rapidamente pelo grupo geral. Embora não seja tão ativa quanto a sala de bate-papo exclusiva para desenvolvedores, ainda funcionou muito bem. Os chats do Skype podem ser moderados e controlados por alguns comandos de chat em grupo , configurando funções de chat e configurando permissões de acesso, o que permite que você realmente personalize a sala de chat para seu caso de uso. Mesmo uma configuração com tanta simplicidade pode melhorar a produtividade remota.
Gosto de saber três coisas de um rastreador de bug que estou usando:
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 todos os outros estão fazendo. Um marcador explícito no sistema de rastreador de bugs, afirmando: 'Sim, estou trabalhando ativamente nisso agora', pode introduzir um padrão e uma sensação semelhantes ao trabalho remoto.
Em segundo lugar, 'O que está em meu prato para o próximo lançamento?' significa, “Quais bugs eu sou responsável” ou “Quais bugs estou lidando”. Certamente há algumas idas e vindas em cada equipe, mas também é bom saber a quem perguntar se você quer pegar um bug ou precisa de ajuda para finalizar seus bugs para o lançamento.
Também é possível que sua equipe não trabalhe assim: por exemplo, seu fluxo de trabalho pode ser onde cada desenvolvedor recebe apenas um bug para começar e retira a pilha não atribuída quando seu bug é concluído. Isso também pode ser produtivo.
A “próxima versão do software” não precisa ser nada grande - estive em equipes nas quais a “próxima versão” significava “daqui a 3 dias, vamos lançar uma nova versão alfa para o cliente ”. Mas ainda é bom para todos saber o que está por vir neste novo lançamento. Especialmente se você retirar os tíquetes não atribuídos quando o tíquete atual for concluído.
Eu incluí algumas recomendações para rastreadores de bugs específicos na parte inferior da postagem.
Para alguns, a comunicação em equipe é a parte mais intimidante de trabalhar remotamente ou em casa. Mas isso só será um problema se você deixar estar .
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 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 com o apertar de um botão, ao invés de uma caminhada pelo escritório, pelo elevador, etc.
Essas dicas se aplicam mais a um funcionário gerenciado remotamente como parte de uma equipe maior, mas podem ser úteis se for apenas você como o único desenvolvedor.
Peguei várias dessas ideias do Wide Teams Podcast - Episódio 48 .
No início do dia, entre no IRC (ou em 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 hackers 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 as pessoas no chat e mantenha-se envolvido com seus colegas. Isso é diferente de quando você esbarra com as pessoas na sala de café, etc., etc. Você precisa explicitamente entrar em contato e manter o contato para que quando você confirmar o código ou precisar de ajuda, as pessoas estejam prontas.
Além de fazer sua presença ser sentida, você também deve avisar seus colegas remotos quando você estiver não trabalhando. Assim como em um escritório tradicional, você não quer desaparecer pelo resto do dia e deixar seus colegas esperando.
Se você está em uma equipe com vários outros desenvolvedores ou gerenciando funcionários remotos, faz sentido verificar quando você 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 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 do poço 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, diga às pessoas quando você estará de volta. Talvez seja 'Vejo todos vocês de manhã' ou 'Volto mais tarde para [x] terminar'. Mas, como as mensagens “Voltar em 1 hora”, elas definem uma certa expectativa à qual sua equipe pode se adaptar.
Há uma startup interessante chamada Sqwiggle que pode resolver alguns desses problemas (embora eu não tenha tentado ainda). 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 foto é ver, de relance, se você está no computador ou não. (Não há nada pior do que tentar bater um papo com alguém online e não ter uma resposta rápida. Eles estão conversando sobre alguma outra coisa? Afundado na zona? Não vê a notificação de bate-papo? No banheiro agora?). Eu ouvi sobre Sqwiggle no Wide Teams Podcast - Episódio 83 .
Os trabalhos de freelancer remotos são sempre diferentes. (Isso é parte do apelo!) Às vezes, você é trazido para uma equipe existente de desenvolvedores puramente como um aumento de equipe. Talvez essa equipe esteja junta há algum tempo e, nesse caso, já tenham práticas de comunicação estabelecidas.
Por outro lado, às vezes você é o único desenvolvedor no projeto, trabalhando com um cliente não técnico. Você pode configurar suas próprias melhores práticas de desenvolvimento de software e ter algum controle sobre como executar a operação. Abaixo estão algumas das melhores práticas da minha década ou mais de experiência de trabalho remoto. Principalmente, esses programas são direcionados a programas de meia semana (20 horas / semana) ou de semana inteira (40 horas / semana).
Há algo a ser dito sobre segurar reuniões standup para falar sobre o estado do projeto. Esses são muito comum em escritórios tradicionais , mas não há razão para que eles não sejam produtivos para a equipe remota: eles são apenas outra maneira de impor a comunicação entre as duas partes: cliente e desenvolvedor.
Uma reunião stand-up tradicional pergunta no que você estava trabalhando ontem, no que você vai trabalhar hoje e se há algum obstáculo em seu caminho. Este formato pode ou não funcionar devido ao tamanho da sua equipe: se for um único projeto de desenvolvedor, essas questões reais não farão sentido.
A frequência com que você deve ter uma reunião standup depende do tamanho e da cultura da equipe. No entanto, aqui estão minhas recomendações:
Com 1-3 desenvolvedores, essas questões são evidentes: você sabe o que cada desenvolvedor está fazendo porque é fácil rastrear seu trabalho individual enquanto eles vasculham os tickets: todo mundo sabe o que todo mundo está fazendo, porque simplesmente não há tantas pessoas fazendo trabalhos.
Com equipes remotas maiores, há mais partes em movimento: você quer ter certeza de que ninguém está pisando no dedo do pé virtual de ninguém ao replicar o trabalho ou fazer alterações incompatíveis.
Dada a estrutura de pagamento por semana do ApeeScape, duas reuniões por semana dão ao cliente tempo suficiente para expressar preocupações sobre o projeto antes que ele se sinta prejudicado em uma taxa semanal. Ter apenas uma reunião por semana pode significar que o cliente está insatisfeito com a qualidade do trabalho e o desenvolvedor não tem tempo para ajustar as entregas.
Equipes remotas avançadas pode ter outros métodos de 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 assim.
Para equipes pequenas, duas reuniões standup 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.
Dependendo do tamanho do projeto, gosto de entregas enviadas ao cliente semanalmente para projetos pequenos (1-2 desenvolvedores) e quinzenalmente para projetos maiores (mais de 3 desenvolvedores). Esse ritmo dá aos desenvolvedores tempo suficiente para concluir pedaços consideráveis de trabalho, incluindo uma interface (ou experiência de usuário aprimorada) para o cliente ver.
Para clientes não técnicos, a única métrica pela qual eles podem medir o progresso é o que podem ver na tela.
É 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 é muitas vezes a única coisa que importa para o cliente. Os clientes não técnicos não se importam que você tenha enviado 500 linhas de código esta semana ou que tenha dificuldade em interagir com algum serviço da web; a única métrica pela qual eles podem medir o progresso é o que 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 eles fiquem presos no trabalho de back-end por dois dias e não tenham tempo para terminar a interface, então eles não têm nada para mostrar o cliente.
Dependendo do tipo de projeto de software, nem todas essas versões do cliente serão lançadas ao público. Por exemplo, se você está trabalhando em um projeto Rails, pode querer implantar as mudanças aprovadas imediatamente; por outro lado, com um aplicativo móvel, você pode chamar uma versão de “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 melhores práticas do bug tracker remoto entram em jogo. Com o rastreamento de bugs, o cliente sabe:
O cliente sabe o que esperar deste lançamento, e os desenvolvedores sabem o trabalho que os espera.
Se sua equipe remota é madura o suficiente para usar implantação contínua e / ou Kanban então tudo bem. No entanto, essas duas técnicas são muito avançadas e mais adequadas para organizações com uma cultura forte baseada no desenvolvedor. A maioria das organizações, onde o desenvolvimento de software personalizado é visto como necessário, mas caro, provavelmente não está preparada para nenhuma dessas técnicas. Por que isso? Duas coisas que eu vi é que o cliente não consegue acompanhar o número de mudanças que os desenvolvedores desejam que eles revisem , ou as prioridades mudam muito rapidamente para que o desenvolvimento faça qualquer coisa .
Se acontecer de você entrar em uma equipe na qual estabelecerá as melhores práticas, listei algumas ferramentas abaixo para gerenciar seu trabalho remoto. Lembre-se de que essas 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.
Começar com o controle remoto ou trabalhar em casa pode ser um ajuste e tanto, tanto para você quanto para o cliente. Achei muito certo e muito errado. Mas, quando dá certo, pode ser uma excelente maneira para clientes ou empregadores resolverem o “Trituração de talentos” problema e criar um gama mais ampla de oportunidades para desenvolvedores que vivem fora dos grandes centros tecnológicos ou hubs de “startups”. Há um mundo inteiro de eficiência a ser obtido com os desenvolvedores trabalhando juntos remotamente com as práticas recomendadas corretas no local.