O que o Product Owner não deve fazer?

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.

O que um Product Owner não pode fazer?

Qual o maior desafio do trabalho do Product Owner?

Quais são as responsabilidades de um Product Owner?

O que os desenvolvedores devem fazer se o Product Owner não estiver disponível?