Arquitetura dos Dados

É curioso como alguns livros acabam sendo conhecidos por um tema muito menor do que realmente abordam. O Projeto Fênix costuma aparecer nas listas de leitura sobre DevOps, mas essa classificação sempre me pareceu limitada. Ao terminar o livro, fiquei com a sensação de ter lido muito mais sobre teoria organizacional, pensamento sistêmico e gestão do que sobre tecnologia propriamente dita.

Li O Projeto Fênix pela primeira vez há aproximadamente seis anos. É curioso perceber como continuo recorrendo às ideias do livro mesmo depois de tanto tempo. Não porque ele ensine uma ferramenta específica — muitas delas, aliás, mudaram desde então —, mas porque seus autores conseguiram fazer algo difícil: transformar princípios de gestão, teoria organizacional e pensamento sistêmico em uma narrativa com a qual qualquer profissional de tecnologia consegue se identificar. As reuniões improdutivas, as interrupções constantes, as prioridades conflitantes, os gargalos invisíveis e a sensação permanente de apagar incêndios fazem parte da rotina de praticamente qualquer equipe de TI. Talvez seja justamente essa proximidade com a realidade que torne seus ensinamentos tão memoráveis.

A história acompanha Bill Palmer, promovido inesperadamente para liderar uma área de TI marcada por atrasos, conflitos internos, incidentes constantes e pela responsabilidade de entregar um projeto considerado vital para a sobrevivência da empresa. A escolha desse formato não é casual. Gene Kim, Kevin Behr e George Spafford acumulam décadas de experiência em gestão de operações de TI, transformação organizacional e melhoria de processos, e optaram por apresentar essas ideias na forma de um romance empresarial. Em vez de escrever mais um manual sobre boas práticas, construíram uma narrativa que permite ao leitor experimentar os problemas antes mesmo de conhecer os conceitos que os explicam. É justamente essa decisão que torna o livro tão envolvente e, ao mesmo tempo, tão didático.

Reduzir O Projeto Fênix a um livro sobre DevOps, no entanto, talvez seja perder justamente sua principal contribuição.

O livro não fala apenas sobre servidores.

Não fala apenas sobre infraestrutura.

Nem mesmo fala apenas sobre tecnologia.

Ele fala sobre sistemas.

Uma das ideias que mais permaneceram comigo depois da leitura foi perceber que organizações se comportam muito menos como organogramas e muito mais como sistemas complexos.

Quando um projeto atrasa, nossa tendência costuma ser procurar culpados. Faltou dedicação da equipe. O gerente planejou mal. O desenvolvedor estimou errado. O fornecedor atrasou uma entrega.

Os autores demonstram exatamente o oposto.

Problemas raramente surgem de indivíduos isolados. Eles emergem das interações entre processos, prioridades concorrentes, filas de trabalho, dependências ocultas e restrições de capacidade.

Essa visão dialoga diretamente com o pensamento sistêmico desenvolvido por Russell Ackoff e popularizado nas organizações por Peter Senge. Ambos defendem que sistemas não podem ser compreendidos analisando suas partes isoladamente, porque grande parte de seu comportamento emerge justamente das relações entre essas partes.

Talvez essa seja a maior lição do livro.

Quando observamos apenas departamentos, deixamos de enxergar o sistema.

Outro aspecto que me chamou atenção foi a influência quase invisível da Teoria das Restrições, desenvolvida por Eliyahu Goldratt.

Durante boa parte da carreira, fui levado a acreditar que aumentar produtividade significava otimizar cada equipe individualmente.

O livro mostra por que essa lógica frequentemente produz exatamente o efeito contrário. Em qualquer sistema existe pelo menos uma restrição dominante. Enquanto ela permanecer limitada, otimizar qualquer outra etapa produz apenas mais filas, mais trabalho acumulado e mais desperdício.

Essa talvez seja uma das ideias mais contraintuitivas da gestão moderna.

Eficiência local não implica eficiência global.

É uma distinção extremamente importante para quem trabalha com dados, engenharia ou produto. Muitas vezes investimos enorme energia em acelerar consultas SQL, otimizar pipelines, automatizar processos ou reduzir o tempo de execução de uma tarefa que, na prática, nunca foi responsável pelo ritmo do sistema como um todo.

Essa discussão inevitavelmente aproxima o livro dos princípios do Lean Manufacturing.

Durante décadas, a indústria concentrou esforços em manter máquinas constantemente ocupadas. Hoje sabemos que utilização máxima nem sempre significa fluxo máximo. O mesmo acontece em tecnologia.

Equipes trabalhando simultaneamente em dezenas de projetos não necessariamente entregam mais valor. Na maioria das vezes apenas aumentam filas, trocas de contexto, interrupções e tempo de espera.

Foi interessante perceber como muitos problemas que costumamos atribuir ao desenvolvimento de software já haviam sido estudados décadas antes pela engenharia de produção.

A tecnologia mudou. A dinâmica dos sistemas, não.

Talvez a maior surpresa da leitura tenha sido perceber que DevOps aparece muito menos como um conjunto de ferramentas e muito mais como uma filosofia de gestão.

Quando pensamos em DevOps, normalmente lembramos de integração contínua, entrega contínua, containers, infraestrutura como código ou observabilidade.

O livro praticamente ignora essas tecnologias.

Seu foco está em reduzir tempos de espera, tornar o trabalho visível, diminuir interrupções, criar ciclos rápidos de feedback e alinhar diferentes áreas em torno de um mesmo fluxo de entrega. Em outras palavras, trata-se muito mais de teoria organizacional do que de tecnologia.

Essa percepção mudou também minha forma de enxergar Engenharia de Dados.

Pipelines, orquestradores, bancos de dados distribuídos e plataformas de streaming costumam receber enorme atenção técnica. Mas, na prática, boa parte dos problemas enfrentados por equipes de dados nasce muito antes da arquitetura. Escopos pouco definidos, prioridades conflitantes, dependências entre equipes, excesso de trabalho em andamento, critérios de priorização pouco claros e ciclos de feedback lentos são desafios que aparecem constantemente ao longo da narrativa e que continuam presentes em projetos modernos de dados. Em muitos casos, passamos semanas discutindo qual tecnologia adotar quando a verdadeira restrição está na forma como o trabalho flui entre as pessoas e as equipes.

Isso reforçou uma ideia que considero cada vez mais importante: organizações não escalam apenas porque adotam tecnologias melhores. Elas escalam quando conseguem construir sistemas capazes de aprender continuamente, limitar desperdícios e melhorar seu fluxo de entrega.

Existe ainda uma influência importante que nem sempre recebe a mesma atenção durante as discussões sobre O Projeto Fênix: o pensamento de W. Edwards Deming. Embora seu nome apareça menos do que Goldratt quando falamos sobre DevOps, sua visão sobre qualidade, melhoria contínua e aprendizagem organizacional atravessa praticamente toda a narrativa. Deming defendia que a maior parte dos problemas de desempenho não está nas pessoas, mas no sistema em que elas trabalham. Essa ideia ecoa constantemente ao longo do livro. Em vez de buscar culpados para cada falha, os personagens são levados a compreender como decisões locais afetam o comportamento do sistema como um todo e como ciclos rápidos de aprendizado são mais valiosos do que tentativas de encontrar soluções perfeitas.

O que mais gostei na obra foi justamente sua capacidade de mostrar que gestão não consiste em controlar pessoas, mas em desenhar sistemas nos quais pessoas consigam produzir bons resultados de maneira consistente.

Essa talvez seja uma das maiores diferenças entre uma organização madura e outra imatura. A primeira procura continuamente melhorar o sistema, a segunda procura continuamente encontrar culpados.

No fim da leitura, ficou claro para mim que este é muito menos um livro sobre DevOps do que um livro sobre pensamento sistêmico aplicado à tecnologia. Provavelmente é exatamente por isso que ele permanece tão relevante uma década após sua publicação. Ferramentas mudam rapidamente. Frameworks entram e saem de moda. Mas gargalos, filas, restrições, ciclos de feedback e aprendizado organizacional continuam sendo desafios permanentes para qualquer empresa que dependa de tecnologia para gerar valor.

Seis anos depois da minha primeira leitura, continuo voltando às ideias desse livro porque elas continuam aparecendo, quase diariamente, no ambiente de trabalho. Os personagens mudam de nome, as tecnologias evoluem, os frameworks são substituídos, mas as organizações continuam enfrentando os mesmos desafios fundamentais.

Poucos livros conseguem envelhecer tão bem. Essa, para mim, é a verdadeira força de O Projeto Fênix: mostrar que os problemas mais difíceis da tecnologia raramente são tecnológicos. Eles são, antes de tudo, problemas de gestão.