SkillEngenhariaDiagnostica

Coleta de Contexto de Negócio e Módulo

Extrai o contexto de produto, negócio e infraestrutura de um módulo antes de qualquer diagnóstico técnico.

Em:Diagnóstico de Dívida Técnica Crítica

Ações

PerfilDev

ProfundidadeMédia

Idiomapt-BR

Objetivo

Em uma frase.

Levantar e organizar todo o contexto de negócio, produto e operação de um módulo ou subsistema antes de iniciar qualquer análise técnica — garantindo que decisões de refatoração sejam priorizadas por impacto real no negócio, não por desconforto subjetivo do engenheiro.

Aplicação

Quando
faz sentido.

Usar

Como primeira etapa do workflow de Diagnóstico de Dívida Técnica Crítica, antes de qualquer análise de código.
Quando um módulo é candidato a refatoração mas ninguém documentou por que ele é crítico ou qual é o risco de mexer nele.
Quando o time sabe que "está ruim" mas não consegue articular o impacto de negócio das dívidas técnicas para stakeholders.
Quando há pressão para refatorar mas sem clareza sobre restrições operacionais (uptime, janelas de manutenção, integrações).

Não usar

Quando o contexto de negócio já está documentado e atualizado — pule direto para mapeamento de dependências.
Para módulos triviais ou utilitários sem impacto direto em fluxos de negócio.
Para análise de código puro — use cyclomatic-complexity-audit ou dependency-mapping-and-decomposition.

Prompt

Instruções
para a IA.

Passo 1 — Identificar a função de negócio do módulo

Responder com precisão: o que este módulo faz para o negócio? Não para o sistema — para o negócio.

- Quais fluxos de usuário dependem diretamente dele? (login, pagamento, onboarding, busca, etc.)

- Quanto do faturamento ou retenção passa por este módulo? - Se ele parar de funcionar por 1 hora, qual é o impacto financeiro e reputacional? - Ele serve usuários finais, sistemas internos, parceiros ou uma combinação?

Documentar a resposta como "Função de Negócio" — uma frase que qualquer PM entenderia.

Passo 2 — Mapear SLAs e restrições operacionais

Levantar todos os compromissos e limitações que restringem quando e como o módulo pode ser modificado:

- SLAs de disponibilidade: 99.9%? 99.99%? Há penalidades contratuais?

- **Janelas de manutenção:** Existe horário permitido para deploys arriscados? - **Restrições de downtime:** O módulo aceita downtime planejado ou precisa de zero-downtime deployment? - **Dependências de calendário:** Black Friday, fechamento fiscal, lançamentos de produto que impedem mudanças? - **Compliance e regulação:** LGPD, PCI-DSS, SOC2 — há dados sensíveis no módulo?

Passo 3 — Catalogar indicadores de dor

Coletar evidências concretas de que o módulo está causando problemas:

- Incidentes: Quantos P1/P2 nos últimos 6 meses? Quais eram as causas-raiz?

- **Bugs recorrentes:** Há tickets que reabrem no mesmo módulo repetidamente? - **Tempo de desenvolvimento:** Estimativas de features no módulo estão consistentemente acima do esperado? - **Onboarding:** Novos engenheiros evitam mexer neste módulo? Quanto tempo leva para alguém se sentir seguro? - **Alertas operacionais:** Há alertas que foram silenciados porque "é assim que funciona"? - **Reclamações internas:** O módulo tem "fama ruim" no time? Por quê?

Cada indicador deve ter: fonte da evidência, frequência e severidade percebida.

Passo 4 — Identificar stakeholders e dependências organizacionais

Mapear quem precisa ser consultado ou informado durante a refatoração:

- Product owner/PM: Quem aprova mudanças no comportamento do módulo?

- **Time de operações/SRE:** Quem monitora e responde quando o módulo falha? - **Times consumidores:** Quais outros times usam APIs ou dados deste módulo? - **Compliance/segurança:** Há aprovações necessárias para mudanças em dados sensíveis?

Passo 5 — Produzir ficha de contexto consolidada

Consolidar tudo em um documento estruturado com as seguintes seções:

```

## Ficha de Contexto — [Nome do Módulo]

Função de Negócio

[1-2 frases]

SLAs e Restrições

| Dimensão | Valor | Implicação para refatoração | |----------|-------|----------------------------| | ... | ... | ... |

Indicadores de Dor (priorizados)

| Indicador | Evidência | Frequência | Severidade | |-----------|-----------|------------|------------| | ... | ... | ... | ... |

Stakeholders

| Papel | Nome/Time | Consultar quando? | |-------|-----------|-------------------| | ... | ... | ... |

Restrições de Execução

[O que NÃO pode ser feito durante a refatoração e por quê] ```

---

Constelação

Onde
ela vive.

Workflows que usam

Diagnóstico de Dívida Técnica CríticaEngenharia

Bundles que incluem

Engenharia de Refatoração OuroEngenharia

Coleta de Contexto de Negócio e Módulo

Em uma frase.

Quandofaz sentido.

Instruçõespara a IA.

Passo 1 — Identificar a função de negócio do móduloResponder com precisão: o que este módulo faz para o negócio? Não para o sistema — para o negócio.- Quais fluxos de usuário dependem diretamente dele? (login, pagamento, onboarding, busca, etc.)

Passo 2 — Mapear SLAs e restrições operacionaisLevantar todos os compromissos e limitações que restringem quando e como o módulo pode ser modificado:- **SLAs de disponibilidade:** 99.9%? 99.99%? Há penalidades contratuais?

Passo 3 — Catalogar indicadores de dorColetar evidências concretas de que o módulo está causando problemas:- **Incidentes:** Quantos P1/P2 nos últimos 6 meses? Quais eram as causas-raiz?

Passo 4 — Identificar stakeholders e dependências organizacionaisMapear quem precisa ser consultado ou informado durante a refatoração:- **Product owner/PM:** Quem aprova mudanças no comportamento do módulo?

Passo 5 — Produzir ficha de contexto consolidadaConsolidar tudo em um documento estruturado com as seguintes seções:```