O playbook de quatro semanas e o nosso próprio placar
O método para subir uma vertical sobre infraestrutura compartilhada em quatro semanas, seguido do registro que diz quantas das nossas de fato conformam.
Por que quatro semanas são possíveis
Quase nada numa vertical nova é novo.
Todas precisam saber quem é um usuário, o que é uma empresa, como uma pessoa pertence a uma empresa, como uma chave de API é escopada e como uma permissão é sobrescrita para um tenant. São cinco entidades, e são idênticas quer o produto alugue escavadeiras quer marque fisioterapia.
Acima delas ficam as capacidades: dezenove pacotes sob @inite/*, cobrindo caixa de entrada, cobrança, incidentes, notificações, i18n, segurança, vitrine e conhecimento entre outros, mais três serviços horizontais para auth, billing e brain. Nada disso é reescrito.
O que sobra é a parte que faz o produto ser o produto: os objetos de domínio e os fluxos sobre eles. Para uma locadora, o ativo, a reserva e o despacho. Para uma imobiliária, o imóvel, o anúncio e o negócio. Esse é o único código genuinamente novo, e quatro semanas é o que ele leva quando tudo debaixo dele já funciona.
A ordem que importa
| Semana | O que entra | Por que aqui |
|---|---|---|
| 1 | auth, tenant | Tudo depois depende de quem pergunta, por quem |
| 1 | api-kit | Erros e limites uniformes antes de haver endpoints a uniformizar |
| 2 | O modelo de domínio | A única coisa genuinamente nova da obra |
| 2-3 | A interação principal: caixa de entrada ou vitrine | O que o produto de fato é |
| 3 | assistant, notifications | Úteis quando já há algo a assistir |
| 4 | billing, security, i18n | Preço por último porque preço é o que mais muda |
Identidade primeiro é a regra de consequência mais afiada. Enfiar multitenancy num produto que assumia um único cliente é o retrabalho mais caro deste ramo, e é o erro que transforma um clone de quatro semanas num de três meses.
Cobrança fica por último pelo motivo oposto. Preço muda mais que identidade, e construí-la na semana um significa construí-la duas vezes.
O placar, sem maquiagem
Um post de playbook normalmente termina com uma contagem de sucessos. No lugar dela, o registro de verdade.
| Status | Qtd | O que significa |
|---|---|---|
| production | 1 | Atendendo usuários |
| pilot | 2 | Calibrando ativamente a especificação |
| migration_pending | 4 | Repositório existe, pretende conformar, lacuna no modelo |
| drift | 4 | Consome os pacotes compartilhados, sem manifesto |
| non_conforming | 2 | Repositório existe, sem pacotes, sem manifesto |
| candidate | 3 | Nomeada, não iniciada |
| legacy | 2 | Substituída |
| conforming | 0 | Declara versão e cumpre o contrato |
Dezoito entradas. Uma em produção. E o status que a especificação define como meta não é de ninguém.
Essa última linha merece um minuto. conforming significa que a vertical declara sua versão de ecossistema e cumpre o contrato por inteiro. Nada cumpre ainda. Metade do registro está em drift ou migration_pending, ou seja: usando o runtime compartilhado na prática, ainda sem assumir isso por escrito.
Por que publicamos assim
Porque uma contagem de verticais é um número de marketing e um registro de status é um número de engenharia, e só o segundo pode estar errado de um jeito que alguém perceba.
"Dezesseis verticais num runtime compartilhado" é uma frase que sobrevive a qualquer quantidade de desvio embaixo dela. "Zero conformes, quatro em desvio" é uma frase que cria trabalho. O registro é mantido à mão e atualizado a cada release da especificação justamente para não virar em silêncio um número do primeiro tipo, e é pelo mesmo raciocínio que a separação entre constituição e runtime mantém o repositório da especificação livre de código executável: uma especificação que entrega runtime deixa de ser verificável contra qualquer coisa.
O que quatro semanas compram e o que não
Compram a remoção da parte repetível. Um produto multitenant funcionando sobre infraestrutura que outras verticais já depuraram, com identidade, cobrança e mensageria herdadas em vez de descobertas.
Não compram clientes, conhecimento de domínio, preço correto, nem o ponto em que aquilo se paga. Nosso registro é a prova: o trabalho de infraestrutura está espalhado por dezoito entradas, e exatamente uma está em produção.
Uma vertical com modelo de domínio genuinamente inédito também vai levar mais, e nenhum encanamento herdado muda isso. As quatro semanas são uma afirmação sobre o piso, não sobre o teto. O case de locação é onde o número se sustentou, e o de imobiliário mostra o que muda quando o modelo de domínio se afasta mais do template.
Se você for fazer isso sozinho
A parte transferível aqui não são os nossos pacotes. É a disciplina de decidir, antes da primeira vertical, qual camada tem permissão de ter opinião.
Escreva as entidades que todo produto da sua família vai compartilhar e não deixe nenhum produto isolado mudá-las. Ponha o runtime compartilhado atrás de uma versão. Mantenha um registro de quais produtos de fato conformam a ele, e faça os status honestos serem desconfortáveis de olhar, porque um registro que ninguém torce o nariz é um registro que ninguém atualiza.
01Se o método funciona, por que só uma vertical está em produção?+
Porque construir uma vertical e conformar a uma especificação são trabalhos diferentes, e só o primeiro é urgente para alguém. Uma vertical chega à produção quando atende usuários bem o suficiente para cobrar por isso; ela chega a conforming quando declara uma versão de ecossistema e cumpre o contrato por inteiro, trabalho que se paga depois e não antes. O registro é deliberadamente pouco lisonjeiro. Quatro das dezoito estão em drift, ou seja, consomem os pacotes compartilhados e nunca publicaram um manifesto, e outras quatro em migration_pending, ou seja, o repositório existe e a intenção de conformar existe, mas há uma lacuna no modelo de dados. Essa distribuição é a cara de um programa guiado por especificação no meio do caminho, e publicá-la como um registro de status em vez de uma contagem de marketing é a única forma de o número continuar útil internamente.
02O que é compartilhado e o que precisa ser escrito toda vez?+
Compartilhado: as cinco entidades do Ring 1 que definem quem é um usuário, o que é uma empresa e como os dois se relacionam, mais os pacotes de capacidade de caixa de entrada, cobrança, incidentes, notificações, i18n, segurança, vitrine e base de conhecimento, mais os três serviços horizontais de auth, billing e brain. Nada disso é reescrito. Escrito por vertical: os objetos de domínio que fazem o produto ser o que ele é, e os fluxos sobre eles. Para uma locadora são o ativo, a reserva e o despacho; para uma imobiliária são o imóvel, o anúncio e o negócio. Essa proporção é o que torna quatro semanas possíveis, e é também o limite honesto da afirmação, porque uma vertical com modelo de domínio genuinamente inédito vai levar mais tempo por mais infraestrutura que herde.
03Em que ordem adotar as capacidades?+
Identidade primeiro, sempre: auth e tenant, porque toda decisão posterior depende de saber quem está perguntando e em nome de quem, e enfiar multitenancy num produto que assumia um único cliente é o retrabalho mais caro deste ramo. Depois o wrapper de requisições, para que formato de erro, logging e limites fiquem uniformes antes de haver muitos endpoints para uniformizar. Depois a capacidade que carrega a interação principal do produto, normalmente caixa de entrada para qualquer coisa com conversas ou vitrine para qualquer coisa com catálogo. Cobrança entra mais tarde do que os fundadores esperam, porque preço muda mais do que identidade e construí-la cedo significa construí-la duas vezes. Segurança e i18n vêm por último apenas na sequência, não na importância, e ambas são muito mais baratas sobre um modelo de tenancy limpo do que aparafusadas num bagunçado.
04Uma vertical de quatro semanas significa um negócio de quatro semanas?+
Não, e confundir os dois é o erro mais comum com um número desses. Quatro semanas é o tempo de engenharia para subir um produto multitenant funcionando sobre infraestrutura que já existe e já foi depurada pelas verticais anteriores. Não é o tempo de achar clientes, aprender o domínio, acertar o preço ou chegar ao ponto em que aquilo se paga. Nosso próprio registro é a prova: o trabalho de infraestrutura está em boa parte espalhado por dezoito entradas, e exatamente uma está em produção. O que as quatro semanas removem é a parte genuinamente repetível, o que libera o calendário para a parte que não é. Quem vende a segunda metade como resultado de quatro semanas está vendendo outra coisa.
Como Uma Única Equipe Entrega 18 Produtos SaaS Diferentes
inite.rent: como reconstruímos um CRM de 318 000 linhas em 4 semanas
