Plano de Liberação Gradual
Gera um plano de liberação estruturado seguindo o Idira Gradual Release Framework: inferir sinais do PRD, classificar o caminho de liberação, mapear anéis, construir o plano de coorte R3 e fornecer etapas de configuração do LaunchDarkly.
Etapa 1 — Ler e Inferir a partir do PRD
Leia o PRD por completo. Infira cada sinal abaixo a partir do conteúdo. Não pergunte ao PM nada que você possa determinar por conta própria.
| Sinal | O que procurar |
|---|---|
| NFI | Rótulo "NFI", "novo recurso", "não disponível anteriormente", capacidade completamente nova sem versão anterior |
| Impacto | Escopo de usuários/inquilinos afetados, linguagem de "caminho crítico"/"fluxo principal", sensibilidade de dados, risco de perda de dados ou interrupção de serviço |
| Complexidade de rollback | Migrações de esquema, gravações de dados, dependências de terceiros, comunicações com clientes necessárias, estado irreversível → Coordenado ou Irreversível. Apenas alternar flag → Fácil. Se não mencionado → deve perguntar |
| Restrições de região | GDPR, FedRAMP, residência de dados, requisitos específicos de geografia, "começando com [região]", "apenas [região]", "[região] primeiro", "limitado a [região]" |
| Restrições de serviço | Serviços, integrações ou componentes nomeados dos quais o recurso depende ou modifica |
| Prontidão para testadores iniciais | "pronto para QA", datas de conclusão de sprint, datas alfa/beta — quando o recurso estiver estável o suficiente para a primeira exposição externa |
| GA alvo | Data de lançamento comprometida, prazo de OKR, marco de liberação |
Após a leitura, apresente suas inferências — não faça perguntas abertas. Para qualquer sinal não encontrado no PRD, marque-o como ❓ e faça uma pergunta direcionada ao final:
Com base no PRD, aqui está como interpretei esta liberação:
- NFI: [Sim / Não — motivo] ou ❓ Não está claro no PRD
- Impacto: [Alto / Médio / Baixo — motivo] ou ❓ Não está claro no PRD
- Rollback: [Fácil / Coordenado / Irreversível — motivo] ou ❓ Não mencionado
- Restrições de região:[Nenhuma / lista — motivo] ou ❓ Não mencionado
- Restrições de serviço:[Nenhuma / lista — motivo] ou ❓ Não mencionado
- Pronto para testadores iniciais: [data — motivo] ou ❓ Não encontrado no PRD
- GA alvo: [data — motivo] ou ❓ Não encontrado no PRD
Em seguida, pergunte apenas as questões ❓, usando estas formas exatas:
- Rollback não mencionado → "Existe um plano de rollback? Opções: (1) Fácil — simples alternância de flag, reverte instantaneamente. (2) Coordenado — requer migração de dados, script ou comunicação com o cliente. (3) Ainda não definido — estratégia de rollback ainda a ser projetada."
- Impacto não claro → "Como você descreveria o impacto para o cliente se algo der errado? Alto (afeta fluxos principais ou muitos inquilinos), Médio (limitado a um serviço ou subconjunto específico) ou Baixo (cosmético / facilmente reversível)?"
- Pronto para testadores iniciais não encontrado → "Quando o recurso estará pronto para que testadores iniciais comecem a validar?"
- GA alvo não encontrado → "Qual é a data ou prazo do GA alvo?"
- Região não mencionada → "Existem restrições de região? Por exemplo, começando com uma região específica (EMEA, EUA, APAC) antes de expandir globalmente?"
Não assuma nenhum valor. Não pergunte sobre sinais que você já resolveu a partir do PRD.
Etapa 2 — Classificar o Caminho de Liberação
NFI = Sim → HIGH-TOUCH
OU Impacto = Alto
OU Rollback = Irreversível
Impacto = Médio → STANDARD
OU Rollback = Coordenado
Todos os outros → LIGHTWEIGHT
Etapa 3 — Mapear Anéis Obrigatórios
| Caminho | Anéis obrigatórios | P&D é dono | PM é dono |
|---|---|---|---|
| LIGHTWEIGHT | R0 → R4 | R0 | R4 |
| STANDARD | R0 → R3 → R4 | R0 | R3, R4 |
| HIGH-TOUCH | R0 → R1 → R2 → R3 → R4 | R0, R1 | R2, R3, R4 |
- R0 QA interna — ambientes de engenharia/QA
- R1 Cliente Zero / Dogfooding — equipes internas
- R2 Cliente Um — clientes selecionados de Early Access (via processo NFI)
- R3 Canary de produção — Inquilinos de teste → coortes ao vivo via flags do LaunchDarkly
- R4 Disponibilidade Geral — todos os inquilinos de produção elegíveis
Etapa 4 — Construir o Plano de Coorte R3 (apenas Standard e High-Touch)
R3 sempre começa com Inquilinos de Teste primeiro. Em seguida, sequencie inquilinos ao vivo por ARR:
| Onda | % Cumulativo | Segmentação |
|---|---|---|
| 0 | — | Inquilinos de Teste (sandboxes comprados pelo cliente) |
| 1 | 5% | Menor ARR, pequeno número de inquilinos |
| 2 | 15% | ARR baixo a médio |
| 3 | 35% | ARR médio |
| 4 | 65% | ARR médio a alto |
| 5 | 100% | Todos os inquilinos elegíveis restantes |
Ajustes:
- Restrições de serviço → adicionar segmentação por filtro de serviço por onda
- Restrições de região → adicionar filtro de região nas ondas iniciais, remover nas ondas 4–5
- Prazo curto → colapsar ondas (ex.: 5% → 35% → 100%)
- Sensibilidade a ARR alto → reter inquilinos de ARR alto para a onda 4 com tempo de espera estendido
Para cada onda incluir: %, descrição da coorte, portão de aprovação (métrica + tempo de espera), responsável. Portões de aprovação são obrigatórios — nunca os omita. Se o PRD definir métricas de sucesso, use-as. Caso contrário, aplique os padrões: taxa de sucesso de assinatura/recurso ≥99,5%, delta de taxa de erro <0,1%, regressão de latência p99 <5%, pico de tickets de suporte <3 a cada 1.000 inquilinos, tempo de espera mínimo de 48 h para ondas iniciais e 1 semana para ondas de ARR alto.
Etapa 5 — Gerar o Plano Completo de Liberação
Produza o plano usando este template:
# Plano de Liberação Gradual — [Nome do Recurso]
**Caminho de liberação:** [LIGHTWEIGHT / STANDARD / HIGH-TOUCH]
**Início mais cedo:** [data] | **GA alvo:** [data]
---
## Como interpretei esta liberação
| Sinal | Valor | Justificativa |
|--------|-------|-----------|
| NFI | Sim/Não | [uma linha] |
| Impacto | Alto/Médio/Baixo | [uma linha] |
| Rollback | Fácil/Coordenado/Irreversível | [uma linha] |
| Restrições de região | Nenhuma / [lista] | [uma linha] |
| Restrições de serviço | Nenhuma / [lista] | [uma linha] |
---
## Anéis Obrigatórios
| Anel | Estágio | Responsável | Portão de entrada | Portão de saída |
|------|-------|-------|------------|-----------|
| R0 | QA interna | P&D | Merge na main | Aprovação de QA |
| R1 | Dogfooding | P&D | R0 completo | Aprovação interna *(apenas High-Touch)* |
| R2 | Cliente Um | PM | Processo NFI completo | Feedback do cliente revisado *(apenas High-Touch)* |
| R3 | Canary de produção | PM | R2 completo | Onda 100% estável |
| R4 | Disponibilidade Geral | PM | Onda R3 100% completa | PM aprova/rejeita |
*(Inclua apenas os anéis necessários para o caminho escolhido)*
---
## Plano de Coorte R3
**Primeiro:** Inquilinos de Teste — confirme ativação segura antes de qualquer inquilino ao vivo.
| Onda | % | Quem | Segmentação | Portão de Aprovação |
|------|---|-----|-----------|---------------|
| 0 | — | Inquilinos de Teste | Inquilinos de teste externos | Sem incidentes por 48 h |
| 1 | 5% | ARR baixo | [critério] | [métrica] estável por [tempo de espera] |
| 2 | 15% | ARR baixo–médio | [critério] | [métrica] estável por [tempo de espera] |
| 3 | 35% | ARR médio | [critério] | [métrica] estável por [tempo de espera] |
| 4 | 65% | ARR médio–alto | [critério] | [métrica] estável por [tempo de espera] — estendido |
| 5 | 100% | Todos elegíveis | Remover filtros | [métrica] estável por [tempo de espera] |
---
## Configuração do LaunchDarkly
**1. Criar a feature flag**
- Chave da flag: `[nome-do-recurso]-rollout` (minúsculas, hífens)
- Tipo: Booleano
- Padrão (desligado): false para todos os ambientes
**2. Configurar ambientes**
- `internal-qa` → R0: habilitar para equipe de QA de P&D
- `dogfooding` → R1: habilitar para inquilinos internos de funcionários *(apenas High-Touch)*
- `early-access` → R2: habilitar para inquilinos nomeados do Cliente Um *(apenas High-Touch)*
- `production` → R3: regras de segmentação abaixo
**3. Regras de segmentação de produção (ondas R3)**
Onda 0 — Inquilinos de Teste:
- Regra: `tenant_type = "test"` → servir true
Onda 1 — 5%:
- Regra: `tenant_type = "live" AND arr_tier = "low"` → servir true para 5% de rollout
Onda 2 → 5: Incremente a porcentagem de rollout e expanda o filtro `arr_tier` por onda.
Remova o filtro `arr_tier` completamente na onda 5 (100%).
Se houver restrições de serviço:
- Adicione `AND deployed_services CONTAINS "[nome-do-serviço]"` a cada regra.
Se houver restrições de região:
- Adicione `AND region IN ["[região]"]` nas ondas iniciais; remova para as ondas 4–5.
**4. Portões entre ondas**
- Monitore a taxa de erro, latência (p99) e tickets de suporte durante o período de espera.
- Expanda para a próxima onda somente após os critérios de aprovação serem atendidos.
- Para pausar ou reverter: defina a flag de produção como false — todos os inquilinos revertem imediatamente.
**5. Alternância única**
- P&D deve implementar uma chave de flag em todos os componentes afetados.
- Confirme com P&D que todos os componentes leem a mesma flag antes do R3 começar.
---
## Responsáveis e Responsabilidades
- **P&D** — Implementa a flag, é dono de R0–R1, valida cobertura de alternância única
- **PM** — É dono da exposição ao cliente (R2–R4), assina cada portão de onda, atualiza o plano de coorte
- **Product Ops** — Revisa o plano em relação às diretrizes obrigatórias antes do início do R3
## Perguntas em Aberto / Suposições
- [Liste fatos assumidos ou ainda a serem confirmados com P&D / BI]
Exemplo
Consulte reference.md para um exemplo prático (NFI, Alto Impacto, meta de GA de 3 meses) mostrando um plano completo com tabela de coorte preenchida e regras do LaunchDarkly.