Mostrar a engenharia sem entregar o método.

Diga“JavaScript sobre Node 18, em módulos ES, sem etapa de compilação e sem servidor. São dezoito pacotes independentes num monorepo, cada etapa do processo testável sozinha. A interface é por comando dentro do editor, em português.”

Por quê. “Sem servidor e sem compilação” é a informação que mais tranquiliza: não há infraestrutura nossa no meio do caminho dos dados deles. Dizer o número de pacotes mostra que é engenharia, não um script.

Diga“PDF, .docx, .doc e reconhecimento de texto em imagem, tudo com biblioteca em JavaScript puro ou WebAssembly. A decisão foi deliberada: nunca exigir instalar programa nativo e não depender do sistema operacional da máquina. Roda local.”

Por quê. Em empresa grande, qualquer coisa que exija instalação em máquina corporativa é uma barreira real. Essa resposta elimina a objeção antes dela aparecer.

Diga“É. A conferência lê a árvore sintática do código, com um analisador. A regra interna é explícita: nunca procurar texto no fonte. Por isso não dá para passar renomeando variável ou escondendo num comentário.”

Por quê. Essa é a resposta que mais impressiona. Qualquer desenvolvedor já viu validação feita por busca de texto quebrar. Dizer que a regra é proibir isso mostra maturidade de engenharia.

Diga“A estrutura sim, e por um motivo concreto: a lógica é função pura e não lê o relógio — até a data entra por parâmetro, e os contadores que numeram os requisitos também. Mesma entrada, saída idêntica. A redação do texto pode variar, e é justamente a parte que o PO revisa.”

Por quê. Veja a seção de determinismo. A força está em admitir o lado que varia. Se você dissesse que é tudo idêntico, ele saberia que não é.

Diga“O relatório é validado contra um esquema versionado. E a regra está no próprio esquema: critério sem teste vinculado só pode sair como não verificado — não existe forma de representar isso como aprovado. É impedido pelo formato, não pela disciplina de quem usa.”

Por quê. A diferença entre “a gente tem cuidado” e “o formato não permite” é enorme para quem é técnico. Use exatamente essa construção.

Diga“Cinco: aprovado, reprovado, não verificado, bloqueado e instável. Bloqueado é quando o teste não conseguiu rodar, por massa de dados ou dependência faltando. Instável é quando oscilou — e a política de nova tentativa é uma só, controlada. Não se repete até dar verde.”

Por quê. A existência de bloqueado e instável é a prova de honestidade do sistema. Quem já brigou com teste intermitente sabe que a tentação é mascarar.

Diga“Isso é registrado como desvio de contrato, classificado em quebra, não-quebra ou indeterminado. Vai junto com o veredito, por critério.”

Por quê. Mostra que a rastreabilidade não para no teste: ela compara o que foi construído com o que foi contratado. É argumento direto de aceite.

Diga“SQLite em WebAssembly quando o projeto é relacional. A decisão importa porque o modelo de dados que sai da especificação vira um DDL de verdade, não um despejo de chave-valor. E todo acesso passa por uma única porta, então trocar para o banco real depois toca um arquivo só.”

Por quê. Responde a desconfiança legítima de que protótipo gera modelo de dados de brinquedo, inútil para quem vai construir.

Diga“Não há stack fixa. A arquitetura do projeto define, e o gerador pergunta ou deriva. O que é invariante é o contrato de legibilidade, não o framework.”

Por quê. Se a Transpetro já tem padrão tecnológico definido, essa é exatamente a resposta que ele quer. Não force nenhuma tecnologia.

Diga“É uma fusão de três vias, como no controle de versão, só que as linhas são requisitos: a última versão publicada, a edição manual do PO e o catálogo regerado da fonte nova. Se só o PO mudou, preserva. Se só a fonte mudou, atualiza. Se os dois mudaram, vira pergunta — não sobrescreve ninguém. E se o PO apagou mas a fonte ainda sustenta, também vira pergunta: nada some em silêncio.”

Por quê. É a resposta mais sofisticada que você tem, e cobre o maior medo dele: documentação que descola da realidade. Mas seja honesta: neste caso do TABG essa etapa ainda não rodou — é uma primeira geração.

Diga“Não. As fontes são comparadas por resumo criptográfico. O que não mudou é carregado da versão anterior e não é reprocessado. E dá para regerar só a funcionalidade afetada, porque cada etapa é um transformador independente.”

Por quê. Responde custo e estabilidade de uma vez. Reprocessar tudo significaria resultado diferente a cada rodada — exatamente o que ele teme.

Diga“A onda de trabalho só vira versão publicada quando todas as perguntas em aberto foram respondidas. Conflito pendente trava a publicação.”

Por quê. É uma trava de processo, e travas são o que um gestor de contrato valoriza. Curta e definitiva.

Diga“O método não depende de um modelo específico. A parte que precisa ser estável está fora do modelo, em código. Trocar de modelo não muda o formato do que o time de desenvolvimento recebe.”

Por quê. Evita comparação de modelos, que é terreno dele e muda a cada trimestre, e reforça o ponto que interessa: a estabilidade não vem do modelo.

Diga“Não. O modelo escreve o texto da regra. O número, o vínculo com a fonte, a conta de cobertura e o veredito do teste são feitos por código comum, que dá o mesmo resultado sempre.”

Por quê. Separar o que varia do que não varia é exatamente o que ele quer ouvir. Ele já desconfia de texto gerado; o que tranquiliza é saber que a estrutura não depende do modelo.

Diga“Requisito sem evidência não entra no catálogo. E a ferramenta é proibida de completar prazo, volume ou nome que o documento não traz.”

Por quê. É regra, não boa intenção. Complemente com o caso: o manual não diz o prazo da resposta ao pedido, e isso ficou como ponto em aberto em vez de virar número inventado.

Diga“A ferramenta não resolve contradição sozinha. Registra e leva para o PO decidir. E a gente combina antes qual fonte tem prioridade se houver conflito.”

Por quê. Mostra que a decisão de negócio continua com gente. No caso do TABG, a fonte prioritária combinada foi o manual de 2022.

Diga“Os formatos de saída são contratos versionados. Quem consome fixa a versão principal, e mudança incompatível obriga a subir a versão. Não há quebra em silêncio.”

Por quê. É vocabulário de integração que ele reconhece. Mostra que a saída foi pensada para alimentar outro sistema, não só para ser lida por gente.

Diga“São lidos na máquina de quem conduz. A extração é local e não envia documento para serviço externo — inclusive o reconhecimento de texto em imagem, que roda em WebAssembly na própria máquina.”

Por quê. Preocupação real com manual operacional de terminal portuário. Resposta curta e firme, sem rodeio.

Diga“Não. Ela lê. Abrir issue, atualizar wiki ou sincronizar exige confirmação explícita, uma por uma. E antes de prometer gravar, ela testa de verdade se tem permissão de escrita — se não tem, para e avisa, em vez de trabalhar e falhar no fim. Também não reescreve histórico à força.”

Por quê. O medo real de quem é técnico é agente autônomo bagunçando repositório. O detalhe do teste de permissão prévio é o que torna a resposta crível.

Diga“Token nunca é digitado na conversa. Quando a nossa infraestrutura e o ambiente do cliente são contas separadas, cada operação usa a credencial do seu lado. E senha de demonstração nunca é guardada em texto aberto, só o resumo criptográfico com sal.”

Por quê. Se ele for de segurança, essa resposta vale ouro. Se puxar mais fundo que isso, leve para o time técnico.

Diga“No Veroptima, as análises rodam sem reter código-fonte. Os arquivos permanecem nos repositórios de origem de vocês.”

Por quê. Pergunta certa de vir numa estatal. É afirmação do deck — use com segurança e pare por aí, sem detalhar como.

Diga“A lógica de especificar antes do código é a mesma que o mercado adotou em 2025. A diferença é o ponto de partida: aquelas ferramentas começam na intenção escrita pelo engenheiro, dentro do repositório. A gente começa na fonte de vocês — o manual — com um PO responsável, e entrega um protótipo navegável para corrigir antes do código. E a reconciliação entre edição manual e fonte nova é um problema que elas deixam em aberto.”

Por quê. Reconhecer o cenário vale mais que fingir ineditismo. Ele vai respeitar que a YouX sabe onde está no mapa — e o fecho da reconciliação é o diferencial técnico real.

Diga“A regra desce até tarefa, com critério de aceite junto. Por exemplo: registrar o pedido de acesso com terminal, navio e produto, sem inventar prazo nem volume, porque o manual não define. A construção vem depois da regra aprovada.”

Por quê. Exemplo concreto vale mais que explicação, e esse item existe escrito nos materiais — terreno firme.

Diga“Sai. E a prontidão não é alguém marcando uma caixinha: é derivada. Um requisito só aparece como pronto se tiver enunciado, origem rastreável, pelo menos um critério que o verifica e nenhuma pergunta em aberto tocando nele.”

Por quê. “Derivada, não marcada à mão” é a construção que desmonta a desconfiança de checklist decorativo.

Diga“Servem — foi exatamente o que fizemos aqui. E a base construída numa ordem de serviço é reaproveitada nas seguintes, em vez de recomeçar do zero.”

Por quê. Argumento de custo que o deck marca. Vem com asterisco: é proposta a validar no piloto, não resultado comprovado.

Diga“Não. Quem desenvolve continua responsável por entregar código testado. O Veroptima faz a verificação independente na homologação e uma pré-validação de segurança antes da esteira.”

Por quê. Reforça a segregação de funções, que é o coração do modelo de contratação. Não é mais uma camada de trabalho: é a camada que falta para o aceite.

Diga“Ainda não. Está em desenvolvimento e hoje é uso interno, integrado ao nosso GitLab. Por isso a proposta é um piloto.”

Por quê. O próprio deck manda ser transparente. Se você sugerir maturidade que não existe e ele pedir referência de cliente, a reunião perde o chão.

Diga“A entrega é a especificação das regras, com um PO nosso alocado, e o relatório de evidências no aceite. A ferramenta é o nosso método de trabalho. E mais do que a ferramenta, o que a gente traz é ajudar a estruturar a forma de contratar: o edital, a medição e o aceite.”

Por quê. Responda sem hesitar e sem pedir desculpa — e emende no diferencial de contratação, que vale mais que a licença.

Diga“Ponto de Função, pelo Roteiro de Métricas do SISP 2.0. A ordem de serviço é aberta com PF estimado e paga pelo realizado. Cada fase recebe o percentual previsto sobre o PF apurado.”

Por quê. A Transpetro já levantou essa pergunta. Fonte na ponta da língua: SISP 2.0, Tabela 7, item 6.1.2.1. Antes da reunião, confirme qual versão do slide de remuneração é a final — há mais de uma no deck.

Diga“Porque escopo fechado obriga a adivinhar antes de entender. Com PF, cada fase recebe seu percentual do apurado — auditável e recontável.”

Por quê. O valor fixo por escopo foi descartado na validação interna. A recusa é posição, não evasiva.

Diga“É a métrica que a Petrobras já reconhece nas contratações de TI. Não estamos propondo padrão novo — estamos amarrando o aceite ao padrão que já existe.”

Por quê. Aqui o tom muda de eficiência para conformidade, que vale mais com diretoria.

Diga“No modelo que trouxemos, não. Quem planeja não executa, quem executa não mede. A gente atua como terceira parte na elicitação e na verificação.”

Por quê. Protege a proposta inteira: se a YouX especifica, desenvolve e testa, a segregação cai — e com ela o argumento do fiscal.

Diga“A YouX opera contratos por Ponto de Função no Serpro e na Dataprev, com contagem e aceite formais. Mas quero ser clara: a Vyva Spec e o Veroptima ainda não atuam nesses contratos. O que levamos para lá é a governança e a medição.”

Por quê. Essa distinção é obrigatória e está escrita no próprio deck. Misturar é o erro mais caro possível. E dá para oferecer conversa com o time do contrato do Serpro.

Diga“Nos projetos da YouX, o levantamento caiu de quinze para cinco dias. Não vou prometer o mesmo percentual aqui — a proposta é medir no piloto, com linha de base definida junto com vocês.”

Por quê. O percentual é da YouX, não do TABG, e vem sempre com a ressalva colada.

Diga“Ninguém ainda. É uma leitura nossa do manual, feita justamente para vocês corrigirem. Não há aceite registrado, e o material foi montado assumindo isso.”

Por quê. Se você sugerir validação que não houve e ele checar, perde tudo. A honestidade aqui é o convite para a próxima conversa.

Diga“É uma hipótese nossa. O manual não nomeia esse papel, e a gente registrou como ponto em aberto. Qual é o nome certo?”

Por quê. É a melhor coisa que pode acontecer: ele corrigindo. Isso prova que o método funciona, ao vivo.

Diga“São dados de exemplo, para a tela poder ser percorrida. Os nove berços saíram do manual; os horários e a sobreposição são fictícios.”

Por quê. Antecipe antes de ele perguntar, se o quadro aparecer na tela. Vale o mesmo para o Navio Exemplo.

Diga“Não formalmente. A gente navegou o protótipo e exercitou o fluxo, mas os 22 critérios continuam marcados como não verificados no relatório. Navegação não substitui teste.”

Por quê. A resposta que mais impressiona alguém técnico: a ferramenta não pinta de verde o que não foi provado. E é o gancho perfeito para falar do Veroptima.

Diga“Porque a fonte é um manual real de vocês, a jornada cabe em quatro passos e os buracos ficam visíveis. Clima, calado, amarração e mapa ficaram de fora de propósito.”

Por quê. Mostra que o recorte foi decisão humana e consciente, não o que a ferramenta conseguiu digerir.

Diga“Hoje não. No protótipo, a confirmação de estoque é um registro, não uma consulta a sistema. O manual cita a interação com a logística; a integração em si seria decisão de projeto.”

Por quê. Separa o que foi lido do manual do que seria construção. Não prometa integração.

Diga“O vídeo é um timelapse bem acelerado, e começa depois de uma preparação prévia: leitura do manual, organização do contexto e decisão do que fazia sentido virar protótipo. Essa parte humana não aparece na gravação.”

Por quê. Se o vídeo der impressão de mágica em minutos, ele desconfia de tudo. Declarar a preparação prévia é o que torna o resultado crível.