Aula 01 - Visão de produto, objetivos mensuráveis e backlog

Aula: 01 - Visão de produto, objetivos mensuráveis e backlog
Objetivos: Compreender a relação entre visão de produto, objetivos mensuráveis e backlog.
Curso: CST em Análise e Desenvolvimento de Sistemas
Série: 4º Semestre (semestral)
Disciplina: Gerenciamento de Projetos Ágil

1. Por que começar pela visão e pelos objetivos

Alinhamento: a visão de produto é o norte que orienta decisões estratégicas e táticas.
Foco em valor: objetivos mensuráveis traduzem visão em resultados de negócio e de usuário (outcomes).
Execução: o backlog conecta objetivos a entregas incrementais.

Diagrama de relação entre artefatos:

2. Visão de produto: fundamentos e prática (1.1)

2.1 Conceito e propósito

Declara, de forma concisa, a mudança que o produto quer provocar para um público específico.
Responde a: para quem, qual problema, qual benefício, qual diferencial.

2.2 Template de visão (elevator pitch)

Use como guia para sintetizar o propósito:

Para [segmento/persona],
que [necessidade/dor],
o [nome do produto]
é um [categoria/solução]
que [principal benefício].
Diferentemente de [alternativas],
nosso produto [diferencial-chave].

Exemplo para um app de biblioteca universitária:

Para estudantes de graduação,
que precisam encontrar e reservar materiais rapidamente,
o UniBooks
é um aplicativo de acervo e empréstimos
que permite busca unificada e retirada express no campus.
Diferentemente do site atual,
o UniBooks oferece notificações inteligentes e espera virtual.

2.3 Personas e stakeholders

Persona: representação do usuário-alvo (metas, comportamentos, dores).
Stakeholders: patrocinadores, áreas de negócio, TI, jurídico, suporte.

Checklist de validação de visão: - Problema e público claramente definidos - Benefício principal específico - Diferencial verificável - Alinhamento com estratégia institucional

2.4 Outcomes versus outputs

Outputs: entregas (telas, APIs, features).
Outcomes: mudanças de comportamento/resultado (ex.: aumentar taxa de empréstimos digitais em 20%).
Medir outcomes orienta decisões sobre o que priorizar no backlog.

2.5 Objetivos mensuráveis

Abordagens complementares:

SMART
- Específico, Mensurável, Atingível, Relevante, Temporal
OKRs
- Objective (inspirador) + Key Results (métricas de resultado)
North Star Metric (NSM)
- Métrica-síntese que correlaciona uso/valor (ex.: livros emprestados por usuário ativo/mês)

Exemplo de objetivo SMART:

objetivo: "Aumentar o uso do catálogo digital"
smart:
  especifico: "Aumentar reservas digitais pelos estudantes de graduação"
  mensuravel: "de 1.200 para 1.800/mês (+50%)"
  atingivel: "com base na média de crescimento após notificações"
  relevante: "eleva acesso ao acervo, reduz filas físicas"
  temporal: "em 90 dias"

Exemplo de OKR:

objective: "Tornar o empréstimo digital a forma preferida dos alunos"
key_results:
  - "Aumentar a taxa de reservas digitais de 30% para 55%"
  - "Reduzir abandono do fluxo de reserva de 35% para 15%"
  - "Elevar NPS do app de 42 para 60"

2.6 Do Product Goal ao roadmap de alto nível

Product Goal (Scrum): resultado de longo prazo para o produto.
Roadmap Now-Next-Later: estabelece linha de evolução sem comprometer datas rígidas.

Exemplo de Product Goal:

Product Goal: Tornar o UniBooks o canal principal de acesso ao acervo, atingindo 60% das reservas via app em 2 semestres.

Roadmap de temas:

now:
  - "Busca unificada + reservas digitais"
  - "Notificações de disponibilidade"
next:
  - "Recomendações personalizadas"
  - "Fila virtual e retirada express"
later:
  - "Integração com bibliotecas parceiras"
  - "Gamificação do hábito de leitura"

3. Do objetivo ao backlog (1.2)

3.1 O que é o Product Backlog

Lista ordenada e evolutiva do que pode ser feito para maximizar valor.
Não é uma lista de tarefas técnicas isoladas; é orientado a valor e aprendizado.

Níveis comuns de granularidade: - Épico: iniciativa ampla que suporta um objetivo. - Feature/Capacidade: conjunto coerente de valor. - História de usuário: fatia vertical, menor, testável. - Tarefa/Subtarefa: passos técnicos para entregar a história. - Spike: investigação/experimento com tempo limitado.

3.2 Decomposição: da visão às histórias

Estratégias de fatiamento: - Fatie por fluxo de usuário (descoberta → seleção → confirmação → notificação). - Fatie por regras de negócio (mínimo funcional antes de variações). - Fatie por risco/aprendizado (entregar primeiro o que valida hipótese crítica).

Exemplo de árvore de decomposição:

3.3 Escrevendo boas histórias de usuário

Template clássico:

Como [tipo de usuário],
quero [capacidade],
para [benefício].

Exemplos:

Como estudante,
quero buscar livros por título/autor,
para encontrar rapidamente o que preciso.

Como estudante,
quero confirmar uma reserva em até dois passos,
para não abandonar o processo em filas longas.

INVEST como guia de qualidade: - Independente - Negociável - Valiosa - Estimável - Pequena - Testável

Anti-padrões comuns: - Histórias muito grandes (épico disfarçado) - Especificar solução de UI rígida em vez de resultado - Critérios vagos (“funcionar bem”) - Itens puramente técnicos sem ligação com valor/risco

3.4 Ordenação e priorização do backlog

Critérios práticos: - Valor esperado (impacto em OKR/NSM) - Urgência (janelas de oportunidade, prazos regulatórios) - Risco/incerteza (validar cedo) - Esforço/complexidade

Métodos úteis: - MoSCoW (Must, Should, Could, Won’t) - Matriz Valor x Esforço (rápida para workshops) - RICE (Reach, Impact, Confidence, Effort) quando há dados

Exemplo simples de matriz Valor x Esforço:

alto_valor_baixo_esforco:
  - "Filtro por disponibilidade"
  - "Confirmação em 2 passos"
alto_valor_alto_esforco:
  - "Fila virtual com previsão"
baixo_valor_baixo_esforco:
  - "Tema escuro"
baixo_valor_alto_esforco:
  - "AR para localização na estante"

3.5 Critérios de aceite: tornando valor verificável

Definem condições objetivas para considerar uma história aceita pelo Product Owner.
Diferem de Definition of Done (DoD), que cobre a qualidade geral do incremento (abordada em aula futura).
Devem ser claros, binários e testáveis, incluindo, quando relevante, requisitos não funcionais.

Exemplo de critérios de aceite (lista):

historia: "Confirmar reserva em 2 passos"
criterios_aceite:
  - "Passo 1: seleção do exemplar disponível"
  - "Passo 2: confirmação do local de retirada"
  - "Tempo médio de resposta < 500 ms no 95º percentil"
  - "Mensagens de erro claras para exemplar indisponível"
  - "Registro de auditoria (quem, quando, qual exemplar)"

Critérios de aceite em Gherkin:

Funcionalidade: Reserva em dois passos
  Como estudante
  Quero confirmar uma reserva em dois passos
  Para reduzir o abandono do fluxo

  Cenário: Reserva concluída com exemplar disponível
    Dado que "existe exemplar disponível do livro 'Engenharia de Software'"
    E que "estou autenticado no app"
    Quando "seleciono o exemplar e confirmo a retirada no Campus Centro"
    Então "vejo a confirmação de reserva com código e prazo de retirada"
    E "recebo notificação push em até 60 segundos"

  Cenário: Indisponibilidade durante a confirmação
    Dado que "outro usuário reservou o último exemplar"
    Quando "tento confirmar a reserva"
    Então "vejo mensagem 'Exemplar indisponível' e opções de fila virtual"

Critérios não funcionais (exemplos): - Desempenho: P95 < 500 ms, P99 < 900 ms - Segurança: senhas nunca em claro, logs sem dados sensíveis - Acessibilidade: contraste AA, suporte a leitor de tela - Observabilidade: métricas de taxa de erro e latência publicadas

3.6 Exemplo integrado: do objetivo ao backlog inicial

Objetivo mensurável:

objetivo: "Aumentar reservas digitais de 1.200 para 1.800/mês em 90 dias"
hipoteses:
  - "Busca mais eficaz reduz desistência por não encontrar itens"
  - "Fluxo em 2 passos diminui abandono em mobile"
metricas:
  - "Taxa de conversão busca→reserva"
  - "Abandono do fluxo de reserva"
  - "Reservas/mês por usuário ativo"

Backlog inicial ordenado:

- historia: "Filtro por disponibilidade na busca"
  valor: "Aumenta conversão em itens reserváveis"
  esforco_relativo: 3
  criterios_aceite:
    - "Exibir somente itens com ao menos um exemplar disponível"
    - "Alternar entre 'todos' e 'disponíveis' em um toque"
    - "Resposta < 300 ms em consulta cacheada"

- historia: "Confirmação de reserva em 2 passos"
  valor: "Reduz abandono do fluxo"
  esforco_relativo: 5
  criterios_aceite:
    - "Dois passos: selecionar exemplar, confirmar retirada"
    - "Mensagens de erro objetivas"
    - "Tracking de eventos para funil de conversão"

- historia: "Notificação de disponibilidade"
  valor: "Retira gargalo de informação tardia"
  esforco_relativo: 3
  criterios_aceite:
    - "Push em até 60s após disponibilidade"
    - "Fallback por e-mail"
    - "Opt-out configurável"

- spike: "Teste A/B de rótulos na busca"
  objetivo: "Verificar se 'Disponível agora' aumenta cliques em 10%"
  limite_tempo: "8 horas"

História com critérios em Gherkin:

Funcionalidade: Filtro por disponibilidade
  Cenário: Exibir apenas itens disponíveis
    Dado que "acesso a busca"
    Quando "ativo o filtro 'Disponível agora'"
    Então "vejo apenas títulos com ao menos um exemplar disponível"
    E "o total de resultados atualiza em até 300 ms"

3.7 Refinamento contínuo

Sessões regulares para detalhar, dividir e estimar itens prioritários.
Resultados esperados do refinamento:
- Histórias INVEST
- Critérios de aceite claros
- Riscos conhecidos e próximos passos de aprendizado
- Ordem atualizada com base em dados recentes

Checklist de qualidade do item pronto para desenvolvimento: - Conecta-se a um objetivo/OKR ativo - Valor e impacto explícitos - Critérios de aceite testáveis (funcionais e, se aplicável, não funcionais) - Aspectos de segurança e acessibilidade considerados - Dependências mapeadas e mitigadas

4. Estudos de caso curtos

4.1 Marketplace local: reduzir cancelamentos

Visão: “Conectar pequenos mercados a consumidores do bairro com entregas no mesmo dia.”
Objetivo: “Reduzir cancelamentos do pedido de 12% para 6% em 60 dias.”
Hipótese: “Mostrar estoque em tempo real na listagem reduz cancelamentos pós-pagamento.”

Backlog focado no objetivo:

- historia: "Indicador de estoque em tempo real na listagem"
  criterios_aceite:
    - "Exibir 'Em estoque', 'Baixo estoque', 'Esgotado'"
    - "Atualização a cada 15s"
- historia: "Substitutos sugeridos para itens esgotados"
  criterios_aceite:
    - "Sugerir 3 itens equivalentes com justificativa"
- historia: "Alerta de esgotamento no carrinho"
  criterios_aceite:
    - "Bloquear checkout com item esgotado e oferecer substitutos"

Métrica de sucesso: - Cancelamentos ≤ 6% e aumento da taxa de conclusão de checkout.

4.2 App de educação: elevar engajamento semanal

Visão: “Personalizar o estudo para acelerar a aprendizagem.”
Objetivo: “Elevar sessões semanais médias por aluno de 1,8 para 3,0 em 90 dias.”

Backlog inicial:

- historia: "Trilha personalizada por objetivo de prova"
- historia: "Lembretes inteligentes baseados em hábito"
- historia: "Resumo gamificado semanal"

Métricas: - Sessões/semana, retenção D7/D30, conclusão de módulos.

5. Boas práticas e armadilhas

Boas práticas: - Comece pelo problema do usuário, não pela solução. - Relacione cada item do backlog a um objetivo ativo. - Escreva critérios de aceite primeiro (ATDD: Acceptance Test-Driven Development). - Fatie verticalmente para validar valor de ponta a ponta. - Reavalie ordenação com dados reais (telemetria, testes A/B).

Armadilhas: - Acumular épicos sem decompor em fatias entregáveis. - Confundir “feito tecnicamente” com “valor entregue”. - Critérios de aceite que não podem ser testados. - Priorizar por “opinião do HIPPO” (Highest Paid Person’s Opinion) sem dados. - Ignorar requisitos não funcionais até a véspera do release.

6. Exercícios propostos

Redigir visão

Escreva a visão do produto de um “Portal de Estágios da Faculdade” usando o template de elevator pitch.

Definir objetivos mensuráveis

Produza 1 objetivo SMART e 2 Key Results alinhados à visão acima.

Criar backlog inicial

Liste 5 histórias de usuário que maximizem o alcance do objetivo no curto prazo.
Para 2 histórias, redija critérios de aceite em Gherkin.

Priorização rápida

Classifique as 5 histórias na matriz Valor x Esforço e justifique a história no topo.

Revisão por pares

Troque o material com um colega e use o checklist:
- A visão declara público, dor, benefício e diferencial?
- Objetivos têm métrica e prazo?
- Histórias seguem INVEST?
- Critérios de aceite são binários e testáveis?

7. Referências de apoio

Scrum Guide 2020 (conceitos de Product Goal e Product Backlog)
Melissa Perri — Escaping the Build Trap (orientação a outcomes)
Roman Pichler — Product Vision Board
Marty Cagan — Inspired (descoberta e produto)
Teresa Torres — Continuous Discovery Habits (descoberta contínua)

Conclusão

Nesta aula, conectamos visão de produto, objetivos mensuráveis e backlog como um fluxo contínuo de entrega de valor. Partimos da definição clara do problema e do público, traduzimos isso em objetivos SMART/OKRs e, então, estruturamos um backlog orientado a outcomes, com histórias INVEST e critérios de aceite testáveis. Essa trilha assegura que cada incremento contribua para metas claras e verificáveis, reduzindo desperdício e elevando a previsibilidade do valor entregue.

Próxima aula

Planejamento de iteração e políticas de fluxo: vamos transformar backlog priorizado em um plano de trabalho viável, introduzindo práticas de planejamento de iteração e os conceitos de Definition of Ready (DoR) e Definition of Done (DoD) como instrumentos para garantir fluxo e qualidade desde o início.