O papel do Product Owner na qualidade do Produto

Muito é comentado sobre as responsabilidades e características do PO e qualidade de software. Entretanto, pude identificar que pouco é falado sobre o papel do Product Owner na qualidade do Produto.

A qualidade é imprescindível para qualquer produto, pois visa atender às necessidades e dores implícitas e explícitas dos diferentes usuários na melhor forma possível, de modo que seus objetivos sejam atingidos e suas necessidades sanadas.

Neste artigo vamos apresentar a definição de qualidade sob diversos pontos de vista, sua importância nas diferentes etapas do ciclo de desenvolvimento e a contribuição e responsabilidade do Dono do Produto neste assunto.

 

Definição de Qualidade

Não há maneira melhor de começar este post apresentando a definição de qualidade sob diversas óticas diferentes.

 

Assine nossa Newsletter e fique sempre atualizado com nossos artigos!

 

Segundo o dicionário:

Qualidade é um conceito subjetivo, é o modo de ser, é a propriedade de qualificar os mais diversos serviços, objetos, indivíduos etc.. Qualidade está relacionada às percepções de cada indivíduo e diversos fatores.

No que diz respeito à qualidade do produto no seu processo de desenvolvimento, podemos citar outras definições interessantes de Bartié:

Qualidade de software é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos… Qualidade não é uma fase do ciclo de desenvolvimento de software … é parte de todas as fases.

Segundo ainda a NBR ISO 8402:

O conceito de qualidade é “A totalidade das características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas”.

A Quality Assurance (Garantia da Qualidade) é definida como:

Profissional ou uma equipe que tem a função de garantir a qualidade no desenvolvimento de um produto. Sua atuação envolve a checagem do cumprimento de certos critérios e métodos ao longo dos processos operacionais.

Podemos então resumir a qualidade como o atendimento às necessidades implícitas e explícitas dos usuários na melhor forma possível, de modo que seus objetivos sejam atingidos através do seu produto utilizando técnicas, ações e controle em todas as fases de desenvolvimento.

Percepções de qualidade que Product Owner precisa compreender

Agora que tivemos um “banho” de definições do que é Qualidade, podemos então colher algumas percepções que Product Owner precisa entender:

• Subjetiva a cada usuário: a qualidade é subjetiva a cada usuário que interage e utiliza o produto, pois ela está relacionada ao atendimento de suas necessidades e sabemos que pessoas são complexas e diferentes a depender de sua persona.
• Processo sistemático que focaliza todas as etapas: é engano acharmos que a qualidade é somente responsabilidade do time de desenvolvimento. Sua necessidade e preocupação também se estende às fases e atividades do Dono do Produto.
• Cumprimento de certos critérios e métodos: uma vez que o time de desenvolvimento atua na criação de um produto visando um objetivo, os refinamentos levantados pelo Proprietário do Produto devem conter critérios bem definidos e detalhados para melhor clareza das ações.
• Satisfazer necessidades implícitas e explícitas: requisitos não funcionais devem ser tão bem pensados e priorizados no Backlog quantos os funcionais.

Veremos a seguir cada uma destas e outras percepções com mais detalhes.

 

A importância da análise na qualidade

O gráfico a seguir mostra uma análise bastante conhecida com relação ao custo relativo para corrigir um defeito:

As informações do gráfico comprovam que na etapa de análise, seja através do Product Discovery, Inception ou qualquer outro método de pesquisa e descoberta, é extremamente importante para a qualidade do produto.

Um levantamento de requisitos equivocado pode causar prejuízos financeiros, perda para concorrência e insatisfação de usuários. Criar mecanismos para garantir a qualidade de software evita uma série de transtornos após a implantação.

Pesquisas e levantamento de requisitos

Bastante conhecido na disciplina de UX Research ou na Engenharia de Requisitos, é um conjunto de técnicas que busca investigar com profundidade um assunto, problema, resposta e/ou situação ainda não conhecido.

Aplicando técnicas de pesquisa como entrevista com usuários, workshop, brainstorming ou colhendo feedback com a área de relacionamento, é possível capturar reais necessidades que, mais tarde, serão transformadas em solução.

Através das habilidades de comunicação e empática, o Product Owner precisa ter a capacidade de moderar as pesquisas, bem como levantar as dores dos usuários e gerar soluções. Tudo isso vai cooperar para melhor atingimento da qualidade do produto a ser desenvolvimento ou ajustado.

Identificação das personas e usuários

A etapa de análise também é o momento de mapear o público alvo do meu produto, bem como meus usuários e identificação das personas.

O mapeamento da jornada destes usuários, bem como seus gostos, costumes, fluxo de processo que ele fará antes, durante e após interação com a aplicação é importantíssimo na etapa de análise.

Já vimos por aqui que a qualidade é subjetiva a cada usuário que interage com o produto, pois está relacionada às percepções de cada indivíduo e diversos fatores. Por isso o PO precisa compreender muito bem cada persona e pensar em soluções que satisfaçam a maior parte delas.

 

A contribuição do PO na qualidade durante o desenvolvimento

O Dono do Produto também pode e deve contribuir na qualidade durante o momento de desenvolvimento. Vejamos como:

Refinamento

Seja através de histórias de usuários, documentos de requisitos ou caso de uso, é interessante que a descrição de cada parte do produto, bem como os critérios de aceite estejam bem definidos.

Para isto, é esperado que no planejamento da sprint os itens de refinamento prioritários estejam melhor refinados e sejam apresentados com bastante clareza. Se necessário, este refinamento pode ser melhor realizado durante o desenvolvimento caso hajam dúvidas ou pedido do time.

O refinamento bem realizados e estruturado pelo PO ajuda no melhor entendimento e, consequentemente, evita erros no desenvolvimento por mal interpretação. Tal refinamento é resultado de uma boa análise e pesquisa realizada anteriormente.

Comunicação e trabalho com o time de desenvolvimento

A comunicação é a principal habilidade necessária para o Dono do Produto. Portanto, praticá-la com excelência em todas as conversas com o time é imprescindível e necessário. Ruído na comunicação certamente gerará mal interpretação e poderá afetar o resultado da qualidade.

A colaboração e disponibilidade com o time de desenvolvimento também implica na qualidade, uma vez que o PO precisa estar disponível a quaisquer dúvidas da Squad, evitando assim retrabalhos e erros desnecessários no produto.

A participação do PO no dia a dia, dailys e colaboração ajuda na direção do time com relação ao objetivo da Sprint.

 

O papel do Dono do Produto nos testes e validações

Não importa se os usuários são internos ou externos, a homologação deve fazer parte das atividades do Proprietário do Produto antes que o resultado chegue aos seus usuários.

Revisão da Sprint

Na revisão da sprint, onde o time apresenta o resultado do trabalho realizado ao Product Owner, o PO pode e deve se atentar aos critérios de aceites vinculados às histórias visando atender às necessidades dos usuários.

Este é mais um momento para inspecionar o trabalho realizado, além de garantir mais um funil de qualidade antes do produto chegar nas mãos dos usuários.

Se o refinamento foi realizado com cuidado e houve sinergia durante o desenvolvimento, é bem provável que haja bem poucas (ou nenhuma) ‘surpresa’ durante a revisão.

Feedback com os usuários

A entrega de uma nova versão do produto ao público não é o último passo! Para assegurar a satisfação e obter novas percepções, é importante colher feedbacks dos usuários.

Lembremos que a qualidade está relacionada à conformidade com as exigências dos meus usuários através das soluções de suas dores e necessidades. Portanto, é importante que o PO identifique e valide se realmente tal dor foi mitigada/sanada.

Esse feedback pode ser através de pesquisas com formulários, utilização da funcionalidade, entrevistas ou análise dos comentários e sugestões sobre o Produto.

 

Conclusão

Qualidade do produto não é mais um diferencial nas empresas, mas sim uma obrigação. Entendemos que se trata de um pré-requisito para conseguir se manter no mercado competitivo com tantas outras opções incríveis de produtos.

Conseguimos apresentar que o Product Owner tem tanta responsabilidade no assunto quanto o time de desenvolvimento (ou mais). Isso porque a sua atuação na garantia da qualidade está em todas as etapas de desenvolvimento.

Fica claro que o PO precisa olhar também para as necessidades implícitas que certamente não são ditas pelos usuários – normalmente requisitos não funcionais (ex.: usabilidade, acessibilidade, durabilidade, conformidade, entre outros).

O Dono do Produto pode e deve olhar para o Backlog do Produto visando qualidade do produto, de modo a pensar na importância do refinamento, execução de PD e priorizar itens vindos dos feedbacks dos usuários, além de considerar requisitos não funcionais, bugs e débitos técnicos.

 

Referências

• https://www.significados.com.br/qualidade/
• https://blogdaqualidade.com.br/definicoes-de-qualidade-e-qualidade-de-produto/
• http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx
• https://kalendae.com.br/blog/quality-assurance/
• https://blog.zeev.it/qualidade-produto-qualidade-processo/