Carga cognitiva como restrição de projeto
Existe um limite para quanta coisa um time consegue manter na cabeça. Passado esse limite, tudo degrada ao mesmo tempo — qualidade, prazo, plantão, retenção — e o diagnóstico costuma ser errado: “falta senioridade”, “falta processo”, “falta comprometimento”.
Carga cognitiva é uma restrição de projeto tão real quanto memória ou latência. Sistemas que a ignoram produzem times exaustos operando coisas que ninguém entende inteiramente.
Os três tipos
Seção intitulada “Os três tipos”A distinção vem da psicologia da aprendizagem e é útil aqui:
Intrínseca — a complexidade essencial do problema. Entender o domínio de pagamentos, saber programar, conhecer o negócio. Reduz-se com treinamento e experiência; não some.
Estranha (extraneous) — complexidade acidental, imposta pelo ambiente. Configurar ambiente local por dois dias, decorar dez comandos para fazer deploy, entender YAML de Kubernetes para publicar um serviço, descobrir por tentativa e erro onde ficam os logs. É essa que a plataforma deve eliminar.
Pertinente (germane) — o esforço de construir modelo mental do próprio domínio. É a carga que você quer preservar: é dela que sai o trabalho valioso.
O objetivo de uma boa plataforma, resumido: eliminar a estranha para liberar espaço para a pertinente.
Sinais de sobrecarga
Seção intitulada “Sinais de sobrecarga”Não são sutis, quando se sabe o que procurar:
- O time é dono de sete serviços e conhece bem dois.
- Ninguém consegue explicar como um dos sistemas funciona de ponta a ponta.
- Toda mudança em certa área depende da mesma pessoa.
- O plantão exige conhecimento que metade do time não tem — e essa metade adia entrar na escala.
- Estimativas viram chute porque ninguém domina o suficiente para estimar.
- Trabalho de manutenção consome tudo, e nada novo avança.
- Documentação está sempre desatualizada, porque não há folga para atualizá-la.
Um teste simples e revelador: peça a cada pessoa que liste os sistemas pelos quais o time responde e marque quais ela conseguiria diagnosticar sozinha às 3h. A distância entre as duas listas é a sua carga cognitiva excedida.
Como reduzir
Seção intitulada “Como reduzir”Em ordem de eficácia:
1. Reduzir escopo. Menos domínios por time. É a intervenção mais eficaz e a mais evitada, porque exige decisão organizacional.
2. Mover complexidade para a plataforma. O time deixa de operar Kubernetes e passa a consumir um golden path. A complexidade não some — ela passa a ser mantida por quem tem isso como produto.
3. Isolar o complicado. Um subsistema que exige especialidade rara vira responsabilidade de um time especializado, com interface clara.
4. Melhorar as abstrações internas. Nomes claros, fronteiras explícitas, documentação de decisão. Barato e subestimado.
O que não funciona: acrescentar pessoas ao mesmo time. Acima de certo tamanho, cada pessoa nova aumenta o custo de comunicação sem reduzir a carga — o time fica maior e igualmente sobrecarregado.
O limite honesto
Seção intitulada “O limite honesto”Carga cognitiva não é medível com precisão. Não existe unidade, e qualquer tentativa de transformá-la em número (“cada serviço vale 3 pontos”) vira burocracia sem valor. O instrumento adequado é a conversa com o time e a observação dos sintomas.
Há também um risco na direção oposta: abstrair demais. Uma plataforma que esconde tudo deixa o time incapaz de diagnosticar quando ela falha — e ela vai falhar. A abstração boa é a que remove o trabalho repetitivo sem remover a possibilidade de olhar embaixo do capô quando necessário.
E carga cognitiva não justifica ausência de responsabilidade. “Somos sobrecarregados” é uma informação sobre o sistema, não uma dispensa de operar o que se escreve. A saída certa é reduzir o escopo ou investir na plataforma — não devolver a operação para um time separado, que é onde essa conversa costuma querer terminar.