Um núcleo, dezoito entradas no registro e uma em produção
O que os nossos produtos setoriais compartilham, o que precisa ser escrito de novo toda vez e por que publicamos um registro de status, e não um contador.
O que está embaixo de todos os produtos ao mesmo tempo
Em qualquer sistema com funcionários e clientes repete-se a mesma coisa. Alguém entra com a própria conta. Tem um papel. O papel permite umas coisas e proíbe outras. Avisos vão para alguém, uma fatura para outro, a correspondência mora num lugar só e é encontrada por busca, e um registro lembra quem mudou o quê.
São cinco entidades obrigatórias: usuário, empresa, o papel entre os dois, a chave de acesso e a exceção de permissões para uma empresa específica, mais dezenove pacotes de capacidades e três serviços: acesso, faturas e assistente. Escrito uma vez, sem ser reescrito para nenhum setor.
A quinta entidade não saiu de um plano e sim de um caso. Na locação, o responsável por uma filial precisava de acesso aos relatórios destinados aos coproprietários da frota, e o papel comum de responsável não concede isso. A tabela de papéis não sabia expressá-lo. O motivo era setorial, a solução saiu geral, e agora todos a herdam.
Quanto de fato se transfere
Aqui costuma-se citar uma fatia grande. Nós medimos duas vezes, e os dois números saíram incômodos.
O CRM de locação que passamos para a base comum são 318 757 linhas e quatro anos de regras acumuladas. De 1872 linhas de esquema, 1650 eram do setor, ou seja 88%. O andaime comum eram 220 linhas.
A segunda medição é mais dura. Fizemos uma plataforma de locação, depois uma de imóveis. Setores vizinhos, os dois sobre um objeto entregue a alguém por um tempo ou para sempre. De 113 conceitos de negócio dos dois produtos, sete se mostraram comuns. Cerca de 6%, e esse número merece leitura à parte.
Daí sai uma consequência útil bem além da nossa cozinha. "Isso nós já temos, é só configurar" é uma frase sobre o andaime, não sobre o seu negócio. De onde vêm as quatro semanas percorre o mesmo assunto do lado de quem escolhe fornecedor.
Com o que isso se sustenta
A mudança da locação levou quatro semanas, e os operadores trabalhavam no aplicativo reconstruído desde a terceira, conduzindo reservas reais por ele.
O gargalo não foram os prazos de desenvolvimento. Três vezes aconteceu de os dados reais da locação contradizerem a especificação da base, e a cada vez reescrevemos a especificação e não os dados. Uma base que não aguenta o contato com um produto que funciona há quatro anos ainda não é uma base.
Um resultado colateral pesou mais do que os planejados. Regras de negócio como "não há entrega de veículo enquanto o contrato não estiver assinado e a caução recebida" foram escritas direto na camada que os agentes de IA externos chamam. Agora o agente não consegue contornar a regra nem sem saber que ela existe: a camada devolve uma recusa apontando a condição violada. Cada produto seguinte recebe isso de graça.
O placar, sem enfeite
| Status | Quantidade |
|---|---|
| Em produção | 1 |
| Piloto | 2 |
| Aguardando migração | 4 |
| Desviados da especificação | 4 |
| Sem passar para a base | 2 |
| Nomeados, não iniciados | 3 |
| Substituídos por outro | 2 |
| Conformidade plena com a especificação | 0 |
Dezoito entradas. Uma em produção. E o status que a especificação fixa como meta ainda não foi alcançado por nenhuma.
O contador de produtos é um número de marketing, o registro de status é de engenharia, e só o primeiro consegue errar sem que ninguém perceba. "Dezoito produtos sobre uma base comum" sobrevive a qualquer desvio embaixo dela. "Um em produção, nenhum em conformidade plena" gera trabalho.
A quem construir uma família de produtos própria, daqui não se transfere o nosso código e sim o hábito: decidir antes do primeiro produto qual camada tem permissão de ter opinião, pôr a base comum atrás de uma versão e manter o registro honesto o bastante para ser desconfortável de olhar. Um registro para o qual ninguém torce o nariz é um registro que ninguém atualiza.
Como isso aparece do lado do cliente e não de quem constrói está em o que automatizar primeiro.
01O que exatamente é comum e o que é escrito de novo toda vez?+
Comum é aquilo que funciona igual em qualquer sistema com funcionários e clientes: quem entrou com a própria conta, que papel tem, o que esse papel permite e proíbe, para quem vão os avisos, para quem vai a fatura, onde mora a correspondência e quem mudou o quê. Entram aqui também a criptografia de dados pessoais e as traduções. Nada disso depende de você alugar escavadeiras ou vender apartamentos, então é escrito uma vez. De novo se escreve a matéria própria: os objetos do setor e as regras de passagem entre etapas. Uma locadora tem uma unidade de equipamento, uma reserva e uma entrega. Uma imobiliária tem um imóvel, um anúncio e um negócio. As palavras se parecem, as regras de dentro não, e o tempo é gasto pelas regras.
02Qual o tamanho da parte que precisa ser escrita do zero?+
Maior do que quase todo mundo espera, nós inclusive no começo. Dois números, ambos medidos. O primeiro: no CRM de locação que passamos para a base comum, 1650 de 1872 linhas de esquema eram do setor, ou seja 88%, e apenas 220 linhas eram o andaime que a base fornece. O segundo é mais duro. Ao construir um segundo produto num setor vizinho, dos 113 conceitos de negócio dos dois produtos 7 foram compartilhados. Cerca de 6%. Daí sai uma consequência simples para quem escolhe fornecedor: a frase isso nós já temos, é só configurar descreve o andaime, não o seu negócio. Esse segundo caso contamos à parte, porque o número é incômodo e merece detalhe.
03Para que construir uma base comum se tão pouco se transfere?+
Porque a economia não vem de onde a procuram. Antes que um produto novo possa cuidar do próprio setor, ele precisa de acessos, empresas, papéis e permissões, faturas ligadas a um provedor de pagamento real, entrada de mensagens de clientes, avisos, traduções, um registro de alterações e criptografia de dados pessoais. Na primeira vez essa lista leva meses, é idêntica para qualquer setor, e qualquer erro silencioso nela aparece não numa demonstração mas numa auditoria de segurança. Construída uma vez, ela permite que o produto seguinte comece onde o negócio de fato começa. As regras setoriais seriam diferentes de qualquer jeito, e o ganho nunca esteve ali.
04Por que vocês publicam um registro de status e não um número de produtos?+
Porque um contador de produtos é um número de marketing e um registro de status é de engenharia, e só o primeiro consegue errar sem que ninguém perceba. A frase dezoito produtos sobre uma base comum sobrevive a qualquer desvio embaixo dela: continua verdadeira enquanto qualquer coisa estiver funcionando. A linha um em produção, dois em piloto, nenhum em conformidade plena gera trabalho, porque cada status é algo que alguém precisa mover. O registro é mantido à mão e atualizado a cada publicação da especificação justamente para não escorregar em silêncio para a primeira formulação. Pelo mesmo motivo o repositório da especificação é mantido livre de código executável: uma especificação que entrega um runtime deixa de ser verificável contra qualquer coisa.
