Por que você deve classificar e priorizar os bugs do seu produto?
Esse é um daqueles assuntos que muitas vezes pode parecer óbvio, mas na prática pode ser mais complicado do que parece. De forma geral, o que está em discussão aqui é conseguirmos responder 3 perguntas:
Quando você precisa ter algum sistema de classificação de bugs?
Por que isso é importante?
Como você deve estruturar isso?
Se você tem pouquíssimos bugs, muito poucos mesmo E se esses bugs são extremamente simples de corrigir, você não deveria se preocupar muito com isso.
Porém, isso dificilmente acontece. Qualquer sistema/programa/site um pouco mais complexo já pode gerar bugs suficiente para deixar o time atarefado por algum tempo.
Ou seja, com raras exceções, você deve sempre priorizar e classificar os bugs.
Por que é importante classificar e priorizar?
A classificação e a priorização são importantes por várias razões, entre elas para ajudar o time a focar nos bugs mais sérios primeiro e para ajudar a organizar o processo de correção.
Sem uma classificação/priorização adequada você passa a ficar dependente do bom senso de quem vai corrigir, na hora da correção. E assim você corre sérios riscos de corrigir os bugs na ordem "errada".
Por exemplo, entre começar a corrigir um problema que impacta o billing e começar a corrigir um problema que é um typo na página, muito provavelmente você vai querer começar a corrigir o do billing. Mas se você não tem uma forma de priorizar isso, eu te garanto que muitas vezes você vai começar pelo typo (por exemplo por ser mais rápido).
Existe uma outra razão para você usar um sistema de classificação. Ele te ajuda a equilibrar o balanço entre corrigir um bug e implementar uma funcionalidade nova.
Por exemplo, você pode instituir algumas "regras" tipo: só corrigirmos bugs de impacto/prioridade médio/baixo quando terminarmos essa nova funcionalidade, ou ainda, sempre que tivermos um bug de prioridade muito alto paramos tudo para resolver o problema.
Como funciona um sistema de classificação e priorização?
Via de regra, você sempre classifica os bugs quanto ao seu impacto, prioridade e/ou severidade (ou uma combinação qualquer desses 3).
Algumas empresas usam um simples ranking de 1 a 5, outras um de ranking de 1 a 3. O importante é que o critério que define o que é bug de prioridade 1 e o que é um bug de prioridade 3 ou 4 esteja claro para todo mundo.
A regra deve ser simples, e tangível para todos. Algo na linha da lista abaixo.
Impacto 1 - Todo o sistema está fora, ou com sérias degradações de performance.
Impacto 2 - Os componentes principais estão degradados, e não temos nenhum workaround (solução de contorno) OU temos funcionalidades-chave degradas.
Impacto 3 - Componentes principais degradados, mas com workaround OU Componentes Secundários Degradados e não temos nenhum workaound)
Impacto 4 - Componentes Secundários Degradados mas temos workaround
Impacto 5. Demais problemas. (typo, pixels desalinhados, etc)
Com uma lista dessa podemos classificar os bugs de forma mais simples e mais objetiva. Por exemplo:
Se o portal saiu do ar, claramente é um bug de impacto 1.
Se você tem um portal de conteúdo, mas o bug impede que seu usuário veja conteúdo, isso também deve ser um bug de impacto 1.
Mas se o problema é que o usuário não consegue compartilhar o conteúdo nas redes sociais, isso já não é de impacto 1, provavelmente ele foi "rebaixado" para impacto 2 ou 3 (dependendo de quanto o compartilhamento é importante para o negócio).
Se você tem um e-commerce, e seu usuário não consegue comprar ou pagar, isso é claramente um bug de impacto 1.
Mas se por outro lado, ainda no billing, ele não consegue parcelar o pagamento, isso é um bug de impacto 2 ou 3.
E quando uma dimensão não é suficiente?
Dependendo do caso você precisa ter uma 2a dimensão para ajudar na classificação. Imagina que você tem um produto que pode ser usado na nuvem (no modelo SaaS) ou on-premisses (quando é instalado na infra-estrutura do cliente). Nesse caso, talvez faça sentido você entender como o impacto (conforme o exemplo acima) é sentido pelos clientes. Para isso você pode usar uma segunda dimensão como ilustrado abaixo:
Prioridade 1 - Afeta todos os clientes
Prioridade 2 - Afeta os principais clientes
Prioridade 3 - Afeta muitos clientes
Prioridade 4 - Afeta poucos clientes
Prioridade 5 - Afeta apenas 1 cliente
Dependendo do sua situação você pode ainda ter outras dimensões. Você pode classificar os bugs ainda por aspectos como:
Se os bugs são Funcionais vs UX vs Tradução.
Se os bugs são Funcionais vs de Performance vs de "Arquitetura" vs de "Especificação".
Quando a complexidade técnica.
Quando a frequência do caso de uso envolvendo o bug.
Bugs vs Times (essa é muito usada quando seu time começa a crescer e se especializar).
Dado que você pode trabalhar todos esses aspectos, como juntamos isso tudo? Minha dica aqui é : "Keep it Simple". Ou seja, por mais que seja tentador colocar tudo em uma forma que faz mil e 1 cálculos e te informa A lista priorizada, eu normalmente sugiro uma abordagem mais simples.
No caso da classificação por time, eu normalmente a uso simplesmente para direcionar os bugs para os times mais adequados. As únicas "dimensões" que eu acho que pode fazer sentido calcular são o impacto e a prioridade. E nesse caso podemos ter uma multiplicação simples. Algo na linha abaixo:
Ou seja, você deveria se preocupar com os pontos "vermelhos", e de forma geral se preocupar pouco com os pontos "verdes".. O que normalmente eu adoto é a regra de não ter bugs "vermelhos". Ou seja, sempre que temos um bug "critico", paramos o time para resolver. Se o bug é moderado, ele pode ser resolvido em outra oportunidade.
Resolvendo bugs não críticos/urgentes
Se você resolver adotar a minha sugestão de não parar tudo quando um bug de prioridade/impactos moderados for identificado, fica a questão de quando esse bug será efetivamente resolvido. Para isso podemos adotar algumas estratégias:
Dedicar uma pessoa do time só para corrigir bugs;
Dedicar um dia na semana para todo o time resolver bugs (bug fix day ou housekeeping);
Dedicar um sprint ou um time-box para a correção dos bugs;
Sempre antes de começar uma funcionalidade nova, você corrigi um bug de baixa prioridade;
Ou uma combinação das alternativas acima.
Das 3 primeiras, eu particularmente já utilizei quase todas, e de forma geral elas funcionam bem para dar conta dos bugs legados. Não recomendo porém que essa abordagem seja utilizada para dar conta dos bugs "novos", pois a forma mais eficiente de corrigir um bug "novo" é na hora que você percebe ele (é também o ponto mais "barato" uma vez que você não precisa mudar de contexto).
Como eu disse antes, pode-se escolher desde o mais simples até o mais complexo. A questão é entender qual o sistema mais se adequa a sua necessidade e ter em mente que quanto mais simples melhor.
