Tempo de leitura: 9 min
Author: ITDS Team
| Resposta curta: uma equipa de desenvolvimento nearshore que entrega é uma equipa pequena, estável e multidisciplinar, com um responsável claro pelas prioridades, um líder técnico dentro da equipa e poucos rituais planeados à volta das horas em comum. A maioria das equipas remotas que falharam tinha a mesma falha: faltava alguém com autoridade para dizer o que importa esta semana, disponível no horário da equipa. |
Contratou bons engenheiros no estrangeiro, mas a equipa não parece entregar. As tarefas avançam, mas os resultados não. As perguntas esperam um dia por resposta. Todas as demonstrações surpreendem alguém. Raramente o problema são os engenheiros. Quase sempre é a estrutura à volta deles.
Este guia mostra como estruturar uma equipa de desenvolvimento nearshore que entrega de facto: os formatos de equipa que funcionam, papéis e proporções, onde fica o product owner, rituais entre fusos horários e um plano para os primeiros 90 dias. Para ver como a ITDS monta equipas dedicadas em Portugal e na Polónia, consulte a nossa página sobre desenvolvimento de software nearshore.
| Neste guia | |
| Formatos de equipa Papéis e proporções Onde fica o product owner |
Rituais entre fusos horários Os primeiros 90 dias Perguntas frequentes |
Formatos de equipa de desenvolvimento nearshore que funcionam
Há dois formatos que funcionam bem e um que raramente funciona.
- Equipa alargada. Os engenheiros nearshore juntam-se à sua equipa existente. Funciona quando tem um líder técnico forte e precisa de mais capacidade num produto que já gere.
- Equipa nearshore alinhada a um fluxo. Uma equipa completa é dona de uma área de produto ou serviço de ponta a ponta, com o seu próprio líder técnico. O termo vem do modelo Team Topologies. Funciona quando quer que uma nova capacidade ou parte do produto avance de forma independente.
- Dividida por função. Design e arquitetura na sede, código no estrangeiro, testes noutro sítio. Cada passagem atravessa uma fronteira e um fuso horário, e a responsabilidade desaparece. Evite.
| À maioria das equipas remotas que falharam não faltavam engenheiros. Faltava alguém que dissesse o que importa esta semana. |
Papéis e proporções numa equipa de desenvolvimento nearshore
Os números exatos dependem do produto, mas as equipas saudáveis costumam ser parecidas:
| Papel | Número típico | Porque importa |
|---|---|---|
| Product owner | 1, partilhado no máximo por duas equipas | Decide as prioridades e responde a perguntas no próprio dia |
| Líder técnico | 1, dentro da equipa | Responsável pelas decisões técnicas e pela qualidade do código |
| Engenheiros | 3 a 6 | Poucos o suficiente para partilhar contexto, muitos o suficiente para aguentar férias e baixas |
| QA | Muitas vezes 1, ou qualidade partilhada | Mantém a qualidade dentro da equipa, e não no fim da linha |
| Design, DevOps, dados | Partilhados ou a tempo parcial, conforme necessário | Especialistas a quem a equipa recorre sem esperar dias |
Uma mistura de engenheiros seniores e de nível intermédio costuma funcionar melhor do que uma equipa só de seniores ou só de juniores. Os seniores dão a direção; os de nível intermédio entregam com regularidade e crescem para serem os próximos líderes.
Onde fica o product owner
Este é o papel que faltava, ou estava no sítio errado, em quase todas as equipas remotas que falharam. O product owner não tem de viver no mesmo país que os engenheiros. Mas tem de estar disponível no horário da equipa, ter autoridade para decidir e participar nos rituais da equipa.
- Se o seu product owner está na sede, reserve pelo menos duas horas por dia de sobreposição para a equipa e garanta a sua presença no planeamento e na revisão.
- Se a sobreposição é pequena, como acontece com equipas dos EUA, considere um product owner delegado perto da equipa, com poderes de decisão claros.
- Nunca deixe que as prioridades cheguem apenas através de tarefas escritas por alguém que a equipa nunca conheceu.
Rituais entre fusos horários para equipas nearshore
Portugal partilha o fuso horário do Reino Unido e a Polónia o da Europa Central, por isso a maioria das equipas europeias tem um dia inteiro em comum. Os rituais continuam a ser importantes.
- Reunião diária nas horas em comum, curta e focada nos bloqueios.
- Planeamento e revisão a cada uma ou duas semanas, com o product owner presente.
- Decisões por escrito. Decisões de arquitetura e prioridades registadas, para que ninguém dependa de uma chamada a que faltou.
- Revisão de código rápida. Acordem um prazo para as revisões, para que o trabalho não fique parado de um dia para o outro.
- Retrospetivas com todos, nos dois locais.
- Tempo juntos. Encontrem-se pessoalmente pelo menos uma ou duas vezes por ano.
| Está a planear uma equipa nearshore? Descreva o produto e a equipa que tem hoje, e sugerimos uma estrutura adequada. Descreva a sua equipa |
Os primeiros 90 dias de uma equipa de desenvolvimento nearshore
| Quando | Foco |
|---|---|
| Dias 1 a 30 | Acessos, apresentações da arquitetura, primeiras entregas pequenas, rituais a funcionar, product owner presente todas as semanas |
| Dias 31 a 60 | A equipa é dona de uma área definida, o líder técnico toma as decisões técnicas do dia a dia, primeiras ações das retrospetivas concluídas |
| Dias 61 a 90 | A equipa planeia e entrega uma funcionalidade relevante com pouca ajuda externa; reveja o que ajustar em papéis e proporções |
Em média, os clientes da ITDS passam do início da procura a um engenheiro integrado em cerca de 20 dias, por isso uma equipa de vários engenheiros pode muitas vezes estar formada nos primeiros meses.
Onde entra a ITDS
A ITDS monta equipas dedicadas e alargadas em Portugal e na Polónia. Ajudamos a escolher o formato, encontramos primeiro o líder técnico e fazemos crescer a equipa à volta dele. Cerca de um em cada cinco candidatos passa a nossa avaliação. Para saber mais sobre modelos de equipa, veja a nossa página sobre criação de equipas de TI.
Equipas de desenvolvimento nearshore: perguntas frequentes
Como uma equipa pequena, estável e multidisciplinar, normalmente com três a seis engenheiros, um líder técnico dentro da equipa e um product owner disponível no horário da equipa. Pode alargar uma equipa existente ou dar a uma equipa completa a responsabilidade por uma área de produto.
Em qualquer lado, desde que esteja disponível no horário da equipa, tenha autoridade para decidir e participe no planeamento e na revisão. Com pouca sobreposição horária, ajuda ter um product owner delegado perto da equipa.
Normalmente três a seis engenheiros e um líder técnico. Equipas mais pequenas sofrem com férias e baixas; as maiores perdem contexto partilhado e devem ser divididas.
Falta de clareza sobre quem decide as prioridades. Quando ninguém com autoridade está disponível no horário da equipa, o trabalho abranda e afasta-se do que o negócio precisa.
Com um bom plano de integração, uma equipa costuma ser dona de uma área definida em cerca de dois meses e entregar funcionalidades relevantes de forma independente em cerca de três.
Descreva a sua equipaDiga-nos o que está a construir e como a sua equipa trabalha hoje. Numa chamada curta, sugerimos um formato de equipa nearshore, os primeiros papéis a contratar e um prazo realista em Portugal ou na Polónia. |