# 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.
• Desenvolvimento do motor de cálculo que processa as respostas do formulário e atribui score e faixa a cada município.
• Construção do dashboard gerencial, com ranking, cadeia de envios por domínio e corte por macrorregião.
• 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.*