Teoria dos Gargalos

Na década de 1980, Eli Goldratt desenvolveu a Teoria das Restrições (TOC). A ideia central é simples, mas profunda:

Todo sistema tem uma restrição—uma etapa que limita a capacidade de entrega do todo.

Pense em uma rodovia: se um trecho está congestionado, toda a rodovia fica mais lenta. Alargar os trechos livres não ajuda. Você precisa resolver o trecho congestionado.

O mesmo se aplica aos fluxos de valor. Se a revisão de código é o gargalo, tornar o desenvolvimento mais rápido apenas cria uma pilha maior na revisão de código. Se os testes são a restrição, contratar mais desenvolvedores apenas significa mais trabalho esperando pelo QA.

O sistema só pode avançar tão rápido quanto sua restrição mais lenta.

Isso tem implicações poderosas para a melhoria: melhorar qualquer coisa que não seja a restrição é teatro. Pode parecer produtivo, mas não tem efeito na capacidade de entrega geral.

Como você encontra a restrição? Procure onde o inventário (trabalho) se acumula.

A restrição tem uma pilha de trabalho esperando na frente dela. Se a revisão de código sempre tem um backlog, a revisão de código provavelmente é a restrição. Se os testes têm semanas de trabalho na fila, os testes provavelmente são a restrição.

Outros sinais de restrições:

• Alta utilização: A restrição está no limite
• Pressão constante: As pessoas na etapa de restrição estão sempre apressadas
• Escassez a jusante: Etapas após a restrição estão esperando por trabalho
• Frustração a montante: "Terminamos, por que não está avançando?"

Restrições comuns em software:

• Revisão de código (poucos revisores, PRs grandes)
• Testes (QA manual, cobertura de testes limitada)
• Deploy (releases complexos, janelas de deploy limitadas)
• Decisões de arquitetura (esperando pelo arquiteto)
• Decisões de produto (esperando pelo product owner)

Observação: a restrição frequentemente não é uma etapa "produtiva". Pode ser um tomador de decisões. Pode ser um processo de aprovação. Pode ser um recurso compartilhado.

A TOC prescreve um processo de cinco etapas:

1. Identificar a restrição: Encontre onde o trabalho se acumula.

2. Explorar a restrição: Maximize a capacidade de entrega através da restrição sem adicionar recursos. Se a revisão de código é a restrição, priorize revisões em vez de novo desenvolvimento. Certifique-se de que os revisores não estão distraídos. Reduza o tamanho dos PRs para que as revisões sejam mais rápidas.

3. Subordinar todo o resto: As não-restrições devem servir à restrição. Se o QA é a restrição, não empurre mais trabalho para o QA—ajuste o ritmo do desenvolvimento para corresponder à capacidade do QA.

4. Elevar a restrição: Se a exploração e a subordinação não forem suficientes, adicione capacidade à restrição. Treine mais revisores. Automatize os testes. Contrate mais da habilidade restrita.

5. Repetir: Uma vez que você quebra uma restrição, outra emerge. A restrição se move. Encontre-a e repita.

Isso é melhoria contínua e iterativa. Você está sempre focado na restrição atual, não disperso por todas as etapas.

A metáfora tambor-pulmão-corda: A restrição é o "tambor" que define o ritmo. O trabalho antes da restrição é o "pulmão". A "corda" puxa o trabalho para o sistema no ritmo que a restrição pode lidar—não mais rápido.