Like A Girl

Pushing the conversation on gender equality.

Code Like A Girl

Técnicas para criar um Produto através de Product Discovery

http://girlzinweb.com/2015/12/10/faut-il-etre-technique-pour-etre-un-bon-po/

Após ter participado do POs on Beer, realizado pela empresa Concrete no Rio de Janeiro, um evento voltado a compartilhar conhecimento sobre produto, fiquei bem entusiasmada com as técnicas apresentadas sobre Product Discovery (Descoberta do Produto). Resolvi escrever para transmitir um pouquinho do que eu ouvi por lá. Para aqueles que desejam trilhar o caminho profissional como PO, acredito que esse artigo vai ser bem bacana, tomara!!

Deixa eu nivelar primeiro alguns conceitos, para alcançar a diversidade de público que possa vir a ler esse artigo.

Definindo o Product Owner

O PO é um dos os três papéis que constituem uma Equipe Scrum clássica, para galera de Agile (Ágil), não é novidade que é papel do PO ou Product Owner (Dono do Produto), é saber os problemas e necessidades dos clientes e descobrir o mínimo produto viável (MVP) para então poder definir os itens que compõem o Product Backlog e os priorizar nas Sprint. Mas como? Pera aí que eu já vou contar o que eu aprendi no evento.

Gestão Ágil

É uma abordagem leve e de mínima intervenção para o gerenciamento de projetos. Ou seja, o projeto é todo dividido em etapas menores, chamadas de iteração, que geralmente duram de 2 a 4 semanas e ao final de cada etapa há uma reavaliação das prioridades do projeto. E um possível replanejamento da etapa que virá em sequência. O conceito de Gestão Ágil surgiu em paralelo ao crescimento do setor de Tecnologia da Informação, que devido as crescentes pressões do mercado por inovação, produtividade e mais qualidade dos produtos (softwares), perceberam a necessidade de uma melhoria nas técnicas de desenvolvimento de software, onde o foco principal é a satisfação do cliente. Para gerir de forma ágil projetos de Softwares, o framework mais usado e conhecido se chama Scrum.

MVP

O Mínimo Produto Viável é um processo de validação de hipóteses, e não um produto final e estático.
•Minimum: o menor tamanho possível, que possa ser entregue no menor tempo possível.
•Viable: uma proposição de valor importante o suficiente para que seu principal cliente adote esse produto, se possível gerando receita.
•Product: funcionalidades encaixadas em uma entrega que se assemelhe a um produto coeso e útil.

Agora vamos aquela pergunta feita lá em cima do artigo, lembra? Como o Product Owner identifica as necessidades do cliente e desenvolve um MVP a fim de definir o Backlog do produto e posteriormente os Backlogs das Sprint?

Temos duas formas diferentes de processos para identificar um produto: incremental e iterativo. No primeiro já temos melhor definido o que queremos, ou achamos que queremos, já no segundo temos apenas uma ideia genérica do que queremos, temos apenas uma vaga ideia (hipótese), e iremos descobrir mais detalhes do que queremos, ao longo do desenvolvimento.

Então o processo Iterativo é o adequado uma vez que o Scrum é um framework ágil, em que o produto é criado em ciclos curtos de construção e validação.

https://qualidadebr.wordpress.com/2010/11/22/processo-incremental-x-iterativo

Com as palavras do Jeff Gothelf: toda solução de Design é uma hipótese, o evento apresentou o método Lean de pesquisa.

https://www.slideshare.net/ConcreteS/pos-on-beer-rj-79730623

A idéia do método Lean de Pesquisa é utilizar o ciclo Build — Measure — Learn (Construir — Medir — Aprender), para desenvolvimento ágil de MVP através da interação com os usuários para testar diferentes hipóteses de produto. O ciclo de descoberta é o processo de captura, pesquisa e priorização ativas das necessidades dos usuários, além de coletar e validar idéias de solução para abordá-las.

Com uma compreensão clara da necessidade do usuário, pode-se elaborar protótipos baratos e validar sua compreensão de soluções ótimas para problemas urgentes. Qualquer coisa que possa ajudá-lo a obter o feedback com a mais alta qualidade, com o menor esforço possível, até mesmo protótipos de papel, esboços ou recursos propostos delineados em um documento.

Trocando em miúdos, junta-se os stakeholders e o time numa sala de guerra, e através das técnicas de consenso, se faz a validação de hipóteses com os clientes, onde os feedbacks dos clientes servem para adquirir aprendizado e, então, decidir o que se deve construir e o que não deve construir. Depois utiliza-se as técnicas de priorização para definir o backlog do produto e das sprint.

A idéia é que o product Discovery precisa ser colaborativa. É responsabilidade de todos (time de desenvolvimento, cliente e, se possível, usuários e patrocinadores) participar do processo. O nível de interação entre as pessoas é muito grande, e muitas relações são formadas ou fortalecidas, o que aumenta radicalmente as chances de sucesso do projeto.

A lição aprendida lá no evento é que no início do projeto para o Product Discovery leva-se de 2 a 3 dias para as técnicas de consenso e priorização, e a partir da execução do projeto nas reuniões de Refining leva-se 1 hora por semana para ideação e priorização, ou seja, identificar o que se deve mudar ou aprimorar.

Seguem Técnicas de consenso que foram apresentadas:

Painel CSD (Certezas, Suposições e Dúvidas)

https://www.slideshare.net/ConcreteS/pos-on-beer-rj-79730623

É uma técnica rápida e simples de implementar, que confere um entendimento geral do status atual do produto.

O time de produto se reúne com stakeholders e membros do time de TI para listar, em colunas separadas, todas as certezas, dúvidas e suposições que eles possuem sobre o produto.

O ideal é que sempre existam mais dúvidas do que certezas, pois são as dúvidas que irão gerar insumos para novas funcionalidades, atualizações, descoberta de potenciais problemas, etc.

Tempo de aplicação: Entre 2h a 3h

Recomendado para entender: Visão geral do produto

É / Não é / Faz / Não faz:

https://www.slideshare.net/ConcreteS/pos-on-beer-rj-79730623

A atividade É-Não É-Faz-Não Faz, criada por Rafael Sabbagh, ajuda a definir um produto. Por vezes é mais fácil descrever algo pelo que tal coisa não é ou deixa de fazer. Essa atividade busca clarificações desta forma, indagando especificamente cada aspecto positivo e negativo sobre o produto ser ou fazer algo. Tipicamente, após tal atividade os participantes terão uma visão mais alinhada tanto sobre o que o produto faz, tanto quento o que o produto não faz. Decisões estratégicas podem ser clarificadas, como tal coisa o produto nunca vai fazer, enquanto que aquela outra ainda não deve fazer.

OKRs (Objectives and Key Results)

https://pt.slideshare.net/AndressaChiaraCSMCSP/tdc-floripa-workshop-product-discovery

É um sistema de definição de metas, é uma abordagem simples para criar alinhamento e engajamento em torno de metas mensuráveis.

O conceito original da OKR veio da Intel e se espalhou para outras empresas do Vale do Silício. O Google aprovou o OKR em 1999, durante seu primeiro ano. Ele apoiou o crescimento do Google de 40 funcionários para mais de 60.000 hoje. Além do Google, outras empresas usam OKR, incluindo Spotify, Twitter, LinkedIn e Airbnb. Mas OKR não é apenas para empresas digitais. Walmart, Target, The Guardian, Dun e Bradstreet, e ING Bank também estão usando OKR.

Segue estrutura de um OKR: Eu vou (Objetivo) medido por (esse conjunto de Key Results).
• Objetivos são descrições qualitativas memoráveis do que deseja alcançar. Os objetivos devem ser curtos, inspiradores e envolventes. Um Objetivo deve motivar e desafiar a equipe.
•Key Results são um conjunto de métricas que medem o seu progresso em direção ao Objetivo. Para cada Objetivo, você deve ter um conjunto de 2 a 5 resultados principais. Mais do que isso e ninguém se lembrará deles.

Todos os Key Results devem ser quantitativos e mensuráveis. Se não tem um número, não é um Key Result. Os OKRs são frequentemente definidos, medidos e reavaliados. O OKR é um processo simples, de cadência rápida que envolve a perspectiva e a criatividade de cada time.

Não existe apenas uma maneira de usar o OKR, cada empresa ou time pode adaptá-lo e ajustá-lo, criando diferentes versões.

Mas existem alguns conceitos centrais:

Metas ágeis: Em vez de usar um planejamento anual estático, o OKR usa uma abordagem ágil. Usando ciclos de metas curtos, as empresas podem se adaptar e responder às mudanças.
Simplicidade: abordagem OKR é simples, e os próprios OKRs são fáceis de entender. O modelo original da Intel definia objetivos mensalmente, o que exigiu um processo leve. As empresas que adotam o OKR reduzem o tempo gasto em definir metas de meses para dias. Como resultado, elas investem seus recursos no atingimento dos seus objetivos e não na sua definição.
Transparência: O propósito principal do OKR é criar alinhamento na organização. Para isso, os OKRs são públicos para todos os níveis da empresa — todos têm acesso aos OKRs de todo mundo. Os OKRs do CEO normalmente estão disponíveis na intranet.

Erros comuns com OKR:

Usar OKR como uma lista de tarefas. Use OKR para medir se você está adicionando valor, não se você está entregando tarefas. Portanto, você precisa entender a diferença entre os Key Results baseados em valor e baseados em atividades.
Criar OKRs demais. Este erro é uma conseqüência comum do primeiro. Em vez de ser uma lista de tudo o que você poderia fazer, OKR lista as suas principais prioridades.
Não alinhar os OKRs. OKR é uma ferramenta de alinhamento, então você nunca deve definir seus OKRs isoladamente. Você tem que conversar com as outras equipes.
OKRs não são resoluções de Ano Novo. Sem acompanhamento regular, você nunca irá alcançá-los.

Proto-personas

https://pt.slideshare.net/AndressaChiaraCSMCSP/tdc-floripa-workshop-product-discovery

Personas são personagens fictícios, modelos descritivos criados para representar a definição do cliente típico. Personas são úteis para identificar características comuns entre os potenciais usuários, ajudando a selecionar e definir o perfil comportamental dos consumidores.

Portanto, podemos concluir que: o uso de personas é bastante útil e importante para uma melhor compreensão do comportamento do usuário. Como pensam, o que desejam, quais serviços precisam, quais são suas aspirações, como preferem ser atendidos, que tipo de relação esperam, por quais valores estão dispostos a pagar, e como é o seu comportamento digital. Estas são algumas definições que conseguimos identificar com o uso de personas. Modelamos personas para determinar os requisitos do produto, para comunicar a documentação com a equipe envolvida, e para validar as ideias medindo a efetividade do design.

Procure sempre listar características de cada tipo de persona, criando-as a partir de um nome e foto que represente este grupo de usuários, frase ou slogan que capture a sua personalidade, dados demográficos, dados tecnológicos, nível de educação, perfil profissional, histórico pessoal, estilo de vida, objetivos, valores e atitudes, necessidades, motivação, desejos, expectativas, conhecimento na área, contexto de utilização do produto, frequência de uso, entre outros.

User Story Mapping

https://www.slideshare.net/ConcreteS/pos-on-beer-rj-79730623

Aprenda a criar mapa de estórias de usuários. A estória do usuário é uma forma de facilitar a comunicação e entendimento, e merece todo o destaque por sua característica colaborativa e que propicia uma discussão entre a equipe e os stakeholders sobre os aspectos mais relevantes da experiência do usuário. Jeff Patton define que: “Story Mapping é uma técnica colaborativa, que auxilia na priorização e planejamento de releases de produtos interativos”. As User Story Mapping deverão ser aplicadas na definição do backlog.

Pense que você precisa desenvolver um novo produto, e como em quase todos os projetos, existem problemas de comunicação. Normalmente estes problemas acontecem pelo fato dos clientes não saberem exatamente o que querem, ou porque encontram dificuldades em transmitir de forma clara e objetiva as suas necessidades e desejos. Existe também o fato dos profissionais envolvidos no projeto quase sempre não atenderem as demandas do negócio, e não conseguirem se comunicar e entender as necessidades dos clientes. Isso é quase sempre comum de acontecer, e o resultado disso tudo são mudanças constantes no escopo e nos requisitos durante o desenvolvimento ou na fase final quando o produto é entregue.

Agora vamos falar sobre as Técnicas de Priorização que foram apresentadas no evento. O evento Refining é dedicado à analisar como pode-se melhorar o trabalho para construir o melhor produto, adotando melhores práticas e abordagens. Basicamente três perguntas centrais são respondidas: o que foi feito de bom (e deve continuar fazendo), o que não foi tão bom (e deve mitigar ou abolir), e o que pode melhorar. Considerando que o time terá que desenvolver as histórias do backlog do produto no próximo sprint, muitas vezes não será possível resolver todos os problemas levantados durante o evento, daí as técnicas de priorização de problemas.

Relevância, urgência e tendência

https://www.slideshare.net/ConcreteS/pos-on-beer-rj-79730623

A matriz GUT é uma ferramenta usada para definir prioridades dadas as diversas alternativas de ação, respondendo racionalmente a duas questões básicas: o que se deve fazer primeiro? Por onde começar? Essa matriz utiliza as variáveis Gravidade, Urgência e Tendência do fenômeno. Todos os problemas devem ser avaliados e classificados e as notas em cada um dos quesitos devem ser um consenso entre o time.

Gravidade: representa o impacto do problema analisado, caso ele venha a acontecer. É analisado sob aspectos como tarefas, pessoas, resultados, processos, organizações etc., considerando sempre seus efeitos a médio e longo prazo, caso o problema em questão não seja resolvido;

Urgência: prazo, o tempo disponível ou necessário para resolver um determinado problema. Quanto maior a urgência, menor o tempo disponível para resolução.

Tendência: representa o potencial de crescimento do problema, ou seja, a probabilidade de se tornar maior com o passar do tempo. É a avaliação da tendência de crescimento, redução ou desaparecimento do problema.

Para cada problema levantado, o time atribui uma nota de 1 a 5 para cada variável. A pontuação final para cada problema será o produto entre as três variáveis. A tabela abaixo mostra a definição dos critérios para a nota em cada um dos quesitos.

Times Scrum são, por essência, auto organizáveis. Sendo assim, os times podem definir variáveis, valores ou critérios de priorização diferentes das apresentadas nesse texto. O time tem autonomia para definir seus critérios de priorização, podendo este ser único, duplo ou múltiplo. Além de agregar mais objetividade na seleção de pontos de melhoria, são ferramentas que estimulam a comunicação e aumentam o alinhamento entre o time. Ressalta-se que o resultado final da priorização dos problemas deve ser consenso entre o time, tal qual a estimativa de pontos em estórias de usuário.

Indicadores RUT

https://pt.slideshare.net/AndressaChiaraCSMCSP/tdc-floripa-workshop-product-discovery

A Andressa Chiara, é que Product Owner na Concrete Solutions, fez adaptações ao GUT, e criou a RUT que funciona em cenários em que outros métodos de priorização falham, porque ela força os stakeholders a avaliarem de forma objetiva cada aspecto do item de backlog e elencá-los usando definições específicas, o que minimiza a subjetividade do processo.

A utilização do modelo RUT de priorização ao longo do refinamento é para gerir o valor agregado por Sprint. Para maiores detalhes: https://imasters.com.br/desenvolvimento/agile/exotica-arte-de-medir-valor/?trace=1519021197&source=single

Espero ter contribuído de forma significativamente aos que tiveram curiosidade sobre quem é e o que faz um PO e também para aqueles que desejam trilhar o caminho profissional de ser um PO.

Por fim deixo o link da apresentação original do evento para quem tiver curiosidade: https://www.slideshare.net/ConcreteS/pos-on-beer-rj-79730623.

Fontes de Pesquisa:

http://artia.com/blog/voce-sabe-o-que-e-gestao-agil-e-quais-sao-suas-metodologias/

https://www.sebrae.com.br/sites/PortalSebrae/artigos/entenda-o-que-e-lean-startup,03ebb2a178c83410VgnVCM1000003b74010aRCRD

https://medium.com/olxbr-design/product-discovery-a8dc701f50b

https://qualidadebr.wordpress.com/2010/11/22/processo-incremental-x-iterativo/

https://blog.productboard.com/the-age-of-product-discovery-part-ii-aebc7f755223

http://felipecastro.com/pt-br/okr/o-que-e-okr/

https://www.slideshare.net/AndressaChiaraCSMCSP/tdc-floripa-workshop-product-discovery

http://www.devmedia.com.br/personas-e-user-story-mapping-identificando-o-seu-verdadeiro-publico-alvo/31699

http://www.caroli.org/o-produto-e-nao-e-faz-nao-faz/

https://www.concrete.com.br/2015/04/27/ferramentas-de-priorizacao-de-problemas/

Ferramentas de priorização de problemas: retrospectivas mais efetivas –

Siga a tag codelikeagirlBR para ver nossos posts! 😀

Quer escrever ou traduzir artigos em português para a Code Like A Girl? Se você já faz parte do time de escritoras(es) da Code Like A Girl basta enviar seu artigo diretamente para nossa publicação. Se você ainda não faz parte do nosso time, envie uma mensagem direta para a conta de twitter CodeLikeAGirlBr. Nós avaliaremos seu artigo e ajudaremos a refiná-lo para publicação.