Priorização: Como priorizamos os problemas na Qualyteam

A priorização é uma dor latente que pode ser observada em diversas empresas e ambientes, pois a capacidade de entrega é sempre menor do que a quantidade de problemas para resolver. Visto que não temos uma capacidade de resolver todos os problemas do mundo, escolher o melhor problema a ser resolvido (priorizar) é uma questão muito importante. Então como saber quais os melhores alvos, visto que você tem poucas balas no cartucho? Tem como a bala fazer curva? Ao longo desse meu tempo de experiência como desenvolvedor e coordenador de projetos, posso dizer que já vi diversas formas de priorização, cada uma com seus pontos positivos e negativos. Meu objetivo nesse artigo é compartilhar com vocês essa experiência de como estamos enfrentando esse problema de priorização aqui na Qualyteam e como chegamos no nosso método de priorização atual.

Método anterior

Há pouco tempo o método de priorização que estávamos usando se baseava em uma separação entre problemas impeditivos (impedem o fluxo do usuário) e não impeditivos, além disso, cada problema recebia uma classificação entre os quatro níveis de prioridade (Baixa, Média, Alta e Urgente), atribuída por um colaborador da equipe de Suporte.

Nessa priorização, nossa visão era atacar os problemas impeditivos mais rápido, permitindo ao usuário fluir melhor no uso do sistema. Um dos problemas é que, as definições dos níveis prioritários eram subjetivas. Observamos que a priorização do problema mudava de acordo com quem o priorizava. Outro fator passou a ser o “grito”, no qual quem gritasse mais tinha uma prioridade maior. Além disso, como eram 8 níveis de prioridade, haviam muitas pendências com a mesma classificação, o que levava a equipe de desenvolvimento a ter que ler e escolher entre essas pendências de mesma prioridade. Com o passar do tempo, tudo estava tendendo a ser Urgente.

Do lado da equipe de desenvolvimento, começamos a notar uma grande insatisfação. Existia um sentimento de que estávamos resolvendo problemas muito pequenos ou específicos que só aconteceriam com a execução de uma sequência de passos muito rara, enquanto tinham problemas comum para vários usuários, que ao nosso ver, deveriam ter maior prioridade.

GUT

Nesse cenário, montamos um time para rever nossa priorização, liderados pelo então coordenador de QA, Sérgio Rocha. Ele havia conversado anteriormente com colaboradores de outras empresas da região para saber como eles tratavam a priorização de problemas, e nos trouxe o GUT (Gravidade, Urgência e Tendência) de uma dessas conversas com colaboradores da RD. O GUT, é uma forma simples de priorização, na qual é analisado e pontuado um problema nas categorias de Gravidade, Urgência e Tendência e com a combinação desses pontos se dá uma valor para priorização. Eles descreveram no post “como priorizar problemas em um cenário complexo” os métodos que usam para resolver a priorização de problemas na RD.

Aplicando e adaptando

Fizemos então um experimento de priorização com o GUT e tivemos resultado muito similar ao nosso problema inicial: Os resultados das priorizações variaram de acordo com quem classificou. Analisando essa situação, nós identificamos dois pontos. Primeiro, a descrição dos critérios ainda estava muito subjetiva; Segundo, as pessoas não estavam conseguindo compreender o que era a categoria de Tendência.

Para resolver o primeiro ponto, trocamos as descrições por exemplos de situações para cada nível das categorias. Mas tivemos muita dificuldade de definir os exemplos para os níveis de Urgência pois observamos que a urgência é uma grandeza mais do ponto de vista do cliente. Nesse ponto nós definimos exemplos de apenas para os 2 maiores níveis da Urgência, englobando caso excepcionais e já conhecidos como casos de extrema urgência e deixamos o range de 1 a 3 para o feeling de quem está priorizando, assim não descartando aquele momento de ouvir o coração do cliente externo/interno e entender esse problema no ponto de vista dele.

Quanto a Tendência, notamos que havia um melhor entendimento quando apresentamos como “chance do problema voltar a ocorrer”. Assim começamos a chamar o nosso modelo de priorização de GUCo (Gravidade, Urgência e Chance de ocorrer) . Validando essas alterações, tivemos um resultado muito melhor. As diferentes pessoas de diferentes setores da empresa (Suporte, Desenvolvimento, QA) avaliaram os mesmos problemas e tiveram resultados similares, que fomos alinhando com o passar do tempo.

Resultados

Hoje, alguns meses depois da nova priorização estar rodando podemos notar que os tipos de problemas mais prioritários mudaram. Passaram a ser mais prioritários problemas gerais do sistema, incluindo alguns mais complexos que os clientes estavam convivendo à anos, outros de desempenho e até de layout. Isso deu à equipe interna um renovação de ânimo, com um sentimento de estar resolvendo os problemas que dariam um melhor resultado.

Depois dessa primeira versão nossa priorização se transformou em um processo vivo, no qual caso surjam novos casos, que não estavam contemplados nos exemplos, é aberto uma discussão com a equipe sobre esse ponto, podendo gerar alterações. Isso já aconteceu algumas vezes desde que estamos rodando, e tem sido uma experiência muito boa.

Nossa “dor” atualmente com o resultado desse processo, tem sido o volume de problemas grandes/complexos, pois eles acabam levando mais tempo para serem resolvidos, assim travando ou diminuindo nossa velocidade de entrega. Atualmente estamos fazendo validações de possíveis soluções para esse problema. Mas isso é assunto para outro post.