O mundo real é obviamente confuso, complexo, raramente existe uma única razão para o que acontece. Mas eu acredito que há algo a ser dito, como uma hipótese, sobre os recentes layoffs (ou demissões em massa, em bom e velho português) em empresas de tecnologia, que talvez vá de encontro, ou fuja um pouco, à lógica comumente aplicada, que é a de colocá-los principalmente na conta da piora da situação econômica global.
Isto não é o mesmo que desconsiderar tal fator como um contribuidor concreto. É e tem potencial significativo de impacto. Mas se pode argumentar que organizações que querem ser a prova de futuro, necessitam ser resilientes e capazes de navegar por águas turbulentas sem tanto impacto.
Ajustes, talvez. O nível que estamos vendo vai muito além disto, por uma ordem de magnitude. E o fato de que ainda existem empresas contratando, conforme consolidado, por exemplo, pelo ótimo blog/newsletter, The Pragmatic Engineer, corrobora minha avaliação.
A pergunta que não quer calar é quantas destas empresas que reportam ainda estar em expansão de times, podem estar tão enganados quanto as que já procederam com as demissões, só estão defasadas ou algo do tipo. As cartas estão nas mesas, e só o tempo dirá com certeza.
Mas quando eu me refiro a (possivelmente) ‘estarem tão enganadas’, o que exatamente quero dizer?
Eis que chegamos, enfim, à minha hipótese, do que pode ser uma espécie de sinal fraco de outras coisas muito mais fundamentais em jogo. Perceba a nuance do plural, pois aqui, possivelmente vários fatores de relevância podem também influenciar.
E eu quero trazer um par de fundamentos básicos que eu acredito que podem estar conectados, e com isto também prestar meu pequeno tributo a uma das maiores referências em pesquisa ligada a desenvolvimento de software, que recentemente nos deixou.
Lei de Brooks – ou tempo e escopo nem sempre interagem de forma linear
Fred Brooks, que nos deixou aos 17 de Novembro deste ano (2022), em sua clássica obra “O Mítico Homem-Mês”, observou que a adição de mais força de trabalho (gente) em projetos de desenvolvimento de software pode ser um tiro que sai pela culatra, e fazer com que se leve mais, não menos, tempo. E isto é o que comumente se refere como Lei de Brooks.
Isto não é só empiricamente comprovado, como também faz sentido lógico:
- Leva tempo para um novo desenvolvedor começar a adicionar valor a um projeto. E com efeito, toma tempo de outras pessoas para que esta curva de aprendizado ocorra de forma efetiva.
- A sobrecarga de comunicação aumenta com o aumento do número de pessoas, e possivelmente de uma forma exponencial.
- O trabalho do conhecimento, tal como desenvolvimento de software, não são tão divisíveis como outros de natureza mais mecânica. Aqui Brooks costumava utilizar uma metáfora, que hoje alguns consideram um tanto politicamente incorreta, mas que, sim, explica apropriadamente o conceito: “nove mulheres não podem gestar um bebê em um mês”.
O ponto, e de fato a conexão, que eu estou tentando trazer aqui é que eu acredito que muitas startups, scaleups e mesmo algumas empresas de tecnologia mais estabelecidas, ainda frequentemente caem na armadilha que a Lei de Brooks tenta nos alertar. No sentido de que há um forte foco em que crescimento exponencial requer crescimento do tamanho de time também, de mesma natureza, exponencial.
Isto não precisa ser necessariamente assim, e pode, de fato, adicionar complexidade de uma forma desnecessária – já que se pode argumentar que, na medida que as coisas já estão se tornando mais complexas pela adição de mais clientes ou usuários e consequentemente interações com estes, deve-se ter um cuidado maior para não adicionar complexidade de uma forma auto-infligida, com o aumento simultâneo muito rápido do tamanho do time.
Em artigo recente, Jason Fried, co-fundador e CEO da 37Signals (criadores do Basecamp e HEY), traz justamente esta reflexão em questionar essa lógica.
A ideia fundamental, na minha visão, é esta:
Há sempre escolha – e se pode deliberadamente escolher fazer mais, mas melhor.
Sempre lembrando que esta é uma das grandes oportunidades que software, comparado com hardware, nos traz: não precisamos definir hoje como o produto vai estar, nem quando lançado, nem quando alcança adequação ao mercado, nem em nenhum momento depois. Podemos trilhar o caminho passo a passo!
O que me traz ao segundo ponto.
Bom e velho gerenciamento de projeto básico ainda deveria existir...
Aqui estou arriscando gerar certa polêmica, talvez alguns ‘disjuntores’ vão cair na cabeça de alguns que ainda vêem o mundo de forma mais binária, ou dicotômica. E neste contexto, alguns declararam a morte de gerenciamento de projeto em favor de uma perspectiva mais baseada em produto, na forma de executar. Eu acredito que isso desconsidera várias coisas, sob vários prismas, mas eu não terei tempo de me aprofundar nisso (quem sabe um próximo artigo!?).
Restrinjamo-nos ao básico, de que trabalhar baseado em produto não exclui, no frigir dos ovos, o fato de que se vai preparar algum trabalho que precisa ser executado, como parte de um experimento ligado a uma hipótese, ou algo do tipo, o que, em última análise, pode ser visto como um tipo de (pequeno) projeto. É o que práticas como GIST, para a definição de roadmap, define, por exemplo, até.
Meu ponto é um pouco mais básico que isto... Para falar do trade-off (ou balanço, se preferir o termo mais próximo em português) entre tempo e escopo, que conforme vimos na Lei de Brooks sequer necessariamente apresenta comportamento linear. Ainda assim, podemos constatar que, fundamentalmente:
Quanto mais se queira fazer, a tendência é de que vai demorar mais... (ou pelo menos ser muito mais complexo de se executar de forma rápida)
O que nos traz novamente à questão das escolhas, e deliberação...
Sintetizando tudo, o que estou sugerindo, ou traçando uma hipótese, é que empresas de tecnologia, principalmente em fase de expansão, podem estar caindo facilmente nesta espécie de armadilha dupla, em que crescem suas ambições e escopo (talvez como uma razão para atrair mais investimento), e por causa disto pensem logicamente que necessitam mais capacidade de execução, mas meio que tomam uma dose muito alta deste ‘remédio’, de tal forma que as coisas ficam mais, não menos, difíceis de serem feitas.
Há certa beleza em manter o tamanho do time em cheque, e crescer em linha com real aumento da demanda e quando não se pode mais deferir comprometimentos.
Até lá, é muito mais eficiente exercer escolhas difíceis e de forma deliberada do ‘o que’ – e mesmo quando esteja lá, quais são as partes essenciais agora - e que se pode executar até ‘quando’. Relembrando, o básico de gerenciamento de projetos, enquanto disciplina, ainda é algo relevante, quiçá ainda mais num contexto de trabalho do conhecimento como tecnologia e suas inerentes complexidades (como a Lei de Brooks).
É sobre o amadurecimento das escolhas, e processo deliberado e transparente de como elas são feitas, para que se separe bem ‘DESEJO’ (gostaria de algo) de ‘NECESSIDADE’ (estou disposto a pagar por este algo) – “needs over wants” (talvez seja um embrião para um manifesto de produto?).
“When we buy a product, we essentially 'hire' something to get a job done. If it does the job well, when we are confronted with the same job, we hire that same product again. And if the product does a crummy job, we 'fire' it and look around for something else we might hire to solve the problem.” -- Clayton Christensen (Theory of Jobs To Be Done)
