Introdução

Eu li O Projeto Fênix (The Phoenix Project) de Gene Kim, Kevin Behr e George Spafford esperando um livro sobre DevOps. O que encontrei foi um espelho. Um espelho desconfortável, daqueles que mostram as coisas que você prefere não ver — não porque não sabe que existem, mas porque já desistiu de tentar mudar.

O livro conta a história de Bill Palmer, um gerente de TI que herda um projeto caótico, uma empresa à beira do colapso tecnológico e uma equipe que apaga incêndios o dia inteiro sem nunca resolver as causas. A ficção é tão precisa que parece reportagem. E pra mim, que trabalho como arquiteto de software há anos, a leitura foi menos ficção e mais documentário — porque eu vivo variações dessa história toda semana.

Não vou fazer resenha. Existem centenas. O que vou fazer aqui é contar por que esse livro me acertou, onde me identifiquei, e o que ele expõe sobre um problema que poucos querem admitir: a maioria das organizações de TI não está preparada para fazer software direito — e o profissional que tenta fazer certo muitas vezes é tratado como o problema, não como a solução.

Se você é desenvolvedor, arquiteto, tech lead ou qualquer profissional que já sentiu a frustração de querer aplicar boas práticas em um ambiente que nem sabe o que é CI/CD, esse texto é pra você.

O cenário que o livro descreve — e que eu reconheço

A TI como departamento de suporte glorificado

No livro, a TI da Parts Unlimited não é vista como parte estratégica do negócio. É o departamento que “faz os computadores funcionarem”. Os projetos são empurrados sem planejamento, as prioridades mudam toda semana, e ninguém entende — ou se importa — com o impacto das decisões técnicas no resultado final.

Isso não é ficção. É o padrão em uma quantidade absurda de empresas.

Já perdi a conta de quantas vezes participei de reuniões onde decisões arquiteturais críticas foram tomadas por pessoas que não entendem a diferença entre um deploy manual e uma pipeline automatizada. Onde a resposta para “precisamos de CI/CD” é “mas o que é isso?” — não de um estagiário, mas de gestores com anos de casa.

O livro captura essa dinâmica com uma precisão que dói: a TI não é ignorada por malícia, mas por desconhecimento sistêmico. As pessoas no topo simplesmente não sabem o que não sabem. E quem sabe — quem está nas trincheiras escrevendo código, mantendo sistemas, acordando de madrugada por causa de incidentes — não tem voz suficiente para mudar o rumo.

Brent — o herói involuntário que trava tudo (e eu sei porque sou ele)

Um dos personagens mais reveladores do livro é Brent, o engenheiro brilhante que é gargalo de tudo. Todo projeto depende dele. Toda escalação crítica vai parar na mesa dele. Ele é indispensável — e exatamente por isso, ele é o maior risco da organização.

Eu não “me identifiquei” com o Brent. Eu sou o Brent. Com uma diferença crucial: eu tenho plena consciência disso.

Sei que sou gargalo. Sei que quando tudo passa por mim, a organização está frágil. Sei que se eu sair de férias, projetos param. Sei que isso não é sinal de competência — é sinal de falha organizacional. O livro me deu o nome para algo que eu já sentia: eu não deveria ser insubstituível, e o fato de ser é um problema que não depende de mim resolver sozinho.

⚠️ Atenção: Se na sua empresa existe um “Brent” — alguém sem o qual nada funciona — vocês não têm um herói. Vocês têm um single point of failure com crachá. E provavelmente esse profissional já sabe disso. A pergunta é: a gerência sabe?

A diferença entre o Brent do livro e eu é que o Brent do livro não questiona a situação — ele apenas executa, absorve, resolve. Eu questiono. Eu levanto a mão e digo: “precisamos de mais pessoas com senioridade técnica”. E é aí que a coisa trava.

Porque o desafio real não é técnico. O desafio é convencer a gerência de que senioridade técnica tem o mesmo valor que senioridade de negócio. Que a empresa precisa de mais profissionais que entendam arquitetura, que saibam configurar uma pipeline, que consigam tomar decisões técnicas com autonomia — e não apenas de pessoas que entendem o processo de negócio mas não sabem a diferença entre um deploy e um commit.

O livro mostra que a solução de Bill Palmer para o problema do Brent é protegê-lo, documentar o conhecimento dele e distribuir para o time. Concordo. Mas o livro assume algo que na minha realidade não existe: que há um time com capacidade técnica suficiente para absorver esse conhecimento.

Quando o time inteiro opera em um nível onde CI/CD é um conceito desconhecido, distribuir conhecimento não basta. Antes disso, a organização precisa investir em contratar e reter profissionais com profundidade técnica real. Não mais generalistas que “se viram”. Profissionais que entendam por que as coisas são feitas de determinada forma — não apenas como.

💡 Dica: Se você é um Brent consciente, documente tudo que faz — não por altruísmo, mas por estratégia. Documentação transforma conhecimento tácito em evidência concreta de que a organização depende de uma única pessoa. Quando a gerência perguntar “por que precisamos contratar mais gente sênior?”, a resposta está na quantidade de documentos que têm o seu nome como único autor.

Onde eu me identifico — e onde dói

O arquiteto que quer fazer certo em um ambiente que não quer mudar

Esse é o ponto mais pessoal deste texto, e vou ser direto.

Eu sou o tipo de profissional que se importa com qualidade. Não por perfeccionismo estéril — mas porque já vi o custo de fazer errado. Já vi deploys manuais quebrarem produção. Já vi código sem testes causar incidentes que duraram horas. Já vi decisões arquiteturais ruins gerarem débito técnico que levou anos para ser pago.

Quando eu proponho CI/CD, testes automatizados, code review, infraestrutura como código, observabilidade, não é porque gosto de complicar. É porque já vivi as consequências de não ter isso. E o livro captura exatamente essa frustração: o profissional que enxerga o problema, propõe a solução, e ouve como resposta “não temos tempo pra isso” — enquanto o tempo é consumido inteiro apagando os incêndios que a falta dessas práticas causou.

E aqui está a ironia que o livro não explora mas que eu vivo: ser o Brent e ser o arquiteto ao mesmo tempo. Eu sou o gargalo técnico que resolve tudo — e ao mesmo tempo sou o profissional que sabe que essa situação é insustentável e tenta mudar. Mas para mudar, preciso que a gerência entenda algo que parece óbvio mas não é: a organização precisa valorizar e investir em senioridade técnica, não apenas em senioridade de negócio.

Na maioria das empresas que conheci, o caminho de carreira valoriza quem entende de processos, de gestão, de stakeholders. E isso é importante. Mas quando a liderança inteira é composta por pessoas que não distinguem um monolito de um microsserviço, as decisões técnicas ficam nas mãos de quem não tem contexto para tomá-las — ou ficam nas mãos de um único Brent que acumula tudo.

ℹ️ Informação: O conceito de “Os Três Caminhos” apresentado no livro — Flow, Feedback e Aprendizado Contínuo — é o framework que fundamenta toda a cultura DevOps. Flow é sobre otimizar o fluxo de trabalho da esquerda para a direita (dev → ops → produção). Feedback é sobre criar ciclos rápidos de retorno (monitoramento, alertas, testes). Aprendizado Contínuo é sobre experimentar, falhar de forma controlada e melhorar o sistema como um todo.

Na minha realidade, o que vejo é o oposto dos Três Caminhos:

  • Flow inexistente: deploys manuais, sem pipeline, sem padronização. Cada desenvolvedor faz do seu jeito. Não existe um caminho definido do código até produção — existe uma colcha de retalhos de scripts, acessos manuais e “o fulano sabe como faz”.
  • Feedback zero: sem monitoramento real, sem métricas de deploy, sem alertas inteligentes. Quando algo quebra, a equipe descobre porque o usuário reclamou.
  • Aprendizado inexistente: post-mortems não acontecem. Os mesmos erros se repetem. Ninguém documenta. Ninguém questiona o processo — porque não existe processo.

Quando nem o básico existe

O que o livro chama de “trabalho não planejado” — aquele fluxo constante de interrupções, urgências e correções que consome 100% da capacidade do time — eu chamo de segunda-feira.

Na Parts Unlimited do livro, o trabalho não planejado domina porque não existem controles. Não existe visibilidade do que está em andamento. Não existe priorização baseada em impacto. Tudo é urgente, logo nada é urgente.

No meu contexto, já vi equipes inteiras que:

  • Não sabem o que é uma pipeline de CI/CD — literalmente nunca ouviram o termo
  • Fazem deploy copiando arquivos via FTP ou RDP
  • Não têm um único teste automatizado em projetos com anos de vida
  • Não usam branches — todo mundo commita na main
  • Não fazem code review — “confia que funciona”

E quando você propõe mudar isso, a resposta mais comum não é resistência ativa. É algo pior: indiferença. “Sempre funcionou assim.” “Não temos budget.” “O time não está pronto.” “Depois a gente vê isso.”

O livro nomeia esse padrão. E nomeá-lo é o primeiro passo para combatê-lo.

O que o livro ensina — para quem quer ouvir

Os Três Caminhos na prática

Gene Kim não inventou DevOps. Mas ele sintetizou os princípios de uma forma que qualquer pessoa de TI pode entender — inclusive as que nunca leram um livro técnico:

Diagrama dos Três Caminhos do DevOps: Flow com pipeline CI/CD, Feedback com ciclo de monitoramento e alertas, e Aprendizado Contínuo com experimentação e post-mortems

Primeiro Caminho — Flow (Fluxo): O objetivo é reduzir o tempo entre o commit do desenvolvedor e o código rodando em produção. Isso exige:

  • Pipeline de CI/CD automatizada
  • Deploys pequenos e frequentes (ao invés de releases gigantes a cada 3 meses)
  • Eliminação de transferências manuais entre equipes (dev → QA → ops → infra → segurança)
  • Work in Progress (WIP) limitado — menos trabalho em paralelo, mais trabalho terminado

Segundo Caminho — Feedback: O objetivo é saber rápido quando algo quebrou — e entender por quê. Isso exige:

  • Monitoramento e observabilidade reais (não só um dashboard que ninguém olha)
  • Testes automatizados em cada estágio da pipeline
  • Alertas que acionam as pessoas certas no momento certo
  • Métricas de deploy: frequência, lead time, taxa de falha, tempo de recuperação (as DORA metrics)

Terceiro Caminho — Aprendizado Contínuo: O objetivo é criar uma cultura onde errar é permitido — desde que você aprenda e o sistema melhore. Isso exige:

  • Post-mortems sem culpa (blameless)
  • Experimentação controlada (feature flags, canary deploys)
  • Tempo dedicado para melhoria técnica (não só features novas)
  • Compartilhamento de conhecimento (documentação, pair programming, tech talks)

💡 Dica: Se você quer começar a aplicar os Três Caminhos e não sabe por onde, comece pelo Primeiro Caminho: automatize o build e o deploy. Uma pipeline simples de CI com build + testes + deploy automatizado já elimina uma quantidade absurda de trabalho não planejado. Não tente resolver tudo de uma vez — o próprio livro ensina que mudança incremental é mais eficaz do que revolução.

A mudança cultural é mais difícil que a técnica

O livro deixa claro: a parte técnica do DevOps é a mais fácil. Configurar uma pipeline, subir um container, automatizar um deploy — tudo isso tem documentação, tem tutorial, tem ferramenta. O difícil é mudar pessoas. Mudar processos. Mudar uma cultura organizacional que premia quem apaga incêndio e ignora quem previne.

Esse é o ponto que mais me frustra e que mais me motiva. Porque eu sei que a mudança é possível. O livro prova isso — Bill Palmer consegue. Mas ele só consegue porque encontra aliados, porque tem apoio (mesmo que tardio) da liderança, e porque é persistente o suficiente para não desistir quando tudo parece impossível.

Dicas para quem se identifica com essa frustração

Se você leu até aqui e se reconheceu, algumas lições que o livro me reforçou:

  • Documente tudo. Processos, decisões, incidentes. Documentação é a arma silenciosa que transforma “fulano sabe” em “está documentado aqui”. A síndrome do Brent morre com documentação.
  • Comece pequeno. Não tente implementar DevOps inteiro na segunda-feira. Comece com uma pipeline de CI para um projeto. Mostre o resultado. Deixe o sucesso falar.
  • Meça antes de propor. Antes de dizer “precisamos de CI/CD”, mostre os dados: quantas horas por mês são gastas em deploys manuais? Quantos incidentes aconteceram por erro humano em produção? Números mudam conversas que opiniões não mudam.
  • Encontre aliados. Bill Palmer não mudou a Parts Unlimited sozinho. Você também não vai mudar sua organização sozinho. Identifique quem se importa, quem sente a mesma dor, e construa a mudança junto.
  • Aceite que alguns ambientes não vão mudar. Isso é duro de ouvir, mas é real. Se depois de anos de tentativa o ambiente continua resistente, talvez o ambiente não mereça o seu melhor. O livro mostra a transformação — mas nem toda organização real quer ser transformada.

Conclusão

O Projeto Fênix não é um livro de DevOps. É um livro sobre como organizações de TI se sabotam — e como é possível parar de fazer isso. Gene Kim, Kevin Behr e George Spafford escreveram um romance que é, na verdade, um manual de diagnóstico disfarçado de ficção.

Pra mim, como arquiteto e como Brent consciente, a leitura foi ao mesmo tempo validadora e frustrante. Validadora porque confirmou que o que eu observo não é paranoia — é um padrão organizacional documentado, estudado e solucionável. Frustrante porque me lembrou que saber a solução não basta. É preciso que o ambiente queira mudar — e que a gerência entenda que investir em profissionais com profundidade técnica não é custo, é prevenção.

Se você trabalha em TI e nunca leu esse livro, leia. Não porque vai te ensinar Kubernetes ou Terraform. Mas porque vai te dar vocabulário para nomear o caos — e ferramentas conceituais para começar a organizá-lo. Se você é gerente, leia com mais atenção ainda: o Brent da sua empresa provavelmente já sabe que é gargalo. O que ele precisa não é de reconhecimento — é de pares à altura. Profissionais com senioridade técnica real que possam dividir o peso, questionar decisões e elevar o nível do time inteiro.

E se você é como eu — o Brent que tem consciência de que não deveria ser insubstituível, que propõe mudanças e ouve silêncio, que quer fazer certo em um ambiente que premia o improviso — vai se sentir menos sozinho ao perceber que Bill Palmer também já esteve exatamente onde você está.

A diferença entre a Parts Unlimited do início do livro e a do final não foi tecnologia. Foi decisão. Decisão de parar de aceitar o caos como normal. Decisão de medir, automatizar, documentar e melhorar continuamente. Decisão de tratar TI como parte estratégica do negócio, não como custo operacional. E, principalmente, decisão de valorizar quem constrói — não apenas quem gerencia.

Essa decisão ainda precisa ser tomada em muitas empresas. Talvez na sua. Talvez na minha.

Leia Também

Referências