Mai 15th, 2008
Product Owner: Um de$graçado ganancio$o
Há algum tempo atrás eu e o Alexandre Magno discutimos sobre o papel do Product Owner dentro do Scrum. Essa discussão rolou na lista Scrum-Brasil, segue o link:
http://br.groups.yahoo.com/group/scrum-brasil/message/470
Se você não estiver a fim de ver este link, veja os pontos de vista abaixo:
Você (Magno) já havia defendido aqui que você não enxerga o PO como diretamente o cliente. Eu já acho ótimo quando o PO é alguém do lado sponsor. Eu vejo que é melhor que o custo do PO não seja custo direto do desenvolvimento. Eu vejo que o PO é mais próximo do cliente presente do XP. Na minha experiência, não achei bom as vezes que o PO era diretamente “da própria organização” do time. Um bom PO é formado a partir da experiência de pagar a conta. Rodrigo Yoshima
Eu realmente gosto do PO junto ao time…conhecendo muito do cliente (e negócio) sim, mas bem envolvido com Scrum e com o projeto. Algo similar ao papel de “Gerente de Produto” que existe hoje na maioria das empresas que produzem algo através de projetos. Alexandre Magno
Antes de mais nada nossas visões não são diametralmente opostas. O ponto é que “daonde sai o dinheiro” e quem está no controle disso pode fazer uma grande diferença para o projeto.
O Product Owner é um papel difícil de encontrar. Todos os projetos que participei salvo duas excessões tive problemas com os Product Owners. Alguns eram moscas mortas. Outros se sentiam como Gerentes de Projeto. Outros se metiam nas coisas técnicas. Além desses problemas, esses Product Owners não tinham um compromisso com sua maior responsabilidade: O ROI do projeto (return on investment ou retorno sobre o investimento). Esses Product Owners problemáticos eram da mesma organização da equipe técnica (Team Role), isto é, eles eram “colegas de trabalho”. Eu realmente acredito que a falta de compromisso com o ROI era por conta dessa proximidade com a equipe.
É muito impressionante ver a falta de compromisso que os projetos em geral tem com o ROI. Ora, ninguém investe dinheiro para perder dinheiro. É estranho ver que o empresariado não enxergou que fábricas de software e consultorias montam contratos que estão se lixando para o ROI e para o sucesso do cliente. Quando um empresário faz um investimento qualquer, como um dono de uma gráfica que compra uma impressora off-set ou um fazendeiro que compra uma ceifadeira, ele sabe que aquele investimento terá um retorno. Isso significa mais páginas impressas ou mais sacas colhidas. Infelizmente muitos empresários estão bem insatisfeitos com o retorno oferecido por soluções de software. Isso se deve a maneira que o software é contratado. Fábricas de Software e Consultorias em Geral não dão a mínima importância se o projeto vai ou não colocar dinheiro no bolso do cliente. O escopo de um projeto para esses fornecedores é implementar requisitos e não dar soluções para problemas de negócio. Geralmente um requisito levantado e implementado não necessariamente resolve um problema de negócio. Requisitos são abstrações. Essa é a maior razão de trabalharmos de maneira iterativa seguindo princípios ágeis. Quem desenvolve um projeto de maneira iterativa quer solucionar os reais problemas de negócio do cliente e não simplesmente implementar requisitos. O mercado em geral adota um processo cascata e não iterativo. Eles caem no conto que requisitos traduzem as necessidades de negócio.
Quando se fala em ROI sempre pensamos em risco e ganho. A melhor literatura nesse aspecto são Os Axiomas de Zurique. Considero “Os Axiomas” uma literatura imprescindível para os brasileiros. Apesar de toda a nossa criatividade não somos treinados em nossas famílias e nossas escolas a correr riscos para ganhar mais.
O Scrum é uma metodologia guiada pelo ROI. Todos os projetos têm risco. Mas se você se focar em ter ganhos rápidos esses riscos podem ser minimizados pois você obtém retorno. Se você pegar o “Agile Project Management with Scrum” você encontrará:
O Product Owner obtém o financiamento no início e durante o projeto, criando os principais requisitos iniciais, os objetivos de retorno sobre investimento (ROI) e o planejamento dos releases. Ken Schwaber
Essas colocação do Ken Schwaber nos dá boas dicas que financiamento e ROI são as tônicas do dia-a-dia do Product Owner. Minha pergunta é: Num projeto outsourcing ou fábrica será que um Product Owner do lado do fornecedor terá um sentimento de financiamento e ROI à flor da pele? Creio que não! Só o cliente tem (ou deveria ter) uma completa visão de investimento, risco e benefício. Outro questionamento: Será que o cliente permitirá que um Product Owner do lado fornecedor represente diante do projeto TODOS os outros stakeholders?
Pegando novamente a literatura do Ken Schwaber, a maioria das vezes que ele fala a respeito do Product Owner ele diz “maximize de value of the project”. Quando ele diz isso não creio que ele esteja falando de um software bonito, nem um software funcional, nem um software implementado na melhor tecnologia. Esse “value” é bufunfa, cascaio, grana, money. Lembre-se: ninguém em sã consciência investe para perder dinheiro. O Software tem que dar lucro.
Desculpe se isso pode ofender alguém, mas lembre-se que estamos inseridos em um contexto capitalista moderno: O Product Owner deve ser um desgraçado ganancioso. Se você não concorda e acha o lucro ruim mude-se para Cuba ou Coréia do Norte enquanto esses regimes ainda existem.
Waren Buffet, Bill Gates e George Soros seriam bons Product Owners. Veja outros aqui.
Infelizmente os exemplos de Product Owner que o Ken Schwaber lista em sua obra não são exemplos de outsourcing. São softwares feitos “em casa”. Porém, o Geoff da MegaFund, um gerente de produto, “queria que o XFlow se tornasse COMERCIALMENTE viável externamente” (página 59). Não creio que ele quisesse dar este software de graça. O Michel, da TechCore, usou o Scrum para “ver que o verdadeiro DINHEIRO seria ganho focando a atenção no desenvolvimento do produto” (páginas 60 e 61). Michel negou a oferta de mais de MEIO BILHÃO de dólares pela sua companhia porque achou que poderia ganhar mais (e ao fim, ganhou 1.43 bilhões com o software). Esses caras não me parecem ter sentimentos comunistas. Esses caras são direcionados pelo ROI.
Pode parecer que não, porém, ter um Product Owner que de fato está financiando o projeto e que só pensa em ROI é muito saudável para o projeto. Ele aceita a iteratividade porque quer ter retorno rápido. Ele quer agilidade pois tem um mercado a atender (e dinheiro a ganhar). Ele quer participar ativamente pois é o dinheiro dele que está sendo investido alí. Quando você foca no ROI besteiras e desperdícios caem por terra. Se este Product Owner representar um grupo de stakeholders, as briginhas comuns que ocorrem entre eles são facilmente resolvidas colocando o dinheiro em primeiro lugar: será que aquele relatório que o estoquista pediu é de fato importante?
O Product Owner não pode ter mais apego à equipe técnica (Team) do que ele tem pelo dinheiro (creio que esta é a maior razão para que o Product Owner não seja da mesma empresa que a equipe).
OK!!! Talvez chamá-lo de “desgraçado ganancioso” seja forte demais. Usei este termo com objetivos didáticos para que você não esqueça as motivações deste importante papel do Scrum. São elas que fazem o Scrum funcionar. Agora, o fato dele ter foco em ROI não pode atrapalhar o trabalho da equipe. Ele não deve pressionar a equipe e as regras do Scrum SEMPRE devem ser seguidas. O Product Owner não pode se meter no dia-a-dia técnico. A equipe dá o prazo e deve ter tranquilidade para trabalhar. Garantir que o processo funcione é papel do ScrumMaster.
Outro ponto é que nem sempre é possível ter um Product Owner no lado do cliente. Não são regras que estou definindo aqui. É possível ter bons Product Owners na visão do Alexandre Magno. Ele até pode cumprir seu papel com relação ao ROI, mas dificilmente será um desgraçado ganancioso de fato. Entre esses dois tipos, eu fico com o De$graçado.
Enviar por e-mail | Hits para esta publicação: 1144
Boa
Também concordo com o seu ponto de vista Rodrigo.
Aqui na empresa a pessoa que faz o papel de “PO” já foi da equipe tecnica e hoje vive se metendo em detalhes tecnicos do projeto quando na verdade deveria se preocupar com outras coisas !
Abraços !
Fala Rodrigo, post legal heim
Bom, não vou me estender muito aqui…até porque estou no momento escrevendo um artigo exatamente sobre isso, sobre quem é o Product Owner.
Veja, entendo sua posição, mas acho o termo “desgraçado ganancioso” - sei que foi uso didático - um pouco forte para alguém que está inserido em uma equipe Scrum, que prega uma mudança comportamental em todos que estão envolvidos no projeto. Lendo seu artigo eu fui remetido a uma visão do comportamento atual dos nossos clientes, que querem “competir” com o fornecedor. Garantir o ROI não necessariamente é isto, não é “tirar mais” do time.
Acho que, tranquilamente, a empresa fornecedora pode ter sim funcionários preocupados - de verdade - com o ROI do cliente…na verdade isso já existe em muitas e muitas empresas aqui mesmo no Brasil.
Ter apego ao time…cara, isso novamente é uma questão de mudança comportamental e não de “quem vai exercer o cargo de PO”. Se não houver mudança comportamental, o PO do fornecedor vai puxar a sardinha pra cá, e o PO do cliente vai puxar a sardinha pra lá…e o Scrum Team? como que fica?
Eu sempre considero as duas opções e, como já manifestei, prefiro um PO aqui, “cheirando” agilidade diariamente, isso vai fazê-lo ter um comportamento adequado. O PO lá, legal, também funciona - também uso, mas dependendo do ambiente que ele esteja inserido em seu trabalho, seu comportamento pode destoar completamente do restante time, e isso - SIM - afeta o resultado final.
Para mim estar lá ou aqui não afeta diretamente no ROI…o comportamento do PO afeta muito mais.
Um abraço.
Alexandre Magno
Legal Magno! Espero que seu artigo colabore ainda mais para a discussão. É nosso Brasil gerando conhecimento!
Eu não vejo muitos POs buscando ROI. Talvez eles estejam buscando ter o projeto funcionando, mas não ter re$ultado$. Quando vejo o Schwaber falando sobre resultados não penso no software implantado e sim a empresa ganhando dinheiro.
Sim, o PO não pode tentar “tirar mais” do time mas sim “tirar o melhor”. Creio que mudar a cabeça dos POs para eles buscarem o ROI é uma mudança de comportamento que ainda não vejo por aqui. As regras do Scrum podem “regular” essa competição que você comentou. Vejo que o ScrumMaster é primordial para isso.
Mas valeu pela opinião. Concordamos que o ROI é o principal. Abraços!
>> Creio que mudar a cabeça dos POs para eles buscaram o
>> ROI é uma mudança de comportamento que ainda não vejo >> por aqui.
Scrum não existe sem mudança comportamental!
Abraços!
Primeiramente parabéns aos dois Rodrigo e Alexandre pelo compartilhamento desta discussão sobre PO.
Vou recomendar isso para o meu PO aqui!!
Abraço a todos.
E SUCESSO.
Muito legal a discussão. Como vc diz, “quando você foca no ROI besteiras e desperdícios caem por terra”. É de fato essencial pro PO sentir o custo do desenvolvimento para avaliar melhor o que é importante. Mas o cenário pode ser mais complexo, já que o retorno buscado pode não ser imediatamente o financeiro. Por exemplo, há momentos em que se pode optar por fortalecer a marca de um produto. Nestes casos a avaliação do retorno é também mais complicada.
Excelente!
Vejo sua visão e a do Magno de excelente forma, meios para lidarmos e pensarmos no PO de maneira correta, seja qual for o lado do time que ele “jogue”.
Parabéns!
Patricia, de fato o Product Owner é um papel difícil. Ele deve dirigir a equipe para que retorno seja obtido. O pensamento dele deve ser: “Tenho $X para investir nessa iteração. O que no meu backlog é mais importante e me dará mais retorno para investir esse $X?”.
Mas creio que você deve ter compreendido muito bem que esse envolvimento com o “business” é sua responsabilidade mais importante! De fato certos retornos são mais difíceis de serem calculados.
[…] O segundo artigo é do Rodrigo Yoshima entitulado “Product Owner: Um de$graçado ganancio$o”. O Rodrigo colocou um ponto interessante que eu também vejo acontecendo em alguns projetos: a falta de compromisso com o ROI. O Scrum é totalmente “ROI-oriented” e é absolutamente essencial que o P.O. entenda isso plenamente para o sucesso dos projetos. […]
Adorei o conceito
Excelente insight!
Rodrigo,
gostei do título e do artigo.
O que me chamou mais atenção foi você chamar atenção para o fato de existirem P.O. não orientados a ROI. O simples fato de você escrever sobre isso é estranho… válido, mas estranho.
Já o tema secundário é bem mais polêmico… de que lado o P.O. deve estar (ou ser), do lado do cliente ou do lado do fornecedor?
Pelo que entendi você defende o P.O. do lado do cliente. Nesse caso tenho algumas dúvidas: Existem profissionais com disponibilidade e competência suficientes no lado do cliente para ocupar essa posição na equipe de projeto? Como preparar esse cara para trabalhar com Scrum? Você já considerou a possibilidade de uma dupla compartilhando e dividindo essa função, um P.O. do cliente e um P.O. do fornecedor?
Leandro, o Scrum está em crescimento aqui no Brasil. Poucas empresas estão em maturidade no processo. Independente do “lado” do PO ele precisa ser treinado.
O próprio ScrumMaster atua ao lado do Product Owner para que ele ganhe essa fluência no Scrum. Apesar da mudança cultural ser grande, as técnicas do Scrum que o PO precisa saber não são muitas. O que ele precisa é saber controlar o Team através do Product Backlog e ganhar dinheiro com isso. Um menthoring pode ser necessário.
Ter dois POs é estranho ao Scrum. O PO é um ponto focal da DEMANDA. Ele toma as decisões com relação ao ROI. Não creio que seja saudável ter dois deles. Ele pode tomar decisões apoiado no julgamento de outros stakeholders e usuários, porém, ele é o único responsável como PO diante do projeto. O ScrumMaster é quem atuaria no lado do fornecedor.
Rodrigo,
agradeço a resposta.
Mas pensando no seu comentário sobre o Scrum no Brasil penso que no momento talvez seja mais interessante reforçarmos os Scrum Teams com “P.O.’s profissionais” no lado do fornecedor.
A função do P.O. é relativamente simples, mas a responsabilidade é grande e um erro ali compromete todo o processo (e talvez a metodologia).
Uma vez que uma dupla (ou um par ;D) não é opção, fico com o P.O. do lado fornecedor.
[…] De qualquer forma, nós da Aspercom estamos vendo que essa estratégia de treinar TODA a equipe no Scrum está dando certo para todos os nossos clientes corporativos. O convencimento deve ser geral. É comum quando estou ministrando que a equipe técnica tenha dúvidas das práticas de engenharia (que geralmente são do XP e não do Scrum). Os Product Owners querem ser desgraçados gananciosos. Essas respostas devem ser dadas e não vejo que um GP tradicional treinado para ser ScrumMaster possa dá-las de imediato. É comum que uma dúvida técnica básica da equipe possa comprometer a adoção do Scrum. […]
[…] Em algumas empresas esse papel é conhecido como Gerente de Produto, e também outros nomes semelhantes. O que importa é que como já disse meu amigo Rodrigo Yoshima no blog dele, esse cara é um desgraçado ganancioso que tem todo interesse no sucesso do projeto, e acredite, ele é fundamental para isto aconteça. […]
“Waren Buffet, Bill Gates e George Soros seriam bons Product Owners”
Hmmm… naaah. Eles iriam querer acertar mais que ninguém, mas só consigo imaginar um produto tosco saindo da mente deles.
Algo como um Zune, por exemplo.
Sou mais um Jobs, que além de querer o retorno, sabe o que deve ser feito.
Todas as empresas erram e acertam. Como a M$ é lider seus erros são mais evidenciados. Buffet, Gates e Soros são os caras mais gananciosos que eu conheço, por isso o exemplo. De qualquer forma, eles criaram bons produtos sim.
Steve Jobs também erra, mas estamos mais dispostos a perdoar ele do que o Bill Gates.
http://idgnow.uol.com.br/internet/2008/08/05/mobileme-poderia-ter-sido-adiado-admite-steve-jobs/
Nessa famosa entrevista, Jobs admite que foi cascateiro e isso prejudicou o MobileMe.
[…] Vou dar um exemplo. Uma das coisas que me atrapalham é perder a ordem das histórias. Quando você está trabalhando iterativamente, seguindo uma ordem definida por um Product Owner, essa ordem deve ser mantida. Quem fez treinamento comigo ou trabalhou comigo em projetos sabe que sou chato para manter a ordem da fila de construção. Nesse novo projetinho Rails que estou desenvolvendo sozinho, resolví isso furando os cartões, colocando uma correntinha para manter a ordem e um durex verde para indicar a primeira história da fila: […]
[…] O Antonio Carlos Silveira do Yahoo falou sobre o papel o Product Owner e a Priorizarão do Product Backlog. Os principais recados foram: […]