Scrum: o dia a dia de um Product Owner

No time Scrum, o product owner (PO) tem o papel de definir junto com os stakeholders os objetivos do produto e o que será construído. Cabendo a ele o dever de priorizar as funcionalidades que vão gerar mais valor para o cliente e descartar aquelas com pouco valor. É uma tarefa difícil e a palavra que o PO mais diz no seu dia a dia é “Não”!

Isso acontece porque todos os dias recebemos várias idéias espetaculares de melhorias, mas que em sua maioria não possuem nenhuma base científica (métricas para suportar a idéia) ou simplesmente não estão alinhadas com os objetivos do negócio. Por isso, todo PO deve entender quais são os business goals do projeto, independente do estágio (inicial ou em desenvolvimento). Neste post iremos abordar as etapas de identificação dos business goals, sessão de product discovery, definição do roadmap, backlog, criação das user stories e teste de hipóteses.

Business goals, como defini-lo?

Através das 4 perguntas é possível definir os objetivos do produto que iremos construir.

1) Qual o problema que o produto pretende resolver?

ex: relacionar pessoas, facilitar a venda de produtos naturais, oferecer hospedagem em qualquer lugar do mundo….

2) Quais são os objetivos de negócio?

ex: criar uma comunidade de pessoas baseada em seus gostos, ofertar produtos veganos para um público premium, facilitar a busca por hotéis em lugares inóspitos.

3) Quem é nosso usuário e como ele se beneficia do produto?

ex: compartilhar momentos da sua vida como amigos, compra de alimentos que atendam suas necessidades, hotéis para todos os gostos e bolsos.

4) Como definimos e medimos nosso sucesso?

ex: quantidade de usuários, crescimento da base, taxa de retorno de usuários, taxa de conversão

As respostas a essas perguntas são fundamentais para o entendimento do produto a ser criado e para o alinhamento com os stakeholders. É uma boa prática, avaliar com futuros usuários se realmente as respostas das perguntas 1 e 3 geram o valor esperado por ele. Isso pode ser feito através de perguntas simples e objetivas, mas sempre evitando guiar a resposta do entrevistado. É possível encontrar benefícios escondidos que gerariam um valor adicional ao nosso produto.

Product Discovery, criando o user story map

Com o entendimento do produto, o próximo passo é realizar a sessão de product discovery junto com a equipe para criar o user story map. O objetivo de criar o user story map é ter a visão de todas as atividades que o usuário irá realizar com o produto, definindo suas tarefas e sub-tarefas para atingir os goals. Com essa visão conseguimos definir:

• 1) O nossoMVP, ou seja, quais são as funcionalidades necessárias para atendermos às necessidades dos usuários
• 2) Desenvolver as funcionalidades que representarão 80% da receita do produto
• 3) Criar um macro planejamento para o segundo release, que provavelemente será alterado com os inputs do MVP
• 4) Definir o Roadmap do produto

Roadmap

O product discovery nos ajudou a criar uma visão geral do produto, mas é o Roadmap do produto que irá definir a direção a ser seguida. O roadmap é o mapa do projeto, ou seja, o caminho que iremos trilhar até chegar ao seus objetivos de negócio, definindo com base nas estimativas quais as futuras entregas do produto.

O Roadmap pode apontar a direção dos próximos 3 a 6 meses. Roadmaps de 3 meses são mais fáceis de gerenciar, sendo mais tangíveis e menos propensos a erros de estimativa, gerando menos expectativa no cliente. Além disso, é mais simples mudar a direção devido a eventuais mudanças de escopo ou necessidades vistas com mais urgência ao longo do tempo, em um roadmap menor.

Backlog

O backlog do produto é uma lista de user stories que serão priorizadas nos sprints, sua ordenação deve ser da mais prioritária para a menos prioritária. A função do time é decidir quais delas cabem no sprint. Além de user stories, o backlog também contém os bugs, trabalho técnico (instalação de um novo framework para desenvolvimento, criação de ambiente de DEV, QA, PRODUÇÃO) e dos estudos técnicos (estudo de qual tecnologia é mais apropriada para o problema).

É uma prática interessante não incluir apenas user stories no sprint, mas balanceá-lo com bugs, trabalho técnico e estudos técnicos, evitando assim otechnical debt.

Criando User stories

A user story define como o usuário irá interagir com o sistema para atingir seus objetivos. É importante frisar que muitas histórias estarão em alto nível no backlog (histórias onde não há definição completa de todos os casos de aceite) e que a cadasprint será feito o refinamento da definição de pronto e de sua complexidade. Existem vários métodos para estimar uma user story comoFibonnaci ou P-M-G. Essa estimativa deve ser feita sem pressão e oScrum Master deve criar um clima no time que incoraje a discussão, para se ter a melhor estimativa possível. Uma dica, evite ter histórias com complexidade alta, a chance de ocorrerem erros na estimativa é maior.

Um exemplo de user story:

Como gerente de vendas, quero saber quais produtos são os mais vendidos, para que seja controlar melhor seu estoque.

De onde podemos derivar o modelo:

Como (ator), [xxxxxxxxxxx].

Quero [xxxxxxxxxxxx].

Objetivo [xxxxxxxxxxxx].

Testando hipóteses do produto

As user stories são excelentes para determinarmos os requisitos/funcionalidades do sistema que serão desenvolvidas e como elas atendem aos nossos usuários. Contudo, existem casos em que não temos certeza de que determinada funcionalidade irá gerar valor para o cliente, ou, no melhor dos casos, que o benefício gerado pela funcionalidade compense o custo de desenvolvimento. Por isso trabalharmos com hipóteses.

Um exemplo de hipótese:

Nós acreditamos que se aumentarmos as imagens dos quartos do hotel na página de hotéis, [como resultado] iremos aumentar o número de vendas (conversão). E teremos certeza de seu sucesso caso as vendas aumentem em 5% com os produtos testados no prazo de 1 semana.

De onde podemos derivar o modelo:

Nós acreditamos [xxxxxxxxxxxxxxxxxxxx].

Como resultado, [xxxxxxxxxxxxxxxxx].

E teremos certeza de seu sucesso [xxxxxxxxxxxxx].

Hipóteses devem ser testadas, para isso deve-se investir o menor esforço possível em seu desenvolvimento. Um exemplo disso é criar funcionalidades “fakes” para uma parcela de usuários. Existem excelentes ferramentas para teste A/B, como optimizely, que exige quase nenhum desenvolvimento para teste de hipóteses.

Neste texto abordamos algumas ferramentas que podem ser utilizadas pelo PO em seu dia a dia, deve ficar claro que adapções ao processos são sempre bem vindos. Cada time Scrum deve procurar a melhor maneira de trabalhar para entregar valor para o cliente no menor tempo possível. Lembre-se,Individuals and interactions over processes and tools.

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.