Marketplace PAT · Sustentação e backlog · Conclusão de Professional Services

Versão para o cliente. Conteúdo interno da Salesforce oculto.

01 · Conclusão

Sustentar a operação e entregar o backlog com a mesma equipe, em fases.

Depois do go-live de 15/11 e da operação assistida até 18/12, o Marketplace PAT precisa de uma equipe contínua. A implementação sai em 19/12, e a plataforma atende cerca de 600 usuários das facilitadoras e uma base de aproximadamente 1 milhão de estabelecimentos, com 32 APIs em produção.

A conclusão de Professional Services: 26 casos de uso no backlog pós-projeto. 16 têm prazo estimado, distribuídos em três fases de construção, e 10 seguem para discovery porque dependem de decisões de política pública ou de terceiros. Uma equipe de 4 recursos (140 h/semana) sustenta a operação e entrega os 16 casos em 6 a 9 meses no cenário base. O limite é de 12 meses: se a previsão passar disso, a capacidade aumenta ou o escopo diminui.

A ordem das fases não segue o valor aparente de cada item. Primeiro entram os requisitos que tornam a plataforma operável, segura e recuperável. Depois vêm as melhorias das jornadas existentes e, por último, as capacidades novas que dependem de licença, de decisão externa ou de dados que a primeira fase organiza.

Fase 1 · Fundação

casos de uso · semanas 1 a 10

Fase 2 · Jornadas

casos de uso · semanas 10 a 14

Fase 3 · Novas capacidades

casos de uso · semanas 14 a 32

Discovery · Ecossistema

casos de uso · prazo de construção só depois do discovery

02 · Casos de uso e fase

Cada caso de uso tem uma fase e um motivo para estar nela.

Os 26 casos vêm das revisões guiadas, das reuniões de arquitetura, dos status reports e do Documento de Visão. A fase depende de três critérios: se o caso sustenta os demais (fundação), se melhora uma jornada que já existe (jornadas) ou se adiciona uma capacidade nova que depende de licença ou de decisão externa (novas capacidades). Os casos sem dono definido ou que dependem de terceiros vão para discovery.

Fase 1 · Fundação

BPP_001, 002, 003, 007, 011, 012 e 016. Operar, proteger e recuperar.

Fase 2 · Jornadas existentes

BPP_004, 005 e 014. Melhorias sobre a base estabilizada.

Fase 3 · Novas capacidades

BPP_006, 008, 009, 010, 013 e 015. Dados, engajamento e IA.

Discovery · Ecossistema

BPP_017 a 026. Viabilidade, dono e tamanho antes de prazo.

Código	Caso de uso	Fase	Porte	Por que nesta fase	Dependência

Candidatos fora da lista oficial. As atas registram mais sete demandas. Duas entram na Fase 1 como parte da fundação: logs estruturados em JSON e a arquitetura de transição para o IDP da Dataprev. As outras cinco (confronto da folha com o eSocial, portal da facilitadora fase 2, download de anexos, extensão de prazo da cotação e logo da empresa) só entram por troca explícita de prioridade, sem aumentar o horizonte.

03 · Requisitos fundacionais

O que precisa existir antes da primeira entrega e o que a Fase 1 constrói.

Requisitos fundacionais são de dois tipos. Os de entrada são condições que a Dataprev e a Salesforce precisam garantir para a equipe começar. Os de plataforma são as capacidades que a Fase 1 constrói e que todas as fases seguintes usam.

Requisitos de entrada · até a semana 1

Continuidade a partir de 19/12. Contrato vigente na saída da equipe de implementação, sem lacuna de cobertura.
Acessos e ambientes. Orgs, repositório, pipeline de deploy, massa de teste e acessos às integrações.
Ferramenta de gestão de defeitos. Definida pela Dataprev para registrar, priorizar e medir chamados.
Responsáveis nomeados. Decisor com resposta em até 48 horas, dono técnico das integrações e dono do produto.
Contrato de interface com o MuleSoft. Fronteira clara entre o que é PAT e o que é da proposta MuleSoft.
Escopo do projeto atual fechado. Item não concluído no projeto de implementação não migra para a sustentação.
Modelo de atendimento acordado. Horário comercial, severidades e definição sobre 24x7.

Requisitos de plataforma · construídos na Fase 1

Operação governada. Catálogo de serviços, severidades, triagem, runbooks e escalonamento (BPP_016).
Observabilidade. Logs estruturados, correlação ponta a ponta e alertas mínimos (candidato de logs JSON).
APIs resilientes e justas. Deduplicação, limite de chamadas e consultas otimizadas (BPP_001, 002 e 003).
Falha recuperável. Fila de exceção e reprocessamento sem perda de proposta (fatia mínima do BPP_007).
Acesso e acessibilidade. Permissionamento granular e VLibras (BPP_011 e 012).
Qualidade e release. Regressão automatizada de cotação, proposta, contrato e folha, com critério de go/no-go.
Transição de identidade. Arquitetura para o IDP da Dataprev, pronta para construir quando ele estiver disponível.

04 · Faseamento

Três fases de construção, uma trilha de discovery e a sustentação o tempo todo.

As fases se sobrepõem quando não há dependência técnica entre elas. Cada fase tem um gate de entrada (o que precisa estar decidido) e um critério de saída (o que precisa estar em produção). A sustentação corre durante todo o período e tem prioridade sobre a evolução quando há incidente.

Linha do tempo do cenário base

Semanas 1 a 10

Fase 1 · Fundação

Deixa a plataforma operável, segura e recuperável. Reduz os incidentes que consumiriam a capacidade da sustentação.

Casos: BPP_001, 002, 003, 007 (fatia mínima), 011, 012 e 016
Gate de entrada: Requisitos de entrada atendidos; contrato de interface com o MuleSoft
Saída: Runbooks ativos, alertas, regressão automatizada e reprocessamento em produção

Semanas 10 a 14

Fase 2 · Jornadas existentes

Melhora a experiência da beneficiária e da facilitadora sem nova arquitetura, usando a base que a Fase 1 estabilizou.

Casos: BPP_004, 005 e 014
Gate de entrada: APIs estáveis; go/no-go e licença para o agente informativo
Saída: Lida/não lida, rascunho de cotação e FAQ do agente em produção

Semanas 14 a 32

Fase 3 · Novas capacidades

Duas frentes. Dados e analytics (BPP_008, 009, 010) e engajamento e IA (BPP_006, 013, 015). Cada item grande é quebrado em entregas.

Casos: BPP_006, 008, 009, 010, 013 e 015
Gate de entrada: Licenças contratadas; réplica Oracle dimensionada; regra de contrato decidida
Saída: Cada frente fecha quando o item está em produção ou é retirado por decisão

Semanas 12 a 19

Discovery · Ecossistema

Trilha paralela e de baixa intensidade. Define viabilidade, dono, dependências e porte de cada caso. Não inclui construção.

Casos: BPP_017 a 026
Gate de entrada: Interlocutores do MTE, DTI e parceiros disponíveis
Saída: Decisão por caso: construir em contrato próprio, adiar ou descartar

Regras do faseamento. Nenhum item grande entra inteiro na Fase 1: o BPP_007 entra só com a fatia de reprocessamento, e o IDP entra só como arquitetura. Um caso cujo gate não estiver atendido na data prevista não trava a fase: ele sai da fila, e o próximo pronto entra no lugar.

05 · Recursos

Quatro pessoas, 140 horas por semana, divididas entre operação e backlog.

A mesma equipe sustenta e evolui. No cenário base, 35% da capacidade (49 h/semana) fica reservada para a sustentação e 65% (91 h/semana) vai para o backlog. A divisão é revista a cada mês com base no volume real de incidentes.

40 h/sem

Technical Architect (TA)

Sustentação: diagnóstico de incidentes complexos, performance, segurança e integrações.

Backlog: arquitetura das fases, padrões, revisão técnica e decisões de integração com MuleSoft e Oracle.

1.040 a 1.560 h no horizonte de 6 a 9 meses

40 h/sem

Solution Architect (SA)

Sustentação: análise funcional dos chamados, regras de negócio e configuração.

Backlog: refinamento dos casos de uso, critérios de aceite e desenho das jornadas.

1.040 a 1.560 h no horizonte de 6 a 9 meses

40 h/sem

Technical Consultant / DEV

Sustentação: correções, deploys, testes de regressão e evidências.

Backlog: desenvolvimento, automação de testes e preparação de release.

1.040 a 1.560 h no horizonte de 6 a 9 meses

20 h/sem

Project Manager (PM)

Sustentação: níveis de atendimento, relatórios e comitê de severidade.

Backlog: priorização, gates de fase, riscos, bloqueios e controle de mudança.

520 a 780 h no horizonte de 6 a 9 meses

Opção somente sustentação. Se a Dataprev contratar só a operação, a equipe cai para metade (cerca de 70 h/semana) e o backlog não avança. É uma alternativa válida, mas não entrega nenhum dos 16 casos de produto.

06 · Tempo e esforço

Entre 2.300 e 3.540 horas de backlog, o que dá 6 a 9 meses no cenário base.

O esforço vem do porte de cada caso de uso. Os itens grandes são estimados já quebrados em entregas. O total inclui 10% para regressão, release e documentação. Dividido pela capacidade de evolução do cenário base (91 h/semana), dá 25 a 39 semanas.

P · 24 a 40 h

Ajuste isolado

Interface conhecida, baixo risco, aceite em uma entrega. Exemplo: VLibras, lida/não lida.

M · 80 a 140 h

Mudança transversal

Jornada existente, com testes e ao menos uma integração conhecida. Exemplo: limite de chamadas.

G · 200 a 280 h

Capacidade nova

Nova arquitetura ou produto. Sempre quebrada em entregas antes de começar.

D · 16 a 32 h

Discovery

Define dono, dependências, viabilidade e porte. Não inclui construção.

Fase	Composição	Esforço	Semanas (91 h/sem)
Fase 1	3 P, 3 M, fatia do BPP_007, logs JSON (M) e arquitetura do IDP+10% de regressão e release	607 a 990 h	7 a 11
Fase 2	1 P e 2 M+10% de regressão e release	202 a 352 h	2 a 4
Fase 3	6 G, em duas frentes+10% de regressão e release	1.320 a 1.848 h	15 a 20
Discovery	10 D, em paralelo+10% de documentação das decisões	176 a 352 h	2 a 4
Total do backlog com prazo estimado		2.305 a 3.542 h	25 a 39

Esforço por fase (mínimo e máximo)

Quanto a operação pesa no prazo

O prazo depende de quanto a sustentação consome. Se a previsão passar de 12 meses, é obrigatório adicionar capacidade ou retirar casos de uso.

Cenário	Divisão da capacidade	Horas de backlog/semana	Previsão para os 16 casos
Operação estabilizada	20% sustentação · 80% backlog	112 h	5 a 7 meses
Base recomendado	35% sustentação · 65% backlog	91 h	6 a 9 meses
Alta pressão	50% sustentação · 50% backlog	70 h	8 a 12 meses · limite de exceção

07 · Bloqueios mapeados de antemão

Dezesseis bloqueios já conhecidos, cada um ligado a um caso de uso e a uma fase.

São decisões, dependências e riscos registrados durante a implementação. Nenhum deles depende só da equipe de Professional Services. A tabela mostra quando cada um precisa estar resolvido para não deslocar a fase.

Bloqueio	Casos afetados	Precisa estar resolvido	Responsável	Tratamento
CríticoLacuna entre 18/12 e o início do contrato	Toda a sustentação	Antes de 19/12	Dataprev e Salesforce	Assinatura antes da saída da equipe de implementação.
CríticoItens do projeto atual que podem escorregar	Todas as fases	Antes da Fase 1	Dataprev e Salesforce	Controle de mudança. O item fica no projeto atual e não migra para a sustentação.
Atendimento 24x7 indefinido	Modelo de sustentação	Antes do contrato	Dataprev	Sem 24x7 no escopo. Se exigido, a Dataprev aloca plantão ou contrata parceiro.
Ferramenta de gestão de defeitos não escolhida	BPP_016	Semana 1	Dataprev	Escolha na mobilização; sem ela não há medição de atendimento.
Governança e capacidade do MuleSoft on-premise	BPP_002, BPP_007, logs JSON	Fase 1	Dataprev e proposta MuleSoft	Contrato de interface. Esta proposta cobre só o lado PAT.
Contratos de API e massa de teste das facilitadoras	BPP_001, 002, 003	Fase 1	Dataprev e facilitadoras	Massa mínima até a semana 2 para testar limites e deduplicação.
SSO com GerID (SAML e criação de usuário no primeiro acesso) atrasado	BPP_011	Fase 1	Dataprev	Permissionamento construído sobre o modelo atual e adaptado quando o SSO chegar.
IDP da Dataprev indisponível para facilitadoras	Arquitetura do IDP, BPP_011	Fase 1	Dataprev	Fase 1 entrega só a arquitetura de transição. A construção entra quando o IDP existir.
Autenticação das adquirentes para cerca de 1 milhão de estabelecimentos	BPP_011, BPP_018	Fase 1	Dataprev	Decisão necessária para fechar o modelo de acesso.
Layout do arquivo da folha	Regressão de folha, confronto com eSocial	Fase 1	Dataprev e MTE	Layout congelado antes de automatizar a regressão.
Criptografia (Shield) nos dados da folha	Regressão de folha, BPP_009, BPP_010	Fase 1 Fase 3	Dataprev	Decisão de segurança antes de usar dados da folha em analytics.
Go/no-go da produtização do agente conversacional	BPP_014, BPP_015	Fase 2	Dataprev e MTE	Sem decisão, o BPP_014 sai da Fase 2 e o BPP_015 sai da Fase 3.
Licenças de produto	BPP_009, 010, 013, 014, 015	Fase 2 Fase 3	Dataprev e Salesforce	Contratação até o gate de cada fase; caso sem licença sai da fila.
Réplica Oracle sem dimensionamento (microbatch e WSO2)	BPP_008, BPP_009	Fase 3	Dataprev infraestrutura	Dimensionamento e dono definidos até a semana 12.
Regra de contrato PAT (três cenários) pendente no comitê	BPP_006	Fase 3	MTE	Decisão até a semana 14. Sem ela, o BPP_006 sai da Fase 3.
APIs do Novo PAT sob responsabilidade da DTI/MTE; API de aceite cancelada	BPP_024, BPP_006	Discovery Fase 3	DTI e MTE	Discovery define o contrato; sem API, a seleção de vencedora não é construída.

08 · Escopo da sustentação

O que a sustentação cobre e o que fica de fora.

Cobre

Correção de incidentes e defeitos em produção, por severidade, em horário comercial.
Análise de causa, runbooks e relatório mensal de atendimento.
Ajustes de configuração e pequenas melhorias dentro da capacidade reservada.
Deploys, regressão e gestão de releases.
Lado PAT das integrações, com contrato de interface acordado.
Apoio técnico às facilitadoras na integração com as APIs.

Não cobre

Atendimento de primeiro nível ao usuário final e plantão 24x7.
Infraestrutura e governança do MuleSoft on-premise (proposta separada).
Itens não concluídos do projeto de implementação.
Construção dos 10 casos do ecossistema, que exigem contrato próprio após o discovery.
Licenças de produto, que são contratadas à parte.

09 · Premissas

O prazo vale enquanto estas condições forem verdadeiras.

Premissas

Requisitos de entrada atendidos até o fim da semana 1.
Decisões da Dataprev e do MTE respondidas em até 48 horas.
Sustentação consumindo em média até 35% da capacidade.
Gates de fase atendidos nas datas da tabela de bloqueios.
Contrato com vigência anual e revisão mensal da priorização.

Gatilhos de revisão do plano

Sustentação acima de 50% da capacidade por dois meses seguidos.
Decisões passando de 48 horas de forma recorrente.
Licença ou decisão ausente no gate de uma fase.
Item do projeto atual migrando sem controle de mudança.
Previsão total passando de 12 meses.

Transparência: se um gatilho disparar, a previsão é recalculada e apresentada no comitê mensal com três opções: reforçar a capacidade, retirar casos de uso ou aceitar o novo prazo. Testes e governança não são cortados para esconder atraso.

10 · Próximos passos

Do statement à proposta.

Validar o faseamentoRevisar com a Dataprev a fase de cada caso de uso e os gates de entrada.

Fechar os bloqueios críticosData de início do contrato, fronteira com o projeto atual e definição sobre 24x7.

Alinhar a fronteira MuleSoftContrato de interface entre esta proposta e a proposta MuleSoft.

Formalizar a propostaEquipe de 140 h/semana, vigência anual e revisão mensal da priorização.

Uso interno Salesforce · não compartilhar com o cliente

11 · Visão interna

Como defender a oportunidade internamente.

A oportunidade PAT Sustentação no Org62 é continuidade operacional mais backlog faseado, com vigência anual. A capacidade anual da equipe não é promessa de escopo: o compromisso é com os 16 casos de produto no horizonte de 6 a 9 meses e com a sustentação durante toda a vigência.

Origem da composição

A equipe segue a proposta do Rafael: TA 40h, SA 40h, DEV ou TC 40h e PM 20h, total de 140 h/semana. Só sustentação equivale a metade. Conversa com Juliana Brites e Rafael Roquette em 14/10.

MuleSoft em proposta separada

Pedido da Ludmila. A avaliação de governança e capacidade do MuleSoft on-premise está com a Diana e o Vanderlei. Esta proposta cobre só o lado PAT das integrações.

Validações técnicas pendentes

Fechar com Eric e Nelson se o BPP_007 pode ser fatiado na Fase 1 e qual parte pertence à proposta MuleSoft, e se os logs estruturados em JSON estão prontos para entrar na fundação.

Cuidados na conversa com o cliente

Não citar a base interna de onde veio o backlog. Não apresentar valores nem margem neste material. O risco de integradores é baixo, mas a falta de massa de teste das facilitadoras é um bloqueio real da Fase 1.

Fontes

Granola, reunião de 14/10/2026 com Juliana Brites e Rafael Roquette.
Slack do Rafael, 15/10/2026, com a composição da equipe.
Backlog pós-projeto do PAT (Jabba), com decisões, riscos e atas das revisões guiadas, arquitetura, dailies e status reports.
Documento de Visão v0.7, para os casos do ecossistema.