Tenex के Citizen Developer SDLC का परिचय, एक छह-चरणीय जीवनचक्र जो गैर-तकनीकी कर्मचारियों द्वारा AI के साथ बनाए गए उत्पादों को व्यक्तिगत प्रोटोटाइप से प्रोडक्शन तक ले जाता है, जिस पर पूरी कंपनी भरोसा कर सकती है।
एलेक्स लीबरमैन (@businessbarista), अरमान हेज़रखानी (@ArmanHezarkhani, सुची पटेल, और अश्विन कडारू (@AshwinKadaru
एक Tenex.co फ्रेमवर्क।
TLDR (संक्षिप्त सारांश)
Citizen SDLC एक छह-चरणीय जीवनचक्र (विचार, प्रवेश द्वार, ट्रिएज, प्रोविज़निंग, निर्माण, संचालन और परिवर्तन) है, जो गैर-तकनीकी कर्मचारियों द्वारा AI के साथ बनाए गए सॉफ़्टवेयर को व्यक्तिगत प्रोटोटाइप से नियंत्रित प्रोडक्शन में बदलता है। एक सिद्धांत सभी चरणों में लागू होता है: AI श्रम करता है, नियतात्मक कोड सीमाएँ निर्धारित करता है, और मानव अपवादों को संभालते हैं। यह इसलिए अस्तित्व में आया क्योंकि AI ने कोड लिखने की लागत लगभग शून्य कर दी और बाधा को आगे बढ़ा दिया, यह सुनिश्चित करने के लिए कि जो बनाया गया है वह सही है और एक बार लाइव होने के बाद बढ़ते बेड़े को नियंत्रित रखना है।
हमारे ग्राहकों में से एक एक निवेश फर्म है। उनकी पोर्टफोलियो संचालन टीम के एक सदस्य, जिसने कभी कोड की एक लाइन नहीं लिखी, ने वह डैशबोर्ड बनाया जो अब उनकी पूरी टीम रोज़ाना इस्तेमाल करती है। यह कुछ दर्जन पोर्टफोलियो कंपनियों में मूल्य-सृजन कार्य को ट्रैक करता है। उसने इसे लगभग दो महीनों में क्लॉड को प्रॉम्प्ट करके बनाया। हर एक लाइन AI द्वारा लिखी गई थी।
और यह अच्छा है। दृश्य सही हैं, वर्कफ़्लो टीम के वास्तविक संचालन के अनुरूप है, और अपनाना तुरंत हुआ। उसने किसी भी इंजीनियर के शामिल होने से पहले ही सही उत्पाद का खाका खींच लिया था।
यह भाग्य नहीं है। दशकों तक, जो व्यक्ति किसी व्यावसायिक समस्या को समझता था, वह लगभग कभी भी वह व्यक्ति नहीं होता था जो उसे ठीक करने के लिए सॉफ़्टवेयर बना सके। इस अंतर को पाटना एक बहुत बड़ा प्रयास था: एक प्रोडक्ट मैनेजर जो उसकी समस्या को एक स्पेक में बदल दे, इंजीनियर जो स्पेक को कोड में अनुवाद करें, और रोडमैप पर बाकी सब कुछ के पीछे एक स्थान। विचार और टूल के बीच महीने बीत जाते थे, और अंततः जो शिप होता था वह किसी और की उसकी बात की व्याख्या होती थी।
वह अंतर अभी समाप्त हो गया है। निर्माण की शक्ति उन लोगों के पास चली गई है जो वास्तव में प्रक्रिया को समझते हैं, जानते हैं कि डेटा का क्या अर्थ है, और हर दिन वर्कफ़्लो में रहते हैं। उसने पहली बार में सही चीज़ बनाई क्योंकि वह स्रोत थी। कोई भी उसका अनुवाद करने या उसे थोड़ा गलत समझने के लिए बीच में नहीं खड़ा था। यही सिटिज़न डेवलपमेंट का वादा है, और उसने इसे पूरा किया।
फिर हमने हुड के नीचे देखा।
पूरा एप्लिकेशन एक HTML फ़ाइल था। 540 KB। लगभग 5,300 लाइनें। मास्टर डेटासेट एक लाइन पर 80 KB डेटा के ब्लॉब के रूप में इसके अंदर रहता था। जब फ़ाइल को अपडेट करने की आवश्यकता होती थी, तो AI ने पैच फ़ंक्शन जोड़ दिए थे जो ऐप लोड होने पर हर बार मानों को फिर से लिखते थे। अपने काम को सहेजने का मतलब था कि ऐप अपने स्वयं के HTML को फिर से लिखे, खुद को आपके लैपटॉप पर डाउनलोड करे, और आप इसे एक नए संस्करण के रूप में साझा ड्राइव पर फिर से अपलोड करें। यदि दो लोग एक साथ संपादित करते हैं, तो अंतिम सहेजें जीतता है, और दूसरे व्यक्ति के संपादन गायब हो जाते हैं।
एक दिन, एक सेव फ़ंक्शन फ़ाइल में एक मार्कर की तलाश में गया, उसे नहीं मिला, और वैसे भी जो कुछ था उसे वापस लिख दिया। पूरा 540 KB का एप्लिकेशन 7 बाइट्स में कट गया। एक ही मूक लेखन में, वह डैशबोर्ड जिस पर उसकी टीम हर दिन चलती थी, अस्तित्व में नहीं रहा, और जिस तरह से इसे बनाया गया था, उसमें इसे पकड़ने, रोकने या वापस लाने के लिए कुछ भी डिज़ाइन नहीं किया गया था।
अधिकांश नेता उस कहानी को सुनते हैं और निष्कर्ष निकालते हैं कि सिटिज़न डेवलपमेंट एक देयता है जिसे बंद कर दिया जाना चाहिए। हमें लगता है कि यह गलत सबक है, और जो कंपनियां इस पर कार्य करती हैं, वे हारने वाली हैं। सही सबक: उसने अपना काम शानदार ढंग से किया। किसी ने सॉफ़्टवेयर को शिप करने के लिए रास्ता नहीं बनाया था।
बाधा स्थानांतरित हो गई
दशकों तक, सॉफ़्टवेयर बनाना महंगा हिस्सा था। यह धीमा, दुर्लभ और महंगा था, और पूरा सॉफ़्टवेयर डेवलपमेंट जीवनचक्र इसकी रक्षा के लिए विकसित हुआ। स्पेक, टिकट, स्प्रिंट, कोड रिव्यू: पारंपरिक SDLC में हर अनुष्ठान इसलिए मौजूद है क्योंकि कोड लिखना बाधा था।
AI ने उस चरण को लगभग शून्य कर दिया, और बाधा स्थानांतरित हो गई है। जब कोई भी एक दोपहर में एक काम करने वाला ऐप बना सकता है, तो महंगा काम अब निर्माण नहीं है। यह वह है जो बाद में आता है: यह सुनिश्चित करना कि जो बनाया गया है वह सही और सुरक्षित है, और एक बार लाइव होने के बाद इन ऐप्स के बढ़ते बेड़े को नियंत्रित रखना है।
GIF
और निर्माण धीमा नहीं हो रहा है, जिससे दो समस्याएं उत्पन्न हो रही हैं जिन्हें हल करने की आवश्यकता है:
पहला, हुड के नीचे गुणवत्ता। एक गैर-इंजीनियर द्वारा एक खाली पेज से प्रॉम्प्ट किया गया एजेंट हैकी सॉफ़्टवेयर पर आता है जो आज काम करता है और हमेशा के लिए अनुरक्षित नहीं किया जा सकता है। 540 KB फ़ाइल एक अपवाद नहीं है; यह बिना रेल के निर्माण का डिफ़ॉल्ट आउटपुट है।
दूसरा, विस्तार। हर टीम अपना खुद का ऐप चाहती है, और कोई भी केंद्रीय IT समूह उनमें से दर्जनों को हाथ से नहीं बना सकता और संचालित नहीं कर सकता। बिना गार्डरेल के, प्रत्येक ऐप उस स्टैक पर बनाया जाता है जिसे बिल्डर या मॉडल ने चुना: एक अलग डेटाबेस, एक अलग ऑथ स्कीम, रहस्य जहाँ भी वे उतरे, वहाँ छिपे हुए। इसके बजाय अनुरोधों को ब्लॉक करें और वे रुकते नहीं हैं, वे बस किताबों से बाहर चले जाते हैं। किसी भी तरह से आपको न केवल ऐप्स का एक बेड़ा विरासत में मिलता है, बल्कि उनके नीचे बुनियादी ढांचे की उलझी हुई गड़बड़ी भी मिलती है, और इनमें से कुछ भी ऐसा नहीं है जिसे IT उचित रूप से सुरक्षित, समर्थन या समझा सके।
तो असली सवाल जो हर कंपनी का सामना करने वाला है: आप गैर-तकनीकी कर्मचारियों को उस बेड़े को विरासत में लिए बिना वास्तविक आंतरिक सॉफ़्टवेयर शिप करने कैसे देते हैं?
तीन डिफ़ॉल्ट उत्तर सभी विफल होते हैं:
1) इसे लॉक कर दें। अनुरोध कतार में लग जाते हैं, धैर्य समाप्त हो जाता है, और शैडो ऐप्स वैसे भी बन जाते हैं। अब आप उनमें से कुछ भी नहीं देख सकते हैं। आप उस पर शासन नहीं कर सकते जिसे आप देख नहीं सकते।
2) इसे खुला छोड़ दें। गैर-इंजीनियरों को बिना किसी संरचना के AI टूल्स पर इंगित करें और डेमो का जश्न मनाएं। इस तरह आपको 540 KB फ़ाइल मिलती है। और आप बाद में इसकी समीक्षा करके इससे बाहर नहीं निकल सकते। जब तक कोड रिव्यू में एक मोनोलिथ दिखाई देता है, तब तक यह पहले से ही एक मोनोलिथ होता है। इसे शुरुआती बिंदु पर ही रोका जाना चाहिए।
3) हर चीज़ की समीक्षा करें। हर बदलाव पर मानव अनुमोदन लगाएं। आपकी IT टीम छोटी है, बिल्ड वॉल्यूम विस्फोटक रूप से बढ़ रहा है, और अब हर डिप्लॉयमेंट एक समीक्षक के कैलेंडर पर इंतजार करता है। समीक्षाएं या तो अपनाने को मार देती हैं या रबर-स्टैम्प हो जाती हैं। दोनों परिणाम उद्देश्य को विफल करते हैं।
तो इसका उत्तर एक और नीति दस्तावेज़ नहीं है, बल्कि एक जीवनचक्र है: एक वास्तविक SDLC, जो उन लोगों के लिए डिज़ाइन किया गया है जो खुद को कभी डेवलपर नहीं कहेंगे, जिसमें एक मेमो में लिखे जाने के बजाय प्लेटफ़ॉर्म में निर्मित गार्डरेल हैं। एक सड़क जो एक बिल्ड को पहले सादे-भाषा के विचार से लेकर नियंत्रित प्रोडक्शन तक ले जाती है, बिना कभी बिल्डर को इंजीनियर बनने के लिए कहे। व्यक्ति इरादा प्रदान करता है; प्लेटफ़ॉर्म अनुशासन प्रदान करता है।
एक सिद्धांत इसके हर चरण में चलता है: AI श्रम करता है, नियतात्मक कोड सीमाएँ निर्धारित करता है, और मानव अपवादों को संभालते हैं। AI ड्राफ्ट करता है, वर्गीकृत करता है और लिखता है। कोड तय करता है कि क्या अनुमति है। लोगों का उपयोग केवल वहीं किया जाता है जहाँ वास्तव में निर्णय की आवश्यकता होती है। उस विभाजन को पकड़ो; यही वह चीज़ है जो पूरी चीज़ को स्केल करती है।
हम इसे Citizen SDLC कहते हैं। छह चरण, प्रत्येक नियंत्रित।
चरण 1
विचार
एक व्यक्ति AI की मदद से ऐप का सादे भाषा में वर्णन करता है: यह क्या करता है, इसका उपयोग कौन करता है, यह किस डेटा को छूता है, इसका मालिक कौन है। इसमें मिनट लगते हैं और यह एक मेमो की तरह पढ़ा जाता है। यह उस ब्रीफ के रूप में भी काम करता है जिस पर आगे की सभी चीज़ें चलती हैं। यह ऑपरेटिंग मॉडल का पहला कदम है: AI एक अव्यवस्थित बात को एक संरचित कलाकृति में बदलने का श्रम करता है।
यहाँ देखें कि व्यवहार में यह कैसा दिखता है। फंड फाइनेंस में कोई टाइप करता है: "मुझे कैपिटल कॉल नोटिस के लिए एक ट्रैकर चाहिए। अभी यह एक स्प्रेडशीट है जिसे मैं हाथ से अपडेट करता हूँ और हर शुक्रवार को ईमेल करता हूँ।" AI वही पूछता है जो एक इनटेक विश्लेषक पूछेगा। इसे और किसे देखने की आवश्यकता है? फंड फाइनेंस और IR में बारह लोग। डेटा आज कहाँ रहता है? बॉक्स में एक स्प्रेडशीट, और केवल-पढ़ने के लिए ठीक है। जब आप बाहर हों तो इसका मालिक कौन है? उसका प्रबंधक। अव्यवस्थित बात एक ब्रीफ बन गई है: उद्देश्य, उपयोगकर्ता, डेटा स्रोत, पहुँच स्तर, मालिक, यहाँ तक कि ऐप के आकार का पहला अनुमान भी। एक PRD, प्रभाव में, जो किसी ऐसे व्यक्ति द्वारा लिखा गया है जिसने कभी PRD शब्द नहीं सुना है।
GIF
अभी तक कुछ भी मौजूद नहीं है। कोई कोड नहीं, कोई पहुँच नहीं, कोई बुनियादी ढांचा नहीं। यह जानबूझकर है: फर्म ऐप के अस्तित्व में आने से पहले उसके बारे में एक राय बनाती है, न कि उसके लोड-बेयरिंग होने के छह महीने बाद।
चरण 2
प्रवेश द्वार
हर अनुरोध एक संरचित प्रवेश द्वार से होकर जाता है, और वही क्रिया जो इसे फ़ाइल करती है, इसे सीधे ट्रिएज में डाल देती है। ब्रीफ अनुरोध है, IT जो टिकट देखता है, स्थायी रिकॉर्ड, और एक कैटलॉग में प्रविष्टि जिसे हर कोई खोज सकता है, सभी एक साथ। कोई गलियारे में पूछना नहीं, कोई एहसान नहीं, कोई शैडो पाइपलाइन नहीं। आप उस पर शासन नहीं कर सकते जिसे आप देख नहीं सकते, और आप उसे साझा नहीं कर सकते जिसे आप ढूंढ नहीं सकते। प्रवेश द्वार दोनों को पहले दिन से सच बनाता है।
यह वह चरण है जो शैडो पाइपलाइन को मारता है। एक बिल्ड जो प्रवेश द्वार को छोड़ता है, वह अभी भी लैपटॉप पर प्रोटोटाइप के रूप में मौजूद हो सकता है, लेकिन वह वहीं रहता है। वह सब कुछ जो प्रोटोटाइप को एक ऐसे सॉफ़्टवेयर में बदलता है जिस पर एक टीम भरोसा कर सकती है, इस चरण के बाद रहता है: वास्तविक स्टोरेज, फर्म साइन-इन, एक डिप्लॉय पाइपलाइन, चलाने के लिए कहीं। इनमें से कुछ भी ऐसे बिल्ड तक नहीं पहुँचता जो कभी प्रवेश द्वार से नहीं आया। आप प्रवेश द्वार के आसपास रूट कर सकते हैं; यदि आप ऐसा करते हैं तो आप प्रोटोटाइप से आगे नहीं जा सकते।
चरण 3
ट्रिएज
AI दो अक्षों पर अनुरोध को वर्गीकृत करता है। आकार: यह किस प्रकार का ऐप है? कर्मचारी वास्तव में क्या बनाते हैं, इसका एक रिवर्स-ऑडिट लगभग हमेशा एक छोटी सूची में आता है: आर्टिफैक्ट जनरेटर, वर्कफ़्लो ऑटोमेशन, CRUD ऐप्स, और इंटरैक्टिव डैशबोर्ड। आकार का नामकरण आपको बताता है कि इसे किस आर्किटेक्चर की आवश्यकता है, और यह अगले चरण को स्टैम्प करने के लिए पक्की सड़क सौंपता है। ब्लास्ट रेडियस: यदि यह बिल्ड गलत दिशा में जाता है तो यह कितना नुकसान कर सकता है? हम इसे चार आयामों पर स्कोर करते हैं:
- पहुँच और क्षमता: यह क्या छू सकता है, और क्या यह लिख सकता है या केवल पढ़ सकता है?
- प्रतिवर्तीता और स्वायत्तता: क्या लूप में कोई मानव है, और क्या कार्रवाई को पूर्ववत किया जा सकता है?
- एक्सपोज़र: आउटपुट कौन देखता है, और यह कंपनी के बाहर कितनी दूर जाता है?
- डेटा संवेदनशीलता: यह जिस डेटा के साथ इंटरैक्ट करता है वह कितना गोपनीय है?
लेकिन यहाँ वह नियम है जो इसे भरोसेमंद बनाता है: AI सलाह देता है। कोड निर्णय लेता है। मॉडल ब्रीफ पढ़ता है और इसे वर्गीकृत करता है; फिर IT द्वारा लिखा गया नीति कोड प्रत्येक वर्गीकरण को नियमों के विरुद्ध जाँचता है। इसे कैपिटल कॉल ट्रैकर पर काम करते देखें। आकार: इंटरैक्टिव डैशबोर्ड। ब्लास्ट रेडियस: आंतरिक फंड डेटा, बारह आंतरिक उपयोगकर्ता, केवल-पढ़ने के लिए, लूप में मानव, मौजूदा ऐप्स के साथ कोई ओवरलैप नहीं। हर आयाम स्वीकृत सीमाओं के अंदर आता है, इसलिए यह स्वीकृत है, और किसी भी मानव ने इसके बारे में बहस नहीं की।
अब एक तथ्य बदलें। मान लें कि ट्रैकर को LP प्रतिबद्धता डेटा की भी आवश्यकता है। ब्रीफ जितना चाहे उतना प्रेरक हो सकता है; वह एकल परिवर्तन डेटा-संवेदनशीलता आयाम को IT द्वारा निर्धारित सीमा से ऊपर ले जाता है, और अनुरोध एक व्यक्ति के पास जाता है। बीच में कोई निर्णय कॉल नहीं हुआ। कोई नियम या तो मेल खाता है या नहीं।
तीन निकास मार्ग:
- स्वीकृत। ब्लास्ट रेडियस हर सीमा के अंदर, पूर्ण ब्रीफ, उच्च आत्मविश्वास। हमारे ग्राहक पर, लगभग 10 में से 9 अनुरोध इस तरह, स्वचालित रूप से हल होते हैं।
- पुन: उपयोग। यह एक ऐसे ऐप के साथ ओवरलैप करता है जो पहले से मौजूद है, इसलिए अनुरोधकर्ता को डुप्लिकेट बनाने के बजाय उस ऐप के मालिक के पास भेज दिया जाता है। डुप्लिकेट को मर्ज किया जाता है, गुणा नहीं किया जाता है।
- एस्केलेटेड। एक आयाम अपनी सीमा पार कर जाता है, या आत्मविश्वास कम है। IT और सुरक्षा में एक मानव को पूर्ण अनुरोध संदर्भ के रूप में मिलता है।
GIF
दसवां अनुरोध, अजीब एक, अभी भी पूर्ण ब्रीफ के साथ एक मानव की मेज पर आता है। अन्य नौ को कभी इसकी आवश्यकता नहीं थी।
चरण 4
प्रावधान
यहाँ वह कदम है जो IT को बड़ी मात्रा में हाँ कहने देता है: प्रावधान IT का यह नियंत्रण खोना नहीं है कि क्या शिप होता है, बल्कि IT का नियंत्रण ऊपर की ओर स्थानांतरित हो रहा है। प्रत्येक ऐप की बाद में समीक्षा करने के बजाय, IT एक बार पक्की सड़क लिखता है, और हर ऐप उसी पर जन्म लेता है। एक व्यक्ति अनुमोदन करता है, और प्लेटफ़ॉर्म ऐप को उसके आकार के लिए सड़क से स्टैम्प करता है: एक रिपो, फर्म साइन-इन, एक डिप्लॉय आइडेंटिटी, एक निजी वातावरण, और अपना स्वयं का डेटाबेस, सभी को IT द्वारा स्वामित्व और संस्करणित बुनियादी ढांचे-के-रूप में-कोड के रूप में परिभाषित किया गया है। मिनटों में प्रावधान किया गया।
यह एकमात्र क्षण है जब उन्नत शक्ति चलती है, और एक मानव इसके सामने है। हर ऐप अलग-थलग, नियंत्रित और ऑडिटेड पैदा होता है: अपना स्वयं का दीवार-बंद वातावरण, कोई सार्वजनिक पता नहीं, कोई संग्रहीत क्लाउड रहस्य नहीं, दिन शून्य से एक केवल-जोड़ें ऑडिट ट्रेल। सुरक्षा कार्य एक बार, सड़क में हुआ। किसी भी ऐप को इसे दोहराने की आवश्यकता नहीं है।
क्योंकि सड़क प्रति आकार लिखी गई है, मानव अनुमोदन एक डिफ़ॉल्ट मुद्रा है, स्थायी कर नहीं। उपन्यास आकार और उच्च-ब्लास्ट-रेडियस बिल्ड मानव गेट को अच्छे के लिए रखते हैं। लेकिन एक बार जब किसी आकार की सड़क ने पर्याप्त बिल्ड पर खुद को साबित कर लिया है, तो उस सड़क पर कम-ब्लास्ट-रेडियस अनुरोध स्वचालित रूप से प्रावधान कर सकते हैं। यह वही "मानव निर्णय को पूंछ के लिए बचाएं" तर्क है जो एक चरण पहले लागू किया गया था: शुरुआत में आप एक व्यक्ति को अधिक रूट करते हैं, और जैसे-जैसे पैटर्न बने रहते हैं, रेखा स्वचालन की ओर बढ़ती है।
और सड़क एक और चीज़ ले जाती है जो बुनियादी ढांचे जितनी ही मायने रखती है: AI नियम पुस्तिका। विरासत में मिला रिपो कोडिंग एजेंट को हर सत्र में निर्देशों का एक सेट सौंपता है, जो वास्तविक विफलताओं से सीखे गए एंटी-पैटर्न को एन्कोड करता है। 1 KB से अधिक के इनलाइन डेटा ब्लॉब्स को न डालें। ऐप लोड होने पर डेटा को फिर से लिखने वाले फ़ंक्शन न जोड़ें। इस तरह हुड के नीचे की गुणवत्ता को बिल्डर से एक भी सर्वोत्तम अभ्यास जानने के लिए कहे बिना हल किया जाता है: सड़क एजेंट को उनका पालन करने के लिए बनाती है। उन नियमों में से प्रत्येक एक निशान है जिसके पीछे एक कहानी है (आपने उनमें से एक पढ़ी है)।
चरण 5
निर्माण
बिल्डर अपने कोडिंग एजेंट (Claude Code, Codex, आदि) को एक नियंत्रित क्लाउड वर्कस्पेस के अंदर प्रॉम्प्ट करता है, कभी भी अपने लैपटॉप पर नहीं। लैपटॉप पर एक टर्मिनल एजेंट वहाँ बैठी हर चीज़ को विरासत में लेता है: मेल, सिंक किए गए ड्राइव, ब्राउज़र कुकीज़, कैश की गई क्रेडेंशियल्स। वर्कस्पेस में, एजेंट प्रोजेक्ट देखता है। और कुछ नहीं।
एक इंजीनियर सामान्य रूप से जो कुछ भी ले जाता है, वह सब रेल द्वारा ले जाया जाता है: हमारे ग्राहक पर, चार परतों में 35 गार्डरेल जिन्हें बिल्डर बंद नहीं कर सकता है।
मर्ज परत में AI-जनरेटेड कोड के लिए विशेष रूप से निर्मित ड्रिफ्ट चेक शामिल हैं: फ़ाइल-आकार बजट, कोई अतिरिक्त-बड़ा इनलाइन डेटा नहीं, ऑडिट-लॉग अनुरूपता। हरा या यह मर्ज नहीं होता है। जब कोई जाँच विफल होती है, तो बिल्डर एजेंट से इसे ठीक करने के लिए कहता है और फिर से पुश करता है।
मानव नियमित परिवर्तनों की समीक्षा नहीं करते हैं। जाँच ही समीक्षा है। नियमित परिवर्तन CI की गति से चलते हैं, न कि समीक्षक के कैलेंडर की गति से। जो मानव तक पहुँचता है वह परिणामी पूंछ है, जिसे यांत्रिक रूप से पता लगाया जाता है: विनाशकारी स्कीमा परिवर्तन, नई निर्भरताएँ, एजेंट की अपनी बाधाओं में परिवर्तन, बुनियादी ढांचे को छूने वाली कोई भी चीज़। वे एक व्यक्ति की प्रतीक्षा करते हैं। और कुछ नहीं करता है। और जब कोई नई चीज़ वैसे भी बच जाती है, तो इसका समाधान एक नई स्वचालित जाँच है, न कि अधिक मानव समीक्षा। सिस्टम सबक को एन्कोड करके सख्त हो जाता है, न कि बैठकों को जोड़कर।
शुरुआत से डैशबोर्ड को याद रखें। उनमें से दो ड्रिफ्ट चेक पहले सप्ताह में ही उस पर फायर हो जाते। 80 KB की एकल-लाइन ब्लॉब अपनी पहली कमिट पर ही CI में विफल हो जाती, विफलता मोड के सख्त होने से महीनों पहले।
चरण 6
संचालन और परिवर्तन
छह महीने बाद, कैपिटल कॉल ट्रैकर अभी भी चल रहा है, और यह वह जगह है जहाँ जीवनचक्र अपनी उपयोगिता साबित करता है। IR में कोई मार्च नोटिस पर वायर डेडलाइन पर सवाल उठाता है। ऑडिट ट्रेल तीस सेकंड में उत्तर देता है: फ़ील्ड को किसने बदला, कब, और इससे पहले यह क्या कहता था, संपादन के समान लेन-देन में रिकॉर्ड किया गया। कोई भी ईमेल श्रृंखला से सच्चाई का पुनर्निर्माण नहीं करता है। जब बिल्डर टीम बदलता है, तो स्वामित्व एक कंधे उचकाने में विलीन होने के बजाय एक नामित उत्तराधिकारी को हस्तांतरित हो जाता है। और यदि वह फर्म को पूरी तरह से छोड़ देता है, तो उसका साइन-इन मर जाता है और इसके द्वारा खोला गया हर दरवाजा एक साथ बंद हो जाता है। ट्रैकर भी शामिल है। अगली तिमाही की सुविधा का अनुरोध पहली कमिट के समान रेल पर चलता है।
शासन वार्षिक ऑडिट पर नहीं, बल्कि संकेत पर चलता है। ट्रैकर के उपयोग मेट्रिक्स से पता चलता है कि दो और टीमें इस पर झुक रही हैं, इसलिए इसे प्रचारित और निवेशित किया जाता है। मुद्रा डैशबोर्ड जिसे अप्रैल के बाद से किसी ने नहीं खोला है, उसे एक मेनू में सड़ने के लिए छोड़ने के बजाय संग्रहीत किया जाता है। कोई भी इसका शोक नहीं मनाता है। पहले दिन स्वामित्व सौंपा जाता है, इसलिए कुछ भी अपने बिल्डर से अधिक जीवित नहीं रहता है। एक अप्रयुक्त ऐप एक विफलता है, ट्रॉफी नहीं। लक्ष्य कभी ऐप गिनती नहीं था: यह एक जीवित कैटलॉग है जिस पर आपके लोग वास्तव में भरोसा करते हैं, भूल गए सॉफ़्टवेयर के कब्रिस्तान के बजाय।
जैसे-जैसे कैटलॉग दस ऐप्स से बढ़कर दो सौ हो जाता है, एक केंद्रीय टीम अब उन सभी पर नज़र नहीं रख सकती है, और निरीक्षण को उन टीमों की ओर बाहर की ओर धकेलना होगा जो ऐप्स के मालिक हैं। इसे कब और कितनी दूर तक संघीय करना है, यह एक निर्णय है, और यह पोर्टफोलियो के बढ़ने के साथ बदलता है। यहाँ शासन एक मुद्रा है जिसे आप ट्यून करते रहते हैं, एक नियंत्रण नहीं जिसे आप एक बार सेट करते हैं।
वह नियम जो पूरी चीज़ को एक साथ रखता है
एक ट्रिगर है जो हम हर ग्राहक को सिखाते हैं, क्योंकि यह "क्या इस पूरी प्रक्रिया की आवश्यकता है?" के 90% सवालों का जवाब देता है: दूसरा-उपभोक्ता नियम। यह काम करता है क्योंकि यह वह क्षण है जब जोखिम प्रोफ़ाइल बदल जाती है।
कोई व्यक्ति अपने लिए, अपने लैपटॉप पर, सीमित डेटा पहुँच के साथ विश्लेषण बना रहा है? कम ब्लास्ट रेडियस, हल्का शासन। चार्ट, मेमो और स्क्रिप्ट जो वे अपने लिए चलाते हैं, उन्हें डिप्लॉयमेंट पाइपलाइन की आवश्यकता नहीं है। लेकिन जिस क्षण कोई दूसरा व्यक्ति आउटपुट का सीधे उपयोग करना चाहता है, लेखक से रिफ्रेश मांगने के बजाय? ब्लास्ट रेडियस बढ़ जाता है: अधिक पहुँच, डेटा आगे की यात्रा कर रहा है, कोई और इसके सही होने पर भरोसा कर रहा है। यह अब सॉफ़्टवेयर है, और यह जानबूझकर, एक स्पष्ट घटना के रूप में, पूर्ण जीवनचक्र में स्नातक होता है। वही डेटा स्रोत, वही पहचान, नई सड़क।
वह एक नियम यही कारण है कि प्रक्रिया लोगों को डुबोती नहीं है। अधिकांश बिल्ड कभी भी रेखा पार नहीं करते हैं। जो करते हैं, वे बिल्कुल वही हैं जो समारोह के लायक हैं।
जिसके बारे में हम ईमानदार हैं
कोई भी प्लेटफ़ॉर्म पहली बार बिल्डरों को सही कोड लिखने नहीं देता है। हम ऐसा दावा नहीं करते हैं। परतें इसलिए मौजूद हैं ताकि एक गलती एक छोटी सी सीमा के अंदर एक असुविधा हो, न कि पूरी फर्म में एक घटना। प्रत्येक परत ठीक वही कवर करती है जो उसके ऊपर वाला नहीं कर सकता है:
और ऑडिट कुछ भी नहीं रोकता है, लेकिन यह हर घटना को छोटा, समझाने योग्य और जिम्मेदार ठहराने योग्य बनाता है। यह एक बुरी दोपहर और एक बुरी तिमाही के बीच का अंतर है।
सिटिज़न डेवलपमेंट पेशेवर इंजीनियरिंग को बदलने के लिए नहीं है। विनियमित प्रक्रियाओं में सिस्टम ऑफ रिकॉर्ड, ग्राहक-सामना या निवेशक-सामना करने वाली कोई भी चीज़, बाहरी उपयोगकर्ताओं के लिए बनाए गए ऐप्स, कोई भी चीज़ जहाँ डाउनटाइम वित्तीय दंड वहन करता है: वे अभी भी इंजीनियरिंग के हैं, और प्रवेश द्वार उन्हें पहले दिन वहाँ रूट करता है। यह जो बदलता है वह बाधा है। यह आंतरिक टूल्स की लंबी पूंछ को लोकतांत्रिक बनाता है जो कभी भी एक औपचारिक इंजीनियरिंग प्रोजेक्ट के लायक नहीं थे और उन्हें उस गति से शिप करता है जो रोडमैप कतार कभी नहीं दे सकती थी। बिना सीमाओं वाला एक फ्रेमवर्क एक नारा है; यह जानता है कि यह किसके लिए नहीं है।
वास्तव में क्या बदलता है
निवेश फर्म में, प्लेटफ़ॉर्म के माध्यम से पहला ऐप वही है जिसने इसे प्रेरित किया: शुरुआती कहानी से डैशबोर्ड, रेल पर फिर से बनाया गया। वही स्क्रीन। वही बिल्डर। अब वास्तविक स्टोरेज, फर्म साइन-इन, और हर संपादन का इतिहास है। यह कभी भी खुद को 7 बाइट्स में नहीं काट सकता है, क्योंकि जिस वर्ग के कोड ने इसे कारण बनाया वह मर्ज नहीं कर सकता है।
लगभग 10 में से 9 अनुरोध पहले से ही स्वचालित रूप से हल हो जाते हैं, और वह हिस्सा केवल बढ़ता है। गैर-तकनीकी बिल्डर जो कुछ भी बनाते हैं, उसमें से अधिकांश स्वभाव से कम ब्लास्ट रेडियस वाला होता है। आंतरिक, ज्यादातर-पढ़ने के लिए, छोटे-दर्शकों वाले टूल्स। जैसे-जैसे प्रत्येक आकार की सड़क खुद को साबित करती है, उनमें से अधिक बिल्ड लूप में बिल्कुल भी मानव के बिना प्रावधान और तैनात करने के लिए सुरक्षित हो जाते हैं। मानव ध्यान परिणामी पूंछ पर केंद्रित होता रहता है और बाकी सभी जगह पतला होता जाता है।
हाँ आज मिनट लगते हैं, और यह तत्काल की ओर बढ़ता है, क्योंकि ना में निर्मित है।
हर कंपनी के पास सैकड़ों बिल्डर होने वाले हैं। अधिकांश कंपनियां अभी भी तय कर रही हैं कि इससे डरना है या इसके बारे में उत्साहित होना है। जो जीतेंगी, वे सबसे अधिक बिल्डरों वाली नहीं होंगी। वे सबसे अच्छी सड़कों वाली होंगी।
