Episódio 37: PBB – Quem participa, exemplos de aplicação e papel do agilista

15 set 2022 | Podcast

> Ouça este episódio

Eu sou o Paulo Caroli e este é o Podcast Mínimo Viável, onde compartilho conhecimento sobre as novas relações de trabalho e, assim, contribuo para a transformação de um mundo melhor.

Neste episódio do Podcast Mínimo Viável, os treinadores da Caroli.org, Ademir Silva, Luis Buchelli, Teo Inke e Vinicius Nakamura compartilham muito conhecimento sobre o Product Backlog Building (PBB). Além de abordar quem são os participantes das sessões, eles falam sobre o papel do agilista nesse processo e trazem exemplos de aplicação desse importante método criado por Fábio Aguiar.

Vinicius Nakamura: A gente tem a pergunta um do Nilton aqui que é: Quem participa do PBB? Se tivermos muitas pessoas, a dinâmica não corre o risco de ficar complexa e o objetivo ser desviado?

Ademir Silva: Vou pegar a parte fácil de quem participa. Quem participa, assim, vou pegar um pouco da minha experiência, então, analista de negócio, Product Owner ali, eu acho que para quem está começando a carreira como Product Owner é uma excelente ferramenta para você atuar ali como pessoa facilitadora, para extrair as histórias que você vai trabalhar, enfim, pode ser PO, Scrum Master, mas é um trabalho que você faz facilmente para ter um backlog pronto pro time trabalhar, tendo a participação de todo mundo.

Então, analista de negócio, PO, Scrum Master, o time de desenvolvimento, com certeza, representante de cliente direto ou o próprio cliente pode estar ali também né, sponsor falando da expectativa ali no início, talvez tenha um sponsor que está falando ali suas expectativas, os problemas que ele viu, então, isso é bacana também.

Pessoas de UX, às vezes, também é legal ter, participam ali, definição de persona o que a gente sabe. Se você pensar num passo a passo, também a pessoa tem que pensar um pouquinho de jornada, conectar isso também com uma jornada. É o que eu mais vejo de pessoas que participam de sessões como essa.

Teo Inke: A outra resposta é sim né, se fica difícil? Acho que fica, mas, assim, eu acho que, complementando o Ademir, é importante ter todos esses skills, principalmente, esses skills que estão dentro do time ou que estão suportando um time. Acho que UX é muito legal ter.

Aí, eu acho que talvez o foco até da pergunta seja, poxa, e o pessoal de negócios? Stakeholders, pessoas que não participam do processo do desenvolvimento daquele produto? Participam ou não? Eu vou colocar minha opinião aqui: cara, dependendo do tipo de stakeholder, eu limitaria a parte esquerda aqui do Canvas. Problemas e expectativas em alto nível, beleza, ainda dá para incluir.

Agora, quando a gente entra ali para personas e começa a descer, aí, talvez, comece a tumultuar, se tiver muita gente, então, eu limitaria. Depende muito de perfil para perfil, mas eu, geralmente, sigo essa linha de: pessoas de negócios, quando entra na persona, já é um negócio um pouco mais do time. Se o time tem um conhecimento mínimo ali, se tem uma pessoa de UX, que conhece da persona, aí nem precisa mais das pessoas de negócio.
Daqui o time segue sozinho. Essa é, geralmente, a minha linha para não ter muito tumulto nessas sessões.

Ademir Silva: Quanto à questão de não tornar a dinâmica complexa, aí é técnica de facilitação. Então assim, você pode separar grupo por persona, seguindo essa linha de um grupo trabalha com persona, o outro depois apresenta e isso vai tornar o trabalho complexo, vai levar mais tempo, né? Porque têm dois grupos tentando se alinhar, né?

A gente vai ter que convergir, então, isso vai tornar um pouco da dinâmica mais complexa, mas exige algumas técnicas de facilitação, tá? Mas, assim, ao mesmo tempo, você pensa assim: o fluxo de construção desse backlog dado pelo processo do PBB, ele já induz a gente a construir junto. Então assim, sejam ali dois grupos, vou pensar em dois ali. A persona 1 tem alguma coisa, uma funcionalidade que todo mundo viu, tem a oportunidade de falar também, mas, assim, vamos chamar de coordenação né para compartilhar o que foi construído, tá? Então, você adicionaria um passinho a mais ali, eu acho.

Vinicius Nakamura: Quando a gente aplica o PBB hoje dentro dos nossos contextos? Por exemplo, eu já apliquei o PBB em algo que estava sendo melhorado. Então, um sistema, que já estava em execução, só que ele ia ser refeito de uma outra maneira. A gente fez o PBB desde o começo, passando por todas as etapas, problemas, expectativas para fazer esse alinhamento.

Então, nesse contexto, funcionou muito bem para algo que já existia, mas que a gente fez uma melhoria, uma renovação desse sistema. E, atualmente, eu tenho feito muito, porque entrei num contexto em que as funcionalidades já estavam levantadas para o ano inteiro. Isso é incrível, mas estavam e tudo bem, né, por quê?

Porque a gente olha para cada uma delas, coloca dentro do Canvas quais são as funcionalidades e quem eu estou atendendo, que é a minha persona, e eu consigo visualizar e, aí, eu consigo conversar um pouquinho mais sobre o que é essa funcionalidade, como que a minha persona vai utilizar ela e, a partir daí, eu consigo levantar os meus PBIs.

Ou seja, eu não necessariamente precisei passar pelo problema e expectativa, né? Eu pude já, já que eu tenho todas as funcionalidades levantadas, nós elencamos uma parte delas, tipo 5 a 10 funcionalidades e a gente levantou quais são os PBIs e aí a gente faz isso de uma forma dinâmica, conforme a gente levanta, vai levantando os PBIs, vai refinando, vai colocando dentro das sprints, trazendo para as plannings e desenvolvendo dentro sprints e, ao longo disso, a gente já vai, também, puxando mais funcionalidades, vai retroalimentando o nosso backlog.

Olha a funcionalidade, levanta os PBIs, refinamento e vai retroalimentando. Então, isso é um fluxo, é um ciclo que não se acaba. Vai estar sempre vivo esse backlog, enquanto tiver existência do produto, esse backlog vai existir e a gente vai sempre estar retroalimentando ele com coisas novas, com personas novas, com funcionalidades novas ou melhorias dessas funcionalidades ou mesmo de novos PBIs que possam surgir dentro de uma funcionalidade. Esses são os dois cenários que eu já atuei com o PBB.

Ademir Silva: Acho que acabei trabalhando com um contexto parecido, sim, acho que foi a época em que eu mais executei workshops de PBB. Era um cliente que estava indo para a transformação ágil, digital etc e ele já tinha uma área de PO muito boa assim. E, então, os projetos que estavam acontecendo já estavam planejados há um ano, no mínimo. Tinha projeto até com planejamento de dois anos.

Então, a partir de agora, X projetos vão encaixar num modelo ágil. E aí foi uma oportunidade que eu vi ali de como é que eu encaixo, não jogo fora todo o trabalho que foi realizado ali de descoberta, de definição, alguma coisa que já existia e trago de forma mais, eu vou usar o termo enxuto assim, o que a gente vai ser trabalhado aqui por esse time com o que já tem.

Aí, ou os projetos estavam começando e eu realinhava, construía um backlog com o PBB para ser iniciado com o time ágil ou continuidade de um projeto que estava acontecendo. A partir de agora, vamos organizar o que já tem pronto, vamos alinhar expectativas e aí a ideia do uso de expectativas foi direcionado para outro sentido ali.

Não era mais sobre o que era que estava sendo desenvolvido. As expectativas a partir de agora o que seria feito e tal. Então, foi um nível mais técnico de expectativa ali, porque as coisas já estavam acontecendo e tinha um legado, os problemas começam a surgir, então, foi um outro uso, que a gente acabou usando ali. Fora do normal, que seria ali o início de um projeto já ágil, que a gente vê aí como mais comum no mercado.

Teo Inke: Tem área que eu possa compartilhar, que é interessante e é assim: vamos lá, a gente pode falar do mundo bonito e a gente pode falar do cenário real, que a gente olha produtos muito complexos, com legado e tal.

Eu tive um cenário em que eu fiz uma atuação pontual num cliente, uma empresa de saúde. O cenário era: tinha alguns times para fazer uma entrega, que tinha uma data fixa, que foi estipulado por alguém e o pessoal estava lá perdido. Eu usei o PBB como pano de fundo para alinhar esses times.

Eu acabei fazendo, não foi uma sessão de PBB com o time, mas foi sessões com os POs para a gente usar o PBB Canvas como pano de fundo para entender: para essa release aqui, para essa migração que eles estavam fazendo, o que a gente precisa? E aí, você vai ver, o backlog estava muito pulverizado, porque tem coisa, um monte de coisa de sistemas diferentes, pedidos daqui, de lá e tal, diretorias e tal.

E aí eu falei, galera, vamos lá, features para esse produto, para essa entrega aqui… o que precisa? Aí, a gente foi colocando, mapeando e tal. Com isso, gerou um foco, entre no caso os três times, eles já tinham até PBIs, só que eles estavam meio perdidos na parte ali das features. Então, o PBB ajudou muito para dar o foco para o pessoal, que falou: beleza, essa daqui entrega, isso aqui tem essa data fim, cara, vamos seguir assim.

Aí, o time foi se alinhando e conseguiu entregar ali praticamente tudo que estava querendo lá, prometendo. Mas, foi interessante para fazer essa engenharia reversa e eu acho que essa é a forma que eu acabo mais atuando. Fazer uma engenharia reversa de, cara, como é que está o backlog hoje? Beleza, vamos pegar esse backlog, jogar, transpor para um PBB Canvas e entender cadê os user story mapping aqui, a gente está conectando as coisas com as personas? A gente sabe quem são as personas?

Esse negócio aqui estranho, isso aqui é do nosso time mesmo, é desse produto? Aí começam aquelas perguntas… hmmm… pera aí, é porque me pediam e começa a tentar dar aquele foco, que eu estava comentando o foco no customer centric ali para você olhar de fato a persona. Aí, você consegue blindar um time, digamos assim, de outras demandas que ficam ali soltas e que, às vezes, não agregam tanto valor.

Luis Buchelli: Eu queria ressaltar que um cenário muito propício para você manter esses artefatos do PBB é quando você já está em andamento do desenvolvimento do seu produto. Como o Teo comentou, né, junto com o andamento, você vai conseguir retroalimentar tudo o que você trabalhou no PBB.

Então, eventualmente, podem aparecer novos PBIs que você não tinha identificado previamente e aí você consegue fazer essa, vamos dizer, engenharia reversa de voltar para seu PBB Canvas e analisar ali onde que esse PBI vai se encaixar, se é que já existe uma funcionalidade que vai é suportar esse PBI.

Se não existir a funcionalidade, você vai precisar criar uma funcionalidade e linkar essa funcionalidade a uma persona. Sempre nessa linha de estar sempre orientado ao usuário, ao cliente e se, eventualmente, inclusive aqui o Product Backlog Item que não pertence a uma funcionalidade existente, nem a uma persona que você tinha mapeado, identificado previamente, você terá que também que criar dentro do seu PBB Canvas essa persona, embaixo dessa persona a funcionalidade correspondente e, embaixo, encaixar esse PBI.

Então, o PBB ele não vai ser útil apenas na construção inicial do seu backlog de produto, mas você pode acabar utilizando o PBB Canvas como uma forma de manter, atualizar e evoluir seu backlog ao longo do ciclo de vida do seu produto também.

Vinicius Nakamura: Perfeito Luis, então, isso aí é bem bacana, porque não é só a construção, mas, também, a atualização, a manutenção, a retroalimentação e o PBB dá para ser utilizado também.

Pessoal, o Afonso trouxe uma pergunta aqui: Consigo aplicar o PBB para qualquer modelo de negócio? Ou seja, não só para TI, é isso Afonso? Não sei se é isso que você quis perguntar.

Ademir Silva: Cara, eu acho que sim, acho que entendimento é assim, você pode usar com o quê? Voltando para aquilo que a gente conversou: eu tenho persona, eu tenho um problema, eu tenho expectativa em torno de um contexto? Eu consigo aplicar esse negócio aí e sair com uma lista de coisas para fazer. Então, assim, se ele se encaixa? Sim, muitos contextos entram aí, né?

Vinicius Nakamura: É, eu pensaria da seguinte forma: modelo de negócio, tudo bem, eu tenho um modelo de negócio, mas qual é o produto que eu estou entregando dentro desse modelo de negócio? Eu traria um pouquinho mais para dentro para poder aplicar o PBB. Aí, se for para pensar em modelo de negócio, eu já usaria o BMC (Business Model Canvas) com Value Proposition Design para isso.

Teo Inke: Eu diria que assim: independente do modelo de negócio, se você tem algum produto, o produto você consegue usar o PBB. Eu acho que, assim, minha percepção. Eu acho que, até adiantando um pouquinho da outra pergunta, quando não usar o PBB? Cara, se você não tem um produto bem definido, se você atende, se você não consegue planejar para ter esse produto, aí, talvez não seja o cenário. Então eu iria por esse caminho.

Vinicius Nakamura: Como vocês enxergam o papel do agilista na construção do PBB?

Ademir Silva: Acho que, na maioria das vezes em que eu apliquei PBB, foi nesse papel de agilista. Uma das características é a de ser um facilitador ali entre o time técnico, o time de negócios, o stakeholder. É uma ferramenta para você conectar ali. Acho que é uma boa ferramenta para ter um leque.

Teo Inke: Outro contexto, também, acabei habilitando como PO ou PM de um time, aí você apresenta a técnica e a própria pessoa faz ali um rascunho, ou pouquinho do backlog e depois leva para o time. Acho que não tem problema nenhum também. Acho que o agilista vai fomentar essa prática para que o time trabalhe com o backlog de uma forma mais efetiva.

Ademir Silva: Sendo um agilista mais efetivo, né? Transferindo conhecimento.

Vinicius Nakamura: Temos aqui a última pergunta de um rapaz que está com uma dúvida muito grande. Esse cara, ele quer saber por que devo usar o PBB? Ele deve estar interessado em fazer talvez o treinamento com a gente aí, o Fábio Aguiar. Por que devo usar o PBB, pessoal?

Acho que a gente falou um pouquinho do porque aqui ao longo da nossa conversa. Apesar do jargão nosso que é um workshop colaborativo e efetivo para criar um backlog, eu entendo que por que usar o PBB?

Porque ele alinha as pessoas de uma forma muito colaborativa a entender o que realmente precisa ser desenvolvido e escrever bem direitinho a história, entender e ter bem priorizado aquilo que realmente traz valor para o negócio, valor para o cliente, o que não é mais um desejo e, sim, aquilo que realmente atende uma necessidade e resolve um problema. Então, essa é minha opinião sobre por que usar o PBB, para construir e fazer a manutenção do backlog.

Ademir Silva: Eu acho que a mesma sequência daquela pergunta né, quando eu tenho um produto para desenvolver e eu quero sair do outro lado com um backlog. Eu acho que é isso, é quando eu precisar um PBB para sair de uma ideia e ter um backlog para começar um trabalho é quando eu uso ali o PBB.

Teo Inke: A resposta concisa é assim: se você quer ter um backlog mais efetivo, eu acho que o PBB pode te ajudar muito nisso.

E aqui o episódio de hoje. Espero que você tenha gostado. Eu te peço para se inscrever e recomendar esse Podcast na sua plataforma de Podcast preferida, como Spotify e YouTube, e nas redes sociais. Ou, como eu prefiro: recomende aos seus amigos. Assim, você me ajuda com a missão de compartilhar conhecimento sobre as novas relações de trabalho, de forma a contribuir para a transformação de um mundo melhor.

> Esse Podcast não tem patrocinadores. Então, se você vem curtindo esse Podcast e quer colaborar com a nossa equipe, vá em www.mepagaumcafe.com.br/caroli. Muito obrigado!

 

Notas do episódio:

Quer aprender mais sobre o PBB? Confira a agenda com as próximas turmas do Treinamento
Adquira o livro Product Backlog Building: Um Guia Prático para Criação e Refinamento de Backlog para Produtos de Sucesso clicando aqui
Assista à íntegra do Webinar sobre PBB 

 

Caroli.org

A Caroli.org, com um excelente time e a integração de pessoas autoras, treinadoras, parceiras e demais colaboradoras, tem como missão principal compartilhar conhecimento e, dessa forma, contribuir para a transformação de um mundo melhor. Veja mais detalhes sobre nossos Treinamentos autorais e exclusivos, nossos Livros e muitos outros conteúdos em nosso Blog.
Episódio 39: Gestão de Inovação e Lean Inception

Episódio 39: Gestão de Inovação e Lean Inception

Neste episódio do Podcast Mínimo Viável, os profissionais Edson Antonio de Lima, Eduardo Prista e Mateo Fernández abordam o tema de Gestão de Inovação e Lean Inception. Eles respondem, ainda, se o uso da Lean Inception é mais adequado para produtos novos ou para features de produtos já existentes e se é na Lean Inception de onde surgem as ideias de inovação.

ler mais
Episódio 38: Qual a diferença entre Lean Inception, Design Thinking e Design Sprint?

Episódio 38: Qual a diferença entre Lean Inception, Design Thinking e Design Sprint?

Neste episódio do Podcast Mínimo Viável, você vai conferir um excelente bate-papo entre os profissionais Cristiane ‘Coca’ Pitzer, Luis Buchelli, Renato Borba e Vanderley Gomes, oportunidade em que abordam as principais diferenças entre Lean Inception, Design Thinking e Design Sprint e trazem exemplos de aplicação da Lean Inception em áreas que vão além da tecnologia da informação.

ler mais
Episódio 36: Filosofando sobre Produto Mínimo Viável

Episódio 36: Filosofando sobre Produto Mínimo Viável

Neste episódio, o criador da Lean Inception, Paulo Caroli, apresenta um Diagrama de Venn, onde aborda a relação entre teorias de filósofos sobre como verificar que uma “verdade é realmente verdadeira” e a questão de suposições e validações ao se definir o Produto Mínimo Viável (MVP).

ler mais

Pin It on Pinterest

X
X
X