टीम सक्षमता और परिचालन उत्पादकता

स्क्रीन 1: ओरिएंटेशन: अंत तक आप क्या कर सकेंगे

मॉड्यूल · ओरिएंटेशन ओरिएंटेशन: अंत तक आप क्या कर सकेंगे

पहले चार मॉड्यूल ने आपको एक आर्किटेक्ट बनाया है जो एक स्टेकहोल्डर के पहले वाक्य से लेकर डिज़ाइन, एकीकरण, गवर्नेंस और हैंडऑफ तक एक डिप्लॉयमेंट ले जा सकता है। यह मॉड्यूल उस डिप्लॉयमेंट के चारों ओर की टीम के बारे में है: लोगों को Claude के साथ उत्पादक बनाना और एक बार सिस्टम लाइव होने के बाद उन्हें उत्पादक रखना।

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

यह मॉड्यूल सक्षमता के बारे में है

प्रत्येक पूर्व मॉड्यूल ने आपको Claude को कैसे बनाना और कॉन्फ़िगर करना है यह सिखाया। यह एक मानता है कि सिस्टम बनाया जा चुका है और पूछता है: एक टीम इसे कितनी अच्छी तरह अपनाती है, और यह हर समस्या में आपको खींचे बिना स्वस्थ कैसे रहता है? टीम सेटअप टीम को वातावरण, पुन: प्रयोज्य संपत्ति, और खर्च मुद्रा सही करने में मदद करता है इससे पहले कि कोई भी लॉगिन करे। डेवलपर वर्कफ़्लो गुणवत्ता की पट्टी को कम किए बिना टीम दिन-प्रतिदिन कैसे काम करता है इसे बढ़ाते हैं, और परिचालन समर्थन वह है जो आप करते हैं जब टीम सिस्टम के भीतर कुछ अप्रत्याशित का सामना करती है।

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

अस्वीकरण / शैक्षणिक सामग्री के लिए नोटिस

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

स्क्रीन 2: टीमों के लिए Claude टूलिंग और वातावरण को कॉन्फ़िगर करना

टीम सेटअप टीमों के लिए Claude टूलिंग और वातावरण को कॉन्फ़िगर करना

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

वातावरण को साझा कॉन्फ़िगरेशन के रूप में तैनात करें

एक टीम वातावरण एक साझा कॉन्फ़िगरेशन है: एक आधार रेखा जिससे हर डेवलपर शुरू करता है व्यक्तिगत सेटअप के एक सेट के बजाय। Claude Code के लिए, इसका मतलब है कि टीम एक प्रोजेक्ट-स्तरीय आधार रेखा पर सहमत होती है: एक साझा CLAUDE. md, सहमत उपकरण और MCP सर्वर का एक सेट, और एक अनुमति मुद्रा, ताकि लोग एक ही जगह से शुरू करें बजाय ad hoc सेटिंग्स की खोज करने और अलग होने के। वह आधार रेखा कुछ है जिसे आप समीक्षा कर सकते हैं, संस्करण कर सकते हैं, और सभी के लिए एक बार सुधार कर सकते हैं।

चैंपियन के माध्यम से रोलआउट करें, फिर बैच

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

कार्य उदाहरण

एक 200-व्यक्ति इंजीनियरिंग संगठन चार विभागों में Claude Code चाहता है। सभी चार को एक बार सक्षम करने के बजाय, आर्किटेक्ट प्रत्येक विभाग में एक चैंपियन को सक्षम करता है, उन्हें एक वास्तविक वर्कफ़्लो (जैसे, कोड-समीक्षा सहायता, एक परीक्षण-जनरेशन चरण) को परिवर्तित करने के लिए दो सप्ताह देता है, और प्रत्येक चैंपियन को अपनी पहली बैच के लिए एक 45-मिनट का सत्र चलाता है जिसमें उनके पांच सहकर्मी शामिल हैं। जब तक व्यापक रोलआउट होता है, हर विभाग के पास एक कार्यशील उदाहरण, एक स्थानीय विशेषज्ञ, और एक साझा CLAUDE. md होता है जिसे चैंपियन पहले से ही ट्यून कर चुका है। एक ही रोलआउट एक एकल सामूहिक ईमेल के रूप में प्रयास किया गया होता तो भ्रमित पहली बार के संकेतों की एक वृद्धि और शायद पुरानी आदतों में एक शांत पीछे हटना पैदा होता।

कौशल वितरण: पुन: प्रयोग का टीम-स्केल संस्करण

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

एक टीम को कौशल तैनात करने के चार तरीके हैं, और वे इस बात में भिन्न होते हैं कि इसे कौन एक्सेस कर सकता है और आप कितना नियंत्रण बनाए रखते हैं। एक मालिक-प्रावधानित कौशल, संगठन सेटिंग्स > कौशल के तहत अपलोड किया गया, संगठन में सभी के लिए एक बार उपलब्ध हो जाता है। यह सबसे सरल पथ है जब एक क्षमता वास्तव में सभी सदस्यों तक पहुंचनी चाहिए। जब कौशल केवल चुनिंदा सदस्यों तक पहुंचना चाहिए, आप एक या अधिक कौशल को एक प्लगइन में बंडल करते हैं और उस प्लगइन को एक समूह को असाइन करते हैं। केवल समूह के सदस्य ही उन कौशल को एक्सेस कर सकते हैं। प्लगइन भी वह जगह है जहां शासित वितरण रहता है: इंस्टॉल प्राथमिकताएं जैसे आवश्यक, डिफ़ॉल्ट रूप से स्थापित, उपलब्ध, या उपलब्ध नहीं, समूह लक्ष्यीकरण, और एक जुड़े हुए भंडार से संस्करण-नियंत्रित अपडेट। तीसरा तंत्र Claude Code प्रोजेक्ट कौशल है: फाइलसिस्टम कलाकृतियां जो प्रोजेक्ट भंडार (. claude/skills/) में रहती हैं, इसलिए वे भंडार के साथ संस्करण करते हैं और उन प्रोजेक्ट्स तक सीमित होते हैं जो उन्हें ले जाते हैं। चौथा API कौशल है, जिसे साथी के अपने उत्पादों द्वारा प्रोग्रामेटिक रूप से बुलाया जाता है। केंद्रीय रूप से प्रबंधित Claude Code कॉन्फ़िगरेशन एक अलग चैनल है: सर्वर-प्रबंधित सेटिंग्स Anthropic के सर्वर से वितरित की जाती हैं जब उपयोगकर्ता प्रमाणित करते हैं और एक घंटे की पोलिंग चक्र पर ताज़ा करते हैं - एक सेटिंग्स तंत्र, कौशल वितरण पथ नहीं।

कौशल वितरण तंत्र वितरण तंत्रसर्वश्रेष्ठ जबशासन और रोलबैक

संगठन-प्रावधानित कौशल (संगठन सेटिंग्स › कौशल)जब एक क्षमता संगठन में सभी तक पहुंचनी चाहिए।मालिक-प्रबंधित उपलब्धता और संगठन भर में हटाना; उपयोगकर्ता व्यक्तिगत कौशल को बंद कर सकते हैं लेकिन उन्हें हटा नहीं सकते। कोई संस्करण पिनिंग या मूल रोलबैक नहीं; अपडेट को मैनुअल रीअपलोड की आवश्यकता है। एक समूह / संगठन को असाइन किया गया प्लगइनजब एक प्रक्रिया या उपकरण सेट विशिष्ट टीमों तक पहुंचना चाहिए, या जिसे शासित रोलआउट की आवश्यकता है।समूह लक्ष्यीकरण, इंस्टॉल प्राथमिकताएं नियंत्रित करती हैं कि क्या कोई प्लगइन आवश्यक है, डिफ़ॉल्ट रूप से स्थापित है, या उपयोगकर्ताओं के लिए उपलब्ध है (वर्तमान प्रशासन UI के अनुसार सटीक लेबल, समर्थन लेख 13837433), और एक जुड़े हुए भंडार से संस्करण-नियंत्रित अपडेट। समूह-स्कोप्ड वितरण के लिए सबसे मजबूत शासन विकल्प। यह एक पूर्व संस्करण में वापस जाने का पथ रखने वाला एकमात्र तंत्र नहीं है: API कौशल स्पष्ट संस्करण पिनिंग का समर्थन करते हैं, और Claude Code प्रोजेक्ट कौशल उस भंडार के साथ रोलबैक करते हैं जो उन्हें ले जाता है। Claude Code प्रोजेक्ट कौशलजब एक उपकरण या सम्मेलन एक टीम अपने स्वयं के प्रोजेक्ट्स में साझा करता है।प्रोजेक्ट भंडार (. claude/skills/) में एक फाइलसिस्टम कलाकृति, भंडार के साथ संस्करण और उन प्रोजेक्ट्स तक सीमित जो इसे ले जाते हैं। API कौशल (संदेश API कंटेनर)जब एक क्षमता साथी के अपने उत्पादों द्वारा प्रोग्रामेटिक रूप से बुलाई जाती है।कॉलिंग सिस्टम में शासित; स्पष्ट संस्करण पिनिंग का समर्थन करता है; पुन: उपयोग मशीन-से-मशीन के बजाय मानव-सामना करने वाला है।

एक वितरणीय कौशल के रूप में एक टीम वर्कफ़्लो को पैकेज करना यह है कि एक अच्छी स्थानीय प्रथा कैसे एक टीम मानक बन जाती है। प्रक्रिया एक शासित कलाकृति के रूप में यात्रा करती है बजाय अनुलेखित ज्ञान के, और अपडेट पुन: समझाने के बजाय संस्करण के माध्यम से प्रचारित होते हैं।

पहले बिल से पहले खर्च मुद्रा सेट करें

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

सावधान रहें

कौशल जो कोई रास्ता वापस नहीं के साथ भेज दिया गया।

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

लागत · जटिलता · जोखिम

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

स्क्रीन 3: चेकपॉइंट: टीम वितरण रणनीति डिज़ाइन करें

टीम सेटअप · चेकपॉइंट चेकपॉइंट: टीम वितरण रणनीति डिज़ाइन करें

अभी कोशिश करें। नीचे दिए गए प्रत्येक परिदृश्य के लिए, चुनें कि टीम को पुन: प्रयोज्य संपत्ति कैसे प्राप्त करनी चाहिए, और उस कारक की पहचान करें जो उस तंत्र को सही बनाता है। एक सही तंत्र गलत कारण के साथ जोड़ा गया पास नहीं होता।

A एक अनुपालन-समीक्षा प्रक्रिया जो हर विभाग को समान रूप से चलानी चाहिए, जिसे केंद्रीय रूप से अपडेट किया जा सकता है और रोलबैक किया जा सकता है।

तंत्र चुनें... संगठन-प्रावधानित कौशल (संगठन सेटिंग्स › कौशल) Claude Code प्रोजेक्ट कौशल संगठन-व्यापी वितरित प्लगइन (या सभी प्रासंगिक समूहों को) API कौशल (संदेश API कंटेनर)

B एक क्षमता जो वास्तव में हर सदस्य के लिए उपलब्ध होनी चाहिए, संस्करण या रोलबैक की कोई आवश्यकता नहीं।

तंत्र चुनें... API कौशल (संदेश API कंटेनर) संगठन-प्रावधानित कौशल (संगठन सेटिंग्स › कौशल) संगठन-व्यापी वितरित प्लगइन Claude Code प्रोजेक्ट कौशल

C एक कोडिंग सम्मेलन और उपकरण सेट जो इंजीनियरिंग टीम को हर प्रोजेक्ट पर साझा करना चाहिए।

तंत्र चुनें... Claude Code प्रोजेक्ट कौशल API कौशल (संदेश API कंटेनर) संगठन-प्रावधानित कौशल इंजीनियरिंग समूह को वितरित प्लगइन

D एक पुन: प्रयोज्य क्षमता जो साथी के अपने कई उत्पादों को प्रोग्रामेटिक रूप से बुलानी चाहिए।

तंत्र चुनें... संगठन-व्यापी वितरित प्लगइन Claude Code प्रोजेक्ट कौशल API कौशल (संदेश API कंटेनर) संगठन-प्रावधानित कौशल

चयन की जांच करें अभी के लिए छोड़ें

स्क्रीन 4: AI टूलिंग के साथ डेवलपर वर्कफ़्लो में सुधार करना

डेव वर्कफ़्लो AI टूलिंग के साथ डेवलपर वर्कफ़्लो में सुधार करना

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

सहायता को मौजूदा वर्कफ़्लो में एकीकृत करें

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

प्रत्येक वर्कफ़्लो चरण पर Claude कहां मदद करता है, और समीक्षा अनुशासन जो इसे अभी भी चाहिए वर्कफ़्लो चरणClaude कहां मदद कर सकता हैसमीक्षा अनुशासन जो इसे अभी भी चाहिए

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

दो विफलता मोड बार-बार दिखाई देते हैं

1अनियमित अपनाना: यह तब होता है जब कुछ डेवलपर्स AI टूलिंग को भारी रूप से उपयोग करते हैं और बाकी इसे मुश्किल से छूते हैं, इसलिए टीम कभी भी उपकरण का वास्तविक लाभ नहीं समझती है और अभ्यास कभी मानकीकृत नहीं होता है। पिछले विषय से चैंपियन-और-बैच रोलआउट इसे से बचने का एक शानदार तरीका है: यह उपयोग को जानबूझकर फैलाता है बजाय इसे सभी को प्रारंभिक अपनाने वालों के लिए छोड़ने के। 2बुनियादी चैट पर रुकना: टीम Claude को एक प्रश्न-उत्तर बॉक्स के रूप में उपयोग करती है और कभी भी उच्च-मूल्य वर्कफ़्लो जैसे उपकरण उपयोग, भंडार-जागरूक सहायता, पैकेज किए गए कौशल में आगे नहीं बढ़ती क्योंकि किसी ने उन्हें पहले कदम से आगे सक्षम नहीं किया। एक टीम को एक्सेस प्रदान करना अपनाना नहीं है; आपको वर्तमान वर्कफ़्लो के भीतर वास्तविक सक्षमता के लिए कॉन्फ़िगर करने की आवश्यकता है।

परिश्रम: अनुशासन जो AI-जनित कार्य को विश्वसनीय रखता है

परिश्रम चार AI Fluency दक्षताओं में से एक है। Anthropic इसे AI के साथ हम क्या करते हैं और कैसे करते हैं इसके लिए जिम्मेदारी लेने के रूप में परिभाषित करता है। डिप्लॉयमेंट परिश्रम विशेष रूप से हम जो आउटपुट उपयोग या साझा करते हैं उसे सत्यापित और वाउच करने की जिम्मेदारी लेने का मतलब है। डेवलपर वर्कफ़्लो पर लागू किया गया, वह जिम्मेदारी एक ठोस आदत के रूप में दिखाई देती है: AI-जनित कोड को किसी भी अन्य कोड के समान मानकों पर रखना, जिसका अर्थ है सही, सुरक्षा, और रखरखाव, और सूक्ष्म विफलता के लिए देखना जहां इंजीनियर आउटपुट स्वीकार करते हैं जिसे वे अब पूरी तरह से समझते नहीं हैं क्योंकि यह सही दिखता है और एक जांच पास करता है।

ठोस डिलीवरेबल जो परिश्रम उत्पन्न करता है वह एक सत्यापन चेकलिस्ट है: ठीक सेट जांच जो एक AI-जनित आउटपुट को उत्पादन तक पहुंचने से पहले पास करनी चाहिए। यह सत्यापन चेकलिस्ट कुछ है जो एक टीम अपनी विशिष्ट आवश्यकताओं के आधार पर आंतरिक रूप से उत्पन्न करती है। चेकलिस्ट में सवाल होने चाहिए जो सत्यापन के सभी चार आयामों को संबोधित करते हैं: सही, सुरक्षा, रखरखाव, और मानव समझ।

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

सावधान रहें

विलय जिसे कोई समझा नहीं सकता।

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

लागत · जटिलता · जोखिम

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

स्क्रीन 5: व्यायाम: सत्यापन चेकलिस्ट परिभाषित करें

डेव वर्कफ़्लो · व्यायाम व्यायाम: सत्यापन चेकलिस्ट परिभाषित करें

अभी कोशिश करें। सत्यापन चेकलिस्ट लिखें जो AI-जनित कोड को उत्पादन से पहले पास करनी चाहिए। नीचे दिए गए चार आयामों में से प्रत्येक के लिए, अपने शब्दों में एक ठोस जांच लिखें। अपनी चेकलिस्ट लिखें, फिर नीचे मॉडल उत्तर प्रकट करें।

सही

सुरक्षा

रखरखाव

मानव समझ

मॉडल उत्तर प्रकट करें

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

चेकलिस्ट पूर्ण चिह्नित करें अभी के लिए छोड़ें

स्क्रीन 6: डिबगिंग और परिचालन समस्या समाधान का समर्थन करना

परिचालन समर्थन डिबगिंग और परिचालन समस्या समाधान का समर्थन करना

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

समर्थन भूमिका अनुवाद है, अग्निशमन नहीं

जब एक परिचालन समस्या उतरती है, टीम आमतौर पर एक लक्षण की पहचान करती है, कारण नहीं। उदाहरण के लिए, वे नोट करेंगे कि विलंबता बढ़ी, आउटपुट गिरावट आई, या एक उपकरण विफल होने लगा। टीम फिर आर्किटेक्ट को खींचती है, जिसका मूल्य परिचालन लक्षण को इसके आर्किटेक्चर कारण से जोड़ना है: वही निदान अनुशासन मॉड्यूल 2 उत्पादन प्रणालियों के लिए बनाया गया, अब एक टीम के समर्थन में लागू किया गया जो डिप्लॉयमेंट के मालिक हैं। एक घटना को स्वयं हल करना अग्निशमन है; टीम को लक्षण-से-कारण पथ सिखाना जो वे भविष्य में फिर से अनुसरण कर सकते हैं समर्थन है जो रहता है।

लक्षणों को आर्किटेक्चर कारणों से जोड़ें

कई परिचालन लक्षण आर्किटेक्चर कारणों के एक छोटे सेट को ट्रेस करते हैं। इन्हें पहचानना टीम को स्पष्ट रूप से तर्क करने की अनुमति देता है कि वे क्या देखते हैं से जहां देखना है। लक्षण → संभावित आर्किटेक्चर कारण → पहली कार्रवाई लक्षणसंभावित आर्किटेक्चर कारणपहली कार्रवाई

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

आत्मनिर्भरता बनाएं: रनबुक और एस्केलेशन पथ

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

सावधान रहें

बहाव जो त्रैमासिक समीक्षा के लिए प्रतीक्षा करता था।

एक समर्थन टीम ने एक पूरे त्रैमासिक के लिए एक डिप्लॉयमेंट के डैशबोर्ड को हरा रहते देखा जबकि उत्तर गुणवत्ता शांति से स्लाइड कर गई। किसी ने धीमी गिरावट को इसके कारण से नहीं जोड़ा: एक बढ़ता हुआ पुनर्प्राप्ति कॉर्पस जिसके साथ सूचकांक नहीं रहा था। लक्षण पूरे समय दृश्यमान थे, लेकिन रनबुक प्रविष्टि जो कहती है कि कोई कोड परिवर्तन के साथ धीमी गिरावट मॉडल, संकेत, या पुनर्प्राप्ति बहाव की ओर इशारा करती है गायब थी। उस पथ के साथ लिखा, एक पहली पंक्ति इंजीनियर समस्या को एक दोपहर में हल कर सकता था; लेकिन इसके बिना, यह एक समीक्षा के लिए प्रतीक्षा करता है।

लागत · जटिलता · जोखिम

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

स्क्रीन 7: मॉड्यूल क्विज़

मॉड्यूल · क्विज़ मॉड्यूल क्विज़

तीन विषयों में पांच परिदृश्य प्रश्न। सर्वश्रेष्ठ उत्तर चुनें; प्रतिक्रिया सिद्धांत का नाम देती है।

प्रश्न 1 · टीम सेटअप एक टीम चार विभागों में एक बार Claude को रोल आउट कर रही है और अपनाना असमान है। अगली सर्वश्रेष्ठ कदम क्या है?

Aहर किसी के लिए दैनिक उपयोग लक्ष्य अनिवार्य करें। Bप्रत्येक विभाग में एक चैंपियन को सक्षम करें पहले, वर्कफ़्लो को साबित करें, फिर बैच में अपनाने को बीज दें। Cप्रतीक्षा करें जब तक प्रत्येक विभाग मदद के लिए पूछे। Dसभी को सबसे मजबूत मॉडल दें उपयोग को प्रोत्साहित करने के लिए।

प्रश्न 2 · कौशल वितरण एक प्रक्रिया को हर विभाग द्वारा समान रूप से चलाया जाना चाहिए और एक जगह से रद्द किया जा सकता है। इसे कैसे वितरित किया जाना चाहिए?

Aहर टीम के चैट में एक संकेत के रूप में चिपकाया गया। Bसभी विभागों को वितरित एक संगठन-प्रबंधित प्लगइन में बंडल किया गया, समूह/संगठन लक्ष्यीकरण, संस्करण-नियंत्रित अपडेट, और रोलबैक के साथ। Cएक टीम के भंडार में एक Claude Code प्रोजेक्ट कॉन्फ़िग। Dलोगों को अनुसरण करने के लिए एक दस्तावेज़ के रूप में ईमेल किया गया।

प्रश्न 3 · डेवलपर वर्कफ़्लो एक टीम तेजी से AI-सहायता प्राप्त कोड भेज देती है लेकिन एक सुरक्षा समस्या फिसल जाती है। सबसे अधिक संभावना क्या गायब था?

Aएक कोड-समीक्षा SLA जो छोटे AI-जनित परिवर्तनों को सुरक्षा समीक्षा से छूट देता है। Bएक लिंटर विलय से पहले ज्ञात कमजोरी पैटर्न को फ्लैग करने के लिए कॉन्फ़िगर किया गया। Cएक सत्यापन चेकलिस्ट जो AI-जनित कोड को उत्पादन से पहले पास करनी चाहिए, जिसमें एक सुरक्षा आयाम शामिल है। Dहाल के सुरक्षा पैटर्न को शामिल करने के लिए अधिक बार मॉडल अपडेट।

प्रश्न 4 · निर्णय समीक्षा में, एक डेवलपर यह समझा नहीं सकता कि एक AI-जनित परिवर्तन एक इनपुट को उस तरह से क्यों संभालता है, लेकिन परीक्षण पास करते हैं। क्या होना चाहिए?

Aइसे विलय करें; परीक्षण हरे हैं। Bइसे तब तक रखें जब तक लेखक व्यवहार और इसके तर्क को समझा सके, मानव-समझ जांच। Cपरीक्षण हटाएं और हाथ से फिर से लिखें। Dहर विलय के लिए आर्किटेक्ट को एस्केलेट करें।

प्रश्न 5 · परिचालन समर्थन एक लाइव डिप्लॉयमेंट पर आउटपुट गुणवत्ता दो महीने में गिरी है कोई कोड परिवर्तन के साथ। आर्किटेक्ट पहले कहां देखता है?

Aमॉडल स्तर बढ़ाएं; एक अधिक सक्षम मॉडल पुनर्प्राप्ति अंतराल के लिए क्षतिपूर्ति करेगा। Bएक मॉडल या संकेत परिवर्तन, या पुनर्प्राप्ति बहाव जैसे कॉर्पस बढ़ा, लक्षण को एक आर्किटेक्चर कारण से जोड़ें। Cहर कॉल ताजा सामग्री खींचने के लिए कैशिंग को अक्षम करें। Dअंतिम कोड डिप्लॉयमेंट को रोल बैक करें और एकीकरण परीक्षण फिर से चलाएं।

क्विज़ जमा करें अभी के लिए छोड़ें

स्क्रीन 8: शब्दावली

समाप्ति · संदर्भ शब्दावली

इस मॉड्यूल में उपयोग की गई मुख्य शर्तें, वर्णक्रम क्रम में। एक शब्द को विस्तारित करने के लिए क्लिक करें।

चैंपियन-प्रति-विभाग रोलआउटएक अपनाने का पैटर्न जो पहले प्रति टीम एक चैंपियन को सक्षम करता है वर्कफ़्लो को साबित करने के लिए, फिर बैच दर बैच अपनाने को बीज देता है। एस्केलेशन पथएक नाम परिभाषा कि कौन क्या संभालता है और कब एक परिचालन समस्या टीम को छोड़ देती है। रनबुकज्ञात लक्षण-से-कारण-से-कार्रवाई पथों का एक कैप्चर किया गया सेट जो एक टीम को आर्किटेक्ट के बिना आवर्ती परिचालन समस्याओं को हल करने देता है। साझा कॉन्फ़िगरेशनएक एकल टीम आधार रेखा (उदाहरण के लिए एक प्रोजेक्ट CLAUDE. md, सहमत उपकरण, और अनुमति मुद्रा) जो हर सदस्य से शुरू करता है, व्यक्तिगत सेटअप के बजाय जो अलग हो जाते हैं। कौशल वितरणचार तंत्रों में से एक के माध्यम से सही लोगों के सामने एक कौशल प्राप्त करना, प्रत्येक के साथ अलग एक्सेस, संस्करण, और रोलबैक व्यवहार: संगठन-व्यापी उपलब्धता के लिए संगठन सेटिंग्स > कौशल में मालिक-प्रावधानित कौशल; समूह और संगठन लक्ष्यीकरण के लिए एक समूह या संगठन को असाइन किए गए प्लगइन संस्करण-नियंत्रित अपडेट और रोलबैक के साथ; एक टीम के लिए भंडार के साथ संस्करणित Claude Code प्रोजेक्ट कौशल; और स्पष्ट संस्करण पिनिंग के साथ प्रोग्रामेटिक पुन: उपयोग के लिए API कौशल। खर्च मुद्रामॉडल डिफ़ॉल्ट, मॉडल अनुमति सूची और प्रतिबंध, प्रयास मार्गदर्शन, और खर्च, दर, और प्रति-उपयोगकर्ता कैप टीम कॉन्फ़िगरेशन के भाग के रूप में सेट करें खपत को सीमा के भीतर रखें। सत्यापन चेकलिस्टठीक सेट सही, सुरक्षा, रखरखाव, और मानव-समझ जांच जो एक AI-जनित आउटपुट को उत्पादन से पहले पास करनी चाहिए।

स्क्रीन 9: पुनरावृत्ति: चार चीजें जो यहां सब कुछ में रखती हैं

मॉड्यूल · पुनरावृत्ति पुनरावृत्ति: चार चीजें जो यहां सब कुछ में रखती हैं

01

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

02

अपनाना चैंपियन और बैच के माध्यम से इंजीनियर किया जाता है एक चैंपियन प्रति टीम वर्कफ़्लो को साबित करता है और अपनाने को बीज देता है; एक्सेस के बिना सक्षमता बुनियादी चैट पर रुक जाती है, और अनियमित अपनाना कभी लाभ को मानकीकृत नहीं करता है।

03

परिश्रम AI-सहायता प्राप्त कार्य को विश्वसनीय रखता है AI-जनित कोड को सही, सुरक्षा, और रखरखाव मानकों पर रखें, और आवश्यकता है कि लेखक समझा सके कि क्या भेज दिया गया, एक सत्यापन चेकलिस्ट के रूप में कैप्चर किया गया जो उत्पादन से पहले गेट करता है।

04

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

यह आर्किटेक्ट ट्रैक को पूरा करता है। आप एक डिप्लॉयमेंट को एक स्टेकहोल्डर के पहले वाक्य से लेकर डिज़ाइन, एकीकरण, गवर्नेंस, हैंडऑफ, और इसे अपनाने और चलाने वाली टीम को वितरित कर सकते हैं।

स्रोत

Anthropic Skilljar, Claude API के साथ निर्माण: उपकरण उपयोग, API एकीकरण यांत्रिकी, और आधार रेखा कौशल अवधारणाएं टीम वितरण में ले जाई गई। Claude Code कॉन्फ़िगरेशन दस्तावेज़ (code. claude. com): CLAUDE. md निर्देश बनाम लागू करने योग्य सेटिंग्स, अनुमति, हुक, MCP, और प्रबंधित सेटिंग्स। Claude Code कौशल और संगठन कौशल प्रावधान दस्तावेज़: कौशल पैकेज संरचना, प्रोजेक्ट कौशल, प्लगइन-आधारित वितरण, और मालिक-प्रावधानित संगठन-व्यापी उपलब्धता। संगठन प्लगइन प्रबंधन (support. code. com): प्लगइन बाजार, समूह असाइनमेंट, इंस्टॉल प्राथमिकताएं, आवश्यक/डिफ़ॉल्ट इंस्टॉल, छिपाएं/हटाएं व्यवहार, मैनुअल अपलोड, Github सिंक, अपडेट, और हटाने यांत्रिकी।

स्क्रीन 10: बधाई! आपने इस मॉड्यूल को सफलतापूर्वक पूरा कर लिया है।

मॉड्यूल पूर्ण · आर्किटेक्ट · 2 मिनट बधाई! आपने इस मॉड्यूल को सफलतापूर्वक पूरा कर लिया है। मॉड्यूल 5 टीम टूलिंग कॉन्फ़िगरेशन, डेवलपर वर्कफ़्लो डिज़ाइन, और परिचालन समर्थन प्रथाओं को कवर करता है जो एक बार डिप्लॉयमेंट लाइव होने के बाद AI उत्पादकता को बनाए रखते हैं। एक डिप्लॉयमेंट जिसे टीम संचालित, डिबग, और सुधार नहीं कर सकती वह उत्पादक नहीं रहेगी; आपके पास अब इसे चलाते रहने के पैटर्न हैं।

0 0 चेकपॉइंट में से पास किए गए

M1

Claude प्लेटफॉर्म और समाधान डिज़ाइन मॉडल चयन, संकेत आर्किटेक्चर, उपकरण डिज़ाइन, और प्लेटफॉर्म-परत ट्रेडऑफ।

M2

एंटरप्राइज एकीकरण और उत्पादन डिप्लॉयमेंट पैटर्न, एकीकरण आर्किटेक्चर, और उत्पादन विश्वसनीयता।

M3

जिम्मेदार AI, सुरक्षा और जोखिम सुरक्षा ढांचे, जोखिम पहचान, और गवर्नेंस प्रथाएं।

M4

स्टेकहोल्डर एनगेजमेंट, जीवनचक्र और गो-टू-मार्केट स्टेकहोल्डर संचार, जीवनचक्र प्रबंधन, और गो-टू-मार्केट रणनीति।

M5

टीम सक्षमता और परिचालन उत्पादकता टीम टूलिंग कॉन्फ़िगरेशन और परिचालन समर्थन प्रथाएं।

आप यहां हैं

मॉड्यूल की समीक्षा करें फिर से शुरू करें