Ep.02 - Fatie o Problema - Gestão de Dependências

A gente conseguir fazer com que esse conhecimento flua cada vez mais, para tornar esses times, essas pessoas, cada vez mais autônomas na resolução do problema. Então, é importante a gente estar preparado para entender quando a cultura se adapta e começa a levar a gente para o mesmo lugar de antes, ela vai engolindo ali a nossa solução, e entender que movimentos a gente precisa fazer para, então, revigorar essa prática, essa intenção que a gente tem de mudança.

É óbvio quando a gente fala isso, mas, gente, quando a gente chega nas empresas, é desesperador, porque as pessoas não conseguem ter esse mapeamento, né? Porque tudo é tratado como importante. Em qualquer cenário, fazer essas escolhas difíceis é uma das coisas mais importantes, porque é o que separa a gente de estar ali rodando em círculos, tentando entregar tudo ao mesmo tempo e não saindo com nada do outro lado, para que a gente realmente consiga entregar valor, né? Porque dificilmente, a gente consegue mexer nas pessoas de uma forma rápida, ou a gente consegue mexer na estrutura de uma forma rápida. Dificilmente você vai encontrar um cenário onde você vai fazer ctrl -c, ctrl -v de uma solução.

É um quadro que está trazendo para a gente muita conexão com as pessoas. Tem muitas pessoas me mandando mensagem com coisas que a gente pode trabalhar aqui no quadro e eu já aviso que temos um backlog já enorme de problemas para resolver. Então, vamos começar destrinchando o problema de hoje, tá? Vamos lá, vamos ver se vocês conseguem se identificar com o que eu vou falar. É uma empresa grande que reestruturou toda a sua tecnologia. E a reestruturação aqui não foi a gente trocar as pessoas de lugar.

É toda a tecnologia antiga, né? Sistemas que foram construídos em linguagens que hoje em dia já estão defasadas ou que eles não conseguem, por exemplo, achar profissionais que trabalham com essa linguagem. E aí eles pegaram todos esses programas, essas tecnologias e resolveram modernizar para tecnologias mais atuais. Então, eles criaram novos times de desenvolvimento, segregaram responsabilidades, né? Desenharam no papel como que as pessoas iriam se conectar, fizeram um programa bem bonito, um programa bem legal, um plano bem estruturado e muito bom no PPT. Só que na prática, quando a gente entendeu um pouco mais, né? Quando eu conversei com a pessoa, a gente conseguiu entender qual era a característica do case, eu percebi que estava tudo uma bagunça.

Então, o que eu entendi é que tinham mais ou menos uns 13 times distintos e cada time, né, com a sua unidade de PO, liderança, tech lead e time de desenvolvimento múltiplos. Esses times rodavam, né, esses papéis lá o tempo todo. Eles estavam trabalhando dentro das suas instâncias, só que os papéis não estavam 100 alinhados com essa necessidade desses times de modernização. Então, apesar de eles estarem trabalhando nesse projeto da modernização, eles também trabalhavam em outras coisas. E aí, fora que eles percebiam ao longo dessa jornada que em algum momento eles começavam a identificar muitas dependências entre esses próprios times e entre esse time de modernização, né, que foi estruturado como se fosse uma nova empresa de tecnologia, e entre esse time de modernização, né, que foi estruturado como se fosse uma nova empresa de tecnologia, que mantinha o produto rodando.

Então, eles tinham muitas dependências entre eles, enfim. Esse é o problema, será? A gente tem várias outras pessoas que se identificam com pessoas compartilhadas, dependências demais acontecendo e que a gente só descobre lá no momento do desenvolvimento.

Eu achei muito legal que você trouxe esse problema, Samy, porque enquanto você estava falando, eu estava lembrando de vários outros casos e cenários. Tem um que eu conheço que se identifica bastante em proporções e necessidades um pouquinho diferentes, mas que se aproximam muito. Uma vez eu acompanhei uma empresa que eles tinham, o grande problema de tecnologia deles era o tal do monolito. Nossa, nosso sistema todo, o principal, teve um grande monolito, a gente precisa migrar essa tecnologia, não dá para ser feito assim, é muito difícil de fazer deploy, é muito difícil de, quando você identifica um erro em produção, você retornar. E aí, beleza, né? Então, troque e modernização da tecnologia para vamos quebrar o monolito. É a mesma coisa nesse caso.

E eles se organizavam originalmente numa grande equipe de tecnologia e uma grande equipe de produto e experiência do cliente, que eram estruturas completamente separadas. E aí, da mesma forma, botamos o nome de todo mundo na caixinha assim, ó, balançou e surgiram, na época, cinco times multidisciplinares com papéis e responsabilidades diferentes. Seria tudo muito lindo se a gente tirasse os nomes das caixinhas e, a partir dali, todo mundo tivesse com clareza do que faz, como que vai se relacionar com as outras equipes, qual é o meu papel, até onde eu vou, até onde eu não vou, o que é a minha responsabilidade. Mas não basta estar escrito no papel. No dia a dia, as coisas vão acontecendo, e os problemas vão surgindo. Então, eu achei legal porque, assim, pra mim, troco os nomes aqui e já me identifiquei muito com o mesmo cenário.

Imagino que quem está ouvindo a gente também vai se identificar. E aí começa, então, nossa saga aqui do episódio. Dado esse cenário, por onde a gente começa? Dado que eu não vou conseguir resolver todos os papéis, responsabilidades, conexões, integrações entre as equipes, dependências de uma única vez, por onde eu começo? Complexo, né? Porque a gente pode analisar esse problema por diversos prismas. E aí a gente pode escolher algumas decisões. A gente pode começar olhando para as pessoas, no primeiro momento. Então, quem são essas pessoas? Por que elas estão compartilhadas? Como é que a gente dá mais autonomia e mais liberdade para elas focarem num desses problemas só? Então, a gente pode olhar para as pessoas como um prisma. A gente pode olhar para a estrutura mesmo da empresa, né?

Como que a gente faz? E apesar de ter colocado esses times numa visão separada, como que a gente faz com que eles consigam trabalhar de forma única, entregando aquele produto de ponta a ponta, sem ter que depender de muitas outras áreas? A gente pode olhar também para o prisma da dependência. Então, dado que a dependência existe, né? Vamos deixar bem claro que, gente, vai existir em qualquer lugar N características de dependência. Então, dado que já existe, como que a gente trabalha com essa restrição de diminuir essas dependências ou tentar se antecipar cada vez mais dessas dependências, tá? Eu vou falar um pouquinho de cada coisa. Vou deixar bem claro, porque, né, é aqui fatia o problema e a ideia de fatiar é a gente conseguir aprender e resolver problemas de forma mais rápida, né, cada vez mais.

Então, vamos olhar, por exemplo, para um PO ou um tech -lead, enfim, né, que estava dividido em múltiplos contextos. Então, a gente consegue, em primeiro momento, o que a gente precisa fazer é dar clareza desses múltiplos contextos e entender o seguinte, essa pessoa, ela está 50 aqui, nesse time, 50 lá em outro time, ou, tá 40 aqui, 40 no outro time e 20 do tempo dela ainda é formando outras pessoas. Essas coisas também acontecem. Então a primeira coisa é a gente identificar essas porcentagens e, gente, não vai ser muito preciso, né? Às vezes é só uma ideia de tempo. Puts, eu fico muito tempo aqui, menos tempo lá e tá tudo bem, tá? A gente não quer aqui, né, cravar o número ali certinho de como vai ser. A gente quer ter uma ideia de como é que tá a distribuição dessas pessoas.

Então essa é a primeira coisa que a gente precisa fazer, entender como que o time tá ali distribuído e o que que a gente pode fazer, né, de acordos com as lideranças pra que a gente consiga tirar cada vez mais essas pessoas de múltiplos contextos e diminuir a quantidade de coisas que elas façam. Mas pensa bem, é uma coisa que tem que tá dividida com os líderes porque isso envolve dinheiro, né, envolve investimento. Então às vezes a gente vai chegar num momento onde a gente vai olhar e vai falar assim, putz, mas ó, a Rafinha, ela tá dividida 50 aqui e 50 lá. Eu não posso tirar ela de lá de forma alguma. Mas será que eu posso ter outra pessoa pra substituir ela aqui? Então a gente precisa começar a tomar essas decisões. Primeira coisa, gente, enxergar como que essas pessoas estão olhando pra essa fatia, né, pra esse prisma do problema e quais são as pequenas alavancas que eu já consigo fazer pra diminuir a quantidade de paralelismo de trabalho dessas pessoas.

Segunda forma, né, a gente falou, é, a primeira forma foi as pessoas, a segunda forma é a reestruturação como um todo. É olhar pra essas equipes e falar assim, será que ao invés de eu ter uma equipe A cuidando desse produto por esse prisma e a equipe B cuidando do mesmo produto por outro prisma, será que eu não consigo ter o mesmo time e aqui dentro do time eu divido as características do tipo de demanda? Pode ser que isso, inclusive, né, diminua o impacto da dependência, que é a terceira forma de olhar pra esse problema. Mas, isso também pode aumentar o nosso tempo de entrega. Então eu vou estar ali dividindo as características de tipo de demanda, repriorizando esse backlog como se fosse um backlog único e isso consecutivamente pode impactar no tempo de entrega daquele trabalho.

Então, mais uma vez, são acordos que a gente vai ter que fazer pra começar a resolver esse problema. E aí rapidamente a última fatia é a gente olhar pras dependências e tentar arrumar uma forma da gente se antecipar a elas. E aí eu confesso aqui, se eu tivesse que trabalhar nesse contexto, essa seria a fatia que eu escolheria. Porque dificilmente, né, a gente consegue mexer nas pessoas de uma forma rápida, ou a gente consegue mexer na estrutura de uma forma rápida. Então, enquanto eu tenho essas outras duas fatias ali, né, com desejos de acontecer, eu vou deixar o time sofrendo com esse problema todo de dependências e tudo mais. Então, a forma mais rápida de eu trabalhar nisso e eu conseguir já resolver o problema das pessoas, é trabalhar nas dependências.

Então, como que eu consigo, de uma forma estruturada, olhar pra essas dependências, por exemplo? Eu gostaria de que a gente começasse por essa fatia aqui, porque é o jeito mais rápido que eu acredito que os nossos ouvintes vão conseguir resolver essas coisas no dia a dia. O que você acha, Rafinha? Eu acho muito bom. Eu acho que tem uma coisa interessante, que é assim, a gente consegue, geralmente a gente consegue resolver dependências de duas formas, né? Ou a gente mexe na estrutura e a estrutura que papéis, responsabilidades, como os times se organizam, como é o organograma da empresa, quem responde pra quem, como que tá estruturada a minha visão de produto, portfólio, né? Então, eu mexo na estrutura base pra que a dependência seja reduzida, mas a gente também mexe em dependência com coordenação.

Então, muitas vezes, quando é um passo grande demais eu mexer na estrutura, ou eu não sei por onde começar na estrutura, começar a tratar dependências a partir de uma visão de coordenação, que basicamente é a gente colocar as pessoas que estão envolvidas naquelas dependências juntas pra conversar e resolver o problema, costuma ser um caminho mais fácil. Então, eu gosto que a gente venha falar de dependências porque não existe uma única solução pra dependências, né? Então, se eu não consigo mexer na estrutura, eu consigo mexer na coordenação. Se a coordenação é complexa demais e eu preciso mexer em algo na estrutura, eu posso mexer uma parte da estrutura pra resolver aquela dependência que tá mais conectada com a principal entrega de valor que eu vou fazer agora.

Isso abre pra gente a possibilidade de diferentes caminhos pra diferentes cenários, o que é muito importante porque, por mais que o mesmo problema aconteça em várias empresas, ele nunca vai ser igual em todos os lugares e a solução também não vai ser igual em todos os lugares, né? É, eu tive esse problema num cliente recente. E aí eu acho que vale a pena eu contar aqui o que meu cérebro pensou e como que a gente estruturou essa coisa toda, porque bate exatamente nesse ponto que você tá fazendo. Resolver a coordenação, né, do trabalho, gente. Então, é muito importante deixar claro que quando a gente fala de coordenação, aqui, a gente tá falando de como que o trabalho flui dentro dessa empresa. E aí é óbvio que as pessoas, elas vão precisar se movimentar pra que esse trabalho flua cada vez mais, tá?

Então a gente não tá falando aqui de ficar, é... mandando nas pessoas o que elas precisam fazer, a gente tá falando pra que o trabalho precisa acontecer, a gente precisa se estruturar enquanto time pra que esse trabalho flua da melhor forma possível. E aí, nesse lugar que eu trabalhei há pouco tempo, eu entendi que, primeiro, né, não dava pra gente conseguir resolver todas as coisas de uma vez, porque sabe aquele ditado, que a gente puxa uma pena e vem um dinossauro? Era assim que eu me sentia lá, a gente puxava um problema, e aí vinham coisas muito maiores por trás que a gente tinha que priorizar e resolver. Então, já aceitar que não dá pra resolver tudo de uma vez, é muito importante. Então, o que que eu podia fazer com o menor custo possível?

O que eu podia fazer era dar visibilidade dessas dependências. Então, eu criei nessa empresa um mapa de dependências, mas não era mapeado, mas de qualquer forma, né, a gente tinha que mapear de uma forma inteligente. O que que eu pensei? Eu pensei em classificar essas dependências na matriz básica de impacto e urgência, mas não da forma como tava planejada a matriz inicialmente, mas a gente olhar o seguinte, será que eu consigo classificar essas dependências, né, com subclassificações que nos permita depois colocar ela melhor nessa matriz? Então, pensa aqui comigo, o que que eu pensei? Eu pensei que essa matriz, ela devia ter quatro quadrantes importantes. O primeiro quadrante é colocar ali quais eram as dependências que precisavam ser resolvidas em até quarenta horas, quarenta e oito horas, porque se a gente não resolvesse em quarenta e oito horas, o time todo ia ficar sem trabalhar, o projeto ia deixar de entregar, a gente ia ter qualquer tipo de problema que ia impossibilitar daquele grupo de pessoas para elas trabalharem.

Então, não era só sobre eu deixar de entregar o trabalho, era eu impactar o trabalho de todo mundo. Então, essa matriz, ela devia ser resolvida para ontem. O segundo quadrante era aquilo que eu não precisava resolver para ontem, mas se eu não resolvesse logo, ia impactar essa entrega dentro desse trimestre. Então, o primeiro quadrante era altamente crítico, esse segundo quadrante, ele era crítico, relevante, porque se eu não resolvesse aquele problema, aquela dependência, a gente que se comprometeu com aquela entrega, né, naquele tempo, a gente não ia ter aquela entrega. O terceiro quadrante era o que é importante de ser feito, mas eu ainda consigo resolver isso com uma alternativa diferente, sabe? Fazer um puxadinho ou fazer de uma forma manual alguma coisa.

Então, essa dependência, ela é crítica ainda, mas eu tenho uma criticidade muito mais baixa. Então, ali é meio médio na criticidade. Por quê? Porque eu tenho uma alternativa para resolver ela. Não é a alternativa ideal, não é a alternativa que vai ficar para frente, mas eu ainda consigo resolver. E aí, o último quadrante é aquilo que a gente pode deixar para resolver lá para o final do trimestre, porque não vai impactar em nada naquele trimestre. Ela vai começar a impactar em trimestres para frente, entregas para frente. Então, ela tem ali uma criticidade muito mais baixa e a gente pode não se preocupar com ela agora, mas ela precisa ainda estar no radar, porque ela vai ter o impacto lá na frente. E aí, parece muito óbvio quando a gente fala isso, mas, gente, quando a gente chega nas empresas, é desesperador, porque as pessoas não conseguem ter um alinhamento, né?

Porque tudo é tratado como importante. Quando a gente conversa, principalmente quando a gente fala de gestão de backlog, e a gente conversa com POs e pessoas que estão trabalhando naquele backlog, tudo é importante, porque eles recebem essa visão de que tudo precisa ser tratado como importante, tá? E aí, o que eu fiz? Eu criei uma cadência, uma reunião, que nesse caso era quinzenal, onde a gente só olhava para essas dependências e a gente, de fato, discutia essa importância. E a gente entendia o que era urgente de verdade. Então, aparecia um item, eu falava assim, tá bom, mas se eu não fizer esse item, qual é o impacto dele? Aí, o time A vai deixar de fazer tal coisa. E aí, eu perguntava, time A, quando que essa coisa está planejada para ser feita?

E o time A falava, não, só vou fazer isso daqui no final do ano. Puts, olha que legal, né? O time que estava com aquela dependência achava que era importante demais, e é importante, mas ele achava que se não fizer agora, está a entrega do outro time. Só que o outro time estava planejando essa entrega para daqui a seis meses. E aí, a gente começou a discutir e dar essa visibilidade e entender de fato o que era urgente. E aí, o que era urgente, a gente saía com acordos claros de quem ia resolver aquele problema. Quem ia se comprometer em resolver aquele problema. E esse problema, dependendo da classificação lá nos quadrantes da matriz, ele tinha que ser resolvido em até 48 horas, ou a gente tinha um pouquinho mais de tempo. Basicamente, é isso que a gente começou a fazer, tá?

Nesse cliente. E foi bem legal, porque a gente começou a discutir, de fato, sobre priorização, sobre urgência e, o mais importante, né? Tirar um pouco da panela de pressão das pessoas de que tudo que tinha que ser feito era urgente. E aí, as pessoas, às vezes, ficavam fazendo diversas horas extras para trabalhar numa urgência que, às vezes, nem existia, porque elas não tinham visibilidade do trabalho como um todo. Eu acho que uma coisa crucial aí, Sam, é que, às vezes, falta critério. As pessoas precisam ter critério para definir o que é urgente. E quando existe uma ausência de critérios, que eu não consigo olhar criticamente mesmo, né? Para um pedido, para uma determinada urgência, e entender o quanto aquilo, de fato, é para agora, ou o quanto aquilo pode esperar, a gente tem dois riscos, né?

A gente tem o risco daquilo que eu estou tratando como se fosse um incêndio que eu tenho que apagar agora e só vai ser usado daqui a seis meses. E a gente tem o outro item, que pode ser algo que eu preciso resolver agora, mas que está passando junto com tantas coisas que eu acabo deixando para depois. E muitas vezes, né? Acho que a gente, quando vai falar sobre priorização e sobre a importância de cada coisa, a gente sabe, gente, que tudo é importante. Se não fosse importante, não tinha alguém advogando por aquilo dentro da empresa, né? É importante para alguém, é importante em algum contexto, é importante para alguma entrega. Porém, a gente tem que fazer escolhas difíceis e em qualquer cenário, fazer essas escolhas difíceis é uma das coisas mais importantes, porque é o que separa a gente de estar ali rodando em círculos, tentando entregar tudo ao mesmo tempo e não saindo com nada do outro lado, para que a gente realmente consiga entregar valor, né?

E uma outra coisa que eu fiquei pensando aí enquanto você falava também, é sobre essa questão da gente ter uma visão de roadmap dessas dependências, né? De quando que essas dependências são, de fato, impactantes, qual é o momento ideal para que a gente possa tratá -las, porque, de novo, não vamos conseguir tratar tudo, né? Então, a gente, às vezes, fica muito, vê, né, as pessoas muito focadas em fazer o roadmap das entregas, mas fazer o roadmap das dependências pode ser tão importante quanto, né? E aí tem um ponto relevante, porque esse roadmap das dependências, a gente extrapola um pouco essa visão de quando essa dependência vai estar, né, prevista para ser resolvida ao longo de um tempo. Mas a gente também olha para a quantidade de pessoas, mesmo as pessoas que resolvem as dependências.

Então, às vezes, também, ainda mais no mesmo tempo, né, a gente tem uma empresa, né, onde é uma empresa muito grande, mas que a gente tem o conhecimento de algumas partes do produto restritas em algumas pessoas, a gente começa a enxergar que o gargalo, no caso, além da falta de visibilidade dessas dependências, também é no ser humano. Então, eu começo a ver, por exemplo, que eu tenho a mesma pessoa resolvendo as dependências distintas nesse roadmap, mas que são dependências que se conectam com o mesmo assunto, com o mesmo produto. E aí a gente tem aqui um outro insight que aí se conecta, lembra, com a primeira forma de resolver esse problema? Que a gente olhar e falar o seguinte, olha, temos que tomar uma decisão. Eu tenho aqui a Samira, por exemplo, que está, além de estar liderando parte desse projeto, parte desse time, ela também é uma pessoa fundamental para resolver esses problemas.

E se a gente não conseguir criar aqui alguma forma de dividir esse conhecimento, né, de uma forma consciente, a gente dividir ou fazer pareamentos e tudo mais, a gente vai ter um risco muito significativo para o negócio, porque parte do negócio está dependendo exclusivamente de um ser humano, e a gente sabe que seres humanos ficam doentes, a gente sabe que seres humanos tiram férias, né, e aí como é que a gente vai resolver isso quando isso acontecer? E a gente tem aqui a falta de oportunidade de dividir conhecimento, de a gente conseguir fazer com que esse conhecimento ele flua cada vez mais, para tornar esses times, essas pessoas cada vez mais autônomas na resolução do problema. Então o roadmap é muito importante para dar visibilidade dessa cadência da resolução das dependências, mas também para a gente conseguir enxergar esses gargalos que às vezes ficam ocultos, né, no caos operacional, porque, gente, é normal, a vida acontece em qualquer organização.

E quando a gente começa a ter a clareza de quais são as pequenas alavancas que a gente consegue mexer, a gente já sabe qual é a próxima fatia do problema que a gente quer resolver.

Falando em próxima fatia então, vamos lá. Consegui visualizar com clareza minhas dependências, tenho ali a ideia de quais são as dependências mais urgentes de serem resolvidas agora, e comecei a fazer dinâmicas onde as pessoas se responsabilizam por essas dependências, elas vão lá e resolvem essas dependências dentro do prazo, né. O que vem depois disso? Então a gente tem que estabelecer essa cadência, estabelecer esse tempo que a gente vai olhar para isso, porque essa cadência é importante para a gente conseguir enxergar o seguinte, nossa, tem um monte de dependência aqui que a gente podia viver de forma mais saudável, sem estar com essa pressão de que tudo é urgência, tá? Então, além de a gente olhar para tudo isso, a gente tem que estabelecer uma cadência que a gente olha de forma recorrente para essas dependências e a gente consegue, de fato, resolvê -las.

Além disso, vocês vão ouvir talvez uma coisa que é muito recorrente de se falar aqui no Love the Problem de uma forma ampla, que é a gente precisa fazer essa coordenação, como a gente falou. Então como que eu olho para o trabalho para eu conseguir fazer, né, a priorização certa desse backlog de uma forma sistêmica? Então a coordenação raramente é individual. Ela geralmente olha para vários times ou várias áreas e a gente olha para o trabalho num nível um pouquinho mais alto, então eu posso fazer coordenação a nível de iniciativas, eu posso fazer a coordenação a nível de projetos ou a nível de épicos, sei lá, que é como que eu conecto esse trabalho todo dessa empresa, olhando para todos os times, para que os times consigam ter clareza de quando que aquele item que tem uma dependência dele está planejado para ser feito.

Então eu também tenho aqui um grande roadmap do trabalho para a gente conseguir se antecipar nessas dependências. E conforme esses itens vão caminhando nessa coordenação, a gente consegue repriorizar essas dependências e até mesmo fazer dependências desaparecerem. Então eu já resolvi isso, então eu tiro essa dependência daqui. Então a gente precisa da clareza das dependências, fazer o mapa de dependências, fazer uma cadência de dependências para principalmente falar sobre prioridade dessas dependências e quem resolve o que, sair com acordos muito claros de quem puxa o que e aí fazer uma coordenação do trabalho para a gente conseguir pegar esse trabalho e conectar com essa visão de dependências. Tão simples quanto isso, gente, só para deixar claro, tá?

Aproveitando que é simples assim, né, o que pode dar errado, Samy? Dado que é simples, acho que pouca coisa, né? Ó, vamos lá, várias coisas podem dar errado, tá? Só para deixar claro, mas... Nesse case que eu estou contando para vocês, que eu fiz esse mapa de dependência, a principal coisa que deu errado lá é as pessoas continuarem classificando tudo como urgência. Tudo, tudo era altamente crítico, tudo tinha que ser resolvido em 48 horas, tudo, tudo, tudo, tudo. E aí a matriz acabou perdendo valor porque ninguém conseguia de fato enxergar o que era urgente, tá? E aí o que a gente fez para resolver esse problema? A gente começou a trazer lideranças para esse mapeamento de dependências. Então, além de eu ter ali, né, o time técnico, o PO, o tech lead olhando para essas dependências, eu comecei a trazer lideranças que poderiam afirmar que, gente, calma, isso daí a gente pode colocar um pouquinho mais para frente.

Ah, não, isso daí não é tão urgente assim porque a gente já tem aquele acordo comercial acontecendo para resolver esse problema. Então a gente começou a trazer mais visibilidade sistêmica de coisas que aconteciam fora da instância só do time para que essas pessoas também se sentissem mais seguras de que elas podiam mudar essa visão de priorização alinhada com o discurso da liderança. Então a gente traz mais visibilidade para o que acontece, a gente melhora a visão sistêmica dessas pessoas, né, em relação ao dia a dia do trabalho, e a gente traz aqui mais segurança e autonomia para que eles consigam repriorizar melhor essas dependências. E aí as coisas voltaram a fluir até que o próximo problema aconteceu. Isso é um ponto importante porque assim, é sempre bom a gente ter clareza de que a cultura se adapta.

Então sempre que a gente traz uma solução para um problema aquela solução pode funcionar muito bem no início, mas a cultura, ela pode estar ali num lugar muito mais profundo dentro da organização que não é só aquela primeira solução que você trouxe que vai desconstruir a cultura que está em prática hoje. Então é muito comum esse cenário que a Sami falou, gente, da gente trazer uma solução, essa solução funcionar e performar muito bem no início, e com o tempo as pessoas se adaptam à cultura antiga para que elas consigam hackear a solução que está em prática. E as pessoas não fazem isso porque elas são malignas, né, porque elas têm intenções ruins. Não, elas fazem isso porque a cultura que está em prática é muito maior e mais forte do que aquela solução que você propôs.

E para desconstruir um aspecto cultural que a gente quer mudar, não vai ser uma solução isolada que vai resolver. Então é importante a gente estar preparado para entender quando a cultura se adapta e começa a levar a gente para o mesmo lugar de antes, ela vai engolindo ali a nossa solução e entender que movimentos a gente precisa fazer para então revigorar essa prática ou essa intenção que a gente tem de mudança. Tem um outro ponto que eu aprendi enquanto consultora e aqui, gente, dicas de pessoa que faz consultoria há muito tempo, eu tenho certeza que a Rafinha vai se identificar, que é às vezes você cria essas soluções e ela funciona muito bem para aquele cenário A, e aí você muda de emprego ou você muda de área dentro da empresa ou você muda de papel e aí você fala o seguinte, putz, eu já reconheci esse padrão antes, eu já criei uma solução que resolveu esse problema em outro lugar, eu vou também colocar essa solução aqui e aí não funciona.

Então, por favor, se por acaso vocês tentarem aplicar essas coisas que a gente está discutindo, essa forma da gente resolver esse problema aí, isso não ser resolvido da forma como a gente está falando aqui, isso não é só um problema seu, é porque existem várias outras cercas elétricas invisíveis, várias outras coisas que você não tem visibilidade que podem estar acontecendo naquele novo cenário e aí a gente vai ter às vezes a mesma solução, então aqui pensa só, a solução principal era a gente dar visibilidade das dependências, a gente fez isso criando a matriz de impacto e esforço, mas às vezes você vai precisar continuar dando visibilidade das dependências nessa outra empresa, nessa outra área, mas com outra ferramenta, então não se apeguem só às ferramentas que a gente está usando, se apeguem ao que a gente precisa resolver e aí criem suas próprias ferramentas, criem seus próprios comos e adaptem aquilo que vocês já vivenciaram em outros cenários para os cenários novos, entendeu?

Porque esse é um outro problema que a gente enxerga também no dia a dia, as pessoas querendo replicar soluções de forma igual em cenários que são desafiadores e complexos também, ou às vezes com informações que estão ocultas, que as pessoas não têm visibilidade. No final do dia, gente, o que é importante é tratar toda a solução como uma hipótese, mesmo que você já tenha feito essa solução dezenas de vezes em lugares diferentes, porque a gente vai fazer bom uso das boas práticas, daquilo que a gente entende que é tendência de mercado, que faz sentido, que já funcionou em outros lugares? Sim! Mas, dificilmente você vai encontrar um cenário onde você vai fazer ctrl -c, ctrl -v de uma solução. Ela sempre, em alguma medida, vai precisar ser adaptada porque a gente precisa respeitar o histórico, o legado, a cultura de cada organização e, mesmo que você tenha visto isso em 20 organizações diferentes, quando você chegar na 21ª, você vai precisar respeitar e entender o que levou aquela organização até aquele momento, quais são os fatores culturais em prática e como que você adapta.

Não é sobre ctrl -c, ctrl -v, é sobre pega a melhor prática, aplica, adapta ao contexto e sempre olha para o resultado. Chegamos onde a gente queria, resolvemos essa fatia do problema e, uma vez que a gente tem esse aprendizado com essa fatia, aí sim, a gente pode ir para a fatia seguinte.

Só lembre -se, recado é, as dependências, esse desenho todo no papel é maravilhoso, mas na prática a gente vai precisar se adaptar, enxergar sobre capacidade, enxergar sobre sobrecarga de sistema, sobrecarga de pessoas, o que a gente precisa mudar. Se você não enxergar, se você precisar se adaptar ao que acontecer no seu dia a dia, essas fatias não vão funcionar ou a forma de você enxergar esse problema não vai funcionar. Por favor, lembre -se isso, a gente precisa se adaptar o tempo todo à realidade do que está acontecendo no nosso dia a dia.