Roadmap de Produto - De onde viemos? Para onde vamos?

Roadmap de Produto

                   Você já vivenciou situações em projetos ágeis onde simplesmente todos desenvolviam a Sprint entretanto ninguém sabia para onde efetivamente estavam caminhando? Qual era a importância de cada uma das entregas para chegar na cereja do bolo ou no fim do projeto. É bem provável que a resposta seja sim, é muito comum este tipo de desorientação na hora de criar novos produtos ou serviços. Embora seja necessário primeiro obter a visão de produto, uma ferramenta que pode facilitar o compartilhamento da resposta seja o P.O. estruturar um Roadmap de Produto.

                   Roteiro de produto ou Roadmap de produto é um artefato de planejamento que mostra como o produto provavelmente evoluirá ao longo das futuras versões, facilitando o diálogo entre a equipe SCRUM e os stakeholders (SCHWABER, 2011). Um roteiro permite que as organizações coordenem o desenvolvimento e o lançamento de itens relacionados dentro de seu portfólio de produtos (PICHLER, 2011).

                   O roteiro de produto diferente do Product Backlog mostra de maneira simples e clara como se pretende chegar à visão de produto, isto é, a estruturação de um plano de ações para alcançar os objetivos de produto descritos na visão de produto (SIMÕES, 2011). A Figura 5 apresenta este ciclo de estruturação do Roadmap de produto.

Fonte: Simões (2011).

                   Este é um artefato dinâmico que deve ser atualizado constantemente, visto que a evolução do produto e da visão é colaborativa e constante (COHN, 2011). Pode servir como diretriz de uma companhia para que sejam lançadas estratégias para o desenvolvimento do portfólio de produtos. A elaboração do Roadmap é uma das práticas mais importantes do processo de desenvolvimento de produtos e, quando conduzido de forma correta, pode influenciar diretamente na conquista e/ou retenção de clientes estratégicos (SIMÕES, 2011).

                   Neste momento a companhia pode além de vender seus produtos já desenvolvidos, vender um plano de produto traçado que atrai e fideliza clientes. Quem já comprou o produto percebe que existe um plano evolutivo do produto, quem ainda não comprou pode ver num futuro breve sua necessidade atendida no escopo daquele produto (SIMÕES, 2011). O PO vislumbra no Roadmap uma ordem cronológica das versões e macro funcionalidades que serão disponibilizadas aos clientes em cada uma das entregas (PICHLER, 2011).

Portanto este instrumento é de extrema valia para o sucesso dos projetos, visto que este artefato propicia uma divulgação mais abrangente do que o PO e Equipe SCRUM “sonham” para o produto. Logo com intuito de chegar ao mercado na hora certa o requisito certo o PO deve conhecer o seu Market-share e assim elaborar Roadmaps de produtos que os clientes amem (PICHLER, 2011).
Para exemplificar o que estamos falando podemos visualizar o roadmap do navegador Firefox: https://wiki.mozilla.org/Firefox/Roadmap

E você já estruturou o seu roadmap? Acha que é viável ou não estruturar um roadmap de longo prazo? Compartilhe sua experiência nos comentários.

Pixar: 22 dicas de storytelling

Olá Pessoal,

Este blog esta parado há muito tempo... Devido alguns contratempos, não ando mais focando em criar conteúdo para este espaço, mas quero retomar esse exercício de compartilhar conteúdo ágil nos próximos dias com vocês.

Hoje estava lendo algumas coisas sobre Storytelling e encontrei o texto abaixo, com 22 dicas da Pixar para escrever histórias, extraído do blog do José Telmo.

Excelente para refletirmos e revermos alguns conceitos quando o nosso trabalho trata com criação, seja ela qual for. Particularmente, vi vários pontos que realmente já travaram por vários momentos o desenvolvimento de uma user story por exemplo. Em que por puro preciosismo de detalhes, acabam tornando a história desinteressante, e perdemos o foco no desfecho principal e o objetivo que queremos alcançar, por isso destaco a 5ª dica que diz o seguinte:

Simplicidade. Foco! Combine personagens. Evite desvios. Você pensa que está perdendo algo importante, mas te deixará livre para escrever.

Agora com mais detalhes, as dicas na íntegra:

1. Você admira a garra de um personagem, por ele tentar mais, do que pelo seu sucesso.
2. O que pode ser divertido para a audiência, pode não ser para você.
3. Tentar emplacar um tema é importante, mas você só verá isso quando terminar de escrever. Agora, reescreva tudo.
4. Era uma vez_____, A cada dia ________, Um dia _______, Até que finalmente ______________,
5. Simplicidade. Foco! Combine personagens. Evite desvios. Você pensa que está perdendo algo importante, mas te deixará livre para escrever.
6. Em que o seu personagem é bom? Jogue o oposto nele! Desafie! Como ele vai lidar com isso?
7. Elabore o fim antes de você chegar no meio. Sério. Conclusões são difícieis, antecipe o quanto antes.
8. Termine sua história e siga em frente, mesmo que ela não seja perfeita. Faça melhor na próxima.
9. Quando você travar, faça uma lista do que não deve se repetir. Muitas vezes, o que vai te destravar aparece.
10. O que mais gosta nas suas histórias preferidas é parte de você. Você tem de reconhecer isso antes de usar.
11. Colocar no papel permite você melhorar. Se ficar na cabeça, a ideia perfeita, você nunca vai dividir com alguém.
12. Evite a primeira ideia que vem à cabeça. E a segunda, a terceira, a quarta – tire o óbvio do caminho. Surpreenda-se.
13. Dê opiniões aos seus personagens. Passivo/Maleável parece bom para você escrever, mas é um veneno para a audiência.
14. Por que você tem de contar ESTA história? Qual a crença que a alimenta? Este é o coração da história.
15. Se você fosse seu personagem, nessa situação, como se sentiria? Honestidade leva a credibilidade em situações inacreditáveis.
16. O que está em jogo? Nos dê uma razão para ir a fundo no personagem. O que acontece se eles falharem?
17. Nada se desperdiça. Se não está funcionando, deixe e siga em frente – a ideia voltará a ser útil mais a frente.
18. Você precisa se conhecer: a diferença entre fazer o melhor e o que é chato. História é teste, não refinamento.
19. Coincidências para colocar os personagem em problemas é ótimo; Coincidências para livrá-los dos problemas é trapaça.
20. Exercício: tire as peças-chave de um filme que detesta. Como você irá rearranjá-las para ficar da forma que gosta?
21. Identifique-se com a situação/personagens. Você não pode apenas escrever. O que faria você agir daquela maneira?
22. Qual a essência de sua história? A forma sucinta de contá-la? Se você sabe, comece a construir a partir daí.

 E aí, o que achou? Espero que tenham refletido durante a leitura e que na próxima criação estas dicas sejam úteis para você.

Abraço e até o próximo post.

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?

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.

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.