Ep. 223 - Redesenhando estruturas com unFIX: flexibilidade e agilidade corporativa

O Unfix é uma biblioteca de padrão. Ele tem diversos padrões, é um cardápio com diversas coisas que você pode usar, pensando em design organizacional, em estruturas organizacionais. Ele te dá muita clareza em onde mexer na estrutura. Se eu tivesse que resumir num tweet, é uma biblioteca de padrão com um cardápio de escolhas para você. O Unfix é como se fosse uma biblioteca de padrões, um Lego. Ele é bastante modular, então ele é uma ferramenta que permite a gente implementar pedacinhos para poder, de fato, solucionar problemas existentes na nossa organização. Ele é para fazer design organizacional de uma forma mais ampla, ágil e, de verdade, escalando equipes de uma forma ágil, que é a maior dificuldade das grandes organizações também. O que é legal é que, no próprio site do Unfix, eles sugerem que você use o Unfix adaptando a ferramenta. Então ele te dá liberdade, desde o início, de usar com flexibilidade, você construir o que você precisa e adaptar para a sua organização de acordo com as suas necessidades. Diferente dos outros métodos, frameworks que a gente vê aí pelo mercado, o próprio nome Unfix traz um pouco sobre por que eu preciso ser fixo. Por que a minha organização muda o tempo inteiro? Então, por que a minha organização, minha forma de estruturar a organização precisa ser fixa, já que eu estou mudando o tempo inteiro? Então ele propõe uma estrutura mais fluida, algo que a gente olha o valor de uma forma mais contínua. Então ele permite mais autonomia e mais flexibilidade. Já alguns frameworks que a gente vê aí no mercado, quando a gente está falando, por exemplo, de um Scrum, tem papéis mais definidos. A gente tem mais rigidez em certos papéis. A forma com que a gente faz é a mais prescrita, é um pouco mais prescritiva. Quando a gente fala de SAFe, então, nem se fala que ele é mais prescritivo, ele pressupõe uma série de papéis, de cadência, de governança. O Unfix não. Ele é mais light, digamos assim, e você consegue adaptar mais para o seu contexto. Então existem até alguns papéis que podem ser mais situacionais dentro do Unfix. Unfix também vem de dar flexibilidade. Fix de fixa. Então, se você quiser, você pode usar o Unfix, tirar talvez essa fixação que as pessoas têm de conexão entre uma hierarquia fixa e a estrutura dos times. Porque isso para o Unfix não vai acontecer. A estrutura dos times pode ser mais modular, ela pode ser mais flexível justamente por causa disso. O grande detalhe é tudo isso ou não. Se você quiser adaptar e ajustar, talvez você pegue do jeito que está. Você precisa usar sabendo o problema que você está querendo resolver na sua organização. E aí você ajusta a ferramenta. E aí só para dar uma noção de quantidade, são 32 padrões, 32 padrões hoje no cardápio que eles podem usar. 32 componentes que a gente pode usar. Isso aumentou recentemente. Não eram 32, eram menos. Isso vem aumentando. Isso mostra que o próprio Unfix está evoluindo. E ele é dividido em cinco grupamentos. Então, a gente tem que ter uma ideia de como a gente vai fazer isso: de time, de decisão, de definição de meta e padrão de processo e crescimento. E só para complementar também, acho que tem um ponto que é importante aqui, que ele é flexível no nível, que eu posso até utilizar de outros frameworks para poder complementar ele. Então, hoje minha empresa roda um SAFe e eu quero mudar a forma que eu estou fazendo e quero fazer de forma mais adaptativa. Consigo utilizar o Unfix e componentes do Unfix para rodar dentro da minha estrutura SAFe, que é uma estrutura prescritiva, e vai ser um SAFe bunch, mas é uma estrutura SAFe, para rodar junto com o Unfix. E por mais que ele seja adaptável, ele te dá algumas configurações viáveis, ele te sugere algumas configurações. Então, desde o nível de time, por exemplo, ele fala que o time deveria ter de 3 a 7 pessoas. Isso é viável? Faz parte do seu jogo? Faz parte do seu contexto? A gente pode sempre ir adaptando. Então, é uma sugestão. Não que isso funcione para todo mundo, mas são padrões de mercado que o Unfix traz. Que tipo de problema vocês já viram por aí? O que eu vejo, primeiro, um método. Eu tenho um método que eu posso usar. Então, por exemplo, um dos componentes é o Innovation Vortex. E esse componente, ele deixa claro o passo a passo da implementação. Então, pra mim, o Innovation Vortex é um componente base pra você usar qualquer outro, porque ele tem ali os seus, cada, o Innovation Vortex, ele tem como se fosse um catavento, e cada parte desse catavento traz um passo que você vai dar. O fato de eu conseguir trazer um método, um exemplo claro de passos a seguir, isso acalma um pouco o ânimo, porque design organizacional e mudança de estrutura sempre gera um pouco de receio, de medo, de aflição. Então, você com o método claro, isso ajuda. E a outra coisa que eu acho que ajuda, um problema que resolve de forma bem clara, é dar nome às caixas de tipo de time. Então, se eu tenho um time que tá focado em entregar valor, ele tem um nome. Se eu tenho um time que tá focado em fornecer serviços compartilhados, ele tem outro nome. Então, dá clareza pra coisas que não estão claras antes. Então, clareza, pra mim, é um problema que resolve, clareza na estrutura. E método pra estrutura avançar. Esses dois problemas, o Unfix resolve de forma bem direta. Adicionando ao que o Renan falou, acho que o Vortex, ele é muito importante, porque sempre que a gente vai falar de estrutura, a gente tem que fazer uma gestão de mudança. E aí, ele, acho que adicionar outras metodologias ou frameworks, ele vai ajudar nessa gestão da mudança. Então, a gente tem passos do que a gente precisa seguir, quem a gente precisa comunicar, o que a gente vai fazer pra fazer, de fato, acontecer essa mudança. Então, dar clareza pras pessoas em qualquer tipo de mudança é muito importante. Ainda mais numa mudança estrutural. E eu acho que, além dos componentes, eles guiarem pra dar nome às coisas, eles fazem com que a gente entenda o que é aquela coisa que a gente criou. Porque, às vezes, a gente criou um monstro, né? Então, putz, hoje faz sentido, não tá fazendo sentido, mas talvez a gente encontre em algum lugar que isso faça sentido ou que a gente tenha que adaptar. Então, muitos componentes, principalmente de times, que eles chamam de crews, né? Então, a gente tem que entender onde que a gente deveria colocar cada coisa e pra cada contexto, o que que a gente deveria construir da estrutura. Então, se eu entendi bem, existe uma organização que, por algum motivo, não tá funcionando da melhor maneira possível o relacionamento entre times ou entregas, enfim. E o Unfix, ele é uma alternativa pra que eu possa olhar pro que eu tenho e reorganizar essa organização, reorganizar esse ambiente, esse ecossistema com esses componentes e isso vai ter ali um, vai trazer uma clareza, como o Renan falou, vai conseguir ajudar na própria gestão da mudança, porque mudar as pessoas que estão envolvidas, é necessário que isso aconteça. No contexto que a gente usou o Unfix pra poder fazer esse design organizacional, primeiro, a gente faz o design organizacional por um propósito, a gente quer atingir alguma coisa, a gente quer atingir um objetivo e talvez hoje a gente esteja distante dele. Então, um dos desejos que a gente tinha ali no cliente era ter um patamar mais integrado, ágil e estratégico das ações que o time fazia, dos projetos que o time fazia, conectando com a estratégia da empresa, e utilizando metodologias mais modernas de trabalho. Então, eles tinham um descasamento na prática do que era feito ali na ponta e o que era definido na estratégia. Só por causa disso, a gente já identificou que existia uma série de problemas existentes também. Então, tinha muitas prioridades, tinha falta de conexão com o negócio, tinha baixa previsibilidade das entregas, uma baixa modernização, então tinha muita coisa legada, pouco microserviço, muita dependência de pessoas que eram expertise em determinado assunto pra poder fazer as coisas acontecerem. Então, os times, eles eram muito compartilhados, tinha muito compartilhamento de pessoas e no final era difícil entregar. Quando a gente olha pra um cenário desse, a gente até pode colocar uma governança mais ágil pra facilitar, o Unfix também fala disso, a gente tem reuniões ágeis, coordenações ágeis pra poder facilitar essas equipes se coordenarem, mas não resolve só. Então, a gente pensou, vamos estruturar os times, vamos reestruturar os times, pra de alguma forma eles terem um propósito mais unificado, olhando pra cadeia de valor ali, e aí sim a gente conseguir, de fato, definir, olha, esse vai olhar pra cadeia de valor, esse vai olhar pra plataforma, e esses aqui vão olhar pra serviços, que é a base ali do Unfix, então falando de value stream, então o pessoal que olhava para os produtos, depois tinha um time de plataforma, que servia esse pessoal dos produtos com microserviços, com componentes reutilizáveis, e a gente também tinha um time que olhava mais pra serviços ali de infraestrutura, que também provia funções, elementos pros outros times consumirem de uma forma mais estrutural. Então, no final, tudo isso que a gente fez foi pra tentar resolver estes problemas. E aí o Unfix veio como uma luva, porque como ele é muito flexível, e naquele contexto os times, eles tinham missões específicas, eram times de missões específicas, que também é um componente ali do Unfix, que são aqueles times que resolvem alguma coisa e depois é um próximo projeto, próximo projeto, meio que caiu como uma luva. Mas, dependendo da sua vertical de negócio, da sua unidade de negócio, você pode, por exemplo, encarar um time de RH como um time de plataforma, porque um time de RH está oferecendo serviços compartilhados pro resto das pessoas da empresa utilizarem. Então, dependendo da estrutura, se você pensar no time de plataforma como um time que oferece serviços compartilhados, pode ser um time de RH. Então, e esse componente, são os componentes das crews, então, crews, são um tipo de componente. E aí, pensando no passo a passo que a Fê trouxe, o passo a passo que ela seguiu, tá totalmente ligado com outro componente, que é o componente que a gente falou primeiro, há um tempo atrás, aqui, sobre o Innovation Vortex, que é justamente, eu encaro ele como um passo a passo de implementação do Unfix. Então, o primeiro passo, a primeira pétala do catavento é contextualizar. Então, qual é meu as-is? Qual é meu desenho atual? O que tá acontecendo hoje? Quais são as, como é que tá desenhada minha estrutura? Agora que eu desenhei minha estrutura atual, que eu sei onde é que eu estou, deixa eu empatizar, entender o que que tá acontecendo, onde é que estão as dores, quais são os problemas, o que precisa ser resolvido aqui nessa estrutura. Uma vez que eu fiz isso, eu vou pro terceiro passo, que é sintetizar. Então, dado tudo isso, dado todos esses problemas, qual é a melhor visão? Qual é o to-be desejado, qual é o desenho desejado pra toda essa estrutura? Agora que eu tenho esse desenho de longo prazo, eu vou criar uma hipótese. Qual é a parte dessa estrutura que eu vou trabalhar primeiro? E aí, no Innovation Vortex, ele chama de hypothesize, que é você criar uma hipótese, na prática. Aí você escolhe essa fatia, faz os trade-offs, os ganhos e os ônus e bônus de rodar essa fatia, e por fim você externaliza, que é um passo adiante no Innovation Vortex. E aí você roda, envolve as pessoas e roda. Então, você vai testar e vai sintetizar essa estrutura, você vai rodar ela. Uma vez que você rodou, o último passo é colher os aprendizados, você sistematizar. Então, aí você vai aprender com tudo que você fez, e aí você coleta feedback pra rodar a próxima estrutura. Mas aí você volta pro passo 1 do Innovation Vortex, que é, onde estamos hoje? Qual é o novo desenho? Ah, eu tenho uma parte da estrutura que tá funcionando assim e outra parte assada. E aí você vai fazendo isso num ciclo eterno de implementação até você finalizar ou chegar no máximo valor que você gostaria com aquela estrutura. Então, esse é um outro componente. O Innovation Vortex, ele te dá o guia pra isso. E como é que você vai usar esse Innovation Vortex? Como você achar melhor na sua empresa. Você pode pular passos, juntar passos, fica à vontade. E aí o Renan falando, me lembrou até algumas coisas que a gente, do trabalho que a gente fez em conjunto aqui na Livelo. Principalmente da primeira parte ali de desenhar o as-is, que foi exatamente onde a gente encontrou os principais problemas que a gente ia tacar. A gente sabia que existia um problema, só a gente não sabia exatamente o que que era e onde que a gente queria chegar com aquilo. Então, algumas pessoas traziam pra gente, putz, existe problema de estrutura, então a gente tem que fazer alguma coisa. E aí no as-is, quando a gente desenhou, o principal ponto que a gente tinha era a quantidade grande de dependências. Então, pro time fazer uma entrega, a gente tinha sete times envolvidos. Então, putz, é muita coisa e isso aumentava o que? O nosso lead time. A gente era menos eficiente do que deveria. E além disso, a gente identificou que os times, eles entregavam funcionalidade. Então, eles não estavam resolvendo um problema de fato de algum cliente no final. E isso estava sendo problemático porque os resultados não estavam vindo de fato como a gente queria e tudo que a gente tratava era um projeto dentro de um produto. Então, foi um primeiro passo bem importante que conecta com a primeira etapa ali do Vortex. E ali quando o Renan fala de validar as hipóteses, acho que esse foi um ponto super importante aqui, levando um pouco pra prática. Quando a gente leva isso pros executivos, eles falam, putz, vamos fazer tudo, vamos fazer um tombamento porque vai ser mais rápido. Mas o que a gente tem por trás disso? O que a gente vai causar se a gente fizer um tombamento? O meu sistema como um todo tá pronto? Vai funcionar? Porque se eu olhar na prática, toda mudança vai ter uma curva J. Então, se o meu resultado tá ruim, pode ser que ele piore. Se o meu resultado tá bom, ele vai piorar também, o pouco ou muito. E aí é difícil medir o quanto. Então, se a gente fatiar e olhar pras hipóteses e entender qual que é a parte viável pra gente fazer que a gente consiga testar e gerar um resultado a curto prazo, vai fazer com que a gente ganhe engajamento das pessoas, que a gente faça uma mudança controlada e com o menor impacto possível pra que depois a gente consiga expandir. Então, acho que seguir os passos, por mais que ele seja adaptativo ao seu contexto, alguns passos, eles são muito mais do que necessários pra que eu tenha algo no final que seja eficiente, que funcione e que seja sustentável ao longo do tempo. Posso dar duas dicas. Se você tem o desenho do as-is, todos os seus problemas, não sabe por onde começar, uma sugestão, comece pelo Governance Crew. Então, provavelmente o Governance Crew, que é um tipo de crew sugerida pelo Unfix, vai te dar uma visão do todo, aonde são os principais problemas pra serem resolvidos. Em muitos lugares, nem a coordenação, o nível de coordenação da liderança, a média gestão, nem eles se falam. Então, quem dirá os times? Quem dirá você mover e mexer times e mudar times? Então, a sugestão começa pelo Governance Crew. E a segunda sugestão que eu vou dar, a segunda dica, é sobre a criação das value streams. O Unfix, pelo menos eu não achei, se alguém sabe onde tem, me manda, por favor. Ele não sugere formas de você criar uma value stream do nada. Como é que você cria uma value stream? Qual o nome que você dá? Como é que você chama ela? Eu sei que é um fluxo de valor, de um produto, de uma jornada, de alguma coisa, ponta a ponta. Mas como é que eu crio ela? Então, eu tenho duas sugestões pra criar value streams. O nome delas, pra você entender qual é a value stream. A primeira é, talvez um formulário fit for purpose, você roda com seus clientes, entende quais são os propósitos deles e atrela o propósito ao fluxo de valor, à entrega. Então, essa value stream atende a esse propósito desse cliente. Essa é uma possibilidade. E a segunda possibilidade, que foi o que a gente usou, essa estava mais acionável pra gente, é você entender o funil de vendas, o funil da jornada do seu cliente, o funil dele dentro do seu produto. E pra cada parte do funil você entende o que o cliente quer ali e esse é o nome da sua value stream. Porque aí fica fácil de entender pra onde vai cada necessidade. Eu queria falar um pouquinho, a gente está falando muito sobre como é o funcionamento, mas eu confesso que pra mim não ficou claro quem então seriam as pessoas ou os times ou o responsável por poder, por fazer essa governança. Porque, obviamente, isso precisa existir, pelo menos na minha visão. A gente está falando uma mudança, quem que vai ali fazer a gestão dessa mudança de fato? A gente está falando de um time que vai trazer esses componentes? A gente está falando de uma autonomia, 100 de autonomia onde os próprios times vão entender o que funciona melhor? Eu queria saber na prática do que vocês viveram, como que aconteceu esse movimento, essa chegada do Unfix pra resolver problema? Aqui na Livelo a gente tinha dois fóruns. O primeiro deles a gente chama de átomo. Então é um grupo com as principais pessoas que podem gerir essa mudança. Então é um grupo multidisciplinar. Geralmente, aqui na Livelo a gente usou executivos, gerentes ou superintendentes, gerente executivo. Então são pessoas que elas têm influência pra fazer a mudança. Então elas conseguem navegar pela empresa, influenciar pra que isso aconteça e principalmente resolver problemas organizativos. Então, o que a gente discutia no átomo? A gente trazia coisas da transformação, que eram problemas que, de fato, a gente que estava no dia a dia, eu com uma agilidade, o Renan com a história, olhando como todo o negócio, agilidade, a gente não conseguia resolver, mas a gente sabia quem podia resolver. E essas pessoas estavam com a gente dentro do átomo, que era uma reunião semanal que a gente fazia com eles e discutia problemas. Então, colocar o bode na mesa, às vezes o problema é de tecnologia, o cara de tecnologia está lá na mesa pra poder discutir e está todo mundo desconfortável. Só que a gente tem que resolver o problema. Então, esse é um dos fóruns, esse é um fórum pensando mais numa mudança organizacional e dentro de cada vertical de negócio a gente tinha um outro fórum chamado NTC, que é o Núcleo de Transformação Corporativa. E aí ele funcionava muito parecido com o átomo, então eu tinha gerentes ali que eram líderes daquela vertical de negócio, então tinha tecnologia, produto, negócio, já tinha time de performance e agilidade aqui dentro da Livelo estava sempre envolvida, a gente inclusive que facilitava essas agendas e a intenção era a mesma. Quais são os problemas que estão acontecendo na gestão da mudança dentro dessa vertical? Que talvez a gente não consiga resolver no dia a dia, mas a gente precisa da ajuda dessas pessoas. Como está evoluindo a mudança? E se a gente está conseguindo alcançar o resultado que a gente precisa? E se a gente não está alcançando? Quais ações que a gente vai fazer em conjunto para poder evoluir e chegar onde precisa chegar? Então esses dois fóruns eram os fóruns principais e o segundo NTC, só para reforçar, a gente fazia por vertical. Então conforme a gente foi não tombando, mas fazendo as fatias de mudanças dentro de cada vertical, a gente foi abrindo esse fórum, puxando as pessoas, explicando para que funcionava, alinhando expectativa para elas e fazendo a roda girar e acontecer. Complementando aqui o que o Lucas trouxe, conectando com o Unfix, a gente tinha o átomo então sob um olhar global, e aí qual é a primeira vertical, segunda ou terceira, priorizando o maior impacto dentro da organização. Dentro do NTC, localmente, a gente começava a rodar, por exemplo, o Unfix ou um org ou um reorg, ou um ajuste, ou uma evolução na estrutura, dependia de cada um. E nessa evolução da estrutura, a gente fazia com o Unfix. A gente rodava o Innovation Vortex, entendia onde é que estava, via quais eram os tipos de crew que tinham, quais eram os tipos de fóruns, o tipo de quais são os ajustes que a gente precisava fazer, e aquela estrutura. Acabamos essa estrutura funcional, vamos para a próxima, que é priorizada pelo átomo. Então é assim que as coisas se encaixavam, se encaixam ainda. Acho que mais uma contribuição, no time ali que eu trabalhei, dentro do contexto que eu trabalhei, era uma empresa financeira ali, mas muito focada em tecnologia, então de fato foi dentro do setor de tecnologia que a gente usou esses elementos todos do Unfix. Eu sempre falo que as coisas a gente coloca como consultoria, a gente ajuda a trazer, mas as pessoas precisam ajudar a manter em pé. Então, nós como consultoria trouxemos um pouco desses elementos, ajudamos nesse design organizacional, mas não foi sozinho, também foi com a ajuda do C-Level, também foi com a ajuda ali da gerente, da coordenação e também dos agilistas organizacionais. Então, com certeza, como eles sabem o que está doendo dentro dos times, já tem muita coisa ali represada, quando chega a consultoria, a gente ajuda a alavancar essas agendas também. Então, esse foi o comitê que ajudou nesse processo de transformação, e uma vez saindo a consultoria, a gente ajudou a alavancar essas agendas também. Então, essa é a melhoria. Essas são as pessoas que vão ser responsáveis por dar continuidade, de manter esses fóruns acontecendo, olhando, vendo, fazendo alguma melhoria contínua, algum ajuste. Então, também fica ali, que nem o Lucas falou ali, C-Level, mas incluiria também os agilistas organizacionais, que eles também têm um papel ali de ajudar a dar continuidade. E o que que depois dessa transformação, dessa mudança, a forma como a liderança se comportava, na tomada de decisão, nessa dinâmica dessa liderança. Vocês perceberam que existiram mudanças? O que que aconteceu? O que que eu vi de mudança? Primeiro, as lideranças, elas se tornaram, elas se envolviam, passaram a se envolver muito mais com a resolução dos problemas, porque elas estavam dentro da governance crew, que a gente, em algum nível, tava chamando de NTC aqui, então elas sabiam dos problemas que estavam acontecendo, elas sabiam das métricas, sabiam dos números, sabiam de tudo que precisava pra tomar decisão pra resolver problema, e sabia do problema, já sem tempo pra perder. Semanalmente, ela tava vendo os problemas principais pra serem resolvidos, então ela estava envolvida e tomando decisão de forma mais tempestiva. Isso foi um ponto que eu percebi. Segundo ponto que percebi também, foi com a clareza do nome das value streams, não havia dúvida sobre pra onde direcionar a resolução de algum item ou de algum problema, essa value stream que resolve esse problema desse cliente, ela precisa melhorar, ela precisa trabalhar, esse problema é dela, então ficou mais claro essa tomada de decisão, foram esses dois pontos, os principais que eu peguei. E você falou uma coisa muito interessante sobre os números, o que vocês puderam perceber de mudança no que vocês estavam medindo, né? O que que teve de resultado, a gente tá falando de, ou o que tem de resultado normalmente, não só especificamente nesse caso, mas a gente tá falando de eficiência, o próprio Scarpato, ele trouxe uma questão ali de lead time antes como uma dor, né? O que que vocês puderam perceber em cada um no seu caso, que teve de resultado, que era tangível assim? Aqui na Livelo, principalmente pensando em eficiência e em eficácia, e começando com eficácia, a gente teve várias evoluções, principalmente porque a gente tava pensando em problemas de fato dos clientes. Então, um exemplo, a gente tinha um tempo de processamento, de um dos nossos serviços, de 30 minutos. E esse, a gente conseguiu diminuir pra 2 minutos. E aí, putz, por que que a gente não resolveu isso antes? Porque a gente tava focado em qual feature a gente ia entregar, o que que a nossa diretoria gostaria, e claro que tem super pontos importantes, mas o que de fato realmente vai trazer o resultado que a gente precisa. Então a gente começou a focar nisso. Quando a gente pensa em eficiência, aí os números acabam sendo talvez até um pouco assustadores, né? Porque se a gente olhar pra frente, a gente tem que pensar em um ponto de vista, né? Então, pra lead time, a gente contabiliza aqui 85 de percentil, né? A gente, em um dos casos, a gente saiu de 133 dias pra 37 dias, que é uma redução de 72%. Acho que são vários componentes, né? Então, a formação dos times, ela conta muito pra redução do lead time, a gente removeu muito a dependência. Então a gente saiu de um cenário que a gente, pra entregar uma coisa, a gente tinha que envolver 7 times. Pra envolver no máximo 2 times. A gente começou a pensar qual que é o tipo de entrega que a gente precisa fazer de fato pro cliente. Então, sair de feature, olhar pra problema, o que que eu preciso entregar de fato que vai resolver um problema de fato do meu cliente e que vai gerar um resultado pra companhia, porque eu tenho que sempre estar no meio do caminho, né? Nem sempre 100 só pro cliente, mas eu também tenho que trazer resultado porque as empresas não são ONGs. Então eu tenho que ter resultado dentro da minha companhia. E qual que é a fatia que eu tenho que trabalhar pra poder entregar rápido, ou seja, de forma eficiente, mas com eficácia também, pra gerar um resultado pra companhia. Então, às vezes, a fatia que a gente trabalhava, ela era muito grande. Por isso que eu demorava muito tempo pra fazer uma entrega. E aí a gente começou a trazer técnicas pra poder ajudar as pessoas a fatiarem de uma forma melhor e reduzir. Então são vários fatores, com a ajuda do Unfix e de outras práticas, que a gente conseguiu gerar números super positivos pra organização, pros times e pras pessoas também. Só o fato de você já limitar e separar, né? É, o problema de ponta a ponta entre cada value stream, elas naturalmente elas vão mais rápido, né? E aí quando você tem um time de plataforma, por exemplo, oferecendo serviços compartilhados para os times de value stream, qual é a priorização desse time de plataforma? A própria governance crew direciona. Então a gente começa pelo que entrega mais valor com menor esforço. E aí tudo começa a se encaixar de forma mais natural. A gente reduz o número de handover. E aí conectado com isso, tem um componente que eu acho que faz muito sentido utilizar, um componente mais estratégico, que ajudou a dar essa visibilidade do que é mais importante, do que não é, do que tem que focar, do que não tem, que é o business lifecycle. Eu acho fortemente que eu utilizei de um jeito diferente do que tá proposto no Unfix. Por quê? Qual é a proposta do business lifecycle? São 10 níveis de um negócio. Que um negócio passa, um startup passa, desde o momento da iniciação, passando pelo market fit, níveis de maturidade. E aí vai evoluindo o ciclo de vida até ele morrer. Como eu usei? Eu usei sob o aspecto de produto. Então, lá no trabalho junto com o Lucas, a gente criou como se fosse uma prancheta estratégica dos produtos da Vertical. Eu tenho diversos produtos. E aí junto com o PM da área, a gente entendeu, o Product Manager da área, a gente entendeu que produto tá em que estágio de maturidade. Pra eu entender que tipo de ação eu preciso fazer nesse produto, pra ele evoluir pro próximo estágio de maturidade. E junto com isso, a gente entendeu quais são as métricas relevantes pra cada estágio de maturidade. Então, por exemplo, se eu tenho um produto que tá na fase de validação, que segundo o business lifecycle é o nível 4, talvez faça sentido eu entender se eu tô tendo qual é o meu custo de aquisição de clientes, pra eu saber se tá valendo a pena continuar com esse produto ou não. Se eu tô validando ou não. Se eu tenho a minha base de clientes tá aumentando. Porque se eu tô validando, eu quero ter mais clientes. Então, pra cada estágio de produto, eu tenho um tipo de métrica diferente. E aí eu passo a cobrar aquele time que tá trabalhando com aquele produto, a métrica ideal pra ele evoluir pro próximo estágio. E por fim, eu tenho uma visão de que time tá cuidando de que produto. E aí eu vejo se o meu produto mais estratégico tá bem atendido. Ou eu deveria fazer algum tipo de mobilização, trazer um time pra lá, um time pra cá. Então eu consigo ter uma visão ampla sobre o aspecto do ciclo de vida do meu produto, em um lugar só, numa prancheta estratégica. E a gente usou isso bastante lá, foi bem legal. E deu bastante direcionamento sobre esse time deveria focar em processo, esse time deveria focar no negócio, esse time deveria focar em jornada do cliente. Tudo em uma única visão. E aí, te complementando. E a gente tá até expandindo essa prática aqui pra aliviar outros produtos que a gente ainda não tinha alcançado. E além de ajudar ali dentro do nível operacional e tático a conectar a estratégia do produto, a gente também consegue conectar com a estratégia organizacional. Então pode ser que em alguns momentos aquele produto talvez esteja indo pro caminho errado. É pra aquele lugar que eu quero ir? Eu preciso ir pra lá com aquele produto? Talvez não. E eu acho que esse trabalho, ele ajuda bastante a gente a entender no médio e longo prazo, como a gente se conecta com a estratégia organizacional da companhia, que geralmente dura mais de um ano a longo prazo. Então como que a gente colabora com isso. E como que a gente faz com que os times, eles estejam no formato certo que é o que o Renan faz. Como o Renan comentou. Então pra estratégia organizacional, como que eu conecto com a minha estratégia de produto de médio e longo prazo pra estratégia do produto. E como os times se conectam com essa estratégia. Porque existe muito no mercado o seguinte dilema, né? Puts, o meu time não tá conectado com a estratégia. Eu tô me sentindo fora da estratégia. Então como que eu faço isso? O Business Lifecycle, ele ajudou muito aqui na Livelo a gente fazer esse tipo de conexão. Tem um último componente aqui pra trazer pra vocês. A gente falou bastante sobre resultados, né? Que resultados que o Unfix ajuda a trazer. Aí eu me lembrei muito também sobre eficiência. E com certeza a redução do lead time, justamente por conta de redução das dependências, né? A gente cria times mais autônomos, que dependem menos. Times que servem outros times. Então isso ajuda muito. De fato, vai reduzir lead time. Eu também tive essa mesma experiência. Só que eu usei um componente muito interessante do Unfix pra elucidar pras pessoas, pra trazer mais clareza sobre os tipos de dependência. Porque às vezes não é muito claro pra todo mundo que dependências são diferentes entre si. Então eu posso ter uma dependência que ela é de autorização. Eu não tenho autorização pra mexer em alguma coisa. Eu posso ter uma dependência que ela é de expertise. Eu não tenho um profissional que saiba mexer nisso porque falta aquele conhecimento. Enfim, eu posso ter diversos tipos de dependência. E o Unfix tem uns cardzinhos bem legais, bem coloridos assim, que ele traz pra gente pra elucidar todos os tipos de dependência que a gente poderia ter, né? Então trazer isso pras pessoas e principalmente ali pra aquela governance crew, que é o pessoal que ajudava a tirar impedimentos e tal ali durante algumas reuniões de coordenação. Facilitou pra eles entenderem que nem toda dependência eu trato da mesma forma. Dependendo do tipo de dependência eu tenho uma forma pra endereçar. Porque elas são diferentes. Então isso elucidou. A gente tem às vezes a propensão de dar a mesma solução. De ficar sempre esperando ou achar que é a mesma forma de resolver, né? E não é. Então eu achei bem legal esses cards do Unfix pra trazer. E eu super sugiro assim numa reunião de coordenação. Onde a gente fala de retirar impedimentos. Elucidar e mostrar pra galera. Ajuda a ter uma visão do que você pode usar. Qual é a parte boa? Que o negócio tá funcionando. Que tipo de desafios que vocês enfrentaram nessa jornada de trazer esse tipo de mudança, né? A gente tá falando aqui do Unfix, mas a mudança como um todo. Onde que vocês esbarraram aí nesses processos? Eu tenho pontos aqui. E não vou falar só de Livelo. Vou falar sobre uma seguradora azul também. Que eu trouxe um exemplo de que eu vivi lá. Primeiro, focar em pouco componente. Tem muito componente. Se você ficar parando, lendo tudo, você vai querer usar tudo e isso não vai sair do lugar. Entenda qual é o seu problema. Entenda o que você quer fazer. E selecione poucos componentes. Porque eu fiquei horas, desafio. Nossa, componente legal. Vou usar, vou usar, vou usar. E você se perde. Foi desafiar. Primeiro desafio. Segundo desafio. Ambientes altamente complexos. Talvez valha a pena você abrir mão de fazer o as-is. Então, em alguns momentos, é tão complexo desenhar o as-is, que você só desenha o to-be e vai puxando. Pensando em Innovation Vortex, pula o contextualizer, que é o primeiro passo, e só desenha o to-be. O que você gostaria? E aí você vai puxando e vai descobrindo, cada fio que você puxar, qual é o nível da meada que você vai ter que resolver. E aí você vai investir, vai gastar. Nem investir. Você vai gastar muito tempo tentando desenhar o as-is. Não vai dar. É onde fica o negócio super complexo. Então, preste atenção se você vai desenhar o as-is, se ele é um ambiente altamente complexo. Eu tive, eu bati muito cabeça até o momento que eu falei, desiste. Vamos pro to-be. E o último, o Unfix, ele não deixa claro, ele não trata processo. Ele trata estrutura. E as pessoas envolvidas, frequentemente, confundem o que é um processo. O que é processo e o que é estrutura. Então, a gente pegando, tentando entender na parte do Innovation Vortex, empatizar com as pessoas, entender quais são as dores estruturais delas, vinha muito, por exemplo, G-Mood. Ah, o G-Mood é ruim. Mas o G-Mood é um processo. Eu não pretendo resolver isso com o Unfix. O Unfix resolve estrutura. Pode ser que a estrutura resolva o processo, mas não é necessariamente uma coisa vinculada a outra. Então, é desafiador explicar pras pessoas a diferença de processos. Estrutura no dia a dia não tá embutido isso. Então, quando alguém traz. Falta prioridade e foco. Ok, eu posso ter uma estrutura pra isso. Só problema estrutural. Às vezes eu consigo resolver. Papéis e responsabilidades não estão claros. Talvez a estrutura resolva isso. Agora, G-Mood ou qualquer outro tipo de processo de subida ou coisas assim, eu preciso deixar claro. Isso é processo, não vou tratar. Isso é estrutura, eu vou tratar. Esses são os três desafios pra mim que mais me apertaram o calo em todas as implementações. Eu vou colocar dois pontos aqui em complemento ao do Renan. O primeiro, ter bem claro o que você vai querer resolver com o Unfix. E aí, eu tenho, eu concordo 100 com o que o Renan colocou e esse é um ponto adicional também de, ou a gente tá resolvendo a coisa certa, a gente tá indo pro caminho certo ou a gente tá querendo implementar algo porque é inovação, é inovador, que é legal e o mercado tá usando. Acho que tem que ter um propósito claro por trás e o porquê que a gente tá fazendo aquilo. Justamente porque o segundo ponto é, toda mudança, ela tem que tá muito clara, principalmente pros stakeholders. Por quê? A gente tem que ter promotor pra fazer mudança. Claro que a gente sempre vai ter alguns detratores, mas se a gente não tiver promotor, ou a mudança ela acontece e não se sustenta ou vai dar tudo errado e vai ser uma dor de cabeça gigantesca. Então, acho que a mensagem aqui é venda bem o que você quer implementar, desde que faça sentido e que tenha um propósito grande por trás que vai resolver problemas e gerar resultado. Senão vai ser bem difícil fazer uma comunicação, por mais que você tenha milhares de metodologias de gestão de mudança, não vai dar certo. Super concordo com o Renan do ponto de mudanças organizacionais não resolvem todos os problemas. Acho que isso a gente enfrenta com certeza, então o Unfix não vai resolver todos os seus problemas, né? Ele vai resolver alguns. Então, esse foi o desafio que eu encontrei. Como lidar com as expectativas das pessoas pra resolver determinados problemas ou processos que não era essa solução que iria resolver. Então, por isso que a gente usa diversas outras ferramentas, certo? Então, até o Lucas estava conversando, vamos fatiar, vamos fazer isso, vamos fazer aquilo. A gente pega um cinto de ferramentas pra ajudar pra poder resolver o restante. Então, assim, acho que esse foi o primeiro desafio, entender que não vai resolver tudo. E um segundo desafio bem específico ali daquele contexto, pros times de plataforma. Times de plataforma, eles vão servir outros times, né? Então, ali naquela minha, aquela experiência, eles não estavam acostumados a fazer isso. E eles já tinham um backlog remanescente, né? Quando a gente montou aquele time. Então primeiro a gente tinha que limpar aqueles bugs, aquele backlog, aquilo que estava de certa forma poluindo, pra depois eles começarem a de fato trabalhar no propósito pelo qual eles foram definidos ali, né? Pelo qual eles iam existir. Então, tinha que fazer um pouco de serviço de casa, primeiro, pra depois a gente de fato começar a rodar. E aí, isso gera uma série de expectativas também nas pessoas. Então, acho que gerenciar isso, falar gente, calma, vamos lá, confia, é o processo. Vamos lá, lutamos juntos. É também algo que a gente tem que tomar cuidado aí quando a gente tá fazendo mudanças, né? Pra que as pessoas entendam. No fim, a parte mais importante é fazer com que esse time entenda o propósito pelo qual ele tá lá. Então, entendendo isso, entendendo o propósito pelo que ele existe, concordando com isso, né? Vai fazer acontecer. Acho que, esse foi um desafio que eu tive de gerenciar as expectativas ali pra esse time de plataforma. No final das contas, é saibam por que vocês estão fazendo o que vocês estão fazendo. Não façam por fazer, porque muito provavelmente não há santo que vá fazer milagre de resolver quando a gente não tem clareza do nosso propósito, da nossa dor e do problema que a gente tá tentando resolver. E, gente, eu agradeço muito a participação de vocês. Infelizmente, chegou, eu acho que merece parte dois, porque eu sinto que eu, pelo menos, vou ter que continuar estudando e lendo, e queria ouvir mais. Mas eu agradeço a participação de todos vocês, e esse é o momento em que a gente deixa aberto pra vocês deixarem um recadinho do coração pra quem tá ouvindo a gente. Então, a mensagem final aqui, o Flor, pelo meu lado, é foque no que realmente vai resolver seus problemas, que é só reforçando o que a gente já falou. Nenhuma ferramenta, eu acho que ela resolve tudo do início ao fim, então utilize aí seu cinturão, ou seja, do Batman ou de qualquer outro personagem pra fazer acontecer de fato as mudanças organizacionais. Elas são complexas, elas são difíceis, podem dar medo, mas a gente tem que conquistar o caminho pra fazer acontecer de uma forma diferente, que gere resultado e que a gente saia do outro lado sem pessoas pelo caminho. Meu recadinho do coração é você não está certo sempre, então adapte-se. No seu dia a dia, você vai errar. Suas convicções nem sempre estarão certas, então ouça o seu par que está trabalhando com você e se adapte. Seja como água, como diria o famoso Bruce Lee. Muito bem, muito obrigada, Fê. Essa foi maravilhosa. É, né? O que vem depois, né? É, então. Acho que da mesma maneira que o Unfix veio de eu vou, Unfix, o Spotify Model, né? Que não existe um modelo único. A galera estava usando o Spotify Model pra tudo, né? Como referência. Também não existe o Unfix pra tudo, então use os componentes que façam sentido, entenda o que faz sentido pro seu negócio, ali pro seu contexto, e busque mais referências, né? Às vezes o seu contexto vai permitir com que você use mais coisas, menos coisas, enfim. Tem uma ampla variedade aí de possibilidades. Não existe um único modelo pra tudo.