L’interface est localisée ; les présentations et documents des Skills sont traduits automatiquement par IA dans votre langue. Le code, les commandes, chemins et termes techniques restent en version originale, et le document de l’auteur fait foi.
Explorer les Skills
Productivité · SKILL.md

program-manager

program-manager

Program Manager sênior para gestão de programas multi-projeto, dependências entre times, RAID log (Risks, Assumptions, Issues, Dependencies), stakeholder management, governança de portfólio, status reporting executivo e entrega de iniciativas estratégicas. Use ao estruturar um programa, coordenar múltiplos squads, gerenciar dependências críticas, reportar s…

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentation de la Skill

GitHub

name: "program-manager" description: "Program Manager sênior para gestão de programas multi-projeto, dependências entre times, RAID log (Risks, Assumptions, Issues, Dependencies), stakeholder management, governança de portfólio, status reporting executivo e entrega de iniciativas estratégicas. Use ao estruturar um programa, coordenar múltiplos squads, gerenciar dependências críticas, reportar status para C-level ou quando o usuário mencionar Program Manager, PgM, programa, portfólio, governança, RAID log, steering committee ou cross-functional delivery." license: MIT metadata: version: 1.0.0 author: Ric Neves - Flowgrammers category: project-management domain: program-management updated: 2026-04-23 agents:

  • claude-code

Program Manager Sênior

Frameworks para gestão de programas estratégicos: portfólio, dependências, RAID, governança, stakeholder management e entrega cross-functional.

Palavras-chave

Program Manager, PgM, TPgM, Technical Program Manager, portfolio management, governança, steering committee, RAID log, risco, dependência, cross-functional, stakeholder management, status report, milestone tracking

Program ≠ Project

ProjetoPrograma
Entregável definidoBenefício estratégico
Início e fimMúltiplos projetos no tempo
1 PM1 PgM + N PMs
Escopo fechadoEscopo adaptável
Sucesso = on time, on budgetSucesso = valor entregue

Exemplo:

  • Projeto: "Migrar para AWS em Q2"
  • Programa: "Modernização de Infraestrutura" (inclui migração, observabilidade, SRE, FinOps)

Responsabilidades Principais

1. Program Charter (1-pager)

# Program Charter: [Nome do Programa]

## Visão
[Uma frase clara sobre o estado futuro]

## Benefícios esperados (quantificáveis)
- R$ X de receita ou Y% de redução de custo
- Z% de melhoria em métrica chave

## Escopo
**Dentro:** [O que o programa entrega]
**Fora:** [O que NÃO faz parte]

## Stakeholders-chave
- Sponsor executivo: [nome]
- Steering committee: [nomes]
- Times envolvidos: [lista]

## Milestones principais
| Milestone | Data | Entregável |
|-----------|------|-----------|
| M1 | Q2/2026 | [...] |
| M2 | Q3/2026 | [...] |

## Riscos top 3
1. [...]
2. [...]
3. [...]

## Orçamento
R$ X (CapEx) + R$ Y (OpEx) + Z FTEs

2. Estrutura de Programa

Papéis típicos:

  • Sponsor Executivo (C-level) — dono do outcome
  • Steering Committee (VPs/Diretores) — decisões críticas mensais
  • Program Manager — coordenação diária
  • Project Managers (1 por workstream) — execução dos projetos
  • Workstream Leads (tech/produto/go-to-market) — liderança técnica

Cadência de rituais:

RitualFrequênciaParticipantesDuração
Steering CommitteeMensalExecs + PgM60 min
Program SyncSemanalPgM + PMs + leads60 min
Risk ReviewSemanalPgM + subset30 min
All-Hands do ProgramaBimestralTodos45 min
RetrospectivaPor milestoneTodos90 min

3. RAID Log (Risks, Assumptions, Issues, Dependencies)

Template:

# RAID Log — [Programa]

## Risks (eventos futuros com probabilidade)
| ID | Descrição | Prob | Impacto | Score | Mitigação | Owner | Status |
|----|-----------|------|---------|-------|-----------|-------|--------|
| R01 | Fornecedor X pode atrasar | M | A | 12 | Plano B contratado | JR | Monitorado |

## Assumptions (premissas a validar)
| ID | Premissa | Validação | Data | Status |
|----|----------|-----------|------|--------|
| A01 | Cliente Y assinará contrato em Q2 | Reunião 2026-05-15 | 2026-05-15 | Pendente |

## Issues (problemas atuais)
| ID | Descrição | Impacto | Owner | Deadline | Status |
|----|-----------|---------|-------|----------|--------|
| I01 | API de terceiros com downtime | Delay 1 sem | MC | 2026-05-10 | Em andamento |

## Dependencies (o que precisamos de outros)
| ID | Entrega esperada | De | Para | Data | Status |
|----|------------------|-----|------|------|--------|
| D01 | Schema de dados | Data Team | Eng Team | 2026-05-01 | Confirmado |

Régua de risco (prob × impacto):

Impacto Baixo (1)Médio (3)Alto (5)
Prob Alta (5)51525
Média (3)3915
Baixa (1)135
  • Score >= 15: escalação obrigatória, steering review
  • Score 9-14: plano de mitigação formal, review semanal
  • Score < 9: monitoramento leve

4. Dependency Management

Tipos de dependência:

  • Finish-to-Start: B não começa até A terminar (mais comum)
  • Start-to-Start: B começa ao mesmo tempo de A
  • Finish-to-Finish: B termina quando A terminar

Mapa visual (use Miro ou similar):

[Data Platform] ─────▶ [ML Training] ─────▶ [Inference Service]
                            │
                            ▼
                     [Data Governance]
                            │
                            ▼
                     [Compliance Review] ─▶ [Production Launch]

Tática contra dependências ocultas:

  • Pergunta semanal em sync: "O que vocês estão esperando de outro time?"
  • Dependency map atualizado a cada milestone
  • Contratos internos (APIs, interfaces) com owners e SLAs

5. Status Reporting

Princípios:

  • RAG status (Red / Amber / Green) + narrativa
  • Honesto sobre red — esconder vira crise maior
  • Trends são mais importantes que pontos isolados
  • Propõe ações, não só informa problema

Template executivo (máx. 1 slide):

# Program Status — [Nome] — [Semana/Mês]

## Overall: AMBER ⚠️

## Milestones
| Milestone | Target | Forecast | Status |
|-----------|--------|----------|--------|
| M1 | 2026-05-30 | 2026-06-07 | 🟡 |
| M2 | 2026-08-15 | 2026-08-15 | 🟢 |

## Top 3 Riscos
1. 🔴 Contratação de 2 engenheiros sêniores atrasada (mitigação: contractor)
2. 🟡 Integração API depende de aprovação legal (resolve 2026-05-10)
3. 🟢 Budget on track

## Decisões necessárias
- Aprovação de orçamento adicional de R$ X (mitigação do risco 1)
- Go/no-go para milestone M1 em 2026-05-15

## O que mudou desde o último update
- Finalizamos discovery de Y (1 semana atrás do plano)
- Fornecedor X confirmou entrega para junho

6. Stakeholder Management

Matriz Poder × Interesse:

Alto InteresseBaixo Interesse
Alto Poder: Manage closelyAlto Poder: Keep satisfied
Baixo Poder: Keep informedBaixo Poder: Monitor

Tática por quadrante:

  • Manage closely: updates semanais, 1:1s quinzenais, consulta em decisões
  • Keep satisfied: updates mensais, envolver em marcos
  • Keep informed: newsletter, all-hands
  • Monitor: visibilidade passiva

Red flags de stakeholder:

  • Sumiu de 2 steering committees seguidos
  • Não responde emails/chats em > 48h
  • Surpresa em decisões (= não está informado)
  • Muda de posição sem aviso
  • Envia subordinados sem poder de decisão

7. Change Management no Programa

Todo programa = mudança organizacional. Se você só gerencia tarefas, falha.

Kotter 8-steps aplicado:

  1. Crie senso de urgência (por que agora?)
  2. Construa coalizão forte
  3. Desenvolva visão e estratégia
  4. Comunique a visão (10× mais do que parece necessário)
  5. Remova barreiras
  6. Gere quick wins
  7. Consolide ganhos
  8. Ancore na cultura

8. Governança de Portfólio (visão multi-programa)

Framework trimestral:

  • Health check de cada programa (RAG, burn, benefícios)
  • Resource allocation — quem precisa de mais / menos
  • Stop / continue / accelerate decisions
  • Dependency map cross-program

Critérios para matar um programa:

  • Benefícios previstos não mais relevantes
  • Custo > benefício
  • Mudança estratégica (pivot)
  • Execução muito ruim, sem caminho de recuperação

Anti-Patterns (evite)

  • ❌ Micromanagement de tarefas (PMs são responsáveis por isso)
  • ❌ Status report que só mostra verde (perda de confiança quando vira vermelho)
  • ❌ Risco listado, mitigação genérica ("vamos monitorar")
  • ❌ Steering committee vira teatro (decisões prontas antes da reunião)
  • ❌ Ignorar stakeholders difíceis (eles viram bloqueadores maiores)
  • ❌ Comunicação só em meeting (use async também: docs, Loom, newsletter)

Métricas do Program Manager

  • Milestone delivery rate: % de marcos entregues on-time
  • Benefício realizado: R$ captured × R$ planejado
  • Stakeholder NPS: pesquisa com membros do steering
  • Issue resolution time: mediana de dias para resolver
  • Team escalations: quantas vezes times do programa precisaram escalar
  • Schedule variance: dias de atraso vs. plano

Perguntas-Chave

  • "Se este programa for cancelado amanhã, qual é o maior desperdício?"
  • "Qual dependência oculta pode quebrar tudo?"
  • "Nossos stakeholders estão realmente alinhados ou só concordam em reunião?"
  • "Que risco estamos ignorando porque é desconfortável falar?"
  • "Qual é o caminho crítico — e quem é o owner do próximo milestone dele?"

Veja Também

  • senior-pm/ — PM de projetos individuais
  • scrum-master/ — execução ágil
  • meeting-analyzer/ — eficiência de reuniões
  • team-communications/ — comunicação de time
  • jira-expert/ — tracking em Jira
  • ../c-level-advisor/coo-advisor/ — execução operacional
Skills enregistrées