8 min leitura • Guide 788 of 877
Responsabilidades do Product Owner
O Product Owner faz a ponte entre negócio e desenvolvimento. O GitScrum fornece ferramentas para POs gerenciarem backlogs, prioridades e comunicação com stakeholders.
Responsabilidades do PO
Deveres Principais
PAPEL DO PRODUCT OWNER:
┌─────────────────────────────────────────────────────────────┐
│ │
│ RESPONSABILIDADES PRIMÁRIAS: │
│ │
│ 1. VISÃO DO PRODUTO │
│ ──────────────────── │
│ • Definir estratégia do produto │
│ • Comunicar visão ao time │
│ • Alinhar trabalho com objetivos de negócio │
│ • Tomar decisões de trade-off │
│ │
│ 2. GESTÃO DE BACKLOG │
│ ───────────────────── │
│ • Criar e manter backlog │
│ • Ordenar por prioridade/valor │
│ • Manter backlog refinado │
│ • Remover itens desatualizados │
│ │
│ 3. REQUISITOS │
│ ─────────── │
│ • Escrever user stories │
│ • Definir critérios de aceite │
│ • Clarificar requisitos │
│ • Fornecer contexto │
│ │
│ 4. GESTÃO DE STAKEHOLDERS │
│ ────────────────────────── │
│ • Coletar input de stakeholders │
│ • Comunicar progresso │
│ • Gerenciar expectativas │
│ • Proteger time do caos │
│ │
│ 5. ACEITE │
│ ──────── │
│ • Revisar trabalho completado │
│ • Aceitar ou rejeitar stories │
│ • Fornecer feedback │
└─────────────────────────────────────────────────────────────┘
Atividades Diárias
RITMO SEMANAL DO PO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DIÁRIO: │
│ ──────── │
│ • Disponível para perguntas do time │
│ • Revisar trabalho completado │
│ • Clarificar requisitos │
│ • Participar da daily (opcional mas útil) │
│ │
│ SEMANAL: │
│ ────────── │
│ • Refinamento de backlog com time │
│ • Reuniões com stakeholders │
│ • Revisão de prioridades │
│ • Escrita de stories │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CERIMÔNIAS DO SPRINT: │
│ │
│ PLANNING: │
│ • Apresentar meta do sprint │
│ • Explicar prioridades principais │
│ • Responder perguntas │
│ • Confirmar escopo com time │
│ │
│ REFINAMENTO: │
│ • Apresentar stories futuras │
│ • Clarificar requisitos │
│ • Aceitar estimativas do time │
│ │
│ DEMO: │
│ • Coordenar com stakeholders │
│ • Aceitar/rejeitar trabalho completado │
│ • Coletar feedback │
│ │
│ RETRO: │
│ • Participar como membro do time │
│ • Ouvir feedback do time │
│ • Comprometer-se com melhorias │
└─────────────────────────────────────────────────────────────┘
Gestão de Backlog
Priorização
ABORDAGEM DE PRIORIZAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FRAMEWORKS DE PRIORIZAÇÃO: │
│ │
│ VALOR VS ESFORÇO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ALTO VALOR ││
│ │ │ ││
│ │ ┌───────────┼───────────┐ ││
│ │ │ Quick │ Big │ ││
│ │ │ Wins ★★★ │ Bets ★★ │ ││
│ │ BAIXO ──┼───────────┼───────────┤──── ALTO ││
│ │ ESFORÇO │ Talvez │ Evitar │ ESFORÇO ││
│ │ │ Depois ★ │ ☆ │ ││
│ │ └───────────┼───────────┘ ││
│ │ │ ││
│ │ BAIXO VALOR ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ORDEM DE PRIORIDADE: │
│ 1. Quick Wins (alto valor, baixo esforço) │
│ 2. Big Bets (alto valor, alto esforço) │
│ 3. Talvez Depois (baixo valor, baixo esforço) │
│ 4. Evitar (baixo valor, alto esforço) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ MOSCOW: │
│ M - Must have (necessário para MVP/release) │
│ S - Should have (importante mas não crítico) │
│ C - Could have (bom ter) │
│ W - Won't have (explicitamente fora do escopo) │
│ │
│ EXEMPLO DE BACKLOG: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PRIORIDADE STORY MOSCOW ││
│ │ ────────── ───── ────── ││
│ │ 1 Login de usuário MUST ││
│ │ 2 Reset de senha MUST ││
│ │ 3 Login social SHOULD ││
│ │ 4 Lembrar-me COULD ││
│ │ 5 Auth biométrica WON'T ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Escrevendo Stories
QUALIDADE DE USER STORY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TEMPLATE DE STORY: │
│ │
│ COMO UM [tipo de usuário] │
│ EU QUERO [capacidade] │
│ PARA QUE [benefício] │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EXEMPLO DE BOA STORY: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ STORY-456: Receber notificação de envio do pedido ││
│ │ ││
│ │ Como um cliente ││
│ │ Eu quero receber um email quando meu pedido é enviado ││
│ │ Para que eu saiba quando esperar a entrega ││
│ │ ││
│ │ CRITÉRIOS DE ACEITE: ││
│ │ ☐ Email enviado quando status do pedido = enviado ││
│ │ ☐ Email inclui número do pedido ││
│ │ ☐ Email inclui link de rastreamento ││
│ │ ☐ Email inclui data estimada de entrega ││
│ │ ☐ Usuário pode optar por não receber nas preferências ││
│ │ ││
│ │ CONTEXTO: ││
│ │ Atualmente 30% dos tickets de suporte perguntam ││
│ │ "cadê meu pedido?" - isso deve reduzir em 50%. ││
│ │ ││
│ │ FORA DO ESCOPO: ││
│ │ • Push notifications (story futura) ││
│ │ • Notificações SMS (story futura) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CRITÉRIOS INVEST: │
│ I - Independente (pode ser feito sozinho) │
│ N - Negociável (time pode discutir como) │
│ V - Valiosa (entrega valor ao usuário) │
│ E - Estimável (time consegue estimar) │
│ S - Small (cabe em um sprint) │
│ T - Testável (critérios de aceite claros) │
└─────────────────────────────────────────────────────────────┘
Gestão de Stakeholders
Gerenciando Expectativas
COMUNICAÇÃO COM STAKEHOLDERS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PO COMO FILTRO: │
│ │
│ STAKEHOLDERS ──→ PO ──→ TIME │
│ │ │
│ Prioriza │
│ Clarifica │
│ Protege │
│ │
│ Sem PO: │
│ Stakeholders ──→ Time (caos!) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ REUNIÕES COM STAKEHOLDERS: │
│ │
│ COLETA DE INPUT: │
│ "Me conte sobre o problema que você está enfrentando" │
│ "Como seria o sucesso?" │
│ "Como isso ajudaria os usuários?" │
│ │
│ NÃO: Deixar stakeholders ditar soluções │
│ SIM: Entender a necessidade subjacente │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DIZENDO NÃO: │
│ │
│ "Isso é valioso. Aqui está por que não é prioridade:" │
│ "Temos X, Y, Z antes porque..." │
│ "Se isso é urgente, o que devemos despriorizar?" │
│ │
│ NUNCA: "Vamos tentar encaixar" │
│ (Cria expectativas falsas) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ UPDATES DE STATUS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DASHBOARD DE STAKEHOLDERS ││
│ │ ││
│ │ Progresso Sprint 12 ││
│ │ ═══════════════════════════░░░░░░░░░ 70% ││
│ │ ││
│ │ ✅ Feature login - Completo ││
│ │ 🔄 Reset de senha - Em progresso ││
│ │ 📅 Login social - Próximo sprint ││
│ │ ││
│ │ RISCOS: ││
│ │ • Dependência de API pode atrasar login social ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Trabalhando com o Time
Colaboração
DINÂMICA PO + TIME:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PO DECIDE: │
│ ────────── │
│ • O QUE construir (requisitos) │
│ • POR QUE construir (valor) │
│ • QUANDO é necessário (prioridade) │
│ • SE está pronto (aceite) │
│ │
│ TIME DECIDE: │
│ ──────────── │
│ • COMO construir (abordagem técnica) │
│ • QUANTO TEMPO leva (estimativas) │
│ • QUANTO podem fazer (capacidade) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DISPONIBILIDADE: │
│ │
│ ✅ BOM PO: │
│ • Responde perguntas no mesmo dia │
│ • Disponível durante refinamento │
│ • Revisa trabalho prontamente │
│ • Claro quando indisponível │
│ │
│ ❌ MAU PO: │
│ • "Eu volto pra você" (nunca volta) │
│ • Nunca no refinamento │
│ • Stories ficam esperando aceite │
│ • Time bloqueado esperando decisões │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ACEITE: │
│ │
│ Quando time diz "pronto": │
│ │
│ 1. Revisar contra critérios de aceite │
│ 2. Testar a funcionalidade │
│ 3. ACEITAR ou REJEITAR com feedback │
│ 4. Se rejeitar: Feedback claro e acionável │
│ │
│ ACEITAR: "Isso atende os critérios, ótimo trabalho!" │
│ REJEITAR: "Link de rastreamento não é clicável (crit. 3)"│
│ │
│ Não: Rejeitar por coisas fora dos critérios de aceite │
│ Não: Adicionar novos requisitos após desenvolvimento │
└─────────────────────────────────────────────────────────────┘