12.6

View in English

12.6 अपनाने का रोडमैप

यह परिशिष्ट इस पुस्तक के अभ्यासों को वृद्धिशील रूप से लागू करने के लिए एक व्यावहारिक मार्गदर्शिका है। पूरी गाइडबुक में सबसे महत्वपूर्ण निर्देश, जो हर अध्याय में दोहराया गया है, है वृद्धिशील रूप से अपनाएँ; बड़ा-धमाका न करें। एक ऐसा परिवर्तन जो एक साथ सब कुछ बदलने की कोशिश करता है वह कुछ भी टिकाऊ रूप से नहीं बदलता: यह सद्भावना को समाप्त कर देता है, टीमों को अभिभूत कर देता है, और पहले संकट में ही ढह जाता है। एक ऐसा परिवर्तन जो वास्तविक पीड़ा से शुरू होता है, एक दृश्यमान जीत देता है, और वहाँ से जटिल होता जाता है, वह हज़ारों के एक संगठन को कुछ वर्षों में आगे बढ़ा सकता है।

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

अपनाने के सिद्धांत

ये सिद्धांत आपके आकार, क्षेत्र, या शुरुआती परिपक्वता की परवाह किए बिना लागू होते हैं।

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

परिपक्वता-आधारित क्रमबद्धता

नीचे दिए गए क्षितिज संचयी हैं: प्रत्येक पिछले पर आधारित है। तारीख़ें मार्गदर्शन हैं, समय सीमाएँ नहीं; एक बड़ा या भारी रूप से नियमित संगठन प्रत्येक चरण को लंबा चला सकता है। पैटर्न (स्थिर करें, फिर मानकीकृत करें, फिर स्केल करें, फिर बनाए रखें) गति की परवाह किए बिना कायम रहता है।

पहले 90 दिन: स्थिर करें और साबित करें

लक्ष्य: एक आधाररेखा स्थापित करें, एक या दो फ़्लैगशिप समस्याएँ चुनें, और एक इच्छुक टीम के साथ एक विश्वसनीय पहली जीत दें।

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

6 महीने तक: जीतने वाले पैटर्न को मानकीकृत करें

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

  • पायलट से गोल्डन पाथ को पुन: प्रयोज्य टेम्पलेट, पाइपलाइन, और दस्तावेज़ीकरण के रूप में प्रकाशित करें।
  • पक्की सड़क की मालिकी और सहायता के लिए एक प्लेटफ़ॉर्म या सक्षम करने वाली टीम (यहाँ तक कि एक वर्चुअल टीम) स्थापित करें।
  • प्रभाव और तैयारी के अनुसार प्राथमिकता देते हुए पैटर्न को तीन से पाँच और टीमों तक फैलाएँ।
  • स्वचालित गुणवत्ता और सुरक्षा गेट (लिंटिंग, टेस्ट, SAST/SCA) को साझा पाइपलाइन में डिफ़ॉल्ट के रूप में शामिल करें, ऐड-ऑन के रूप में नहीं।
  • एक दोषरहित घटना-समीक्षा अभ्यास शुरू करें और आंतरिक रूप से पोस्टमॉर्टम प्रकाशित करें।
  • एक हल्का गवर्नेंस मंच (आर्किटेक्चर समीक्षा, पक्की-सड़क प्रबंधन) स्थापित करें जो गेटकीपिंग के बजाय रुकावटें दूर करे।

12 महीने तक: पूरे संगठन में स्केल करें

लक्ष्य: पक्की सड़क को अधिकांश नए काम के लिए डिफ़ॉल्ट बनाएँ और सबसे बुरे लेगेसी अभ्यासों को सेवानिवृत्त करना शुरू करें।

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

2+ वर्ष: लगातार बनाए रखें और सुधारें

लक्ष्य: अभ्यास “हम कैसे काम करते हैं” बन जाते हैं, कोई कार्यक्रम नहीं, और संगठन केंद्रीय धक्के के बिना उन्हें सुधारता है।

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

एक प्राथमिकता फ्रेमवर्क

आपके पास हमेशा उन्हें करने की क्षमता से अधिक सुधार होंगे। कमरे में सबसे ऊँची आवाज़ के बजाय एक सरल, बचाव योग्य मॉडल के साथ प्राथमिकता दें।

प्रत्येक उम्मीदवार पहल को तीन आयामों पर स्कोर करें:

  • प्रभाव (1–5): यह किसी वास्तविक परिणाम (डिलीवरी गति, विश्वसनीयता, सुरक्षा, लागत, या उपयोगकर्ता मूल्य) को कितना सुधारेगा, और कितनी टीमों या उपयोगकर्ताओं के लिए?
  • प्रयास (1–5): इसे देने में कितना काम, समन्वय, और व्यवधान लगेगा? (अधिक = अधिक प्रयास।)
  • जोखिम भार (0.5–2.0): तात्कालिकता और उजागरण के लिए एक गुणक। सुरक्षा, अनुपालन, और सुरक्षा मुद्दे अधिक भार रखते हैं; अच्छे-से-होने वाली चीज़ें कम रखती हैं।

एक उपयोगी रैंकिंग स्कोर है:

Priority = (Impact × Risk weight) ÷ Effort

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

कार्यान्वित उदाहरण

पहलप्रभावप्रयासजोखिम भारप्राथमिकताक्रम
शीर्ष राजस्व सेवा के लिए परिनियोजन स्वचालित करें521.53.75अभी
टियर-1 सेवाओं में SLO और अलर्टिंग जोड़ें421.53.00अभी
साझा पाइपलाइन में SAST/SCA शामिल करें422.04.00अभी
सभी फ्रंट एंड में एक डिज़ाइन सिस्टम रोल आउट करें451.00.80बाद में
मेनफ़्रेम बैच को क्लाउड में माइग्रेट करें551.51.50चरणबद्ध
टीमों में ADR को मानकीकृत करें311.03.00अभी (त्वरित जीत)
संगठन-व्यापी एक नई प्रोग्रामिंग भाषा अपनाएँ250.50.20टालें

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

डोमेन-दर-डोमेन त्वरित जीत

पुस्तक के हर हिस्से में एक कम-लागत, उच्च-संकेत पहला कदम है। यहाँ से शुरू करें।

भाग“यहाँ से शुरू करें” त्वरित जीत
बुनियादी बातें (संस्कृति, टीमें, प्रक्रिया)हल्के ADR अपनाएँ और एक दोषरहित रेट्रोस्पेक्टिव चलाएँ; निर्णयों और सीखने को दृश्यमान बनाएँ।
प्रोग्रामिंग शिल्पCI में एक ऑटो-फ़ॉर्मेटर और लिंटर को लागू डिफ़ॉल्ट के रूप में चालू करें, ताकि शैली समीक्षा का विषय बनना बंद हो जाए।
आर्किटेक्चरअपने सबसे महत्वपूर्ण सिस्टम के लिए एक-पृष्ठ का आर्किटेक्चर निर्णय और एक C4 कॉन्टेक्स्ट आरेख लिखें।
सुरक्षापाइपलाइन में निर्भरता स्कैनिंग (SCA) और सीक्रेट स्कैनिंग जोड़ें; इन्हें पहले एक महत्वपूर्ण रिपॉज़िटरी के लिए सक्षम करें।
UX / डिज़ाइनअपने सबसे अधिक-ट्रैफ़िक वाले फ़्लो पर तीन सस्ते उपयोगिता परीक्षण चलाएँ; जो शीर्ष मुद्दा आप देखते हैं उसे ठीक करें।
AI / MLकिसी भी मॉडल काम से पहले एक-पृष्ठ की समस्या फ़्रेमिंग और डेटा-तैयारी जाँच लिखें; परिभाषित करें कि आप सफलता का मूल्यांकन कैसे करेंगे।
डेटा / एनालिटिक्सएक एकल सहमत “नॉर्थ-स्टार” मीट्रिक और एक भरोसेमंद डैशबोर्ड परिभाषित करें; किसी परस्पर विरोधी को सेवानिवृत्त करें।
DevOps / प्लेटफ़ॉर्मएक टीम को पूरी तरह स्वचालित बिल्ड-टेस्ट-डिप्लॉय पाइपलाइन तक पहुँचाएँ और इसे टेम्पलेट के रूप में दस्तावेज़ीकृत करें।
संचालन / विश्वसनीयताअपनी सबसे महत्वपूर्ण उपयोगकर्ता यात्रा के लिए SLI और एक SLO परिभाषित करें; कारणों पर नहीं, लक्षणों पर अलर्ट करें।
एंटरप्राइज़ / सरकारअपने वर्तमान नियंत्रणों को एक फ्रेमवर्क (NIST CSF, ISO 27001, या SOC 2) से मैप करें और एक नियंत्रण के लिए सबूत स्वचालित करें।

एंटरप्राइज़ के लिए विशेष मार्गदर्शन

बड़े स्थापित संगठन पैमाना, कई टीमें, गहरा लेगेसी, और भारी परिवर्तन-प्रबंधन ओवरहेड लेकर चलते हैं। रोडमैप को तदनुसार अनुकूलित करें।

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

सरकार के लिए विशेष मार्गदर्शन

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

  • पहले दिन से ATO के लिए डिज़ाइन करें। संचालन प्राधिकरण और सतत निगरानी गेट (NIST RMF / 800-37 के अनुसार) समयरेखाओं पर हावी हो सकते हैं। सुरक्षा नियंत्रण और सबूत संग्रह को पाइपलाइन में जल्दी बनाएँ ताकि अनुपालन सतत हो, देर से आने वाली, अवरुद्ध करने वाली हड़बड़ी न हो।
  • वृद्धिशील रूप से ख़रीदें। बहु-वर्षीय, बड़े-धमाके वाली खरीद उस बड़े-धमाके की विफलता को संस्थागत बनाती है जिसके ख़िलाफ़ यह पुस्तक चेतावनी देती है। मॉड्यूलर अनुबंध, छोटे पुरस्कार, और परिणाम-आधारित कार्य विवरण को प्राथमिकता दें जो पुनरावृत्ति की अनुमति दें।
  • विक्रेताओं और एकीकरणकर्ताओं को टीम के हिस्से के रूप में प्रबंधित करें। अधिकांश सरकारी इंजीनियरिंग ठेकेदारों द्वारा दी जाती है। पक्की सड़कें, गुणवत्ता गेट, और पारदर्शिता आवश्यकताओं को अनुबंधों में लिखें, और लॉक-इन व बस-फ़ैक्टर जोखिम से बचने के लिए सरकार को ज्ञान और कोड हस्तांतरण सुनिश्चित करें।
  • वित्तपोषण चक्रों के आस-पास योजना बनाएँ। बहु-वर्षीय और वार्षिक विनियोग यह सीमित करते हैं कि आप किसके प्रति प्रतिबद्ध हो सकते हैं। काम को इस तरह क्रमबद्ध करें कि हर वित्तपोषित वृद्धि स्टैंडअलोन मूल्य दे और यदि वित्तपोषण बदलता है तो आपको परिवर्तन के बीच में न फँसाए।
  • एक्सेसिबिलिटी और सरल भाषा कानूनी दायित्व हैं। Section 508, ADA, WCAG, और सरल-भाषा जनादेश आवश्यकताएँ हैं, संवर्धन नहीं। पाइपलाइन में एक्सेसिबिलिटी जाँच और वर्कफ़्लो में सामग्री समीक्षा शामिल करें।
  • पारदर्शिता एक सुविधा है। FOIA, ओपन-सोर्स जनादेश (“सार्वजनिक पैसा, सार्वजनिक कोड”), और प्रकाशित सेवा मानकों का मतलब है कि आपका काम सार्वजनिक जाँच के अधीन है। इसके लिए डिज़ाइन करें: स्पष्ट रिकॉर्ड, जहाँ उपयुक्त हो खुला, और ईमानदार प्रकाशित प्रदर्शन डेटा।
  • सिद्ध सार्वजनिक-क्षेत्र पैटर्न का अनुसरण करें। U.S. Digital Services Playbook, GOV.UK Service Standard, और USWDS कठिन-अर्जित सबक को संहिताबद्ध करते हैं; उन्हें फिर से आविष्कार करने के बजाय अपनाएँ।

अपनाने की सफलता को मापना

अग्रणी संकेतक (जल्दी संकेत कि बदलाव पकड़ बना रहा है) और पिछड़ते संकेतक (वे परिणाम जिनकी आपको अंततः परवाह है) दोनों को मापें। एक एकल पठन के बजाय रुझान देखें, और कभी किसी मीट्रिक को खेला जाने वाला लक्ष्य न बनने दें।

प्रकारसंकेतकयह आपको क्या बताता है
अग्रणीपक्की सड़क पर टीमों की संख्याअपनाव कितनी तेज़ी से फैल रहा है
अग्रणीपाइपलाइन गेट कवरेज (टेस्ट, SAST, a11y)गुणवत्ता/सुरक्षा कितनी अंतर्निहित हो गई है
अग्रणीडेवलपर अनुभव सर्वेक्षण स्कोरक्या पक्की सड़क वास्तव में मदद करती है
अग्रणीADR के रूप में दर्ज किए गए निर्णयों का प्रतिशतक्या लेखन/सीखने की संस्कृति वास्तविक है
पिछड़तापरिनियोजन आवृत्ति (DORA)डिलीवरी थ्रूपुट
पिछड़तापरिवर्तनों के लिए लीड टाइम (DORA)कमिट से उत्पादन तक की गति
पिछड़तापरिवर्तन विफलता दर (DORA)डिलीवरी प्रक्रिया की गुणवत्ता
पिछड़तासेवा पुनर्स्थापित करने का समय (DORA)परिचालन लचीलापन
पिछड़ताघटना आवृत्ति और गंभीरता रुझानसमय के साथ विश्वसनीयता सुधार
पिछड़ताऑडिट निष्कर्ष / नियंत्रण विफलताएँअनुपालन स्थिति
पिछड़तारिटेंशन और कर्मचारी छोड़नाक्या संस्कृति सुधर रही है

चार DORA मीट्रिक डिलीवरी के लिए सबसे मान्य क्रॉस-इंडस्ट्री परिणाम माप हैं; चारों में एक साथ सुधार को मुख्य संकेत मानें, और एक को दूसरे की बलि देकर सुधारने से सावधान रहें।

सामान्य विफलता मोड और उनसे कैसे बचें

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

सबसे छोटा संभव संस्करण

यदि आप इस परिशिष्ट से और कुछ नहीं याद रखते:

  1. सबसे बड़ी पीड़ा खोजें और इसे एक इच्छुक टीम के साथ ठीक करें।
  2. उस समाधान को एक पक्की सड़क में बदलें जो पुराने तरीके से वास्तव में आसान हो।
  3. परिणाम मापें, जीत दिखाएँ, और अगले चरण को वित्तपोषित करने के लिए इसका उपयोग करें।
  4. दोहराएँ, घेरे को चौड़ा करते हुए, जब तक पक्की सड़क बस यह न बन जाए कि आप कैसे काम करते हैं।
  5. प्रायोजन बनाए रखें, मापते रहें, और कभी बड़ा-धमाका न करें।

आकलन को आधार देने वाले परिपक्वता मॉडल के लिए अध्याय 12.4 देखें, और हर चरण को क्रियान्वित करने वाली लॉन्च, समीक्षा, और ऑडिट चेकलिस्ट के लिए अध्याय 12.2 देखें।