Trabalhar com um developer remoto pela primeira vez pode parecer enviar uma mensagem numa garrafa. Explicas o que precisas, esperas, e torces para que o que voltar se pareça com o que tinhas em mente. Quando não se parece, a frustração é real e o instinto é normalmente culpar o developer.
Às vezes isso é justo. Mas mais frequentemente o problema começou mais cedo, na forma como o projeto foi configurado e comunicado desde o início.
Aqui está o que realmente faz funcionar as relações com developers remotos.
Escreve o que queres antes de qualquer conversa acontecer
A maior fonte de expectativas desalinhadas é um briefing que só existe na tua cabeça. O que parece óbvio para ti não é óbvio para alguém que nunca viu o teu negócio antes. Antes de contactar um developer, escreve o que precisas, o que deve fazer, quem vai usar, e como é o sucesso.
Não precisas de um documento formal. Precisas de clareza suficiente para que um estranho o possa ler e perceber o que estás a tentar construir. Esse exercício por si só vai poupar horas de trocas de mensagens mais tarde.
Combina como vais comunicar antes do trabalho começar
Diferentes developers trabalham de forma diferente. Alguns preferem comunicação assíncrona por email ou uma ferramenta de gestão de projetos. Outros estão confortáveis com videochamadas regulares. Nenhum está errado, mas precisas de combinar isto antecipadamente em vez de descobrir a meio do projeto que as expectativas não coincidem.
Combina também as expectativas de tempo de resposta. Se esperas respostas em duas horas e o developer trabalha num fuso horário diferente, essa conversa precisa de acontecer no primeiro dia.
Dá feedback sobre o que foi entregue, não sobre o processo
Quando contratas um developer remoto, estás a contratar a sua experiência. Dizer-lhe como escrever o código é como contratar um arquiteto e depois ditar onde vai cada tijolo. Estás a pagar pelo julgamento dele.
O que deves absolutamente fazer é dar feedback claro sobre o que entregam. Faz o que pediste? Tem o aspeto certo? Falta alguma coisa? Sê específico, direto e rápido. Feedback vago como “não parece certo” é difícil de agir. Feedback específico como “o formulário deve redirecionar para uma página de obrigado após a submissão” não é.
Leva os marcos a sério
Dividir um projeto em marcos com pontos de aprovação é bom para ambos os lados. Tens visibilidade sobre o progresso sem precisar de estar envolvido em cada decisão. O developer obtém confirmação clara de que o trabalho está no caminho certo antes de avançar.
Quando um marco é entregue, revê-o corretamente e responde dentro de um tempo razoável. Deixar entregas por rever durante dias paralisa o projeto tanto quanto um developer que fica em silêncio.
Respeita os horários de trabalho e o tempo focado
Um bom developer precisa de blocos de tempo ininterrupto para fazer o seu melhor trabalho. Enviar mensagens ao longo do dia à espera de respostas instantâneas é contraproducente. Fragmenta a atenção dele e abranda o trabalho pelo qual estás a pagar.
Agrupa as tuas perguntas. Se tens cinco coisas a perguntar, envia-as juntas em vez de uma de cada vez ao longo do dia. Este é um pequeno hábito que faz uma diferença significativa na eficiência do trabalho.
Como é a boa colaboração remota na prática
Quando funciona bem, trabalhar com um developer remoto parece ter um membro de equipa capaz e independente com quem te reunes regularmente, não alguém que precisas de supervisionar. O trabalho fica feito. Os problemas são sinalizados cedo. Os prazos são cumpridos.
Esse resultado não depende apenas de contratar o developer certo. Depende também de seres o tipo de cliente para quem um bom developer consegue fazer o seu melhor trabalho.
Se procuras um developer remoto que comunica claramente e entrega sem precisar de ser gerido, entra em contacto.