Práticas Ágeis - Produto

Prévia do material em texto

1
2
De acordo com a variedade de produto que temos, podemos conhecer ou não nossos 
usuários. Eles podem estar perto, serem poucos ou aos milhares espalhados pelo planeta. O 
fundamental é conhecer, saber o que querem, qual a linguagem mais adequada para nos 
comunicar com eles, quais os pontos de dor que sentem e que o aplicativo vai ajudar a 
resolver. Pode haver mais de um grupo de usuários com intuitos diferentes ao usar o 
produto, por isso precisamos tentar construir o produto mais adequado para necessidades 
distintas.
O produto pode estar relacionado a um público mais jovem, teu usuário pode ter 
familiaridade ou não com aplicativos, podem já usar um produto similar no mercado ou 
podemos lançar uma novidade. Em todas as ocasiões é fundamental conhecê-los, entender 
suas dores e necessidades, entender o caminho percorrido para o uso do aplicativo (produto) 
que estamos cuidando, para que ele seja aceito por todos.
Atenção: cliente e usuário, muitas vezes utilizado como sinônimo, mas usuário é quem usa 
seu produto e cliente é quem paga a conta, em alguns caso isso pode fazer muita diferença. 
Exemplo: um produto para pets, na verdade estamos falando a linguagem do dono do pet, 
atraindo ele, ele é o cliente que compra, mas precisamos incluir os pontos de dor do pet, 
desenhar o produto para o pet, para que o usuário fique satisfeito e volte a comprar 
produtos.
3
4
Steve Jobs, o gênio por trás da experiência única do cliente da Apple, disse: “Você tem que 
começar com a experiência do cliente e só então trabalhar a tecnologia, não o contrário”. 
Hoje em dia, uma visão e uma estratégia claras para as interações com o cliente não são mais 
um “bom ter” - é essencial. Entender, avaliar e refinar a experiência do cliente, uma das 
maneiras mais poderosas de compreender seu estado atual e os estados futuros é um mapa 
da jornada do cliente/usuário.
Um mapa da jornada do cliente/usuário é uma representação visual da experiência do 
cliente com seu produto.
A seguir os passos para a criação da jornada do usuário:
- Definir os objetivos
- Realizar pesquisa pessoais
- Defina os pontos de contato com o cliente
- Mapeie o estado atual
- Mapeie estados futuros
5
6
7
A visão declara seu objetivo geral, a razão final para criar o produto, a mudança positiva que 
você deseja realizar. Torne sua visão grande e inspiradora; use uma breve declaração ou 
slogan; e garanta que as partes interessadas e as equipes de desenvolvimento o apoiem, que 
ele seja compartilhado.
Grupo-alvo descreve o mercado ou segmento de mercado que você deseja abordar. Você 
deve declarar quem é provável que o produto se beneficie, quem são seus usuários e 
clientes.
Necessidades descreve a proposta de valor do produto: o principal problema que o produto 
aborda ou o principal benefício que ele oferece. Deve deixar claro por que as pessoas vão 
querer usar o produto ou pagar por ele. Capture o que significa sucesso para usuários e 
clientes. Se você identificar várias necessidades, priorize-as.
Produto resume os três a cinco recursos que fazem seu produto se destacar e que são 
essenciais para seu sucesso. Eles provavelmente estão relacionados à sua proposta de venda 
exclusiva e devem atender às necessidades identificadas. Não cometa o erro de listar muitos 
recursos. Limite-se a no máximo 5. Capture os detalhes do produto em um estágio posterior 
em sua carteira de produtos.
Objetivos de negócios define o porquê vale a pena para sua empresa investir no produto. 
Declara os benefícios comerciais desejados, por exemplo, aumentar a receita, entrar em um 
novo mercado, reduzir custos, desenvolver a marca ou adquirir conhecimento valioso. 
(https://www.romanpichler.com/blog/the-product-vision-board/)
(https://www.romanpichler.com/blog/tips-for-writing-compelling-product-vision/)
8
O objetivo principal do canvas MVP é validar ideias para a versão mais simples de um 
produto que pode ser disponibilizada/comercializada.
Vamos ao board: MVP Vision informa qual é a visão deste MVP.
Do lado esquerdo: foco no usuário, relacionado ao Design Thinking. Quero avaliar meu 
usuário (Personas & Platforms), o que ele quer fazer (Journeys) para definir as ações a serem 
construídas no sistema (Features). Personas representam os usuários, funcionalidades as 
ações do sistema e na jornada desenhamos o passo a passo para cumprir um objetivo.
Do lado direito: relacionado ao Lean Statup. Depois que construir o sistema, o que é preciso 
medir para perceber se tive sucesso ou não (aprende com resultado)? Outcome são os 
resultados esperados, e mostra o que nós queremos aprender, as Features são as 
funcionalidades, que representa o que precisamos construir e as Metrics for business que 
representa o que queremos medir (veja o fluxo construir -> medir -> aprender)
Saiba mais em https://www.caroli.org/o-canvas-mvp/
9
10
11
É fácil ter, em produtos digitais, um cenário onde o usuário final não está por perto 
do mapeamento da visão e necessidades, esse é um erro comum. Um outro aspecto, 
depois de tentar reunir todos os envolvidos é mantê-los engajados e participativos 
durante o processo.
A empatia significa buscar se sentir como um usuário, para compreender as dores e 
planejar as melhores alternativas.
12
13
O formato de User Stories mais famoso é o Connextra que assume a seguinte abordagem: 
COMO UM, EU QUERO, PARA QUE
As histórias podem ser técnicas ou de negócio, mas independente do tipo devem ser 
priorizadas de acordo com o valor de retorno que trás para o produto.
14
Bill Wake, autor do livro “Extreme Programming Explored”, descreveu em seu blog quais seriam as características
de boas User Stories. Ele formou o acrônimo INVEST (“investir”, em inglês) com a primeira letra de cada uma
dessas características, afirmando que devemos “investir em boas User Stories” (Wake, 2003).
De acordo com Wake, uma User Story deve ser:
independente: User Stories devem ser o mais independentes ou desacopladas possível umas das outras, ou seja,
User Stories com grande número de dependências em outras User Stories devem ser evitadas. Essa
independência visa ser viável alterar livremente a ordem que serão desenvolvidas e, ao fazê-lo, não ser
necessário alterar suas estimativas. Cabe adicionar que uma User Story se traduzirá sempre em uma
funcionalidade de ponta a ponta, que representa valor para o usuário. Além disso, deve ser possível entender
uma User Story sem ser necessário ler quaisquer outras;
negociável e negociada: seus detalhes serão discutidos, negociados e definidos entre as pessoas de negócios
(com o Product Owner, entre elas) e o Time de Desenvolvimento. São as “Conversas”, dos três C’s;
valiosa: devem representar valor de negócio para os clientes do projeto. Ao dividir-se uma User Story, o resultado
dessa divisão deve ser User Stories menores que também representem funcionalidades de ponta a ponta, e não
partes de trabalho técnico;
estimável: o Time de Desenvolvimento deve possuir detalhes suficientes — tanto técnicos quanto de negócios —
para estimar o trabalho de se transformar a User Story em parte do produto, de forma que o Product Owner
possa ordená-la apropriadamente. Assim, conversas suficientes devem ser realizadas entre as pessoas de
negócios e os membros do Time de Desenvolvimento para se obter os detalhes de negócios da User Story a ser
desenvolvida. Os membros do Time de Desenvolvimento devem discutir possíveis soluções e executar pequenos
experimentos, caso necessário, para reduzir os riscos técnicos da User Story. É claro que o nível de detalhes
necessário depende de quão próxima a User Story está de ser colocada em desenvolvimento. Estimativas
fornecem o custo de desenvolvimento de uma User Story. Mesmo caso não se utilizem estimativas, os detalhes
são necessários para dividir as User Stories de forma que fiquem pequenas o suficiente para serem desenvolvidas;
pequena (“small”, em inglês) ou dimensionada apropriadamente: apenas User Stories pequenas e com um bom
nível de detalhes podem sercolocadas em desenvolvimento. Quanto mais para baixo no Product Backlog a User
Story estiver, maior ela será, a princípio. User Stories pequenas próximas a seu desenvolvimento têm maior
precisão em suas estimativas, permitem um melhor ordenamento do Product Backlog e representam um menor
risco ao possibilitarem que mais itens façam parte de um Sprint;
testável — deve ser possível verificar e confirmar que a User Story está pronta, ou seja, que foi transformada em
parte do produto e está funcionando conforme esperado. A verificação é realizada por meio dos Critérios e Testes
de Aceitação. É a “Confirmação”, dos três C’s.
15
16
As histórias no topo do backlog têm nível de granularidade mais detalhado, possivelmente já 
discutido com o time e é passível de desenvolvimento, está ready (pronto para o 
desenvolvimento – verificar se está atendendo ao critério de ready nos acordos do time). O 
time não pode ser impactado ao puxar uma história para desenvolvimento e descobrir que a 
mesma ainda não está completamente entendida, falta definição ou ser surpreendida com 
novos critérios de aceite não discutidos antes.
17
O Product Backlog é ordenado, de forma que seus itens são tão menores e mais detalhados 
quanto mais acima estiverem nessa lista. Os itens da parte superior do Product Backlog são 
pequenos e possuem detalhes suficientes que os permitem serem aceitos no próximo Sprint
para desenvolvimento. Os itens mais abaixo são cada vez maiores e menos detalhados.
Épicos são User Stories que representam itens grandes demais ou sem detalhes suficientes 
para serem desenvolvidos. Enquanto épicos, essas User Stories somente necessitarão de mais 
detalhes quando ganharem prioridade.
À medida que ganha prioridade, o épico ou parte dele evolui para User Stories menores (veja 
a figura [ref-label 9-13]).
Temas são coleções ou conjuntos de User Stories que estão relacionadas e, assim, podem ser 
agrupadas. Razões para agrupar User Stories em temas incluem, entre outras:
juntas definem uma meta de negócios específica;
são provenientes de um mesmo épico;
pertencem a um Time de Desenvolvimento em um ambiente com múltiplos times 
trabalhando a partir de um mesmo Product Backlog.
O agrupamento de User Stories em temas relacionados a metas de negócios pode facilitar o 
trabalho de ordenação do Product Backlog em planejamentos mais longos, mantendo-se o 
foco em quais metas são mais importantes de serem atingidas primeiro ao invés de manter-
se o foco em itens individuais.
Cada tema geralmente possui um curto título que o identifica.
18
19
20
21
22
23
Formas de avaliação do método
- Quantitativo: apoiado por números
- Qualitativo: baseado em opiniões, portanto subjetivo, baseado na experiência e 
palpite do especialista entrevistado.
Origem do dado
- Interna: o dado vem de dentro da organização, por exemplo: do time de 
desenvolvimento, dos gestores, diretoria, etc.
- Externa: o dado vem de fora da empresa, por exemplo: interessados no produto 
(stakeholder) ou cliente.
24
25
Na Matriz de Eisenhower (é, o nome do inventor é estranho mesmo!) as tarefas são divididas 
em quadrantes de acordo com a importância e urgência.
Classifique como:
- Crise quando não há tempo a perder, são as tarefas que precisam estar no topo da sua lista.
- As tarefas são alocadas no quadrante Metas e planos quando ainda há tempo para se 
programar para fazer.
- Tarefas não tão importantes mas que têm alguma urgência para ser resolvidas são tratadas 
como Interrupções, aqui a dica é delegue ou faça apenas o que não for atrapalhar seu 
trabalho.
- Quando a tarefa não for importante e nem urgente – evite-as e coloque-as em Distrações.
Lembrete: quando tudo é urgente e importante, não temos priorização!
26
A técnica MoSCoW é formada do acrônimo das palavras Must, Should, Could e Would ajuda a indicar a prioridade das tarefas 
(ou histórias). Uma vez que os requisitos foram reunidos e os acordos foram alcançados entre as partes interessadas, as equipes 
podem começar a atribuir requisitos a cada uma das quatro categorias a seguir:
M – Must Have = Deve ter. Esta primeira categoria inclui todos os requisitos essenciais para a conclusão bem-sucedida do 
projeto. Devem ser elementos não negociáveis que fornecem o subconjunto mínimo u lizável (DEVE) de requisitos. Por 
exemplo, o aplicativo de transporte precisa ter: solicitar viagem, escolher destino, dentre outros. Os itens essenciais podem ser 
definidos como: 1)Não adianta concluir o projeto dentro do prazo final sem este requisito. 2) O produto final ou software não 
seria compatível ou legal sem este requisito. 3) O produto final ou software não seria seguro sem este requisito. 4) O produto 
final ou software não fornecerá uma solução eficaz sem esse requisito.
Se houver alguma maneira de contornar um requisito específico, ele deve ser considerado um elemento na coluna Should
(deveria ter) ou Could (poderia ter). É importante observar que atribuir requisitos às categorias deveria ter e poderia ter não 
significa que o elemento não será entregue; apenas revela que não é essencial e, portanto, não é garantido.
S – Should Have = Deveria ter. Esta segunda categoria de requisitos pode ser usado para preparar requisitos para versões 
futuras sem impactar o projeto atual. Os elementos são importantes para a conclusão do projeto, mas não são essenciais. Em 
outras palavras, se os requisitos considerados aqui não estiverem incluídos no produto final, o produto ainda funcionará. No 
entanto, estes elementos forem incluídos, eles aumentarão muito o valor do produto. Pequenas correções de bugs, melhorias 
de desempenho e novas funcionalidades são exemplos de requisitos que podem se enquadrar nesta categoria.
Entre a primeira coluna e a segunda coluna, nesta segunda o requisito pode ficar de fora. Isso geralmente é medido em termos 
do valor do negócio ou do número de pessoas afetadas por sua ausência.
C - Pode ter. Esta categoria inclui requisitos que têm um impacto muito menor quando deixados de fora do projeto. Como 
resultado, os requisitos que podem ter são geralmente os primeiros a serem despriorizados - os requisitos essenciais e 
essenciais sempre terão precedência. Os que podem ter podem ser definidos como: Um elemento desejável, mas sem 
importância. Deixar de fora esse requisito impactará menos o produto do que deixar de fora um elemento que deveria ter.
W - Não vou ter. Esta categoria final inclui todos os requisitos que foram reconhecidos como não prioritários para o cronograma 
do projeto. Atribuir elementos à categoria que não terá ajuda a fortalecer o foco nos requisitos nas outras três categorias, ao 
mesmo tempo em que define expectativas realistas para o que não será incluído no produto final. Além disso, essa categoria é 
benéfica na prevenção do aumento do escopo - ou a tendência de aumento dos requisitos do produto ou projeto durante o 
desenvolvimento além do que foi antecipado. Alguns requisitos do grupo que não vai ter acabarão sendo priorizados e 
transformados em projetos futuros; outros nunca serão usados. Para diferenciar entre esses tipos de elementos, subcategorias 
podem ser criadas dentro do grupo que não terá para identificar quais requisitos ainda devem ser implementados e quais 
podem ser ignorados.
27
Buy a Feature
Esta dinâmica, como qualquer outra, precisa da participação de usuários e clientes. Uma 
parcela das features são apresentadas, é interessante separar umas 10 features para a 
reunião não ficar maçante. As features já devem ter estimativa de custo do desenvolvimento 
(pode ser usado story point). O custo total das features apresentadas deve ser calculado. O 
recurso, que é o dinheiro que compra as features, deve ser limitado a 30% e distribuído para 
os participantes (clientes e usuários).
É interessante se surgir barganha, mas o que deve ser considerado para redução do custo é a 
simplificação da funcionalidade e nunca o achatamento do preço.
Customizações:
Alguns pontos podem ser customizados de acordocom a necessidade do produto e dos 
participantes. Por exemplo: a divisão pode ser por área, se mais de um cliente de uma 
mesma área da empresa estiver participando. O percentual está proposto em 30%, mas pode 
ser adequado de acordo com o tempo e capacidade do time de desenvolvimento.
28
29
O modelo de Kano foi desenvolvido para ajudar as empresas a priorizarem a satisfação dos clientes. Kano, professor da 
Universidade de Tóquio, definiu uma metodologia para se conseguir encantar o cliente ao lhe entregar algo que vai além de 
suas expectativas. Nesse contexto, os requisitos do modelo de Kano são classificados em:
1- Requisitos atrativos: Se eles existirem, melhor. Mas se não existirem, não significa que o cliente não estará satisfeito. Eles 
podem atrair mais consumidores e diferenciar seu produto ou serviço, mas não são essenciais para seu sucesso. Exemple de 
modelo de Kano para requisitos atrativos: a) Restaurante que oferece estacionamento gratuito no local. B) Um carro com 
garantia de 5 anos, em vez de 1 ano. C) Uma companhia aérea que oferece milhas em dobro.
2- Requisitos unidimensionais ou de desempenho: Se eles estão presentes, trazem satisfação ao cliente e, além disso, quanto 
mais intensos, maior a satisfação. Em outras palavras: quanto maior seu desempenho, mais satisfeitos ficarão os clientes. 
Exemplo de modelo de Kano para requisitos unidimensionais: a) Quanto mais gostosas as comidas, mais satisfeitos os clientes. 
B) Quanto mais econômico, mais satisfação um carro trará ao cliente. C) O conforto é diretamente proporcional a satisfação do 
cliente.
3- Requisitos obrigatórios ou necessários: Sem eles o cliente, certamente, estará insatisfeito. Ele espera por eles e exige que 
estejam presentes. São características intrínsecas ao produto ou serviço, sem as quais ele será considerado extremamente 
insatisfatório. Exemplo de modelo de Kano para requisitos obrigatórios: a) Todo restaurante tem que ser limpo e higiênico, 
sem isso, nenhum cliente estará satisfeito. B) Um carro deve ser seguro, pois se apresenta risco aos seus ocupantes, não 
apresenta um requisito obrigatório que qualquer consumidor exige. C) Você decolaria em um avião de uma companhia aérea 
regular, cuja pintura estivesse descascando? Apesar de possivelmente isso não afetar seu desempenho ou segurança, para 
uma companhia aérea, aparentar ser segura em cada detalhe é um requisito obrigatório. Já, se você tivesse que pegar um 
ônibus para a cidade vizinha, possivelmente isso não faria diferença para você.
4- Requisitos indiferentes: Características que não afetam o grau de satisfação dos usuários estando ou não presentes e com 
qualquer grau de desempenho. Exemplo de modelo de Kano para requisitos indiferentes: a) O que importa para o cliente de 
um restaurante se o seu sistema de gestão de estoques é da empresa A ou B? b) Qual a diferença para o motorista de um 
automóvel se a cor dos cabos elétricos internos que ele não vê são azuis ou verdes? C) Um cliente se sentirá mais satisfeito 
com uma companhia aérea em função do seu consumo de combustível?
5- Requisitos reversos: Nesse caso, sua existência é percebida negativamente pelos clientes. Assim, tem um efeito reverso 
sobre sua satisfação. Exemplos de modelo de Kano para requisitos reversos: a) Um restaurante tão lotado que gera enormes 
filas, pode ser bom para o dono, mas desagrada aos clientes. B) Da mesma forma, quanto menor o espaço interno, menor a 
satisfação dos donos de veículos. C) Quanto menos opções e variedade no cardápio de uma companhia aérea, menor a 
satisfação de seus clientes.
(https://www.venki.com.br/blog/modelo-de-kano/)
30
RICE é um acrônimo para os quatro fatores que usamos para avaliar cada ideia de projeto: alcance, 
impacto, confiança e esforço.
O alcance é medido em número de pessoas / eventos por período de tempo. Isso pode ser “clientes 
por trimestre” ou “transações por mês”. Tanto quanto possível, use medidas reais de métricas de 
produto em vez de tirar números de um chapéu.
O impacto é o “quanto esse projeto aumentará a taxa de conversão quando um cliente o encontrar?”, 
ou como “aumentar a adoção” ou “maximizar o prazer”. Escala de múltipla escolha: 3 para “impacto 
massivo”, 2 para “alto”, 1 para “médio”, 0,5 para “baixo” e finalmente 0,25 para “mínimo”. Por 
exemplo: Projeto 1: Para cada cliente que o vir, isso terá um grande impacto. A pontuação de impacto 
é 3. Projeto 2: terá um impacto menor para cada cliente. A pontuação de impacto é 1. Projeto 3: Este é 
um ponto intermediário em termos de impacto. A pontuação de impacto é 2.
A confiança é uma porcentagem que indica quanto apoio você realmente tem para suas estimativas, a 
seguinte escala pode ajudar a classificação: 100% é “alta confiança”, 80% é “médio”, 50% é “baixo”. 
Exemplos: Projeto 1: temos métricas quantitativas para alcance, pesquisa de usuário para impacto e 
uma estimativa de engenharia para esforço (confiança de 100%). Projeto 2: Tenho dados para apoiar o 
alcance e o esforço, mas não tenho certeza sobre o impacto (confiança de 80%). Projeto 3: O alcance e 
o impacto podem ser menores do que o estimado e o esforço pode ser maior (confiança de 50%).
O esforço é uma estimativa de quanto trabalho teremos para criar a solução estime o tempo total que 
um projeto exigirá de todos os membros de sua equipe: produto, design e engenharia. O esforço é 
estimado como um número de “pessoas-mês” - o trabalho que um membro da equipe pode fazer em 
um mês. Exemplo: Projeto 1: Isso levará cerca de uma semana de planejamento, 1-2 semanas de 
design e 2-4 semanas de tempo de engenharia (esforço de 2 pessoas-mês). Projeto 2: Este projeto 
levará várias semanas de planejamento, uma quantidade significativa de tempo de design e pelo 
menos dois meses do tempo de um engenheiro (esforço de 4 pessoas-mês). Projeto 3: Isso requer 
apenas uma semana de planejamento, nenhum novo design e algumas semanas de tempo de 
engenharia (esforço de 1 pessoa-mês).
31
O cálculo é simples (alcance x impacto x confiança)/esforço. Ordene do maior para o menor e você 
terá uma lista priorizada de itens para o desenvolvimento.
31
Uma das maiores dificuldades no uso de qualquer tipo de priorização é alinhar as 
pessoas, deixar claro o que é, o que vai acontecer, o que é importante, quais regras. 
Colocando todos os envolvidos no desenvolvimento daquele produto na mesma 
direção.
O debate é sempre muito rico, colocar pessoas de diferentes áreas, com diferentes 
pontos de vista discutindo em prol do produto, participando e enriquecendo a 
priorização das features. Primeiro nós divergimos para depois convergir.
32
33
Mapa de histórias (story mapping)
“User Story Mapping é um mapa que organiza as histórias de usuário em um modelo que 
ajuda a compreender a funcionalidade do sistema, a identificar falhas no seu backlog, e a, 
efetivamente, planejar releases holísticas que oferecem valor aos usuários e ao negócio a 
cada versão”. Jeff Patton – The New User Story Backlog Is a Map.
É a big picture utilizada pelos times ágeis quando precisam visualizar roadmaps de produtos 
de alto nível e planos de releases. Expõe uma visão da forma como o trabalho vai ser 
desdobrado em três elementos:
Backbone (user activities): os temas que o usuário será capaz de executar com o fluxo de 
trabalho.
Walking skeleton (user tasks): são as tarefas que suportam o backbone. 
Histórias de usuário: representa a quebra das histórias que permitem a conclusão das 
tarefas.
(https://leonardo-matsumota.com/2019/03/14/o-mapa-de-historias-story-mapping-e-
roadmap-de-produto/)
34
35
36