Porque é tempo de abandonar o seu Change Advisory Board

O Change Advisory Board (CAB) é uma componente significativa do Change Management nos departamentos de TI. A sua promessa? Minimizar o risco, acelerar a resolução de incidentes e melhorar a comunicação e colaboração. Mas, na prática, o CAB reduz significativamente o Time-to-Market e é dispendioso em termos de mobilização de equipas e recursos financeiros. Pode também gerar uma falsa sensação de segurança e baixar a qualidade da entrega. 15 anos de experiência em Devops ensinaram-me uma coisa: é tempo de abandonar o seu CAB em favor da automatização.

‍

As últimas décadas testemunharam mudanças profundas na forma como as aplicações são concebidas e geridas. As duas mais significativas são provavelmente a utilização generalizada das abordagens Agile e Devops. Na encruzilhada destas duas grandes transformações está a Gestão da Mudança (Change Management), ou como assegurar que as mudanças esperadas pela empresa sejam efetivamente implementadas na produção, de uma forma segura e sem impacto para os utilizadores.

Um dos aspectos mais visíveis da Gestão da Mudança é o CAB, que representa o Conselho Consultivo da Mudança (Change Advisory Board), e na Alenia trabalhamos com muitos intervenientes, incluindo os principais bancos de investimento. Nestas organizações, os departamentos de TI são compostos por milhares de pessoas, espalhadas pelos principais centros financeiros (NY, Londres, Paris, Hong Kong, etc.) e são responsáveis por centenas de aplicações críticas. Como em muitas grandes empresas, a cultura CAB ainda está muito presente. Observei até 4 casos de CAB para o mesmo pedido de alteração antes de ser autorizado a entrar em produção:

• O CAB da tribo localizada em Paris, pois o chefe de produção da tribo quer certificar-se de que tudo é feito corretamente para "poupar tempo”
• O CAB da região, por exemplo, para uma entrega pelas equipas de Nova Iorque a um banco cuja sede se encontra em Paris
• Um CAB ad-hoc, porque a aplicação faz parte de um processo comercial sensível que já sofreu vários incidentes importantes no passado
• O CAB global do departamento de TI

Cada uma destas reuniões têm frequentemente lugar semanalmente, com uma duração mínima de uma hora e reunindo um número significativo de participantes (o business e os seus representantes, desenvolvedores, analistas empresariais, gestores de projeto, testadores, integradores, suporte a aplicações, profissionais de infra-estruturas, gestores de mudança, gestores de lançamento, gestores, etc.)

Convém lembrar que as instâncias do CAB são apenas a ponta do iceberg, e que isto pode representar uma hora de trabalho a montante, por vezes mais, para o fluxo de trabalho de elaboração e validação de cada pedido de mudança. Para além disso, há a preparação do CAB e a validação de cada um destes pedidos, muitas vezes várias centenas por semana.

‍

Porque é que os CABs estão tão difundidos?

É fácil compreender que o processo de disponibilizar uma nova funcionalidade aos utilizadores não vai ser o mais fácil, mas acima de tudo que vai levar tempo! Então porque é que a maioria das empresas optou por implementar um CAB?

Uma vez ultrapassados os preconceitos de comportamento humano, que não devem ser subestimados, tais como "sempre o fizemos desta forma" ou "se não tivermos um CAB, não temos uma gestão de mudança séria" ou uma cultura empresarial que gera mais desconfiança do que confiança, encontramos principalmente as seguintes razões:

1.    Minimizar os riscos associados a alterações que conduzam a perturbações ou falhas

2.    Acelerar a resolução de incidentes com rastreabilidade clara para identificar rapidamente as alterações que causam a perturbação

3.    Assegurar que as alterações são devidamente revistas e aprovadas para cumprir os requisitos regulamentares ou de auditoria interna

4.    Melhorar a comunicação e a colaboração entre as diferentes equipas da organização

‍

Na realidade, o que é observado?

O CAB permitirá acima de tudo verificar se cada ator completou corretamente o pedido de mudança. Dado o volume, diversidade e complexidade das mudanças a serem tratadas, ninguém será capaz de assegurar que as ações foram realmente realizadas corretamente, ou mesmo de assegurar que uma mudança terá um impacto sobre outra. Pior ainda, o organismo do CAB, devido à sua posição, carece frequentemente da autoridade para impedir realmente uma mudança. Tudo isto cria um falso sentimento de segurança e diluição de responsabilidade, em que todos pensam que o que fazem é validado por outra pessoa, o que contribui para uma qualidade inferior.

No que diz respeito à rastreabilidade, há muitas vezes margem para melhorias. A lentidão do processo significa que as equipas que são solicitadas a entrar em produção, geralmente sob pressão do negócio ou da gerência, preferem não seguir o rasto ou fazer alterações à pressa.

Finalmente, no que diz respeito à comunicação entre equipas, tais problemas são tão profundos que o CAB tornar-se-á geralmente um campo de batalha, o que, sejamos francos, não é o lugar ideal para a colaboração.

Os objectivos do CAB são, portanto, na melhor das hipóteses, apenas parcialmente atingidos, e são, de fato, muito dispendiosos:

• Um enorme abrandamento do Time to Market, de alguns dias para várias semanas, o que tem consequências para o negócio, mas também para a motivação dos empregados.
• O número de pessoas mobilizadas antes e durante o CAB representa um custo financeiro significativo
• Embora haja muito poucos estudos científicos sérios sobre o assunto, a investigação que levou à redação do livro Accelerate, escrita por autores líderes na área, mostra uma correlação negativa entre a qualidade de entrega e a existência de um CAB. Esta correlação mantém-se mesmo quando o CAB é utilizado apenas para alterações de alto risco. Pior ainda, as equipas sem um CAB têm uma qualidade de entrega superior.

Finalmente, a primeira reação a um incidente grave será geralmente aumentar os critérios de controlo do CAB, ou mesmo acrescentar uma instância, o que acentuará este círculo vicioso.

Neste caso, porquê continuar?

Esta observação é frequentemente partilhada pelos vários intervenientes na Gestão da Mudança, mas ainda é demasiado raro ver desaparecer os CABs. Penso que a principal razão é que o abandono do CAB pode ser visto como uma tomada de risco imprudente e um sinal enviado de que todos podem fazer o que querem porque a polícia já não estará lá.

Na realidade, a melhor resposta para combinar velocidade e qualidade só pode ser a automatização:

• Antes de mais nada, investir na qualidade do software em vez de procedimentos. Espalhar a utilização de BDD, TDD, programação por pares, gestão da cobertura de código, testes de aceitação de escrita, etc.
• Construir uma conduta CI/CD robusta e totalmente automatizada que assegure que os testes sejam sistematicamente reproduzidos o mais cedo possível no ciclo de desenvolvimento (shift left) e que só permita a entrega com um elevado nível de confiança.
• Esta mesma conduta é responsável pela criação de pedidos de mudança na ferramenta ITSM e pela geração de documentos obrigatórios para satisfazer os pedidos do regulador e de auditoria. Esta automatização terá também a consequência direta de melhorar a qualidade dos dados e, portanto, a resolução de incidentes relacionados com a entrega.
• Quanto à colaboração entre equipas, a implementação de conceitos ligados à Agilidade ou à gestão Lean é muitas vezes a mais eficaz. A construção do pipeline e a sua melhoria contínua pelas equipas de desenvolvimento e produção são muitas vezes exercícios perfeitos para falar e compreender-se mutuamente.

 Podemos realmente existir sem um CAB?

Após mais de 15 anos no ambiente profissional em torno de questões de entrega, penso que a única boa razão para manter um CAB é fazê-lo apenas quando se tem uma estratégia clara para sair dele. Aqui estão 3 dos exemplos mais comuns:

1. Tenho um CAB principalmente "infra". Neste caso, trabalho com as minhas equipas de TI para assegurar que as minhas aplicações são resistentes ao fracasso, ao extremo, isto pode levar à implementação do Chaos Monkey. Desta forma, a aderência entre infra-estrutura e aplicações é reduzida ao mínimo, ou mesmo desaparece completamente, o que torna o CAB inútil.

2. Tenho um CAB para algumas aplicações problemáticas, muito transversal, monolítico e muitas vezes aplicações vindas de fornecedores. Neste caso, a solução seria criar um procedimento "go/no go" específico para estas aplicações, o tempo para trabalhar na instalação sem interrupção de serviço e para tornar a aplicação mais modular.

3. As minhas equipas não estão maduras, será um desastre se eu parar o CAB. É preferível estabelecer indicadores para definir com precisão o nível de maturidade que espero que autorize as entregas fora do CAB. Isto pode ser feito através da criação de uma Error Budget Policy baseada em business SLAs, ou voltando ao modo CAB quando a aplicação tiver tido mais de X incidentes de lançamento no mês passado.

No final, o que devemos recordar? A gestão da mudança e uma estrutura para a gerir são hoje indispensáveis. Mas pensar que o CAB é necessário para o bom funcionamento da empresa é claramente um erro, tendo em conta a sua eficiência e custos muito relativos. A qualidade do processo de lançamento de funcionalidades na produção provém acima de tudo da automatização. Automatização que deve ser apoiada por uma fábrica de testes que garanta com um alto nível de fiabilidade que o que entra em produção não causará regressão ou comportamento inesperado. Além disso, existem todas as alavancas de resiliência, a fim de limitar falhas, ou para assegurar que pode ser relançada rapidamente, se necessário.

Se está interessado neste tópico e gostaria de prolongar a discussão, por favor, não hesite em me contactar!