Tudo o que precisa de saber sobre problemas de comunicação e rotatividade de colaboradores
Ao subcontratar serviços ou projetos de desenvolvimento de software, pode alcançar melhor os objetivos da empresa. No nearshoring, tem duas opções: pode trabalhar com um prestador de serviços que desenvolve o produto final por si (palavra-chave: outsourcing) ou que lhe disponibiliza os programadores necessários no país de nearshoring (palavra-chave: outstaffing ou equipa dedicada). Se escolher o segundo modelo, tem mais liberdade para moldar o projeto, mas assume a responsabilidade do projeto e gere a equipa de desenvolvimento de software. Os projetos não se gerem sozinhos. A sua equipa enfrentará vários desafios que precisam de ser superados. De seguida, explicamos por que deve prestar atenção a problemas de comunicação e a uma elevada rotatividade de colaboradores. Também ficará a saber como executar com sucesso os seus projetos de nearshoring com competências culturais, técnicas e de gestão.
Desafios comuns em projetos de nearshoring
Mas, primeiro, vejamos os desafios que as equipas de desenvolvimento de software enfrentam no nearshoring. Esta não é uma lista exaustiva, mas reduz a seleção a desafios muito típicos e aos mais comuns.
Priorização e objetivos em evolução
Mesmo que os requisitos tenham sido inicialmente especificados e os objetivos do projeto definidos e priorizados, as alterações são bastante comuns. Quais são as razões para isso? Muitas vezes, surgem novos requisitos e funcionalidades que precisam de ser desenvolvidos. Ou uma visão de produto não pode ser implementada como inicialmente idealizada e tem de ser ajustada. Cada alteração afeta inevitavelmente os três parâmetros: tempo, custo e qualidade/desempenho. Por isso, alterar prioridades e, ainda assim, atingir com sucesso os objetivos do projeto não é uma tarefa trivial, mas um grande desafio no desenvolvimento de software.
Velocidade – o fator tempo
Um problema comum é a velocidade a que o software é desenvolvido. Muitas vezes, demora mais do que se pensou e planeou inicialmente. Ou alterações e funcionalidades adicionais abrandam todo o projeto. O produto fica concluído mais tarde, o que, por exemplo, aumenta os custos de desenvolvimento.
Pressão
A pressão surge inevitavelmente como consequência dos dois pontos referidos acima. Se os requisitos e os objetivos mudarem durante o projeto, as tarefas forem repriorizadas e os tempos de desenvolvimento se prolongarem, isso cria pressão: para terminar a tempo, manter-se dentro do orçamento e, ainda assim, entregar uma qualidade muito boa.
Qualidade e processo de desenvolvimento
Falando de qualidade, também acontece em projetos de desenvolvimento em nearshoring que a qualidade do software não é a esperada. É necessário um gestor de projeto ou de entrega muito competente para contrariar isto. Em geral, também deve ficar precisamente definido e especificado para uma equipa nearshore de acordo com que processos e métodos o software é desenvolvido.
Comunicação
Os problemas de comunicação ocorrem com bastante frequência em equipas de desenvolvimento. Especialmente sob pressão de tempo, o tom torna-se muitas vezes mais duro. No entanto, razões técnicas, linguísticas e culturais também podem levar a problemas de comunicação e até a conflitos dentro da equipa. É por isso que, mais adiante, iremos analisar com mais detalhe quais são essas razões e como as pode prevenir.
Motivação e espírito de equipa
As equipas nearshore trabalham num contexto remoto. A equipa é composta por uma equipa interna e uma equipa externa na localização nearshore. Ou a equipa de desenvolvimento está totalmente localizada no país de nearshoring e apenas o gestor de projeto ou o CTO está na localização de origem. Seja qual for a configuração, é importante formar uma equipa, manter a motivação dos colaboradores elevada e trabalhar em direção a um objetivo comum. Porque, assim que a motivação diminui, a qualidade do trabalho também baixa e os colaboradores têm maior probabilidade de sair.
Rotatividade de colaboradores
Isto leva-nos ao tema da rotatividade de colaboradores. A saída de colaboradores pode colocar em risco um projeto inteiro. De facto, é mais comum em projetos de nearshoring que os colaboradores saiam da equipa. Devido a prazos de aviso curtos, a transição para um novo empregador pode ser concluída rapidamente. Isto precisa de ser evitado, razão pela qual, neste artigo do blogue, também abordamos a questão de por que alguém sai da equipa e o que pode fazer em relação a isso. Mas, primeiro, vejamos o tema da comunicação.
Problemas de comunicação: quais são as causas?
A comunicação ocorre num contexto cultural. A proficiência na língua inglesa, por si só, não causa dificuldades. No entanto, mesmo que o inglês esteja correto, persistem dificuldades linguísticas devido a nuances de significado (o que é exatamente que se quer dizer quando alguém diz “Maybe”?) ou à estrutura. Esta última é evidente, por exemplo, em e-mails longos em que o leitor se pergunta o que exatamente a outra pessoa quer transmitir. Muitas vezes, em projetos nearshore, comunica-se demasiado por escrito, com demasiados e-mails. Os mal-entendidos são inevitáveis, pois não é possível determinar o significado exato a partir de expressões faciais, gestos ou colocando perguntas, como seria numa conversa. Deve também estar atento a diferenças culturais. Uma grande distância de poder, combinada com respeito pelos superiores, pode levar alguém a não dizer “Não” quando está numa posição subordinada. Da mesma forma, essa pessoa não dirá que algo não é viável ou que não consegue fazer algo. Assumimos então que essa pessoa tratará de uma tarefa, o que não acontece. Do ponto de vista do Product Owner, os requisitos estão claramente formulados e são inequívocos. No entanto, a equipa de desenvolvimento não os compreende. Isto pode dever-se à língua, à experiência prévia e ao conhecimento existente que cada indivíduo traz. O mesmo se aplica aos processos: ou não existem, ou estão mal configurados. Nem sempre é claro quando e quem fala com quem. As reuniões não são suficientemente preparadas. O que é frequentemente notório no nearshoring: os objetivos da empresa não são comunicados. Mesmo que a equipa de desenvolvimento esteja geograficamente distante, continua a querer saber a direção e o seu contributo. Por fim, problemas técnicos (hardware utilizado, ferramentas implementadas) também podem ser a razão pela qual a comunicação não funciona de forma fluida.
Como pode evitar problemas de comunicação com a equipa de nearshoring?
Durante a entrevista, verifique se as competências de inglês estão realmente presentes e quão boas são. Sem competências linguísticas suficientes, qualquer colaboração torna-se difícil a impossível. Seja respeitoso e apreciativo com todos os colaboradores, independentemente da sua origem ou de fazerem parte da equipa interna ou da equipa nearshore. Diga o que quer dizer e queira dizer o que diz. Seja preciso e confirme se foi compreendido. Ainda mais importante: reserve tempo, ouça. Certifique-se de que também compreende o que a outra pessoa quer comunicar. Definir um plano de comunicação pode ser muito útil. Isto também exige uma agenda e objetivos. Ao usar as perguntas W (o quê, quem, quando, onde, etc.), pode garantir que nada é esquecido durante as reuniões. Embora estas devam ter duração limitada, assegure ainda assim que se alcança um entendimento comum sobre o que cada um precisa de fazer.
Razões para uma elevada rotatividade de colaboradores no nearshoring
Os colaboradores, normalmente, não ficam na mesma empresa toda a vida. Um certo nível de rotatividade é normal. No entanto, se os colaboradores ficam na empresa apenas por muito pouco tempo ou se vários colaboradores saem num período muito curto, então existe certamente uma razão para esta elevada rotatividade de colaboradores. Isto deve ser investigado, porque, no pior dos casos, pode colocar em risco um projeto nearshore inteiro. O esforço pode falhar. Do nosso ponto de vista, existem duas razões principais para os colaboradores saírem: má gestão e melhores oportunidades de carreira noutra empresa. Melhores oportunidades de carreira podem ser proporcionadas por incentivos financeiros. Ganha-se mais dinheiro noutro lugar. No entanto, também podem estar relacionadas com o conteúdo. O novo emprego, o projeto e as tecnologias utilizadas são mais interessantes. O programador pode, assim, desenvolver novas competências, o que promove a sua carreira a longo prazo. Um novo projeto também significa novos supervisores e gestores de projeto. Não é raro que os colaboradores mudem porque se dão melhor com o novo chefe e escapam à má gestão do seu emprego atual. O que significa “má gestão”? Uma equipa é mal gerida se não houver coesão de equipa. Se não houver identidade de equipa. Isto é um sinal claro de que algo está errado. Mesmo que a equipa se divida em duas ou mais fações, algo está errado e os problemas são inevitáveis. Na área nearshore, isto acontece muitas vezes porque prevalece uma espécie de sistema de classes. Enquanto a equipa interna “pode fazer tudo”, a equipa de nearshoring fica limitada. Isto pode assumir formas muito diversas: a informação é retida, há menos comunicação com a equipa, há menos recursos técnicos e muito mais. Também no nearshoring: sempre que atuamos como chefe em vez de líder, surgem problemas. As competências de liderança são mais necessárias do que nunca.
Como pode reter colaboradores na equipa?
Comunique com os colaboradores de igual para igual. Estabeleça uma ligação permitindo, por exemplo, conversa informal e reservando tempo para isso. Descubra o que motiva cada pessoa. Vá ao encontro dos colegas onde eles estão. Igualmente importante: explique regularmente “para onde vai a viagem”. Quais são os próximos objetivos, tarefas, marcos, etc.? Reúna-se regularmente presencialmente com os seus colaboradores. Embora as reuniões cara a cara também possam ocorrer online, o contacto pessoal é insubstituível. A troca pessoal é mais fácil de implementar no nearshoring do que em projetos de offshoring, que se caracterizam por uma grande distância geográfica. Medidas de team building ajudam a formar uma equipa e a manter a motivação e a identidade da equipa. Podem ser eventos de equipa ou festas. Pense em como organiza isto e a quem confia o papel de “Happiness Manager”. Para equipas muito grandes, pode fazer sentido ter uma pessoa que se dedica principalmente ou exclusivamente a isto. Atribua tarefas à equipa com base nos papéis e competências dos colaboradores. Com uma boa gestão de competências, evita que alguém não se adeque à posição ou desempenhe mal o papel. O colaborador acaba por sair ou, pior ainda, os colegas saem porque, por exemplo, consideram o gestor incompetente. Muitas vezes, a única opção que lhes resta é a demissão. Isto aplica-se não só aos programadores, mas também ao gestor. Se a má gestão for a razão da rotatividade de colaboradores, terá inevitavelmente de substituir o gestor. Só com um novo gestor o projeto ainda pode ser salvo. Há praticamente um ponto de não retorno. Antes de os colaboradores saírem, a motivação já costuma ter diminuído significativamente e o ambiente da equipa é mau. Como descobrir qual é o ambiente, se algo está a mudar para pior? Através da observação, perguntando ao gestor de projeto, através de conversas e através de inquéritos regulares. Preferencialmente anónimos. Mantenha-se a par do nível salarial. Informe-se sobre como os salários estão a evoluir no respetivo país. O headhunting intenso de programadores significa que bons programadores podem ser rapidamente aliciados se o seu salário deixar de ser competitivo. Assim, os salários devem ser ajustados em conformidade.
Que melhorias são possíveis? – a nossa conclusão
Se uma equipa for bem gerida, o desempenho aumenta em 50–100%, do nosso ponto de vista. Uma boa gestão é, por isso, crucial no nearshoring e em equipas grandes. São necessários líderes, não chefes. Gestores alinhados com a equipa, que sentem o seu pulso, equilibram os interesses da equipa e das partes interessadas e atuam atempadamente quando são necessárias mudanças. Por vezes, um pouco de diplomacia é mais do que útil. Isto significa que as empresas têm de investir tempo e dinheiro para lá chegar. Deve ser alocado 5–10% do orçamento total de desenvolvimento de software para este fim. Dependendo do tamanho da equipa, pode ser uma pessoa a tempo inteiro ou parcial responsável por este programa holístico de melhoria, que cuida da equipa e implementa processos. E não se esqueça do fator diversão – a sua equipa e o próprio devem sentir-se confortáveis e motivados para que o seu projeto de nearshoring seja bem-sucedido.