Carregando ...
Desculpe, ocorreu um erro ao carregar o conteúdo.
 

Re: [scrum-brasil] Instruindo o Product Owner

Expandir mensagens
  • Rodrigo Yoshima
    Concordo Magno... porém, convenhamos, um PO CHICKEN é uma aberração para o Scrum IMHO.... PO deve ser a coisa mais PIG do mundo. Na minha relação, PO PIG
    Mensagem 1 de 42 , 6 de out de 2008
      Concordo Magno... porém, convenhamos, um PO CHICKEN é uma aberração
      para o Scrum IMHO....

      PO deve ser a coisa mais PIG do mundo. Na minha relação, PO PIG
      CLIENTE : PO PIG FORNECEDOR é 100:1... (não exagero tanto!!!). He he
      he he...

      Rodrigo Yoshima
      www.ASPERCOM.com.br
      (Proximos cursos: UML SP 06/10 | Scrum DF 18/10 | Scrum SP 08/11 |
      Requisitos SP 28/11)


      2008/10/3 Alexandre Magno <axmagno@...>:
      >
      > Fala Pedro,
      >
      > normalmente um PO comprometido que seja um bom PO, mesmo estando "do lado"
      > do fornecedor estará bem alinhado e envolvido com o cliente (se não não
      > seria um bom PO). Minha realação continua 1000:1 :)
      >
      > Lembrando que, sem dúvida, se eu tiver um PO PIG do cliente, fantástico!!!!
      > Minha relação é PO CHICKEN (cliente) x PO PIG (fornecedor)
      >
      > []s
      >
      > ax
      >
      > ________________________________
      >> To: scrum-brasil@...
      >> From: pedroreys@...
      >> Date: Thu, 2 Oct 2008 21:56:26 -0200
      >> Subject: Re: [scrum-brasil] Instruindo o Product Owner
      >>
      >>
      >> Olá Alexandre,
      >>
      >> 2008/10/2 Alexandre Magno
      >>> O que falo é sempre o seguinte: prefiro 1000 vezes ter um PO comprometido
      >>> (PIG) do lado do fornecedor, do> que um PO envolvido (CHICKEN) do lado do
      >>> cliente! Vejam, 1000 vezes...(pelo menos).
      >>
      >> Sem sombra de dúvida que um PO comprometido é MUITO melhor que um PO
      >> envolvido.
      >>
      >> Porém não podemos desconsiderar que entre um PO comprometido mas que não
      >> tenha conhecimento negocial suficiente que o permita priorizar o que deve
      >> ser feito visando o aumento do valor agregado pelo projeto e um PO
      >> totalmente alinhado aos objetivos estratégicos do cliente e com conhecimento
      >> negocial suficiente para priorizar os que deve ser feito, a razão não é mais
      >> 1000 : 1. :)
      >>
      >> Abraços,
      >>
      >> Pedro Reys
      >>
      >>
      >>
      >> 2008/10/2 Alexandre Magno
      >>
      >> E a discussão de novo :)
      >>
      >> Bom, há uns dois meses atrás li um livro muito bom chamado "Show me the
      >> money: how to dermine ROI in people, projects and programs" que abriu muito
      >> minha cabeça quanto ao assunto ROI...após lê-lo acabei vendo o quanto muito
      >> do que é falado sobre ROI em listas, blogs, etc. é, no mínimo, "viagem na
      >> maionese". ROI é algo um pouco mais amplo e que, na minha opinião, um bom PO
      >> deve sim dominar.
      >>
      >> Quanto ao PO ser do lado fornecedor ou cliente...já discutimos isso várias
      >> vezes por aqui e gente, não há certo ou errado...só tenha certeza que você
      >> está fazendo da forma ideal para o seu cenário para depois não vir com o
      >> discurso "Olha, ter um PO bom é muito difícil...isso não funciona...bla,
      >> bla, bla". Os próprios gurus (Mike, Jef, Ken, etc.) tem opiniões diferentes
      >> sobre este assunto. O que falo é sempre o seguinte: prefiro 1000 vezes ter
      >> um PO comprometido (PIG) do lado do fornecedor, do que um PO envolvido
      >> (CHICKEN) do lado do cliente! Vejam, 1000 vezes...(pelo menos)
      >>
      >> []s
      >>
      >> Alexandre Magno, CST
      >>
      >> ________________________________
      >>
      >>> To: scrum-brasil@...
      >>> From: pedroreys@...
      >>> Date: Thu, 2 Oct 2008 15:05:12 -0200
      >>> Subject: Re: [scrum-brasil] Instruindo o Product Owner
      >>
      >>>
      >>>
      >>> ROI de um projeto (independente de desenvolvido de um produto ou a
      >>> prestação de um serviço) é o retorno que será percebido com o resultado do
      >>> projeto.
      >>>
      >>> Posto isso, entendo o que o Rodrigo disse. Quem está investindo no
      >>> projeto é o cliente, não o fornecedor, e neste caso o ROI é do cliente e não
      >>> há ROI do fornecedor.
      >>>
      >>> Um outro cenário que, este sim, resultará em ROI para o fornecedor do
      >>> cenário acima é:
      >>>
      >>> Foram identificadas as necessidades de aumentar a satisfação dos
      >>> clientes, aumentar a qualidade dos softwares desenvolvidos, aumentar o ROI
      >>> do cliente nos softwares desenvolvidos.
      >>>
      >>> Como estratégia para atender estas necessidades foi definida a adoção de
      >>> modelos ágeis de desenvolvimento de software.
      >>>
      >>> É este projeto de adoção de modelos ágeis de desenvolvimento que trará
      >>> ROI para a organização de TI, uma vez que aqui sim a organização de TI
      >>> estará fazendo investimentos.
      >>>
      >>> Neste cenário, o PO do projeto de adoção de Agile terá que priorizar os
      >>> itens do backlog de maneira a maximizar o ROI do projeto. Por exemplo, um
      >>> backlog inicial que deverá ser priorizado pelo PO:
      >>>
      >>> * "Capacitar a equipe em Agile";
      >>> * "Treinar em Scrum o corpo tático da empresa";
      >>> * "Identificar fornecedores de post-its e canetinhas";
      >>> * "Implantar um servidor de Integração Continua";
      >>> * "Implantar Solução de Testes Automatizados";
      >>> * "Redefinir a disposição dos Postos de Trabalho".
      >>>
      >>> Mesmo nos casos de desenvolvimento de produtos, onde a organização em seu
      >>> sentido amplo, não é uma prestadora de serviços de desenvolvimento de
      >>> software, o ROI do projeto deve ser definido pelo cliente do projeto, ou
      >>> seja quem está fazendo o investimento no projeto de desenvolvimento do
      >>> produto. É a área de marketing, o gerente de produtos, etc. Enfim, mesmo
      >>> neste caso, IMHO, o P.O sempre que possível deverá ser externo à quem está
      >>> desenvolvendo o projeto, pois os desenvolvedores não possuem a visão de
      >>> negócio necessária para avaliar o que deve ser prioritário visando o ROI do
      >>> projeto. Nem creio que seja justo ou responsável colocar este "peso" sobre o
      >>> ombro deles.
      >>>
      >>>
      >>> Abraços,
      >>>
      >>> Pedro Reys
      >>>
      >>>
      >>>
      >>>
      >>> 2008/10/2 Raony Araújo
      >>>
      >>> que é?
      >>>
      >>> 2008/10/2 Ânderson Quadros :
      >>
      >>>
      >>>> Com certeza alguns comentário estão usando o termo ROI fora de seu
      >>>> conceito.
      >>>>
      >>>>
      >>>>
      >>>>
      >>>> 2008/10/2 Marcos Silva Pereira
      >>>>>
      >>>>> Rodrigo, acho que o Raony quis dizer: "maxime o SEU retorno,
      >>>>> maximizando o
      >>>>> retorno DO CLIENTE". O que pra mim faz todo sentido quando pensamos em
      >>>>> uma
      >>>>> "politica sustentável".
      >>>>>
      >>>>> Abraço...
      >>>>>
      >>>>> --
      >>>>> Marcos Silva Pereira
      >>>>> http://marcospereira.wordpress.com
      >>>>> "People who are crazy enough to think they can change the world, are
      >>>>> the
      >>>>> ones who do."
      >>>>>
      >>>>>
      >>>>> 2008/10/2 Rodrigo Yoshima
      >>>>>>
      >>>>>> Agora ficou confuso:
      >>>>>>
      >>>>>> Raony agora:
      >>>>>>> para uma política sustentável, eu preciso sempre focar no ROI do
      >>>>>>> cliente, pq é ele que me paga e por sua vez, constitui o meu ROI.
      >>>>>>
      >>>>>> Raony a dois posts atrás:
      >>>>>>>>>>> na visão dele, o objetivo do PO é maximizar o ROI da empresa de
      >>>>>>>>>>> desenvolvimento (que é onde o scrum está sendo aplicado, e por
      >>>>>>>>>>> isso
      >>>>>>>>>>> onde deve se colher os frutos) e, obviamente, ele faz isso
      >>>>>>>>>>> agradando o
      >>>>>>>>>>> cliente que é quem paga, e por isso tem como segundo objetivo
      >>>>>>>>>>> diretamente relacionado ao primeiro: maximizar o ROI do cliente.
      >>>>>>
      >>>>>> Decida-se... é para focar o ROI do cliente ou do fornecedor?
      >>>>>>
      >>>>>> Na minha opinião o ROI do fornecedor não tem relação nenhuma com o ROI
      >>>>>> do Projeto. Sim, clientes satisfeitos aumentam meu mercado e fidelizam
      >>>>>> clientes, mas para isso, eu como fornecedor, consigo ROI investindo em
      >>>>>> pessoas e em tecnologia no meu time (entregar mais com mais qualidade
      >>>>>> e podendo cobrar mais por isso). Tendo isso eu posso aumentar a minha
      >>>>>> margem de venda. O que não tem relação nenhuma com o projeto, o
      >>>>>> cliente, nem com o PO e nem mesmo com o Scrum.
      >>>>>>
      >>>>>> Rodrigo Yoshima
      >>>>>> www.ASPERCOM.com.br
      >>>>>> (Proximos cursos: UML SP 06/10 | Scrum DF 18/10 | Scrum SP 08/11 |
      >>>>>> Requisitos SP 28/11)
      >>>>>>
      >>>>>> ------------------------------------
      >>>>>>
      >>>>>> Links do Yahoo! Grupos
      >>>>>>
      >>>>>>
      >>>>>
      >>>>
      >>>>
      >>>
      >>>
      >>>
      >>
      >> __________________________________________________________
      >> Cansado de espaço para só 50 fotos? Conheça o Spaces, o site de
      >> relacionamentos com até 6,000 fotos!
      >> http://www.amigosdomessenger.com.br
      >>
      >>
      >>
      >
      > __________________________________________________________
      > Instale a Barra de Ferramentas com Desktop Search e ganhe EMOTICONS para o
      > Messenger! É GRÁTIS!
      > http://www.msn.com.br/emoticonpack
      >
    • Rodrigo Yoshima
      Danilo, já ví ANs ser POs. Já ví gerentes do lado do fornecedor serem POs. Já ví um stakeholder sem poder ser PO. Já ví não ter PO. Todas essas
      Mensagem 42 de 42 , 14 de out de 2008
        Danilo, já ví ANs ser POs. Já ví gerentes do lado do fornecedor serem
        POs. Já ví um stakeholder sem poder ser PO. Já ví não ter PO. Todas
        essas configurações são aplicadas no caso da discussão: PROJETO FEITOS
        FORA DE CASA. Creio que a grande maioria de pessoas que tem problemas
        com POs (eu mesmo) se configuram neste estilo de projeto.

        Na minha experiência, bons POs são formados a partir da experiência de
        pagar a conta (ver o dinheiro saindo do seu próprio bolso). Aí sim o
        cara vai ter um sentimento de ROI correndo nas veias. Um bom PO se
        questiona: "Tenho 180 mil para gastar nessa relese. Quanto estiver
        pronta como vou poder tirar dinheiro de alguém com o software?".

        Quando chamei o PO carinhosamente de "Desgraçado Ganancioso" no meu
        blog, muitas pessoas ficaram chocadas e mandaram comentários que não
        deu para publicar! Minha resposta: na época da Guerra Fria a gente
        ainda tinha dúvidas se lucro era bom. A gente tinha um sentimento do
        tipo: "Será que o comunismo da URSS é tão ruim assim?". Eram só
        devaneios, nada muito sério, porém, atualmente, no capitalismo
        moderno, SABEMOS que o LUCRO é BOM. Sim, outras coisas também são
        importantes, mas o lucro é primordial.

        Não concordo muito com a visão romântica que muitas pessoas no mercado
        tem a respeito de Agile. Acredite: Agile é para lucrar e não para
        deixar todo mundo contente. Nosso mercado é tão doido que são as
        equipes que sugerem aos superiores a adoção de Agile, quando o
        movimento deveria ser o contrário (isso não ocorre porque a gerência
        em geral é burra). O que é engraçado é que muitas dessas equipes não
        tem idéia do buraco que elas estão se enfiando. Como exemplo: eu mesmo
        prefiro fazer algumas horas extras do que trabalhar no "Energized
        Work" que algumas equipes imprimem, principalmente em "Pair
        Programming". Mas isso é pessoal (especialmente para um cara que sofre
        de déficit de atenção).

        Rodrigo Yoshima
        www.ASPERCOM.com.br
        Próximas turmas: Scrum DF 18/10 | Requisitos SP 28/10 | Scrum SP 08/11

        2008/10/14 Danilo Carlos Avante <daniloc.avante@...>:
        > Olá Rodrigo,
        >
        > Por que um AN não pode ser o PO ?
        > O AN não terá capacidade em decidir o que agrega mais valor ao negócio do
        > cliente ?
        >
        > []´s
        > Danilo
        >
        > 2008/10/13 Rodrigo Yoshima <rodrigoy@...>
        >>
        >> Olá.... respostas no texto.
        >>
        >> 2008/10/13 Gustavo Santos <gustavo5120@...>:
        >>
        >> > Acho que há muitas chances de um PO (fornecedor) virar um Analista de
        >> > Negócios. O que deveria ser feito nesse caso?
        >>
        >> Sorry... Analista de Negócio é Analista de Negócio. PO é PO. A gente
        >> vai cai na discussão anterior. Creio que achar um bom analista de
        >> negócio é tão difícil quanto achar um bom PO. Não confunda analista de
        >> negócio com analista de requisitos. São duas coisas diferentes apesar
        >> de relacionadas.
        >>
        >> > E, obviamente, um PO PIG no Cliente com o devido conhecimento de um PO
        >> > é sonho....... mas poderia ser A Dream Come True!
        >>
        >> Creio que o maior obstáculo é envolvimento e não conhecimento. Nosso
        >> mercado tem uma postura ridícula. Eu chamo isso de "buy and forget",
        >> fecha um escopo e sai desenvolvendo sem muita interação entre negócio
        >> e TI.
        >>
        >> Rodrigo Yoshima
        >> www.ASPERCOM.com.br
        >> Próximas turmas: Scrum DF 18/10 | Requisitos SP 28/10 | Scrum SP 08/11
        >
        >



        --
        Rodrigo Yoshima
        www.ASPERCOM.com.br
        Próximas turmas: Scrum DF 18/10 | Requisitos SP 28/10 | Scrum SP 08/11
      Sua mensagem foi enviada com êxito e será entregue aos destinatários em breve.