Gestão de Prioridades em Times de Desenvolvimento
Estabeleça sistemas de priorização claros para trabalho de desenvolvimento. Ajude times a focar no que mais importa e tome decisões de prioridade consistentemente.
8 min de leitura
Prioridades claras previnem troca de contexto, reduzem discussões sobre o que trabalhar e garantem que o trabalho mais valioso seja feito primeiro. Os labels de prioridade, sprint goals e ordenação de backlog do GitScrum ajudam times a manter foco claro no que mais importa. A chave é ter um sistema que todos entendem e seguem consistentemente.
Frameworks de Priorização
| Framework | Melhor Para | Como Funciona |
|---|---|---|
| Eisenhower | Diário/semanal | Matriz Urgente vs Importante |
| MoSCoW | Planejamento de release | Must/Should/Could/Won't |
| WSJF | Times ágeis | Score Valor ÷ Duração |
| RICE | Decisões de feature | Reach × Impact × Confidence ÷ Effort |
| Stack Ranking | Clareza simples | Force ordem, sem empates |
Definição de Níveis de Prioridade
SISTEMA DE NÍVEIS DE PRIORIDADE
DEFINIÇÕES DE PRIORIDADE:
┌─────────────────────────────────────────────────┐
│ P1 - Crítico │
│ ├── Outage de produção ou bug major │
│ ├── Vulnerabilidade de segurança │
│ ├── Bloqueando deployment de cliente │
│ └── Deadline regulatório/compliance │
│ Resposta: Largue tudo, corrija agora │
│ SLA: Resolução em horas │
│ │
│ P2 - Alto │
│ ├── Bug significativo afetando usuários │
│ ├── Feature chave para próxima release │
│ ├── Compromisso major com cliente │
│ └── Iniciativa estratégica │
│ Resposta: Próximo sprint, capacidade protegida │
│ SLA: Resolução em 1-2 sprints │
│ │
│ P3 - Médio │
│ ├── Desenvolvimento normal de feature │
│ ├── Bug afetando alguns usuários │
│ ├── Melhoria técnica │
│ └── Requisições de enhancement │
│ Resposta: Planejado quando capacidade permite │
│ SLA: Resolução em 2-4 sprints │
│ │
│ P4 - Baixo │
│ ├── Features nice-to-have │
│ ├── Issues cosméticos │
│ ├── Bugs de edge case │
│ └── Considerações futuras │
│ Resposta: Backlog, pode não ser feito │
│ SLA: Sem compromisso │
└─────────────────────────────────────────────────┘
Matriz Eisenhower
MATRIZ URGENTE VS IMPORTANTE
┌─────────────────────────────────────────────────┐
│ │
│ URGENTE NÃO URGENTE │
│ ┌─────────────────┬─────────────────┐ │
│ │ │ │ │
│ IMPOR- │ FAÇA PRIMEIRO │ AGENDE │ │
│ TANTE │ │ │ │
│ │ • Outages de │ • Dev features │ │
│ │ produção │ • Dívida técnica│ │
│ │ • Issues de │ • Arquitetura │ │
│ │ segurança │ • Melhoria de │ │
│ │ • Blockers de │ processo │ │
│ │ cliente │ • Treinamento │ │
│ │ │ │ │
│ ├─────────────────┼─────────────────┤ │
│ │ │ │ │
│ NÃO │ DELEGUE │ ELIMINE │ │
│ IMPOR- │ OU AGRUPE │ OU DESPRIO │ │
│ TANTE │ │ │ │
│ │ • Maioria emails│ • Trabalho busy │ │
│ │ • Requisições │ • Reuniões │ │
│ │ de status │ desnecessárias│ │
│ │ • Admin de │ • Scope creep │ │
│ │ rotina │ • Over- │ │
│ │ │ engineering │ │
│ │ │ │ │
│ └─────────────────┴─────────────────┘ │
│ │
└─────────────────────────────────────────────────┘
Pontuação WSJF
WEIGHTED SHORTEST JOB FIRST
FÓRMULA WSJF:
┌─────────────────────────────────────────────────┐
│ │
│ WSJF = Cost of Delay ÷ Job Duration │
│ │
│ Onde Cost of Delay = │
│ User Value + Time Criticality + Risk/OE │
│ │
│ Escala cada fator 1-10: │
│ ├── User Value: Quanto usuários querem isso │
│ ├── Time Criticality: Urgência da entrega │
│ └── Risk/Opportunity: Custo de não fazer │
└─────────────────────────────────────────────────┘
EXEMPLO DE CÁLCULO WSJF:
┌─────────────────────────────────────────────────────────────────┐
│ Feature User Time Risk CoD Size WSJF Prioridade│
│ ────────────────────────────────────────────────────────── │
│ Feature A 8 5 3 16 3 5.3 2 │
│ Feature B 5 8 7 20 8 2.5 4 │
│ Feature C 7 6 4 17 2 8.5 1 │
│ Feature D 6 4 5 15 5 3.0 3 │
│ │
│ Vencedor: Feature C (maior WSJF = 8.5) │
│ Razão: Alto valor relativo ao tamanho pequeno │
└─────────────────────────────────────────────────────────────────┘
Stack Ranking
ABORDAGEM FORCE RANKING
REGRAS DE STACK RANKING:
┌─────────────────────────────────────────────────┐
│ 1. Dois itens não podem ter mesma prioridade │
│ 2. Ordene de 1 a N (mais para menos) │
│ 3. Capacidade determina linha de corte │
│ 4. Itens abaixo da linha não acontecem no sprint│
│ 5. Re-rank quando prioridades mudam │
└─────────────────────────────────────────────────┘
STACK RANK DO BACKLOG:
┌─────────────────────────────────────────────────┐
│ Rank Item Pontos │
│ ────────────────────────────────────────── │
│ 1 Bug fix fluxo pagamento 3 ──┐ │
│ 2 Feature dashboard usuário 8 │ │
│ 3 Rate limiting API 5 │ │
│ 4 Fix responsivo mobile 3 │ │
│ 5 Melhorias na busca 5 ├──│ Capacidade: 25
│ 6 Sistema notif. email 13 │ │
│ 7 Feature export admin 5 ──┘ │
│ --- LINHA DE CORTE (25 pontos) -------- │
│ 8 Suporte dark mode 8 ──┐ │
│ 9 Login social 5 ├──│ Talvez próx sprint
│ 10 Dashboard analytics 13 ──┘ │
└─────────────────────────────────────────────────┘
Lidando com Conflitos de Prioridade
RESOLUÇÃO DE CONFLITOS DE PRIORIDADE
QUANDO STAKEHOLDERS DISCORDAM:
┌─────────────────────────────────────────────────┐
│ Passo 1: Colete dados │
│ ├── Números de impacto no usuário │
│ ├── Implicações de receita/custo │
│ ├── Restrições de deadline │
│ └── Dependências │
│ │
│ Passo 2: Aplique framework objetivo │
│ └── Pontue itens usando WSJF ou RICE │
│ │
│ Passo 3: Se ainda empatado │
│ ├── Product Owner decide em features │
│ ├── Tech Lead decide em decisões técnicas │
│ └── Escale para gestor se impasse │
│ │
│ Passo 4: Documente e comunique │
│ └── Registre decisão e racional │
└─────────────────────────────────────────────────┘
RESPOSTA PARA "TUDO É P1":
┌─────────────────────────────────────────────────┐
│ Mostre a matemática: │
│ │
│ "Temos 40 pontos de capacidade neste sprint. │
│ Esses 8 itens totalizam 75 pontos. │
│ Podemos fazer ~4 itens. │
│ │
│ Quais 4 são realmente mais importantes? │
│ O que acontece se os outros 4 esperarem 2 sem?"│
│ │
│ Torne trade-offs explícitos e visíveis │
└─────────────────────────────────────────────────┘
Mudanças de Prioridade no Meio do Sprint
LIDANDO COM DISRUPÇÕES DE PRIORIDADE
POLÍTICA DE REQUISIÇÃO DE MUDANÇA:
┌─────────────────────────────────────────────────┐
│ Pergunta 1: É uma verdadeira emergência? │
│ ├── Outage de produção → Sim │
│ ├── Vulnerabilidade de segurança → Sim │
│ ├── Deadline de cliente (conhecido antes) → Não│
│ └── Stakeholder mudou de ideia → Não │
│ │
│ Se SIM (verdadeira emergência): │
│ 1. Pare trabalho atual │
│ 2. Swarm na emergência │
│ 3. Escopo do sprint atual ajusta automaticamente│
│ 4. Documente impacto │
│ │
│ Se NÃO (não emergência): │
│ 1. Adicione ao backlog │
│ 2. Priorize para próximo sprint │
│ 3. Discuta por que parece urgente │
│ 4. Enderece causa raiz │
└─────────────────────────────────────────────────┘
REGRAS DE PROTEÇÃO DO SPRINT:
┌─────────────────────────────────────────────────┐
│ Protegido: Compromisso do sprint │
│ ├── Time concordou com esses itens │
│ └── Mudar disrupta flow e moral │
│ │
│ Flexível: Escopo dentro de itens │
│ └── Pode reduzir escopo para add item urgente │
│ │
│ Buffer: Reserve 10-15% para inesperado │
│ └── Capacidade planejada para trabalho não plan│
│ │
│ Tracking: Conte mudanças de prioridade │
│ └── Contagem alta = problema de planning a fix │
└─────────────────────────────────────────────────┘
Melhores Práticas
Anti-Padrões
✗ Sem sistema de prioridade claro
✗ "Tudo é Prioridade 1"
✗ Mudando prioridades todo dia
✗ Stakeholder mais barulhento vence
✗ Sem proteção para trabalho comprometido
✗ Desenvolvedores escolhendo o que trabalhar