 |
| Bellacosa Mainframe e need for control |
☕ Um Café no Bellacosa Mainframe
Need for Control: Doctor Who, COBOL e o Dia em que Criamos Tantos Controles que Ninguém Mais Conseguia Trabalhar
Uma viagem pela TARDIS dos incidentes para entender por que nossa necessidade de reduzir incerteza pode transformar governança, processos, dashboards e aprovações em uma máquina tão complexa quanto o problema que pretendíamos controlar
08:07.
Segunda-feira.
Mudança simples.
Ou pelo menos parecia.
Nosso jovem programador COBOL precisava alterar uma rotina.
Três linhas.
IF WS-STATUS = 'A'
PERFORM PROCESSAR-CLIENTE
END-IF.
Mudança proposta:
IF WS-STATUS = 'A'
OR WS-STATUS = 'P'
PERFORM PROCESSAR-CLIENTE
END-IF.
Código:
três minutos.
Teste unitário:
quinze.
Mas antes de produção:
ticket.
Aprovação do líder.
Aprovação do gestor.
Aprovação de arquitetura.
Aprovação de segurança.
Aprovação do DBA.
Aprovação da operação.
CAB.
Change Advisory Board.
Revisão adicional porque a mudança caiu perto do fechamento.
Novo documento.
Risk assessment.
Rollback plan.
Evidence pack.
Planilha.
Print da tela.
Print da planilha.
Print do print.
Nosso jovem olha para o relógio.
Quatro dias depois:
a alteração continua esperando.
Ele pergunta:
— Tudo isso é realmente necessário?
O gerente responde:
— Controle.
— Controle de quê?
— Da mudança.
— Mas ninguém das últimas quatro aprovações olhou o código.
Silêncio.
— Mesmo assim precisamos do processo.
— Por quê?
— Para garantir que está sob controle.
Nosso programador olha para o ticket.
CHANGE STATUS:
WAITING FOR APPROVAL 11/14
— E se precisarmos corrigir algo urgente?
— Existe processo emergencial.
— Quantas aprovações?
— Nove.
Silêncio.
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se no meio da sala.
A porta abre.
O Doctor sai carregando uma pasta enorme.
Muito maior do que deveria ser possível.
Ele joga sobre a mesa.
THUMP.
— O que é isso?
— Procedimento para abrir a porta da TARDIS.
— Tudo isso?!
— Não.
Pausa.
— Isso é só o formulário para pedir autorização para solicitar o formulário.
Nosso jovem sorri.
O gerente não.
O Doctor olha para a lista de aprovações.
— Vocês criaram tudo isso porque tinham incidentes?
— Sim.
— Funcionou?
— Tivemos menos mudanças não autorizadas.
— Excelente.
— Então está correto.
— Talvez.
O Doctor aponta para o tempo médio de entrega.
CHANGE LEAD TIME:
2 dias → 11 dias
Depois:
EMERGENCY CHANGES:
+240%
Depois:
MANUAL WORKAROUNDS:
+170%
— Parece que quando ficaram mais difíceis as mudanças normais...
Pausa.
— as pessoas começaram a encontrar caminhos alternativos.
O gerente permanece em silêncio.
O Doctor sorri.
— Às vezes o desejo de controlar um sistema cria exatamente o comportamento que torna o sistema menos controlável.
Bem-vindo ao:
Need for Control
Ou:
Necessidade de Controle
Antes de seguir, uma pequena precisão importante.
“Control Bias” não é uma categoria única e universal da psicologia com definição tão padronizada quanto Confirmation Bias, Anchoring Bias ou Hindsight Bias.
Aqui usaremos Need for Control como uma lente comportamental:
a necessidade psicológica de reduzir incerteza aumentando regras, supervisão, previsibilidade, monitoramento e capacidade de intervenção.
Isso não é automaticamente ruim.
Na medida certa:
é governança.
Quando exagerado:
vira rigidez.
Em linguagem Bellacosa:
“Se alguma coisa pode escapar do nosso controle, criamos mais um processo. Quando esse processo começa a escapar do controle, criamos outro processo para controlar o primeiro.”
🧠 A diferença para Illusion of Control
No capítulo anterior vimos:
Illusion of Control
“Tenho mais influência sobre o resultado do que realmente tenho.”
Agora temos algo diferente:
Need for Control
“Eu me sinto desconfortável quando não consigo prever ou comandar o que acontecerá.”
Um fala sobre:
percepção de poder.
O outro:
necessidade psicológica de previsibilidade e domínio.
Eles podem trabalhar juntos.
Primeiro:
“Precisamos controlar isso.”
Depois criamos:
processos;
dashboards;
aprovações.
Então:
“Agora controlamos.”
Talvez não.
☕ O ser humano não gosta muito de incerteza
Imagine duas situações.
Situação A
Você sabe:
o sistema falhará às 15h.
Ruim.
Mas previsível.
Situação B
Existe 10% de chance de falhar em algum momento.
Talvez nunca.
Curiosamente, a segunda situação pode produzir muita ansiedade.
Porque não sabemos:
quando;
como;
onde.
A incerteza pode ser psicologicamente mais desconfortável que um risco conhecido.
Então tentamos transformá-la em:
checklists;
cronogramas;
controles;
aprovações.
Tudo isso pode ser ótimo.
Até começar a existir principalmente para produzir:
sensação de previsibilidade.
👻 Easter Egg nº 1 — o painel da TARDIS
Companion olha para centenas de controles.
— Você sabe para que serve cada botão?
Doctor:
— Claro.
— Este?
— Não toque.
— E aquele?
— Definitivamente não toque.
— Aquele vermelho?
— Talvez seja iluminação.
— Talvez?!
Doctor pensa.
— A verdade é que controlar uma coisa complexa não significa conhecer cada estado possível dela.
Pausa.
— Às vezes significa construir capacidade suficiente para continuar quando ela surpreender você.
Excelente definição de resiliência.
🧠 Controle é bom
Precisamos deixar isso claro.
Sem controle:
qualquer pessoa altera produção;
dados são modificados;
mudanças não são registradas;
não existe rollback;
ninguém sabe quem fez o quê.
Governança existe por motivos excelentes.
O problema não é:
controle.
É:
controle sem proporcionalidade.
☕ A pergunta é sempre:
“Quanto controle precisamos para este risco?”
Mudança:
alterar comentário.
Risco mínimo.
Talvez uma revisão simples.
Mudança:
alterar cálculo de liquidação financeira.
Risco alto.
Mais controles.
Se os dois passam pelo mesmo ritual de 47 etapas:
o processo deixou de distinguir risco.
🧠 Risk-Based Control
Um modelo mais maduro:
LOW RISK
↓
AUTOMATED TESTS
PEER REVIEW
AUTO DEPLOY
MEDIUM RISK
↓
REVIEW
VALIDATION
CHANGE WINDOW
HIGH RISK
↓
MULTIPLE APPROVALS
CANARY
ROLLBACK TEST
INCIDENT PLAN
Agora:
controle acompanha risco.
Não ansiedade.
🧠 Need for Control + Loss Aversion
Por que organizações acumulam aprovação?
Porque ninguém quer:
perder produção;
perder dinheiro;
perder reputação.
Loss Aversion aumenta desejo de controle.
Então cada incidente cria:
mais um gate.
☕ A árvore genealógica do formulário
Incidente em 2008:
cria campo A.
Incidente em 2011:
campo B.
2014:
assinatura C.
2017:
aprovação D.
2020:
planilha E.
2023:
checklist F.
2026:
ninguém sabe por que metade existe.
Mas retirar qualquer item parece:
arriscado.
Status Quo Bias entra.
🧠 Scar Tissue Process
No capítulo de Recency Bias falamos de:
scar tissue architecture.
Podemos ter também:
scar tissue process.
Cada incidente deixa uma cicatriz procedural.
Uma aprovação.
Uma regra.
Um formulário.
Com o tempo:
o processo vira o registro fóssil de todos os medos organizacionais.
🧠 Sunk Cost protege controles inúteis
— Precisamos mesmo dessa ferramenta?
— Investimos milhões.
— Ela reduz risco?
— Bom...
— Então?
— Já investimos milhões.
Sunk Cost.
Agora não apenas projeto fica vivo.
Governança também.
🧠 Status Quo Bias
Controle existe há dez anos.
Ninguém lembra causa.
Mas remover:
“E se acontecer alguma coisa?”
Essa frase é Need for Control + Status Quo Bias.
☕ O misterioso campo 37
Change form:
FIELD 37:
SECONDARY APPLICATION IMPACT VALIDATION REFERENCE
— Para que serve?
— Não sei.
— É obrigatório?
— Sim.
— Quem lê?
— Ninguém.
— Podemos remover?
— Melhor não.
Perfeito.
🧠 Action Bias e controle
Quando algo falha:
queremos agir.
Depois do incidente:
também queremos agir.
Então criamos:
novo controle.
Novo procedimento.
Novo treinamento.
Isso produz sensação:
“Fizemos alguma coisa.”
Action Bias pós-incidente.
Mas será que o controle reduz causalmente o risco?
🎯 Pergunta Bellacosa nº 1
Sempre que surgir novo processo:
“Qual failure mode específico este controle reduz?”
Se ninguém consegue responder:
cuidado.
🎯 Pergunta Bellacosa nº 2
“Como saberemos se ele funciona?”
Se não há métrica:
talvez seja teatro.
🧠 Control Theater retorna
No capítulo anterior falamos de:
teatro de controle.
Um CAB com quinze pessoas.
Todos clicam:
APPROVE.
Ninguém:
analisa rollback.
Formalmente:
controle.
Efetivamente:
ritual.
☕ Aprovação não é review
Essa diferença merece quadro.
APPROVED
≠
REVIEWED
Você pode ter:
17 aprovações
e:
zero análise real.
🧠 Diffusion of Responsibility
Quanto mais aprovadores:
mais fácil cada um pensar:
“Outro verificou.”
Agora o controle criado para aumentar responsabilidade...
dilui responsabilidade.
Linda ironia.
👥 Groupthink
CAB.
Primeiro aprovador:
APPROVE.
Segundo:
APPROVE.
Terceiro vê uma dúvida.
Mas todo mundo aprovou.
Ele aprova.
Groupthink dentro da própria governança.
🪜 Authority Gradient
Diretor:
— Essa mudança precisa entrar hoje.
CAB inteiro:
APPROVED.
Quinze controles formais.
Um comando hierárquico.
O sistema possuía governança.
Mas não independência.
🧠 Controles podem ser independentes ou decorativos
Uma boa barreira:
pode realmente impedir mudança.
Uma barreira ruim:
sempre aprova.
Se aprovação nunca rejeita nada:
talvez não seja barreira.
É carimbo.
☕ O teste Bellacosa do controle
Pergunte:
“Quando foi a última vez que este controle impediu alguma coisa?”
Se:
nunca,
duas possibilidades:
tudo realmente é perfeito;
o controle não controla.
Investigue.
🧠 Need for Control + Planning Fallacy
Quanto mais processo:
mais difícil estimar trabalho.
Mas gestores continuam dizendo:
“A alteração leva duas horas.”
Código leva duas.
Governança:
sete dias.
Planning Fallacy ignora trabalho invisível criado pelos próprios controles.
🧠 Process Tax
Todo controle possui:
custo operacional.
Tempo.
Coordenação.
Cognitive load.
Espera.
Esse custo precisa entrar na equação.
☕ Controle gratuito não existe
Uma aprovação de cinco minutos parece barata.
Multiplique:
500 mudanças × 12 aprovadores.
Agora existe enorme custo.
🧠 Queueing Theory entra na governança
Imagine:
um único aprovador.
100 mudanças.
Cada aprovação leva 10 min.
Parece simples.
Mas se chegam mais rápido do que são processadas:
fila cresce.
Governança vira gargalo.
Curioso:
uma organização de TI pode otimizar filas MQ...
e esquecer que criou uma fila humana.
☕ O JES da burocracia
JOB001 WAITING APPROVAL
JOB002 WAITING APPROVAL
JOB003 WAITING APPROVAL
...
Sem WLM.
Sem initiator suficiente.
Só café.
🧠 Little's Law no corredor
Quanto mais trabalho em progresso:
mais tempo médio.
Mesmo princípio.
Se 200 tickets esperam:
CAB semanal,
lead time explode.
Não é falta de esforço.
É desenho de fluxo.
🧠 Need for Control pode produzir Shadow IT
Agora vem a consequência deliciosa.
Processo oficial fica impossível.
Usuário precisa entregar.
Então cria:
planilha;
script local;
conta alternativa;
manual workaround.
Ou seja:
controle excessivo cria:
comportamento fora do controle.
☕ Proibir tudo produz criatividade
Gestor:
— Ninguém pode executar scripts sem aprovação.
Usuário:
— Entendido.
Três meses depois:
Excel com 47 macros movimentando processo crítico.
Parabéns.
🧠 Normalization of Deviance
Shadow process funciona.
Todo mundo usa.
Agora:
desvio normalizado.
O controle excessivo plantou sua própria exceção.
🌀 Drift Into Failure
Procedimentos ficam complexos.
Pessoas contornam.
Contornos viram normais.
Observabilidade cai.
Sistema deriva.
Então:
mais controle.
Mais contorno.
Loop.
🧠 Control Paradox
Podemos desenhar:
INCERTEZA
↓
MAIS CONTROLE
↓
MAIS COMPLEXIDADE
↓
MAIS ATRASO
↓
MAIS WORKAROUND
↓
MENOS VISIBILIDADE
↓
MAIS INCERTEZA
↓
MAIS CONTROLE
Esse é o:
Paradoxo Bellacosa do Controle.
👻 Easter Egg nº 2 — Gallifrey Bureaucracy
Doctor chega a Gallifrey.
Funcionário:
— Formulário para uso da TARDIS?
— Eu tenho uma TARDIS.
— Precisa preencher formulário.
— Para quê?
— Para controlar o uso das TARDIS.
— Mas eu já estou usando.
— Exatamente por isso precisamos de mais controles.
Algumas organizações existem em todos os planetas.
🧠 Need for Control + Illusion of Control
Agora o ciclo fecha.
Sentimos ansiedade.
Criamos controle.
Controle existe.
Sentimos segurança.
Illusion of Control:
“Agora o risco está resolvido.”
Mas talvez controle só:
registre;
aprove;
documente.
Não reduza o failure mode.
☕ Planilha não segura pacote TCP
Ainda.
🧠 Compliance Bias
Existe uma tendência organizacional perigosa:
confundir:
compliance
com:
safety / reliability / security.
Checklist completo.
Auditoria passa.
Então:
“Estamos seguros.”
Não necessariamente.
Compliance é importante.
Mas é evidência de aderência a regras.
Não prova ausência de risco.
🔐 Segurança
Política:
senha deve ter 14 caracteres.
Usuário usa:
SenhaSuperSegura2026!
em cinco sistemas.
Compliance?
Talvez.
Segurança perfeita?
Não.
Controle formal não captura tudo.
🧠 Goodhart aparece
Quando métrica vira alvo:
deixa de ser boa métrica.
Exemplo:
KPI:
100% changes approved.
Equipe garante:
100%.
Mas qualidade de review?
Desaparece.
Controle virou performance teatral.
☕ “Zero mudanças não autorizadas”
Excelente.
Mas se toda emergência ocorre fora do processo?
A estatística pode estar maravilhosa.
A realidade menos.
🧠 Need for Control + Micromanagement
No nível humano:
gestor quer saber:
cada tarefa;
cada hora;
cada movimento.
Porque visibilidade produz segurança.
Mas excesso de supervisão pode:
reduzir autonomia;
aumentar espera;
diminuir iniciativa.
Agora equipe começa:
perguntar tudo.
🧠 Learned Helplessness organizacional
Se qualquer ação exige aprovação:
pessoas aprendem:
“Não decida.”
Agora em incidente:
ninguém toma iniciativa.
Diffusion of Responsibility + Need for Control.
☕ “Por que ninguém fez nada?”
Porque treinamos durante anos:
“Não faça nada sem perguntar.”
Depois reclamamos de falta de ownership.
Isso é design cultural.
🧠 Authority Gradient reforçado por controle excessivo
Quanto mais decisões centralizadas:
mais forte a hierarquia.
Especialistas locais param de decidir.
Informação continua distribuída.
Authority fica centralizada.
Má combinação.
🧠 Centralização cria atraso informacional
A pessoa que aprova talvez saiba menos sobre o caso que quem está executando.
Mas autoridade está longe do contexto.
Local Rationality perde espaço.
🎯 Pergunta Bellacosa nº 3
“Quem possui melhor informação para tomar esta decisão?”
Nem sempre é a pessoa de maior cargo.
🧠 Delegation with Guardrails
Uma alternativa madura:
não controlar cada ação.
Defina:
limites.
Exemplo:
ENGINEER MAY ROLLBACK WITHOUT APPROVAL IF:
FAILURE RATE > 10%
AND
DATA LOSS RISK EXISTS
Agora:
autonomia dentro de guardrails.
Controle por design.
☕ Mainframe já conhece isso
RACF.
Permissões.
Perfis.
Você não precisa de gerente aprovando cada READ.
A arquitetura define:
o que pode.
🧠 Policy as Code
Em ambientes modernos:
regras podem ser automatizadas.
Em vez de:
sete pessoas verificando manualmente,
pipeline bloqueia:
teste falhou;
vulnerabilidade;
coverage inadequada.
Isso pode aumentar controle real e diminuir burocracia.
💻 COBOL e pipeline
Imagine:
COMPILE
↓
UNIT TEST
↓
STATIC ANALYSIS
↓
INTEGRATION TEST
↓
APPROVAL IF HIGH RISK
Mudanças simples:
fluem.
Mudanças críticas:
sobem de controle.
Risk-based automation.
🧠 Automatizar controle também tem risco
Automation Bias manda lembranças.
Se pipeline diz:
GREEN,
não significa:
zero risco.
Mas controles automáticos:
consistentes;
rápidos;
auditáveis
podem ser melhores que carimbos humanos repetitivos.
☕ Automação boa remove burocracia, não julgamento
Excelente princípio.
Automatize:
o determinístico.
Mantenha humano:
onde contexto importa.
🧠 Need for Control + Automation Bias
É tentador dizer:
“Vamos automatizar tudo e teremos controle total.”
Não.
Talvez tenhamos:
controle mais rápido.
E novos failure modes.
Automação não remove incerteza.
Muda sua forma.
🤖 IA e Need for Control
Agora chegamos ao futuro interessante.
Agentes começam a executar:
tarefas;
deploys;
análises.
Gestão fica desconfortável.
Resposta natural:
mais approvals.
Mais HITL.
Mais logs.
Alguns necessários.
Mas se qualquer ação de agente exige humano confirmar cada etapa:
não temos agente.
Temos automação com mouse humano.
🧠 HITL precisa ser meaningful
Human-in-the-loop funciona se humano:
tem tempo;
contexto;
autoridade;
capacidade de revisar.
Se recebe:
500 confirmações,
vira:
APPROVE
APPROVE
APPROVE
APPROVE
Alarm Fatigue aplicado a governance.
☕ Approval Fatigue
Excelente primo de Alarm Fatigue.
Muitas aprovações:
aumentam chance de aprovação automática mental.
Controle criado para aumentar segurança...
reduz atenção.
🧠 Four-Eyes Principle
Segundo par de olhos é ótimo.
Mas só se:
realmente olhar.
Caso contrário:
temos dois pares de olhos e zero observação.
🧠 Random sampling pode ser melhor
Em alguns processos de baixo risco:
em vez de revisar 100% superficialmente,
revisar:
10% profundamente.
Talvez controle real aumente.
Depende do domínio.
Risk-based governance novamente.
🎯 Pergunta Bellacosa nº 4
“Preferimos 100% de revisão superficial ou menos revisões realmente efetivas?”
Boa discussão.
🧠 Control Budget
Uma ideia interessante:
cada equipe possui capacidade cognitiva limitada para controle.
Se gastamos atenção verificando:
coisas triviais,
faltará atenção para:
coisas críticas.
Logo:
controle também precisa de priorização.
☕ Você só tem um número limitado de “preste atenção” por dia
Use bem.
🧠 Alarm Fatigue e Approval Fatigue têm a mesma estrutura
Muito sinal.
Pouco significado.
Humano começa a automatizar mentalmente.
Então:
mais controle
pode produzir:
menos controle.
🧠 Checklists também precisam tamanho certo
Checklist de 8 itens:
ótimo.
Checklist de 147:
talvez ninguém leia.
Mais itens não significa:
mais segurança.
✈️ Aviação como inspiração
Checklists críticos são:
estruturados;
práticos;
focados.
Não enciclopédias.
Em TI também:
runbook de incidente precisa ser executável.
☕ Se o runbook precisa de CTRL+F durante o incêndio, talvez precise de redesign
Especialmente se possui 600 páginas.
🧠 Control Complexity
Toda regra adicional:
interage com outras.
Então controles também podem criar:
complexidade emergente.
Regra A exige aprovação.
Regra B impede aprovação fora da janela.
Regra C exige rollback antes da janela.
Agora mudança impossível.
Cria exceção.
Exceção vira processo.
🧠 Exception Explosion
Quanto mais rígido o processo:
mais exceções aparecem.
Logo:
mais regras para controlar exceções.
Mais complexidade.
☕ IF dentro de IF dentro de IF
Governança espaguete.
COBOL pelo menos compila.
💻 Podemos escrever:
IF CHANGE-HIGH-RISK
PERFORM FULL-CONTROL
ELSE
IF CHANGE-MEDIUM-RISK
PERFORM STANDARD-CONTROL
ELSE
PERFORM AUTOMATED-CONTROL
END-IF
END-IF.
Melhor que:
PERFORM EVERYTHING
para qualquer mudança.
🧠 Need for Control + Dunning-Kruger
Gestor conhece pouco detalhes técnicos.
Pode compensar incerteza criando:
mais controle procedural.
Porque não consegue avaliar tecnicamente.
Isso é compreensível.
Mas pode virar:
governança substituindo compreensão.
☕ “Não entendo, então preciso aprovar”
Talvez você precise:
especialista.
Não necessariamente:
mais assinatura.
🧠 Expertise-based governance
Decisão deveria envolver quem entende risco.
Não apenas quem ocupa camada hierárquica.
🧠 Fundamental Attribution Error
Processo enorme.
Pessoa contorna.
Incidente.
Organização diz:
“Fulano não respeitou processo.”
Pergunta:
processo era utilizável?
Talvez comportamento seja consequência do excesso de controle.
Contexto novamente.
🧠 Actor-Observer Bias
Gestão:
“Equipe contorna porque é indisciplinada.”
Equipe:
“Contornamos porque processo impede trabalho.”
Provavelmente há verdade dos dois lados.
Investigue.
🧠 Self-Serving Bias
Quando controle funciona:
“Governança excelente.”
Quando falha:
“Pessoa descumpriu.”
Conveniente.
Talvez controle estivesse mal desenhado.
🧠 Narrative Bias
Depois do incidente:
“Precisamos de mais controle.”
História simples.
Mas talvez incidente tenha ocorrido porque:
controle existente atrasou resposta.
Contra-narrativa importante.
🎯 Pergunta Bellacosa nº 5
“O incidente ocorreu por falta de controle ou pela forma como o controle existente funcionava?”
Fantástica.
🧠 Need for Control e antifragilidade
Um sistema extremamente rígido pode não aprender.
Você tenta impedir:
toda variação.
Mas variações pequenas ajudam:
descobrir fraquezas;
adaptar.
Game Days são exemplo.
Criamos falha deliberada controlada.
Parece oposto de Need for Control.
Na verdade:
aceitamos pequena incerteza para aumentar resiliência.
☕ Deixar quebrar de propósito?!
Gestor tradicional:
— Nunca!
SRE:
— Em ambiente controlado.
Porque queremos saber:
o que acontece.
Controle real vem de experimentação.
Não apenas prevenção.
🧠 Chaos Engineering
A filosofia:
sistemas distribuídos falham.
Então:
vamos testar hipóteses sobre resiliência.
Isso é quase antídoto filosófico para necessidade excessiva de controle.
Não tentamos eliminar imprevisibilidade.
Treinamos para ela.
🧠 Resilience versus predictability
Need for Control deseja:
previsibilidade.
Resilience Engineering deseja:
capacidade de adaptação.
A organização madura quer os dois.
Mas sabe:
previsibilidade nunca será total.
☕ Rígido quebra. Adaptável dobra.
Sem virar frase de biscoito da sorte:
é uma boa metáfora.
🧠 Controle local versus autonomia
Em sistemas complexos, componentes autônomos podem responder mais rápido.
Exemplo:
circuit breaker.
Não espera aprovação humana.
Detecta.
Abre.
Recupera.
Você abriu mão de controle manual imediato...
para ganhar controle sistêmico melhor.
🧠 WLM é um belo exemplo
Imagine tentar gerenciar manualmente cada workload.
Impossível.
Você define:
políticas;
prioridades;
objetivos.
WLM ajusta.
Isso é:
controle por intenção e guardrails.
Não micromanagement de cada transação.
☕ WLM como lição de gestão
Não diga ao sistema:
“dê exatamente 7,3% de CPU a cada segundo.”
Diga:
“este workload é importante; este objetivo deve ser atendido.”
O sistema adapta.
Talvez gestores humanos possam aprender algo.
🧠 Control by Objective
Em vez de controlar cada passo:
defina:
resultado;
limites;
SLO;
política.
Isso reduz necessidade de supervisão constante.
📊 SLOs
Exemplo:
AVAILABILITY SLO:
99.95%
LATENCY P95:
< 500ms
ERROR BUDGET:
X
Agora equipe tem espaço de decisão.
Controle por objetivo.
🧠 Error Budget é quase terapia contra Need for Control
Não buscamos:
zero mudança;
zero falha.
Aceitamos:
nível controlado de risco.
Se error budget está saudável:
podemos evoluir.
Se acabou:
reduzimos risco.
Muito mais sofisticado que:
“Não mexa em nada.”
☕ Zero risco = zero produção
Talvez única forma garantida.
Mesmo assim hardware envelhece.
🧠 Risk Appetite
Toda organização precisa aceitar:
algum risco.
Porque:
zero risco tem custo infinito.
Need for Control tenta perseguir impossibilidade.
Governança madura define:
risco aceitável.
🧠 Residual Risk
Depois dos controles:
ainda sobra risco.
Isso precisa ser aceito conscientemente.
Não fingir que desapareceu.
☕ O risco residual é aquele que continua existindo depois que o PowerPoint fica verde
Excelente.
🧠 Control Effectiveness Review
Todo controle deveria periodicamente responder:
ainda necessário?
ainda efetivo?
custo?
cria workaround?
pode ser automatizado?
pode ser removido?
Isso evita acúmulo eterno.
🧹 Control Garbage Collection
Sim.
Garbage collection de processos.
Controle sem uso:
remove.
Controle duplicado:
consolida.
Controle obsoleto:
aposenta.
☕ PERFORM PROCESS-GC
Gostei.
🧠 Sunset Clause
Novo controle criado após incidente?
Inclua:
REVIEW AFTER:
6 MONTHS
Não precisa ser permanente automaticamente.
Se funciona:
mantenha.
Se não:
mude.
🧠 Temporary controls love becoming permanent
Workaround de duas semanas.
Cinco anos depois:
“processo padrão.”
Normalization of Deviance novamente.
🎯 Pergunta Bellacosa nº 6
“Quando este controle poderá ser removido?”
Se resposta:
“nunca”,
precisa haver motivo forte.
🧠 Measure friction
Governança deveria medir:
change lead time;
approval wait;
emergency change rate;
exception rate;
manual workaround rate.
Essas métricas mostram se controle está produzindo fricção contraproducente.
📊 Sinal de processo ruim
NORMAL CHANGES ↓
EMERGENCY CHANGES ↑
Talvez pessoas estejam classificando tudo como emergência para escapar do processo.
O controle está sendo roteado.
☕ Se toda mudança virou emergência, talvez a emergência seja o processo
Frase pronta para parede.
🧠 Security Exception Growth
Mesma coisa.
Política rígida.
Exceções sobem.
Talvez política não corresponda ao trabalho real.
Não culpe exceção automaticamente.
Revise regra.
🧠 Work-as-Imagined vs Work-as-Done novamente
Processo oficial:
bonito.
Trabalho real:
outra coisa.
Need for Control frequentemente aperfeiçoa:
Work-as-Imagined.
Enquanto pessoas aperfeiçoam:
workaround.
Essa distância é risco.
🧠 Gemba — vá ver
Em qualidade e Lean existe a ideia de:
ir ao local onde o trabalho acontece.
Não desenhe controle apenas da sala de reunião.
Observe:
como equipe realmente opera.
☕ O fluxograma não sente o telefone tocando às 03:00
O operador sente.
🧠 Lean e desperdício administrativo
Aprovação que não agrega valor pode ser:
waiting;
overprocessing.
Governança também pode gerar desperdício.
Controle precisa justificar custo.
🧠 Value Stream Mapping
Mapeie mudança:
CODING: 2h
TEST: 4h
WAITING: 5d
APPROVAL: 15min
Agora percebe:
o trabalho não demora uma semana.
O sistema de espera demora.
☕ Lead Time != Touch Time
Clássico.
Importantíssimo.
🧠 Need for Control e Agile
Agile tentou, entre outras coisas, reduzir alguns loops longos de planejamento e aprovação.
Mas empresas podem criar:
“Agile control bureaucracy.”
Daily.
Weekly.
Status.
Dashboard.
Jira.
Planilha paralela.
PowerPoint.
Agora:
mais cerimônia do que antes.
Ferramenta não remove necessidade psicológica de controle.
Ela pode receber uma interface nova.
☕ Waterfall com post-it continua waterfall
Provocação carinhosa.
🧠 Micromanagement digital
Monitorar:
commits;
horas;
status online;
tickets.
Dá sensação de produtividade observável.
Mas conhecimento não é linha de montagem simples.
Métrica errada cria comportamento errado.
Goodhart.
🧠 Measuring output versus activity
Controle excessivo mede:
atividade.
Número de tickets.
Horas.
Commits.
Mas objetivo deveria ser:
valor;
qualidade;
confiabilidade.
☕ Cem commits podem significar excelente trabalho
Ou alguém brigando com o mesmo bug durante uma semana.
Sem contexto:
métrica não controla desempenho.
🤖 IA e supervisão futura
Quando agentes operarem mais:
a tentação será criar:
dashboard central de tudo.
Talvez necessário.
Mas precisamos distinguir:
visibility;
observability;
control.
E principalmente:
intervention capacity.
Ver agente fazer algo não significa conseguir pará-lo adequadamente.
🧠 Kill Switch
Bom.
Mas já testou?
Illusion of Control.
Need for Control cria o botão.
Engenharia precisa provar que funciona.
🧠 Permission Boundaries
Melhor do que supervisionar cada ação:
limitar ferramentas.
Agente pode:
ler.
Não:
deletar.
Ou:
pode alterar só ambiente X.
Guardrails reduzem necessidade de confirmação constante.
☕ Menos “posso clicar em tudo”
Mais:
“não consigo destruir o universo por acidente.”
Excelente design.
🧠 Least Privilege como controle elegante
Não observa cada passo.
Limita capacidade.
Isso é controle forte com pouca burocracia.
🧠 Safe Defaults
Default:
seguro.
Usuário precisa deliberadamente aumentar risco.
Isso reduz controle manual.
💻 COBOL também
Em vez de:
IF ERROR
CONTINUE
use:
IF ERROR
STOP RUN
quando integridade exige fail-safe.
O design já toma decisão conservadora.
🧠 Fail Open versus Fail Closed
Não existe resposta universal.
Segurança pode preferir:
fail closed.
Disponibilidade talvez:
fail open.
O importante:
decidir conscientemente.
Não inventar 27 aprovações para cada caso.
🧠 Need for Control + Normalcy Bias — o paradoxo
Às vezes organizações controlam demais o cotidiano...
mas subestimam catástrofes.
Milhares de regras para mudança simples.
DR nunca testado.
Interessante.
Controlamos o que é visível.
Ignoramos o raro.
☕ Aprovação para mudar comentário:
14 pessoas.
Restore de backup:
ninguém testou em dois anos.
Prioridades curiosas.
🧠 Base Rate Neglect
Talvez controles estejam focados em riscos raros muito memoráveis...
enquanto riscos comuns continuam.
Faça Pareto.
Onde incidentes realmente nascem?
📊 Control Portfolio
Para cada controle:
FAILURE MODE
FREQUENCY
IMPACT
CONTROL
EFFECTIVENESS
COST
Agora governança vira engenharia.
🧠 Cost-Benefit Control
Se controle custa:
R$ 1M/ano
e reduz risco anual esperado em:
R$ 10k,
talvez revisar.
Claro, compliance e risco catastrófico complicam.
Mas princípio:
controle precisa ser racional.
🧠 Tail Risk
Controle caro pode ser justificável para evento raro e catastrófico.
Então não use apenas frequência.
Impacto importa.
Base Rate + severity.
☕ Não remova extintor porque nunca pegou fogo
Outra distinção importante.
Controle pouco usado pode ser essencial.
Precisamos entender função.
🧠 Need for Control não é sobre remover governança
É sobre:
governança proporcional, efetiva e adaptável.
Esse é o coração do capítulo.
🧠 Controle bom tem cinco características
1. Tem objetivo claro
Qual risco reduz?
2. É proporcional
Ao impacto.
3. É verificável
Sabemos se funciona.
4. Tem custo conhecido
Tempo e trabalho.
5. Pode evoluir
Quando sistema muda.
☕ Se não sabemos por que existe, provavelmente precisamos descobrir antes de mantê-lo para sempre
Não remover cegamente.
Investigar.
📋 Checklist anti-Need for Control
[ ] Qual risco este controle reduz?
[ ] O risco é frequente ou de alto impacto?
[ ] O controle realmente funciona?
[ ] Quando foi testado?
[ ] Qual é o custo operacional?
[ ] Ele aumenta lead time?
[ ] Está gerando workarounds?
[ ] Existe approval fatigue?
[ ] Poderia ser automatizado?
[ ] Poderíamos usar guardrails em vez de aprovação?
[ ] O controle é proporcional ao risco?
[ ] Estamos confundindo compliance com segurança?
[ ] Estamos medindo atividade ou resultado?
[ ] Quem possui melhor contexto para decidir?
[ ] Existe sunset review?
[ ] O controle ainda corresponde ao sistema atual?
🧪 Como combater Need for Control — passo a passo
Passo 1 — Inventarie controles
Liste.
Sim.
Às vezes ninguém sabe quantos existem.
Passo 2 — Ligue cada controle a um risco
Sem risco identificado:
investigue.
Passo 3 — Meça eficácia
Ele evita?
Detecta?
Limita?
Passo 4 — Meça fricção
Lead time.
Espera.
Exceções.
Passo 5 — Classifique risco
Low.
Medium.
High.
Passo 6 — Automatize o determinístico
Testes.
Policies.
Validações.
Passo 7 — Delegue com guardrails
Não centralize tudo.
Passo 8 — Teste controles críticos
DR.
Rollback.
Kill switch.
Passo 9 — Revise periodicamente
Process GC.
Passo 10 — Aceite risco residual
Não tente transformar incerteza em papelada infinita.
🧠 A organização que não tolera nenhuma incerteza
eventualmente cria:
uma quantidade enorme de processo.
Mas incerteza continua.
Agora apenas ficou:
escondida.
Talvez isso seja pior.
☕ Paperwork does not destroy entropy
A física continua vencendo.
🧠 Resiliência como alternativa psicológica
Talvez a maior defesa contra Need for Control seja:
aprender a confiar na capacidade de adaptação.
Não:
“nada dará errado.”
Mas:
“Quando algo inesperado acontecer, conseguiremos detectar e responder.”
Isso reduz necessidade de prever tudo.
🧠 Prediction versus Adaptation
Modelo A:
prever todos os casos.
Impossível.
Modelo B:
prever os principais e ter capacidade adaptativa para o resto.
Muito mais realista.
☕ Não podemos escrever IF para todos os futuros
Mas podemos ter:
ELSE.
Uma metáfora COBOL perfeita.
💻 O ELSE filosófico
IF CONDITION-KNOWN
PERFORM EXPECTED-ACTION
ELSE
PERFORM SAFE-HANDLING
END-IF.
Não sabemos qual condição inesperada aparecerá.
Mas sabemos:
o que fazer quando nossa premissa falhar.
Isso é resiliência.
🧠 Exception Handling
Control freak architecture tenta:
eliminar exceções.
Resilient architecture:
aceita que exceções existem.
E trata.
☕ Uma rotina sem tratamento de erro é a forma mais otimista de necessidade de controle
Ela assume:
o universo obedecerá ao happy path.
🧠 Error Budget novamente
Excelente porque transforma risco em:
algo administrável.
Não precisamos:
zero falhas.
Precisamos:
falhas dentro de limites aceitáveis.
Isso muda mentalidade.
🧠 Control as Feedback, not Domination
Talvez a palavra controle tenha dois sentidos.
Um:
dominar.
Outro:
regular com feedback.
Engenharia de controle funciona com feedback.
Não com onipotência.
A organização madura usa o segundo.
☕ Você não manda na correnteza
Mas pode conduzir o barco.
Essa talvez seja a metáfora mais simples.
🧠 Doctor Who edition
O Doctor não controla:
todo planeta;
toda pessoa;
todo paradoxo.
Mas possui:
conhecimento;
TARDIS;
planos;
capacidade de improvisação.
Sua força é adaptação.
Não domínio absoluto.
👻 Easter Egg nº 3 — o manual infinito
Companion:
— Doctor, achei o manual completo da TARDIS.
Doctor olha.
Livro infinito.
— Excelente.
— Vamos ler?
— Não temos alguns milhões de anos.
— Então como você pilota?
Doctor:
— Conhecimento, feedback e uma quantidade preocupante de improvisação.
O mesmo vale para sistemas complexos.
Talvez com menos explosões.
🧠 Knowledge versus Procedure
Procedimentos são memória institucional.
Ótimos.
Mas não substituem:
competência.
Uma equipe sem expertise e com milhares de páginas de procedimento:
continua frágil.
🧠 Training versus Controls
Controle evita erro.
Treinamento melhora decisão.
Precisamos dos dois.
Não tente resolver falta de competência adicionando aprovação eterna.
☕ Um formulário não transforma ninguém em sysprog
Infelizmente.
🧠 Need for Control e confiança
Equipes maduras precisam de:
trust, but verify.
Confiança sem controle:
ingenuidade.
Controle sem confiança:
paralisia.
O equilíbrio é:
autonomia + observabilidade + accountability.
🧠 Guardrails > Gates em muitos casos
Gate:
pare e peça permissão.
Guardrail:
você pode seguir dentro dos limites.
Esse é um conceito poderoso.
☕ Autoestrada
Guardrail não pede autorização para cada curva.
Impede que um erro vire queda da montanha.
Excelente design.
🧠 Mainframe e guardrails
RACF.
Dataset naming.
SMS classes.
JCL checks.
WLM.
São formas de estruturar comportamento.
Você não precisa de reunião para cada alocação.
Política já existe.
🧠 Governance as Architecture
A melhor governança muitas vezes fica:
embutida no sistema.
Não numa planilha.
📈 Mature DevOps
Pipeline.
Automated controls.
Audit trail.
Risk-based approvals.
Canary.
Rollback.
Agora velocidade e controle não são opostos.
Design ruim faz parecer que são.
☕ DevOps não significa “sem controle”
Significa:
controle melhor integrado ao fluxo.
🧠 Change Failure Rate
Se reduzir burocracia aumenta failure rate:
problema.
Se reduz lead time mantendo ou melhorando qualidade:
excelente.
Meça.
Não debata apenas ideologicamente.
🧠 Four Key Metrics spirit
Lead time.
Deployment frequency.
Change failure.
Recovery.
Controles devem melhorar equilíbrio.
Não maximizar uma métrica isolada.
🧠 Need for Control em liderança
Um bom gestor pergunta:
“Que decisões vocês podem tomar sem mim?”
Se resposta:
nenhuma,
temos fragilidade.
☕ O gerente vira SPOF
Single Point of Failure humano.
Férias?
Produção parada.
Parabéns pela governança.
🧠 Delegation Resilience
A equipe precisa funcionar:
sem pessoa específica.
Processo de controle precisa evitar SPOFs.
🧠 Bus Factor da aprovação
Se somente diretor X pode aprovar:
risco operacional.
Controle se tornou dependência.
🎯 Pergunta Bellacosa nº 7
“Nosso mecanismo de controle possui ele próprio um Single Point of Failure?”
Boa.
🧠 Control Failure Modes
Sim.
Controles falham.
Approval system indisponível.
RACF rule errada.
Monitoring quebrado.
Control plane precisa:
resiliência.
☕ O sistema que controla produção também é produção
Nunca esqueça.
🧠 Meta-control
Quanto mais controles:
mais precisamos monitorar controles.
Isso pode virar regressão infinita.
Controle do controle do controle.
Em algum momento precisamos aceitar:
suficientemente bom.
🧠 Satisficing
Herbert Simon popularizou a ideia de:
buscar solução suficientemente boa dentro de limites reais.
Não ótima perfeita.
Em governança:
controle suficientemente eficaz.
Porque controle perfeito pode custar mais que o sistema.
☕ O procedimento perfeito chega depois que o sistema foi aposentado
Talvez.
🧠 Risk-Based Satisficing
Pergunte:
qual nível de controle é suficiente para este risco?
Essa é uma pergunta muito mais madura que:
“Como eliminamos qualquer possibilidade de falha?”
📓 Diário do Doctor
Se guardar algumas ideias desta viagem, guarde estas:
Need for Control descreve nossa tendência de buscar previsibilidade, supervisão e domínio quando a incerteza nos incomoda.
Controle não é ruim; controle desproporcional é.
Illusion of Control trata de acreditar que controlamos mais; Need for Control trata do desejo de aumentar controle.
Cada novo controle possui custo operacional e cognitivo.
Aprovação não é necessariamente revisão.
Muitos aprovadores podem produzir Diffusion of Responsibility e Approval Fatigue.
Controles excessivos podem gerar Shadow IT e workarounds.
Status Quo Bias e Sunk Cost mantêm controles cujo propósito já foi esquecido.
Risk-based governance é melhor que aplicar o mesmo ritual a todas as mudanças.
Guardrails podem ser melhores que gates.
Automação funciona bem para controles determinísticos; julgamento humano deve permanecer onde contexto importa.
Compliance não é sinônimo de segurança ou confiabilidade.
Resiliência reduz a necessidade de prever e controlar tudo.
Controles também precisam de revisão, testes e aposentadoria.
E principalmente:
Governança madura não pergunta “como controlamos tudo?”. Pergunta “quais riscos precisam de controle forte, onde podemos delegar e como continuamos seguros quando o mundo inevitavelmente sai do roteiro?”.
🕰️ De volta à mudança das três linhas
Quatorze aprovações.
Lead time:
onze dias.
A equipe revisa processo.
Descobre:
dez aprovações foram adicionadas depois de incidentes antigos.
Seis tratavam riscos hoje cobertos automaticamente.
Três eram duplicadas.
Duas ninguém mais sabia explicar.
Redesenham.
Agora:
Mudança de baixo risco
AUTOMATED TESTS
PEER REVIEW
PIPELINE
Média
+ OWNER APPROVAL
+ ROLLBACK
Alta
+ ARCHITECTURE
+ OPERATIONS
+ CHANGE BOARD
+ CANARY
Nosso programador altera:
IF WS-STATUS = 'A'
OR WS-STATUS = 'P'
PERFORM PROCESSAR-CLIENTE
END-IF.
Testes.
Review.
Pipeline.
Produção.
Duas horas.
Sem incidente.
O gerente pergunta:
— Não perdemos controle?
Nosso jovem responde:
— Acho que removemos trabalho que parecia controle.
Pausa.
— E mantivemos aquilo que realmente reduzia risco.
O Doctor sorri.
— Excelente.
🔧 Três meses depois
Métricas:
CHANGE LEAD TIME:
11d → 1.8d
EMERGENCY CHANGES:
-63%
CHANGE FAILURE RATE:
UNCHANGED
MANUAL WORKAROUNDS:
-48%
Interessante.
Menos burocracia.
Mesmo nível de segurança.
Menos exceções.
Talvez:
a organização tenha aumentado controle real justamente ao abandonar parte da necessidade de controlar cada passo.
🥚 Easter Egg final
Na manhã seguinte aparece:
BELLACOSA.BIAS(NEED-FOR-CONTROL)
Dentro:
IF NEW-CONTROL-REQUESTED
PERFORM IDENTIFY-RISK
PERFORM MEASURE-FRICTION
END-IF.
IF CONTROL-HAS-NO-OWNER
OR CONTROL-HAS-NO-PURPOSE
PERFORM REVIEW-CONTROL
END-IF.
IF RISK = 'LOW'
PERFORM USE-GUARDRAILS
ELSE
PERFORM APPLY-PROPORTIONAL-CONTROL
END-IF.
Comentário:
* MORE CONTROL
* IS NOT ALWAYS
* MORE CONTROL.
Outro:
* APPROVED
* DOES NOT MEAN
* REVIEWED.
Outro:
* GUARDRAILS SCALE.
* MICROMANAGEMENT DOES NOT.
Mais um:
* CONTROL THE RISK.
* NOT EVERY BREATH.
E naturalmente:
* THE DOCTOR NEVER FILLED
* FORM 27-B BEFORE USING THE TARDIS.
Nosso jovem fecha o membro.
Algumas horas depois alguém propõe:
— Tivemos um incidente. Precisamos acrescentar três aprovações ao processo.
Ele pergunta:
— Que falha exatamente elas impediriam?
Silêncio.
— Bom... aumentariam o controle.
Ele sorri.
— Então antes de adicionar controle...
Pausa.
— vamos descobrir se estamos reduzindo risco ou apenas reduzindo ansiedade.
A sala fica quieta.
Depois alguém sugere:
validação automática.
Outro:
canary.
Outro:
limite de permissão.
Nenhuma aprovação extra.
Três controles técnicos.
Muito mais fortes.
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro da War Room fica:
Quando não conseguimos tolerar incerteza, tentamos administrar o futuro com regras. Quando amadurecemos, usamos regras onde funcionam, guardrails onde escalam e resiliência onde o futuro simplesmente se recusa a ser controlado.
E talvez essa seja a diferença entre:
burocracia de controle
e:
engenharia de controle.
Uma tenta fazer o mundo obedecer.
A outra aceita que o mundo não obedecerá sempre — e constrói sistemas capazes de continuar funcionando mesmo assim.
☕🌀
Next stop: Zero-Risk Bias — quando preferimos eliminar completamente um risco pequeno porque “zero” é psicologicamente irresistível, enquanto ignoramos uma redução muito maior em outro risco que continua sem chegar a zero.
