402 lines
16 KiB
Markdown
402 lines
16 KiB
Markdown
# 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.*
|