O documento congelado
Muitas normas escrevem-se uma vez, aprovam-se numa reunião e nunca mais se tocam. Dois anos depois descrevem tecnologias que já não se usam e proíbem coisas que todo o mundo faz. As equipas aprendem que a norma não reflete a realidade, e deixam de olhar para ela.
O extremo contrário também falha: normas que alguém modifica quando lhe apetece, sem avisar, e que acordam diferentes numa segunda-feira qualquer.
Um ciclo com estados
Cada regra da norma passa por estados conhecidos:
- Proposta. Qualquer pessoa pode propor uma regra nova ou uma mudança, com o seu motivo: um incidente, uma mudança tecnológica, uma exigência legal.
- Em revisão. O responsável do domínio avalia-a e ajusta-a com as equipas afetadas.
- Em vigor, com transição. Aprova-se com uma data de entrada em vigor e um período para se adaptar. O novo exige-se desde o primeiro dia; o existente tem um prazo.
- Revisão periódica. De tempo a tempo (por exemplo, uma vez por ano) confirma-se que continua a fazer sentido.
- Retirada ou substituída. Uma regra que já não acrescenta nada retira-se; uma que muda substitui-se por uma nova versão que cita a anterior.
Versionar como o software
- Cada versão da norma tem número e data, e uma lista de mudanças legível.
- As mudanças anunciam-se antes de entrarem em vigor, não depois.
- Pode saber-se que versão se aplicava em qualquer momento passado, o que importa numa auditoria.
- As regras automatizadas seguem a norma: quando uma regra muda, a sua verificação automática muda na mesma versão.
A fonte das propostas
As melhores propostas não vêm de uma comissão, mas da operação: um incidente que revelou um vazio (como em cada falha deixa uma regra), uma exceção que se repete tanto que devia ser a regra, uma regra que ninguém cumpre porque não faz sentido.
Esta última fonte merece o seu próprio artigo, porque as exceções bem geridas são o melhor termómetro de uma norma.
Como o aplicamos: Governo Multicloud.