1.1 सॉफ़्टवेयर इंजीनियरिंग को क्यों मापें

अवलोकन और प्रेरणा

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

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

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

प्रमुख सिद्धांत

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

सिफ़ारिशें

डैशबोर्ड से नहीं, निर्णय से शुरू करें

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

डायग्नोस्टिक उपयोग को मूल्यांकनात्मक उपयोग से अलग करें

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

मापन को एक तथ्य नहीं, एक परिकल्पना मानें

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

मापन की अनुपस्थिति को दृश्यमान बनाएँ

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

समझौते: लाभ और हानि

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

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

अपनी टीम के साथ चर्चा करने के प्रश्न

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

क्षेत्र दृष्टिकोण

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

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

एंटरप्राइज़। मुख्य जोखिम वे मेट्रिक्स हैं जो प्रबंधन परतों के माध्यम से ऊपर जाते समय डायग्नोस्टिक से मूल्यांकनात्मक उपयोग की ओर चुपचाप फिसल जाते हैं, और वे डैशबोर्ड जो जमाव से बढ़ते हैं क्योंकि उन्हें छाँटने का काम किसी का नहीं है। इस पैमाने पर गवर्नेंस (विषय 1.4) वैकल्पिक नहीं है। व्यावसायिक इकाइयों में परिभाषाओं को मानकीकृत करें, और मेट्रिक्स कार्यक्रम में ही एक नियमित सेवानिवृत्ति समीक्षा बनाएँ।

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

उदाहरण

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

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

व्यावसायिक तर्क: प्रेरणाएँ, ROI, और TCO

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

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

विरोधी-पैटर्न और नुक़सान

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

परिपक्वता मॉडल

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

चर्चा के लिए विचार

हमारे डैशबोर्ड पर कौन-सा मेट्रिक ऐसा है जिसे आज पूछे जाने पर बनाए रखने का औचित्य साबित करना हमें सबसे कठिन लगेगा?
पिछले चौथाई में हमने कौन-सा निर्णय किसी मेट्रिक के उपयोग से लिया, राय के बजाय?
हमारे संगठन में कहाँ एक डायग्नोस्टिक मेट्रिक चुपचाप मूल्यांकनात्मक बन गया है?
हम किस चीज़ को मापने से डरते हैं, और क्यों?
यदि हमारा मेट्रिक्स कार्यक्रम कल ग़ायब हो जाए, तो कौन-से निर्णय बदतर हो जाएँगे?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren, Jez Humble, और Gene Kim द्वारा (परिणाम-आधारित इंजीनियरिंग मापन की शोध नींव)।
How to Measure Anything, Douglas W. Hubbard द्वारा (उन चीज़ों को मात्रात्मक बनाने का एक सामान्य ढाँचा जो अमाप्य लगती हैं)।
Measuring and Managing Performance in Organizations, Robert D. Austin द्वारा (उस शिथिलता का बुनियादी विश्लेषण जिसे मापन एक संगठन में ला सकता है)।
Thinking, Fast and Slow, Daniel Kahneman द्वारा (वे संज्ञानात्मक पूर्वाग्रह जो बिना सहायता के निर्णय को मापन का एक अविश्वसनीय विकल्प बनाते हैं)।
Google का DevOps Research and Assessment (DORA) कार्यक्रम, dora.dev (State of DevOps पर चल रहा शोध जिस पर यह पुस्तक पूरे समय आधारित है)।