La domanda più comune che riceviamo da altri fondatori non riguarda i prezzi o il go-to-market. È tranquillo, leggermente sospettoso: come fa un team delle tue dimensioni a mantenere 150 moduli senza che tutto crolli? La risposta onesta è che non manteniamo 150 moduli. Manteniamo una piattaforma e uno strato molto sottile sopra di essa. Il trucco sta nella spietatezza riguardo a quale livello appartenga una determinata opera.
I conti che spaventano la gente.
Se immagini 150 moduli come 150 piccole applicazioni, ciascuna con il proprio modello di dati, le proprie autorizzazioni, la propria fatturazione, le proprie notifiche, allora 22 persone sono ovviamente pazze. Si tratta di sei moduli per ingegnere, ciascuno un prodotto a sé stante. Nessuna squadra sopravvive a questo. Il timore è giusto, per quell'architettura.
Ma non è questa l'architettura. Un CRM, uno strumento di fatturazione e un help desk appaiono a un utente come tre prodotti diversi. Sotto, ci sono gli stessi elementi primitivi: record, relazioni, una sequenza temporale di eventi, ruoli e permessi, denaro, documenti e un bus di notifica. Le differenze riguardano principalmente il vocabolario e il layout, non i macchinari.
Non stiamo costruendo 150 ottimi prodotti. Stiamo costruendo un piccolo numero di primitive ben costruite, configurate in 150 modi.
Il nucleo/modulo si divide.
Tutto ciò che è difficile risiede nel nucleo ed è costruito una volta: identità, autorizzazioni, livello di dati relazionali, pagamenti, archiviazione di file, ricerca, registro di controllo, sistema di notifica, motore di esportazione. Queste sono le parti veramente difficili e genuinamente condivise. Un bug risolto qui è stato corretto per tutti i 150 moduli contemporaneamente. Una funzionalità aggiunta qui, ad esempio le firme elettroniche, diventa immediatamente disponibile per ogni modulo che lo desidera.
Un modulo, quindi, volutamente sottile. È uno schema di dati, un insieme di visualizzazioni, uno o due flussi di lavoro e il vocabolario per un lavoro. "CRM" è una configurazione che dice: questi tipi di record sono lead e offerte, questa è la visualizzazione della pipeline, queste sono le fasi, ecco cosa significa una conversione. Si basa interamente sul nucleo. Un nuovo modulo è principalmente una dichiarazione, non un codice.
La dura regola: guadagna la tua unicità.
La disciplina che impedisce a tutto questo di marcire è un’unica regola, applicata in revisione: un modulo non può essere speciale a meno che non se lo sia veramente guadagnato. Ogni volta che un modulo richiede il proprio modello di autorizzazione su misura, il proprio formato di notifica una tantum, il proprio modo privato di archiviare una data, la risposta predefinita è no. Spingilo nel nucleo come capacità generale o non farlo.
Questo è fastidioso sul momento e decisivo negli anni. La maggior parte delle richieste "abbiamo bisogno di qualcosa di personalizzato qui" sono in realtà "non abbiamo pensato abbastanza al caso generale". Quando si forza il caso generale, il nucleo diventa più ricco, ogni modulo ne trae vantaggio e la superficie da mantenere rimane pressoché piatta anche quando il numero dei moduli aumenta.
A cosa abbiamo rinunciato.
Questo approccio ha un costo reale e dovremmo dargli un nome. Uno strumento di punta, costruito da un team ossessionato da un lavoro, supererà il nostro modulo equivalente su quel lavoro. La piattaforma di posta elettronica più profonda ha un'automazione che noi non abbiamo. Lo strumento di progetto più profondo ha punti di vista che noi non abbiamo. Non stiamo fingendo il contrario.
Ciò per cui scambiamo questa profondità è la coerenza: moduli che condividono un modello di dati, un accesso, una fattura, un'esportazione e un livello di notifica. Per un team di 5-50 persone, tale coerenza vale più dell’ultimo 20% di profondità in ogni singola categoria. Per una squadra la cui intera attività rientra in quella categoria, non lo è. Sappiamo esattamente per chi siamo e l'architettura è la ragione per cui possiamo servirli con 22 persone.