Redator de SD - preparado para deploy

2026-08-11 19:00:04 -03:00
commit 18ae589d3a
35 changed files with 5832 additions and 0 deletions
@@ -0,0 +1,401 @@
+# Manual de Redação de Solicitação de Demanda (SD)
+
+## Como transformar uma demanda em entregáveis faturáveis, enquadrados e datados
+
+Contrato: Pregão Eletrônico nº 29/2025 — Processo 1321127 · SES-MG × Isis Saúde
+
+---
+
+## A regra que organiza tudo
+
+**O entregável é a unidade faturável.** Ele carrega tipo, item, semanas, USTs e datas próprias. É por ele que se mede, se fatura e se controla saldo de pool.
+
+A fase — Descoberta, Design, Arquitetura, Construção — **não é um container**. É um atributo do entregável, e o que define seu time-box.
+
+```
+ENTREGÁVEL
+├── Tipo (Descoberta / Design / Arquitetura / Construção)  → define o time-box
+├── Item do TR (I-02 / I-03 / I-04 / I-05)                 → define de qual pool debita
+├── Semanas (2 a 4)                                        → define a duração
+├── USTs = time-box × semanas                              → o valor faturável
+├── Período (data inicial a data final)                    → quando aconteceu
+├── Artefatos comprobatórios                               → o que prova
+└── Critérios de aceite                                    → como se verifica
+```
+
+Duas consequências práticas:
+
+- **Uma SD pode ter dois entregáveis do mesmo tipo**, com escopos e datas diferentes. Não existe "a fase de Construção" — existem os entregáveis de Construção que a demanda exigiu.
+- **Entregáveis de itens diferentes nunca se somam na mesma linha.** Cada um debita de um pool distinto e é medido separadamente.
+
+---
+
+# PARTE I — MONTAGEM DOS ENTREGÁVEIS
+
+---
+
+## Passo 1 — Entenda a demanda
+
+Três perguntas:
+
+**1. O que o cliente quer ver funcionando no final?**
+Não o que precisa ser feito — o que ele quer *ver*.
+
+**2. Isso já existe ou é novo?**
+Já existe e precisa mudar → manutenção. Nunca existiu → construção nova.
+
+**3. Qual é a natureza do trabalho?**
+Construir um pedaço da plataforma? Automatizar um processo? Criar um dashboard? Treinar alguém?
+
+Demanda com mais de uma natureza cruza mais de um item. Isso é normal — vira entregáveis separados.
+
+---
+
+## Passo 2 — Decomponha em atividades
+
+Blocos de trabalho que uma pessoa consiga explicar em uma frase. Não precisa ser granular.
+
+---
+
+## Passo 3 — Enquadre cada atividade
+
+```
+1. É plataforma crescendo (módulo novo, fonte nova, conector novo)?  → I-02
+2. É ensinar alguém a usar algo que já foi implantado?               → I-03
+3. É automatizar tarefa repetitiva / corrigir algo em produção?      → I-04
+4. É criar dashboard, algoritmo, IA, busca ativa, análise?           → I-05
+```
+
+**Teste da estrada** — para a dúvida clássica entre I-02 e I-04:
+
+> I-02 constrói a estrada. I-04 põe o piloto automático.
+> Primeira vez que conecta ou constrói → I-02.
+> Automatizar algo que já poderia ser feito manualmente → I-04.
+
+**Armadilhas frequentes:**
+
+| Situação | Item correto | Por quê |
+|---|---|---|
+| Produto novo sendo construído | I-02 | Ainda não existe para ser mantido |
+| Dashboard, índice, score, ranking | I-05 | É inteligência, não automação |
+| App em produção com bug de interface | I-04 | Manutenção perfectiva |
+| Regra de negócio nova no motor | I-05 | Evolução de algoritmo |
+| Oficina de discovery pré-implantação | I-05 | I-03 é consultoria pós-implantação |
+
+---
+
+## Passo 4 — Agrupe as atividades em entregáveis
+
+Agrupe atividades que compartilham **o mesmo item e o mesmo tipo** e que produzem um artefato final coerente.
+
+| Tipo | O que entra | Pergunta-guia |
+|---|---|---|
+| **Descoberta** | Levantamento, mapeamento, investigação | "O que eu precisava saber antes de começar?" |
+| **Design** | Visualização, UX, fluxos, protótipos, modelagem de regras | "Como vai parecer?" |
+| **Arquitetura** | Planejamento técnico, modelo de dados, viabilidade | "Como vai ser construído?" |
+| **Construção** | Implementação, teste, publicação | "Está funcionando?" |
+
+**Quando quebrar em mais de um entregável do mesmo tipo:**
+
+- O escopo excede 4 semanas → quebre, porque 4 é o teto por entregável
+- Duas frentes rodam em paralelo com times distintos → entregáveis separados, mesmo período
+- Um pedaço pode ser faturado antes do outro → separe, para não travar o faturamento do que já está pronto
+- Atividades pertencem a itens diferentes → obrigatoriamente separados
+
+**Quando não quebrar:**
+
+- Só para "ter mais entregáveis". Cada entregável custa USTs próprias — quebrar infla o orçamento sem entregar mais
+- Quando o resultado só faz sentido inteiro. Metade de um dashboard não é faturável
+
+Nem toda demanda tem os quatro tipos. Uma oficina pode ter só Descoberta e Construção. Uma manutenção, só Construção. Tipo inventado para "ficar completo" é glosa esperando acontecer.
+
+---
+
+## Passo 5 — Defina semanas e datas de cada entregável
+
+```
+Mínimo: 2 semanas (regra contratual)
+Máximo: 4 semanas
+Típico: 2 a 3 semanas
+```
+
+| Se o entregável... | Semanas |
+|---|---|
+| É simples, escopo fechado, poucas dependências | 2 |
+| É médio, precisa de reuniões e validação | 3 |
+| É complexo, múltiplos stakeholders, muita incerteza | 4 |
+
+**Regras de data:**
+
+- Entregáveis **encadeados** (um depende do outro) não podem se sobrepor. Se Descoberta e Design compartilham semanas, os mesmos perfis aparecem alocados a 200% — é achado de auditoria.
+- Entregáveis **paralelos** podem compartilhar período, desde que sejam times distintos. Declare isso explicitamente na SD, ou parecerá erro.
+- A data final de cada entregável é a data que habilita seu faturamento. Ela precisa fazer sentido contra a evidência: entregável que fecha em 31/05 não pode ter como comprovação um documento enviado em 14/06.
+
+---
+
+## Passo 6 — Calcule as USTs de cada entregável
+
+```
+USTs = time-box × semanas
+```
+
+**Time-box por tipo e item:**
+
+| | Descoberta | Design | Arquitetura | Construção |
+|---|---|---|---|---|
+| **I-02** | 40h | 40h | 40h | **40h** |
+| **I-03** | 40h | 40h | 40h | **40h** |
+| **I-04** | 40h | 40h | 40h | **80h** |
+| **I-05** | 40h | 40h | 40h | **80h** |
+
+Descoberta, Design e Arquitetura são sempre 40h. A única diferença está na Construção: 40h em I-02/I-03, 80h em I-04/I-05.
+
+**USTs prontas para copiar:**
+
+| Semanas | Desc / Design / Arq (todos os itens) | Construção I-02 e I-03 | Construção I-04 e I-05 |
+|---|---|---|---|
+| 2 | 80 | 80 | **160** |
+| 3 | 120 | 120 | **240** |
+| 4 | 160 | 160 | **320** |
+
+---
+
+## Passo 7 — Defina os artefatos comprobatórios de cada entregável
+
+**Entregável ≠ artefato.** O entregável é a unidade faturável. Os artefatos são os documentos que provam que ele aconteceu.
+
+Quanto maior o valor do entregável, mais lastro documental ele precisa carregar:
+
+| USTs do entregável | Artefatos comprobatórios mínimos |
+|---|---|
+| 80 | 1 |
+| 120 a 160 | 2 |
+| 240 ou mais | 3 |
+
+Nomeie artefatos que **existem de fato**. Documento comprobatório inventado é pior que entregável sem comprovação — o primeiro é problema de integridade, o segundo é só pendência.
+
+---
+
+# PARTE II — REDAÇÃO DA SD
+
+---
+
+## Cabeçalho
+
+| Campo | Regra de preenchimento |
+|---|---|
+| Cliente / Contratante | Secretaria de Estado de Saúde de Minas Gerais (SES-MG) |
+| Contratada | Isis Saúde |
+| Contrato | Pregão Eletrônico nº 29/2025 — Processo 1321127 |
+| Projeto / Solução | Nome do projeto real desta demanda. **Confira** — é o campo mais copiado por engano |
+| Nº da SD | Sequencial |
+| Versão | V1, V2… |
+| Data de abertura | DD/MM/AAAA. Nunca escreva "não formalizada" nem qualquer confissão de irregularidade |
+| Período de execução | Da data inicial do primeiro entregável à data final do último |
+| Item ou itens do TR | Número **e** título literal. Se a SD cruza itens, liste todos |
+| Quantidade total de UST | Soma dos entregáveis, com número por extenso |
+| Prazo de execução | Duração do calendário, não a soma das semanas quando há paralelismo |
+| Quantidade de entregáveis | Número |
+
+---
+
+## 1. Objetivo
+
+Dois a quatro períodos. Diz o que a SD formaliza e qual resultado permite alcançar. Não repete o contexto.
+
+---
+
+## 2. Contexto e escopo da demanda
+
+Três a cinco parágrafos:
+
+1. **O problema de gestão** — o que trava, o que a SES-MG não consegue fazer hoje
+2. **O insumo disponível** — o que já existe e por que não basta na forma atual
+3. **O que a demanda entrega** — a solução em termos concretos
+4. **O achado ou resultado**, quando houver
+5. **O desdobramento** — o que isso destrava adiante
+
+Números reais e verificáveis. Se um número aparece na SD e outro no artefato entregue, a inconsistência aparece sozinha na primeira leitura cruzada.
+
+---
+
+## 3. Quadro de entregáveis
+
+O coração da SD. Uma linha por entregável faturável.
+
+| # | Entregável | Tipo | Item TR | Semanas | Time-box | UST | Período |
+|---|---|---|---|---|---|---|---|
+| 1 | | | | | | | |
+| 2 | | | | | | | |
+| 3 | | | | | | | |
+| | **Total** | | | | | **XXX** | |
+
+**Confira antes de seguir:**
+- Cada linha: `UST = time-box × semanas`
+- Nenhum entregável abaixo de 2 nem acima de 4 semanas
+- Time-box de Construção correto para o item (40h ou 80h)
+- Períodos de entregáveis encadeados não se sobrepõem
+- Se há paralelismo, está declarado em nota
+- A soma da coluna UST bate com o cabeçalho
+
+Quando a SD cruza itens, acrescente uma linha de subtotal por item — é assim que o controle de pool é feito.
+
+---
+
+## 4. Detalhamento dos entregáveis
+
+Um bloco por entregável, na ordem do quadro. Quatro seções cada.
+
+```
+ENTREGÁVEL N — [Nome do artefato final]
+Tipo · Item TR · X semanas · XX UST · DD/MM a DD/MM
+
+Resumo
+Três linhas. O que o entregável fez e o que produziu.
+
+Atividades previstas
+Bullets. Blocos de trabalho concretos, de seis a nove.
+
+Artefatos comprobatórios
+- [Documento com nome real e, quando houver, data]
+- [Documento]
+
+Critérios de aceite
+Bullets. Condições verificáveis por terceiro.
+```
+
+**Sobre os critérios de aceite** — o teste é se alguém que não participou consegue dizer sim ou não olhando o artefato:
+
+| Serve | Não serve |
+|---|---|
+| "Índice reproduzível: mesma base e mesmo código produzem resultado idêntico" | "Modelo bem construído" |
+| "Dashboard acessível pelos perfis indicados pela SES-MG" | "Dashboard funcionando adequadamente" |
+| "Toda pergunta do formulário mapeada à dimensão que alimenta" | "Documentação completa" |
+
+---
+
+## 5. Enquadramento no Termo de Referência
+
+Seção obrigatória. É a que sustenta a SD se a fiscalização contestar o item — e é a que evita a reclassificação que muda o time-box de Construção e derruba as USTs pela metade.
+
+| | |
+|---|---|
+| **Item do TR** | Número e título literal, exatamente como no TR |
+| **Descrição do item** | Transcrição do escopo do item conforme o TR |
+| **Aderência desta SD** | Bullets ligando o que foi entregue ao que o item prevê |
+
+**Regras para os bullets de aderência:**
+
+- Um bullet por componente entregue, de três a cinco no total
+- Use o vocabulário do item, não o vocabulário interno da equipe
+- Descreva o que foi construído, não o que foi discutido
+- Não cite componente que a SD não tem só para reforçar o encaixe
+
+**Exemplo — entregáveis de índice e dashboard (I-05):**
+
+| | |
+|---|---|
+| **Item do TR** | I-05 – Serviços técnicos de inteligência e produtos analíticos de gestão em saúde |
+| **Descrição do item** | Serviços técnicos de inteligência aplicada aos dados da plataforma, compreendendo a concepção e o desenvolvimento de algoritmos analíticos, modelos de classificação, índices e dashboards gerenciais destinados a apoiar a tomada de decisão das áreas demandantes da SES-MG. Inclui extração de fenótipos, clusterização e priorização de populações e territórios, apuração de indicadores e disponibilização dos resultados em painéis, relatórios e produtos analíticos de gestão. |
+| **Aderência desta SD** | • Concepção do algoritmo de classificação em sete dimensões ponderadas, com penalidade, bônus de cadeia e normalização em escala de 0 a 100.<br>• Desenvolvimento do motor de cálculo que processa as respostas do formulário e atribui score e faixa a cada município.<br>• Construção do dashboard gerencial, com ranking, cadeia de envios por domínio e corte por macrorregião.<br>• Disponibilização do painel aos gestores da SES-MG como insumo de priorização das ondas de integração. |
+
+**Quando a SD cruza dois itens:** repita a seção 5 inteira para cada item, e indique quais entregáveis do quadro pertencem a cada um.
+
+---
+
+# PARTE III — VALIDAÇÃO
+
+**Enquadramento**
+```
+[ ] Cada entregável tem item definido (I-02 / I-03 / I-04 / I-05)
+[ ] Produto novo está no I-02, não no I-04
+[ ] Dashboard, índice ou algoritmo está no I-05, não no I-04
+[ ] Automação de tarefa repetitiva está no I-04
+[ ] Treinamento pós-implantação está no I-03
+[ ] Entregáveis de itens diferentes estão em linhas separadas
+[ ] Há subtotal por item quando a SD cruza itens
+```
+
+**Cálculo**
+```
+[ ] Cada entregável entre 2 e 4 semanas
+[ ] UST de cada linha = time-box × semanas
+[ ] Time-box de Construção correto (40h em I-02/I-03, 80h em I-04/I-05)
+[ ] Soma da coluna UST bate com o cabeçalho
+[ ] Entregáveis encadeados sem sobreposição de período
+[ ] Paralelismo, quando existe, está declarado
+[ ] Prazo do cabeçalho reflete o calendário, não a soma das semanas
+```
+
+**Documento**
+```
+[ ] Nome do projeto é o desta demanda, não copiado de outra SD
+[ ] Número do item e título do item correspondem entre si
+[ ] Título do item confere com a redação literal do TR
+[ ] Números do contexto batem com os artefatos entregues
+[ ] Produto tem um nome só ao longo de todo o documento
+[ ] Nenhum campo confessa irregularidade
+[ ] Cada entregável tem o mínimo de artefatos comprobatórios da sua faixa
+[ ] Todo artefato citado existe de fato
+[ ] Data final de cada entregável é coerente com a data dos seus artefatos
+[ ] Todo critério de aceite é verificável por terceiro
+[ ] Seção 5 preenchida com aderência específica, não genérica
+```
+
+---
+
+# ANEXO — Referência rápida
+
+## Enquadramento em 4 perguntas
+
+```
+1. É plataforma crescendo (módulo novo, fonte nova, conector novo)?  → I-02
+2. É ensinar alguém a usar algo que já foi implantado?               → I-03
+3. É automatizar tarefa repetitiva / corrigir algo em produção?      → I-04
+4. É criar dashboard, algoritmo, IA, busca ativa, análise?           → I-05
+```
+
+## USTs por entregável
+
+| Semanas | Desc / Design / Arq | Construção I-02 e I-03 | Construção I-04 e I-05 |
+|---|---|---|---|
+| 2 | 80 | 80 | 160 |
+| 3 | 120 | 120 | 240 |
+| 4 | 160 | 160 | 320 |
+
+## Artefatos comprobatórios por entregável
+
+| USTs | Artefatos mínimos |
+|---|---|
+| 80 | 1 |
+| 120 a 160 | 2 |
+| 240+ | 3 |
+
+## Conjunto típico de entregáveis (3 + 2 + 2 + 3 semanas)
+
+| Item | Descoberta | Design | Arquitetura | Construção | **Total** |
+|---|---|---|---|---|---|
+| I-02 | 120 | 80 | 80 | 120 | **400** |
+| I-03 | 120 | 80 | 80 | 120 | **400** |
+| I-04 | 120 | 80 | 80 | 240 | **520** |
+| I-05 | 120 | 80 | 80 | 240 | **520** |
+
+## Estrutura da SD
+
+```
+Cabeçalho (identificação)
+1. Objetivo
+2. Contexto e escopo da demanda
+3. Quadro de entregáveis (tipo × item × semanas × time-box × UST × período)
+4. Detalhamento dos entregáveis
+   4.N Resumo (3 linhas)
+   4.N Atividades previstas (bullets)
+   4.N Artefatos comprobatórios (nomeados)
+   4.N Critérios de aceite (bullets verificáveis)
+5. Enquadramento no Termo de Referência
+   Item do TR / Descrição do item / Aderência desta SD
+```
+
+---
+
+*Documento de apoio à formalização de demandas — RMDS / SES-MG.*