Como priorizar problemas em um cenário complexo?
Crescemos muito nos últimos anos e hoje somos mais de 100 colaboradores em Produto distribuídos em 20 times, os quais trabalham de forma independente, ou seja, todos têm autonomia para lidar com seus problemas da forma que acharem mais adequada.
A capacidade de entrega de cada time é finita e, para escolhermos o que fazer primeiro, é necessário criar uma gestão de problemas com critérios de classificação e priorização bem definidos. São muitas fontes de dados diferentes e diversos casos que precisamos entender, categorizar e priorizar.
Por isso, estudamos métodos de priorização utilizados no mercado, fizemos projetos pilotos e gostaríamos de compartilhar nossas experiências para ajudar você a priorizar problemas em um cenário complexo!
Categorizando
Identificamos as categorias como o ponto de partida para entender melhor o backlog de problemas. Sejam estes internos — problemas relacionados à qualidade do código e a sua manutenibilidade — ou externos — problemas que já estão afetando nossos clientes.
Para isso, classificamos os defeitos do nosso produto em 2 grandes categorias:
- Débito técnico — referente à qualidade interna;
- Bug — referente à qualidade externa.
Débito Técnico
Consideramos um débito técnico uma solução de arquitetura ou infraestrutura que não atende as demandas atuais ou que traz um risco de não atender ao aumento de uso do software em um futuro próximo. Essas demandas podem ser tanto de escala quanto de dificuldade de manutenção e expansão das funcionalidades.
É comum e esperado que um código surja com um bom design. Porém, após inúmeras alterações de pessoas diferentes, este código começa a adquirir complexidade e se torna um débito para futuras mudanças.
Bug
Classificamos como bug, tudo que afeta diretamente o usuário final. Consiste em um comportamento inesperado da aplicação, algo que não deveria estar acontecendo. Ocorre quando a aplicação foi programada para funcionar de uma forma e, por algum motivo, apresenta um comportamento diferente, seja ele a interrupção de um fluxo, um resultado inesperado ou um uso inadequado.
Agora que estamos alinhados em como categorizamos os problemas aqui na Resultados Digitais, iremos partir para a priorização.
Priorizar significa fazer primeiro as coisas que geram mais valor para os nossos clientes. Mas como sabemos o que é mais importante para eles?
Priorizando
Por algum tempo utilizamos uma metodologia desenvolvida na própria RD, baseada em critérios de gravidade e frequência para definir a prioridade dos problemas. No entanto, tínhamos a ciência de que essa metodologia “feita em casa” já não refletia a realidade dos times.
Com o objetivo de buscar um método de priorização de problemas que atenda melhor o nosso contexto atual, estudamos dois dos mais comuns no mercado: RICE e GUT.
RICE
RICE é uma sigla em inglês para os seguintes termos que serão avaliados:
Alcance (Reach): quantidade de clientes que aquela tarefa irá alcançar.
Impacto (Impact): quantidade de clientes que serão impactados.
- 3 — impacto massivo
- 2 — grande impacto
- 1 — médio impacto
- 0,5 — pequeno impacto
- 0,25 — impacto mínimo
Confiança (Confidence): nível de confiança das estimativas.
- 100% — alta estimativa
- 80% — média estimativa
- 50% — baixa estimativa
- Esforço (Effort): quantidade de tempo necessário para a tarefa ser finalizada.
Para calcular o RICE basta multiplicar os 3 primeiros itens e dividir pelo último:
RICE = (Alcance x Impacto x Confiança) / Esforço
GUT
A ideia é classificar nossos bugs e débitos técnicos levando em consideração a gravidade, urgência e tendência do problema com o objetivo de definir qual devemos atacar primeiro.
Para facilitar a priorização criamos um template com o cálculo automatizado do GUT para auxiliar os times de produto a priorizarem nossos problemas.
- Inicialmente devemos listar nosso backlog de bugs e débitos técnicos em uma tabela básica;
2. Pontuar cada bug e débito técnico conforme os critérios de Gravidade, Urgência e Tendência, seguindo as informações abaixo:
Gravidade: consequências que os problemas podem causar se não atuarmos sobre eles.
- Sem gravidade — 1: causa desconforto na operação, gera frustração na experiência.
- Pouco grave — 2: impede a conclusão de um fluxo de operação. Só é possível concluir por retentativa ou work around.
- Grave — 3: interrompe um caso de uso. Não é possível contornar ou remediar a situação sem intervenção da empresa.
- Muito grave — 4: causa prejuízo reversível à operação do cliente, como indisponibilidade de dados/operações.
- Extremamente grave — 5: causa prejuízo irreversível à operação do cliente, como perda de informações ou de oportunidade.
Urgência: tempo estimado em que podemos resolver os problemas.
- Pode esperar — 1: mais de 6 meses — pode ser feito no trimestre que vem.
- Pouco urgente — 2: mais de 3 meses — temos que resolver neste trimestre.
- Urgente, merece atenção em curto prazo — 3: mais de 1 mês — temos que resolver neste mês.
- Muito urgente — 4: até 1 mês — temos que resolver nesta semana.
- Necessidade de ação imediata — 5: nesta semana — temos que resolver pra ontem.
Tendência: refere-se ao que irá acontecer com os problemas se não forem resolvidos.
- Ameniza — 0,5: As ações que já foram ou estão sendo executadas tendem a amenizar o problema ao longo do tempo.
- Não irá mudar — 1: Permanece estável.
- Piorar a médio prazo — 2: Aumenta linearmente com o aumento do número de clientes.
- Piorar a curto prazo — 3: Aumenta exponencialmente com o aumento do número de clientes ou do engajamento promovido em uma funcionalidade.
- Piorar rapidamente — 5: Aumenta exponencialmente com a projeção de uso e a inclusão de novas condições no uso do produto.
3. A planilha do template já está automatizada com o cálculo do GUT, o qual se dá pela multiplicação dos critérios:
GUT = Gravidade x Urgência x Tendência
O resultado com maior pontuação é de 125 pontos e o menor é 0,5. Após priorizar todos os problemas, ordene a lista do maior GUT para o menor.
Buscando a melhor solução
Inicialmente, realizamos uma pesquisa com todos os Product Managers e Tech-Leaders dos times de produto através de um formulário contendo perguntas como:
A sua equipe utiliza a criticidade dos bugs e débitos técnicos nas priorizações de tarefas?
Qual a forma de priorização utilizada?
Essa forma está atendendo a sua equipe bem?
Os 16 times responderam a pesquisa, sendo que todos utilizavam o nosso método de priorização “feito em casa” e 5 deles passaram a utilizar também outras metodologias como GUT e RICE.
Dos 16 times, apenas 4 deles estavam satisfeitos. Logo, 75% dos times estavam insatisfeitos. Contudo, os times que utilizaram outras metodologias como o GUT e o RICE, se mostraram 100% satisfeitos.
Após a pesquisa, a insatisfação dos times com o método de priorização atual tornou-se ainda mais evidente. O que todas as equipes querem é: uma forma de verificar o impacto dos bugs e débitos técnicos no produto, mensurar quantos clientes serão afetados e medir o esforço. Sendo assim, chegamos a conclusão que a melhor alternativa no momento seria realizar um piloto com o RICE.
Piloto com RICE
Foi realizado um piloto em 5 times de produto, cujo objetivo era priorizar todos os bugs e débitos técnicos com o RICE. Ao realizar a priorização, nos deparamos com os seguintes problemas:
- Os valores do RICE ficaram com uma variação extremamente alta, podendo ultrapassar 500.000 (ou mais);
- É necessário um esforço alto para obter o Alcance de cada funcionalidade;
- O RICE ficará inválido em pouco tempo, pois o número de clientes/contas cresce muito rápido, inviabilizando o levantamento do alcance para todos os clientes/funcionalidades.
Tendo em vista os problemas listados, o RICE tornou-se inviável para a nossa realidade. Portanto, iniciamos um experimento com o GUT.
Piloto com GUT
Realizamos mais um piloto em 5 times de produto, cujo objetivo era priorizar todos os bugs e débitos técnicos com o GUT. Após a execução do piloto, conseguimos obter os seguintes benefícios:
- O valor máximo do GUT é 125 e esse valor não sofrerá alteração com o crescimento da base de clientes;
- Por contemplar bugs e débitos técnicos, conseguimos concentrar todos os problemas no software em uma lista única priorizada;
- Ajuda a garantir que os esforços serão investidos primeiro nos problemas mais críticos que, consequentemente, geram mais valor aos clientes;
- É escalável, pois é uma metodologia simples de ser aplicada.
Após a execução dos pilotos, chegamos a conclusão de que a metodologia mais viável para a classificação dos bugs e débitos técnicos é o GUT e passamos a aplicar para todos os times de produto.
Conclusão
No universo de desenvolvimento de software, vivemos em constante mudança e precisamos conseguir atender as demandas dos clientes de forma ágil. Com o backlog classificado e priorizado, é possível resolver os problemas mais rápido e melhorar o produto de forma contínua. Esse é um processo custoso, mas que no longo prazo garante a estabilidade e confiabilidade do projeto.
Com relação à escolha do melhor método de priorização, os projetos piloto também ajudaram a agilizar o processo e escolher a metodologia de forma mais assertiva. Realizando os testes com uma amostragem reduzida, impactamos menos nos trabalhos dos times, pois nem todos precisaram mudar seus procedimentos diários enquanto estávamos experimentando.
Para levar esses aprendizados para o seu dia-a-dia, nossa dica é: conheça melhor seus problemas e comece a puxar as correções para o ciclo de desenvolvimento do time. O tempo das pessoas é um recurso muito valioso para a empresa, então ajude a garantir que ele está sendo empregado de forma otimizada e nas atividades certas!
