एक टीम ने एक क्षेत्रीय उत्सव के लिए टिकट बुकिंग सेवा का डिज़ाइन तैयार किया। यह अपेक्षित भार को आसानी से संभाल लेता है, और डिज़ाइन समीक्षा सर्वसम्मति से समाप्त हो जाती है। फिर निर्देश बदल जाते हैं: आयोजक अब वादा करता है कि टिकटों की बिक्री तब भी जारी रहनी चाहिए, जब बिक्री अवधि के दौरान एक डेटा सेंटर ऑफ़लाइन हो जाए। अब उसी डिज़ाइन में एक त्रुटि का खतरा है, और इसे तैयार करने वाले इंजीनियरों को यह तय करना होगा कि क्या बदलना है, क्या छोड़ना है और अपने इस निर्णय को कैसे समझाना है।
यह एक उदाहरण मात्र है, कोई दस्तावेजी घटना नहीं। यह वह स्थिति है जिसका अभ्यास करने के लिए सिस्टम डिज़ाइन काटा बनाया जाता है: एक डिज़ाइन जो पहले के प्रतिबंधों के तहत ठीक था, नए प्रतिबंधों के सामने आता है, और इंजीनियरों को कारणों सहित उसका बचाव या संशोधन करना होता है। यह मार्गदर्शिका इंजीनियरिंग इनेबलमेंट लीड्स और इंजीनियरिंग मैनेजर्स के लिए है। इसमें बताया गया है कि सिस्टम डिज़ाइन काटा क्या है, इसे कैसे बनाया जाता है, इसे कैसे चलाया और स्कोर किया जाता है, और प्रशिक्षण कब उपयोगी नहीं रह जाता। प्रत्येक मामले और मानदंड का उपयोग करने से पहले एक वरिष्ठ इंजीनियर द्वारा सत्यापन किया जाना चाहिए।
सिस्टम डिजाइन काटा क्या है?
सिस्टम डिज़ाइन काटा एक संक्षिप्त, समय-सीमाबद्ध डिज़ाइन अभ्यास है। एक छोटी टीम को एक पैराग्राफ में एक व्यावसायिक समस्या दी जाती है, वे एक आर्किटेक्चर का खाका तैयार करते हैं, उसे अपने साथियों के सामने प्रस्तुत करते हैं और कठिन प्रश्नों के उत्तर देते हैं। शोधकर्ता इसे आर्किटेक्चर काटा या आर्किटेक्चरल काटा भी कहते हैं। इस प्रारूप की शुरुआत टेड न्यूवार्ड ने एक कार्यशाला के रूप में की थी और इसके नियम और मॉडरेटर की भूमिका का दस्तावेजीकरण वेबसाइट पर उपलब्ध है। नील फोर्ड का वास्तुशिल्प कटास पृष्ठन्यूवार्ड का प्रेरक प्रश्न, जिसका उल्लेख वहां किया गया है, यह है कि संगठन महान वास्तुकारों को कैसे विकसित कर सकते हैं जब इंजीनियरों को अपने करियर में आधे दर्जन से भी कम बार आर्किटेक्ट बनने का मौका मिलता है। काटा उन्हें उत्पादन जोखिम के बिना अतिरिक्त अभ्यास प्रदान करता है।
त्वरित तथ्य
| सवाल | संक्षिप्त जवाब |
|---|---|
| कार्य क्या है? | किसी बाधा में परिवर्तन होने पर आर्किटेक्चर का बचाव करें। |
| समूह का आकार कितना होता है? | मूल प्रारूप में 3 से 5 लोगों के छोटे समूह होते हैं, जिनमें एक मॉडरेटर होता है। |
| आपका स्कोर क्या है? | समझौता संबंधी तर्क और एक नई बाधा के प्रति प्रतिक्रिया, यह सबसे सुंदर आरेख नहीं है। |
| क्या डिजाइन पैटर्न पर आधारित एक प्रश्नोत्तरी पर्याप्त है? | नहीं। यह पूर्वापेक्षाओं की पुष्टि करता है, लेकिन यह नहीं कि कोई इंजीनियर दबाव में अपने विकल्प को उचित ठहरा सकता है या नहीं। |
| इस मामले की पुष्टि कौन करता है? | एक इंजीनियरिंग मैनेजर या एक वरिष्ठ आर्किटेक्ट। |
| एक काटा किस चीज को ठीक नहीं कर सकता? | डिजाइन संबंधी अधिकार का अभाव, अस्पष्ट आवश्यकताएं और कार्यस्थल पर ठीक से डिजाइन करने के लिए समय की कमी। |
| आपको कैसे पता चला कि यह काम कर गया? | एक नए, अनदेखे मामले का मूल्यांकन सहमत मानदंडों के आधार पर किया गया, साथ ही वास्तविक डिजाइन समीक्षाओं पर अनुवर्ती कार्रवाई भी की गई। |
1. प्रदर्शन संबंधी समस्या का वर्णन करें।
विषय से नहीं, कार्य से शुरुआत करें। कार्य है बदलती परिस्थितियों में आर्किटेक्चर का बचाव करना। वास्तविक कार्य में यह डिज़ाइन समीक्षाओं, घटना अनुवर्ती कार्रवाईयों और नियोजन बैठकों में होता है, जहाँ आवश्यकताएँ बदलती रहती हैं: अधिक ट्रैफ़िक, उपलब्धता का कड़ा वादा, डेटा-रेजिडेंसी का नया नियम, या सीमित बजट।
कई इंजीनियर एक तर्कसंगत वास्तुकला का खाका खींच सकते हैं। लेकिन कम ही इंजीनियर यह बता पाते हैं कि दो लक्ष्यों के टकराव की स्थिति में वे किन चीजों का त्याग करेंगे और कौन से सबूत उनका निर्णय बदल देंगे। यही दूसरा कौशल है जिसका अभ्यास काटा में किया जाता है।
एक वाक्य में प्रदर्शन विवरण लिखें और किसी इंजीनियरिंग मैनेजर से इसकी जाँच करवाएँ: "किसी आर्किटेक्चर और बदले हुए प्रतिबंध को देखते हुए, इंजीनियर यह बताता है कि क्या गड़बड़ है, बदलाव का प्रस्ताव देता है, फायदे-नुकसान बताता है और यह भी बताता है कि उसे अभी क्या नहीं पता है।"
2. सीखने और संदर्भ संबंधी कमियों का निदान करें
कुछ भी बनाने से पहले, उस कार्य की तुलना अपने कार्यक्रम में वर्तमान में प्रचलित और मूल्यांकित की जाने वाली प्रक्रियाओं से करें।
- क्या अभ्यास में वास्तविक कार्य का उपयोग होता है? यदि प्रशिक्षण में केवल पैटर्न को अलग-अलग करके सिखाया जाता है और मूल्यांकन एक बहुविकल्पीय परीक्षा है, तो किसी ने भी अपने विकल्प का बचाव करने का अभ्यास नहीं किया है।
- संज्ञानात्मक आवश्यकता क्या है? ब्लूम के संशोधित वर्गीकरण में, विकल्पों की तुलना बाधाओं से करना विश्लेषण और मूल्यांकन के अंतर्गत आता है, और संशोधित डिज़ाइन प्रस्तावित करना सृजन के अंतर्गत आता है। हमारी मार्गदर्शिका ब्लूम के वर्गीकरण के अनुसार सीखने की गतिविधियों का मिलान करना यह दर्शाता है कि गतिविधि को उस स्तर से कैसे मिलाया जाए।
- क्या कौशल के अलावा कोई और चीज बाधा बन रही है? जाँच करें कि इंजीनियरों के पास डिज़ाइन करने का समय है या नहीं, क्या आर्किटेक्चर संबंधी निर्णय लेने की ज़िम्मेदारी किसी और की है और क्या आवश्यकताएँ लिखित रूप में मौजूद हैं। यदि कोई निर्णय टीम के बाहर के किसी व्यक्ति द्वारा लिया जाता है, तो किसी भी कार्रवाई से टीम के कार्यों में कोई बदलाव नहीं आएगा। उन समस्याओं को उन लोगों तक पहुँचाएँ जो उन्हें हल कर सकते हैं।
3. डिजाइन की तैयारी और अभ्यास
प्रत्येक चरण को एक अलग कार्य सौंपें।
तैयार करना। एक संक्षिप्त नैदानिक परीक्षण के साथ पूर्वापेक्षाओं की जाँच करें: आपकी टीम द्वारा उपयोग की जाने वाली शब्दावली (उपलब्धता, संगति, विलंबता, लागत), वे मूलभूत तत्व जिनकी उन्हें जानकारी होनी चाहिए, और आपका अपना डिज़ाइन समीक्षा टेम्पलेट। इस चरण में स्व-गति से अध्ययन करना उपयुक्त है, और एक पुनरावलोकन जाँच केवल पूर्वापेक्षाओं की पुष्टि करती है।
अभ्यास करें. काटा का अभ्यास करें। नील फोर्ड की वेबसाइट पर वर्णित प्रारूप के अनुसार, टीम बनने के बाद, अभ्यास तीन चरणों में चलता है: एक चर्चा चरण जहाँ टीम यह तय करती है कि वे क्या बना रहे हैं, एक सहकर्मी समीक्षा चरण जहाँ प्रत्येक टीम प्रस्तुति देती है और प्रश्नों के उत्तर देती है, और एक मतदान चरण जहाँ साथी "बहुत बढ़िया" ("शानदार"), "ठीक-ठाक" ("कुछ कमियाँ रह गईं") या "खराब") ("बहुत बड़ी चूक") देते हैं। कुछ नियम सीधे तौर पर अपनाने योग्य हैं: टीमें अपरिचित तकनीक के बारे में अनुमान लगा सकती हैं लेकिन उन्हें बताना होगा, और यह मानकर नहीं चल सकतीं कि वे सर्व-कुशल लोगों की टीम को काम पर रख सकती हैं।
परिवर्तन संबंधी बाधा जोड़ें। मानक काटा में एक निश्चित समस्या दी गई है। इस मार्गदर्शिका में कौशल का अभ्यास करने के लिए, बीच में एक दूसरा कार्ड जोड़ें: एक बदला हुआ प्रतिबंध जिसे टीम को स्वीकार करना होगा। यह हमारी डिज़ाइन संबंधी पसंद है, मूल नियमों का हिस्सा नहीं है, इसलिए इसका परीक्षण करें।
प्रतिक्रिया। फीडबैक को निर्णयों से जोड़ें, न कि कुल स्कोर से। "आपने दो क्षेत्रों में बदलाव किया, लेकिन यह नहीं बताया कि बदलाव के दौरान दिए गए ऑर्डर का क्या होगा" कहना "5 में से 3" कहने से कहीं अधिक उपयोगी है।
लाइव इनपुट या अतुल्यकालिक समीक्षा? लाइव मार्गदर्शन तब सबसे अधिक उपयोगी होता है जब कोई विकल्प अस्पष्ट हो और इंजीनियर किसी वरिष्ठ सहकर्मी से यह सीख सकें कि वे उस निर्णय पर क्यों अडिग रहेंगे। लिखित तर्क की तुलना व्याख्यात्मक उदाहरण से करने के लिए अतुल्यकालिक समीक्षा पर्याप्त है।
4. एक वास्तविक उदाहरण के माध्यम से काम करें
यह केवल उदाहरण के लिए है। उपयोग करने से पहले एक वरिष्ठ इंजीनियर को मामले और उत्तर के मानदंडों को सत्यापित करना चाहिए।
मामला। एक क्षेत्रीय उत्सव में सप्ताहांत में 20,000 टिकट बिक जाते हैं, जिनमें से अधिकांश बिक्री पहले दस मिनट में ही हो जाती है। ब्रीफ के पहले संस्करण में एक ऐसी बुकिंग सेवा की मांग की गई है जो इस चरम स्थिति को संभाल सके। डिज़ाइन में शामिल हैं: एक वेब स्तर, एक डेटाबेस और चेकआउट के समय भुगतान प्रदाता से संपर्क करने की सुविधा।
परिवर्तित प्रतिबंध। आयोजनकर्ता ने बीच में ही कहा: यदि कोई डेटा सेंटर ऑफलाइन हो जाता है तो भी बिक्री जारी रहनी चाहिए, और कोई भी टिकट दो बार नहीं बेचा जा सकता है।
पहला प्रयास। "दूसरा डेटा सेंटर जोड़ें और डेटाबेस की प्रतिकृति बनाएं।" टीम ने एक परिचित तरीके का सहारा लिया है, लेकिन यह नहीं बताया है कि जब दोनों साइटें एक-दूसरे से संवाद नहीं कर पाएंगी तो दोहरी बिक्री न करने के नियम का क्या होगा।
प्रतिक्रिया दें और पुनः प्रयास करें। प्रशिक्षक टीम से उन दो लक्ष्यों के नाम बताने को कहता है जो आपस में टकराव में हैं और यह भी कि नेटवर्क के टूटने की स्थिति में वे किस लक्ष्य की रक्षा करेंगे। पुनः प्रयास में उनसे विकल्प चुनने और यह बताने को कहा जाता है कि ग्राहक को कैसा अनुभव होता है।
एक और मजबूत प्रयास। "हम दोहरी बिक्री न करने के नियम का पालन करेंगे। विभाजन के दौरान, केवल प्राथमिक साइट ही टिकट बेचती है और दूसरी साइट पर प्रतीक्षा पृष्ठ दिखाया जाता है। हम थोड़े समय के लिए कम उपलब्धता स्वीकार करते हैं ताकि एक ही सीट दो बार न बेची जाए। हमने मान लिया है कि विभाजन दुर्लभ और अल्पकालिक होता है, और हम आयोजक से यह पुष्टि चाहेंगे कि प्रतीक्षा पृष्ठ स्वीकार्य है। यदि उन्हें दोनों साइटों पर बिक्री की आवश्यकता होती है, तो हम कुछ बिना बिके सीटों की कीमत पर, प्रत्येक साइट को पहले से ही अलग-अलग सीट ब्लॉक आवंटित करेंगे।" ध्यान दें कि यह उत्तर विवाद का नाम बताता है, एक पक्ष का चयन करता है, लागत बताता है और यह भी बताता है कि उसे क्या जानकारी नहीं है।
प्रत्येक प्रतिक्रिया तर्कसंगत है या अपूर्ण है? प्रत्येक का मूल्यांकन स्वीकृत मानदंडों के आधार पर करें, न कि समीक्षक द्वारा पसंद किए गए आर्किटेक्चर के आधार पर। पहले प्रयास में एक घटक का नाम दिया गया है, लेकिन उसके नुकसान या कमियों का उल्लेख नहीं किया गया है। बेहतर प्रयास विशिष्ट है, अपनी मान्यताओं को बताता है और उसकी कीमत के साथ एक विकल्प प्रस्तुत करता है।
5. क्षमता का आकलन करें और स्थानांतरण की योजना बनाएं
किसी इंजीनियर की क्षमता का प्रमाण उसके द्वारा पहले कभी न देखे गए नए मामले पर प्रदर्शन करना है। इसमें ट्रेड-ऑफ तर्क और नई बाधा के प्रति प्रतिक्रिया को अंक दिए जाते हैं। एक सरल मूल्यांकन मानदंड में प्रत्येक के लिए 0 से 2 तक का पैमाना उपयोग किया जाता है:
| कसौटी | प्रत्यक्ष साक्ष्य |
|---|---|
| कार्य निष्पादन | परिवर्तित बाधाओं के तहत वास्तुकला का बचाव करता है और निर्णय के पीछे के साक्ष्य को दर्ज करता है। |
| विचार | इसमें प्रासंगिक बाधाओं, विचारे गए विकल्पों और अनिश्चितताओं के बारे में बताया गया है। |
| सीमाएँ | स्वीकृत डिजाइन प्रक्रियाओं का पालन करता है और जानकारी या प्राधिकरण के अभाव में सहायता मांगता है। |
एंकर: 0 का अर्थ है अनुपस्थित या असमर्थित, 1 का अर्थ है प्रासंगिक कमियों के साथ आंशिक, और 2 का अर्थ है पूर्ण और सहमत मानदंडों के अनुसार उचित। गंभीर त्रुटियों को अलग से परिभाषित करें, जैसे कि किसी निर्दिष्ट सुरक्षा या डेटा-सुरक्षा आवश्यकता की अनदेखी करना, ताकि समग्र स्कोर किसी एक त्रुटि को छिपा न सके। यह मूल्यांकन मानदंड एक प्रस्ताव है, मान्य तैयारी मानक नहीं: इसे एक इंजीनियरिंग प्रबंधक के साथ अनुकूलित करें और इसका पायलट परीक्षण करें। हमारी मार्गदर्शिका उपयोगी प्रतिक्रिया के साथ इंटरैक्टिव अभ्यास डिजाइन करना इसमें यह बताया गया है कि निर्णयों से संबंधित प्रतिक्रिया कैसे लिखी जाए।
योजना का स्थानांतरण सोच-समझकर करें। काटा के बाद, प्रत्येक इंजीनियर से समीक्षा के लिए एक लाइव डिज़ाइन निर्णय लाने को कहें और उन पर वही प्रश्न लागू करें। किसी पिछली घटना की दोषरहित समीक्षा वास्तविक कार्य के लिए एक और अच्छा माध्यम है; हमारी मार्गदर्शिका देखें। निर्दोष घटना समीक्षा चलाना.
जहां इंटरैक्टिव डिलीवरी मददगार होती है
इंटरैक्टिव प्रारूप तब मददगार होते हैं जब समूह में शामिल होने से पहले सभी को अपनी सहमति देनी होती है। लाइव काटा सत्र में, एक फैसिलिटेटर बदली हुई बाधा को दिखा सकता है, प्रत्येक टीम सदस्य से यह पूछ सकता है कि वे क्या समझौता करेंगे और क्यों, और फिर चर्चा शुरू होने से पहले परिणाम बता सकता है। मूल प्रारूप के अंत में साथियों का मतदान भी इसी तरह आसानी से कराया जा सकता है। तैयारी के लिए या सत्र में शामिल न हो पाने वाले इंजीनियरों के लिए भी यही तरीका अपनाया जा सकता है। AhaSlides यह इंटरैक्टिव लर्निंग और लाइव व सेल्फ-पेस्ड डिलीवरी के बीच स्विच करने की सुविधा देता है। यह एक प्रेजेंटेशन और लर्निंग टूल है, न कि आर्किटेक्चर बनाने या चलाने की जगह, इसलिए डायग्राम को व्हाइटबोर्ड या अपने डिज़ाइन टूल में ही रखें। किसी भी विशिष्ट ऑथरिंग, फीडबैक या रिपोर्टिंग फ़ंक्शन पर निर्भर रहने की अपनी योजना को अपने वर्कफ़्लो से मिला लें। फ़ॉर्मेट चुनने के बारे में मार्गदर्शन के लिए, हमारा लेख देखें। अनुकूली, इंटरैक्टिव और लाइव लर्निंग का उपयोग कब करें.
जो परिवर्तन हुआ उसे मापें
पहले से ही तय कर लें कि किन बातों से यह साबित होगा कि इंजीनियर बदलते हालात में भी आर्किटेक्चर का बचाव कर सकते हैं। किसी अनदेखे मामले में किए गए ट्रेड-ऑफ तर्क की तुलना प्रोग्राम शुरू होने से पहले लिए गए बेसलाइन से करें। यह तय करें कि इसमें कौन-कौन शामिल होंगे, हर मामले का आधार क्या होगा और इसका समय क्या होगा। अगर नतीजे बेहतर होते हैं, तो ट्रेनिंग का श्रेय देने से पहले देखें कि उसी अवधि में और क्या-क्या बदलाव हुए, जैसे कि नया डिज़ाइन रिव्यू टेम्प्लेट, स्टाफ में बदलाव या कोई ऐसी घटना जिसने सबका ध्यान खींचा हो।
वे बाधाएं जो बनी रह सकती हैं
- डिजाइन प्राधिकरण। यदि टीम निर्णय नहीं लेती है, तो उसका अभ्यास करने का सीमित प्रभाव होता है।
- पहर। एक काटा में घंटों लगते हैं; असली डिज़ाइन बनाने में हफ़्ते लगते हैं और इसमें ऐसे डेटा की आवश्यकता होती है जो काटा से प्राप्त नहीं किया जा सकता।
- मामले का विवरण। एक मामले में कुछ समझौते करने पड़ते हैं। स्कोर किसी इंजीनियर के सामान्य निर्णय को नहीं दर्शाता है।
- जटिलता। अधिक जटिलता का मतलब हमेशा बेहतर आर्किटेक्चर नहीं होता, इसलिए सबसे अधिक कंपोनेंट्स को प्राथमिकता न दें।
- स्थानांतरण। किसी कार्यशाला में अच्छा प्रदर्शन करना और किसी तनावपूर्ण समीक्षा में अच्छा प्रदर्शन करना एक जैसा नहीं होता, इसलिए काटा के बाद, वास्तविक परिवेश में अपने प्रदर्शन की जाँच करें।
इन समस्याओं के बारे में प्रायोजकों को पहले ही बता दें और अलग-अलग समाधानों की योजना बनाएं। काटा (Kata) इंजीनियरों की समझाने और बचाव करने की क्षमता को बेहतर बनाता है। यह अधिकार या समय प्रदान नहीं करता है।
ज़्यादातर पूछे जाने वाले सवाल
सिस्टम डिजाइन काटा क्या है?
एक संक्षिप्त, समयबद्ध डिज़ाइन अभ्यास जिसमें एक छोटी टीम किसी व्यावसायिक समस्या के लिए एक आर्किटेक्चर का खाका तैयार करती है, उसे अपने साथियों के सामने प्रस्तुत करती है और चुनौतीपूर्ण प्रश्नों के उत्तर देती है। इसे आर्किटेक्चर काटा भी कहा जाता है।
एक टीम में कितने लोग होने चाहिए?
मूल प्रारूप में 3 से 5 लोगों के छोटे समूह होते हैं, जो आमतौर पर एक कमरे में मौजूद 4 से 10 समूहों में से एक होते हैं। समूहों को इतना छोटा रखें कि हर कोई बोल सके।
आप सिस्टम डिजाइन काटा का मूल्यांकन कैसे करते हैं?
एक नया मामला प्रस्तुत करें और सहमत मानदंडों के आधार पर निर्णय लेने की प्रक्रिया और बदले हुए प्रतिबंध के प्रति प्रतिक्रिया का मूल्यांकन करें। साथियों की प्रतिक्रिया उपयोगी प्रतिक्रिया है, लेकिन यह अपने आप में कोई स्कोर नहीं है।
कहा से शुरुवात करे
अपने संगठन में बार-बार लिए जाने वाले किसी एक डिज़ाइन निर्णय को चुनें और उस पर एक पैराग्राफ का केस स्टडी लिखें। एक परिवर्तित बाधा जोड़ें, किसी इंजीनियरिंग मैनेजर से केस स्टडी और उत्तर मानदंडों का सत्यापन करवाएं, और गंभीर त्रुटियों की सूची के साथ तीन मानदंडों वाला एक रूब्रिक तैयार करें। इसे लागू करने से पहले एक टीम के साथ इसका पायलट परीक्षण करें।
यह देखने के लिए कि कैसे एक काटा को आपकी अपनी टीम के साथ लाइव चलाया जा सकता है, और बाद में स्व-गति से इसका पुन: उपयोग किया जा सकता है, एक्सप्लोर करें AhaSlides.
