A lei de Gall (parte I)

A Lei de Gall é um princípio do design de sistemas, da ciência da complexidade e da aprendizagem organizacional que afirma:

“A complex system that works is invariably found to have evolved from a simple system that worked.”

— John Gall, Systemantics (1975) 

E o seu corolário:

“A complex system designed from scratch never works and cannot be patched up to make it work. Start over with a working simple system"

O verdadeiro sentido da Lei de Gall é que a complexidade que funciona tem de surgir de forma gradual, e não ser construída de uma só vez. Os sistemas complexos bem-sucedidos — sejam biológicos, tecnológicos, organizacionais ou de gestão — desenvolvem-se por iterações sucessivas, e não através de um grande desenho inicial. Não se constrói um avião começando por um plano perfeito no papel; começa-se por um planador simples, experimenta-se, aprende-se e evolui-se a partir daí.

Da mesma forma, os sistemas simples falham de forma controlada, enquanto os sistemas complexos falham de modo catastrófico. Implementações gigantes, procedimentos demasiado concebidos ou sistemas ISO exageradamente pesados tendem a colapsar sob o peso das suas próprias ambições. Já os sistemas simples revelam os seus problemas mais cedo, com menor custo e com menor risco para a organização.

No fim, a evolução vence sempre a especificação. O refinamento progressivo gera estabilidade; os projectos demasiado desenhados geram frustração. A maturidade de um sistema constrói-se passo a passo, permitindo que a complexidade certa emerja apenas quando é realmente necessária.

É por isso que as pequenas experiências, feitas em partes controladas do sistema, são tão valiosas. Permitem validar ideias, filtrar o que funciona e, sobretudo, podar o que não serve. Quando se testa uma solução em pequena escala, os erros aparecem cedo, sem grande custo e com impacto limitado. As interacções entre pessoas, processos e tecnologia tornam-se visíveis e compreensíveis. É neste espaço reduzido e seguro que nasce a aprendizagem verdadeira, a que ajuda a perceber o que deve ser simplificado, reforçado ou abandonado.

Ao contrário, quando um sistema é implementado de uma vez, com documentação exaustiva, processos totalmente redesenhados e novas práticas impostas de cima para baixo, tudo fica mais frágil. As falhas surgem onde menos se espera, as pessoas recorrem a atalhos, a utilização real diverge do plano, e a organização vê-se obrigada a remendar continuamente para manter o sistema vivo. Um sistema concebido em grande escala tende a falhar de forma igualmente grande; um sistema que cresce a partir de pequenas experiências falha em modo “seguro”, permitindo aprender e ajustar rapidamente.

É essa capacidade de evoluir por iterações, de experimentar e refinar antes de escalar, que separa os sistemas resilientes dos sistemas pesados que ninguém usa. Ao começar com uma versão simples — suficientemente clara para funcionar e suficientemente pequena para ser corrigida — criam-se as condições para que a complexidade futura seja uma resposta natural às necessidades reais, e não uma construção teórica desligada do terreno. As pequenas experiências tornam-se, assim, o laboratório da organização: o espaço onde se valida, se elimina, se poda, se afina e, finalmente, se constrói algo duradouro.

Em suma: sistemas vivos crescem por evolução, não por desenho grandioso. E a evolução começa sempre com experiências pequenas, concretas e disciplinadas, capazes de revelar o que funciona, o que não funciona e o que nunca devia ter sido tentado. 

Lembro-me logo da nossa constituição.

Continua.