अन्य संस्थापकों से हमें मिलने वाला सबसे आम प्रश्न मूल्य निर्धारण या बाज़ार में जाने के बारे में नहीं है। यह शांत, थोड़ा संदिग्ध है: आपके आकार की एक टीम पूरी चीज़ को नष्ट किए बिना 150 मॉड्यूल कैसे बनाए रखती है? ईमानदार उत्तर यह है कि हम 150 मॉड्यूल का रखरखाव नहीं करते हैं। हम एक प्लेटफ़ॉर्म और उसके ऊपर एक बहुत पतली परत बनाए रखते हैं। चाल यह निर्ममता है कि दिया गया कार्य किस परत का है।
वो गणित जो लोगों को डराता है.
यदि आप 150 छोटे अनुप्रयोगों के रूप में 150 मॉड्यूल की कल्पना करते हैं - प्रत्येक का अपना डेटा मॉडल, अपनी स्वयं की अनुमतियाँ, अपनी स्वयं की बिलिंग, अपनी स्वयं की सूचनाएं - तो 22 लोग स्पष्ट रूप से पागल हैं। यह प्रति इंजीनियर छह मॉड्यूल हैं, प्रत्येक अपने आप में एक उत्पाद है। कोई भी टीम उससे बच नहीं पाती. यह डर सही है, उस वास्तुकला के लिए।
लेकिन वह वास्तुकला नहीं है. एक सीआरएम, एक इनवॉइसिंग टूल और एक हेल्प डेस्क उपयोगकर्ता को तीन अलग-अलग उत्पादों की तरह दिखते हैं। नीचे, वे वही मुट्ठी भर आदिम हैं: रिकॉर्ड, रिश्ते, घटनाओं की समयरेखा, भूमिकाएँ और अनुमतियाँ, पैसा, दस्तावेज़ और एक अधिसूचना बस। अंतर अधिकतर शब्दावली और लेआउट का है, मशीनरी का नहीं।
हम 150 बेहतरीन उत्पाद नहीं बना रहे हैं। हम 150 तरीकों से कॉन्फ़िगर किए गए, अच्छी तरह से निर्मित प्राइमेटिव्स की एक छोटी संख्या का निर्माण कर रहे हैं।
कोर/मॉड्यूल विभाजित.
सब कुछ मूल में रहता है, और यह एक बार निर्मित होता है: पहचान, अनुमतियाँ, संबंधपरक डेटा परत, भुगतान, फ़ाइल भंडारण, खोज, ऑडिट लॉग, अधिसूचना प्रणाली, निर्यात इंजन। ये वे भाग हैं जो वास्तव में कठिन हैं और वास्तव में साझा किए गए हैं। यहां एक बग को एक ही बार में सभी 150 मॉड्यूल के लिए ठीक कर दिया गया है। यहां जोड़ी गई एक क्षमता - मान लीजिए, ई-हस्ताक्षर - हर उस मॉड्यूल के लिए तुरंत उपलब्ध हो जाती है जो इसे चाहता है।
तो फिर, एक मॉड्यूल जानबूझकर पतला होता है। यह एक डेटा स्कीमा, दृश्यों का एक सेट, एक या दो वर्कफ़्लो और एक कार्य के लिए शब्दावली है। "सीआरएम" एक कॉन्फ़िगरेशन है जो कहता है: ये रिकॉर्ड प्रकार लीड और सौदे हैं, यह पाइपलाइन दृश्य है, ये चरण हैं, यहां रूपांतरण का मतलब है। यह पूरी तरह से कोर पर सवार है। एक नया मॉड्यूल अधिकतर घोषणा है, कोड नहीं।
कठिन नियम: अपनी विशिष्टता अर्जित करें।
जो अनुशासन इसे सड़ने से बचाता है वह एक ही नियम है, जिसे समीक्षा में लागू किया गया है: किसी मॉड्यूल को तब तक विशेष होने की अनुमति नहीं है जब तक कि उसने वास्तव में इसे अर्जित नहीं किया हो। हर बार जब कोई मॉड्यूल अपना स्वयं का विशिष्ट अनुमति मॉडल, अपना स्वयं का एकबारगी अधिसूचना प्रारूप, दिनांक संग्रहीत करने का अपना निजी तरीका चाहता है - डिफ़ॉल्ट उत्तर नहीं है। इसे सामान्य क्षमता के रूप में मूल में डालें, या ऐसा न करें।
यह फिलहाल कष्टप्रद है और वर्षों के लिए निर्णायक है। अधिकांश "हमें यहां कुछ कस्टम की आवश्यकता है" अनुरोध वास्तव में "हमने सामान्य मामले के बारे में पर्याप्त रूप से नहीं सोचा है।" जब आप सामान्य मामले पर बल देते हैं, तो कोर समृद्ध हो जाता है, प्रत्येक मॉड्यूल को लाभ होता है, और आपको जिस सतह क्षेत्र को बनाए रखना होता है वह मॉड्यूल गिनती बढ़ने पर भी लगभग सपाट रहता है।
हमने क्या त्याग किया.
इस दृष्टिकोण की वास्तविक लागत है, और हमें इसका नाम बताना चाहिए। एक काम के प्रति जुनूनी टीम द्वारा बनाया गया एक सर्वोत्तम-प्रजाति बिंदु उपकरण, उस एक काम पर हमारे समकक्ष मॉड्यूल को मात देगा। सबसे गहरे ईमेल प्लेटफ़ॉर्म में स्वचालन है जो हमारे पास नहीं है। सबसे गहरे प्रोजेक्ट टूल में ऐसे विचार हैं जो हमारे पास नहीं हैं। हम अन्यथा दिखावा नहीं कर रहे हैं.
हम उस गहराई का व्यापार सुसंगतता के लिए करते हैं - मॉड्यूल जो एक डेटा मॉडल, एक लॉगिन, एक बिल, एक निर्यात और एक अधिसूचना परत साझा करते हैं। 5-50 की टीम के लिए, वह सुसंगतता किसी भी एक श्रेणी में गहराई के अंतिम 20% से अधिक मूल्यवान है। ऐसी टीम के लिए जिसका पूरा व्यवसाय उसी श्रेणी का है, ऐसा नहीं है। हम ठीक-ठीक जानते हैं कि हम किसके लिए हैं, और वास्तुकला ही वह कारण है जिससे हम 22 लोगों के साथ उनकी सेवा कर सकते हैं।