Last updated on | FAQs, Product Owner

Agile Product Owner, o guia completo de tudo o que precisa de saber

by Luís Gonçalves
agile product owner

O Agile Product Owner (PO) é responsável por gerir o Product Backlog para alcançar o resultado desejado da equipa. O papel do Agile Product Owner é novo e crítico.

O Que é Um Agile Product Owner

Existem muitos papéis numa Equipa Scrum. Uma das funções, do Agile Product Owner (PO), é responsável pela gestão do Product Backlog para alcançar o resultado desejado da equipa. O papel do Agile Product Owner é significativo quando se trata de qualidade. Este é o único membro da equipa que tem o poder de aceitar qualquer história como está.

Para a maioria das empresas que mudam para Agile, a função de Agile Product Owner é nova e crítica. A maioria das empresas contrata um Agile Product Owner em período integral para dar suporte à Equipa Agile. As relações e responsabilidades do Agile Product Owner não são apenas significativas, mas estendem-se para além da equipa local. Também trabalham com o restante da equipa de gestão de projetos, clientes e partes interessadas.

O Agile Product Owner é um líder; normalmente, alguém com experiência em marketing, gestão de projetos ou conhecedor do mercado e dos seus utilizadores. Também devem ter uma compreensão clara da concorrência e das tendências futuras do domínio e tipo de sistemas que estão a ser desenvolvidos.

A função do Agile Product Owner foi criada inicialmente para lidar com os desafios enfrentados por muitas equipas Scrum. Muitas equipas tiveram dificuldade em escolher que direção tomar. Isto resultou na equipa em ter uma direção divergente, uma direção múltipla ou nenhuma direção.

O Agile Product Owner passa muito tempo com a equipa, esclarecendo os artigos do Product Backlog e decidindo que artigos fazer, com base nos detalhes do produto.

Dificuldades Comuns

Pode ser um desafio para alguém fazer o trabalho do Agile Product Owner. Devem tomar todas as decisões sobre o produto, conhecer as necessidades do negócio e passar um tempo considerável com a Equipa Scrum.

Devido à quantidade de trabalho envolvida, as responsabilidades são geralmente divididas igualmente entre muitos membros da equipa. As empresas estão a começar a usar mais uma equipa de valor para lidar com a carga de trabalho. Se, como proprietário de uma empresa, decidir usar esta abordagem, será necessário nomear um único tomador de decisões.

A proporção ideal do Agile Product Owner para a Equipa Scrum é de 1:1 – um Product Owner para uma Equipa Scrum. A proporção será violada se mais de uma equipa estiver a trabalhar no mesmo produto simultaneamente. O Agile Product Owner acaba por trabalhar com várias equipas. O problema com este modelo é que uma das equipas é frequentemente ignorada pelo Agile Product Owner.

Se o Agile Product Owner tiver muitas responsabilidades, este não estará prontamente disponível para a Equipa Scrum. Isto pode causar muitos problemas e atrasos na equipa, porque não podem responder às perguntas ou tomar decisões em tempo hábil. Isto é conhecido como Agile Product Owner ausente.

As equipas que precisam de um Agile Product Owner mais do que o que o Agile Product Owner pode entregar, podem nomear um Agile Product Owner representante. O Agile Product Owner representante pode ser indicado pelo proprietário ou pela equipa do produto atual.

No entanto, muitas equipas não gostam dessa abordagem porque o Agile Product Owner pode substituir as decisões do representante a qualquer momento. Geralmente, o Agile Product Owner real substitui o representante num momento inconveniente para a equipa.

Responsabilidades do Agile Product Owner

Os papéis e responsabilidades podem variar de um para o outro, dependendo do ambiente de produto e desenvolvimento, mas existem muitos fatores comuns para cada posição. Cada Agile Product Owner detém todas as responsabilidades, mas deve colaborar com a sua equipa e delegar a carga de trabalho de acordo com as necessidades desta.

Existem sete responsabilidades comuns de cada Agile Product Owner:

1.  Alinhamento na Visão

O Agile Product Owner é responsável por definir as metas e criar a visão da equipa. A visão precisa de ser claramente comunicada com todos os envolvidos no projeto, incluindo: a Equipa Scrum, as partes interessadas e a equipa de gestão de projetos. A visão é usada para priorizar e direcionar as decisões da equipa.

2. Gerir o Product Backlog

O Agile Product Owner gere a lista User Stories que precisam de ser feitas pela Equipa Scrum. Devem escrever os artigos do Agile Product Owner e os critérios de aceitação para cada um e, de seguida, solicitar o trabalho para garantir que a visão do produto foi cumprida.

O Product Backlog deve ser visível para que todos os envolvidos com a equipa possam vê-lo. Desta forma, o Agile Product Owner pode otimizar o desempenho do trabalho e garantir que os envolvidos compreendam claramente a estratégia e o roteiro de desenvolvimento.

Product Backlog é uma fonte viva que é continuamente atualizado. Mostra todo o trabalho a ser concluído durante o desenvolvimento. É usado para garantir que a equipa completa sempre as tarefas mais importantes de forma iterativa e incremental.

3. Deter as finanças

O Agile Product Owner é responsável por fornecer o melhor retorno do investimento. É responsável por todas as decisões económicas durante o lançamento e o nível de produto sprint. O triângulo de ferro de alcance – orçamento, tempo e qualidade – pode ser ajustado de acordo com a necessidade. O custo e o benefício de cada User Story do Product Backlog ambém podem ser usados para determinar a ordem do trabalho.

4. Responsabilidades de Equipa

O Agile Product Owner deve envolver a equipa scrum. Devem partilhar a visão da organização, responder às perguntas da equipa e ouvir sugestões sobre como adicionar, excluir, alterar ou melhorar a meta do utilizador. O Agile Product Owner motiva a equipa e procura feedback.

5. Definir Restrições

O Agile Product Owner também define os limites e restrições para atingir as metas. Restrições devem ser atingíveis. Podem incluir datas de conclusão de prazo, limitações de custo, limites de memória e mínimos de velocidade.

O Agile Product Owner deve ter cuidado para não estabelecer metas irrealistas ou tecnicamente impossíveis. Se algumas metas irrealistas forem enviadas, uma boa comunicação entre o utilizador, o representante do utilizador e a Equipa Scrum é a chave para a deteção precoce.

6. Priorização de Tarefas

Priorizar tarefas durante o sprint também é importante para atingir os objetivos da equipa. As equipas primeiro trabalham nos segmentos mais importantes. Quando estes são concluídos, podem liberar esses segmentos para o utilizador ou cliente. A segmentação de tarefas pode criar valores mais altos de produtos e resultados de ROI positivos. Também pode ajudar a colocar partes do produto no mercado mais cedo.

Projetos podem durar muito tempo; portanto, todo o feedback é importante. Seja bom ou mau, o feedback geralmente significa alterar, eliminar ou adicionar metas ao projeto. Como as alterações são feitas enquanto o projeto já está em andamento, os custos serão menores do que se o projeto já estivesse concluído.

7. Participação em Eventos de Desenvolvimento

O Agile Product Owner desempenha um papel importante no desenvolvimento de eventos, como Sprint Planning, Sprint Review, Agile Retrospectives e Daily Scrum.

Trabalham com as partes interessadas durante as atividades de planning para determinar quais etapas e conteúdos precisam de ser dados para entregar na próxima iteração, lançamento ou nível de produto e a próxima iteração.

Durante o Sprint Planning, o Agile Product Owner trabalha com a Equipa Scrum para definir, elaborar, estimar, ordenar e excluir artigos do Product Backlog.

Colaboram com a equipa para determinar as próximas ações necessárias para melhorar o trabalho. Durante o sprint, o Agile Product Owner trabalha com a Equipa Scrum; respondendo a perguntas e aceitando User stories prontas. No entanto, o Agile Product Owner é o único com autoridade para adicionar ou remover o trabalho, cancelar o sprint ou interromper o desenvolvimento do projeto.

Podem participar em scrums diários para coordenar e colaborar com a equipa no trabalho que está a ser realizado no sprint.

Características do Agile Product Owner

Os Agile Product Owners partilham cinco características comuns:

1.    Disponível e Envolvido

O Agile Product Owner está totalmente envolvido no projeto. Trabalha com a Equipa Scrum diariamente; responde a perguntas e está prontamente disponível quando surgem problemas que possam atrasar o projeto.

2.    Habilitado

A organização permite que o Agile Product Owner tome decisões e seja responsável pelas suas decisões. Todas as decisões devem ser tomadas ao nível do produto para manter a velocidade do desenvolvimento. A organização deve ter cuidado para não anular o Agile Product Owner ou correr o risco de a equipa ignorar a hierarquia da empresa.

3.    Decisivo

O Agile Product Owner deve responder às perguntas da equipa com rapidez e autoridade. Atrasos podem impedir que o trabalho seja concluído a tempo. Inverter as decisões anteriores vai criar falta de confiança.

O Agile Product Owner é o melhor papel para tomar decisões com base no conhecimento do cliente e no suporte das partes interessadas.

4.    Bom Domínio de Conhecimento

O Agile Product Owner entende as necessidades do cliente-alvo. Tem um sólido conhecimento de negócios para liderar o desenvolvimento de produtos da equipa e, ao mesmo tempo, coordenar todas as partes interessadas. Tem uma forte rede de suporte dentro da organização e pode desenvolver boas relações com clientes e fornecedores.

5.    Ótima Comunicação

O Agile Product Owner deve ser um excelente comunicador, colaborador e “pessoa de pessoas”. Pode partilhar a sua visão, alinhar pessoas, concentrar os seus esforços e motivar a equipa. A sua alta inteligência emocional ajuda a colaborar e orientar o desenvolvimento do produto para uma conclusão bem-sucedida.

7 Competências de um ótimo Agile Product Owner

Satisfazer o Cliente

Os Agile Product Owners não são apenas administradores, mas também satisfazem o cliente. Embora seja importante ouvir as partes interessadas e alterar as user stories em conformidade, também é importante ouvir o cliente e descobrir as suas necessidades.

Contador de Histórias

Grandes Agile Product Owners fazem mais do que apenas seguir a mecânica de adicionar uma história de utilizador no Product Backlog antes de enviá-la para os developers. Pensam em formas de transformar a história num recurso de produto que encante o utilizador.

Por exemplo, digamos que um artigo do Product Backlog  para uma empresa de partilha de boleias é enviar aos utilizadores um recibo por e-mail. O utilizador está ocupado? Precisa de criar um relatório de despesas no excel para o recibo? Existe informação adicional – método de pagamento, opções de documentos, localização de levantamento ou entrega, distância – que seria útil? Um ótimo Agile Product Owner olharia para a imagem mais ampla.

Sabe delegar

Para ser honesto, embora o papel de Agile Product Owner deva ser feito por uma pessoa na estrutura Scrum, é impossível que uma pessoa gira tudo. Se o trabalho começar a falhar, muitas equipas irão criar um papel paralelo adicional. Por exemplo, as equipas também podem adicionar um Agile Product Owner técnico para compensar o Agile Product Owner que não se vê como líder.

As equipas devem delegar e construir uma equipa informal útil se quiserem sobreviver e prosperar. Espere, isto soa como uma Equipa Scrum? Sim e não. Pode optar por incluir um Scrum Master e vários membros da Equipa Scrum, se quiser. Mas uma equipa separada e informal do Agile Product Owner vai ajudá-lo em várias responsabilidades, especialmente se não for um especialista em determinadas áreas.

Desenvolvedor

Não há nada de errado em dizer que é também um desenvolvedor. No Scrum, as equipas são apanhadas na delegação de funções. Embora seja útil para ensinar Scrum, nem sempre é útil. Os papéis podem facilmente tornar-se exagerados, afasta o foco do valor da entrega em relação a quem faz o quê.

No caso do Agile Product Owner, é fácil de pensar “Eu possuo o Product Backlog. Possuo as histórias do utilizador. Entrego-as à Equipa Scrum e eles desenvolvem-nas”. Isto pode ser verdade, mas ainda faz parte de uma equipa; não é apenas o líder da equipa.

Toda a equipa agrega valor. Quando vê o seu papel como um membro da equipa, orientando o resto dos membros relativamente ao que deve ser construído, a sua colaboração com os outros será mais saudável.

Agente de conhecimento

Enquanto é um desenvolvedor, também é um agente de conhecimento. Pode representar o Product Backlog e agir como interface entre a Equipa Scrum e as partes interessadas, mas não significa que é um especialista em todo o produto. Se os desenvolvedores estão a escrever código, estes podem não ir longe ao falar consigo.

Em vez disso, devem conversar com especialistas: os interessados que representam os utilizadores. Parte do seu trabalho é colaborar e capacitar os desenvolvedores, encontrar os especialistas certos para conversar. Se essas discussões resultarem em requisitos de mudança, deve ser mantido informado. Se isso não for viável, coloque os desenvolvedores no comando para que possam obter as informações necessárias.

Solucionador de conflitos

Qualquer pessoa que não consiga lidar com conflitos não deve ser Agile Product Owner. No desenvolvimento de produtos, vai lidar com situações inerentes e repletas de conflitos, especialmente quando as pessoas estão em conflito por recursos e políticas. Ter fortes competências de resolução de conflitos é importante para evitar que as disputas se intensifiquem.

Os Agile Product Owners devem ser corajosos, confiantes e capazes de lidar com situações difíceis. Devem saber que geralmente devem passar por algum conflito para chegarem a uma solução. Saber como mediar e colaborar irá minimizar a parte negativa.

Papel de “Escada-Rolante” Efetivo

Não importa o quão bom é na resolução de conflitos, em algum momento, terá de escalar uma situação na cadeia de comando. A escalada não está relacionada com disputas mesquinhas, é o feedback que a gestão deu em relação aos objetivos em conflito. Por exemplo, se duas partes interessadas atribuíram a mesma equipa a duas tarefas diferentes que não se encaixam, há conflito.

Os melhores Agile Product Owners já têm mecanismos de escalonamento de conflitos prontos. Embora, sem dúvida, tente resolver os conflitos da melhor maneira possível com as partes interessadas, ainda vai precisar das competências necessárias para subir e descer a cadeia de gestão. Em vez de esperar por uma crise, deve construir e testar o seu plano de escalonamento em antemão. Pode fazê-lo procurando oportunidades para aumentar rapidamente as interações pequenas e aplicáveis, para que domine as competências. Quando os grandes problemas acontecerem, estará pronto e confortável para lidar com isso.

Existem inúmeras competências que pode cultivar como Agile Product Owner. Mas essas sete qualidades dar-lhe-ão uma vantagem no seu papel.

Transformação Agile: Product Owner vs. Analista de Negócios

Um dos primeiros desafios que as empresas enfrentam quando se transformam em Agile é entender os novos papéis necessários para apoiar a iniciativa. A função de Product Owner é o conceito mais importante, porém o mais novo, para as empresas entenderem. Uma pergunta comum que as empresas costumam fazer é: “O que torna essa função de Product Owner diferente de um Analista de Negócios?” As diferenças entre as duas funções são importantes. Entender essas diferenças é fundamental para o seu sucesso.

A função de um Agile Product Owner é uma fusão de várias funções – representante comercial, analista de negócios, gestor de projeto e outras funções. Os papéis são combinados numa abordagem Scrum. Este é projetado para fornecer um nível de responsabilidade que de outra forma não existe.

Por ser um novo papel, é importante identificar as pessoas com potencial para desenvolver as competências necessárias para realizar o trabalho. Recomendo que escolha alguém do lado do negócio, não do lado de TI para preencher o papel. Deve escolher alguém que possa ser treinado em escrever histórias e definir os critérios de aceitação.

Também deve escolher alguém que tenha o apoio e a compreensão da gestão de que o comprometimento exigido para a função é muito maior do que qualquer coisa que já tenha experimentado anteriormente. Também gostaria de recomendar que o gestor transfira muitas das responsabilidades existentes da pessoa para a outra equipa.

Então, para quê treinar um Agile Product Owner para escrever histórias e definir critérios de aceitação quando já tem um Analista de Negócios que possui as mesmas competências? A resposta é responsabilidade. Quando um recurso comercial possui o conteúdo de cada sprint, não há ninguém para jogar o jogo da culpa, portanto, há menos atrito entre os gestores de TI e de projeto.

Desenvolver um papel, o responsável por aceitar as histórias, ninguém em TI tem autoridade para aceitar as histórias. Apenas o negócio em si pode decidir se o trabalho concluído é aceitável e se encaixa no propósito.

No Scrum, apenas uma pessoa é responsável por definir e aceitar histórias. E não posso enfatizar suficientemente a importância de não dividir essas responsabilidades.

Juntamente com a responsabilidade, a comunicação também é importante. Quando o Agile Product Owner é da empresa, há uma hipótese maior de que a comunicação entre os Agile Product Owners e os Gestores de Produto seja mais natural e fluida. Isto vai tornar mais fácil para a equipa resolver problemas, mantendo-se alinhada nas metas de negócios. Irá haver também menos surpresas durante as demonstrações sprint. Um Agile Product Owner pode literalmente “sentar-se” com a Equipa Scrum e depois reportar efetivamente ao Gestor de Produto; colmatar a lacuna entre os departamentos de negócios e de TI.

Quando a empresa está a trabalhar com o Agile Product Owner e o Analista de Negócios, estes podem ter uma perspetiva holística para a solução de problemas. O Agile Product Owner fornece uma abordagem de foco do utilizador, enquanto o Analista de Negócios usa o foco do sistema. O Agile Product Owner descobre o que o utilizador deseja e, de seguida, decide a melhor forma de fornecer o melhor valor, enquanto que o Analista de Negócios identifica os casos, condições de erro, dependências e impactos para outras áreas do sistema ou outros sistemas.

Não há dúvida de que o Analista de Negócios oferece grande valor à equipa, mas o Agile Product Owner deve manter direitos exclusivos para aceitar histórias e gerir prioridades para manter a responsabilidade.

Resumo

Como o Agile Product Owner é uma nova função para muitas organizações, recomendamos que identifique os indivíduos que possuem os atributos necessários para a função. Incluem: fortes competências de comunicação, bom senso comercial, capacidade de tomar decisões rápidas, base técnica e, o mais importante, alguém que possa desenvolver um nível de confiança tanto da equipa como da Gestão de Produto. Depois de identificar a pessoa certa, recomendo enviar o candidato para treino inicial, treino de ferramenta e treino contínuo.

Para que essa nova função seja bem-sucedida, toda a organização deve respeitar as decisões do Agile Product Owner. Todas as decisões devem estar visíveis nos pedidos de conteúdo e no Product Backlog.

Espero que esta publicação tenha mostrado as responsabilidades e competências claras de um Agile Product Owner. Se esta publicação tiver sido útil, partilhe-a com os seus amigos e colegas.

ORGANISATIONAL MASTERY SCORECARD

Desenvolvi um teste grátis que o vai ajudar a identificar que areas da sua organisação precisam de mais ajuda para alcançar excelência no seu processo de Product Development

Faça O Teste
Rate this post:
Luís Gonçalves

About Luís Gonçalves

https://plus.google.com/u/0/+LuisGonçalves1979

Luis Gonçalves is an Entrepreneur, Author & International Keynote Speaker. He works with Senior Executives to implement his ‘Organisational Mastery’ system so they can greatly increase the effectiveness and efficiency of their organisations; enabling them to become recognised and highly rewarded Leaders.

Comments

Share your point of view

X