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
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.
É 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:
