[Bruno Mentges de Carvalho] Criando um Product Backlog, parte 1

Recentemente um dos nossos clientes internos na globo.com pediu para que nós os ajudássemos a elaborar um product backlog para uma nova versão de seu produto. Eu representando o lado técnico, um product owner, um arquiteto da informação e um designer fomos escolhidos para tal atividade.

Product backlog é um documento de alto nível do projeto. Nele é contido todas as features, wish-lists, etc. que o cliente deseja para o sistema descritas de uma maneira bem abrangente e na linguagem do cliente, que chamamos de “histórias”. Cada história contém também uma estimativa de complexidade e o valor de negócio da mesma para o cliente, para facilitar na priorização.

Um exemplo de uma história é o seguinte: “Para poder ter uma experiência melhor assistindo um vídeo, eu como usuário gostaria de poder assistir o vídeo em tela cheia“.

A primeira etapa foi marcar uma reunião com os envolvidos para ouvir deles o que eles tem hoje, o que os atrapalha, e o que eles querem para resolver seus problemas. Do ponto de vista técnico, que é o que vos apresento, o maior desafio é se ater ao “O QUÊ” ao invés do “COMO”. Ouvir o que eles querem fazer, o que eles precisam, o que os atrapalha, etc. Por vezes me peguei com vontade de perguntar se queriam isso dessa ou daquela forma, e precisei me conter para não tirar o foco da reunião.

Depois dessa reunião nós tivemos uma visão mais clara da necessidade de nossos futuros clientes e resolvemos reunir o time e conversar a respeito, visto que serão eles (e eu) que iremos desenvolver o produto. Essa reunião foi muito produtiva pois levantou diversos pontos que ainda precisavam ser trabalhados.

Já aí temos alguns pontos desse nosso processo:

1. Se reunir com o time do cliente e o cliente e ouvir deles os “o quês
2. Se reunir com o seu time e discutir os pontos levantados
3. Marcar uma reunião com o cliente e o time do cliente para dar este primeiro feedback.

Como podemos ver, a presença do cliente é fundamental. E esse ciclo de reuniões já produz um primeiro feedback. Tivemos uma nova reunião para passar o feedback e atacar os pontos levantados. Tudo isso foi feito em menos de uma semana, o que é o mote das práticas ágeis: ciclos curtos de feedback.

A partir destes 3 pontos já é possível rascunhar um primeiro product backlog. E, como seguimos o scrum e práticas ágeis, isso não é nenhum problema, pois o product backlog é aberto e modificável.

Essa foi a parte 1 do processo de criação do product backlog. Em breve estarei escrevendo o próximo da série, enquanto avançamos com a criação product backlog.