Diğer kuruculardan aldığımız en yaygın soru fiyatlandırma veya pazara açılmayla ilgili değil. Sessiz, biraz şüpheli bir durum: Sizin büyüklüğünüzdeki bir ekip, her şey çökmeden 150 modülü nasıl koruyabilir? Dürüst cevap şu ki, 150 modüle sahip değiliz. Bir platform ve onun üzerinde çok ince bir katman tutuyoruz. İşin püf noktası, belirli bir eserin hangi katmana ait olduğu konusunda acımasız olmaktır.
İnsanları korkutan matematik.
150 modülü 150 küçük uygulama olarak hayal ederseniz - her biri kendi veri modeline, kendi izinlerine, kendi faturalandırmasına, kendi bildirimlerine sahip - o zaman 22 kişi kesinlikle deli. Bu, mühendis başına altı modül anlamına geliyor ve her biri kendi başına bir ürün. Hiçbir takım bundan sağ çıkamaz. Bu mimari için korku doğrudur.
Ama mimari bu değil. Bir CRM, bir faturalama aracı ve bir yardım masası, kullanıcıya üç farklı ürün gibi görünür. Altlarında ise aynı bir avuç ilkel var: kayıtlar, ilişkiler, olayların zaman çizelgesi, roller ve izinler, para, belgeler ve bir bildirim veriyolu. Farklılıklar çoğunlukla kelime dağarcığı ve düzendir, makine değil.
150 harika ürün üretmiyoruz. Az sayıda, iyi inşa edilmiş, 150 şekilde yapılandırılmış ilkeller inşa ediyoruz.
Çekirdek/modül bölünmesi.
Zor olan her şey çekirdekte yaşar ve bir kez oluşturulur: kimlik, izinler, ilişkisel veri katmanı, ödemeler, dosya depolama, arama, denetim günlüğü, bildirim sistemi, dışa aktarma motoru. Bunlar gerçekten zor olan ve gerçekten paylaşılan kısımlardır. Burada düzeltilen bir hata, 150 modülün tamamı için aynı anda düzeltildi. Buraya eklenen bir özellik, örneğin e-imzalar, isteyen her modül tarafından anında kullanılabilir hale gelir.
O halde bir modül kasıtlı olarak incedir. Bu bir veri şeması, bir dizi görünüm, bir veya iki iş akışı ve bir iş için kullanılan kelime dağarcığından oluşur. "CRM" şunu söyleyen bir konfigürasyondur: bu kayıt türleri potansiyel müşteriler ve anlaşmalardır, bu boru hattı görünümüdür, bunlar aşamalardır, işte dönüşümün anlamı budur. Tamamen çekirdeğe dayanıyor. Yeni bir modül çoğunlukla kod değil bildirimdir.
Zor kural: benzersizliğinizi kazanın.
Bunu çürümekten koruyan disiplin, inceleme sırasında uygulanan tek bir kuraldır: Bir modülün, onu gerçekten hak etmedikçe özel olmasına izin verilmez. Bir modül kendi özel izin modelini, kendi tek seferlik bildirim formatını, tarihi saklamanın kendi özel yolunu istediğinde varsayılan yanıt hayırdır. Bunu genel bir yetenek olarak çekirdeğe itin veya yapmayın.
Bu şu anda can sıkıcıdır ve yıllar geçtikçe belirleyici olur. "Burada özel bir şeye ihtiyacımız var" isteklerinin çoğu aslında "genel durum hakkında yeterince düşünmedik." Genel durumu zorladığınızda çekirdek zenginleşir, her modül faydalanır ve korumanız gereken yüzey alanı, modül sayısı arttıkça bile kabaca düz kalır.
Nelerden vazgeçtik.
Bu yaklaşımın gerçek bir maliyeti var ve bunun adını koymalıyız. Tek bir işe takıntılı bir ekip tarafından oluşturulan türünün en iyisi bir puan aracı, o iş için eşdeğer modülümüzü geride bırakacaktır. En derin e-posta platformunda bizim sahip olmadığımız otomasyon vardır. En derin proje aracı bizim sahip olmadığımız görüşlere sahiptir. Biz aksini iddia etmiyoruz.
Bu derinliği takas ettiğimiz şey tutarlılıktır; tek bir veri modelini, tek oturum açmayı, tek faturayı, tek dışa aktarmayı ve tek bildirim katmanını paylaşan modüller. 5-50 kişilik bir ekip için bu tutarlılık, herhangi bir kategorideki derinliğin son %20'sinden daha değerlidir. Tüm işi tek bir kategori olan bir ekip için bu geçerli değil. Kimin için olduğumuzu tam olarak biliyoruz ve mimari sayesinde onlara 22 kişiyle hizmet verebiliyoruz.