Pensamento Sistêmico

Um sistema é mais do que uma coleção de partes. São as partes mais suas interações. E frequentemente, as interações importam mais do que as próprias partes.

Considere uma equipe de software. Você tem desenvolvedores, designers, engenheiros de QA, um gerente de produto. Cada indivíduo pode ser excelente. Mas se eles não se comunicam bem, se as transferências são desajeitadas, se os incentivos estão desalinhados—a equipe tem desempenho inferior apesar do talento.

Pensamento sistêmico significa entender o sistema completo antes de tentar melhorar as partes. Significa perguntar: Como as peças interagem? Que ciclos de feedback existem? Que comportamentos emergentes surgem?

A maioria das disfunções organizacionais vem de ignorar o pensamento sistêmico. Cada departamento otimiza suas próprias métricas enquanto o resultado geral sofre. Vendas fecha negócios que o produto não consegue entregar. Engenharia constrói funcionalidades que o marketing não consegue vender. Todos atingem seus KPIs enquanto a empresa luta.

Aqui está um cenário comum: A equipe de desenvolvimento é o gargalo. Então a gestão decide tornar os desenvolvedores mais eficientes. Eles rastreiam story points, medem velocidade, reduzem reuniões. A produtividade dos desenvolvedores aumenta.

Mas a entrega não melhora. Por quê?

Porque o gargalo nunca foi realmente no desenvolvimento. Foi no deploy—um processo manual e propenso a erros que apenas uma pessoa entendia. Ao acelerar o desenvolvimento, você apenas criou um acúmulo maior no deploy. O lead time aumentou mesmo que os desenvolvedores trabalhassem mais rápido.

Otimização local melhora uma parte do sistema. Otimização global melhora o sistema inteiro. Elas não são a mesma coisa—e a otimização local frequentemente prejudica o desempenho global.

Essa é a percepção de Goldratt da Teoria das Restrições: melhorar qualquer coisa que não seja a restrição é desperdício. Se o deploy é sua restrição, tornar o desenvolvimento mais rápido é teatro. Conserte o deploy primeiro.

Em organizações de software, otimizações locais comuns que prejudicam globalmente:

• Maximizar a utilização dos desenvolvedores (destrói folga, aumenta tempos de espera)
• Medir velocidade individual (incentiva manipulação, prejudica colaboração)
• Otimizar tempo de build (irrelevante se deploys só acontecem mensalmente)

Sistemas contêm ciclos de feedback—a saída de uma parte se torna entrada de outra. Alguns ciclos são de reforço (amplificação), outros são de equilíbrio (estabilização).

Exemplo de ciclo de reforço: Desenvolvedores cortam caminhos para cumprir prazos. Isso cria débito técnico. O débito técnico desacelera o desenvolvimento futuro. As equipes cortam mais caminhos para cumprir o próximo prazo. A espiral da morte acelera.

Exemplo de ciclo de equilíbrio: Uma equipe adota limites de WIP. O trabalho se acumula. As pessoas se mobilizam para ajudar a limpar o acúmulo. O WIP cai. O sistema se autoestabiliza.

Comportamento emergente é um comportamento no nível do sistema que não pode ser previsto apenas pelas partes. Um engarrafamento não é causado por nenhum carro individual—ele emerge de milhares de pequenas interações. Da mesma forma, uma organização disfuncional pode ter todos os indivíduos excelentes, mas o sistema produz disfunção.

O pensamento Lean requer dar um passo atrás para ver esses padrões. Você não pode consertar uma espiral da morte de reforço treinando indivíduos. Você tem que mudar a dinâmica do sistema—geralmente mudando incentivos, restrições ou mecanismos de feedback.