Menu fechado

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.

[photopress:buffet.jpg,thumb,pp_image][photopress:gates.jpg,thumb,pp_image][photopress:soros.jpg,thumb,pp_image]
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.

31 Comentários

  1. Robson

    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 !

  2. Alexandre Magno

    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

  3. Rodrigo Yoshima

    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!

  4. Alexandre Magno

    >> 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!

  5. Fábo Desconsi

    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.

  6. Patricia Fontes

    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.

  7. Luiz Aguiar

    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!

  8. Rodrigo Yoshima

    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.

  9. Pingback:» Mais sobre Product Owners » Guilherme Chapiewski - Blog sobre desenvolvimento de software e tecnologia

  10. Leandro Mendonça

    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?

  11. Rodrigo Yoshima

    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.

  12. Leandro Mendonça

    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.

  13. Pingback:Débito Técnico » Blog Archive » Um exemplo a ser seguido

  14. Pingback:Introdução ao SCRUM « Luiz Aguiar - Be Happy, Be Agile!

  15. Alexandre Gandra

    “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.

  16. Rodrigo Yoshima

    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.

  17. Pingback:Débito Técnico » Blog Archive » Besteirol Agile

  18. Pingback:Participação no “Falando em Agile 2008″ « André Faria Gomes

  19. Pingback:Scrum Gathering: Palestra: Scrum para Desenvolvimento Interno e para Produtos de Software « Blog do Ensinar

  20. Rafael Rocha

    Interessante o termo didatico, mas quais aspectos pessoais, perfil e areas de conhecimento geralmente exigi-se de um product owner?

    De que forma o scrum master pode colaborar para isto ?

    Um Product Owner poderia ser o gerente do projeto ou interferir em aspectos tecnicos ?

  21. Rodrigo Yoshima

    Rafael, os aspectos pessoais podem variar de área/ou tipo de projeto. Nas empresas que tenho tido contato, como o Crivo, Synchro e outras (vejas os cases aqui no blog), o PO é um cara de negócios e alinhado com o mercado (apesar de que alguns deles tem um background técnico). De qualquer forma, se o produto final não atende uma necessidade do mercado, a falha é inteiramente do PO.
    O ScrumMaster auxilia o PO, possivelmente treinando. De qualquer forma, geralmente quando eu treino equipes os POs também participam.
    O PO não é gerente de projetos na visão tradicional de um gerente de projetos. O PO não deve interferir em aspectos técnicos, a não ser que ele seja capacitado para tal e a equipe acate a essas opiniões. Como por exemplo, dependendo da área de atuação, a linguagem de implementação pode ser decidida por aspectos mercadológicos e não técnicos. Geralmente a equipe não tem esse tipo de sensibilidade.

  22. Almiro Alves

    Ótimo artigo Rodrigo, também concordo que o idela seria o PO ficar do lado do cliente, porém acredito que o responsável por garantir que o PO não vai passar por cima das regras do Scrum é o próprio ScrumMaster, ou seja, o ScrumMaster que tem que sentir se o PO está pegando pesado ou não.

    Abs, e parabéns mais uma vez pelo artigo.

  23. Pingback:Como criar e priorizar um backlog « Agile no mundo real

  24. Pingback:Por que Agile e Lean funcionam? « Acordo Coletivo (Empregados Petroleiros)

  25. Pingback:Seu cliente é ágil? | sauloarruda.eti.br

  26. Pingback:Participação no "Falando em Agile 2008" | André Faria Gomes

  27. Otavio Medeiros

    Olá Rodrigo, este post tem excelentes informações. Tu escreveu a seguinte opinião:
    “Eu realmente acredito que a falta de compromisso com o ROI era por conta dessa proximidade com a equipe”.
    Me parece que tu parte da premissa de que o PO é um cliente, um investidor, então não existe ninguém melhor do que ele para entender o que gera valor para ele . Eu te digo que eu trabalhei com um PO, que era do cliente, e não tinha a menor noção de ROI, do que realmente gerava valor para ele. No entanto, em outro projeto, o cliente terceirizou um PO que conduziu de forma excelente o projeto e todas as iterações geravam retorno para quem contratou ele. Sendo assim, sou obrigado a concordar que o papel do PO tem muito mais a ver com o comportamento do que com o time que ele “joga”.

    Tenho uma dúvida que acredito ser bastante básica. Imagine que a empresa A quer lançar um produto para uma empresa B mas terceiriza o desenvolvimento para a empresa C. Tome como verdade o fato de que o PO faz parte da empresa C. A empresa B só irá investir no produto da empresa A se ele gerar algum retorno. Da mesma forma, a empresa A só irá investir na empresa C se esta última gerar retorno. Este PO deve se focar em qual cliente? Acredito que no cliente B pois ele é quem vai gerar retorno para o A. O cliente A pode não saber as reais necessidades do cliente B (acredite, eu vejo isso quase sempre). Se o PO não gera retorno para o B, este não investirá no A que por sua vez não investirá no C. Enfim, acredito que o foco do PO seja no cliente final. Estou certo?

    Novamente, parabéns pelo artigo, muitíssimo bom.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *