É possível ter Previsibilidade e Cadência na Gestão de Problemas em Produção com #NoEstimate?
Venho compartilhar um case prático de um trabalho baseado em uso de métricas de fluxo, e priorização dinâmica, para transitarmos de um cenário com bastante imprevisibilidade sobre quando um novo problema em produção seria resolvido, para um cenário que possamos, sem um árduo trabalho de estimativa, manter um bom alinhamento de expectativa e previsibilidade.
O desafio principal foi criar uma agenda sustentável para a gestão de problemas em produção, independente da criticidade, focando em manter um tempo de resposta adequado as necessidades dos clientes e melhorar o nível de confiança e gestão de expectativa entre as partes interessadas. Dado que o quadro anterior dependia frequentemente de forças-tarefa para estabilizar a quantidade de problemas sempre que chegava em um teto máximo que tínhamos estabelecido.
Portanto, vou compartilhar algumas ações que nos ajudaram a estabilizar este quadro, fazendo uso de mecanismos de previsibilidade de fluxo e gestão de risco, além de políticas explícitas que fomos instituindo para alcançar a agenda proposta.
O roteiro abaixo vai ajudar a entender um pouco mais e dar dicas para esta jornada:
1 — Trate o problema realmente urgente como urgente
Todos conhecem a máxima, quando tudo é urgente nada é urgente, e quando tratamos de problemas de software em produção, os famigerados bugs, esta regra é ouro. É essencial você ter um sistema de classificação destes por prioridade, entendendo quais itens são críticos, ou de alta, ou de média, ou de baixa prioridade, não vou me aprofundar aqui nos critérios que você pode usar, mas é importante que seja algo simples, de linguagem ubíqua, seja documentado como uma política explicita do seu projeto e torne esta classificação parte intrínseca do processo de abertura de bugs para a engenharia.
A lição aqui deste primeiro passo é que uma vez você conhecendo quais os problemas são realmente críticos, você adote uma política especial de trabalho, que vamos chamar aqui de política de expedite (“expedite” significa acelerar e é uma das classes de serviço que se usa em sistema Kanban). Nesta política de trabalho você irá acordar as seguintes ações com todos os seus times:
1 — Haverá uma raia separada no topo do board de trabalho dos times para os itens críticos priorizados para ele.
2 — Estes itens uma vez no quadro de visão do time precisarão ser resolvidos tão breve quanto possível, mesmo que isto signifique parar um trabalho em andamento ou ultrapassar o limite de carga (WIP Limit) estabelecido para aquele time em alguma coluna do fluxo de trabalho.
Adotar uma política exclusiva para lidar com esta categoria de problemas, e criar mecanismos para a gestão visual destes, fará com que o time consiga priorizar estes itens com a urgência que eles demandam, focando em respondermos de forma rápida aos itens que vão ter um maior impacto ao cliente, proporcional ao tempo que atrasamos a resposta. Esta ação também ajuda a criar uma cultura de auto-organização do time em relação a este tipo de problema. É importante que você conduza suas reuniões diárias com o time através da leitura do quadro, e portanto, você observará que a equipe priorizará estes bugs de maior impacto com atenção, sem a necessidade de coordenação para tal iniciativa.
Agora que já temos uma estratégia acordada com todos os times em relação a ações realizadas sobre itens críticos, vamos seguir nossa história, avançando alguns meses no tempo, e para os próximos passos vamos fazer uso daquilo que trabalhar em projetos ágeis usando gestão de fluxo nos dar de forma tão positiva, métricas!
“Agilidade gera dados, A agilidade gera muitos dados. Os Gerentes utilizam esses dados para direcionar o projeto rumo ao melhor resultado possível”
(Robert C Martin, Clean Agile, 2020, Alta Books)
2 — Conheça a capacidade do time e use isto a seu favor
Uma vez coletando dados de fluxo, descobrimos, em números, algo que já desconfiávamos pelas narrativas dos stakeholders, uma vez os problemas sendo priorizados pelo time, eles eram rapidamente resolvidos, ou pelo menos dentro de um tempo de resposta gerenciável com as partes interessadas, mas o problema é saber quando, ou se, um problema iria ser priorizado, era algo que dependia bastante de esperança, ou de um pedido direto à gestão dos times, o que não é nem um pouco orgânico ou escalável. No caso de problemas críticos, a política de expedite já estava ajudando bastante com a questão do alinhamento de expectativa, mas quando eram problemas não críticos, os pontos de insatisfação com a falta de previsibilidade eram visíveis.
Vem então a segunda parte do nosso processo evolucionário, olhamos os dados históricos de todos os bugs resolvidos até hoje separados por time e por classificação, e levantamos os seguintes dados em dias:
- Tempo entre o Bug ser aberto para engenharia até ser priorizado para os times
- Tempo entre o Bug ser iniciado até ser resolvido em produção
Você consegue extrair estes dados facilmente com a sua ferramenta de gestão do trabalho e usando o Excel ou várias ótimas ferramentas de métricas de fluxo que há no mercado.
Uma vez com estes dados em mãos, podemos montar uma visão rápida do percentil(*) de tempo de ciclo de cada etapa que cada bug de prioridade Crítica, Alta, Média ou Baixa passou até ser resolvido, em um determinado período de tempo. Aqui está um exemplo do tempo de resolução dos bugs para uma determinada categoria em um dos times de desenvolvimento, os percentis são representados pelas barras horizontais pontilhadas com os valores percentuais, sendo cada um dos círculos um bug entregue:
(*) Percentil é um conceito estatístico usado para dividir um conjunto de dados ordenados em 100 partes iguais, de forma que cada parte representa uma porcentagem específica dos dados
O exemplo acima é somente um recorte do tempo de entrega uma vez priorizado, como citei acima você precisa segmentar a análise para o estudo das informações que vamos abordar com destalhes a seguir.
Um ponto de atenção neste momento é entendermos se a variabilidade desta distribuição é confiável o suficiente para usarmos como uma ferramenta para estipularmos uma previsibilidade que possamos usar para alinharmos a expectativa de tempo de resposta.
Uma forma simples de fazer isto é por meio de um histograma(*) desses tempos de ciclo levantados acima, e então, posso analisar se é ou não uma distribuição confiável para usarmos como ferramenta para previsibilidade, através de uma análise da distância entre a calda (percentil 98% da minha amostra) com a mediana (percentil 50% da mesma), este cáculo é relativamente simples e você pode encontrar mais detalhes aqui: https://getnave.com/blog/thin-tailed-vs-fat-tailed-distribution/.
(*) Um histograma é uma representação da distribuição de frequência de um conjunto de dados numéricos.
Aqui está meu exemplo desta distribuição:
Em nosso caso constatamos matematicamente que o tempo para responder um bug, uma vez priorizado, tinha uma boa previsibilidade independente da classificação, mas para bugs não críticos havia uma confiabilidade muito baixa e uma alta variação entre o tempo de estes serem abertos e entrarem para o backlog dos times.
Sabendo destes dados acima, acordamos uma nova política, todos os bugs uma vez abertos receberiam uma data de vencimento (due date), esta data seria posta no card do bug pelo gerente responsável pelo time que atuava na feature afetada pelo mesmo (esta informação da funcionalidade afetada era inserida quando o bug era aberto pelo time de suporte).
Esta data não era uma estimativa, mais uma análise de expectativa de tempo de entrega, que podemos chamar aqui de SLE (Service Level Expectation, ou seja, expectativa de nível de serviço), e neste case adotarmos o seguinte processo para chegarmos nesta data de forma simples:
1 — O gerente deste time, com base em uma análise rápida da taxa de vazão do trabalho iniciado pelo time, estipulava uma data provável que este problema poderia ser puxado para o backlog do time (lembre-se que Bugs críticos seguiam com a política própria de expedite e priorização imediata)
2 — Tendo esta data, ele pegava a quantidade de dias do percentil 85% do tempo de resolução de todos os bugs, daquela mesma classificação, resolvidos pelo time nos últimos três meses, ou seja, o intervalo máximo que em que 85% de tudo que foi respondido nos últimos três meses levou até ir para produção após priorizado. Então somávamos esta quantidade de dias à data de priorização (passo 1), e agora teríamos a data de expectativa de resposta para colocar no card. Claro que, para facilitar o trabalho, colocamos estes percentis previamente em um Excel que era atualizado a cada três meses, acelerando bastante o processo.
Acho que você já observou que o passo 1 tem uma alta margem de falha, e isso era previsto mesmo, alinhamos com todos que o processo era um experimento, mas era necessário para começarmos a trabalhar com esta estratégia de #noestimate, e mais a frente vocês verão como criamos formas de garantir uma maior acuracidade desta previsão.
“Nós, programadores, simplesmente não sabemos quanto tempo as coisas levarão. Isto não significa que somos incompetentes ou preguiçosos, significa que não temos como saber exatamente o quanto uma tarefa será complicada até que ela esteja em andamento e seja concluída.”
(Robert C Martin, Clean Agile, 2020, Alta Books)
3 — Analise o Risco olhando a data que algo precisa começar e não a data que precisa terminar algo.
Agora chegamos em um ponto essencial para o nosso experimento, estabelecemos em nossas cadências uma análise do risco de os bugs em aberto daquele time não serem resolvidos antes da data de SLE que foi estipulada, e priorizamos os bugs com maior risco ou antes que o risco aumente.
Para chegar neste indicador de risco passamos a focar a análise, não em relação a data de entrega prevista, mas em relação a data que cada bug deveria ser priorizado dentro de um intervalo seguro do seu tempo de ciclo histórico de resolução. Ou seja, se o percentil 100% daquele time era 15 dias, eu sabia que se o time priorizasse o bug até a data prevista de entrega menos 15 dias, a chance de não entregar a tempo era muito baixa, pois tudo que ele fez em três meses de problemas da mesma categoria, não levou mais que 15 dias para resolver, mas se a data atual fosse maior que o intervalo do percentil 50% daquele time menos a data desejada de resposta do bug, eu sabia que o risco de dar errada era muito alto, pois priorizando o bug hoje a chance de dar tempo de responder até o SLE era de menos de 50%.
Para determinar quais intervalos de dada de início do trabalho seriam uma margem de começo muito cedo, cedo, normal, tarde ou último momento responsável para confiar na previsibilidade, eu usei uma das abordagens sugeridas no Livro Kanban Maturity Model, no apêndix D, chamado Triage, que reproduzo abaixo (aqui nesta página tem um exercício bem simples para entender melhor este processo https://djaa.com/one-important-planning-question/). Segue o modelo de intervalos de data de início e a relação entre a data de entrega desejada e a distribuição de tempo de ciclo do time:
Conhecendo os intervalos acima, apliquei um algoritmo bem simples para categorizar o risco de cada um dos bugs, colocando esta equação no Excel ou PowerBI e adicionado uma coluna com o indicador de risco, a informação fica bem visual. Segue aqui a lógica que decidi aplicar para o meu cenário, de forma que ao final bastava comparar as datas:
Um efeito colateral muito legal deste levantamento acima é que você também vai conhecer, além do nível de risco, as datas de início normal, tarde ou muito tarde do seu trabalho, e estas datas podem servir como datas sugeridas para priorizar o trabalho da semana, de fato eu cheguei a criar um calendário inteligente no PowerBI com a data sugerida para cada bug ser priorizado de forma que não seja nem cedo demais, nem tarde demais.
4 — Colete dados e acompanhe a evolução
Tenha uma cadência para olhar regularmente o risco, e priorizar de forma balanceada e sutentável os problemas que serão trabalhados, a visibilidade proposta anteriormente pelo PowerBI (ou pelo Excel), será um ferramental que poderá apoiar demais a objetividade desta reunião. Tente criar tanto a visibilidade de risco dos bugs ainda não iniciados, seguindo o algoritimo aplicado no passo anterior, como uma análise de "lagging indicator" acerca do percentual de bugs entregues dentro da previsão e o intevalo de distribuição desta.
Após alguns meses rodando o processo acima, começamos a observar um efeito muito interessante. Lembram que o tempo de engajamento dos bugs tinha uma variabilidade muito alta para usarmos de forma confiável para análise de previsibilidade? Pois bem, o tempo para um novo bug aberto ser priorizado caiu significativamente, dado que a gestão de risco acima, relativa à data que um bug precisaria ser priorizado, fez com que os problemas fossem priorizados na hora certa (just in time) para mitigar o risco de não serem entregues no tempo acordado no SLE.
E agora com uma distribuição mais confiável do tempo para priorização de novos bugs, pudemos eliminar a etapa em que o gerente precisava estipular a data de priorização do problema para somar com o percentil 85% do tempo de entrega de bugs priorizados, ou seja, atualizamos a política, para que em caso de novos bugs o gerente responsável pela feature afetada somente precisaria observar o percentil 85% total dos últimos três meses dos bugs resolvidos daquela classificação (da etapa de aberto até resolvido), e colocar a data de expectativa de entrega como SLE, simples e pontual.
5 — Tenha suas salvaguardas
Uma dica importante é que problemas e assimetrias ocorrem, por isso tenha salvaguardas para evitar situações atípicas que possam gerar uma carga muito alta de problemas que possam sobrecarregar o sistema. No meu caso coloquei um gatilho para uma ação que chamamos de Bug-Smashing, ou seja, um dia inteiro em que toda a engenharia parava os trabalhos e focava na redução do backlog de problemas. Para tal, gerei uma visualização rápida no PowerBI da taxa média de demanda de novos bugs em produção versus a taxa média da capacidade de resolução de bugs da engenharia, usei uma média móvel de três semanas nestas taxas, e caso as diferenças entre estas ultrapassasse 20%, acionaríamos o bug-smashing.
Sobre este número de 20%, eu cheguei nele analisando o histórico de toda a engenharia e o quanto da relação entre capacidade e demanda era tratado de forma sustentável, segue aqui um recorte deste gráfico, felizmente em um ano, somente uma vez esta salvaguarda foi necessária.
Os Resultados
Com estes passos acima, fomos capazes de gerenciar melhor a expectativas junto as partes interessadas, dado que com a maior acuracidade em relação ao SLE foi possível construir uma maior confiança, assim como permitir que em casos de bugs que precisariam de uma atenção maior por questões relativas ao negócio, podiam comunicar a engenharia facilmente, caso estivessem desconfortáveis com a data de previsão.
Mas eu acredito que o maior ganho foi alcançarmos um equilíbrio sustentável entre a entrada e saída de problemas, garantindo a qualidade da entrega, e respeitando a velocidade de trabalho de cada um dos times, dada a natureza e contexto de cada equipe, de uma forma simples e que habilitou também a auto-organização destes times sobre que bugs seriam puxados e quando.
Após rodarmos este experimento tivemos um resultado significativo já no primeiro ano, no qual destaco:
· Aumento da confiança e alinhamento da expectativa sobre o tempo de resposta de problemas em produção, independente da criticidade.
· Queda significativa da idade dos bugs, raramente temos bugs mais velhos que 30 dias, mesmo que sejam de baixa prioridade.
· Queda de 67% no backlog total de bugs.
· Queda de 56% no tempo de engajamento para a priorização de um bug após aberto.
· Queda de 51% no tempo total de resposta de um bug após aberto para engenharia.
· Queda significativa de 76% no tempo que um bug passava “em espera” no suporte antes de ser respondido ao cliente.
Espero ter contribuído com as dicas acima sobre a importância de usarmos processos que busquem a sustentabilidade, entre a capacidade e a demanda, e abordagens #noestimate para alinhamento rápido e gestão de expectativa.
