Quando o Product Owner escuta pela primeira vez: o que é mais importante para entregar nesse primeiro ciclo de release? A resposta clássica é “o software inteiro”.
Uma das principais dificuldades que um PO encontra ao priorizar seu backlog nas primeiras vezes está ligado ao seu desejo de apresentar o produto completo para seus clientes.
Imagine a situação de um produto que controla venda de tickets de eventos musicais. O sistema é pensado e acessado da seguinte maneira:
Um administrador cadastra eventos, o usuário final busca um evento, se cadastra no site, escolhe a cadeira – se possível, efetua o pagamento e finalmente imprime o ingresso.
A clássica abordagem seria priorizar o backlog da seguinte maneira:
1. cadastro de administrador do sistema
2. gerenciamento de eventos (cadastra, remove, atualiza, cadastra cadeiras marcadas)
3. busca de eventos
4. cadastro de usuários e comentários para eventos
5. escolha de cadeiras
6. receber pagamentos
7. emissão de bilhetes
Para fins didáticos, supondo uma necessidade uniforme de 3 semanas para a execução de qualquer história, o PO só possui um site que agrega valor a sua empresa no final de 4 meses e 2 semanas, e com suporte a emissão automática após 5 meses e 1 semana.
Somente no final desse período ele terá feedback dos usuários finais, aqueles que se comportam de maneira imprevisível e detectam bugs que não imaginávamos existir.
O que aconteceu? As histórias foram priorizadas de acordo com o momento em que elas aparecem no fluxo de acesso ao software.
Mas precisamos mesmo de todas essas histórias completas para entregar valor ao nosso PO e consequentemente permitir o uso do software pelo cliente?
Note que uma outra priorização também é possível:
1. criação e atualização de eventos com senha master (1.5)
2. busca de eventos (3)
3. cadastro de usuários e comentários para eventos (3)
4. receber pagamentos (3)
5. emissão de bilhetes (3)
6. cadastro de cadeiras para eventos (1.5)
7. escolha de cadeiras (3)
. cadastro de administrador do sistema
. remoção de eventos
Com essa priorização, temos:
~1 mês: um site de busca de eventos
~2 meses: um site colaborativo de eventos
~2 meses e meio: as vendas online iniciam
~3 meses: emissão de bilhetes online revoluciona o mercado
3 meses e meio: escolha de cadeiras online revoluciona o mercado
Note que o próprio desenvolvimento passa a ser pago pelas vendas que foram geradas após 2 meses e meio.
Por não tentar seguir o fluxo do usuário em um sistema mas sim entregar funcionalidades que o mesmo pode utilizar desde o início, o PO e sua empresa ganham uma vantagem competitiva muito forte.
Quando seus concorrentes entregarem o sistema, a empresa que utilizou a segunda priorização já possui uma comunidade de usuários forte, um sistema com menos bugs, e gerando dinheiro há algum tempo.
A segunda empresa obteve retorno real 50% mais rápido que a primeira.
Crie histórias e priorize-as para entregar sempre algo utilizável, não crie e priorize para entregar tudo. A criação de seu backlog e a priorização é fundamental para sua posição no mercado, seja você uma empresa de produtos ou web 2.0.
E você, possui outras dicas de criação e priorização?
5 05UTC março 05UTC 2010 às 13:53
Bom começo…continue
5 05UTC março 05UTC 2010 às 16:40
É triste ver que muitas empresas que se dizem na onda ágil adotam tal roupagem, mas continuam tratando as entregas como um “set” de funcionalidades sem exercício efetivo do negócio.
Parabéns Guilherme!
Simples, curto, objetivo e didático
6 06UTC março 06UTC 2010 às 18:56
Post fenomenal. Qualquer um entende, mesmo não sendo programador. Espalhei para um monte de gente
9 09UTC março 09UTC 2010 às 12:03
[...] Rodrigo Yoshima « Como criar e priorizar um backlog [...]
9 09UTC março 09UTC 2010 às 14:14
Muito bom o post Guilherme.
Para quem quer trabalhar de forma ágil e agregar valor ao seu sistema tem que priorizar aquilo que é mais importante para o cliente.
Deixar se cair no waterfall de fato não é legal.
12 12UTC março 12UTC 2010 às 22:27
[...] Como criar e priorizar um backlog – Guilherme Silveira (Agile no mundo real); [...]
14 14UTC março 14UTC 2010 às 18:38
[...] Como criar e priorizar um backlog – Guilherme Silveira (Agile no mundo real); [...]
19 19UTC abril 19UTC 2010 às 21:58
[...] Uma forma de enxergar que devemos melhorar o processo de desenvolvimento é verificar que perdemos dinheiro ao tomar decisões ou muito cedo, ou tarde demais. [...]
22 22UTC abril 22UTC 2010 às 4:40
Legal o exemplo (posso usar nos meus treinamentos?)!
A grande quebra de paradigma da priorização é que antes nós, desenvolvedores, é que ditávamos a ordem com que as coisas tinham que ser feitas segundo critérios técnicos. Agora quem prioriza é o cliente (ou o PO) segundo critérios do negócio. “Nós” passamos essa responsabilidade para “eles”, porém a gente tem que ficar de olho se estão fazendo bom uso…
[]s,
Rodrigo de Toledo
22 22UTC abril 22UTC 2010 às 4:55
Muito boa visão Guilherme!
Gosto muito da questão que o pessoal da 37Signals usa em referências do Basecamp, em que a parte de billing foi implementada depois da ferramenta estar disponível para os usuários comprarem.
Como o processo de billing só devia ocorrer depois de 30 dias do primeiro cliente ter entrado, porque vamos priorizar antes?
Seguindo na onda do que foi apresentado no post, poderíamos entrar em uma questão de análise de risco, valor de negócio e outras mil variáveis para classificar e ordenar um backlog.
Só que eu continuo sempre achando que a priorização deve ser a que permitir entregar o software mais cedo em produção. Chegando neste caso no que você fala, a partir de 2 meses e meio o projeto de software começa a se pagar sozinho.
E aí chegamos na simplicidade, que é a quantidade de software que você não precisa fazer para ter um produto funcionando na mão.
Parabéns novamente.
22 22UTC abril 22UTC 2010 às 13:23
acho q isto poderia ser interessante para ir um passo mais para frente!
http://bit.ly/5l6X1
http://oreil.ly/13EPgd
http://bit.ly/580Rjq
9 09UTC dezembro 09UTC 2010 às 3:09
Didático, fácil entendimento.
8 08UTC abril 08UTC 2011 às 13:22
Hey very cool site!! Man .. Beautiful .. Amazing .. I’ll bookmark your site and take the feeds also…I’m happy to find a lot of useful info here in the post, we need work out more strategies in this regard, thanks for sharing. . . . . .
18 18UTC abril 18UTC 2011 às 11:14
My spouse and i genuinely like what we publish here. Rather new along with wise. A single dilemma however. I’m operating Chrome using Debian along with components of your respective existing theme bits can be a minor wonky. My spouse and i know it’s not only a usual build. However it’s a little something for you to preserve in mind. My spouse and i hope who’s will certainly support along with continue to keep up the top notch good quality producing.
24 24UTC agosto 24UTC 2011 às 7:12
Long time I’ve been looking for the notes about it. Finally, I managed to get the point – thank to your post. Thanks a lot and keep posting!
1 01UTC setembro 01UTC 2011 às 15:58
Long time I’ve been looking for information about it. Finally, I found the point – thank to your article. Well, thank you and good luck!