Ângulo

Uma exigência técnica de uma grande conta — o banco de dados dentro da assinatura de nuvem dela, o gateway de e-mail dela, o fornecedor de modelo de linguagem dela — se negocia pelo motivo, nunca pela viabilidade. O motivo diz quanto basta conceder; responder ao pedido do jeito que ele foi formulado equivale a conceder o máximo sem saber por quê, e esse máximo é pago depois em divergência do produto, em linhas que nenhuma planilha de custos mostra.

Síntese

Um grande grupo está avaliando o seu software de folha de pagamento. O negócio avança. Aí cai uma frase: "o banco de dados tem que ficar na nossa assinatura Azure".

A discussão que vem depois acontece quase sempre no mesmo lugar: dá para fazer? Tecnicamente, sim. Quanto tempo? Dois meses. Você orça, se compromete e segue em frente.

Essa discussão pulou a única pergunta que coloca você no comando: por que esse pedido. Uma auditoria ISO a ser cumprida, uma política de segurança que proíbe dados fora do tenant da empresa, um time de cibersegurança que quer os logs na própria ferramenta de monitoramento. Nada disso é um julgamento sobre a sua competência — ninguém acha que o cliente vai hospedar melhor do que você. É controle: poder responder pelos próprios dados diante do auditor.

O motivo importa porque é ele que define a dosagem. Se a necessidade é provar que os dados não saem da União Europeia, uma região de hospedagem e um compromisso por escrito já respondem. Se é segurar a chave de criptografia, uma chave gerenciada pelo cliente responde. Nenhuma dessas duas necessidades exige o banco dentro da assinatura dele. Responder ao pedido do jeito que ele foi formulado é conceder o máximo por um motivo que você não identificou.

Porque o que você concede tem preço, e ele é pago em linhas que ninguém acompanha. O banco vive na casa do cliente: cada entrada em produção que mexe na estrutura de dados vira um procedimento para enviar, uma validação para esperar, uma janela de manutenção para reservar. O primeiro cliente faz isso na terça, o terceiro adia para o mês seguinte, e três meses depois as suas correções são testadas contra quatro estados de banco diferentes. O que se perde aí é exatamente o que dava sentido ao modelo: um produto único que você faz avançar para todo mundo ao mesmo tempo. Já a linha de infraestrutura caiu — e é justamente essa que o vendedor olha quando propõe um desconto.

Há um caso em que a conta se inverte: um bloco que não diferencia nada pode, sozinho, impedir a venda. O SSO não distingue nenhum software de folha de pagamento dos concorrentes, e a ausência dele basta para eliminar você. Então você constrói, não pelo que ele traz, mas pelo que a ausência dele custa. A pergunta nunca é "isso cria valor" — é "isso abre o quê, e em que linha isso é pago".

Daí a conclusão, que não é técnica. Essas exigências não são casos particulares para tratar um a um: são a cultura de governança de um segmento de mercado. Decidir vender ali é aceitar essa restrição como um dado do mercado, orçá-la de uma vez por todas e negociar cada pedido pelo motivo, e não pela viabilidade.

Tensões / contradições

Duas notas não dizem a mesma coisa sobre o que dá para ceder. Uma sustenta que substituir um fornecedor sem mudar o valor torna o serviço substituível — logo, que é preciso resistir; a outra, que a substituição continua cara assim que o bloco carrega o estado durável — logo, que o risco é menor do que parece. A fronteira entre as duas não está traçada.

Outra tensão em aberto: a tese pede para negociar pelo motivo, mas nada garante que o interlocutor o conheça. Uma exigência repassada por um comprador pode ter perdido a razão de ser no caminho.

Questões

• Como fazer o motivo aparecer quando o interlocutor só está repassando uma regra interna?
• Até quantos estados de banco diferentes um time aguenta antes de a qualificação virar inviável?