Pronto para o nearshoring? O Nearshore Readiness Test

Johannes Krüger

I'm an experienced leader in the nearshore services sector, serving as Founding Partner & Managing Director at nearshorefriends. I have deep experience in coordinating international tech and talent operations.

Pronto para o nearshoring? O Nearshore Readiness Test

Pronto para o nearshoring? O Nearshore Readiness Test

Quais são os requisitos para a sua empresa fazer nearshoring com sucesso?

Na nossa prática diária, falamos com empresas interessadas no tema do nearshoring. Frequentemente, as empresas estão cientes dos benefícios do nearshoring mas sentem dificuldade em avaliar se possuem os pré-requisitos para “fazer nearshoring”. No entanto, as condições de enquadramento corretas desempenham um papel decisivo para determinar se tal projeto será bem-sucedido. Não é sem razão que o nearshoring é um tema do qual muitos se afastam com a opinião de que “não pode ser feito”. A nossa experiência demonstrou que o nearshoring é bem-sucedido quando as empresas cumprem certos requisitos e seguem determinados princípios. Existem fatores críticos que são decisivos. Com base nos nossos muitos anos de experiência em projetos de nearshoring, conhecemos estes fatores de sucesso e apresentamo-los neste artigo. Com base nesta visão geral, pode verificar, num primeiro passo, se o nearshoring é uma opção para a sua empresa ou não.


Língua

As equipas de nearshore estão localizadas no estrangeiro. A comunicação só pode, portanto, ocorrer em inglês. É irrealista assumir que se podem encontrar especialistas de TI suficientes que se ajustem ao projeto em termos de competências e experiência e que também falem fluentemente a língua do seu país de origem. Consequentemente, os colaboradores que trabalham com a equipa de nearshore devem aceitar comunicar 100 % em inglês.


Tarefas e processos internos

Se todos os colaboradores trabalharem num único país e toda a equipa estiver numa sala, as tarefas podem ser distribuídas a pedido. Também pode discutir temas de forma ad hoc. A coordenação é relativamente fácil e obtém-se muita informação importante através dos canais informais. Por outro lado, se estiver a trabalhar com uma equipa distribuída onde alguns ou todos os colaboradores trabalham remotamente, a situação é completamente diferente. Aqui, os seguintes aspetos são importantes:

Os requisitos devem ser registados numa ferramenta

Os requisitos individuais para o software devem ser descritos num sistema que funcione com tickets. Pode ser o Jira, o Trello ou algo comparável. Mas deve ser mais do que apenas uma folha de Excel, pois isso pode facilmente levar a confusão. A descrição deve ser curta e concisa, mas suficientemente completa para que um programador de software possa trabalhar com ela sem ter de perguntar mais várias vezes.

Reuniões de equipa fixas

É muito importante para o moral da equipa que as reuniões de equipa ocorram sempre à mesma hora e não sejam canceladas. Deve tornar-se um ritual. Os métodos ágeis, como o SCRUM, geralmente também prevêem isto. Quando uma equipa se senta numa sala, geralmente não importa muito se as reuniões são adiadas ou canceladas. Continuaria a haver a comunicação de corredor e podem comunicar entre si através de canais oficiais curtos. Mas à distância, é importante que todos aderiram a processos definidos para alcançar um fluxo de comunicação onde a informação não se perca. Esta execução consistente e disciplinada de rituais tem uma influência motivadora nos colaboradores. Além disso, tem um efeito positivo na cultura corporativa.

Desenvolvimento e teste de software

Na Europa de Leste, existe geralmente uma separação entre testar e desenvolver uma aplicação. Isto faz sentido por várias razões. As funções também são separadas de uma perspetiva financeira, porque os salários dos testers na Europa de Leste, por exemplo, são mais baixos do que os dos programadores. Por outro lado, contradiz a ideia original do SCRUM, onde cada membro da equipa pode fazer tudo. No entanto, tende a acontecer que um programador de software que testa o seu próprio código encontre menos erros do que uma terceira pessoa, porque é excessivamente otimista em relação ao seu próprio trabalho.


Mercado de trabalho

O mercado de trabalho noutros países “gira” muito mais depressa do que estamos habituados. Os contratos podem ser rescindidos com um mês de aviso prévio, dependendo da região, e o tempo de permanência de um colaborador na empresa é geralmente mais curto. Isto tem efeitos de longo alcance. Por exemplo, o processo de recrutamento deve ser muito mais rápido do que o habitual em países como a Alemanha. Isto deve-se ao facto de um (bom) candidato ter quase sempre várias ofertas em cima da mesa e não esperar muito tempo para receber uma aceitação ou rejeição. Isto significa que a revisão dos candidatos deve ser realizada rapidamente por parte da empresa. Um candidato deve receber uma carta de aceitação ou rejeição aproximadamente uma semana após a entrevista. Caso contrário, deve esperar que um bom candidato desista porque outra empresa simplesmente tomou uma decisão mais depressa.


Compromisso

Aqueles que abordam o tema do nearshoring com uma perspetiva puramente baseada em custos não serão bem-sucedidos. O lema não deve ser poupar dinheiro onde quer que seja possível. Os grandes profissionais de TI têm oportunidades de emprego alternativas em todo o mundo. Não permanecem muito tempo num ambiente caracterizado apenas pelo corte de custos. Os programadores querem entregar um bom trabalho num ambiente razoável. Para alcançar bons resultados com uma equipa, os seguintes passos são, portanto, essenciais.

Visitas

Pelo menos a cada 3-4 meses, alguém do seu país deve visitar a equipa ou, pelo menos, 2 membros devem vir ter consigo. Geralmente, isto é feito durante o planeamento de marcos, etc. Reuniões presenciais regulares tornam claro para a equipa que são importantes e levados a sério, e não apenas uma “bancada de trabalho barata”.

Equipamento

O hardware e o software devem ser o padrão da indústria e não de baixo custo. Nenhum engenheiro gosta de trabalhar com ferramentas baratas e más.

Gestão e desenvolvimento de pessoal

Os colaboradores querem sentir que o seu desempenho está a ser notado e que estão a expandir as suas competências. Da mesma forma, querem ver que o seu feedback e sugestões de melhoria são ouvidos. É por isso que as discussões de feedback e as avaliações de colaboradores são importantes.


Stack Tecnológica & Projetos de Manutenção

Cada especialista de TI tem interesse em expandir continuamente os seus conhecimentos. Portanto, procuram os empregadores que lhes permitam utilizar tecnologias novas e requisitadas. Isto tem as seguintes consequências: se trabalhar com tecnologia antiga, terá dificuldade em encontrar programadores adequados. Se quiser mudar projetos de manutenção para o estrangeiro, terá dificuldade em encontrar programadores porque esses projetos raramente permitem que alguém receba formação real. Claro que este tema não deve ser visto a preto e branco. Num projeto de manutenção, tem de estar preparado para o facto de a procura de pessoal demorar mais tempo e atrair uma categoria diferente de especialistas de TI do que projetos com tecnologias de ponta.


Métodos

Os programadores, por exemplo na Europa de Leste, trabalham geralmente com SCRUM ou Kanban ou uma mistura de ambos. Existem outros métodos, mas recomenda-se experimentar menos aqui e manter os métodos que cada membro da equipa já conhece. O que certamente não funciona é o desenvolvimento ad-hoc, onde se supõe que deve adicionar “rapidamente” esta ou aquela funcionalidade. Este estilo é frequentemente encontrado em pequenas agências digitais ou de publicidade. Num contexto internacional que abrange vários milhares de quilómetros, isto encerra um grande potencial para mal-entendidos — especialmente quando se trata de prioridades, funcionalidades exatas e prazos. Como descrito acima, os processos internos e as descrições de tarefas são importantes.


Compromisso do C-Level

O nearshoring só será possível se o nível de gestão estiver totalmente empenhado. Especialmente o CIO/CTO. Se não estiverem a bordo, haverá conflitos mais cedo ou mais tarde. Por vezes os custos são criticados, e por vezes as capacidades da equipa de nearshore são fundamentalmente questionadas, podendo até ser percebida como um corpo estranho.


Cultura

Outros países, outros costumes. A tolerância a outras culturas é um pré-requisito básico para o nearshoring. As empresas devem reconhecer e apreciar as vantagens e o potencial da outra cultura. Não espere que todos pensem e ajam da forma a que está habituado. Nem é sempre o caso de a forma habitual ser a ideal. Existem também diferenças de experiência entre países individuais. Enquanto o nearshoring é território novo para muitas empresas alemãs, está muito mais difundido e é implementado com sucesso na Escandinávia.


Resumo

Neste artigo do blogue, compilámos os critérios essenciais e mais importantes que são cruciais para o sucesso no nearshoring. Para uma avaliação mais aprofundada da prontidão para o nearshore, estamos disponíveis para conversar a qualquer momento.

Mais artigos

Two men smile and shake hands in front of a banner that reads "10 years. People. Projects." with the website www.nearshorefriends.com. The setting appears to be a modern office space.

10-Year Anniversary – What a Rollercoaster!

«Some events stay with us long after they end. Our recent networking event in Sofia was one of them—a powerful reminder of what matters most: our community.” The Nearshorefriends Networking...

Lista de Verificação de Preparação Gratuita

Preparado para Nearshoring?

Descubra o grau de preparação da sua empresa para nearshoring