Como um PO deve lidar com os Bugs?
Bugs são sempre um problema na vida de um PO pois atrapalham a Sprint e seguram o desempenho do time. A verdade é que Bugs sempre surgirão, a grande questão é quais são as atitudes em que os POs devem tomar em relação a isso? Para responder esta pergunta devemos analisar alguns aspectos, como prioridade e causa dos bugs.
Prioridade
Quando o PO toma o conhecimento de algum Bug, o que deve ser feito? Eu gosto de olhar por outro ângulo, primeiro pense o que não deve ser feito imediatamente.
O PO não deve interromper o time de desenvolvimento imediatamente, pois se o time é interrompido então a performance será reduzida e o PO não tem informações suficientes neste momento para ajudar o time, em resumo, será uma bagunça.
O PO também não deve entrar em pânico, pois um Bug não determina que o time precisa atuar na solução deste imediatamente.
Um bom PO deve saber medir os riscos e entender o tamanho do problema, algumas perguntas que gosto de fazer antes de definir a prioridade dos bugs são:
- O que acontece se o problema continuar a existir? Com essa pergunta busco entender o real impacto, muitas vezes os stakeholders não tem essa resposta, no geral, isso significaria que não é um problema de alto impacto, pois quando é alto, as respostas são claras, por exemplo, se o problema continuar, os clientes não conseguem fazer nenhum pagamento.
- Quem é o público impactado? É importante entender quem de fato sofre com o Bug, pois pode ser um cenário que apenas um pequeno percentual sofre com isso. Por exemplo, em um e-commerce, o problema afeta apenas clientes que utilizam Internet Explorer, neste caso o PO deve pesquisar o percentual de clientes impactados.
- Como reproduzir o bug? O passo a passo para reproduzir o bug é primordial para facilitar a atuação, o PO não deve aceitar explicações superficial como “não funciona”, precisa de detalhes para entender melhor o cenário. Caso o bug não seja possível reproduzir, é preciso entender o impacto, pois não saber como reproduzir não quer dizer que seja uma exceção, a dúvida neste caso seria um problema.
Após a resposta de tais perguntas fica mais fácil entender quando o bug deve ser eliminado, assim definindo a prioridade de forma mais estruturada.
Quais são as possíveis causas dos bugs?
Os Bugs podem ocorrer por diversos motivos, por exemplos:
- Mudança não informada entre sistemas, por exemplo API
- Processo de qualidade frágil
- Critérios de aceitação incompletos
- Entre infinitas outras causas
Existem inúmeras situações onde tais bugs são criados, muitas destas não estão no controle do PO, porém há ações que o PO pode sim tomar para reduzir a quantidade de bugs, tais como:
- Sprint: qual o comprometimento da Sprint? Se o PO força o time a se comprometer com mais tarefas para satisfazer Stakeholders, tal satisfação pode ocorrer apenas no curto prazo, pois sobre pressão, a qualidade pode ser colocada em risco.
- Processo de qualidade: como as tarefas são desenvolvidas? O time tem tempo para fazer os testes unitários, automatizar os testes? Não é o trabalho do PO definir tal processo, porém é trabalho do PO respeitar e motivar que o processo de qualidade seja cada vez mais robusto, pois a qualidade do produto deve estar acima de tudo.
- Critérios de aceitação: quão preciso são os critérios de aceitação? O PO precisa mudar durante a Sprint? Se isso acontece, pode gerar mudanças no desenvolvimento de forma repentina e bugs podem ser causados.
Em resumo, um bom PO não interrompe o time de desenvolvimento para um Bug onde não tem todas as informações necessárias sobre tal. Um bom PO também preza a qualidade acima de quantidade, desta forma motivando o time a reforçar cada vez mais a qualidade das entregas.
Quer saber mais sobre este tema? Se inscreva em meu curso Como ser um Product Owner.
