Desmistificando o Product Owner

Guia do artigo:

• O que é um Product Owner?
• Deveres do Product Owner
• Como agregar valor ao projeto?
• A fórmula para o sucesso

O Scrum é um conjunto disperso de diretrizes que regem o processo de desenvolvimento de um projeto, desde a fase de concepção até a sua conclusão. Esse framework tem por objetivo determinar um processo de desenvolvimento iterativo e incremental, além de ser uma metodologia disciplinada que possibilita o desenvolvimento controlado do sistema. Esta metodologia proporciona ainda uma melhor capacidade de adaptação e uma maior produtividade dos recursos.

No Scrum, destaca-se o papel doProduct Owner, o qual tem atraído muito interesse e controvérsias. Algumas pessoas acreditam que se esteja reformulando o Gerente de Projetos tradicional; outras acham que é um líder dentro da equipe ou que ele pode assumir o papel de Gerente de Projetos; outras pessoas dizem ainda que é um papel de ajudante, não tendo responsabilidades sobre o projeto.

O co-fundador do Scrum, Ken Schwaber, escreveu a seguinte afirmação acerca do Product Owner no Guia Scrum: O Product Owner é a única pessoa responsável pela gestão do Product Backlog, permitindo estar visível para todos, e visa garantir a importância da equipe (Edição de Maio de 2009, p. 5). Esta definição parece bastante inofensiva, até se considerar suas implicações. Ela exige que o Product Owner ajude a identificar e descrever os requisitos e garanta que o Product Backlog esteja pronto para a próxima reunião de planejamento da Sprint. Isso também significa que o Product Owner tem que se envolver no planejamento e mapeamento dos requisitos do produto, decidindo o que irá compor a release, fornecendo feedback para a equipe, além de gerenciar clientes, usuários e outras partes interessadas.

As diferentes responsabilidades fazem do Product Owner um papel desafiador e que compartilha algumas tarefas tradicionalmente atribuídas a um profissional de marketing, Gerente de Produto ou Gerente de Projeto. Mas não se engane, por mais tentador que seja, não se deve comparar o Product Owner aos papéis tradicionais. O Product Owner é um papel novo, que tem toda a autoridade perante o projeto, sendo ele o responsável pelo seu sucesso ou fracasso. Tem-se uma dependência da natureza e do tamanho do projeto, da fase do ciclo de vida em que o projeto se encontra, entre outros fatores, ou seja, é completamente mutável. Por exemplo, um Product Owner responsável por um novo projeto constituído de software e hardware deverá ter competências diferentes de alguém que esteja liderando o esforço para melhorar uma aplicação web. De modo semelhante, um Product Owner que trabalha em um projeto Scrum relativamente grande, requer habilidades diferentes das de um Product Owner que colabora com uma equipe de pequeno porte.

Com base nisso, quem deve desempenhar o papel de Product Owner? Para grandes projetos, o Product Owner é tipicamente um representante do cliente. Uma pessoa ligada ao cliente tende a assumir o papel quando o produto está sendo desenvolvido para uma organização específica, por exemplo, um cliente externo, que exige uma solução de novo aplicativo para um sistema legado, ou um cliente interno (por exemplo, o departamento de marketing), pedindo uma atualização do site web. Algumas pessoas envolvidas com o projeto como clientes, usuários, gerentes de projeto, analistas de negócios e arquitetos podem preencher o papel de Product Owner em circunstâncias peculiares, apesar de não ser aconselhável.

O que é um Product Owner?

Ser o Product Owner não significa realizar tudo sozinho. O Product Owner é parte da equipe Scrum e colabora estreitamente com os demais membros, sendo responsável por garantir que o trabalho vislumbrado seja realizado, além de necessitar do apoio dos demais membros da equipe em relação a dependências de funcionalidades ou questões tecnológicas.

Diante deste contexto, pretende-se, ao longo deste artigo, expressar as dificuldades enfrentadas pelo papel do Product Owner e quais características levam a pessoa responsável por esse papel a ter uma maior desenvoltura ao longo das etapas de desenvolvimento do projeto, realizando a interação com todos os membros envolvidos.

Deveres do Product Owner

O Product Owner deve ser decisivo e possuir não só a responsabilidade, mas também a autoridade para determinar a prioridade do trabalho da equipe do projeto que está sendo desenvolvido. O Product Owner também deve proteger constantemente os interesses do cliente em termos de funcionalidade, além de mantê-lo ciente de todas as etapas do projeto. Dessa forma, surgem como foco deste papel as necessidades do cliente, o sucesso do projeto e a colaboração entre os membros envolvidos.

Como já informado, o Product Owner é responsável por compreender e comunicar as necessidades do cliente. Pode-se visualizá-lo como um empreendedor, alguém que desenvolve e comunica a visão do produto sempre agregando valor ao projeto. O Product Owner completa o backlog e refina o seu conteúdo de forma contínua, visando que novos requisitos sejam adicionados e os existentes sejam refinados antes da próxima reunião de planejamento da Sprint. Além disso, ele deve priorizar o Product Backlog, garantindo que a equipe trabalhe com os requisitos mais importantes.

O sucesso do projeto é a segunda área de competência do Product Owner. Isso inclui a realização dos objetivos do projeto e os objetivos financeiros (como o retorno sobre o investimento, Return of Investment). O Product Owner ainda decide sobre a ordem de desenvolvimento das funcionalidades e as datas das releases, a fim de maximizar a satisfação do cliente e o ROI. Ademais, também é responsável por criar e atualizar o Product Backlog e os relatórios das releases.

Por último, mas não menos importante, o Product Owner colabora com a equipe interagindo com as partes interessadas em todo o processo. Assim ele mantém o foco na colaboração, e, também, visa o esclarecimento das dúvidas quando consultado, além de elaborar a reunião de planejamento da Sprint.

Como agregar valor ao projeto?

Algumas organizações têm dificuldade em encontrar a pessoa certa para desempenhar o papel de Product Owner. Por causa disso, elas dividem as responsabilidades desse papel para vários indivíduos. Por exemplo, um gerente de projeto assume a responsabilidade de cuidar das necessidades do cliente e o ScrumMaster se torna responsável pelo sucesso do projeto e da colaboração, misturando conceitos e metodologias. Ao cair nessa armadilha, as empresas perdem parte do potencial da função do Product Owner e uma grande chance de mudar (para melhor) o desenvolvimento do projeto. Ter várias pessoas praticando o papel do Product Owner só faz sentido quando existem várias equipes trabalhando no mesmo projeto. Neste caso, se tende a trabalhar com uma equipe de Product Owners e uma única pessoa responsável por todo o projeto (às vezes chamado de Product Owner chefe).

Existem, também, problemas decorrentes da união do papel de ScrumMaster com o Product Owner. No Scrum o Product Owner fica responsável por conceitos e ideias (ex: o Backlog), enquanto o ScrumMaster é responsável pela execução e qualidade do projeto. O Product Owner quer mais funcionalidades, enquanto o ScrumMaster está focado na execução e conclusão, e em fazer as coisas acontecerem. Deste modo, essa combinação de papéis não é recomendada, uma vez que é necessário ter uma pessoa com habilidades únicas para assumir tal responsabilidade, o que é bastante difícil de ocorrer.

Outro erro comum é ter um desenvolvedor ocupando o papel de Product Owner. Isso geralmente sinaliza que as pessoas da gerência do cliente não estão dispostas a assumir as responsabilidades do Product Owner. Caso isso ocorra, o potencial desta função se perde, as necessidades dos clientes já não são entendidas e as mudanças necessárias na colaboração entre a área comercial e a área de desenvolvimento não acontece. Desta forma, é provável que o setor comercial entregue os requisitos e em seguida se retire do processo de desenvolvimento, pois não estarão comprometidos com o projeto.

E, finalmente, existem Product Owners que apenas estão disponíveis em pequenos intervalos de tempo e se limitam a realizar o planejamento da Sprint e as reuniões de revisão. Este tipo de pessoa encontrará dificuldades para dirigir e guiar ativamente o projeto. Os problemas que surgem só serão resolvidos pelas suposições e hipóteses do ScrumMaster e da equipe. Não importa o motivo – excesso de trabalho ou ter outras prioridades –, o Product Owner não estar disponível afetará negativamente a liberação da release, o desenvolvimento dos itens do backlog, o feedback para as partes interessadas e o projeto como um todo, inclusive colocando em risco a sua execução.

Acerca dessas considerações, surgem algumas recomendações sobre o que não fazer quando se é um Product Owner:

• Ser mais focado em pessoas do que no Produto. O Product Owner tem que ser mais centrado no produto;
• Não ser capaz de gerenciar a expectativa das partes interessadas. O Product Owner tem que entender e gerenciar as expectativas e prioridades das partes interessadas e agir em conformidade para que isso ocorra. Qualquer falha em fazê-lo pode direcionar a equipe para um caminho indesejado;
• Deixar de comunicar a visão do produto. O Product Owner é o mais importante elo entre o cliente e a equipe. Ele deve garantir que a equipe entenda e trabalhe solucionar os itens da Sprint;
• Deixar de comunicar a realidade às partes interessadas. O Product Owner comunica a realidade do projeto, o seu progresso, os gargalos e qualquer outra informação relevante para o cliente e outras partes interessadas;
• Estar desconectado da equipe. Se o Product Owner tiver, por muitas vezes, o foco direcionado para diferentes finalidades que não estejam relacionadas ao projeto, ele não será capaz de participar regularmente das atividades da equipe e das reuniões de planejamento;
• Deixar de se envolver no projeto. O Product Owner tem que se envolver em todas as atividades da equipe e em suas interações com o cliente. Se ele não está envolvido com a equipe, o projeto tende a fracassar. Da mesma forma, se ele está muito envolvido com o projeto, sem estar disponível para o cliente, este perde o contato com o status do projeto;
• Estar indisponível. Se o Product Owner ficar indisponível por longos períodos de tempo, as decisões que devem ser tomadas por esse papel podem atrasar o projeto e as atividades da equipe;
• Não possuir poderes para solucionar qualquer problema dentro do projeto. Existem várias decisões de negócio que o Product Owner deve tomar. Se ele não tem esse poder, o projeto não irá progredir corretamente;
• Ter problemas em priorizar e refinar as necessidades do cliente. O Product Backlog é um artefato importante gerido pelo Product Owner, que precisa entender as necessidades e prioridades do cliente e, continuamente, aprimorá-las de acordo com as circunstâncias.

A fórmula para o sucesso

De que forma pode-se evitar os problemas descritos anteriormente e ter sucesso na implementação deste papel? Bom, existem diversas responsabilidades e funcionalidades que, se bem empregadas, podem agregar valor ao papel do Product Owner, como a de ser concedido o poder de decisão para a realização do seu trabalho (Empowerment­­ – ver Nota DevMan 1). O indivíduo deve ter tempo suficiente para fazer o trabalho, e deve ser devidamente qualificado. Se o Product Owner participa de um projeto importante, este papel deve ser patrocinado diretamente pela alta administração da empresa. Além disso, o Product Owner deve participar ativamente da definição da meta de cada release. Isto permite que ele se responsabilize por alcançar as metas estipuladas.

Esse termo significa ter a autoridade para tomar decisões e assumir a responsabilidade por suas consequências. Trata-se de ser capaz de tomar decisões rapidamente, sem ser necessário obter a aprovação da gerência. Há empresas que subestimam a importância do papel do Product Owner e, como resultado, não concedem autoridade suficiente, podendo tornar o papel inoperante.

Ser um bom Product Owner requer uma grande variedade de habilidades, dentre elas realizar a análise de processos de negócios, a análise de requisitos, o gerenciamento do ciclo de vida do produto, o gerenciamento de configuração, o marketing organizacional, a gestão do desenvolvimento, entre outras atividades. No desenvolvimento tradicional, cada uma dessas atividades pode ser realizada como funções individuais, mas o Scrum requer alguma proficiência nos conceitos e práticas envolvidos e a consciência para solicitar apoio quando necessário.

Ser o Product Owner é ter um comprometimento em tempo integral. Em grandes projetos, com várias equipes, é razoável dividir o trabalho em um Product Owner “estratégico”, incumbido de manter a visão do produto e executar o planejamento das releases com todas as equipes, e um Product Owner “tático”, engajado com a equipe encarregada de elaborar soluções para os problemas decorrentes do projeto, proporcionando feedback diário para as partes interessadas.

Decorrente desta divisão, as habilidades necessárias e o nível de comprometimento são os fatores que geralmente proíbem ou dificultam que pessoas do lado do cliente se tornem bons Product Owners. Se o cliente não possui uma pessoa com capacidade de determinar uma lista dos itens que estão a ser entregues ou se esta pessoa não pode se comprometer a auxiliar a equipe em um nível que permita a entrega rápida, então ela não é adequada para esse papel.

Ter as características e virtudes adequadas sugere duas coisas: conhecimento profundo das necessidades do cliente e uma noção teórico/prática da metodologia ágil Scrum. A este último, inclui-se a capacidade de aplicar práticas relevantes, tais como elaborar e priorizar o Product Backlog de ​​forma eficaz.

Acerca dessas características, destacam-se algumas responsabilidades e qualidades essenciais a um bom Product Owner, a fim de auxiliar a boa execução do projeto e manter as equipes eficientes:

• Analisar problemas de negócio e transformá-los em histórias significativas;
• Possuir capacidade de comunicação com todos os membros (internos ou externos) do projeto;
• Trabalhar com vendas e marketing visando obter ideias para o backlog;
• Participar das reuniões diárias, reuniões de planejamento da Sprint, revisões de Sprint e retrospectivas;
• Envolver o cliente e as partes interessadas para garantir que a equipe esteja construindo o produto certo;
• Facilitar e influenciar o trabalho sem repressão ou ditando regras;
• Criar e manter o Product Backlog;
• Priorizar as sequências do Backlog de ​​acordo com o valor do negócio e/ou ROI;
• Inspecionar o andamento do projeto ao final de cada Sprint e ter total autoridade para aceitar ou rejeitar o trabalho realizado;
• Não deve ter medo de tomar decisões difíceis.

Conclusão

Não há dúvidas, a implantação do papel de Product Owner pode ser difícil, mas tê-lo no projeto é essencial para uma adoção com sucesso do Scrum. Portanto, resista à tentação de ajustar esse papel, enfraquecendo-o para que ele possa se tornar mais fácil de ser aplicado. Em vez disso, use todos os esforços para promover as mudanças organizacionais necessárias para ajudar a empresa a melhorar, fazendo com que ela possa usar este papel para obter uma vantagem competitiva. Realizar todas as alterações necessárias provavelmente será uma tarefa difícil, mas vale o esforço pelos ganhos que este papel incorpora ao projeto.

Guia Completo de Scrum

Guia

Curso Gerência de Projetos

Curso

Curso de Scrum

Curso