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.

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

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.

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

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.

Translate

sábado, 13 de outubro de 2012