Método ágil para quando tudo dá errado: a peça que faltava em seu plano de resposta a incidentes

Ao adaptar os valores encontrados no manifesto ágil, é possível eliminar a resposta a incidentes e obter confiança do usuário. 

 

Shannon Winter Shannon Winter
Browse topics

As metodologias ágeis estão sendo cada vez mais usadas fora do ambiente tradicional de desenvolvimento de software em todas as áreas da empresa, até em marketing! Então, começamos a pensar, como é o método ágil no ambiente de gerenciamento de incidentes? Na Atlassian, definimos o método ágil como uma abordagem iterativa e estruturada para o gerenciamento de projeto e de produto. Ele oferece à equipe a capacidade de responder às mudanças sem sair dos trilhos.

Como bugs em produção, incidentes e tempo de inatividade podem, definitivamente, ser classificados como momentos em que as coisas "saíram dos trilhos", imaginamos que uma metodologia como a agilidade — criada para ajudar as equipes a ficarem nos trilhos — teria um local natural no gerenciamento de incidentes – especificamente, comunicação de incidentes.

Aplicar valores ágeis na resposta a incidentes

Embora haja muitas ferramentas para ajudar a equipe a detectar, alertar, analisar e resolver incidentes, as ferramentas sozinhas não conseguem substituir uma comunicação clara às partes interessadas. E vamos ser realistas: o risco pode ser alto. Reputação, atrito com clientes, tempo gasto no controle de danos, só para citar alguns. As metodologias ágeis podem ajudar a manter esses riscos os mais baixos possíveis. 

Muitos de vocês estão, provavelmente, familiarizados com os quatro valores principais do manifesto ágil: 1) indivíduos e interações em processos e ferramentas, 2) trabalho com software com uma documentação abrangente, 3) colaboração do cliente em relação à negociação do contrato e 4) resposta à mudança ao seguir um plano. Vamos ver com mais profundidade como isso pode ser usado para comunicações de incidentes mais ágeis.

Princípio de comunicação de incidente: comunicação de incidente centrada em pessoas

Esse princípio é baseado no valor ágil, pessoas e interações acima de processos e ferramentas. Processos e ferramentas são importantes para qualquer processo de gerenciamento de incidentes, mas não significam nada quando vistos como algo separados das pessoas que os usam e da cultura que formaram. O que fecha as lacunas entre pessoas, processos e ferramentas? Comunicação, é claro! 

A comunicação é fundamental quando surgir um item seja um bug pequeno na produção ou uma falha no sistema. Até mesmo o plano de incidentes mais completo exige comunicação frequente para alcançar uma solução e manter a confiança. 

Durante um incidente, os usuários afetados estão, provavelmente, obtendo erros frustrantes – se não estiverem totalmente debilitados – e precisam saber o que está acontecendo assim que possível. Muitos enviam e-mails, publicam tweets e/ou abrem chamados sobre o item, então é do interesse de todos o conhecimento rápido da situação com uma mensagem que mostre que você sabe que algo está errado e que isso vai ser corrigido. Na Atlassian, usamos o Statuspage para comunicação com as partes interessadas internas e externas durante tempos de inatividade e pense que você também vai encontrar valor rapidamente ao tentar transmitir as informações do incidente aos usuários com rapidez e escalabilidade. De fato, o Statuspage ajudou os usuários a aumentar a velocidade da comunicação de incidentes em 50%.

Quer testá-lo?

Faça a inscrição ou entre no Statuspage >>  

 

Depois de entrar, saiba mais sobre as práticas recomendadas para inscrever os usuários finais e se comunicar com eficiência durante um incidente:

 

Mas seja qual for a ferramenta usada para informar aos clientes, a comunicação com empatia percorre um longo caminho. Há pessoas do outro lado do problema que confiam no serviço que você presta e que você vai manter elas informadas se algo der errado. Embora templates sejam ótimos em um mundo ideal, você precisa de pessoas que consigam se comunicar com clareza, concisão e empatia para ganhar a confiança dos clientes até mesmo nos piores momentos. Tomemos a Dyn, por exemplo. Eles tiveram uma enorme paralisação durante um dos maiores ataques de DDoS na história, mas mesmo assim os usuários agradeceram a eles peça sinceridade demonstrada durante a interrupção do serviço.

Como Werner Vogels, diretor de tecnologia da AWS, disse ao discutir a grande interrupção do AWS S3 em fevereiro de 2017:

"Os clientes não gostam de conselhos que dizem "fique quieto, não faça nada". Não, não é isso que eles querem. E para isso você precisa oferecer informações realmente boas, fazer com que eles entendam o que está acontecendo e oferecer uma expectativa de quando o serviço vai voltar a ficar on-line, se você tiver essas informações."

Princípio de comunicação de incidentes: criação fácil de páginas e atualização de incidentes

Para esse princípio, usamos o valor ágil, Trabalhar com software em uma documentação abrangente. A documentação sobre o produto deve ser clara e fácil, assim como as atualizações de incidentes. Os usuários não devem ler entre as linhas (ou analisar parágrafos longos) para saber o que está acontecendo e quando podem esperar uma correção. Enquanto precisa pensar sobre as atualizações de incidente e garantir que está tendo empatia e solidariedade na comunicação, você não deve deixar que portões de aprovação ou várias revisões atrapalhem as atualizações frequentes e honestas. 

Analisando de novo o incidente da Dyn, é possível ver que a equipe não desperdiçou tempo comunicando as atualizações aos usuários. Ao longo das mais de 11 horas de incidente, eles atualizaram a página de status 11 vezes (uma média de 61 minutos entre as atualizações). A página de status possibilitou que eles tivessem um único local para comunicação sobre o incidente, em vez de desperdiçar tempo procurando listas de correspondência para enviar e-mail ou tentando comunicar as atualizações em 140 caracteres no Twitter. Ou seja, eles entenderam o que deviam fazer enquanto mantinham o foco em fazer o serviço voltar a funcionar. 

A beleza de uma ferramenta de comunicação de status diferenciada na qual você não precisa passar muito tempo para que a página funcione. Leva menos de 30 minutos para criar uma página de status e, como no método ágil, a página de status pode e deve ser iterativa. Pense sobre disponibilizar uma página para os clientes e faça ainda melhor. Depois de ter passado por alguns incidentes com a página de status, como parte do processo, você pode fazer ajustes para melhorar.

Pronto para criar a própria página de status? Faça a inscrição ou entre no Statuspage >>

Não espere até o próximo incidente para criar uma página de status. Reserve alguns minutos para estar na melhor posição possível quando o tempo de inatividade ocorrer. Não se esqueça de que você não precisa gastar muito tempo configurando uma página para ela fazer o trabalho:

Princípio de comunicação de incidente: comunicação transparente durante incidentes e além

O valor ágil A colaboração do cliente em uma negociação de contrato tem tudo a ver com trabalhar com os clientes para disponibilizar o melhor produto e experiência possíveis. Para a gente, isso significa ter canais de feedback adequados para que os clientes possam expor preocupações e alertar sobre quaisquer problemas que possam existir (usando ferramentas como Jira Service Desk, Twitter etc.). As empresas de classe mundial entendem que os clientes esperam uma resposta aos feedbacks e querem estar envolvidos quando se trata de fazer melhorias no produto e no processo de resposta de incidente. Empatia e explicação passam por um longo caminho, e os clientes fazem questão de pedir por isso, como é possível ver nesses tweets:

Isso também significa manter transparência em relação ao tempo de atividade para que os usuários saibam exatamente o que obtêm ao se inscreverem. Ao se inscrever para um serviço em nuvem, você confia que esse serviço seja confiável. Nem sempre é um contrato físico, mas sim um contrato inerente negociado entre o cliente e o provedor de serviços, que quando as coisas dão errado, as duas partes colaboram para garantir que tudo seja resolvido com rapidez e que todos sejam mantidos informados da investigação até a resolução. O que leva ao valor final de resposta às mudanças... 

Princípio de comunicação de incidentes: retrospectivas ágeis

Até os melhores planos...você sabe o resto. Reminiscente do valor ágil, Respondendo a mudanças ao longo de um plano, sabemos que mesmo os planos mais bem elaborados inevitavelmente precisam mudar durante e após a ocorrência de um incidente. O método ágil tem tudo a ver com se manter em equilíbrio e obter feedback rápido e constante que melhore o produto e a cultura.

A Wistia, uma empresa de hospedagem de análise e vídeos da internet, aprendeu sobre a importância de permanecer ágil durante um incidente inesperado em 2013 que deixou a infraestrutura de estatísticas paralisada. Eles não estavam preparados, o que fez com que recebessem milhares de chamadas de clientes insatisfeitos. O primeiro pivô foi a criação da própria página de status para ajudar a facilitar o trabalho em situações como essa. Mas, ao criar a ferramenta própria de comunicação de status, eles conseguiram dar suporte a um novo produto além do produto principal. Ficou claro que era um custo que a equipe de 20 pessoas não podia arcar na época. O segundo pivô foi parar de usar a própria solução e migrar para o Statuspage. 

Jordan Munson, engenheiro de suporte na Wistia, descreveu a jogada: "Após vários meses de frustração em relação à solução útil, mas quase sem recursos, decidimos que precisávamos de algo a mais, algo que não exigisse tanto. Foi quando começamos a usar o Statuspage. Desde que migramos para o Statuspage, conseguimos fazer o que queríamos: manter os clientes atualizados, com rapidez e facilidade, sobre o status do aplicativo. Para chegar a isso, foi preciso apenas uma grande paralisação e a criação de um novo produto. Após alguns anos, o processo é muito mais suave. As pessoas recebem atualizações diretas da gente quando há uma paralisação, sabem onde procurar por atualizações, e as atualizações feitas na página de status são enviadas para vários locais".

A equipe de Munson pegou limões (a paralisação de 2013) e fez uma limonada (um processo de comunicação de incidentes novo, escalável e aprimorado). Essa é uma excelente resposta ágil à mudança. 

As retrospectivas também fazem parte desse valor ágil. Uma retrospectiva oferece à equipe a chance de parar e discutir o que funcionou bem durante a comunicação do incidente, o que não funcionou muito bem e, o mais importante, o que você vai fazer para evitar que os mesmos problemas aconteçam novamente. Não ceda à tentação de não fazer uma retrospectiva depois que um incidente for marcado como "resolvido" ou se achar que a equipe se saiu bem. Há sempre espaço para melhoria quando se trata de comunicação de incidente e há sempre uma chance de melhorar o relacionamento de ganhar a confiança dos usuários. 

Dica profissional:

Teste essa atividade de retrospectiva do Esquema Tático da Atlassian para oferecer um ambiente seguro para a equipe refletir e discutir o que funciona (e o que não funciona) para que você possa melhorar.

Revisitando o primeiro manifesto ágil, as retrospectivas definitivamente exigem comunicação com empatia para ter êxito e proporcionar resultados duradouros. Veja abaixo algumas linguagens para considerar ao discutir como a resolução de incidente se saiu em uma reunião de retrospectiva. Algumas das linguagens também devem estar na revisão pós-incidente (PIR) enviada aos usuários após o serviço voltar a funcionar. Usar o método ágil significa melhorar continuamente não apenas em como você executa as tarefas relacionadas aos incidentes, mas também em como você se relaciona com os colegas de equipe e executa a função durante uma situação estressante. 

People Language

Product Language

Assumptions, hopes, and fears

Tasks, issues, and actions

Motivations, misunderstandings, and behaviors

Springs, epics, stories, and releases

Preferences, relationships, and respect

Milestones, dependencies, and dates

Role and responsibilities

Meetings, calendars, emails, and files

Não se esqueça da confiança

Falamos bastante sobre confiança no método ágil e não é diferente para esse caso de uso. A comunicação de incidente efetiva requer confiança e empoderamento. As equipes na empresa devem se sentir empoderadas com a aprovação e o conhecimento necessários para comunicar os usuários sobre os incidentes. As pessoas também devem conseguir confiar que todos vão cumprir os deveres atribuídos durante uma resposta de incidente, e não vão hesitar em fazer o possível quando algo inesperado ocorrer. Confiar que as equipes vão comunicar com eficiência os incidentes vai permitir que os clientes sejam informados rapidamente e, em troca, vai aumentar a confiança do usuário e a fidelidade ao serviço (67% dos clientes do Statuspage afirmam que essa ferramenta ajudou a aumentar a confiança dos usuários!). Um ganho verdadeiramente mútuo.