O mercado de TI está acirrado como nunca. Na luta constante pela inovação, empresas traçam diversas estratégias para lançar novas versões de seus produtos em tempo hábil e, muitas vezes, contratar desenvolvedores de software é uma das táticas escolhidas por gestores de TI.
Esse movimento de contratação é muito comum e está acontecendo agora mesmo: uma busca rápida no Linkedin mostrou mais de 8.700 vagas para o termo “desenvolvedor” no Brasil. Além disso, a Catho relatou que, entre março e agosto de 2020 (em plena pandemia), a procura por programadores de certas especialidades aumentou mais de 100%.
Crescer equipes de programação, contudo, é um passo que deve ser dado com muita cautela. Muitas empresas podem assumir que mais pessoas desenvolvendo um sistema pode significar mais produtividade, mas isso nem sempre é real.
Pensando nisso, trago o questionamento: será que você realmente precisa contratar mais desenvolvedores para o seu projeto? Ou existem outras frentes que podem ser atacadas para ajudar em seus desafios?
A seguir, para te ajudar a descobrir essa resposta, discuto sobre quando pode ser o momento certo para contratar novos desenvolvedores ou quando talvez sua dor possa ser endereçada por outras soluções.
Quando contratar um desenvolvedor é a estratégia correta?
Antes de mais nada, gostaria de reforçar que eu não sou contra contratar mais desenvolvedores para seu time. Na verdade, em alguns ambientes isso é altamente necessário para garantir as entregas e o valor para o usuário.
Porém, defendo que isso deve ser feito com cautela e avaliando todos os possíveis motivos para que você não incorra em gastos desnecessários e acabe gerando mais problemas.
Abaixo, cito alguns motivos pelos quais contratar realmente seria um bom motivo.
Você vai expandir o produto
Imagine que você é um aplicativo bancário e quer agregar a opção de investimentos às já existentes soluções de extrato, transferência e pagamentos. Isso muitas vezes significaria uma nova squad, com novas especialidades e, consequentemente, traria necessidade de mais programadores.
Ou seja, se você já possui algumas frentes em seu produto e identificou a oportunidade de agregar a ele novas soluções, contratar mais desenvolvedores com certeza vai te ajudar nesse ponto.
Tenha em mente que, se esse é seu cenário, você também precisará de outras especialidades na nova equipe, como o PO e o QA, por exemplo. Atente-se a isso.
Você tem problemas com suas entregas
Pense na seguinte situação: seu backlog está lotado. Sprint após sprint seu time atual não dá conta de entregar o acordado. Os desenvolvedores trabalham muito além do horário, mas, ainda assim, não é incomum releases serem postergadas. O custo pelo atraso das entregas não para de subir.
Muitas vezes isso pode ser categorizado como dores de crescimento, e contratar desenvolvedores para ajudar a dar vazão a demanda pode ser uma boa escolha.
Note que aqui considero que você tem um problema intrínseco à demanda de desenvolvimento, desconsiderando problemas com alto número de bugs, a dificuldade do programador de interpretar histórias de uso ou coisas assim. Avalie se esses outros itens fazem parte do seu cenário antes de escolher como seguir.
Se enxerga em alguma das situações que pontuei? Então o próximo passo é mandar o e-mail para seu time de talentos e iniciar o recrutamento quanto antes. Inclusive deixo um material que pode te ajudar nessa jornada de contratação.
Ainda tem dúvidas? Abaixo discuto motivos para rever essa estratégia.
Quando não contratar novos desenvolvedores?
Você está pressionado pela inovação
Vamos voltar ao exemplo do aplicativo bancário. Imagine que você identificou a necessidade dos consumidores de conseguir compartilhar comprovantes de pagamento por um canal de mensagem indisponível na sua aplicação e que hoje isso já é possível no produto do concorrente.
Então, você vai até sua squad de pagamentos (aquela que já existia) e coloca isso no backlog de desenvolvimento. Entretanto, tanto essa quanto outras demandas demoram para sair do papel, e você pensa que trazer mais desenvolvedores pode ajudar a criar e liberar features mais rápido para o mercado.
E aí?
Já disse por aqui o quanto a inovação pressiona líderes a quererem entregar mais e mais rápido. É uma pressão comum no mercado. Querer ser mais ágil e impactar os usuários antes dos outros players pode gerar uma demanda constante por incluir novas features no produto com um time to market cada vez mais apertado.
Por que, então, não contratar mais braço para dar vazão às demandas de inovação? Simples: nem sempre mais braço é sinônimo de mais eficiência. Isso se deve majoritariamente a um fator: a comunicação.
Quanto mais elementos você adicionar em um time, mais difícil será de gerir a comunicação que roda dentro dele, principalmente em equipes onde a interdependência é alta. Isso pode atrasar criticamente seu projeto.
Pense no caso do aplicativo bancário: o novo programador que vai trabalhar na feature do comprovante precisará se comunicar com o desenvolvedor responsável pela efetivação da transação para garantir que tudo esteja integrado – e isso é apenas um dos pontos de contato que precisam existir dentro do time.
Como você garante que essas ramificações de comunicação estão ocorrendo da melhor forma e sendo produtivas? E como garantir isso com novos pontos de contato nascendo a toda hora por conta da entrada de novos membro em seu time?
E isso sem contar no tempo de onboarding do novo colaborador, que provavelmente precisará do acompanhamento de uma pessoa mais experiente para guiá-lo nos seus primeiros dias.
Agora imagine todos esses esforços que eu citei acima em um ambiente onde prazos já estão atrasados. Fred Brooks já falava sobre isso lá em 1975, em seu ainda atual livro “The Mythical Man-Month”: “adicionar mais pessoas atrasa, e não acelera, o cronograma”.
Dê uma olhada no gráfico abaixo, retirado do livro citado.
Uma dica de como você pode contornar esse problema é tentando repriorizar suas entregas. Eu entendo que, muitas vezes, a necessidade de inovar rapidamente nos fará querer apressar as coisas. Mas a priorização com foco no que gerará mais valor ao usuário pode fazer com que você alivie o peso em seu time e volte a ter a produtividade desejada sem ter que adicionar mais pessoas em seu processo.
Sua taxa de bugs é alta
Você sabia que mais de 17 horas por semana é o tempo usado por desenvolvedores para corrigir bugs ou outros problemas de qualidade? Já encontrei, durante algumas reuniões de negócios que fiz recentemente, casos de empresas onde 80% do tempo do time era usado para correção de bugs! Conto isso no vídeo abaixo.
A ideia central aqui é que bug significa retrabalho, e se o maior foco do seu time está em corrigir bugs e não em evoluir o produto, o valor que você está gerando para o usuário final é baixíssimo.
Então, sim: se você não está vendo seu time inovar, pode ser que o problema não seja falta de braço, mas sim a quantidade de retrabalho que está sendo empregada. E, afinal, não faz sentido colocar mais pessoas para desenvolver se, no fim do dia, é bem provável que elas introduzam ainda mais bugs no circuito, gerando um ciclo vicioso.
Esse cenário, comum muitas vezes até em times mais maduros, pode ser um sintoma de um problema não tão incomum quanto poderia ser: a falta de cultura da qualidade através da equipe.
Cultura da qualidade, como já expliquei aqui no blog em outras ocasiões, é um sistema onde todas as pessoas envolvidas no processo de desenvolvimento têm em mente que são responsáveis pela qualidade final do que está sendo entregue.
Sendo assim, garantir que o produto não irá ao ar com bugs não é responsabilidade apenas do profissional de testes, mas um resultado de como o produto é pensado e desenvolvido por todos os papéis inseridos.
Saiba mais sobre como ajudamos a Whirlpool a aplicar a Cultura de Qualidade.
Introduzir a mentalidade da qualidade em sua equipe vai mitigar os riscos de introduzir bugs em sua aplicação durante a fase de desenvolvimento ou até mesmo durante a etapa de levantamento de requisitos (que, acredite ou não, é onde mais da metade dos bugs nascem). Isso diminuirá seu índice de retrabalho, tornará o processo mais ágil e desbloqueará tempo do seu time para inovar.
Seus processos ainda não estão devidamente organizados
Se você quer evoluir seu produto, mas ainda não adota algumas práticas internas para te dar velocidade no processo, tenha cuidado. Talvez você precise colocar a casa em ordem antes de trazer mais integrantes para dentro dela.
Por exemplo, pense em seu processo de deploy: ele é automatizado ou as releases ainda são feitas de modo manual? No último caso, será que faz sentido colocar mais pessoas no processo para que elas coloquem mais itens na fila de publicação?
E quanto ao roadmap do projeto, ele está estruturado ou você ainda vê pontos de melhoria para acompanhar a organização do trabalho que está sendo feito e das metas que estão sendo perseguidas? Se ainda há melhorias a se implementar, será que aumentar o time é uma boa?
Pense nos pontos da sua operação que não estão rodando da maneira ideal e imagine como eles podem piorar ao trazer mais gente para seu time.
Próximos passos
Como eu disse, a contratação é um movimento que precisa ser bem planejado e feito pelos motivos certos. Por isso reforço a necessidade de você entender o que te faz pensar nessa solução como a mais viável para o seu cenário.
Isso será benéfico tanto para a sua operação, que verá melhorias através do caminho que você decidir traçar, como também para os próprios desenvolvedores: sabemos que contratar é difícil, e fazer isso pelas razões erradas pode ter implicações indesejadas para as pessoas.
Use os termos que explorei acima como um assessment para descobrir o que faz sentido para a sua realidade e, a partir daí, trace a melhor estratégia para enfrentar seus desafios. O importante é ter em mente que, independente do que você escolha fazer, o objetivo final ainda é apenas um: gerar valor para seu usuário.
