भाग एक: संविधान
अगर आपको केवल यह हिस्सा याद है, तो आप जानते हैं कि हम कैसे काम करते हैं।
हर चीज़ के नीचे का विचार
हम यह समझने की कोशिश करते हैं कि वास्तव में क्या सच है, उस समझ से निर्माण करते हैं, और जब सबूत बदलता है तो अपनी सोच बदल देते हैं।
वास्तविकता हमें बताती है कि क्या सच है। हमारा मिशन हमें बताता है कि क्या करने लायक है।
हमारा मिशन लोगों और उनके एजेंट्स को उनकी दुनिया की एक साझा, भरोसेमंद, संशोधन योग्य समझ देना है, ताकि जो वे सीखते हैं वह गायब होने के बजाय जमा हो।
समझ तभी उपयोगी है जब यह हमारे काम को बदल दे। स्पष्ट रूप से देखना काम की शुरुआत है, अंत नहीं।
स्पष्ट रूप से देखें। तय करें कि क्या मायने रखता है। कार्य करें।
ये Siftable में लोगों और एजेंट्स दोनों के लिए ऑपरेटिंग नियम हैं।
उनकी क्षमताएँ, अनुमतियाँ, ज़िम्मेदारियाँ और निर्णय लेने का अधिकार अलग-अलग हैं। सबूत, ईमानदारी, स्रोत, अनिश्चितता, विरोधाभास और संशोधन के मानक अलग नहीं हैं।
मनुष्य उन परिणामों के लिए जवाबदेह बने रहते हैं जिन्हें वे सौंपते हैं।
नीचे दी गई सभी बातें इन विचारों से निकलती हैं।
१. वही कहें जो सच है
इस बारे में साफ़ रहें कि हम क्या जानते हैं, हमें क्या लगता है, और हमें अभी क्या पता लगाना है।
प्रोडक्ट, सबूत, हमारी प्रगति, या हमारी निश्चितता को उससे बेहतर न दिखाएँ जितनी वह है — एक-दूसरे से, उपयोगकर्ताओं से, या खुद से।
“यह हमारा सबसे अच्छा अनुमान है” और “हमने इसे वेरिफ़ाई किया है” अलग-अलग बातें हैं।
उसी तरह “हम इस पर प्रयोग कर रहे हैं” और “हम इसे डिलीवर करेंगे” भी अलग हैं।
हम सावधानी से वादे करते हैं और जो वादे करते हैं उन्हें निभाते हैं।
यही नियम एजेंट्स पर भी लागू होता है। एक एजेंट को कभी भी अनुमान को सबूत के रूप में पेश नहीं करना चाहिए, किसी सार्थक अनिश्चितता को छिपाना नहीं चाहिए, या ऐसी किसी चीज़ को वेरिफ़ाई करने का दावा नहीं करना चाहिए जो उसने नहीं किया है।
२. समस्या का मालिक एक व्यक्ति होता है
हर ज़रूरी समस्या के लिए एक इंसान जवाबदेह होता है, जिसका काम उसे शुरू से अंत तक समझना है।
दूसरे लोग और एजेंट्स बिना किसी सीमा के योगदान दे सकते हैं। एजेंट्स सौंपे गए टास्क के मालिक हो सकते हैं और अपने अधिकार के भीतर स्वतंत्र रूप से काम कर सकते हैं। लेकिन समग्र परिणाम की जवाबदेही एक टीम, सिस्टम या एजेंट के झुंड में गायब नहीं हो जाती है।
मालिक हमेशा जानता है:
- हम क्या हासिल करने की कोशिश कर रहे हैं;
- हम वर्तमान में क्या मानते हैं;
- क्या अभी भी अज्ञात है;
- क्या सबूत मौजूद है;
- वास्तव में क्या हुआ;
- क्या विफल हुआ;
- और आगे क्या होगा।
हम समस्याओं के आसपास संगठित होते हैं, सिस्टम के नहीं।
एक मेमोरी टीम का काम मेमोरी की समस्या को हल करना है, न कि वर्तमान मेमोरी सिस्टम को बचाए रखना। अगर हमारे बनाए किसी चीज़ को बदलना सही जवाब है, तो उसका मालिक ऐसा कहने वाला पहला व्यक्ति होना चाहिए।
मालिकियत एक ब्लैक बॉक्स नहीं बनाती है। एक वैध कारण वाले लोग सीधे उपयोगकर्ताओं, सबूतों, ट्रेसेस, सिस्टम और शामिल लोगों के पास जा सकते हैं।
परिणाम के लिए मालिक जवाबदेह बना रहता है।
३. रिसर्च और बिल्डिंग एक साथ होती हैं
हम सवाल पूछकर, चीज़ें बनाकर, उन्हें परखकर, जो होता है उसे मापकर और अपनी समझ को सुधारकर सीखते हैं।
रिसर्च अनुशासित तरीक़े से अनिश्चितता को कम करना है। यह अपने आप में सिद्धांत बनाना नहीं है।
इंजीनियरिंग उपयोगी चीज़ों को हक़ीक़त बनाना है। यह कहीं और लिए गए फ़ैसलों को आँख बंद करके लागू करना नहीं है।
महत्वपूर्ण निर्णय लेने वाले लोग सबूत और अमल दोनों के इतने करीब रहते हैं कि यह समझ सकें कि उनके फ़ैसले वास्तव में क्या करते हैं।
एजेंट्स को भी इसी लूप में भाग लेना चाहिए: जाँच करें, निर्माण करें, परीक्षण करें, परिणाम का निरीक्षण करें और अपडेट करें — उन्हें दिए गए अधिकार और बाधाओं के भीतर।
४. हक़ीक़त के करीब रहें
प्रोडक्ट का इस्तेमाल करें।
उपयोगकर्ताओं से बात करें।
देखें कि वे वास्तव में कैसे काम करते हैं।
ट्रेस पढ़ें।
विफलताओं की खुद जाँच करें।
इस पर ध्यान दें कि लोग वास्तव में क्या करते हैं, न कि हम क्या सोचते हैं कि उन्हें क्या करना चाहिए।
रिपोर्ट, डैशबोर्ड, मेट्रिक्स, सारांश और मॉडल हमें हक़ीक़त को समझने में मदद कर सकते हैं। वे खुद हक़ीक़त नहीं हैं।
एक तकनीकी रूप से शानदार सिस्टम जो एक वास्तविक समस्या का समाधान नहीं करता है, वह सफलता नहीं है।
५. अपनी सोच बदलना ही प्रगति है
गलत होना नाकामी नहीं है। अपनी सोच बदलने से इनकार करना नाकामी है।
एक अच्छा प्रयोग जो किसी विचार को गलत साबित करता है, वह महीनों की व्यर्थ मेहनत बचा सकता है।
अनावश्यक कोड को हटाना नया कोड जोड़ने से ज़्यादा मूल्यवान हो सकता है।
किसी सिस्टम को सरल बनाना उसे विस्तारित करने से ज़्यादा कठिन और ज़्यादा मूल्यवान हो सकता है।
जो काम अब समझ में नहीं आता उसे रोकना एक वैध परिणाम है।
सीखना तब मायने रखता है जब वह अनिश्चितता को कम करे और जो हम करते हैं उसे बदले।
हम महत्वपूर्ण दिखने के लिए जटिलता नहीं बनाते हैं।
हम प्रोजेक्ट्स को केवल इसलिए जीवित नहीं रखते हैं कि उन पर पहले ही लागत आ चुकी है।
इंसानों और एजेंट्स दोनों से यह उम्मीद की जाती है कि जब सबूत बदलें तो वे अपने काम करने के मॉडल को बदलें।
६. प्रक्रिया को अपनी उपयोगिता साबित करनी होगी
प्रक्रिया इसलिए मौजूद है क्योंकि अनुभव ने हमें सिखाया है कि कुछ चीज़ों का मज़बूती से होना ज़रूरी है।
जब हम बार-बार एक ही सबक सीखते हैं, तो हम उसे कोड में बदल देते हैं। जब भी व्यावहारिक हो, हम ज़्यादा औपचारिकताओं के बजाय टूल, टेस्ट, ऑटोमेशन और साफ़ सिस्टम बाधाओं को प्राथमिकता देते हैं।
प्रक्रियाएँ पवित्र नहीं हैं।
जब वे विफल हों तो उन्हें सुधारें।
जब वे मदद करना बंद कर दें तो उन्हें हटा दें।
और किसी प्रक्रिया को ऑटोमेट करने से पहले यह साबित करें कि वह प्रक्रिया मौजूद रहने लायक है।
प्रक्रिया का उद्देश्य अच्छे काम को आसान बनाना और बार-बार होने वाली गलतियों को कठिन बनाना है — न कि संगठन को परिपक्व दिखाना।
७. सम्मान पद से नहीं, विवेक से मिलता है
उसकी सुनें जो समस्या को सबसे अच्छी तरह समझता है।
अच्छे विचार कहीं से भी आ सकते हैं। प्रमाण-पत्र, कार्यकाल, पद, संगठनात्मक स्थिति, या चाहे उपयोगी अवलोकन किसी इंसान या एजेंट से आया हो, यह किसी तर्क को सही नहीं बनाता है।
जो मायने रखता है वह तर्क और सबूत की गुणवत्ता है।
महत्वपूर्ण फ़ैसलों से पहले खुलकर बहस करें। यह साफ़ करें कि फ़ैसला कौन लेगा।
एक बार फ़ैसला हो जाने के बाद, उसका समर्थन करें और उसे अच्छी तरह से लागू करें।
अगर कोई ठोस नया सबूत सामने आता है, तो इसे फिर से खोलें। हक़ीक़त बदलने के कारण रास्ता बदलना बेवफ़ाई नहीं है।
फ़ैसले का अधिकार सौंपा जा सकता है। विश्वास किए जाने का अधिकार अर्जित करना पड़ता है।
काम करने के चार सूत्र
ये अतिरिक्त सिद्धांत नहीं हैं। ये उन संगठनों से सीखे गए उपयोगी अनुस्मारक हैं जिन्होंने हमसे पहले कठिन समस्याओं का समाधान किया है।
कोई रास्ता निकालें।
यह माना जाता है कि आपमें काम करने की क्षमता है। अगर एक रास्ता बंद है, तो दूसरा देखें। यह समझाने में न उलझें कि कुछ मुश्किल क्यों है, बल्कि उसे हल करें।
वह सरल काम करें जो काम करता है।
समाधानों को उनके नतीजों से आँकें, न कि वे कितने परिष्कृत लगते हैं, इससे। जटिलता को अपने अस्तित्व को सही ठहराना पड़ता है।
ऑप्टिमाइज़ करने से पहले हटाएँ।
आवश्यकता पर सवाल उठाएँ। जो अनावश्यक है उसे हटा दें। जो बचता है उसे सरल बनाएँ। फिर उसे तेज़ करें और ऑटोमेट करें।
समस्या के अंदर जाएँ।
केवल दूर से आवश्यकताएँ इकट्ठा न करें। समस्या का सामना कर रहे लोगों के साथ काम करें। वास्तविक वर्कफ़्लो देखें और परिणाम की ज़िम्मेदारी लें।
साधारण भाषा का नियम
अगर किसी महत्वपूर्ण विचार या नियम को साधारण भाषा में नहीं समझाया जा सकता है, तो शायद हम उसे अभी तक अच्छी तरह से नहीं समझे हैं।
जटिलता नीचे रह सकती है।
साझा समझ इतनी सरल रहनी चाहिए कि उसे संप्रेषित किया जा सके।
भाग दो: समझौते
एमटीएस समझौता
तकनीकी स्टाफ का एक सदस्य एक अन्वेषक और एक निर्माता दोनों है।
आपको हर चीज़ में समान रूप से मज़बूत होने की ज़रूरत नहीं है। कुछ लोग अनुसंधान, सिस्टम, उत्पाद, डिज़ाइन, बुनियादी ढाँचे, सुरक्षा, या किसी अन्य तकनीकी अनुशासन में बहुत गहराई तक जाएँगे। मज़बूत विशेषज्ञता मूल्यवान है।
लेकिन हर एमटीएस को यह करने में सक्षम होना चाहिए:
- अच्छे सवाल पूछें और धारणाओं को सबूत से अलग करें;
- एक विचार का परीक्षण करने के लिए एक उपयोगी तरीका डिज़ाइन करें;
- काम करने वाले सिस्टम बनाएँ, या उनके निर्माण का निर्देशन करें;
- एजेंट्स और अन्य उपकरणों के माध्यम से प्रभावी ढंग से काम करें;
- जाँचें कि वास्तव में क्या हुआ;
- केवल सारांश से तर्क करने के बजाय विफलताओं की जाँच करें;
- अपने तर्क को सादे तौर पर समझाएँ;
- और जब वास्तविकता असहमत हो तो रास्ता बदलें।
निर्माता का मतलब “वह व्यक्ति नहीं है जो मैन्युअल रूप से सबसे ज़्यादा कोड लिखता है।”
जैसे-जैसे उपकरण बेहतर होंगे, एजेंट ज़्यादा कार्यान्वयन करेंगे। निर्माण का मतलब है एक वास्तविक, काम करने वाले, समझने योग्य सिस्टम को अस्तित्व में लाने में सक्षम होना — वास्तुकला, विनिर्देशों, परीक्षणों, मूल्यांकनों, उपकरणों, निशानों, कोड और एजेंट आउटपुट पर निर्णय के माध्यम से — और यह कैसे व्यवहार करता है इसकी ज़िम्मेदारी लेना।
कोई व्यक्ति जो केवल प्रस्ताव बना सकता है लेकिन कुछ भी वास्तविक नहीं बना सकता, वह यहाँ असामान्य होगा।
इसी तरह वह भी जो बिना यह सोचे कि वे सही, उपयोगी या बनाने लायक हैं, तेज़ी से कार्यान्वयन कर सकता है।
गैर-तकनीकी भूमिकाओं से पीआर मर्ज करने की उम्मीद नहीं की जाती है। उनसे उम्मीद की जाती है कि वे अपने शिल्प में सबूत, स्वामित्व और वास्तविकता के साथ संपर्क के समान मानकों का पालन करें।
जब भी व्यावहारिक हो, हम काल्पनिक चीज़ों के विवरण के बजाय काम करने वाली चीज़ों को प्राथमिकता देते हैं।
मनुष्यों और एजेंट्स के लिए एक ऑपरेटिंग सिस्टम
मनुष्यों और एजेंट्स को सच्चाई के लिए अलग-अलग नियम नहीं मिलते हैं।
उनकी अलग-अलग क्षमताएँ, अनुमतियाँ, ज़िम्मेदारियाँ और अधिकार हैं। लेकिन वे दुनिया को समझने और उस पर कार्रवाई करने के लिए एक ही प्रणाली में भाग लेते हैं।
दोनों एक ही मूल विचारों के साथ काम करते हैं:
दावा · सबूत · अनुमान · अनिश्चितता · प्रतिबद्धता · विरोधाभास · संशोधन
दोनों यह सहेजते हैं कि महत्वपूर्ण जानकारी कहाँ से आई।
दोनों गलत हो सकते हैं।
दोनों से अपडेट होने की उम्मीद है।
दोनों विरोधाभासों को चुपचाप सुलझाने के बजाय सामने लाते हैं।
दोनों भेद करते हैं:
“मुझे लगता है” को “मैंने सत्यापित किया” से।
एजेंट्स केवल उन्हें दिए गए अधिकार के भीतर कार्य करते हैं। मनुष्य यह तय करने के लिए ज़िम्मेदार रहते हैं कि कौन सा अधिकार सौंपना है और उस सौंपने के परिणामी परिणामों के लिए जवाबदेह हैं।
लक्ष्य यह दिखावा करना नहीं है कि मनुष्य और एजेंट विनिमेय हैं।
लक्ष्य यह सुनिश्चित करना है कि दोनों में से किसी को भी वास्तविकता के लिए एक अलग मानक न मिले।
महत्वपूर्ण काम सुपाठ्य होना चाहिए
महत्वपूर्ण काम पर्याप्त टिकाऊ, स्रोत-सहित सबूत छोड़ता है ताकि कोई अन्य अधिकृत व्यक्ति या एजेंट समझ सके:
- क्या हुआ;
- यह क्यों हुआ;
- क्या तय किया गया था;
- किस सबूत ने इसका समर्थन किया;
- और इसका क्या परिणाम हुआ।
नियम है:
कुछ भी महत्वपूर्ण दुर्गम क़बीलाई ज्ञान पर निर्भर नहीं होना चाहिए।
इसका मतलब यह नहीं है कि सब कुछ रिकॉर्ड किया जाए।
कार्मिक मामले, कानूनी सलाह, संवेदनशील व्यक्तिगत बातचीत, ग्राहक-प्रतिबंधित जानकारी, सुरक्षा-संवेदनशील सामग्री और अन्य जानकारी जो निजी रहनी चाहिए, जानबूझकर निजी रहती हैं।
सुपाठ्यता काम की सेवा करती है। यह विवेक, गोपनीयता, सुरक्षा या विश्वास को ओवरराइड नहीं करती है।
आवर्ती काम को सीखना चाहिए
जब व्यावहारिक हो, तो आवर्ती काम एक बंद लूप बन जाता है:
अवलोकन करें → समझें → निर्णय लें → कार्य करें → मापें → सीखें → अपडेट करें
ग्राहक की प्रतिक्रिया को अगले उत्पाद निर्णय में सुधार करना चाहिए।
घटनाओं को अगले सिस्टम में सुधार करना चाहिए।
बिक्री की बातचीत को अगली बिक्री की बातचीत में सुधार करना चाहिए।
एजेंट की विफलताओं को अगले एजेंट रन में सुधार करना चाहिए।
मानव की विफलताओं को अगले मानव निर्णय में सुधार करना चाहिए।
जो हम सीखते हैं वह गायब होने के बजाय जमा होना चाहिए।
ऑपरेटिंग फॉर्मूला
गति में पूरा सिस्टम है:
वास्तविकता को स्पष्ट रूप से देखें। चुनें कि क्या मायने रखता है। किसी को स्वामित्व दें। बनाएँ। देखें कि क्या हुआ। अपडेट करें। जो अब मिशन की सेवा नहीं करता है उसे हटा दें। दोहराएँ।
कंपनी Siftable के दर्शन का एक डॉगफूड उदाहरण है।
जो अनुशासन हम उत्पाद से चाहते हैं, वही इसे बनाने वाले लोगों और एजेंट्स पर लागू होता है।
भाग तीन: ऑपरेटिंग नोट्स
ये संविधान से ज़्यादा सटीक हैं और बदलने के लिए ज़्यादा तैयार हैं।
सच्चाई पर
हर फ़ैसले के लिए समान मात्रा में कठोरता की ज़रूरत नहीं होती है।
सबूत का स्तर तीन चीज़ों के साथ बढ़ता है:
अनिश्चितता × परिणाम × अपरिवर्तनीयता
एक छोटा, प्रतिवर्ती निर्णय? विवेक का प्रयोग करें और शिप करें।
मेमोरी, पुनर्प्राप्ति या ऑन्टोलॉजी में एक मौलिक परिवर्तन? बताएँ कि हम क्या मानते हैं, सबूत को और क्या समझा सकता है, हम इसे कैसे मापेंगे, और क्या हमारी सोच बदल देगा।
एक सुरक्षा, डेटा-अखंडता, गोपनीयता, या विश्वास-प्रभावित निर्णय? शिपिंग से पहले काफी उच्च स्तर का उपयोग करें।
हम दोनों चरम सीमाओं को अस्वीकार करते हैं:
व्यावहारिकता के भेस में आरामदायक अस्पष्टता
और
कठोरता के भेस में अकादमिक औपचारिकता।
दो सवाल मायने रखते हैं
अनिश्चित उत्पाद कार्य के लिए, हमें आमतौर पर दो अलग-अलग सवालों के जवाब देने की ज़रूरत होती है:
क्या यह काम करता है?
और
क्या यह मायने रखता है?
पहला वैज्ञानिक या तकनीकी सत्य है।
दूसरा उत्पाद सत्य है।
एक ऐसा आदर्श प्रयोग जो एक ऐसे सवाल का जवाब देता है जिसकी किसी को परवाह नहीं है, वह गलत लक्ष्य पर निर्देशित कठोरता है।
एक स्टार्टअप के लिए, उपयोगकर्ता वास्तव में क्या करते हैं, यह वास्तविकता के सबसे मज़बूत संकेतों में से एक है।
स्वामित्व पर
हर महत्वपूर्ण समस्या का ठीक एक जवाबदेह मानव स्वामी होता है।
स्वामी समस्या की वर्तमान स्थिति को वहन करता है और जवाब दे सकता है:
- हम क्या हासिल करने की कोशिश कर रहे हैं, और यह क्यों मायने रखता है?
- हम वर्तमान में क्या मानते हैं?
- क्या अभी भी अज्ञात है?
- हमारे पास क्या सबूत है?
- वास्तव में क्या शिप किया गया है?
- क्या विफल हुआ?
- किसने हमारी सोच बदली?
- आगे क्या होगा?
स्वामित्व शुरू से अंत तक होता है।
योगदान असीमित है।
एजेंट्स पर्याप्त सौंपे गए काम को स्वतंत्र रूप से निष्पादित कर सकते हैं और कार्यों या उप-समस्याओं की कार्यशील स्थिति बनाए रख सकते हैं।
लेकिन सौंपने से मानव जवाबदेही समाप्त नहीं होती है।
जानकारी स्वामी के माध्यम से गेट नहीं की जाती है। जवाबदेही उनके साथ बनी रहती है।
अधिकार और संस्थापक पर
दो अलग-अलग तरह के अधिकार होते हैं।
ज्ञान संबंधी अधिकार: हमें किसी दावे या निर्णय को कितना महत्व देना चाहिए कि क्या सच है?
निर्णय का अधिकार: निर्णय लेने के लिए कौन ज़िम्मेदार है?
वे एक जैसे नहीं हैं।
विशेषज्ञता, सबूत और एक मज़बूत ट्रैक रिकॉर्ड ज्ञान संबंधी अधिकार अर्जित करते हैं।
यह लागू होता है चाहे उपयोगी सबूत या तर्क किसी इंसान से आए या एजेंट से।
निर्णय का अधिकार स्पष्ट रूप से सौंपा जाता है।
महत्वपूर्ण फ़ैसलों के लिए, एक नामित मानव निर्णयकर्ता होता है — आमतौर पर समस्या का मालिक। फ़ैसले से पहले ज़ोरदार बहस हो सकती है। एक बार तय हो जाने पर, अमल करें। जब ठोस नया सबूत सामने आए तो फिर से खोलें।
संस्थापक की भूमिका
स्वामित्व वितरित है। कंपनी-व्यापी संदर्भ नहीं है।
संस्थापक काम को समझने के लिए संगठनात्मक सीमाओं को पार कर सकता है: पुनर्प्राप्ति को डीबग करने वाले इंजीनियर से सीधे बात करें, एक एजेंट के ट्रेस का निरीक्षण करें, ग्राहक के साथ बैठें, कोड का निरीक्षण करें, या एक धारणा को चुनौती दें।
ऐसा करने से स्वामित्व स्वचालित रूप से हस्तांतरित नहीं होता है।
संस्थापक के पास असामान्य रूप से व्यापक निर्णय अधिकार और पूरी कंपनी को समझने की ज़िम्मेदारी होती है।
संस्थापक के पास सही होने का स्वचालित अधिकार नहीं होता है।
संस्थापक का अंतर्ज्ञान सिस्टम में एक परिकल्पना के रूप में प्रवेश करता है, सबूत के रूप में नहीं।
समन्वय पर
कोई भी भूमिका मुख्य रूप से संगठन में जानकारी ऊपर या नीचे भेजने के लिए मौजूद नहीं होनी चाहिए।
हम यह नहीं चाहते:
इंजीनियर → मैनेजर सारांश → डायरेक्टर सारांश → एक्जीक्यूटिव सारांश
जब अंतर्निहित काम का सीधे निरीक्षण किया जा सकता है।
न ही इंसानों को अपना समय उस जानकारी को मैन्युअल रूप से भेजने में लगाना चाहिए जिसे एक अधिकृत सिस्टम या एजेंट सीधे सुपाठ्य बना सकता है।
महत्वपूर्ण स्थिति सिस्टम और कलाकृतियों में रहनी चाहिए जिन्हें उपयुक्त लोग और एजेंट खुद क्वेरी कर सकें।
अगर हमारे पास अंततः मैनेजर होते हैं, तो वे इसलिए होने चाहिए क्योंकि वे लोगों और टीमों को बेहतर बनाते हैं: कोचिंग, भर्ती, विवेक का विकास, मानकों को बनाए रखना, कठिन समस्याओं का समाधान करना और बाधाओं को दूर करना।
“अगले मैनेजर के लिए स्थिति को सुपाठ्य बनाना” किसी नौकरी के अस्तित्व के लिए पर्याप्त कारण नहीं है।
नौकरशाही से पहले क्षमता ख़रीदें
एक स्थायी समन्वय भूमिका, प्रक्रिया या टीम जोड़ने से पहले, पूछें कि क्या बेहतर टूलिंग, ऑटोमेशन, कंप्यूट, एजेंट्स या एक मज़बूत व्यक्ति वही क्षमता प्रदान कर सकता है।
एक महँगा अनुमान बिल जो कई समय से पहले की भर्तियों को रोकता है, वह सस्ता हो सकता है।
एक विशाल अनुमान बिल जो बेकार काम पैदा कर रहा है, वह अभी भी बर्बादी है।
टोकन की खपत उत्पादकता का पैमाना नहीं है।
ज्ञान और मशीनरी पर
ज्ञान को सहेजें। मशीनरी को फिर से बनाएँ।
जिन चीज़ों को हम टिकाऊ मानते हैं उनमें शामिल हैं:
- सबूत और स्रोत;
- महत्वपूर्ण निर्णय और वे क्यों लिए गए;
- ग्राहक की समझ;
- बाधाएँ;
- डोमेन मॉडल;
- परीक्षण और मूल्यांकन;
- विनिर्देश;
- सीखे गए कौशल।
जिन चीज़ों को बदलने के लिए हम ज़्यादा इच्छुक हैं उनमें शामिल हैं:
- डैशबोर्ड;
- गोंद कोड (glue code);
- एक बार के आंतरिक उपकरण;
- अस्थायी इंटरफेस;
- ऑर्केस्ट्रेशन;
- कार्यान्वयन विवरण।
यह सबसे ज़्यादा आंतरिक सॉफ़्टवेयर पर लागू होता है।
कुछ मुख्य सिस्टम और एब्स्ट्रैक्शन सालों तक चलने चाहिए। लेकिन वे यह स्थायित्व एक महत्वपूर्ण समस्या को हल करना जारी रखकर कमाते हैं — इसलिए नहीं कि उन्हें बनाना महँगा था।
सीखने और सरलीकरण पर
एक नकारात्मक परिणाम उस अनिश्चितता के अनुपात में मूल्यवान है जिसे वह समाप्त करता है।
एक विलोपन उस जटिलता के अनुपात में मूल्यवान है जिसे वह बिना मूल्य नष्ट किए हटा देता है।
पूरा चक्र है:
सीखें → विश्वास बदलें → कार्रवाई बदलें → सुधार करें
“हमने 47 प्रयोग किए” कोई उपलब्धि नहीं है अगर कुछ भी उपयोगी नहीं बदला।
न ही “हमने 10,000 लाइनें हटा दीं।”
हम लॉन्च के तमाशे को सीखने के तमाशे से नहीं बदलते हैं।
प्रक्रिया पर
प्रक्रिया संस्थागत शिक्षा का संकलित रूप है।
जब हम कुछ कठिन तरीके से सीखते हैं, तो हम उस सबक को सहेजते हैं ताकि हमें उसे हमेशा कठिन तरीके से सीखने की ज़रूरत न पड़े।
क्रम में प्राथमिकता दें:
- अनावश्यक आवश्यकता को हटाएँ;
- अनावश्यक काम हटाएँ;
- जो बचा है उसे सरल बनाएँ;
- इसे तेज़ बनाएँ;
- इसे ऑटोमेट करें।
ऑटोमेशन सबसे अंत में आता है।
जब कोई प्रक्रिया आवश्यक हो, तो अच्छे उपकरणों और प्रणालियों के माध्यम से प्रवर्तन को प्राथमिकता दें, बजाय गद्य के जिसे लोगों को मैन्युअल रूप से याद रखना चाहिए।
हर प्रक्रिया को जवाब देने में सक्षम होना चाहिए:
यह क्यों मौजूद है?
अगर कोई जवाब नहीं दे सकता है, तो यह हटाने के लिए एक उम्मीदवार है।
घटनाओं से बेहतर समझ और बेहतर तंत्र उत्पन्न होना चाहिए, न कि एक स्वचालित नया चेकबॉक्स।
भाग चार: सिद्धांत और तंत्र
प्रारंभिक-चरण का सिद्धांत — २०२६
यह हमारा विश्वास है कि एक शुरुआती Siftable को कैसे काम करना चाहिए। यह संवैधानिक नहीं है और कंपनी बदलने पर इसे बदलना चाहिए।
- ऐसी चीज़ बनाएँ जो लोग चाहते हैं।
- लगातार उपयोगकर्ताओं से बात करें।
- वे काम करें जो बड़े पैमाने पर नहीं किए जा सकते, जब वे हमें कुछ महत्वपूर्ण सिखाते हैं।
- सब कुछ सहज महसूस होने से पहले शिप करें। बिल्डिंग से वह ज्ञान मिलता है जो प्लानिंग से नहीं मिल सकता।
- सहज महसूस होने से ज़्यादा छोटे रहें। भर्ती करना अपने आप में प्रगति नहीं है।
- अनसुलझी प्रोडक्ट अनिश्चितता को छिपाने के लिए कभी भर्ती न करें।
- वास्तविक क्षमता और सीखने पर आक्रामक रूप से ख़र्च करें; संगठनात्मक दिखावे पर सावधानी से ख़र्च करें।
- एजेंट्स का आक्रामक रूप से उपयोग करें जहाँ वे वास्तविक क्षमता बढ़ाते हैं, न कि AI अपनाने का दिखावा करने के लिए।
- संस्थापक विवरण में रहता है।
- ध्यान भटकाने वाली चीज़ों से बचें। फ़ोकस जीवित रहने का एक फ़ायदा है।
वर्तमान तंत्र — २०२६
ये उपकरण हैं, आदेश नहीं। जब कुछ बेहतर मौजूद हो तो इन्हें बदलें या हटा दें।
अजनबी-संपर्क गेट
प्रमुख प्रोडक्ट का काम अनिश्चित काल तक उन उपयोगकर्ताओं के संपर्क के बिना जारी नहीं रहता जो हम नहीं हैं।
प्रोडक्शन ट्रेस समीक्षा
एक सिस्टम पर काम करने वाले लोग नियमित रूप से असली ट्रेस और असली विफलताओं का निरीक्षण करते हैं — मानव और एजेंट दोनों — केवल सारांश पर निर्भर रहने के बजाय।
डॉगफूडिंग (Dogfooding)
हम अपना काम करने के लिए Siftable का उपयोग करते हैं जहाँ भी ऐसा करने से हमें कुछ उपयोगी सीखने को मिलता है। इसमें हमारे मानव-एजेंट वर्कफ़्लो शामिल हैं: कंपनी को स्वयं उस सिस्टम का उपयोग करना चाहिए जिसे वह बना रही है।
निकाली और सरलीकृत चीज़ों का लॉग
हम उन सार्थक चीज़ों को रिकॉर्ड करते हैं जिन्हें हमने रोका, गलत साबित किया, हटाया या सरल बनाया — कारण के साथ।
प्रयोग का टेम्पलेट
पर्याप्त रूप से परिणामी अनिश्चितता के लिए:
- दावा;
- प्रतिस्पर्धी स्पष्टीकरण;
- माप;
- क्या हमारी सोच बदल देगा;
- परिणाम;
- व्याख्या;
- फ़ैसला।
इसे दाँव के अनुपात में उपयोग करें।
सीधे उपयोगकर्ता सत्र
संस्थापक और तकनीकी कर्मचारी नियमित रूप से उपयोगकर्ताओं के साथ सीधे समय बिताते हैं।
संशोधन
विभिन्न परतें अलग-अलग गति से बदलती हैं।
मूल सिद्धांत और मिशन तभी बदलने चाहिए जब कंपनी खुद कुछ अलग बन रही हो।
सात सिद्धांत और समझौते टिकाऊ हैं, लेकिन पवित्र नहीं। किसी एक को बदलने के लिए यह साफ़ करना होगा कि हमने क्या सीखा और पुराना संस्करण अब सही क्यों नहीं है।
ऑपरेटिंग नोट्स हमारी समझ में सुधार होने पर बदलते हैं।
सिद्धांत और तंत्र दिनांकित और प्रयोज्य हैं।
एक नए संवैधानिक सिद्धांत के रूप में प्रस्तावित किसी भी चीज़ के लिए एक उपयोगी परीक्षण:
- क्या इसे हर चीज़ के मूल विचार से निकाला जा सकता है?
- क्या हम किसी आकर्षक चीज़ का नाम ले सकते हैं जिसे यह हमें मना करने पर मजबूर करेगा?
अगर नहीं, तो यह शायद सजावट है।
इसे निचली परत में रखें — या इसे छोड़ दें।
क्या इसे वास्तविक बनाता है
यह दस्तावेज़ संस्कृति नहीं है।
संस्कृति वह है जिसे हम पुरस्कृत करते हैं।
जिसे हम अस्वीकार करते हैं।
हम किसे काम पर रखते हैं।
हम क्या सहन करते हैं।
लोग अधिकार का उपयोग कैसे करते हैं।
मनुष्य एजेंट्स को कैसे सौंपते हैं।
एजेंट्स कैसे व्यवहार करते हैं जब कोई नहीं देख रहा होता है।
जब कुछ विफल हो जाता है तो हम कैसे प्रतिक्रिया करते हैं।
जब सबूत असुविधाजनक होता है तो हम क्या करते हैं।
संविधान अंततः इस बात से लिखा जाता है कि जब हमें तकलीफ़ होती है तो हम क्या करते हैं।
पहली बार जब वास्तविकता किसी ऐसी चीज़ को गलत साबित करती है जिसे हम पसंद करते हैं और हम फिर भी रास्ता बदलते हैं, तो यह यहाँ लिखे किसी भी चीज़ से ज़्यादा मायने रखता है।