O trabalho SumOne Team Member Handbook de SumOne está licenciado com uma Licença Creative Commons - Atribuição-CompartilhaIgual 4.0 Internacional.
Baseado no trabalho disponível em http://www.github.com/sumoners/s1-team-member-handbook.
Podem estar disponíveis autorizações adicionais às concedidas no âmbito desta licença em http://www.github.com/sumoners/s1-team-member-handbook.
Na SumOne trabalhamos com times mistos, onde parte dos seus colegas não trabalham do seu lado e podem estar em outra cidade, outro estado e até mesmo em outro país.
Nossa ideia com isso é de que nossa busca por talentos que consigam construir produtos que são referências globais não pode se limitar a nossa área de atuação geográfica. Temos quase certeza de que o raio de 20km em Florianópolis não é o lugar com a maior concentração de talentosos engenheiros, designers, administradores, você pega a ideia.
Essa abordagem, no entanto, trás diversos desafios consigo: enquanto trabalhando remotamente você pode trabalhar "a hora que quiser", com a roupa que quiser (de cueca e roupão, alguém?), na sua bat-caverna, a necessidade de trabalhar em equipe faz com que os desafios de comunicação se tornem exponencialmente mais complexos, já que não é possível passar pela mesa do colega e tirar uma dúvida ou fazer uma daily meeting onde cada um consiga falar de forma organizada (sim, sabemos como funciona...)
Para lidar com esse desafio, buscamos inspiração em empresas que trabalham com essa mesma dinâmica como 37 Signals, Zapier e Stripe. Baseados na experiência deles (não temos nenhuma ainda, em Abril de 2015), construimos uma série de guidelines que determinam três grandes e importantes escopos para times remotos:
- As suas atitudes como membro de um time remoto
- As ferramentas para nos mantermos sempre alinhados
- Os processos para que tudo funcione direito
Encontrou uma tecnologia nova? Um processo novo? Quer usar um lab day pra fazer uma câmera flutuante usando flubber e o seu brinquedo novo do Kickstarter para criar assistentes pessoais robóticos flutuantes?
Abra uma issue!
Sim, você precisa se adaptar e se esmerar para ser um bom membro em um time remoto. Queremos estabelecer aqui não regras e procedimentos mas sim um mindset que você precisa ter, jovem padawan.
Seja uma pessoa pró-ativa, que busca coisas para fazer ao invés de ficar esperando alguém te mandar fazer algo. Você sempre vai poder contar com uma liderança para te dar uma direção e auxílio para as tarefas mais importantes que você precisa fazer, mas não espere por uma ordem para começar a fazer algo!
A impossibilidade de cutucar as costas do colega para perguntar que diabos
aquele método #call_scarlett_johanson, já que ele pode estar do outro lado
do mundo, em outra Timezone (ou pode estar dormindo, de ressaca, vá saber), vai
gerar grandes dificuldades para resolver problemas.
Então aprenda a escrever efetivamente, comunicação formalizada e documentação
são a essência do sucesso para um time remoto!
Se tem uma coisa pra você levar para a vida desse documento é essa:
documente!
Você não vai poder tomar o cafézinho das 10 com os colegas de trabalho nem descer para comer uma coxinha de frango com um pão de queijo no posto que fica perto do escritório, nem mesmo a cervejinha das sextas-feiras você vai conseguir tomar com o seu time, então trate de socializar e aproveitar o seu tempo com a sua família e amigos (se esse for seu interesse, claro, sempre existe um World of Warcraft caso não seja ;) ).
Sim, Slack, quem não conhece vai adorar, quem já conhece ama. Com o Slack trocamos mensagens instantâneas, organizamos canais, equipes, etc.
Usamos o GitHub para fazer comentários em commits, pull requests e mantemos o wiki do projeto documentado com nossas escolhas em arquitetura e design de código (e outras coisas que são mais fáceis de entender lendo um documento do que olhando o código).
Precisa conversar com vídeo? Hangouts é a solução! Todos no escritório tem webcams e você como membro da equipe remota também precisa ter a sua!
O melhor lugar para documentar tudo o que não vai no GitHub (tudo que não é referente a código).
No Trello guardamos nosso Roadmap, Ideias, To-Dos e Tecnologias e Artigos bacanas. A única regra no Trello é a seguinte: Não crie um card sem adicionar uma descrição detalhada do seu conteúdo. É muito fácil esquecer o que "Refatorar código porcaria do Rajed" significa se não houver uma descrição clara. Ah, tem outra regra na verdade: siga o padrão! Se já existem outros cards, tome um tempinho para ver como eles estão organizados e como suas descrições estão escritas antes de sentar o dedo num card desconexo.
Usamos nosso blog interno para postar o que fizemos e o que vamos fazer, toda semana. É um substituto para o daily meeting que realizamos no dia-a-dia no escritório. A propósito, o time que trabalha no escritório continua com o daily, com a nova tarefa de escrever os seus Friday Posts para alinhar com o pessoal que trabalha remoto!
Criamos sistemas para conectar empresas e seus clientes, seria uma coisa absurda se nós não nos conectássemos aos nossos, certo? Toda semana, um engenheiro fica com dedicação exclusiva a dar suporte, 100% do tempo da semana. Isso faz com que os outros engenheiros consigam trabalhar focados e traz o time para bem próximo do cliente.
Esse engenheiro encarregado do suporte fica também encarregado de fazer um housekeeping, bugfixing, criando testes em áreas sem cobertura e outras atividades virtuosas enquanto não estiver resolvendo problemas de suporte.
Existem alguns problemas que só podem ser resolvidos por devs específicos. Quando uma buxa dessas chegar, o engenheiro de plantão no suporte vai ficar responsável por fazer uma "filtragem" do que é urgente e precisa interromper o sprint de alguém e o que pode esperar até o próximo sprint (ou até a próxima encarnação). Em cada sprint, temos espaço para apenas duas "atividades não planejadas" serem executadas, então o dev tem que usar esse "poder" com sabedoria.
Todo e qualquer pull request que esteja do GitHub deve passar por um code review de pelo menos um colega. Cutuque o colega no Slack e peça para ele revisar seu código. Só assim ele passa para o QA e você fica bonitão com sua to-do limpinha.
Um dia X da semana (precisamos definir) nos reunimos todos em um Hangout para fazermos pequenas lightning talks. Toda semana alguém é escolhido para falar a respeito de algo, sendo que nas semanas em que tivermos novos membros na equipe essas pessoas são automaticamente selecionadas. É uma boa hora pra trocar ideias, contar algumas piadas e aprender coisas novas com os colegas. Lightning talks duram, no máximo, 15 minutos, e o hangout em geral meia hora!
Todo mês você vai trocar ideias com o seu gerente, serão abordadas 4 coisas básicas:
- O que você está empolgado a respeito?
- O que te preocupa?
- Uma coisa que o gerente pode fazer melhor para você
- Uma coisa que você pode fazer melhor
Easy breezy, as conversas terão no mínimo meia hora, então prepare o gogó para trocar boas ideias!
Posts semanais (toda sexta-feira) no blog interno da empresa (P2 Theme) detalhando sem preguiça o que você entregou nessa semana e o que virá pela frente na semana que vem. Dessa forma sempre nos mantemos atualizados sobre o que está acontecendo na empresa de uma forma prática, rápida e dinâmica.
Importante: É seu papel não só postar mas também comentar, dar dicas, sugestões, etc nos posts dos colegas.
Pelo menos duas vezes ao ano precisamos fazer um encontro com toda a equipe. Vamos para algum lugar bacana passar alguns dias juntos e maquinar como vamos conquistar o mundo com nossas ideias e produtos mirabolantes! :)