O limite de projetos paralelos em times de desenvolvimento

A empresa tem um time de desenvolvimento que está trabalhando em dois ou três projetos, e então um novo sistema chega para ser desenvolvido.

Isso acontece a todo tempo em empresas com equipe de desenvolvimento interna; a necessidade de um novo projeto.

Qual a capacidade de um time analistas e programadores? 

Existe um número mágico de projetos que podem ser feitos em paralelo? Dois projetos é pouco, quatro é muito? 

É certo pensar que ao trazer um novo projeto para o time de desenvolvimento, eles ficarão animados e empenhados em começar a implementar mais um sistema, ou a verdade é que isso será um sobrepeso ao volume de trabalho atual?

Manter o contexto do que está sendo desenvolvido

Enquanto um desenvolvedor trabalha ele precisa manter um volume de informações na cabeça, lembrar de uma quantidade de coisas, e garantir que elas estejam todas bem entendidas na cabeça dele. “Cliente sem CPF? Não pode. Consulta sem data de retorno? Só se o médico não solicitar a volta. Resultado de exame antes do prazo? Apenas se o médico tiver nas condições A ou B, e, na consulta solicitar urgência.”. São as regras de negócio.

Parte destas informações estarão escritas em algum lugar, mas é inevitável que boa parte do time circule pensando nisso, para garantir que o projeto está indo no sentido certo. Escrever 100% das regras pode ser trabalhoso demais, e eventualmente se gastar mais tempo escrevendo e atualizando documentos, do que código.

Além de conhecer de cabeça todas as regras um desenvolvedor precisa entender todas as ferramentas de programação que está usando, as bibliotecas nos códigos e como todas as partes se ligam. Como é a comunicação com o banco de dados, tipos de cache, onde arquivos são salvos, quais os critérios de segurança, qual o limite de tempo máximo para uma informação ser obtida… isso tudo fica na cabeça do programador e do time de desenvolvimento. 

Tudo isso, é o contexto do projeto. Esse volume de informações que precisam ser carregadas pela equipe.

É comum sonharmos com um possível problema no sistema, ou descobrirmos no banho a solução de um bug. Prova de que aquelas informações ficam pairando, circulando mesmo em nossas mentes.

Troca de contexto em projetos de software

Ao mudar de um projeto para o outro, é preciso “arquivar” temporariamente todas aquelas regras e então “carregar” a do novo projeto. Ou seja, o cérebro estava a pouco pensando com as regras/técnicas/tecnologias/conceitos/modelos de um projeto, em na hora seguinte, precisa pensar em outro.

Essa mudança constante aumenta a carga cognitiva, baixa a produtividade, aumenta a sobrecarga de trabalho. Para algumas pessoas pode ser algo trivial trocar de um projeto para o outro, ou pensar em vários ao mesmo tempo. Porém para times de desenvolvimento pode ser um tanto delicada essa troca, devido a "profundidade que é preciso mergulhar” para a implementação.

Neste diagrama elaborado por Gerald Weinberg (um estudioso das ciências da computação, da psicologia e antropologia) é apresentada de forma bem objetiva as perdas da troca de contexto.

O que podemos entender então é que o ideal é mudar o mínimo possível de um projeto para outro, e lembrar que ignorar esses limites (ao atribuir mais responsabilidades do que o suportável) afeta negativamente a performance, e consequentemente a capacidade de entrega.

Conhecimento e motivação

Queremos profissionais cada vez melhores em nossos projetos. Que nosso designer se especialize cada vez mais em UX/UI, que o time de Q&A elabore técnicas mais rápidas de validar o que foi feito, que o desenvolvedor possa implementar sistemas ainda mais rápidos e práticos do que os anteriores.

A troca de projetos constante costuma dificultar a concentração e aprofundamento nestes detalhes.

Pensando na motivação destes desenvolvedores, o quanto mais desejarem fazer um sistema perfeito, melhor, porque na verdade é isso que ele quer, fazer um sistema incrível! Se a demanda aumenta e a sobrecarga se instaura, a motivação fica baixa e as entregas ficam sem brilho.

Manutenção de projetos anteriores

Indo além dos projetos em desenvolvimento, é preciso lembrar que os projetos passados precisam ser mantidos, corrigidos, ajustados e as vezes até melhorados.

Pode acontecer da equipe precisar ainda manter algum "software legado”, o que indica que um projeto usa tecnologias antigas e sua manutenção se torna muito mais delicada. Poucas pessoas saberão trabalhar neles e as alterações precisam ser muito bem pensadas.

[equilibrando pratos]

Se esta responsabilidade de manutenção ficar sobre o mesmo time que precisa estar entusiasmado com o projeto novo, pode ser difícil equilibrar todos estes pratos.

Quantidade ideal de projetos?

Se queremos eficiência do time e entregas de qualidade, o que é melhor mesmo seria trabalhar em apenas um projeto. Caso exista a demanda por vários projetos, o ideal seria desenvolver um projeto por vez, indo do começo ao fim em um sistema, antes de se dedicar ao próximo.

Posso falar aqui de causa própria, de uma época estive envolvido no desenvolvimento de sete projetos em paralelo. Era preciso intercalar os dias entre os projetos para poder ter pelo ao menos algumas horas de foco total em cada um deles. Mas de fato, quando eu voltava para um projeto, o último dia que eu tinha trabalhado nele era na semana passada. 

Na prática, era como se eu tivesse um dia da semana para cada projeto, e posso afirmar, não foi um período nada bom, e sinto que impactou na qualidade daqueles projetos.

Não existe então um número mágico que diga “x projetos ao mesmo tempo é o máximo” , é preciso levar em consideração todas estas informações para então decidir.

Se o time está lento, sem muito ânimo, entregando projetos com qualidade baixa, sem aquele “plus a mais”, talvez já seja um sinal de que estão lidando com projetos demais.

Terceirizar o desenvolvimento ou manutenção

Nos dias de hoje, desgastar seu time interno não é uma boa estratégia, visto as oportunidades ótimas que estão ao redor.

Uma alternativa para empresas com times já ocupados com diversos projetos, é designar para outra empresa o desenvolvimento/manutenção de alguns sistemas, afim de desafogar o time interno.

Para alguns é uma forma até de trazer novas tecnologias para a empresa, enxergando a empresa terceirizada como uma extensão do time, facilitando a capacitação do time interno e aumentando a motivação.

Estar sempre trabalhando com as tecnologias mais novas pode ser difícil para o time interno, mas para um time terceirizado isso é bem mais fácil, e oxigena a equipe interna com novas técnicas e ferramentas.

Se esta for uma boa opção para sua empresa, não deixe de falar conosco.