ऐसे सिस्टम डिजाइन काटा कैसे बनाएं जो इंजीनियरों को आर्किटेक्चरल ट्रेड-ऑफ का मूल्यांकन करने के लिए प्रशिक्षित करें

एक टीम ने एक क्षेत्रीय उत्सव के लिए टिकट बुकिंग सेवा का डिज़ाइन तैयार किया। यह अपेक्षित भार को आसानी से संभाल लेता है, और डिज़ाइन समीक्षा सर्वसम्मति से समाप्त हो जाती है। फिर निर्देश बदल जाते हैं: आयोजक अब वादा करता है कि टिकटों की बिक्री तब भी जारी रहनी चाहिए, जब बिक्री अवधि के दौरान एक डेटा सेंटर ऑफ़लाइन हो जाए। अब उसी डिज़ाइन में एक त्रुटि का खतरा है, और इसे तैयार करने वाले इंजीनियरों को यह तय करना होगा कि क्या बदलना है, क्या छोड़ना है और अपने इस निर्णय को कैसे समझाना है।

यह एक उदाहरण मात्र है, कोई दस्तावेजी घटना नहीं। यह वह स्थिति है जिसका अभ्यास करने के लिए सिस्टम डिज़ाइन काटा बनाया जाता है: एक डिज़ाइन जो पहले के प्रतिबंधों के तहत ठीक था, नए प्रतिबंधों के सामने आता है, और इंजीनियरों को कारणों सहित उसका बचाव या संशोधन करना होता है। यह मार्गदर्शिका इंजीनियरिंग इनेबलमेंट लीड्स और इंजीनियरिंग मैनेजर्स के लिए है। इसमें बताया गया है कि सिस्टम डिज़ाइन काटा क्या है, इसे कैसे बनाया जाता है, इसे कैसे चलाया और स्कोर किया जाता है, और प्रशिक्षण कब उपयोगी नहीं रह जाता। प्रत्येक मामले और मानदंड का उपयोग करने से पहले एक वरिष्ठ इंजीनियर द्वारा सत्यापन किया जाना चाहिए।

सिस्टम डिजाइन काटा क्या है?

सिस्टम डिज़ाइन काटा एक संक्षिप्त, समय-सीमाबद्ध डिज़ाइन अभ्यास है। एक छोटी टीम को एक पैराग्राफ में एक व्यावसायिक समस्या दी जाती है, वे उसका आर्किटेक्चर स्केच बनाते हैं, उसे अपने साथियों के सामने प्रस्तुत करते हैं और कठिन प्रश्नों के उत्तर देते हैं। शोधकर्ता इसे आर्किटेक्चर काटा या आर्किटेक्चरल काटा भी कहते हैं। इस प्रारूप की शुरुआत टेड न्यूवार्ड ने एक कार्यशाला के रूप में की थी और इसके नियम और मॉडरेटर की भूमिका नील फोर्ड के आर्किटेक्चरल काटा पेज पर दर्ज हैं। न्यूवार्ड का प्रेरक प्रश्न, जो वहाँ उद्धृत है, यह है कि जब इंजीनियरों को अपने करियर में आधे दर्जन से भी कम बार आर्किटेक्चर करने का मौका मिलता है, तो संगठन महान आर्किटेक्ट कैसे तैयार कर सकते हैं? काटा उन्हें उत्पादन जोखिम के बिना अतिरिक्त अभ्यास का अवसर प्रदान करता है।

त्वरित तथ्य

1. प्रदर्शन संबंधी समस्या का वर्णन करें।

विषय से नहीं, कार्य से शुरुआत करें। कार्य है बदलती परिस्थितियों में आर्किटेक्चर का बचाव करना। वास्तविक कार्य में यह डिज़ाइन समीक्षाओं, घटना अनुवर्ती कार्रवाईयों और नियोजन बैठकों में होता है, जहाँ आवश्यकताएँ बदलती रहती हैं: अधिक ट्रैफ़िक, उपलब्धता का कड़ा वादा, डेटा-रेजिडेंसी का नया नियम, या सीमित बजट।

कई इंजीनियर एक तर्कसंगत वास्तुकला का खाका खींच सकते हैं। लेकिन कम ही इंजीनियर यह बता पाते हैं कि दो लक्ष्यों के टकराव की स्थिति में वे किन चीजों का त्याग करेंगे और कौन से सबूत उनका निर्णय बदल देंगे। यही दूसरा कौशल है जिसका अभ्यास काटा में किया जाता है।

एक वाक्य में प्रदर्शन विवरण लिखें और किसी इंजीनियरिंग मैनेजर से इसकी जाँच करवाएँ: "किसी आर्किटेक्चर और बदले हुए प्रतिबंध को देखते हुए, इंजीनियर यह बताता है कि क्या गड़बड़ है, बदलाव का प्रस्ताव देता है, फायदे-नुकसान बताता है और यह भी बताता है कि उसे अभी क्या नहीं पता है।"

2. सीखने और संदर्भ संबंधी कमियों का निदान करें

कुछ भी बनाने से पहले, उस कार्य की तुलना अपने कार्यक्रम में वर्तमान में प्रचलित और मूल्यांकित की जाने वाली प्रक्रियाओं से करें।

1. क्या अभ्यास में वास्तविक कार्य का उपयोग होता है? यदि प्रशिक्षण में केवल पैटर्न को अलग-अलग करके सिखाया जाता है और मूल्यांकन एक बहुविकल्पीय परीक्षा है, तो किसी ने भी अपने विकल्प का बचाव करने का अभ्यास नहीं किया है।
2. संज्ञानात्मक आवश्यकता क्या है? ब्लूम के संशोधित वर्गीकरण में, विकल्पों की तुलना बाधाओं से करना विश्लेषण और मूल्यांकन के अंतर्गत आता है, और संशोधित डिज़ाइन प्रस्तावित करना सृजन के अंतर्गत आता है। हमारी मार्गदर्शिका ब्लूम के वर्गीकरण के अनुसार सीखने की गतिविधियों का मिलान करना यह दर्शाता है कि गतिविधि को उस स्तर से कैसे मिलाया जाए।
3. क्या कौशल के अलावा कोई और चीज बाधा बन रही है? जाँच करें कि इंजीनियरों के पास डिज़ाइन करने का समय है या नहीं, क्या आर्किटेक्चर संबंधी निर्णय लेने की ज़िम्मेदारी किसी और की है और क्या आवश्यकताएँ लिखित रूप में मौजूद हैं। यदि कोई निर्णय टीम के बाहर के किसी व्यक्ति द्वारा लिया जाता है, तो किसी भी कार्रवाई से टीम के कार्यों में कोई बदलाव नहीं आएगा। उन समस्याओं को उन लोगों तक पहुँचाएँ जो उन्हें हल कर सकते हैं।

3. डिजाइन की तैयारी और अभ्यास

प्रत्येक चरण को एक अलग कार्य सौंपें।

तैयारी। एक संक्षिप्त नैदानिक ​​जांच के साथ पूर्वापेक्षाओं की जाँच करें: आपकी टीम द्वारा उपयोग की जाने वाली शब्दावली (उपलब्धता, संगति, विलंबता, लागत), वे मूलभूत तत्व जिनकी उन्हें जानकारी होनी चाहिए, और आपका अपना डिज़ाइन समीक्षा टेम्पलेट। इस चरण में स्व-गति से अध्ययन करना उपयुक्त है, और एक पुनरावलोकन जाँच केवल पूर्वापेक्षाओं की पुष्टि करती है।

अभ्यास करें। काटा का अभ्यास करें। नील फोर्ड की वेबसाइट पर वर्णित प्रारूप के अनुसार, टीम बनने के बाद, अभ्यास तीन चरणों में चलता है: एक चर्चा चरण जहाँ टीम यह तय करती है कि वे क्या बना रहे हैं, एक सहकर्मी समीक्षा चरण जहाँ प्रत्येक टीम प्रस्तुति देती है और प्रश्नों के उत्तर देती है, और एक मतदान चरण जहाँ साथी "बहुत बढ़िया" ("शानदार"), "ठीक-ठाक" ("कुछ कमियाँ रह गईं") या "खराब") ("बहुत बड़ी चूक") देते हैं। कुछ नियम सीधे तौर पर अपनाने लायक हैं: टीमें अपरिचित तकनीक के बारे में अनुमान लगा सकती हैं लेकिन उन्हें बताना होगा, और यह मानकर नहीं चल सकतीं कि वे सर्व-कुशल लोगों की टीम को काम पर रख सकती हैं।

बदलती हुई बाधा को शामिल करें। मानक काटा एक निश्चित समस्या देता है। इस मार्गदर्शिका में कौशल का अभ्यास करने के लिए, बीच में एक दूसरा कार्ड जोड़ें: एक बदली हुई बाधा जिसे टीम को आत्मसात करना होगा। यह हमारी डिज़ाइन संबंधी पसंद है, मूल नियमों का हिस्सा नहीं है, इसलिए इसका परीक्षण करें।

प्रतिक्रिया। प्रतिक्रिया को निर्णयों से जोड़ें, न कि कुल स्कोर से। "आपने दो क्षेत्रों में बदलाव किया, लेकिन यह नहीं बताया कि बदलाव के दौरान दिए गए ऑर्डर का क्या होगा" कहना "5 में से 3" कहने से कहीं अधिक उपयोगी है।

लाइव इनपुट या अतुल्यकालिक समीक्षा? लाइव सुविधा तब सबसे अधिक उपयोगी होती है जब कोई विकल्प अस्पष्ट हो और इंजीनियर किसी वरिष्ठ सहकर्मी से यह सीख सकें कि वे उस निर्णय पर क्यों अडिग हैं। लिखित तर्क की तुलना व्याख्यात्मक उदाहरण से करने के लिए अतुल्यकालिक समीक्षा पर्याप्त है।

4. एक वास्तविक उदाहरण के माध्यम से काम करें

यह केवल उदाहरण के लिए है। उपयोग करने से पहले एक वरिष्ठ इंजीनियर को मामले और उत्तर के मानदंडों को सत्यापित करना चाहिए।

मामला यह है कि एक क्षेत्रीय उत्सव में एक सप्ताहांत में 20,000 टिकट बिक जाते हैं, जिनमें से अधिकांश बिक्री पहले दस मिनट में ही हो जाती है। ब्रीफ के पहले संस्करण में एक ऐसी बुकिंग सेवा की मांग की गई है जो इस चरम स्थिति को संभाल सके। डिज़ाइन: एक वेब स्तर, एक डेटाबेस, और चेकआउट के समय भुगतान प्रदाता से संपर्क।

नियम में बदलाव किया गया। बीच में ही आयोजक ने जोड़ा: यदि कोई डेटा सेंटर ऑफ़लाइन हो जाता है तो भी बिक्री जारी रहनी चाहिए, और कोई भी टिकट दो बार नहीं बेचा जा सकता।

पहला प्रयास। "दूसरा डेटा सेंटर जोड़ें और डेटाबेस की प्रतिकृति बनाएं।" टीम ने एक परिचित तरीके का सहारा लिया है, लेकिन यह नहीं बताया है कि जब दोनों साइटें आपस में संवाद नहीं कर पाएंगी तो दोहरी बिक्री न करने के नियम का क्या होगा।

प्रतिक्रिया और पुनः प्रयास। फैसिलिटेटर टीम से उन दो लक्ष्यों के नाम बताने को कहता है जो आपस में टकराव में हैं और नेटवर्क विभाजन की स्थिति में वे किस लक्ष्य की रक्षा करेंगे। पुनः प्रयास में उनसे चयन करने और यह बताने को कहा जाता है कि ग्राहक को कैसा अनुभव होता है।

एक और बेहतर प्रयास। "हम दोहरी बिक्री न करने के नियम का पालन करेंगे। विभाजन के दौरान, केवल प्राथमिक साइट ही टिकट बेचेगी और दूसरी साइट पर प्रतीक्षा पृष्ठ दिखाया जाएगा। हम थोड़े समय के लिए कम उपलब्धता स्वीकार करते हैं ताकि एक ही सीट दो बार न बेची जाए। हमने मान लिया है कि विभाजन दुर्लभ और अल्पकालिक है, और हम आयोजक से यह पुष्टि चाहेंगे कि प्रतीक्षा पृष्ठ स्वीकार्य है। यदि उन्हें दोनों साइटों पर बिक्री की आवश्यकता है, तो हम कुछ बिना बिके सीटों की कीमत पर, प्रत्येक साइट को पहले से ही अलग-अलग सीट ब्लॉक आवंटित करेंगे।" ध्यान दें कि यह उत्तर विवाद का नाम बताता है, एक पक्ष का चयन करता है, लागत बताता है और यह भी बताता है कि उसे क्या नहीं पता।

प्रत्येक उत्तर उचित है या अपूर्ण? प्रत्येक का मूल्यांकन स्वीकृत मानदंडों के आधार पर करें, न कि समीक्षक द्वारा चुने गए आर्किटेक्चर के आधार पर। पहले प्रयास में एक घटक का नाम तो दिया गया है, लेकिन उसके बदले में क्या देना होगा, इसका उल्लेख नहीं किया गया है। बेहतर प्रयास विशिष्ट है, अपनी मान्यताओं को बताता है और उसकी कीमत के साथ एक विकल्प प्रस्तुत करता है।

5. क्षमता का आकलन करें और स्थानांतरण की योजना बनाएं

किसी इंजीनियर की क्षमता का प्रमाण उसके द्वारा पहले कभी न देखे गए नए मामले पर प्रदर्शन करना है। इसमें ट्रेड-ऑफ तर्क और नई बाधा के प्रति प्रतिक्रिया को अंक दिए जाते हैं। एक सरल मूल्यांकन मानदंड में प्रत्येक के लिए 0 से 2 तक का पैमाना उपयोग किया जाता है:

मुख्य बिंदु: 0 का अर्थ है अनुपस्थित या असमर्थित, 1 का अर्थ है प्रासंगिक कमियों के साथ आंशिक, और 2 का अर्थ है पूर्ण और सहमत मानदंडों के अनुसार उचित। गंभीर त्रुटियों को अलग से परिभाषित करें, जैसे कि किसी निर्दिष्ट सुरक्षा या डेटा-सुरक्षा आवश्यकता की अनदेखी करना, ताकि समग्र स्कोर किसी एक त्रुटि को छिपा न सके। यह मूल्यांकन मानदंड एक प्रस्ताव है, मान्य मानक नहीं: इसे इंजीनियरिंग प्रबंधक के साथ अनुकूलित करें और इसका प्रायोगिक परीक्षण करें। उपयोगी प्रतिक्रिया के साथ इंटरैक्टिव अभ्यास को डिज़ाइन करने के लिए हमारी मार्गदर्शिका में यह बताया गया है कि निर्णयों से संबंधित प्रतिक्रिया कैसे लिखें।

योजना को सोच-समझकर स्थानांतरित करें। काटा के बाद, प्रत्येक इंजीनियर से एक लाइव डिज़ाइन निर्णय की समीक्षा करने के लिए कहें और उन पर समान प्रश्न लागू करें। किसी पिछली घटना की दोषरहित समीक्षा वास्तविक कार्य के लिए एक और अच्छा माध्यम है; दोषरहित घटना समीक्षा आयोजित करने के लिए हमारी मार्गदर्शिका देखें ।

जहां इंटरैक्टिव डिलीवरी मददगार होती है

इंटरैक्टिव फॉर्मेट तब मददगार होते हैं जब समूह में शामिल होने से पहले सभी को अपनी सहमति देनी होती है। लाइव काटा सेशन में, फैसिलिटेटर बदले हुए प्रतिबंध को दिखा सकता है, टीम के प्रत्येक सदस्य से यह पूछ सकता है कि वे क्या समझौता करेंगे और क्यों, और फिर चर्चा शुरू होने से पहले परिणाम बता सकता है। मूल फॉर्मेट के अंत में साथियों का मतदान भी इसी तरह आसानी से कराया जा सकता है। तैयारी के लिए या सेशन में शामिल न हो पाने वाले इंजीनियरों के लिए भी यही तरीका अपनाया जा सकता है। AhaSlides इंटरैक्टिव लर्निंग और लाइव व सेल्फ-पेस्ड डिलीवरी के बीच स्विच करने की सुविधा देता है। यह एक प्रेजेंटेशन और लर्निंग टूल है, न कि आर्किटेक्चर बनाने या चलाने की जगह, इसलिए डायग्राम को व्हाइटबोर्ड पर या अपने डिज़ाइन टूल में रखें। किसी भी विशिष्ट ऑथरिंग, फीडबैक या रिपोर्टिंग फ़ंक्शन पर भरोसा करने से पहले उसे अपने वर्कफ़्लो से मिला लें। फॉर्मेट चुनने के बारे में मार्गदर्शन के लिए, हमारा लेख देखें कि एडैप्टिव, इंटरैक्टिव और लाइव लर्निंग का उपयोग कब करना चाहिए ।

जो परिवर्तन हुआ उसे मापें

पहले से ही तय कर लें कि किन बातों से यह साबित होगा कि इंजीनियर बदलते हालात में भी आर्किटेक्चर का बचाव कर सकते हैं। किसी अनदेखे मामले में किए गए ट्रेड-ऑफ तर्क की तुलना प्रोग्राम शुरू होने से पहले लिए गए बेसलाइन से करें। यह तय करें कि इसमें कौन-कौन शामिल होंगे, हर मामले का आधार क्या होगा और इसका समय क्या होगा। अगर नतीजे बेहतर होते हैं, तो ट्रेनिंग का श्रेय देने से पहले देखें कि उसी अवधि में और क्या-क्या बदलाव हुए, जैसे कि नया डिज़ाइन रिव्यू टेम्प्लेट, स्टाफ में बदलाव या कोई ऐसी घटना जिसने सबका ध्यान खींचा हो।

वे बाधाएं जो बनी रह सकती हैं

• डिजाइन प्राधिकरण। यदि टीम निर्णय नहीं लेती है, तो उसका अभ्यास करने का सीमित प्रभाव होता है।
• पहर। एक काटा में घंटों लगते हैं; असली डिज़ाइन बनाने में हफ़्ते लगते हैं और इसमें ऐसे डेटा की आवश्यकता होती है जो काटा से प्राप्त नहीं किया जा सकता।
• मामले का विवरण। एक मामले में कुछ समझौते करने पड़ते हैं। स्कोर किसी इंजीनियर के सामान्य निर्णय को नहीं दर्शाता है।
• जटिलता। अधिक जटिलता का मतलब हमेशा बेहतर आर्किटेक्चर नहीं होता, इसलिए सबसे अधिक कंपोनेंट्स को प्राथमिकता न दें।
• स्थानांतरण। किसी कार्यशाला में अच्छा प्रदर्शन करना और किसी तनावपूर्ण समीक्षा में अच्छा प्रदर्शन करना एक जैसा नहीं होता, इसलिए काटा के बाद, वास्तविक परिवेश में अपने प्रदर्शन की जाँच करें।

इन समस्याओं के बारे में प्रायोजकों को पहले ही बता दें और अलग-अलग समाधानों की योजना बनाएं। काटा (Kata) इंजीनियरों की समझाने और बचाव करने की क्षमता को बेहतर बनाता है। यह अधिकार या समय प्रदान नहीं करता है।

ज़्यादातर पूछे जाने वाले सवाल

सिस्टम डिजाइन काटा क्या है?

एक संक्षिप्त, समयबद्ध डिज़ाइन अभ्यास जिसमें एक छोटी टीम किसी व्यावसायिक समस्या के लिए एक आर्किटेक्चर का खाका तैयार करती है, उसे अपने साथियों के सामने प्रस्तुत करती है और चुनौतीपूर्ण प्रश्नों के उत्तर देती है। इसे आर्किटेक्चर काटा भी कहा जाता है।

एक टीम में कितने लोग होने चाहिए?

मूल प्रारूप में 3 से 5 लोगों के छोटे समूह होते हैं, जो आमतौर पर एक कमरे में मौजूद 4 से 10 समूहों में से एक होते हैं। समूहों को इतना छोटा रखें कि हर कोई बोल सके।

आप सिस्टम डिजाइन काटा का मूल्यांकन कैसे करते हैं?

एक नया मामला प्रस्तुत करें और सहमत मानदंडों के आधार पर निर्णय लेने की प्रक्रिया और बदले हुए प्रतिबंध के प्रति प्रतिक्रिया का मूल्यांकन करें। साथियों की प्रतिक्रिया उपयोगी प्रतिक्रिया है, लेकिन यह अपने आप में कोई स्कोर नहीं है।

कहा से शुरुवात करे

अपने संगठन में बार-बार लिए जाने वाले किसी एक डिज़ाइन निर्णय को चुनें और उस पर एक पैराग्राफ का केस स्टडी लिखें। एक परिवर्तित बाधा जोड़ें, किसी इंजीनियरिंग मैनेजर से केस स्टडी और उत्तर मानदंडों का सत्यापन करवाएं, और गंभीर त्रुटियों की सूची के साथ तीन मानदंडों वाला एक रूब्रिक तैयार करें। इसे लागू करने से पहले एक टीम के साथ इसका पायलट परीक्षण करें।

यह देखने के लिए कि कैसे एक काटा को आपकी अपनी टीम के साथ लाइव चलाया जा सकता है, और बाद में स्व-गति से इसका पुन: उपयोग किया जा सकता है, AhaSlides देखें।