Como criar e gerir uma equipa de engenharia remota a partir da Europa

Já escolheste um parceiro e um modelo de colaboração. Se ainda não, começa por como avaliar um parceiro nearshore na Europa e pela comparação dos três modelos de colaboração. Este artigo trata do que vem depois do contrato: a mecânica do dia a dia para criar e gerir uma equipa de engenharia remota com engenheiros em Portugal, quer o resto da tua empresa esteja em Berlim, quer em Boston.

As equipas remotas raramente se desviam porque os engenheiros são fracos. Desviam-se porque as regras por defeito nunca foram escritas: ninguém decidiu quando é que uma mensagem precisa de resposta, onde fica uma decisão, o que significa "feito" ou que horas pertencem às reuniões. Cada secção termina com algo que podes copiar para o teu repositório esta semana.

Faz primeiro as contas aos fusos horários

Portugal continental (Lisboa, Porto) usa UTC+0 no inverno (WET) e UTC+1 no verão (WEST). Face às cidades com que é mais provável trabalhares, o Porto está:

• Londres: à mesma hora, todo o ano.
• Berlim, Paris, Madrid, Amesterdão, Varsóvia: uma hora atrás, todo o ano.
• Helsínquia, Atenas, Bucareste: duas horas atrás, todo o ano.
• Nova Iorque: cinco horas à frente durante a maior parte do ano.
• Chicago, Denver, São Francisco: seis, sete e oito horas à frente.

Os desfasamentos europeus nunca mudam, porque a UE e o Reino Unido mudam a hora no mesmo instante: às 01:00 UTC do último domingo de março e do último domingo de outubro. Os EUA mudam às 02:00 hora local do segundo domingo de março e do primeiro domingo de novembro. Entre essas datas, a diferença transatlântica é uma hora mais curta. Em 2027, o Porto está quatro horas à frente de Nova Iorque de 14 a 28 de março e de 31 de outubro a 7 de novembro, e os restantes desfasamentos norte-americanos da lista encolhem uma hora nessas mesmas semanas. A maior parte do Arizona nunca muda a hora, por isso Phoenix está sete horas atrás do Porto no inverno e oito no verão.

Essas semanas estragam as reuniões recorrentes. Um evento de calendário fica preso ao fuso horário em que foi criado, por isso uma reunião criada em Nova Iorque para as 11:00 (16:00 no Porto) aparece às 15:00 no Porto durante essas semanas. Decide que relógio manda em cada reunião recorrente, deixa-o por escrito e avisa o outro lado antes de cada mudança.

Um exemplo prático

Parte do princípio de que toda a gente trabalha das 09:00 às 18:00 hora local, com o almoço incluído. A janela partilhada vai do início mais tardio ao fim mais cedo, depois de pôr ambos no mesmo relógio:

• Porto e Nova Iorque: as 09:00 em Nova Iorque são as 14:00 no Porto, e o Porto para às 18:00, por isso a janela partilhada é das 14:00 às 18:00 hora do Porto (das 09:00 às 13:00 em Nova Iorque). Quatro horas, cinco nas semanas de desencontro.
• Porto e Chicago: três horas, quatro nas semanas de desencontro.
• Porto e São Francisco: uma hora, duas nas semanas de desencontro.
• Porto e Berlim: oito horas. Porto e Helsínquia: sete.

Agora desconta o almoço. Se em Nova Iorque almoçam às 12:00, são 17:00 no Porto, e as quatro horas passam a três úteis. Se os engenheiros do Porto aceitarem trabalhar das 11:00 às 20:00, a janela com Nova Iorque sobe para seis horas e São Francisco fica com três. Isso sai dos fins de dia dos engenheiros, por isso vai para o acordo escrito e é revisto; nunca se dá por adquirido.

Para verificares os teus próprios números em qualquer data (Python 3.9 ou posterior; no Windows, corre primeiro pip install tzdata):

from datetime import date, datetime, time, timedelta
from zoneinfo import ZoneInfo

def overlap_hours(day, a, b):
    """a and b are (timezone, start, end) working days on the same date."""
    def window(tz, start, end):
        zone = ZoneInfo(tz)
        return datetime.combine(day, start, zone), datetime.combine(day, end, zone)
    a_start, a_end = window(*a)
    b_start, b_end = window(*b)
    shared = min(a_end, b_end) - max(a_start, b_start)
    return max(shared / timedelta(hours=1), 0)

porto = ("Europe/Lisbon", time(9), time(18))
new_york = ("America/New_York", time(9), time(18))
for day in [date(2027, 1, 18), date(2027, 3, 22), date(2027, 7, 19)]:
    print(day, overlap_hours(day, porto, new_york))

Imprime 4.0 para janeiro, 5.0 para a semana de desencontro de março e 4.0 para julho.

Agendar dentro da sobreposição

• Usa no máximo metade da sobreposição em reuniões agendadas. Guarda o resto para desbloquear: pair programming, uma chamada rápida sobre uma revisão encravada.
• Põe a sobreposição nos calendários das duas equipas como um bloco com nome, para que ninguém a ocupe.
• Tudo o resto é assíncrono por defeito: estado, code review, propostas de design.
• Uma pergunta feita depois da sobreposição é respondida na manhã seguinte, por isso cada engenheiro tem sempre um segundo ticket pronto.

Põe o acordo de trabalho por escrito

O acordo de trabalho é um ficheiro curto no repositório, WORKING_AGREEMENT.md, alterado através de pull requests, tal como o código. Numa equipa dedicada com o seu próprio tech lead, quem é dono dele é o tech lead; numa team extension, é o teu engineering manager. Os valores abaixo são um ponto de partida; o que importa é que os dois lados os tenham aceitado por escrito.

• Horário comum: a sobreposição, indicada nos dois fusos horários (14:00–18:00 Porto, 09:00–13:00 Nova Iorque), com as semanas de desencontro assinaladas.
• Chat: resposta em menos de uma hora durante o horário comum. Fora dele, não se espera resposta.
• Revisão de pull requests: primeira revisão no prazo de um dia útil depois de marcado como pronto.
• Urgente: a ferramenta de paging, nunca o chat. Se não justifica um alerta, não é urgente.
• Decisões: tudo o que muda uma interface, uma dependência ou um modelo de dados leva um registo de decisão em docs/adr/, revisto como pull request. Uma decisão tomada numa chamada não conta até estar escrita lá.
• Definition of done: merge feito, testes verdes na CI, lançado em produção (atrás de uma flag, se for preciso), monitorização ativa, runbook atualizado e ticket ligado à alteração.
• On-call: quem está na rotação, que horas cobre cada região, o caminho de escalamento e como são compensadas as horas de on-call e o descanso a seguir, acordado por escrito com o teu parceiro antes do primeiro turno.
• Feriados: um calendário partilhado com os feriados dos dois países. Os de Portugal não coincidem com os dos EUA nem com os alemães, e cada município acrescenta o seu: 13 de junho em Lisboa, 24 de junho no Porto.

Um registo de decisão não precisa de ser longo:

docs/adr/0007-move-background-jobs-to-postgresql.md

Status:       accepted, 2027-02-03
Context:      what forces a decision now, in five lines or fewer
Options:      what was considered, one line each
Decision:     what we will do
Consequences: what gets easier, what gets harder, what we will watch
Review:       link to the pull request where this was discussed

Quem faltou à chamada, ou quem chegar no próximo ano, consegue ler porquê.

Se quiseres uma segunda opinião antes de pôr isto em prática, a nossa avaliação gratuita de equipas nearshore analisa exatamente estas peças: as tuas horas reais de sobreposição ao longo do ano, o teu rascunho de acordo de trabalho e onde se estão a perder decisões entre fusos horários.

Um processo de recrutamento que teste o trabalho remoto

O teu parceiro faz a primeira triagem dos candidatos. Mesmo assim, fazes o teu próprio processo com a lista curta, e ele deve testar o trabalho tal como vai ser feito: por escrito, com diferença horária e sobre código.

1. 1Uma amostra de trabalho sobre código realista. Um repositório pequeno parecido com o teu: um serviço com um teste a falhar, um relatório de bug vago e um pequeno pedido de funcionalidade. Limita-a a três horas, ou paga-a se precisar de mais. Pede um pull request com descrição.
2. 2Uma sessão de pair programming sobre a própria entrega. De sessenta a noventa minutos, remota, com as ferramentas que a tua equipa usa todos os dias. Expande a funcionalidade com o candidato ou corrige com ele algo levantado na revisão. Observa como raciocina em voz alta, como aceita uma sugestão e como diz "não sei".
3. 3Uma troca por escrito. Deixa uma lacuna deliberada no enunciado da amostra de trabalho e vê se o candidato pergunta antes de adivinhar, e como.

Avalia a escrita com a mesma seriedade que o código:

• Primeiro a conclusão, depois o raciocínio.
• Os pressupostos ficam explícitos onde o enunciado era ambíguo.
• A descrição do pull request permite a um revisor noutro fuso horário aprová-lo sem chamada: o que mudou, porquê, como foi testado e o que fica de fora.
• As mensagens de commit explicam a intenção, não só o diff.

Esquece os enigmas de algoritmos e os trabalhos para casa de vários dias sem pagamento. Nenhum mostra como alguém trabalha no teu código, e o segundo afasta precisamente os engenheiros séniores que têm outras opções.

Onboarding: um pull request com merge na primeira semana

Quase todo o trabalho de onboarding pode ser feito antes de o engenheiro começar.

• Antes do primeiro dia: contas, acesso ao repositório e à CI, chat, o gestor de tickets, acesso só de leitura ao staging, o gestor de palavras-passe e um portátil que cumpra a tua política de dispositivos. Uma pessoa é dona dessa checklist e fecha-a antes da data de entrada.
• Primeiro dia: o engenheiro clona o repositório, corre um único comando documentado (make dev, um dev container, um ficheiro compose) e tem a aplicação a correr localmente com dados de teste. Cada passo que falha é um bug do onboarding, e corrigir a documentação é o seu primeiro commit.
• Um buddy designado: uma pessoa, idealmente com sobreposição total, a quem se tira carga do sprint nas duas primeiras semanas. "Pergunta a qualquer um" significa não perguntar a ninguém.
• Primeira semana: um pull request com merge. Escolhe a tarefa antes da data de entrada: pequena, real e que passe pelo caminho do deploy. O que importa é o ciclo: branch, teste, CI, revisão, merge, deploy. O tempo que esse pull request espera por revisão é a primeira medição do teu próprio processo.

Depois, um plano 30-60-90 com resultados que consigas verificar:

• Dia 30: já fez merge de vários pull requests numa área, reviu o de outra pessoa, fez um deploy e acompanhou um turno de on-call, se a função o incluir.
• Dia 60: levou uma pequena funcionalidade do ticket à produção, escreveu ou atualizou um registo de decisão e entrou na rotação de revisões.
• Dia 90: é o primeiro revisor de um componente, apresenta o seu próprio trabalho na demo e é dono do documento de onboarding para a próxima entrada.

Mantém síncrono só o que precisa de o ser

A sobreposição é o teu recurso mais escasso. Gasta-a no que corre mal por escrito:

• Síncrono: planeamento semanal, retros, discussões de design em que há mesmo desacordo, 1:1, resposta a incidentes e pair programming para desbloquear.
• Assíncrono: o estado diário (publicado no início do dia de cada pessoa: feito, a seguir, bloqueios), code review, propostas de design e anúncios.

As demos continuam ao vivo, dentro da sobreposição, apresentadas pelos engenheiros que construíram o que se mostra. Se só a equipa interna faz demos, a equipa remota torna-se invisível para quem define as prioridades.

Nas retros, recolhe os temas por escrito antes, para que a reunião seja gasta a discutir. Alterna o facilitador entre locais e transforma cada ação num ticket com responsável. Uma ação que volta três retros seguidas já é um sinal por si só.

Se uma conversa no chat já foi e voltou três vezes sem convergir, passa-a para uma chamada dentro da sobreposição e publica o resultado na conversa.

Mede e vigia a deriva

Tira uma linha de base no primeiro mês a partir dos sistemas que já tens e revê-a de poucas em poucas semanas. Compara a equipa remota consigo própria ao longo do tempo e com a tua equipa interna no mesmo código, não com o benchmark de outra empresa.

• Lead time: do primeiro commit até estar a correr em produção.
• Tempo de revisão: desde que o pull request é marcado como pronto até à primeira revisão, separado conforme autor e revisor partilhem ou não a região. É aqui que a fricção horária aparece primeiro.
• Tempo de onboarding: dias desde a data de entrada até ao primeiro pull request com merge, e até à primeira alteração em produção feita de forma autónoma. Mede o teu onboarding, não a pessoa.
• Retenção: quem saiu e quantos componentes têm uma única pessoa que alguma vez reviu alterações neles.

Se exportares os dados de pull requests da tua plataforma Git para PostgreSQL, os números de revisão saem de uma consulta:

SELECT
  date_trunc('week', ready_at) AS week,
  author_region = reviewer_region AS same_region,
  count(*) AS pull_requests,
  percentile_cont(0.5) WITHIN GROUP (ORDER BY first_review_at - ready_at) AS median_to_first_review,
  percentile_cont(0.5) WITHIN GROUP (ORDER BY merged_at - ready_at) AS median_to_merge
FROM pull_requests
WHERE merged_at IS NOT NULL
GROUP BY 1, 2
ORDER BY 1, 2;

A deriva aparece antes dos prazos falhados. Vigia:

• O tempo de revisão entre regiões a subir enquanto o da mesma região se mantém.
• Pull requests cada vez maiores, porque as pessoas acumulam trabalho quando a revisão é lenta.
• Perguntas que passam dos canais da equipa para mensagens privadas, ou que deixam de ser feitas.
• Um estado escrito cada vez mais curto e vago: "continuo no ticket".
• Decisões tomadas em chamadas sem registo de decisão, que o outro lado descobre depois.
• Engenheiros remotos que recebem tickets mas nunca problemas, e que deixaram de apresentar nas demos.
• Mensagens enviadas às 21:00 hora do Porto a tornarem-se normais.

Um destes sinais merece ser levantado no próximo 1:1. Vários ao mesmo tempo costumam querer dizer que o acordo de trabalho deixou de ser cumprido: revê-o em conjunto em vez de acrescentares mais uma reunião.

Por onde começar

Faz as contas à sobreposição, escreve o acordo e garante que o primeiro pull request tem merge na primeira semana. Tudo o resto assenta nessas três coisas. Se estás a montar uma equipa de engenharia nearshore e queres uma visão externa, a nossa avaliação gratuita revê a tua sobreposição e o teu calendário de reuniões, o teu acordo de trabalho, o teu percurso de onboarding desde o portátil até ao primeiro pull request com merge e os teus dados de tempo de revisão, e diz-te onde é mais provável que a equipa se desvie.