Ao longo da carreira, temos a oportunidade de trabalhar em um número variado de projetos e equipes. Ao entrarmos num projeto em andamento, notamos semelhanças com os projetos anteriores, principalmente no que se diz respeito aos problemas, que em projetos já com alguns anos de existência, lançados no mercado e num ciclo de alterações contínua, sempre vêm à tona.

Um deles, que destaco aqui, é aquele quando temos uma equipe com um integrante que detém sozinho grande parte do conhecimento necessário para andamento do projeto. Isto inclui o conhecimento dos processos de negócio dos clientes, a arquitetura da aplicação, processos de “build” e “deploy”, que mais ninguém sabe executar – além de detalhes obscuros de APIs criadas internamente e não documentadas, entre outros. Não que seja ruim que alguém conheça muitos detalhes do projeto, mas quando esse conhecimento não é disseminado para todo o time, a empresa cria uma espécie de relação simbiótica com este profissional, onde ela é a prejudicada.

Note que não falo aqui sobre especialistas em tecnologias específicas e complexas, porém disseminadas, como: sistemas de bancos de dados, segurança da informação, redes, entre outras. Estes especialistas são essenciais para que o projeto atinja um nível diferencial de qualidade e maturidade tecnológica.

Mas o que acontecerá quando este profissional resolve deixar a empresa? Nesse momento, tentamos espremê-lo como se fosse a última laranja do cesto, tentando absorver todo o seu conhecimento, adquirido em anos, em apenas algumas semanas – até a última gota! No último dia damos tapinhas na costas e surge a velha frase: “estarei sempre a disposição de vocês”. Mas a verdade é que ninguém está sempre a disposição e todo esse conhecimento acumulado é perdido.

Há alguns sinais bem claros que apontam quando o projeto possui este tipo de profissional e eles devem ser combatidos.

Falta de automação

• O “build” é executado manualmente e de forma complicada;
• O processo de teste necessita que uma série de requisitos sejam satisfeitos antes que o ambiente adequado esteja corretamente configurado;
• O “deploy” é manual ou complexo demais, com necessidade de interação humana mesmo que seja apenas um “hotfix” para um cliente.

Esse primeiro sinal deve ser eliminado através da automação dos processos repetitivos e simplificação de processos complexos. Essa eliminação de complexidade e repetição pode ser obtida com agendamento de scripts, utilização de servidores para integração contínua (CI), sistema de controle de versões (VCS) e “bugtracking”. O ideal é que estes sistemas conversem entre si e estejam fortemente integrados, eliminando o número de repetições e o esforço necessário para integração e entrega do produto.

Crescimento da empresa e estagnação dos processos

• O software tinha poucas funcionalidades no início e, com isso, um menor número de bugs reportados e uma menor quantidade de hotfixes;
• O número de clientes era menor e o número de deploys executados não justificava um sistema completo para sua automação;
• A tecnologia, arquitetura e/ou ferramenta utilizada para execução do processo era adequada quando a realidade do projeto era outra.

As metodologias ágeis prezam pela adaptação às mudanças, mas isso não deve ser aplicado apenas aos requisitos de negócios do cliente. O projeto precisa evoluir e os processos internos devem ser continuamente revisados. Novas tecnologias e metodologias devem ser experimentadas e aplicadas quando forem uma evolução para o projeto. Um projeto que não evolui continuamente acumula gordura desnecessária, o que não é bom para sua saúde.

Disseminação do conhecimento

Dissemine o conhecimento através de reuniões diárias ou semanais, onde os problemas e soluções adotadas devem ser expostos. Incentive o time a buscar novas soluções, além de melhores práticas e ferramentas. Não especialize seus desenvolvedores em áreas específicas do projeto, busque padrões e torne o código uma propriedade coletiva, para que todos sejam capazes de interagir com ele. Documente aquilo que é complexo até que possa ser simplificado.

Pessoas tiram férias, ficam doentes, mudam de empresa e até mesmo morrem, por isso devem ser substituíveis de forma a causar um mínimo de impacto no projeto.