Como iniciar o seu projeto de nearshoring e como torná-lo bem-sucedido

Tem um projeto de TI e pergunta-se como implementá-lo? Já ouviu falar de nearshoring: em princípio, é uma opção para si. Talvez até já tenha tido uma experiência inicial. As vantagens do nearshoring face a projetos de offshoring são óbvias. O nearshoring oferece a melhor relação preço-desempenho no que toca ao outsourcing de TI. Mas de que serve este conhecimento se não souber como configurar e implementar com sucesso um projeto de nearshoring na prática? É frequentemente necessário clarificar antecipadamente se o projeto é adequado para nearshoring. Este artigo mostrará quais os projetos adequados para nearshoring, como é a implementação prática e como dar os primeiros passos com uma equipa de nearshoring.

Cada projeto de TI é único, mas nem sempre adequado para nearshoring

Os projetos são muito diferentes entre si. O horizonte temporal, as tarefas, os recursos e o resultado pretendido definem a forma como o projeto é concebido. Na verdade, as diferenças aqui são muito grandes e, por isso, nem todos os projetos são adequados para nearshoring. Analisemos alguns exemplos mais de perto. Para projetos que precisam de ser implementados ad hoc e muito rapidamente por uma equipa, o nearshoring não é uma alternativa. Encontramos tais projetos em agências de publicidade, por exemplo, onde os pedidos dos clientes surgem rapidamente e têm de ser implementados. Os recursos, ou seja, os respetivos colaboradores ou freelancers, estão disponíveis para que a implementação possa começar imediatamente. Não encontrará esta capacidade de resposta no nearshoring. Se tiver de montar ou encontrar uma equipa primeiro, isso demora simplesmente demasiado tempo. O cliente não ficaria entusiasmado se tivesse de esperar muito tempo pelo resultado. Se for necessário apenas um especialista para um projeto existente ou novo (por exemplo, um especialista em Salesforce), pode sempre externalizar isto, procurando um especialista num país de nearshoring. Este especialista pode apoiar projetos ad hoc ou tornar-se parte de uma equipa a longo prazo. Para projetos de legado e manutenção, depende muito de quem utiliza para o efeito. Na nossa experiência, é difícil entusiasmar programadores juniores com estes projetos. Eles não consideram o trabalho nestes projetos muito interessante e também é difícil para eles desenvolverem novas competências para as suas carreiras. Os programadores seniores têm maior probabilidade de estar interessados, uma vez que estes projetos são de longo prazo ou mesmo por tempo indeterminado, e oferecem-lhes um certo nível de estabilidade. O nearshoring faz mais sentido no desenvolvimento de produtos. No início, existe uma visão do produto ou a ideia de um produto. Esta visão pode ser decomposta muito bem em marcos individuais que são desenvolvidos passo a passo. Para a implementação, é necessária uma equipa de desenvolvimento de software que trabalhe na concretização do produto durante um período mais longo. Uma equipa de nearshoring pode ser montada muito bem para este fim. O esforço e os benefícios são aqui equilibrados.

Para que projeto se adequa cada conceito?

Grosso modo, conhecemos três modelos ou abordagens da nossa experiência de anos em nearshore. Estes diferem na componente temporal e em se e quanta experiência está disponível na gestão de projetos de desenvolvimento de software.

Freelancer

Para projetos que têm uma duração muito curta e não requerem uma equipa grande, trabalhar com um freelancer é uma boa opção. Isto também permite que se conheçam primeiro. Talvez o especialista de TI venha até a fazer parte de uma equipa de desenvolvimento mais tarde, se ambas as partes assim o desejarem.

Outsourcing de Projetos

Suponhamos que existe a visão de um produto ou de uma aplicação. No entanto, não sabe como realizá-la. Como criar um proof of concept (PoC)? Como montar uma equipa e que competências (por exemplo, linguagens de programação) devem ter os membros individuais da equipa? Se lhe faltar experiência em gestão de projetos ou não quiser ter um gestor de projeto interno, a única opção é trabalhar com um fornecedor de outsourcing. No outsourcing, o cliente diz como deve ser o produto final, que requisitos e funcionalidades devem ser cumpridos e a que custo. Coloca o desenvolvimento de software totalmente nas mãos do fornecedor, que é responsável por entregar um produto final no fim. Como mencionado, isto pode ser vantajoso se lhe faltar experiência, know-how ou recursos. No entanto, nesta constelação, tem pouca influência no pessoal e na velocidade com que o software é desenvolvido. É da responsabilidade do fornecedor de nearshoring montar a equipa adequada.

Equipa de Nearshoring – Outstaffing

Neste modelo, uma equipa de profissionais de TI trabalha remotamente para si e para o seu projeto a partir de um país de nearshoring. Esta equipa remota consiste em vários especialistas de TI, tais como programadores e testers de software, que são reunidos conforme as suas necessidades para o projeto. O cliente escolhe os membros da equipa e desenvolve-os para formar uma equipa, a sua equipa. O facto de a equipa trabalhar exclusivamente para si também é designado por equipa dedicada. É muito livre na composição da equipa — desde que os especialistas certos possam ser encontrados na localização nearshore. Também será responsável pelo desenvolvimento do produto e pela implementação do projeto. Portanto, só deve seguir este caminho se puder gerir tal equipa sozinho ou se tiver alguém a bordo com a devida experiência técnica, cultural e de gestão. Por exemplo, um delivery manager, gestor de projeto, agile coach ou CTO.

Onde encontrar profissionais de TI para a sua equipa ou um parceiro de nearshoring

Existem inúmeros recursos para encontrar freelancers. Portais de internet como o Upwork, freelancer.com ou Gulp não só colocam freelancers como também tratam do processamento de pagamentos. Se procura um fornecedor de nearshoring, pode consultar portais como o Clutch ou o The Manifest. Lá pode encontrar uma variedade de parceiros ativos em outsourcing e/ou outstaffing através de categorias e países. As avaliações de clientes e os perfis dos fornecedores ajudam-no a encontrar prestadores de serviços adequados. Além disso, existem portais online (por exemplo, Transparency Wins) onde as empresas podem colocar um pedido e selecionar o adjudicatário adequado a partir das propostas submetidas.

O início com uma equipa de nearshoring

Primeiro, é necessária uma visão. Esta deve ser redigida em não mais de três páginas. As perguntas poderiam ser: O que deve ser desenvolvido (app móvel, website, software empresarial, etc.)? Para que é necessário ou o que devem os clientes poder fazer com ele? Especificações de software abrangentes raramente são encontradas hoje em dia porque não só consomem muito tempo, como também têm de ser constantemente reescritas assim que os requisitos para o produto mudam. Como os bons programadores raramente estão desempregados, também pode usar a visão para entusiasmar os programadores com o projeto. Além disso, deve estimar a quantidade de trabalho e o tamanho da equipa a partir da visão. Pela nossa experiência, o tamanho da equipa e o fornecedor de nearshoring precisam de ser compatíveis. Se o seu projeto for pequeno, correrá melhor se trabalhar com um fornecedor pequeno. Para um fornecedor grande, os projetos pequenos são financeiramente pouco atrativos. Se não houver conhecimento de tecnologias, pode descrever as funcionalidades do produto e a visão do produto e atribuir a um outsourcer de projeto a implementação completa. No entanto, caso faça a gestão da equipa sozinho, procure um fornecedor que o possa ajudar a encontrar profissionais de TI e que forneça espaço, infraestrutura e administração. Ter uma equipa dedicada faz sempre sentido quando é necessário apoio a longo prazo, por exemplo, porque existe todo um pipeline de projetos. Pode então montar a equipa de uma forma muito mais granular e desenvolver competências que são necessárias para atingir os objetivos da empresa e do projeto. Se ainda não estiver cem por cento claro para onde a jornada se dirige no início, porque apenas é necessário um proof of concept (PoC) ou um minimum viable product (MVP), então pode desenvolver isto com freelancers. No entanto, o desenvolvimento de um produto final requer geralmente uma equipa estável.

O que é importante para o sucesso do projeto de nearshoring

Fornecemos-lhe agora algumas dicas para o ajudar a começar. Para que não tropece ao dar os seus primeiros passos no nearshoring. O sucesso do seu projeto — se todos os objetivos do projeto forem cumpridos no final — depende em grande medida da qualidade da gestão da equipa e do projeto. De seguida, fornecemos alguns métodos e dicas para o caminho.

Workshop

Com base na visão do produto, deve ser criada uma lista de tarefas concreta juntamente com um cronograma. Desta forma, as dependências podem ser identificadas e descritas (O que depende de quê? O que deve ser desenvolvido primeiro, o que vem depois?). O número de programadores necessários também pode ser determinado. Isto é melhor alcançado num workshop para o qual todos os stakeholders são convidados (vendas, cliente, CEO, CTO, etc.). Novas funcionalidades do produto surgem frequentemente das discussões com os stakeholders, e decide-se em cada caso se devem ser implementadas. Os requisitos não funcionais também devem ser definidos, uma vez que estes têm impacto nos custos. Também pode encomendar tal workshop a um outsourcer de projeto, que trabalhará consigo para desenvolver um plano e uma especificação. Utilizará depois estes documentos para obter propostas adequadas de vários fornecedores.

Proof of Concept

Com um PoC, verifica a viabilidade da sua visão. Na gestão de projetos, este é um marco que prova a viabilidade de um projeto em princípio — tanto técnica como comercialmente. Ao fazê-lo, confirma o conceito do seu projeto e cria a base para o trabalho posterior. Para as startups, um PoC é frequentemente o pré-requisito para atrair investidores.

Kanban

O Kanban vem originalmente do Japão e da indústria automóvel. No desenvolvimento de software, este método ágil é utilizado para trazer a complexidade de um projeto para uma estrutura, de modo a que se torne mais gerível. Um quadro (virtual ou real) é dividido em colunas que denotam diferentes fases (por exemplo, a fazer, em curso, em teste, concluído). Os cartões que representam tarefas são movidos de estação em estação à medida que o projeto avança. As tarefas e responsabilidades podem ser visualizadas muito bem. Existem bastantes fornecedores para tais ferramentas digitais de gestão de projetos.

Scrum/Sprints

O Scrum é também um modelo de processo de gestão de projetos, especialmente no desenvolvimento de software. A abordagem aqui é diferente da do Kanban. O foco está num certo ritmo que uma equipa segue durante o desenvolvimento. Assim, os projetos são decompostos em partes de duas semanas, um sprint. Para um sprint, determina-se quais as tarefas existentes e quanto tempo é necessário para cada tarefa. No final de um sprint, avalia-se se os esforços foram realistas. Estimam-se novos esforços para o próximo sprint. Isto melhora a cooperação da equipa, uma vez que esta é submetida a uma espécie de processo de aprendizagem. Incrementalmente, a produtividade da equipa melhora.

Backlog Estruturado

As funcionalidades que um produto deve ter são registadas num backlog. Pode ser entendido como uma lista de tarefas e é utilizado no Scrum. As tarefas que ainda precisam de ser concluídas são registadas na lista. Esta lista é dinâmica, pelo que o backlog deve ser mantido, atualizado e limpo regularmente. Caso contrário, a estrutura e, consequentemente, a visão geral perder-se-ão.

Story Points, Mensurabilidade, Ferramentas

Ferramentas como o Trello (para Kanban) ou o Jira (para Scrum) ajudam-no no seu trabalho. Elas mostram o progresso do projeto e ajudam a medir quais os pacotes de trabalho que foram concluídos nas últimas duas semanas de um sprint. Desta forma, podem ser identificadas oportunidades de melhoria para a equipa. Os esforços podem ser avaliados com story points. O que se mede não é quanto tempo foi gasto numa ordem de trabalho, mas quantos pontos a tarefa tem. Isto deve ser estimado antecipadamente: quanto mais elaborada e demorada for a tarefa, mais story points recebe.

Scope Creep

Este termo refere-se a alterações no projeto que aumentam o projeto de forma contínua e incontrolável. Isto pode ocorrer quando o âmbito de um projeto não é devidamente definido ou controlado. Novos requisitos para o produto e constantes alterações no projeto levam a um trabalho interminável no produto ou no lançamento do software sem que este seja terminado. Uma vez que isto também faz disparar os custos, deve definitivamente manter-se atento a este aspeto.

Dívida Técnica

A dívida técnica é uma metáfora comum no desenvolvimento de software. Surge quando o software é desenvolvido com qualidade insuficiente. Isto acontece frequentemente quando novas funcionalidades são implementadas rapidamente e, por isso, de forma pouco cuidada. Quanto mais vezes isto acontece, mais difícil se torna reparar os défices resultantes na estrutura do software. Frequentemente, estas «questões herdadas” dificultam a incorporação de novas funcionalidades. Para evitar isto, devem ser sempre agendadas fases no desenvolvimento durante as quais se remove a dívida técnica. Se isto for negligenciado, o software muitas vezes só pode ser completamente reconstruído.

Conclusão

Existem muitas coisas a considerar ao implementar o seu projeto de nearshoring. No início, há sempre a questão de saber se tem experiência de gestão de projetos suficiente na sua empresa para gerir a equipa de nearshoring. Se não for esse o caso, resta-lhe a opção de externalizar o desenvolvimento do produto para um prestador de serviços. Se estiver interessado em construir a sua própria equipa de nearshoring, este artigo fornece orientações sobre as melhores práticas para tornar o projeto um sucesso. Os fornecedores de nearshoring estão localizados no respetivo país e podem apoiá-lo na formação da equipa e no recrutamento. Também fornecem salas, infraestrutura e apoio administrativo. São a ligação cultural com a equipa de nearshoring e garantem, com eventos, que o fator de felicidade entre os especialistas de TI é elevado e que a identidade da equipa é criada. A nearshorefriends tem localizações nearshore na Tunísia, em Portugal e na Ucrânia. Sinta-se à vontade para nos contactar se tiver alguma dúvida sobre o seu projeto ou se necessitar de uma equipa.