segunda-feira, 30 de abril de 2012

Função: Product Owner



Hoje estava pensando que como estou escrevendo um blog chamado “PO Place”, eu deveria explicar um pouquinho mais sobre qual o verdadeiro papel deste profissional, inserido no contexto ágil.
Segundo Mike Cohn, em seu livro Desenvolvimento de Software com Scrum, Aplicando Métodos Ágeis com Sucesso, ele introduz este papel com a seguinte frase:

“Considero o dono do produto como a pessoa que garante que a equipe se dedique ao objetivo correto... O dono do produto direciona a equipe para o alvo certo;”




O Product Owner é o CLIENTE de um time Scrum, ele é responsável pelo retorno sobre o investimento de um produto.  Entre suas tarefas estão:

  • Definir todas as funcionalidades que o produto deve possuir. É importante salientar que sugestões de histórias podem ser feitas por qualquer pessoa mas a inclusão destas no Product Backlog é de  gerência do Product Owner.
  • Priorizar as funcionalidades que devem ser incluídas a cada Sprint de acordo com o valor de negócio. 
  • Aceitar ou Rejeitar as entregas do time, homologação funcional.
Além disto, faz parte da tarefa do Product Owner avaliar a entrega de seu produto para os demais clientes bem como, repriorizar e rever funcionalidades. O Product Owner tem o poder para interromper um Sprint em caso de urgência e até mesmo de suspender um projeto caso detecte que seu retorno não será o esperado pela empresa. Pois como falamos no post anterior o Product Owner é o responsável pelo ROI.

O perfil de um Product Owner está relacionado à área de produto, sendo necessário que o mesmo consiga compartilhar os objetivos do produto que está sendo construído pelo time.




 Ele deve ser visto como um líder pelo time deve ser o principal motivador e ter bom relacionamento com a equipe. Isto é importante, pois o time precisa assumir que os desafios do Product Owner são os seus desafios.

Para obter este reconhecimento é importante que haja uma sintonia muito grande entre a equipe e o seu Product Owner. Todos os membros da equipe Scrum devem compartilhar um relacionamento confiável e simbiótico, isto é trabalhar como parceiros. Não deve haver nós e eles, somente nós. Quem cumpre o papel de P.O. deve gastar no mínimo uma hora com seu time por dia para afinar o instrumento de comunicação e expectativas de entrega.

Conhecer bem a equipe significa entender do que ela é capaz, especialmente saber traduzir as demandas de negócio para as técnicas e vice-versa. Quanto mais se estabelece este conhecimento mútuo, melhor é a comunicação e o P.O. se torna mais eficiente para planejar.

Portanto é preciso olhar um pouco fora da caixa para descrever este papel, que é muito mais do simplesmente um listador de funcionalidades e/ou um tirador de pedidos. Este sujeito é responsável pela lista de objetivos, pois uma funcionalidade é menor que um objetivo de negócio alcançado. Por estas e outras que eu concordo com a frase que li outrora num artigo que dizia o seguinte:

“Olhando com mais calma, o P.O. é mais que um papel, é a alma do Negócio”.

Agora gostaria de saber, você e sua equipe estão realmente em sintonia com os objetivos do produto?


sexta-feira, 20 de abril de 2012

O PRODUTO MÍNIMO COMERCIALIZÁVEL x ROI





O sucesso dos produtos desenvolvidos está diretamente ligado ao valor investido e retornado, logo o responsável pelo produto deve gerenciar quais são os requisitos essenciais que devem ser desenvolvidos para cumprir a visão do produto de forma objetiva. Conforme levantado em pesquisa realizada pelo Standish Group, 65% das features não são utilizadas ou raramente são utilizadas. Estes dados refletem visões de produto nebulosas, onde o time não sabia o que desenvolver e o responsável pelo projeto não soube extrair de forma satisfatória a real necessidade do mercado ou cliente.

No que tange estes pontos, criar um produto mínimo nos dá uma série de vantagens, conforme observado por Smith e Reinertsen (1997), e Denne e Cleland-Huang (2004). O produto é lançado mais rapidamente, e o tempo para o mercado é reduzido; a funcionalidade é lançada de maneira mais oportuna. O produto é desenvolvido a um custo mais baixo e gera maior retorno do investimento. Os pagamentos são recebidos mais cedo, melhorando o fluxo de caixa, bem como acelerando o aprendizado.


Se pegarmos o exemplo do Iphone lançado em 2007, a experiência proporcionada por este telefone aos seus usuários fez com que seus concorrentes se envergonhassem. Após o lançamento foi marcada uma nova era de smartphones. Um dos segredos por trás deste sucesso é o conjunto estreito de necessidades do cliente que a Apple selecionou. Ao invés de tentar agradar a muitas pessoas ao mesmo tempo copiando todos os recursos que os concorrentes ofereciam, a Apple assumiu uma visão nova de como os smartphones deveriam se parecer e, funcionar e, deliberadamente, omitiu algumas funcionalidades. A primeira versão do Iphone lançada ao mercado, não tinha os recursos de copiar e colar, nem mesmo a possibilidade de enviar uma mensagem de texto para vários destinatários, por exemplo. Estas limitações, no entanto não impediram seu sucesso. 
Reduzir o escopo de funcionalidades permitiu a Apple desenvolvesse e entregasse um produto dentro de um espaço de tempo competitivo e deu-lhe uma liderança significativa em relação à concorrência.

Sair com um produto mínimo também reduz riscos. Menos dinheiro é perdido caso o produto fique abaixo do esperado, logo é possível colocar na estratégia margem para fracassos.

Reduzindo o tempo para o mercado, podemos escutá-lo e a ele responder com mais frequência, ao invés de tentar antecipá-lo.

domingo, 15 de abril de 2012

VISÃO DE PRODUTO


                   “Gato, qual é o caminho correto?”, perguntou Alice ao Gato de Cheshire no romance de Lewis Carrol, Alice no país das maravilhas. “Depende, Alice; para onde você quer ir?”, o Gato respondeu. “Não sei, não importa muito.”, Alice retrucou. “Para quem não sabe aonde quer ir, então qualquer caminho serve”, o Gato rebateu (Carroll, 1998, p.56)

Antever quais os principais atributos que o produto deve ter em seu ciclo de vida para atingir seu objetivo é essencial para chegar lá. O Product Owner é responsável por desenvolver uma visão do produto e compartilhar esta de forma genérica. Demonstrando quais são os objetivos de negócio que o produto deve suprir. Logo quem cumpre o papel deve ter a sensibilidade de delimitar o escopo da visão de forma com que seja possível o desenvolvimento de forma iterativa e colaborativa, a construção do produto e suas user stories devem ser de responsabilidade de toda equipe sem que esta visão permita margem para fuga de escopo.

Segundo Roman Pichler para desenvolver uma visão refinada, esta deve responder às seguintes questões:

·         Quem irá comprar o produto? Quem é o consumidor alvo? Quem usará o produto?
·         Quem são seus usuários alvo?
·         Que necessidades o produto resolverá? Que valor ele agregará?
·         Quais atributos do produto são críticos para atender às necessidades selecionadas e, portanto, para o seu sucesso? 
·         Aproximadamente, como ele se parecerá e se comportará? Em que áreas se destacará?
·         Como o produto pode ser comparado com os já existentes?
·         Como a empresa ganhará dinheiro vendendo o produto?
·         Quais as fontes de receita e qual é o modelo de negócios?

Portanto a visão deve comunicar a essência do futuro do produto de maneira concisa e descrever uma meta compartilhada que ofereça direção, mas ser ampla suficiente para facilitar a criatividade.

Este ponto é de suma importância para que o time esteja envolvido e comprometido com o objetivo do produto. O envolvimento da equipe é peça fundamental para o sucesso, e um dos principais motivos deste envolvimento é proveniente de um engajamento dos integrantes pela causa representada na visão do produto.