Destrinchando as funções de P.O. — parte 1

P.O. (Product Owner) e Scrum Master são papéis muito importantes dentro do Scrum, um framework bastante adotado em gerenciamento de projetos de alta complexidade. Tenho dois profissionais como referência aqui no Brasil quando o assunto é Scrum e metodologias ágeis: Annelise Gripp e Jorge Audy. Fora do Brasil, minha maior fonte de aprendizado tem sido o blog do Scrum ORG, que, apesar de estar em inglês, recomendo muito a leitura.

Tenho estudado bastante tópicos e queria compartilhar algumas coisas muito interessantes que tenho encontrado enquanto procuro entender de forma mais profunda a atuação da P.O. e da Scrum Master dentro de uma equipe.

Reforço para que sua pesquisa não fique restrita apenas a este artigo: leia o blog da Annelise Gripp, do Jorge Audy e do Scrum ORG, além do manual do Scrum que você pode baixar gratuitamente pelo Scrum Guides (inclusive em português!) e muito importante: procure oportunidades para exercitar o que aprender, mas sempre com muita humildade, viu? Scrum nos dá ferramentas, não razão. Nesse sentido, os hackathons me ajudaram demais, pois foram as primeiras oportunidades que tive para ser P.O. de projetos.

Para que este artigo não fique gigantesco — e você não desista de ler — vou dividi-lo em partes. Para começar, vamos abordar algumas das funções da P.O.

Product Owner — P.O. (parte 1)

De forma resumida, a P.O. (ou em português, a pessoa dona do produto)num projeto Scrum é responsável pelo relacionamento com as parte interessadas dentro do projeto, garantindo que a comunicação dos requisitos, funcionalidades e critérios de aceitação cheguem de forma clara e que sejam devidamente atendidos durante a execução das tarefas pela equipe de desenvolvimento Scrum.

E como uma P.O. faz o seu trabalho?

Vou relacionar as atividades principais da forma que eu as conheço e que as aplico hoje na equipe de produto da Shawee e que aplicava quando participava de hackathons como P.O. Este artigo é um documento vivo, caso sintam falta de algo, coloquem nos comentários que eu complementarei com os devidos créditos.

Antes que a equipe comece a trabalhar, precisa saber o que é necessário para criar um produto mínimo viável daquele projeto para começar a receber feedbacks. Através destes feedbacks, teremos novas histórias de usuários e novos requisitos para trabalhar, tendo em vista sempre o que vai agregar o valor mais alto possível para as partes interessadas.

Sabemos que a P.O. deve manter o backlog sempre priorizado, mas, vamos olhar com mais detalhes: quando se fala de priorização, não é apenas organizar as histórias da mais urgente para a menos urgente, mas também garantir que as histórias com mais urgência tenham o máximo de detalhes possível e estejam prontas para desenvolvimento. A essa atividade damos o nome de refinamento de backlog.

Mas as coisas na vida real não são tão lineares como gostaríamos. Estou falando da eterna luta de equilíbrio entre os requisitos funcionais e os não-funcionais na priorização, pois, embora os requisitos não funcionais sejam vitais para fazer uma aplicação ser coesa, segura e escalável, por outro lado, temos os requisitos funcionais que são o que mais salta aos olhos das partes interessadas.

Neste momento, a P.O. vai ouvir a equipe e entender a necessidade de suas solicitações em relação a definição de quais histórias trabalhar primeiro e passar esses argumentos da melhor forma para as partes interessadas (que muitas vezes, não são da área de tecnologia e não entendem porque um banco de dados precisa ficar pronto antes de uma função de login, por exemplo). É muito importante que a P.O. tenha boas skills de negociação, porque vai usa-las muito e precisará desenvolve-las cada vez mais, já que nem todas as conversas com partes interessadas são tranquilas.

Acompanhe a continuação aqui.