Como as equipes compartilham funções e responsabilidades de gerenciamento de mudanças

Gerente/Coordenador de alterações

Os Gerentes de alterações — às vezes chamados de coordenadores de alterações — costumam ser responsáveis por gerenciar todos os aspectos das alterações de TI. Eles priorizam as solicitações de alteração, avaliam o impacto e aceitam ou rejeitam as alterações. Eles também documentam os processos de gerenciamento de alterações e os planos de alterações. E o mais importante: eles se preparam, organizam e agem como membros das reuniões do CAB. O sucesso de um Gerente de alterações costuma ser avaliado pelo cumprimento dos objetivos de prazo e orçamento.

Autoridades/aprovadores de alterações

Uma Autoridade de alterações é uma pessoa que toma a decisão de autorizar ou não uma alteração. Às vezes, é uma pessoa só, como um gerente ou um executivo. Às vezes, é um grupo de pessoas em um conselho consultivo de alterações. Às vezes, é um revisor de pares. De acordo com a ITIL 4, "Em empresas com velocidade alta, é uma prática comum descentralizar a aprovação de alterações, tornando a revisão de pares um preditor principal do alto desempenho".

Os Gerentes de alterações costumam trabalhar junto com a autoridade de alterações para aprovar as alterações e as distribuir pela empresa. Em alguns casos, em especial nas empresas pequenas, o Gerente de alterações é uma Autoridade de alterações e tem o poder de tomar essas decisões sem envolver pessoas ou equipes adicionais.

Partes interessadas da empresa

As partes interessadas da empresa costumam se envolver no gerenciamento de alterações e podem estar inclusas no processo de autorização. O procedimento é cada vez mais comum, considerando a importância essencial dos serviços de software à maioria das empresas.

Por exemplo, se uma alteração afetar a conexão entre o software de rastreamento de pagamentos da equipe financeira e o CRM da equipe de vendas, as partes interessadas das equipes de vendas e finanças podem precisar ser envolvidas nas reuniões de CAB e nas decisões finais feitas sobre a alteração.

Engenheiros/desenvolvedores

As equipes de desenvolvimento costumam enviar as alterações para aprovação e documentar o caso da necessidade. Depois que alteração é aprovada, nas empresas que usam uma abordagem de criação e execução própria, essas equipes implementam e monitoram a alteração e, muitas vezes, respondem a quaisquer incidentes ou problemas relacionados a ela. Em outros casos, a equipe de gerenciamento de incidentes responsável por quaisquer incidentes causados pela alteração pode estar separada dos desenvolvedores que implementam a alteração.

Agentes da central de atendimento

Os agentes da central de atendimento podem trazer uma perspectiva exclusiva da linha frente sobre os incidentes e problemas comuns de serviço que uma alteração pode causar.

Gerentes de operação

Como eles são responsáveis por manter os sistemas funcionando no dia a dia, os gerentes de operação consideram os riscos e as dependências.

Gerentes de relacionamento com o cliente

Para representar a voz do cliente, os gerentes de relacionamento podem oferecer conhecimento sobre a mentalidade, as frustrações e as necessidades sempre em mudança do cliente.

Agentes de segurança da informação e engenheiros de rede

Os especialistas em segurança de rede e infraestrutura da nuvem trazem insights importantes sobre as ameaças e as vulnerabilidades.

O que é um CAB?

Convocando aqueles com as responsabilidades descritas acima, os conselhos consultivos de alterações (CABs) são grupos com a tarefa de avaliar os riscos de cada solicitação de alteração e as aprovar (ou não). Na maioria dos casos, um CAB realiza reuniões agendadas com frequência para revisar todas as alterações futuras propostas e inclui especialistas, conforme o necessário, para explicar, defender ou avaliar a alteração com eles. Os CABs tradicionais são conhecidos como protetores, controlando a liberação das alterações.

Por este motivo, além das reuniões tediosas, backlogs longos das solicitações de alteração e distância do trabalho em si, os CABs costumam ser vistos com desdém. Por sorte, muitos CABs estão evoluindo para melhor permitir uma entrega de software ágil, assumindo um papel de consultoria mais estratégico. Os CABs estão se transformando em consultores responsáveis por monitorar as tendências de alteração, recomendar práticas que possam abordar e buscar formas de melhor permitir que as equipes forneçam valor aos clientes e reduzam os riscos.

O desafio dos CABs

Os clichês sobre reuniões ruins também se aplicam aos CABs. Muitos criticam esse tipo de reunião como sendo desperdiçadoras de tempo, por não cumprir o suficiente, envolver muitas pessoas aleatórias e existir quando elas "poderiam ter sido um e-mail". A situação se deve, em parte, à forma como os CABs tradicionais são sobrecarregados de responsabilidades.

Vamos analisar uma metáfora da aviação para ilustrar o desafio. A gente pode pensar no CAB como a torre de controle de um aeroporto. Aquela torre de controle tem um trabalho: dizer aos aviões quando eles podem pousar. Ela nunca teria a tarefa de avaliar se os aviões têm uma estrutura segura ou se o piloto tem as credenciais certas, porque esses fatores já foram confirmados pela ANAC e outras agências.

Ao mesmo tempo, muitos CABs reúnem uma variedade de partes interessadas e têm a tarefa de tomar decisões amplas de segurança sobre todos os tipos de alterações diferentes. As decisões acontecem, muitas vezes, no final da semana, quando as pessoas estão cansadas e ansiosas para aproveitar o final de semana. O CAB não está posicionado para o sucesso.

Além disso, os CABs costumam se preocupar, em especial, com o risco das alterações causarem incidentes. Claro que a preocupação é importante, mas eles também precisam pesar o risco de atrasar alterações valiosas. Avançar muito devagar pode ter consequências negativas para os clientes e, em um mundo muito competitivo de software como serviço, afundar uma empresa.

É possível elevar e focar o papel do CAB. Com as práticas certas em vigor, muitas alterações podem ser automatizadas. Dessa forma, o CAB pode se tornar um conselheiro importante, rastrear as tendências e fazer parceria com as equipes descobrindo formas de habilitar alterações mais rápidas que beneficiem os clientes.

Como posicionar o CAB como consultor estratégico

A primeira etapa no reposicionamento do CAB é esquecer a noção de que o gerenciamento pesado de alterações produz resultados positivos. Dados de um Relatório de estado do DevOps de 2019 revelaram que os processos que precisavam de aprovação de um CAB tiveram um impacto negativo no desempenho do fornecimento de software e os respondentes que seguiam esses processos eram 2,6 vezes mais propensos a ter um desempenho lento. Além disso, não havia evidências para sustentar que um processo de aprovação formal estivesse associado a taxas menores de falha de alteração.

Por este motivo, as equipes modernas estão seguindo essas etapas para melhorar os CABs.

Pare de tratar as solicitações de alteração como "uma solução para todos os casos"

Cada solicitação de alteração é uma oportunidade de rastrear e coletar informações. A gente pode aprender sobre as taxas de sucesso, os incidentes relacionados e os fatores correlacionados a eles. Com o tempo e a aplicação dos dados, deve ser possível pré-aprovar e automatizar cada vez mais alterações. Apenas as alterações mais arriscadas e com maiores consequências devem precisar de aprovação pessoal.

Aproxime o gerenciamento de alterações e de lançamentos

A abordagem legada às versões era agrupar e lançar todas de uma vez. Cabe aos CABs, então, fazer a revisão minuciosa e aprovar grandes pacotes de alterações. Esta abordagem leva a incidentes graves e dificulta encontrar a origem do problema quando ele ocorre. Ela também reduz a taxa com que as equipes podem oferecer valor aos clientes. Como resultado adicional, os gerentes de alteração e lançamento podem alocar menos tempo para tarefas de gestão de projetos.

Use lançamentos progressivos para testar e iterar

Uma equipe progressiva implementa um canário ou sinaliza o recurso com um pequeno subconjunto de usuários para testar e provar a estabilidade antes da implementação completa. O teste limita o escopo de um possível incidente e prova o sucesso de uma implementação antes de estender a todos os ambientes.

Use a automação e as ferramentas para simplificar o gerenciamento de alterações

As equipes de alta velocidade estão começando a repensar os antigos modelos de aprovação. Em vez de lidar com um longo backlog de solicitações de alteração em uma reunião semanal e presencial, é possível fazer uso da colaboração virtual. A colaboração pode ser um simples e-mail informando as solicitações de alteração para que elas possam ser revisadas antes de uma reunião do CAB. Em outros casos, coisas como tickets do Jira e páginas do Confluence podem permitir que os revisores de alteração tenham o contexto necessário para colaboração assíncrona e aprovação das alterações. Usando o Jira Service Management, as equipes podem colaborar dessas maneiras, até mesmo para participar de uma videoconferência ou criar um canal designado do Slack. Dependendo de como sua equipe prefere manter contato, ela ainda está alojada no mesmo lugar para que todos estejam na mesma página.

As ferramentas legadas de ITSM dificultam que as equipes de infraestrutura, operações e desenvolvimento criem uma solicitação de alteração. Busque a automação e um software moderno para reduzir o peso da entrada manual de informações de alteração. A última coisa que um desenvolvedor quer fazer é preencher tickets em um sistema separado e desajeitado, se o trabalho pode ter rastreamento automático. No Jira Service Management, as equipes podem aproveitar o processo automático para agilizar o processo de alteração, minimizar riscos e reduzir o tempo de inatividade.

Vire para a esquerda e traga o gerenciamento de alterações mais próximo dos praticantes

Uma das estratégias mais comuns que, muitas vezes, substitui ou reduz as aprovações do CAB é a revisão de pares, que coloca a responsabilidade de identificar problemas no código nas pessoas que o entendem melhor. A ITIL 4 destaca que em "Em empresas com velocidade alta, é uma prática comum descentralizar a aprovação de alterações, tornando a revisão de pares um preditor principal do alto desempenho". Da mesma forma, o Relatório de estado do DevOps de 2019 recomendava que "as empresas deveriam 'virar à esquerda' para a aprovação baseada em revisão de pares durante o processo de desenvolvimento".

Para manter a conformidade com os regulamentos, esta abordagem precisa ser documentada com meticulosidade, que é onde os sistemas como o Bitbucket entram em cena, fazendo o rastreamento automático de autores e revisões de pares e evitando que as alterações sejam colocadas em uso sem o processo exigido.

Na Atlassian, a revisão de pares é uma parte essencial do processo de aprovação. Como um dos especialistas em conformidade e risco de TI, explica: "Todos os códigos da Atlassian são armazenados no Bitbucket. Quando um desenvolvedor quer fazer uma alteração, ele verifica o código fora do Bitbucket e no próprio laptop. Quando ele o verifica de volta no repositório do Bitbucket, em vez de atualizar o código, o sistema é configurado para exigir a revisão de pares. Apenas após a revisão ser realizada e aprovada, o código é enviado de volta ao repositório. E se o código não for aprovado? Ele é enviado de volta ao desenvolvedor original com as observações do revisor. Ele corrige o que estiver errado e o envia para outra revisão de pares".

Convoque especialistas para permitir boas práticas

As empresas se tornam mais complexas, facilitando o fluxo de informações e a coordenação entre as equipes é cada vez mais essencial. Em vez de aprovar solicitações individuais de alteração, os CABs podem mover o foco para melhoria da prática. Neste paradigma, eles podem oferecer recomendações de melhoria de práticas, implementar recursos melhores e oferecer recursos e ferramentas que resultem em um desempenho melhor. O paradigma estende o alcance do CAB para tratar o risco de lentidão no lançamento de valor para o mercado.

Até mesmo em empresas de TI mais tradicionais, o CAB pode se tornar um local para encontrar soluções criativas. Em um caso, uma universidade que não tolera riscos e adere a ferramentas e práticas legadas de ITSM precisou descobrir como informar aos alunos sobre um serviço importante que ficaria indisponível. O CAB se tornou um fórum para brainstorm de novas táticas de comunicação. Eles decidiram espalhar doces e pôsteres em uma campanha que foi eficaz em desviar solicitações recebidas sobre um upgrade planejado do sistema.