Najczęstsze pytanie, jakie otrzymujemy od innych założycieli, nie dotyczy cen ani wejścia na rynek. To cichy, nieco podejrzany: w jaki sposób zespół twojej wielkości może utrzymać 150 modułów bez zawalenia się całości? Szczera odpowiedź jest taka, że nie utrzymujemy 150 modułów. Utrzymujemy jedną platformę i bardzo cienką warstwę na niej. Sztuka polega na bezwzględności, do której warstwy należy dane dzieło.
Matematyka, która przeraża ludzi.
Jeśli wyobrazisz sobie 150 modułów jako 150 małych aplikacji — każda z własnym modelem danych, własnymi uprawnieniami, własnymi fakturami i własnymi powiadomieniami — to 22 osoby są oczywiście szalone. To sześć modułów na inżyniera, a każdy stanowi produkt sam w sobie. Żadna drużyna tego nie przeżyje. Obawy dotyczące tej architektury są słuszne.
Ale to nie ta architektura. CRM, narzędzie do fakturowania i dział pomocy technicznej dla użytkownika wyglądają jak trzy różne produkty. Pod spodem znajduje się ta sama garść prymitywów: zapisy, relacje, harmonogram wydarzeń, role i uprawnienia, pieniądze, dokumenty i szyna powiadomień. Różnice dotyczą głównie słownictwa i układu, a nie maszyn.
Nie tworzymy 150 świetnych produktów. Budujemy niewielką liczbę dobrze zbudowanych prymitywów, skonfigurowanych na 150 sposobów.
Podział rdzenia/modułu.
Wszystko, co trudne, żyje w rdzeniu i jest budowane raz: tożsamość, uprawnienia, relacyjna warstwa danych, płatności, przechowywanie plików, wyszukiwanie, dziennik audytu, system powiadomień, silnik eksportu. To są części, które są naprawdę trudne i naprawdę wspólne. Naprawiony tutaj błąd został naprawiony dla wszystkich 150 modułów jednocześnie. Dodana tutaj funkcja — powiedzmy podpisy elektroniczne — staje się natychmiast dostępna dla każdego modułu, który tego potrzebuje.
Moduł jest zatem celowo cienki. Jest to schemat danych, zestaw widoków, przepływ pracy lub dwa i słownictwo dotyczące jednego zadania. „CRM” to konfiguracja, która mówi: te typy rekordów to potencjalni klienci i transakcje, to jest widok rurociągu, to są etapy, oto, co oznacza konwersja. Jeździ całkowicie na rdzeniu. Nowy moduł to głównie deklaracja, a nie kod.
Twarda zasada: zarabiaj na swojej wyjątkowości.
Dyscyplina, która chroni to przed rozkładem, to pojedyncza zasada, egzekwowana w trakcie przeglądu: moduł nie może być wyjątkowy, chyba że naprawdę na to zasłużył. Za każdym razem, gdy moduł potrzebuje własnego, dostosowanego do indywidualnych potrzeb modelu uprawnień, własnego, jednorazowego formatu powiadomień, własnego, prywatnego sposobu przechowywania daty – domyślna odpowiedź brzmi „nie”. Wprowadź to do rdzenia jako ogólną zdolność lub nie rób tego.
Jest to irytujące chwilowo i decydujące na przestrzeni lat. Większość próśb typu „potrzebujemy tutaj czegoś niestandardowego” tak naprawdę dotyczy „nie przemyśleliśmy wystarczająco szczegółowo ogólnego przypadku”. Kiedy wymuszasz przypadek ogólny, rdzeń staje się bogatszy, każdy moduł na tym zyskuje, a powierzchnia, którą musisz utrzymać, pozostaje mniej więcej płaska, nawet gdy liczba modułów rośnie.
Z czego zrezygnowaliśmy.
Takie podejście ma realny koszt i powinniśmy to nazwać. Najlepsze w swojej klasie narzędzie punktowe, zbudowane przez zespół mający obsesję na punkcie jednego zadania, będzie oferować więcej niż nasz odpowiednik w tym jednym zadaniu. Najgłębsza platforma e-mailowa ma automatyzację, której my nie mamy. Najgłębsze narzędzie projektowe ma widoki, których my nie mamy. Nie udajemy, że jest inaczej.
To, na co sprzedajemy tę głębokość, to spójność — moduły, które współdzielą jeden model danych, jeden login, jeden rachunek, jeden eksport i jedną warstwę powiadomień. Dla zespołu składającego się z 5–50 osób ta spójność jest warta więcej niż ostatnie 20% głębokości w dowolnej kategorii. W przypadku zespołu, którego cała działalność dotyczy tej jednej kategorii, tak nie jest. Wiemy dokładnie dla kogo jesteśmy, a architektura sprawia, że możemy ich obsługiwać w 22 osoby.