Novo PSA · TBC — Visão do Projeto e Discovery DDD
Atualização de 07/10. A reunião de 06/10 com o backoffice mudou o escopo, o modelo e a abordagem do projeto. A conciliação com esta análise está na aba Conciliação · reunião 06/10.
Resumo executivo
O Novo PSA Financeiro tem uma base técnica sólida, mas o domínio ainda não foi validado com quem opera o financeiro de serviços no CSC. A recomendação é pausar código novo por duas semanas e rodar um Discovery Sprint de validação, usando o protótipo navegável como instrumento.
O que é. Substituir a parte financeira do PSA atual (Dynamics 365 Project Operations) por um sistema próprio, integrado ao Protheus. confirmado
Por que importa. O apontamento de horas é a principal reclamação, e o custo apontado diverge cerca de 25% do custo real do DRE. A alçada por faixa de margem dá lugar a uma aprovação de estouro chamada Investimento. confirmado
Onde está. São 69 requisitos ativos, 10 módulos de domínio em código e 200 testes automatizados passando localmente. A publicação no ambiente de teste está parada por falta de acesso ao servidor. confirmado
O que encontramos. O método DDD foi seguido na forma, mas sem as sessões com operadores que o próprio veredito do projeto exigia. Os sintomas já aparecem: renomeação estrutural depois do código, escopo descoberto tarde e o indicador central (custo real × DRE) ainda sem cálculo. confirmado
O que propomos. Sete dias úteis com operadores do CSC (PMO, coordenadores, faturamento, controladoria, RH) para decidir 12 pontos críticos e o recorte do primeiro lançamento. hipótese — proposta
As três decisões que mais mudam o desenho: como o custo mensal vira custo-hora; se horas de Investimento geram receita; e como o faturamento por parcela alimenta Buffer e Backlog. hipótese
Legenda usada em todo o documento: confirmado = está registrado no repositório como decisão ou dado; hipótese = inferência nossa, ainda não validada com o time TBC.
Contexto e problema
Hoje o financeiro dos serviços da TBC roda no Dynamics 365 Project Operations, customizado e ligado ao Protheus por tabelas-espelho e rotinas ADVPL. O volume é relevante: 2.103 contratos, 2.093 projetos e 76.843 apontamentos registrados no Protheus. confirmado
| Dor | Evidência no repositório | Efeito no negócio |
|---|---|---|
| Apontamento difícil | "Principal problema hoje reclamado" (spec, Contexto) confirmado | Horas lançadas tarde ou erradas; fechamento do mês pesado |
| Custo por função, não por pessoa | Defasagem de ~25% entre custo apontado e custo real do DRE confirmado | Margem de projeto não confiável para decisão |
| Alçada por faixa de margem | Termos NCC, write-up, RDA e ITA descartados pelo negócio confirmado | Aprovação complexa e pouco explicável |
| Planejamento sem visão | "O calendário está branco, não tenho visão do planejamento" (feedback de 26/09) confirmado | PMO só vê o projeto depois das horas lançadas |
| Integração frágil com o Protheus | Pedido de venda responde "ok" mesmo quando falha; entrada REST sem autenticação; limite de 4 parcelas por pedido confirmado | Falhas silenciosas no faturamento |
O que não muda. O Protheus segue como ERP (pedido, nota fiscal, títulos, folha e cadastro de clientes) e o CRM segue com a proposta comercial. Contratos antigos não migram para o modelo novo nesta fase. confirmado
Objetivos, resultados e indicadores
O projeto nasceu para fechar a defasagem de custo e simplificar a aprovação de estouro. O código já cobre a maior parte dos fluxos, mas só o reconhecimento de receita tem indicador calculado hoje.
| Resultado esperado | Como medir | Situação no código |
|---|---|---|
| Custo real por pessoa e margem confiável | Defasagem custo apontado × DRE: hoje ~25% confirmado; meta a definir com a controladoria hipótese | Custo mensal digitado à mão; custo-hora e margem corrente não implementados confirmado |
| Apontamento simples e confiável | % de OS aprovadas dentro do mês; OS descartadas no fechamento hipótese | Agenda e ciclo da OS prontos; indicador não existe confirmado |
| Estouro governado por Investimento | Investimento liberado ÷ valor original do contrato; tempo até a liberação hipótese | Fluxo GPP → Diretor pronto; sem notificação ativa confirmado |
| Receita reconhecida pela Entrega | Receita reconhecida × faturada; Buffer e Backlog por projeto confirmado | Calculado por projeto; faturamento em horas lançado à mão confirmado |
| Faturamento sem falha silenciosa | Parcelas faturadas no prazo; falhas de integração detectadas hipótese | Lado do Novo PSA pronto; lado Protheus ainda não existe confirmado |
| Visão de planejamento e portfólio | Projetos atrasados; utilização da equipe hipótese | Cronograma simples pronto; capacidade e portfólio não iniciados confirmado |
Os quatro indicadores levantados na reunião de 25/09 seguem válidos: margem realizada (custo e hora vendidos × hora realizada), receita reconhecida × faturada, Buffer e Backlog por projeto, e a defasagem contra o DRE. confirmado
Atores, áreas e sistemas
O modelo tem cinco perfis bem definidos, mas três áreas que decidem regras financeiras ainda não aparecem como atores: controladoria, faturamento e RH. A reunião de origem (25/09) teve Jessica Araújo Pessoa (PMO), Leandro (TI) e Lemos (Diretor). confirmado
| Ator ou área | Papel | O que decide | Situação no modelo |
|---|---|---|---|
| Coordenador de Projeto | Planeja a Agenda, cria as OS, solicita Investimento, mantém o cronograma | Quem trabalha em qual dia; pedido de horas extras | Modelado confirmado |
| Substituto Temporário | Mesmo acesso do coordenador por período definido | — | Modelado confirmado |
| PMO | Cadastra contratos e projetos, libera projetos, transfere saldo, conduz as parcelas | Estrutura e saldo inicial | Modelado confirmado |
| Admin PMO | Reabre período fechado | Exceções depois do fechamento | Modelado confirmado |
| GPP (Gestor de Portfólio do Projeto) | Primeiro aprovador de todo Investimento | Até 2% acumulado do valor original do contrato | Modelado; vínculo do GPP com unidade ou projeto não existe confirmado |
| Diretor | Aprovador acima da alçada do GPP | Investimentos que estouram o teto | Modelado confirmado |
| Consultor | Executa o trabalho e tem custo individual | — | Não usa o sistema: o coordenador registra planejado, realizado e aprovado confirmado; se é assim na prática, falta validar hipótese |
| Controladoria | Dona do DRE, da receita e da margem | Regra de reconhecimento e custo-hora | Ausente do modelo hipótese |
| Faturamento do CSC | Libera parcelas e acompanha pedido, nota e recebimento | Quando e quanto faturar | Representado pelo perfil PMO no código confirmado |
| RH e Folha | Fonte do custo mensal por pessoa | — | Integração não construída confirmado |
| Responsável Portfólio | Papel preenchido em 100% dos projetos no Protheus | — | Não modelado; pode ser o próprio GPP hipótese |
Sistemas. Dynamics 365 Project Operations (a substituir); Protheus (pedido de venda, nota fiscal, títulos, folha e clientes); CRM (origem da proposta); Novo PSA Financeiro (contratos, projetos, apontamento, Investimento, custo, receita e parcelas). confirmado
Fluxo do negócio de ponta a ponta
O caminho do contrato até a receita está modelado e codificado; o que ainda depende de decisão fica em custo, receita, margem e faturamento. confirmado
Exceções já cobertas no modelo: saldo insuficiente bloqueia o planejamento; descarte de OS exige motivo; reprovação de Investimento exige justificativa; o consultor não pode ter duas OS no mesmo dia; coordenador ausente ganha substituto temporário; falha na integração com o Protheus aparece como erro, nunca como sucesso. confirmado
Mapa detalhado. Os seis subprocessos (contratação, agenda e apontamento, Investimento, fechamento do mês, faturamento e recebimento, custo, receita e margem) estão desenhados em raias, com quem faz cada etapa, as regras do sistema e os pontos críticos no lugar onde aparecem: Mapa de processos do Novo PSA.
Escopo funcional e fora de escopo
Oito capacidades já existem em código; três estão parciais, duas delas no centro do problema (custo e receita); e quatro frentes não foram iniciadas ou sequer levantadas.
| Capacidade | Requisitos | Situação | Observação |
|---|---|---|---|
| Contratos (dados, cliente, motivo CFP, valor original e recalculado, margem vendida) | REQ-001, 007, 008, 054–060, 067, 068, 070 | Pronto confirmado | Descrição dos 22 motivos CFP "a confirmar" |
| Projetos (cadastro, liberação, saldo, coordenador, substituto, reequilíbrio) | REQ-004–014, 040–043, 069 | Pronto confirmado | Estado "Pré-encerrado" do Protheus não existe |
| Agenda e Apontamento (ciclo da OS, bloqueio de agenda, descarte, KM) | REQ-015–019 | Pronto confirmado | Regra de KM entrou em 28/09 sem requisito escrito |
| Investimento (alçada acumulada, GPP → Diretor) | REQ-020–026 | Pronto confirmado | Sem notificação ativa ao solicitante |
| Parametrização financeira versionada | REQ-031, 032 | Pronto confirmado | Quem pode alterar ainda indefinido |
| Fechamento e reabertura de período | REQ-037, 038 | Pronto confirmado | Ninguém dispara o fechamento automaticamente |
| Cronograma (tarefas e marcos) | REQ-044–050 | Pronto confirmado | Modelado sem entrevista com o PMO |
| Parcelas e integração com o Protheus | REQ-051–053, 060–066 | Pronto do nosso lado confirmado | Lado Protheus não existe; fora do trilho de Discovery |
| Custo por pessoa e rateio de coordenação | REQ-027–030 | Parcial confirmado | Custo digitado; sem integração com a folha; custo-hora indefinido |
| Receita, Buffer e Backlog | REQ-033–036 | Parcial confirmado | Faturamento em horas sem origem; sem relatório consolidado |
| Auditoria de alterações | REQ-039 | Parcial confirmado | Cobre 2 operações de reabertura |
| Margem corrente do contrato | REQ-002 | Não iniciado confirmado | Depende da regra de custo-hora |
| Autenticação e perfis reais | — | Não iniciado confirmado | Perfil hoje simulado por cabeçalho |
| Capacidade de recursos, desempenho (valor agregado) e portfólio | — | Não iniciado confirmado | Lacunas registradas em 26/09, não priorizadas |
| Despesas além de KM, change request, adiantamentos e honorários, listas de preço | — | Não levantado confirmado | Telas do PSA atual ainda não analisadas |
Fora de escopo, por decisão registrada. Cotação e proposta (ficam no CRM); emissão de nota e contabilidade (ficam no Protheus); migração dos contratos antigos; alçada por faixa de margem; desvinculação entre remuneração e hora apontada. confirmado
Aplicação do DDD: avaliação e abordagem
Sim, o DDD deve ser aplicado — e o próprio projeto chegou a essa conclusão em 24/09. O que falta é a parte do método que foi pulada: descobrir e validar o domínio com quem opera o financeiro no dia a dia.
Critérios de aplicação da Fase Zero (Discovery Sprint).
| Sinal | Evidência neste projeto | Atende |
|---|---|---|
| Vocabulário técnico próprio (financeiro e contábil) | Entrega, Buffer, Backlog, alçada, Investimento, motivo CFP confirmado | Sim |
| Áreas usando nomes diferentes para a mesma coisa | "Split" virou "Projeto"; "Contingência" é "Investimento"; a "Tarefa" do apontamento real não é a tarefa do cronograma confirmado | Sim |
| Fluxo financeiro entre partes | Faturamento, baixa de títulos, rateio de coordenação, KM, tributação confirmado | Sim |
| Muitos "depende" | Método de cobrança no contrato ou no projeto; 22 motivos CFP; data do trabalho × data contábil confirmado | Sim |
| Regras por estado, perfil ou momento do mês | Fechamento mensal, alçada acumulada, substituto temporário confirmado | Sim |
Resultado: 5 de 5 sinais. O veredito de 24/09 marcou 3 de 5 porque dois sinais só aparecem com pessoas reais — e eles apareceram depois, já com código escrito.
O que foi bem feito. Veredito de encaixe antes de especificar, com riscos explícitos. Separação entre intenção, planejamento, execução e resultado, com agregados pequenos. Indicadores calculados a partir de eventos, nunca gravados como contador. Registro honesto da proveniência de cada bloco. confirmado
O que foi pulado, e o sintoma de cada lacuna.
| Etapa da Fase Zero | O que aconteceu | Sintoma observado |
|---|---|---|
| Entrevistas com operadores (6 a 8 sessões) | Uma reunião de origem e perguntas respondidas por TI; a pauta de liberação dos operadores foi preparada, mas a liberação não está registrada confirmado | As 7 fases foram concluídas em dois dias; regras de custo e receita foram inferidas, não ouvidas |
| Event Storming com o negócio | Não houve confirmado | Pontos críticos descobertos depois do código |
| Validação do modelo com o negócio | Feita por TI a partir de telas do PSA confirmado | Renomeação Split → Projeto depois do código: 8 tarefas de retrabalho e suíte de testes reescrita (de 285 para 147) |
| Aterrissagem controlada na especificação | Dois blocos entraram fora do trilho (REQ-060 a 070) confirmado | Integração e cadastros sem modelo de domínio validado |
O código não é desperdício: ele virou um protótipo funcional do domínio. O risco é seguir para produção com regras financeiras inferidas. hipótese
Abordagem recomendada: Discovery Sprint de validação, sem recomeçar.
Hipótese de partida: os 18 documentos de Discovery, a especificação e o código atual.
Instrumento: o protótipo navegável e um Event Storming com operadores do CSC.
Foco: os 12 pontos críticos listados adiante, começando por custo-hora, receita do Investimento e faturamento.
Saída: glossário e mapa de contextos revisados, decisões registradas, recorte do primeiro lançamento e especificação atualizada.
Critério de saída: o CSC reconhece o próprio negócio no modelo.
O custo é de uma a duas semanas sem código novo. O ganho é evitar a segunda renomeação estrutural, agora com regras de dinheiro envolvidas. hipótese
Linguagem ubíqua preliminar
O glossário do projeto é um bom ponto de partida, mas quase todo termo financeiro ainda carrega uma ambiguidade que só o operador resolve. A coluna da direita é a pauta da Fase 2 com o CSC.
| Termo | Significado no modelo atual | Ambiguidade ou contraexemplo a validar |
|---|---|---|
| Contrato | Vínculo comercial com o cliente; agrupa 1 a N Projetos; guarda Valor Original (teto negociado) e Valor Recalculado (consolidado) confirmado | No Protheus, 95% dos contratos têm coordenador próprio, além do coordenador de cada projeto confirmado. Quem responde pelo contrato? |
| Projeto (antigo Split) | Unidade de saldo, coordenação e planejamento; numeração derivada do contrato (1234-01) confirmado | O Protheus tem 4 estados, incluindo Pré-encerrado; o modelo tem 3 confirmado |
| Saldo do Projeto | Horas disponíveis, consumidas no planejamento da OS e devolvidas no descarte confirmado | Uma hora liberada por Investimento vale o mesmo que uma hora vendida? hipótese |
| Apontamento (= OS) | Horas de um consultor em um dia: Planejado, Realizado, Aprovado ou Descartado confirmado | O Protheus separa data do trabalho e data de contabilização; o modelo guarda só uma confirmado |
| Entrega | OS aprovada; régua de toda receita confirmado | Contraexemplo: hora faturada sem OS aprovada não é Entrega confirmado |
| Investimento ("Contingência" no PSA atual) | Pedido de horas extras quando o saldo esgota, aprovado pelo GPP e, acima do teto, também pelo Diretor confirmado | É custo absorvido pela TBC ou aditivo pago pelo cliente? A resposta muda receita e margem hipótese |
| Alçada do GPP | Até 2% do Valor Original do contrato, somando os Investimentos já liberados confirmado | Pedidos ainda pendentes não entram na soma confirmado. É intencional? |
| Valor-Hora de Investimento | Referência para converter horas pedidas em reais, só para a alçada confirmado | Não é o custo do consultor nem o preço de venda confirmado |
| Custo do Colaborador | Custo mensal por pessoa (folha fixa e variável), versionado por mês confirmado | Como vira custo-hora: horas úteis, apontadas ou aprovadas? Inclui encargos? hipótese |
| Rateio de Coordenação | 20% somados ao custo do analista no apontamento, versionado por data confirmado | Não incide sobre as horas do próprio coordenador confirmado |
| Buffer | Horas entregues e ainda não faturadas confirmado | O faturamento real é por parcela em reais no contrato; o Buffer usa faturamento em horas por projeto confirmado |
| Backlog | Horas faturadas e ainda não entregues; abate a receita do mês confirmado | Mesmo ponto do Buffer |
| Margem Vendida | Calculada na criação do contrato e congelada confirmado | Diferente da Margem do Contrato corrente, que ainda não tem fórmula confirmado |
| Motivo CFP | Classificação comercial e fiscal do contrato; 22 códigos reais confirmado | Só 5 códigos geram pedido de venda hoje; descrições "a confirmar" confirmado |
| Método de Cobrança | Preço Fechado, Banco de Horas, Tempo e Material (exemplos do projeto) confirmado | No Protheus aparece no contrato e no projeto. Muda a regra de receita? hipótese |
| Parcela de Faturamento | Fração do contrato a faturar: Aguardando, Liberada, Pedido Gerado, Faturada confirmado | Ciclo proposto por TI a partir de descrição verbal, sem lista fechada de campos confirmado |
| KM | Distância até o cliente × 2 em OS presencial de projeto que cobra KM confirmado | Reembolso ao consultor, cobrança ao cliente ou ambos? hipótese |
| Tarefa | Item do cronograma; Marco é tarefa de duração zero confirmado | No apontamento real, "tarefa" significa "mês + pessoa" confirmado |
| Fechamento de Período | Fim do mês: OS não aprovadas são descartadas; só o Admin PMO reabre confirmado | Quem dispara e em que dia? Hoje o disparo é manual confirmado |
Termos descartados, para não reintroduzir: NCC, write-up/eficiência, RDA, ITA e alçada por faixa de margem. confirmado
Eventos de domínio (Big Picture preliminar)
O modelo já trata os fatos de contratação, execução, Investimento e faturamento, mas três fatos de que o negócio depende ainda não existem: custo-hora calculado, margem apurada e faturamento por projeto. hipótese
Este quadro é o ponto de partida do Event Storming com o CSC: cada evento tracejado precisa de dono, gatilho e regra, e cada ponto crítico vira uma pergunta na parede.
Subdomínios e contextos delimitados
A divisão atual em módulos é boa. O ajuste proposto é tratar receita e margem como núcleo, dar contexto próprio a faturamento e a despesas, e criar identidade e acesso antes de produção. hipótese
Núcleo é onde a TBC decide a rentabilidade dos serviços: merece a validação mais funda. Suporte é necessário e específico da TBC. Genérico pode usar solução pronta.
| De | Para | O que passa | Tipo de relação |
|---|---|---|---|
| CRM | Contratação | Proposta fechada, hoje redigitada confirmado | Conformista, sem integração |
| Contratação | Apontamento | Projeto liberado com saldo e coordenador confirmado | Fornecedor e cliente |
| Apontamento | Investimento | Falta de saldo confirmado | Evento |
| Investimento | Contratação | Saldo e valor recalculado ampliados confirmado | Evento |
| Apontamento | Receita e margem | Entrega (OS aprovada) confirmado | Evento |
| Custo e remuneração | Receita e margem | Custo-hora por pessoa e mês hipótese | Linguagem publicada, a construir |
| Faturamento | Receita e margem | Valor faturado por projeto hipótese | A definir (ponto crítico 4) |
| Parametrização | Investimento e custo | Parâmetros vigentes na data do fato confirmado | Linguagem publicada |
| Protheus | Faturamento, custo e despesas | Pedido, nota, baixas, folha e KM confirmado | Camada anticorrupção; lado Protheus a construir |
Protótipo de validação
Atualizado em 19/10 (versão 3). Entraram as telas de cotações, banco de horas e status report, a aprovação de horas pela coordenação e o portal do cliente com horas e saldo, a partir das fontes recebidas entre 09 e 17/10. As respostas da TBC vão até 27/10. As telas marcadas como v2 foram propostas depois da reunião de 06/10; as marcadas como v3, em 19/10.
O protótipo reproduz as regras do repositório com dados fictícios: cinco contratos, seis projetos, cinco clientes e uma equipe de onze pessoas, todos inventados. É o instrumento das sessões de validação, não o sistema em produção; nenhum número dele deve ser lido como dado da TBC.
Como usar nas sessões. “Ver como”, na faixa do protótipo, troca o papel: PMO, coordenação, consultores, GPP, Diretor, Admin PMO, controladoria (proposto) e cliente. Cada papel abre na tela que usa no dia a dia. Com o modo validação ligado, marcadores em âmbar mostram onde cada pergunta aparece: 1 a 12 são os pontos críticos, C1 a C8 as contradições e divergências, N1 a N13 as divergências novas de 09 a 17/10 e P1 a P11 as perguntas sem bloqueio. Cada marcador abre o ponto, mostra o que as fontes dizem e, quando há regra alternativa, deixa simular o efeito antes de registrar a resposta.
Respostas. O roteiro de validação reúne os itens com a situação (confirmado, precisa ajuste, em aberto) e o texto da decisão. Quem abre a página com acesso de edição registra para todo o time; quem só visualiza vê as respostas do time e guarda as suas no próprio navegador. “Copiar respostas” leva tudo para a ata.
| Tela | Para quem | O que a sessão decide | Marcadores |
|---|---|---|---|
| Painel do PMO | PMO | Se os indicadores do contrato bastam para o dia a dia e o que espera decisão do CSC | 4, 5 |
| Cotações v3 | Controladoria | Conferência da cotação, filial, fator e motivo CFP, ganhar ou devolver ao CRM, contrato sem redigitação | 3, 4, 9, C4, N13 |
| Banco de horas v3 | PMO e coordenação | Saldo, vencimento, alertas e extrato mensal de cada cliente | N2, P9 |
| Status report v3 | PMO, controladoria e diretoria | Semáforos que nascem dos eventos, com “sem dado” quando falta origem | C6, N11, P10 |
| Contratos e contrato | PMO e faturamento | Dados que chegam do CRM, unidade de venda, Motivo CFP, método de cobrança, parcelas e pedido de venda no Protheus | 3, 4, 5, 9, 10, 11, C2, C4, C5, C8, P1, P4, P6 |
| Agenda do coordenador | Coordenação | Quem lança o realizado, se o dia pode ser dividido entre projetos, consumo do saldo e KM | 6, 7, 12 |
| Minhas horas v2 | Consultores, coordenação e GPP | Confirmação da OS com descrição e evidência, trava depois de confirmada, antecedência, conflitos de janela e confirmação pelo WhatsApp | 8, C7, P7, P8, N1, N3, N4, N5 |
| Aprovação de horas v3 | Coordenação e GPP | A coordenação aprova ou rejeita com motivo; o GPP acompanha. Conflitos de agenda, atrasos e efeito na margem | 5, C6, C7, P7, N1 |
| Fechamento do mês | PMO e contabilidade | Dia do fechamento e destino das OS realizadas e não aprovadas | 8 |
| Investimentos | Coordenação, GPP e Diretor | Natureza do Investimento, cadeia de aprovação, teto do GPP e pedidos pendentes na alçada | 2, 11, P1, P5 |
| Receita e margem | Controladoria e Diretoria | Receita por Entrega, horas de Investimento, regra por método de cobrança, parcela em horas e proposta de margem | 1, 2, 3, 4, 5 |
| Custo-hora | Controladoria e RH | Divisor do custo mensal (horas úteis, apontadas ou aprovadas), encargos e rateio de coordenação | 1 |
| Portal do cliente v3 | Cliente | Horas aprovadas e saldo sem valores, confirmação da agenda da semana, aceites, riscos e canal com o time | 3, P9, P10, N6, N8 |
| Parametrização | PMO e Diretoria | Quem altera alçada, valor-hora de Investimento e rateio; significado dos 22 Motivos CFP | 9, P3 |
| Roteiro de validação | Todos | Registro das respostas, item a item | Todos |
Pontos críticos, hipóteses e perguntas para o time TBC
Doze pontos decidem se o sistema entrega o que prometeu; dez deles bloqueiam o primeiro lançamento. Os cinco primeiros mexem diretamente em custo, receita e margem.
| # | Ponto crítico | Por que importa | Pergunta ao CSC | Quem responde | Bloqueia o 1º lançamento |
|---|---|---|---|---|---|
| 1 | Custo-hora | Decide se a defasagem de ~25% contra o DRE fecha hipótese | O custo mensal vira custo-hora dividido por horas úteis, apontadas ou aprovadas? Entram encargos, férias e 13º? E o tempo sem alocação? | Controladoria e RH | Sim |
| 2 | Investimento e receita | A receita usa valor original ÷ horas vendidas para toda hora entregue, inclusive as de Investimento confirmado; se o cliente não paga essas horas, a receita pode passar do valor do contrato hipótese | Investimento é custo absorvido pela TBC ou aditivo cobrado? Horas de Investimento geram receita? | Diretoria e controladoria | Sim |
| 3 | Receita por método de cobrança | Uma regra única serve Preço Fechado, Banco de Horas e Tempo e Material confirmado | Cada método reconhece receita do mesmo jeito? O valor-hora vem do contrato ou da lista de preço? | Controladoria | Sim |
| 4 | Faturamento em dois modelos | Buffer e Backlog usam horas faturadas por projeto, lançadas à mão; o faturamento real é parcela em reais no contrato confirmado | Como uma parcela vira horas faturadas de cada projeto? | Faturamento e controladoria | Sim |
| 5 | Margem corrente do contrato | Indicador central sem fórmula (REQ-002) confirmado | Margem é receita reconhecida menos custo apontado? Inclui despesas e KM? Mensal ou acumulada? | Diretoria e controladoria | Sim |
| 6 | Quem lança o realizado | A maior reclamação é o apontamento, e no modelo só o coordenador registra confirmado | O consultor lança as próprias horas ou o coordenador lança por ele? | PMO e coordenadores | Sim |
| 7 | Bloqueio de agenda | Hoje qualquer segunda OS no mesmo dia é bloqueada, mesmo 4h + 4h confirmado | Um consultor pode dividir o dia entre dois projetos? | PMO e coordenadores | Sim |
| 8 | Fechamento do mês | OS não aprovadas são descartadas; o disparo hoje é manual confirmado | Em que dia fecha? O que acontece com OS realizada e não aprovada por ausência do coordenador? | PMO e contabilidade | Sim |
| 9 | Motivo CFP e pedido de venda | 22 códigos em uso; só 5 geram pedido hoje confirmado | O que significa cada código e quais são faturáveis? | Faturamento e TI Protheus | Sim |
| 10 | Integração com o Protheus | O lado Protheus não existe confirmado | Quem constrói os serviços novos? Qual produto e TES usar? O número do contrato bate? | TI Protheus | Sim |
| 11 | Alçada com pedidos pendentes | Dois pedidos simultâneos podem ficar abaixo do teto do GPP e, somados, ultrapassá-lo hipótese | Pedidos pendentes entram na soma da alçada? | Diretoria | Não |
| 12 | Despesas e KM | KM entrou sem requisito escrito; outras despesas não foram levantadas confirmado | KM é reembolso, cobrança ou ambos? Hospedagem, alimentação e passagens entram? | Faturamento e RH | Não |
Perguntas sem bloqueio (P1 a P6 no protótipo). P1, GPP vinculado à unidade ou ao projeto; P2, papel do Responsável Portfólio; P3, quem altera a parametrização; P4, estados de encerramento (Pré-encerrado, saldo de projeto encerrado); P5, canal de notificação de aprovações; P6, método de cobrança e modalidade no contrato ou no projeto. confirmado
Contradições entre fontes (C1 a C5 no protótipo, na ordem abaixo), que não resolvemos por conta própria.
O veredito de 24/09 diz "bloqueado até liberar os operadores"; o cronograma marca a Etapa 0 como concluída no dia seguinte, sem registro da liberação.
A base da alçada é "valor do Projeto" nos documentos de Discovery e "valor do Contrato" na especificação depois da renomeação.
O fluxo de pedido aceita 5 motivos CFP; os contratos reais usam 22.
O número da proposta do CRM é obrigatório (REQ-054), mas cerca de 45% dos contratos reais não o têm.
O custo total do contrato é digitado (decisão de 26/09), mas na tela do PSA atual é um campo calculado.
Condições de entrada para produção. Autenticação real com os cinco perfis (hoje o perfil vem num cabeçalho da requisição). Trilha de auditoria completa (hoje cobre 2 operações). Ambiente dedicado com HTTPS. Política de uso de dados reais em desenvolvimento e de acesso à produção do Protheus. Acordo formal de integração com o time Protheus. Runbook, monitoramento, backup e ao menos dois administradores por camada. confirmado para o estado atual; hipótese para o critério
Plano do Discovery Sprint e próximos passos
Atualização de 08/10. A reunião de 06/10 trocou a sequência abaixo por outra: primeiro os insumos que a TBC ficou de enviar, depois o protótipo v2 com a aplicação ideal e, em seguida, a fase 2 com coordenadores de projeto e GPPs. decisão de 06/10 O plano a seguir fica como registro da proposta de 05/10; a sequência vigente e os responsáveis estão na aba Conciliação · reunião 06/10.
A proposta é validar o modelo com o CSC em 20/10 e chegar a 21/10 com a especificação atualizada e o recorte do primeiro lançamento definido. hipótese — proposta de agenda
Cada dia tem uma saída concreta: entrevistas geram notas e vocabulário; o Event Storming gera a linha do tempo e os pontos críticos; a modelagem fecha custo, receita e faturamento; a validação transforma o que sobrar em decisão pendente com dono.
Próximos passos (proposta).
Enviar ao time TBC este documento e o protótipo, pedindo comentários nos pontos críticos — Bruno Sousa, até 08/10/2026
Alinhar com a diretoria da TBC a liberação dos operadores: PMO, dois coordenadores, um GPP, faturamento, controladoria, RH e TI Protheus — até 09/10/2026
Combinar com a TI da TBC a pausa de código novo durante o sprint, com o repositório atual como hipótese de partida
Reservar sala e material para o Event Storming presencial — 15/10/2026
Atualizar especificação, plano e tarefas, e registrar o recorte do primeiro lançamento — 21/10/2026
Fontes e teto de afirmação
Este documento se apoia só no repositório do projeto, lido em 05/10/2026. Nenhuma hipótese aqui foi validada com operador do CSC.
Fonte: repositório privado tbc-servicos/projetonovopsa, branch main, último commit 8232414 (28/09/2026), 79 commits e 182 arquivos.
Leitura integral: spec.md, plan.md, CLAUDE.md, registro de gates e a pasta discovery (documentos 00 a 18 e CRONOGRAMA).
Leitura dirigida: schema.prisma; serviços de apontamento, financeiro, Investimento, colaborador, contrato, parcelas e recebimentos; tasks.md (títulos e estados); frontend (estrutura, tema e telas de Financeiro e Investimentos).
Não acessado: o sistema rodando (local ou sandbox), o Protheus, as telas do Dynamics 365, a transcrição da reunião de 25/09 e os levantamentos externos citados no repositório.
Teto de afirmação. confirmado significa que está escrito no repositório como decisão do usuário, dado levantado ou comportamento do código. hipótese é inferência nossa e deve ser lida como pergunta, não como conclusão. Volumes e percentuais do Protheus são os registrados no repositório em 28/09, sobre amostra de 40 registros por tabela.
Contato: Bruno Sousa — CEO DataAgile · (62) 99941-0220 · bruno@dataagile.com.br
Contato: Bruno Sousa — CEO DataAgile · (62) 99941-0220 · bruno@dataagile.com.br