Gerenciando Requisições de Features de Múltiplos Stakeholders
Lide com requisições de features concorrentes de forma justa. Construa um processo transparente que mantém stakeholders informados e alinhados.
8 min de leitura
Múltiplos stakeholders com prioridades concorrentes é normal - caos não precisa ser. O GitScrum ajuda a gerenciar requisições de features com formulários de entrada, sistemas de pontuação e roadmaps transparentes que alinham stakeholders em torno de prioridades compartilhadas.
Desafios de Gestão de Requisições
Problemas Comuns
CAOS DE REQUISIÇÕES DE STAKEHOLDERS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SINTOMAS: │
│ • Todo stakeholder acha que sua requisição é top priority │
│ • Requisições vêm por múltiplos canais │
│ • Sem critérios claros para o que é construído │
│ • "Quem grita mais" é priorizado │
│ • Mudanças de escopo constantes │
│ • Time frustrado com prioridades mudando │
│ • Stakeholders frustrados com falta de progresso │
│ │
│ CAUSAS RAIZ: │
│ • Sem processo formal de intake │
│ • Critérios de priorização obscuros │
│ • Falta de visibilidade nas restrições │
│ • Sem entendimento compartilhado de capacidade │
│ • Pressão política sobrepondo processo │
│ │
│ IMPACTO: │
│ • Time trabalha nas coisas erradas │
│ • Valor de negócio não maximizado │
│ • Relacionamentos tensionados │
│ • Produtividade perdida com troca de contexto │
│ │
│ SOLUÇÃO: Processo transparente e consistente │
│ que trata todos os stakeholders de forma justa │
└─────────────────────────────────────────────────────────────┘
Processo de Intake
Formulário de Requisição
INTAKE DE REQUISIÇÃO DE FEATURE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FORMULÁRIO DE REQUISIÇÃO DE FEATURE │
│ │
│ Solicitante: ___________ Departamento: ___________ │
│ Data: ___________ Prioridade solicitada: ___________ │
│ │
│ 1. O QUE VOCÊ PRECISA? │
│ [Breve descrição da feature desejada] │
│ ________________________________________________ │
│ │
│ 2. POR QUE VOCÊ PRECISA? │
│ [Problema de negócio sendo resolvido] │
│ ________________________________________________ │
│ │
│ 3. QUEM SE BENEFICIA? │
│ [Número de usuários/clientes afetados] │
│ ________________________________________________ │
│ │
│ 4. O QUE ACONTECE SEM ISSO? │
│ [Impacto de não fazer isso] │
│ ________________________________________________ │
│ │
│ 5. QUÃO URGENTE É? │
│ ☐ Crítico (impacto no negócio agora) │
│ ☐ Alto (necessário este trimestre) │
│ ☐ Médio (seria útil) │
│ ☐ Baixo (bom ter) │
│ │
│ 6. EXISTEM ALTERNATIVAS? │
│ [Workarounds atualmente sendo usados] │
│ ________________________________________________ │
│ │
│ 7. COMO MEDIREMOS SUCESSO? │
│ [Métricas que melhorariam] │
│ ________________________________________________ │
│ │
│ [Enviar Requisição] │
└─────────────────────────────────────────────────────────────┘
Canal Único
DISCIPLINA DE CANAL DE REQUISIÇÕES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ❌ ANTES: Requisições Vêm de Todo Lugar │
│ │
│ • Email para desenvolvedores individuais │
│ • Mensagens de Slack │
│ • Conversas de corredor │
│ • Notas de reunião │
│ • "Você pode só..." │
│ │
│ RESULTADO: Coisas se perdem, priorização injusta │
│ │
│ ───────────────────────────────────────────────── │
│ │
│ ✅ DEPOIS: Canal Único de Intake │
│ │
│ Todas requisições → Formulário → Backlog GitScrum │
│ │
│ RESPOSTAS PARA REQUISIÇÕES FORA DO CANAL: │
│ │
│ "Ótima ideia! Por favor submeta através do formulário │
│ de requisição de feature para que possa ser propriamente │
│ avaliada e priorizada junto com outras requisições." │
│ │
│ "Entendi - para garantir que isso não se perca, │
│ pode adicionar ao backlog de requisições?" │
└─────────────────────────────────────────────────────────────┘
Sistema de Pontuação
Framework RICE
PONTUAÇÃO RICE PARA REQUISIÇÕES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ R - REACH (Alcance) │
│ Quantas pessoas isso afeta por trimestre? │
│ Ex: 500 usuários = pontuação 500 │
│ │
│ I - IMPACT (Impacto) │
│ Quanto afeta cada pessoa? │
│ 3 = Massivo | 2 = Alto | 1 = Médio | 0.5 = Baixo │
│ │
│ C - CONFIDENCE (Confiança) │
│ Quão confiantes estamos? │
│ 100% = Alta | 80% = Média | 50% = Baixa │
│ │
│ E - EFFORT (Esforço) │
│ Pessoa-meses para completar │
│ 0.5 = Pequeno | 1 = Médio | 2 = Grande │
│ │
│ FÓRMULA: (R × I × C) / E │
│ │
│ EXEMPLO: │
│ Feature: Single Sign-On │
│ R: 200 usuários | I: 2 (alto) | C: 80% | E: 2 meses │
│ Score: (200 × 2 × 0.8) / 2 = 160 │
│ │
└─────────────────────────────────────────────────────────────┘
Matriz de Priorização
COMPARANDO REQUISIÇÕES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REQUISIÇÃO │ RICE │ STRAT │ CLIENTES │ DECISÃO │
│───────────────────┼───────┼───────┼──────────┼────────────│
│ SSO Enterprise │ 160 │ ✅ │ 15 │ 🟢 Fazer │
│ Dashboard custom │ 120 │ ✅ │ 8 │ 🟢 Fazer │
│ Export PDF │ 80 │ ❌ │ 20 │ 🟡 Depois │
│ Mobile app │ 200 │ ✅ │ 5 │ 🟢 Fazer │
│ Dark mode │ 45 │ ❌ │ 50 │ 🔴 Não │
│ │
│ CRITÉRIOS ADICIONAIS: │
│ • STRAT = Alinha com estratégia do produto? │
│ • CLIENTES = Quantos clientes pediram? │
│ • Considerar também: churn risk, competitive gap │
│ │
└─────────────────────────────────────────────────────────────┘
Comunicação com Stakeholders
Sessões de Priorização
REUNIÃO DE PRIORIZAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FREQUÊNCIA: Quinzenal ou Mensal │
│ PARTICIPANTES: Product, Stakeholders principais │
│ DURAÇÃO: 60-90 minutos │
│ │
│ AGENDA: │
│ │
│ 1. REVIEW DO PERÍODO (15 min) │
│ • O que foi entregue │
│ • Resultados de releases │
│ │
│ 2. CAPACIDADE DISPONÍVEL (10 min) │
│ • Quantas semanas-pessoa temos │
│ • Restrições conhecidas │
│ │
│ 3. NOVAS REQUISIÇÕES (20 min) │
│ • Apresentar novas requisições │
│ • Mostrar pontuação RICE │
│ • Discussão breve │
│ │
│ 4. PRIORIZAÇÃO (30 min) │
│ • Ranking colaborativo │
│ • Tradeoffs discutidos abertamente │
│ • Decisões tomadas em grupo │
│ │
│ 5. PRÓXIMOS PASSOS (10 min) │
│ • O que entra no próximo ciclo │
│ • Comunicação para quem não compareceu │
│ │
└─────────────────────────────────────────────────────────────┘
Dizendo Não Graciosamente
TEMPLATES DE "NÃO":
┌─────────────────────────────────────────────────────────────┐
│ │
│ NÃO AGORA (adiado): │
│ ───────────────────── │
│ "Obrigado pela requisição de [feature]. Após avaliação │
│ com nosso framework RICE, ela pontuou [X] - o que a │
│ coloca na nossa lista de 'considerar mais tarde'. │
│ │
│ Aqui está o que priorizamos na frente e por quê: │
│ [explicação breve] │
│ │
│ Revisamos prioridades mensalmente - se suas │
│ circunstâncias mudarem, nos avise." │
│ │
│ NÃO (provavelmente nunca): │
│ ────────────────────────── │
│ "Agradecemos a sugestão de [feature]. Após consideração, │
│ decidimos que não se alinha com nossa direção de produto │
│ porque [razão específica]. │
│ │
│ Entendemos que é importante para você. │
│ Alternativas que podem ajudar: [opções]" │
│ │
│ SEMPRE INCLUA: │
│ • Reconhecimento da necessidade │
│ • Razão clara (não vaga) │
│ • Alternativas se possível │
│ • Porta aberta para futuro (se apropriado) │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Checklist de Implementação
CHECKLIST DE GESTÃO DE STAKEHOLDERS
═══════════════════════════════════
INTAKE:
☐ Formulário de requisição criado
☐ Canal único estabelecido
☐ Respostas automáticas configuradas
☐ Time treinado para redirecionar
AVALIAÇÃO:
☐ Framework de pontuação definido
☐ Critérios documentados e públicos
☐ Processo de enriquecimento estabelecido
☐ Threshold de decisão claro
PRIORIZAÇÃO:
☐ Sessões regulares agendadas
☐ Stakeholders certos convidados
☐ Capacidade visível para todos
☐ Decisões documentadas
COMUNICAÇÃO:
☐ Templates de resposta criados
☐ Roadmap visível para stakeholders
☐ Updates regulares de status
☐ Feedback loop fechado
CULTURA:
☐ Processo respeitado por liderança
☐ Exceções são exceções (não regra)
☐ Transparência valorizada
☐ Dados informam decisões
Processo transparente de requisições transforma conflitos de stakeholders em colaboração - todos entendem o "por quê" por trás das prioridades.