O Projeto Fênix, de Gene Kim, Kevin Behr e George Spafford, é um romance corporativo sobre um executivo de TI que assume uma área completamente desorganizada, marcada por urgências constantes, pressão do negócio e expectativas irreais. A história acompanha a tentativa de colocar ordem em um ambiente onde tudo é prioridade e nada flui, usando uma narrativa para traduzir conceitos de DevOps, gestão de fluxo e Teoria das Restrições.
Comecei a leitura sem qualquer contexto sobre a proposta da obra, apenas por indicação de um colega de trabalho. Mergulhei na narrativa sem expectativa e o estranhamento veio rápido. Os diálogos soam artificiais, os cenários são levados ao limite e os números parecem inflados de propósito. 200 pessoas em TI. 600 mudanças em uma única semana.
O protagonista também causa desconforto. Bill é correto demais para um ambiente em colapso. Uma família de comercial de margarina, antagonistas caricatos, arcos de redenção que parecem saídos de roteiro de cinema.
Mas com o avanço da leitura, ficou claro que essa escolha não é descuido narrativo. A proposta do autor não é ser o próximo New York Times Best Seller, mas usar situações extremas e personagens simbólicos como ferramentas para ensinar conceitos de gestão.
E, gostando ou não desse formato, ele cumpre o papel. Em vez de decorar conceitos, acompanhamos situações, decisões e consequências, nos identificando com os cenários descritos e gravando os aprendizados com mais facilidade.
A partir do momento em que entendi essa proposta, a leitura fluiu muito melhor. Passei a olhar além da teatralidade e as situações narradas começaram a revelar padrões familiares.
Quando o problema é sistêmico, esforços pontuais só redistribuem o caos
Bill assume TI em um cenário completamente colapsado. Tudo é urgente. Tudo depende de TI. Ninguém confia em TI. A empresa vive em modo crise.
O projeto Fênix é anunciado como prioridade máxima, mesmo sem clareza de escopo, dependências ou impacto no resto do sistema.
Diante desse cenário, Bill reage do jeito mais comum possível. Tenta organizar reuniões, faz priorizações manuais e busca algum tipo de controle sobre mudanças. Mas os problemas continuam surgindo, sempre em modo urgência. A sensação é de estar trocando a roda do carro com o carro em movimento.
A história começa a ganhar forma quando Bill conhece Erik, que atua como um mentor. Erik observa o sistema como um todo e provoca Bill a mudar a forma de enxergar o problema. É ele quem apresenta a Teoria das Restrições: todo sistema tem um gargalo. Um ponto específico que limita o fluxo de todo o resto.
Gargalos não são teóricos: eles têm nome, rosto e agenda cheia
No livro, esse gargalo é Brent, um dos desenvolvedores. Tudo passa por ele. Decisões técnicas, correções, emergências, validações. O time inteiro depende da capacidade de uma única pessoa.
Infelizmente, essa parte não é exagero literário, mas uma realidade comum em diversas empresas. O processo inteiro trava porque uma pessoa (ou setor) específica é o ponto de passagem obrigatório.
A pessoa vive apagando incêndios, nunca tem tempo para documentar, ensinar ou estruturar. Quanto mais resolve, mais dependente o sistema se torna dessa pessoa. O problema não está na intenção dela, mas no desenho do sistema que prioriza ações imediatas em vez de prevenção.
Quando essa pessoa precisa tirar férias, sofre um compreensível burnout ou pede demissão, o impacto não é individual. O sistema inteiro sente.
Empresas costumam valorizar quem resolve rápido e salva o dia. Já o trabalho menos visível, como documentar, estruturar fluxo ou melhorar processos, vira algo sempre adiável, quando não descartável.
O resultado aparece na forma de dívida técnica, retrabalho constante e desgaste emocional. Times cansados, produtos instáveis e lideranças frustradas.
O efeito colateral não aparece só quando o herói sai de cena. Em sistemas com pouca documentação e processos opacos, o simples fato de conhecer a empresa funciona como um mecanismo de sobrevivência. Não é uma escolha do funcionário, é o sistema que cria essa dependência. Pessoas acabam permanecendo em cargos, e muitas vezes até sendo promovidas, muito mais pelo acúmulo de contexto do que por performance ou habilidade de liderança.
Isso dificulta substituições, enfraquece o onboarding e bloqueia a evolução do time.
Sistemas ruins limitam pessoas boas
Uma das reflexões mais importantes do livro é como sistemas mal desenhados fazem profissionais competentes performarem abaixo do potencial. Pessoas excelentes parecem medianas quando estão presas em organizações que não avançam. A motivação some. O trabalho vira sobrevivência.
Sempre surge alguém tentando fomentar a mudança. Mas mudança estrutural não se sustenta no esforço individual. Precisa de grupo, alinhamento entre áreas e liderança disposta a mexer no sistema, não apenas cobrar resultado. Não é falta de talento. É falta de sistema.
Uma andorinha só não faz verão
Quando Patty tenta implementar um CAB cheio de etapas, aprovações e rituais bem desenhados no papel, o operacional não acompanha, e pontua que abrir um pedido de mudança leva mais tempo do que executar a própria mudança. O processo existe, mas não serve a quem precisa dele.
Bill escuta essa dor, envolve aqueles que são responsáveis ou impactados por esse processo, e ajusta o modelo de acordo com as necessidades e realidade de todos. Liderar, nesses momentos, é reconhecer quem tenta despertar a mudança, apoiar quem se engaja e trabalhar ativamente para trazer quem resiste.
A virada acontece quando a liderança se aproxima do operacional, escuta a dor real de quem executa o trabalho, transforma dor operacional em decisão estrutural e cria uma cultura de processo, documentação e gestão que coloca pessoas no centro. Porque, no fim, são elas que fazem o sistema funcionar.
As Três Maneiras entram em cena
É a partir desse ponto que as Três Maneiras deixam de ser conceito e começam a aparecer como prática. Não como um framework apresentado em slides, mas como resposta direta à dor.
O foco passa a ser fluxo: menos trabalho em progresso, menos multitarefa e mais clareza sobre o que realmente está andando. O trabalho precisa fluir da esquerda para a direita, sem ficar preso em filas invisíveis.
O feedback se torna constante: problemas deixam de ser descobertos só em produção. Áreas passam a conversar mais cedo, com mais frequência. As surpresas diminuem porque os sinais aparecem antes.
O erro muda de papel: deixa de ser um evento traumático e passa a alimentar aprendizado contínuo. O processo entra em revisão constante, e a conversa começa a sair da culpa para o entendimento do sistema.
Sem heróis e vilões isolados
Operações, Tecnologia e Segurança começam, ainda que com atrito, a dividir o mesmo espaço de decisão. A liderança, em vez de apenas cobrar prazos e entregas, passa a atuar no desenho do sistema.
Com fluxo mais previsível, menos retrabalho e menos urgência artificial, o projeto Fênix deixa de ser o epicentro do caos. Ele não se torna perfeito e vira um case idealizado, mas passa a ser gerenciável. Essa transformação mostra que sistemas saudáveis dependem de escolhas conscientes de liderança, estrutura bem desenhada, e times capazes de aprender juntos.
A maior contribuição da narrativa é mostrar que performance real não depende de heroísmo individual, mas de sistemas que não precisam de heróis para funcionar.
