Compartilhar no facebook
Compartilhar no twitter
Compartilhar no linkedin
4 de junho de 2021

O gargalo nas empresas de tecnologia do qual poucas pessoas falam

Sabe qual é o problema da maioria das empresas? Elas acham que podem melhorar sua performance como um todo ao otimizar individualmente partes da empresa.  

Pareceu confuso? Calma que esse texto vai te ajudar a entender.

Para começar, temos que definir algumas premissas:

i) Todo sistema tem um gargalo pior do que os outros; Se todo o sistema sempre tem um gargalo que é pior que todos os outros, também podemos concluir a segunda premissa: ii) o desempenho de qualquer sistema é limitado pelo seu pior gargalo – em outras palavras, a resistência de uma corrente é igual à resistência de seu elo mais fraco. Basta que um elo se rompa para que a corrente se torne inútil.

Exemplo 1

A padaria que todo o gestor em empresas de tecnologia gostaria de ter
A padaria que todo o gestor em empresas de tecnologia gostaria de ter

Imagine que você é dono de uma padaria e percebe que sempre tem clientes insatisfeitos pela demora na fila do caixa. A sua primeira ideia é aumentar a quantidade de caixas disponíveis, certo? 

Mas será que o problema está de fato ali? Ou será que é porque a internet da máquina do cartão de crédito está ruim? Será que seu público prefere pagar em dinheiro e está faltando troco? Será que, na verdade, a pessoa responsável pelo caixa está sem treinamento e demorando muito? São muitas possibilidades. 

Adicionar mais um caixa talvez seja uma solução local ótima e não necessariamente uma solução global – seria necessário investigar. 

Definições:

Melhorias isoladas são conhecidas como “local ótimo” (ou, no contexto de matemática aplicada e ciência da computação, “Local optimum”). Essa melhoria é focada numa parte individual do todo – e isso nem sempre é bom para a empresa.

Também existe o termo “Global Optimum” que significa que a melhoria em si é melhor para o desempenho do sistema como um todo. 

Ao longo do texto vou exemplificar ainda mais estes conceitos.

“Mas Marcell, o que raios isso tem a ver com empresas, gargalo de tecnologia e Product Management?” Tudo. 


Vamos agora para um contexto de empresas de tecnologia onde existe o papel do Product Manager.

Pense nas empresas que você trabalhou e como elas, em via de regra, funcionam. De um jeito simplório funciona assim: Os executivos se reúnem e decidem que é a hora da empresa melhorar o KPI “XPTO”. Logo em seguida é feito um anúncio para a empresa inteira dizendo que a prioridade número 1 é o KPI “XPTO”.  

E o que acontece? O modelo clássico de cascatear os objetivos pelas áreas. Inclusive se você usar um framework de OKRs – esse KPI agora se tornou prioridade número um e começa a cascatear por todas as áreas da empresa. Com isso, cada líder começa a priorizar iniciativas que impactam este KPI.

Porém o problema está justamente aí: Nessa hora que a cascata é feita, cada área da empresa, muitas vezes, olha somente para os seus KPIs (local optimum, lembra?) e pensam somente nas melhorias locais, das suas áreas individualmente e não no todo (em vários lugares isso também é conhecido como “Silos”). 

Os OKRs ajudam a mitigar isso por meio de alinhamentos, check-ins mensais e até os famosos “Shared OKRs“. Entretanto, isso não resolve o problema, afinal o viés de pensar em metas da sua própria área é maior (principalmente se isso contar na avaliação de desempenho do colaborador).

Isso é uma doce ilusão que os executivos possuem – principalmente aqueles que nunca estiveram executando no dia a dia e possuem uma falta de sensibilidade com a realidade. 

Já ouvi comentários como “Nossa, a empresa inteira realmente está empenhada em melhorar o KPI ‘XPTO”. Enquanto, na verdade, essa filosofia está completamente errada, pois para melhorar um KPI ou um sistema/processo como um todo, melhorias individuais nem sempre são as melhores alternativas – principalmente com a falta de alinhamento entre áreas onde os incentivos são bem diferentes. 

Esse é o ponto importante sobre o ótimo local em sistemas complexos: os ótimos locais não são apenas algo do tipo “ah, está bom o suficiente”. Na verdade, dependendo de como você implementar, eles podem tornar as coisas piores do que se você não tivesse feito nada. É isso que a Teoria das Restrições propõe resolver e foi daí que surgiu o termo “Local Optimum“.


Exemplo 2

Agora que o conceito está mais claro, vamos em mais um exemplo, dessa vez ainda mais ilustrativo. 

Imagine uma startup quente ali pelos seus Series D ou E. Ela está bombando. Todo mundo quer trabalhar lá. Linkedin é cheio de likes. Uma vaga aberta tem mais de 2.000 aplicações. Incrível!

Agora, para fins ilustrativos, imagine que essa startup sexy é um marketplace B2B2C – e, naturalmente, as áreas que mais demandam para Produto e Engenharia são Marketing e Comercial. Como já é de se imaginar, existe muito mais demanda, ideias de projetos e coisas que são “must-have” do que a engenharia consegue construir a tempo. 

Gargalo nas empresas de tecnologia

É nessas horas que o bicho pega – se engenharia virou gargalo então o que as outras áreas vão fazer? E a área de produto e design? Elas vão trabalhar em projetos que serão feitos depois de 6 meses ou 1 ano? Mas aí até começaram a implementar vai estar tudo defasado – e acredite, eu já passei por isso. Já tive a grandiosa missão de fazer discovery por 6 meses porque não haviam engenheiros disponíveis. Triste. 

E por que isso acontece? Porque as empresas operam sob uma regra universal do mercado de trabalho: “esteja ocupado.” E não algo como “Otimize ao máximo seu tempo e esforço”. Com isso, as pessoas precisam estar ocupadas produzindo coisas que, em sua maioria, não serão utilizadas, pois até chegar a hora de ser desenvolvido já ficou datado ou as prioridades mudaram.

Mas também não dá para culpar os middle managers, afinal, eles não podem ter um recurso subutilizado. E também não dá para culpar os funcionários, até porque não tem nada pior do que estar num emprego onde parece que você tem pouca coisa pra fazer – a culpa mesmo é da alta liderança (C-levels, diretores, etc).

Enquanto a engenharia está com gargalo, as outras áreas resolvem criar mais projetos – e, obviamente, tem de tudo. Desde ideias “inovadoras” até estudos que podem ser relevantes. Mas a verdade é que isso gera ainda mais problemas, porque esses novos projetos eventualmente se tornarão demandas para engenharia e produto. E por mais que você tenha equipes maduras na área de tecnologia que saibam dizer não, ficar dizendo não, analisando demandas e participando de reuniões é extremamente desgastante e leva tempo.

Quando as empresas chegam nesse ponto (e acredite, eu já trabalhei em várias que chegaram a isso), todo mundo começa a ficar frustrado, os resultados começam a atingir um platô, nenhum produto é lançado e o “management team” sente a necessidade de fazer algo. 

E o que eles fazem?

Se tiverem funding (lembrem que é uma startup sexy e com várias rodadas de investimento), vão contratar mais gente.

Genial!

Agora o gargalo é ainda maior. Porque além de ter o gargalo antigo, você adicionou pessoas que ainda vão precisar passar pela curva de aprendizado e você nem sequer resolveu o primeiro gargalo. Lembra das premissas do início do texto? 

i) Todo sistema tem um gargalo que é o pior de todos;

ii) O desempenho de qualquer sistema é limitado pelo maior gargalo.

É por isso que temos fadiga do Zoom, pessoas se sentindo miseráveis nas empresas, gente com anos de experiência sem cases para relatar – tudo isso porque as empresas são ineficientes e acreditam que a forma de serem mais eficientes é contratando. Os gestores esquecem que precisam resolver o maior gargalo de todos antes de pensar em otimizações locais dos gargalos menores – e não, nem sempre é contratando mais gente que você resolve o principal gargalo.

Infelizmente já vi isso acontecendo em outras áreas também, como Customer Support, por exemplo. Algumas empresas fazem um cálculo de quantos agentes de suporte são necessários a cada N clientes e saem contratando pessoas ao invés vez de melhorar a eficiência.

Qualquer otimização que não seja no gargalo é perda de recursos. Você conseguirá ter belas apresentações, projetos incríveis e projeções promissoras. Mas o produto na rua que é bom, não. 

Procure otimizações globais antes de sequer pensar em otimizações locais. Pode parecer bobo, mas fazer exercícios como os “5 porquês” pode ajudar a identificar os gargalos e ajudar você nessa priorização. É claro que muitas vezes isso não vai ser uma decisão do Product Manager, mas ao ter a visão holística do negócio e identificar os gargalos você poderá argumentar melhor com sua liderança para definirem melhor a estratégia de ataque.

Agradecimentos ao aluno da PM3, Leo Aragão, que fez uma pergunta sobre o que era “ótimo local” em uma das aulas do Joaquim Torres e me inspirou em fazer esse artigo. Também agradeço a estas pessoas por terem revisado e dado feedback no texto: Bruno Coutinho, Camila Duarte, Lucas Omeltech, Priscilla Lugão, Raphael Farinazzo.

Referências:

Autoria de:

PROMO JUNHO CPG + Camiseta

campanha promocao junho camiseta curso de product growth pm3 growth hacking product

PM3 Lives 27

pm3 lives gabriel werlich coaching product managers involves

Newsletter Mensal

E-book Entrevistas PM

Você também pode gostar de ler

Conheça as mentorias em grupo da PM3

Aqui na PM3 estamos em constante evolução. Fazemos questão de proporcionar não apenas novidades para o mercado brasileiro de Product Management, como também otimizar cada