16 KiB
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:
- O problema de gestão — o que trava, o que a SES-MG não consegue fazer hoje
- O insumo disponível — o que já existe e por que não basta na forma atual
- O que a demanda entrega — a solução em termos concretos
- O achado ou resultado, quando houver
- 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.