1.10 इंजीनियरिंग प्रभावशीलता और डेवलपर प्रोडक्टिविटी

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

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

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

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

मुख्य सिद्धांत

• प्रोडक्टिविटी बहुआयामी है। कोई एक संख्या इसे नहीं पकड़ती। एकमात्र माप के रूप में पेश किया गया कोई भी मेट्रिक गलत है।
• घर्षण हटाने के लिए मापें, लोगों को रैंक करने के लिए नहीं। मापन का विषय सिस्टम है, व्यक्ति नहीं।
• त्रिकोणासन (triangulate) करें। डेवलपर जो कहते हैं कि काम कैसा महसूस होता है, उसे सिस्टम जो वास्तव में रिकॉर्ड करता है उससे मिलाएँ।
• डेवलपर का अनुभव डेटा है। फ़ीडबैक लूप, संज्ञानात्मक भार (cognitive load), और फ्लो मापने योग्य हैं और सुधारने लायक हैं।
• मान लें कि हर मेट्रिक के साथ खेल-खिलवाड़ होगा। एकाधिक आयामों और ईमानदार इरादे से गुडहार्ट के नियम के विरुद्ध डिज़ाइन करें।
• परिणामों से सावधानी से जोड़ें। प्रभावशीलता को व्यावसायिक मूल्य तक सीढ़ी चढ़नी चाहिए बिना ऐसा लक्ष्य बने जो भ्रष्ट कर दे।

सिफारिशें

एकल-मेट्रिक के जाल को अस्वीकार करें

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

आप क्या मापते हैं इसे संरचित करने के लिए SPACE का उपयोग करें

SPACE फ्रेमवर्क आपको साथ रखने लायक पाँच आयाम देता है: Satisfaction and well-being (संतुष्टि और कल्याण), Performance (प्रदर्शन), Activity (गतिविधि), Communication and collaboration (संचार और सहयोग), और Efficiency and flow (दक्षता और फ्लो)। SPACE का मुद्दा यह है कि आपको कम से कम कुछ आयाम चुनने चाहिए, कभी केवल एक नहीं, और कभी सभी एक ही श्रेणी से नहीं। गतिविधि मेट्रिक्स (कमिट, डिप्लॉय) लुभावने हैं क्योंकि इन्हें इकट्ठा करना आसान है, लेकिन अकेले ये विकृत करते हैं। इन्हें एक संतुष्टि संकेत और एक प्रदर्शन संकेत के साथ जोड़ें ताकि कोई एक आयाम बाकी को उजागर किए बिना खेला न जा सके। एक टीम जो संतुष्टि गिरते और परिवर्तन विफलता दर बढ़ते हुए अधिक डिप्लॉय शिप कर रही है, वह अधिक प्रोडक्टिव नहीं है, और एक संतुलित सेट यह आपको तुरंत दिखा देता है।

डेवलपर अनुभव को फ़ीडबैक लूप, संज्ञानात्मक भार, और फ्लो के रूप में मानें

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

धारणाओं को सिस्टम मेट्रिक्स के साथ त्रिकोणासित करें

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

DORA को एक डिलीवरी संकेत के रूप में उपयोग करें, लीडरबोर्ड के रूप में नहीं

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

सिस्टम को मापें, व्यक्ति की कभी निगरानी न करें

यह वह रेखा है जिसे आपको पार नहीं करना चाहिए। मेट्रिक्स को टीम और संगठन स्तर तक समग्र करें, और उनका उपयोग घर्षण खोजने और हटाने के लिए करें। ऐसे डैशबोर्ड न बनाएँ जो डेवलपरों को कमिट, घंटों, या “प्रोडक्टिविटी स्कोर” से रैंक करें, और व्यक्तिगत टेलीमेट्री को वेतन या पदोन्नति को प्रभावित न करने दें। निगरानी उस मनोवैज्ञानिक सुरक्षा और विश्वास को नष्ट कर देती है जिस पर प्रभावी इंजीनियरिंग निर्भर करती है, और यह लोगों को काम के बजाय मेट्रिक को अनुकूलित करना सिखाती है। व्यक्तिगत विकास और मूल्यांकन करियर लैडर और प्रबंधक वार्तालापों (अध्याय 1.3) के अलग, मानवीय तंत्रों से संबंधित हैं। प्रभावशीलता मापन पूछता है “हमारी टीमों को क्या धीमा कर रहा है?” यह कभी नहीं पूछता “हमारा सबसे धीमा इंजीनियर कौन है?”

टॉइल और घर्षण पर सीधे प्रहार करें

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

ट्रेड-ऑफ़: फ़ायदे और नुकसान

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

केंद्रीय तनाव कठोरता (rigour) बनाम ईमानदारी का है। एक संख्या रिपोर्ट करना आसान है और भ्रष्ट करना भी आसान है; एक समृद्ध, बहुआयामी चित्र ईमानदार है लेकिन एक व्यस्त अधिकारी को समझाना कठिन है। इसे एक छोटा संतुलित सेट चुनकर हल करें (कुछ SPACE आयाम, एक सर्वेक्षण, और एक डिलीवरी पठन के रूप में DORA), स्नैपशॉट के बजाय रुझान रिपोर्ट करें, और स्पष्ट रहें कि संख्याएँ सिस्टम सुधारने के लिए हैं, लोगों को स्कोर करने के लिए नहीं। जब नेतृत्व “एक चार्ट” चाहता है, तो उन्हें कुछ पूरक संकेतों का एक रुझान दें और इन्हें एक झूठे समग्र में समेटने के प्रलोभन को अस्वीकार करें।

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

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

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

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

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

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

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

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

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

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

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

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

उदाहरण

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

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

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

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

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

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

एंटी-पैटर्न और नुकसान

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

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

• स्तर 1, आरंभ: प्रोडक्टिविटी का आकलन आंत की भावना या कोड की लाइनों, वेलोसिटी, या घंटों जैसे एक खेले जा सकने वाले मेट्रिक से किया जाता है। मापन तदर्थ और प्रतिक्रियाशील है, घर्षण अदृश्य है, शिकायतें किस्सागत हैं, और कोई नहीं बता सकता कि संगठन बेहतर हो रहा है या नहीं।
• स्तर 2, विकास: कुछ टीमें बुनियादी अभ्यास अपनाती हैं: कुछ मेट्रिक्स, अक्सर गतिविधि गणना, और कभी-कभार एक डेवलपर अनुभव सर्वेक्षण। अभ्यास टीम-दर-टीम असंगत हैं, डेटा एकत्र किया जाता है लेकिन शायद ही कभी उस पर कार्रवाई होती है, कच्ची टीमों-के-पार तुलनाएँ रेंगकर आती हैं, और व्यक्तियों को रैंकिंग से बचाने वाला कोई साझा सिद्धांत नहीं है।
• स्तर 3, मानकीकरण: एक संतुलित मापन कार्यक्रम दस्तावेज़ीकृत है और पूरे संगठन में लागू है, SPACE-शैली के आयामों, एक नियमित DevEx सर्वेक्षण, और एक डिलीवरी संकेत के रूप में DORA (अध्याय 11.5) का उपयोग करते हुए। मेट्रिक्स नीति द्वारा टीमों तक समग्र किए जाते हैं, व्यक्तियों को कभी रैंक नहीं किया जाता, और निष्कर्ष फ़ीडबैक लूप छोटा करने तथा टॉइल कम करने (अध्याय 9.1) के लिए ठोस काम को संचालित करते हैं।
• स्तर 4, प्रबंधन: कार्यक्रम को आधार रेखाओं के विरुद्ध मापा और नियंत्रित किया जाता है। फ़ीडबैक-लूप समय, सर्वेक्षण स्कोर, और DORA रुझान सहमत लक्ष्य रखते हैं और समय के साथ ट्रैक किए जाते हैं; हर टीम की तुलना उसके पड़ोसियों के बजाय उसके अपने प्रक्षेपवक्र से की जाती है; प्लेटफ़ॉर्म और टॉइल-कमी निवेश को पुनः प्राप्त क्षमता पर पहले-और-बाद के डेटा से उचित ठहराया जाता है; और किसी भी संकेत में एक प्रतिगमन बिना ध्यान दिए गुज़रने के बजाय समीक्षा को ट्रिगर करता है।
• स्तर 5, संचालन: मापन विश्वसनीय, नियमित, और अनुकूली है। अवधारणात्मक और सिस्टम डेटा त्रिकोणासित किए जाते हैं, रुझान निरंतर सुधार को खिलाते हैं, घर्षण और संज्ञानात्मक भार को सक्रिय रूप से खोजा और हटाया जाता है, मापन सेट स्वयं संगठन के बदलने के साथ संशोधित होता है, और प्रभावशीलता को व्यावसायिक और सार्वजनिक परिणामों के साथ इस तरह एकीकृत किया जाता है कि किसी भी मेट्रिक को भ्रष्ट करने वाला लक्ष्य बनने की अनुमति नहीं दी जाती।

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

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

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

• इंजीनियरों के लिए प्रोडक्टिविटी बहुआयामी है। किसी भी एकल संख्या (कोड की लाइनें, वेलोसिटी, कमिट, घंटे) को एकमात्र माप के रूप में अस्वीकार करें, क्योंकि गुडहार्ट का नियम गारंटी देता है कि इसके साथ खेल-खिलवाड़ होगा।
• कई आयामों को साथ रखने के लिए SPACE फ्रेमवर्क (संतुष्टि और कल्याण, प्रदर्शन, गतिविधि, संचार और सहयोग, दक्षता और फ्लो) का उपयोग करें ताकि कोई एक आयाम अकेले न खेला जा सके।
• डेवलपर अनुभव फ़ीडबैक लूप, संज्ञानात्मक भार, और फ्लो पर आकर टिकता है। लूप छोटा करना और भार हटाना असली प्रोडक्टिविटी है जिसे गतिविधि गणना कभी नहीं दिखाती।
• एक DevEx सर्वेक्षण से अवधारणात्मक डेटा को अपने टूल से सिस्टम डेटा के साथ त्रिकोणासित करें; हर एक दूसरे को सुधारता है।
• DORA मेट्रिक्स को एक टीम-स्तरीय डिलीवरी संकेत मानें, लीडरबोर्ड नहीं; इनकी गहराई अध्याय 11.5 में रहती है और पाइपलाइन अध्याय 11.2 में।
• सिस्टम को मापें, व्यक्ति को कभी नहीं। टीमों तक समग्र करें, मूल्यांकन को अध्याय 1.3 के अलग मानवीय चैनलों में रखें, और मापन को कभी निगरानी न बनने दें।
• पुनः प्राप्त समय को टॉइल कम करने (अध्याय 9.1), कोड समीक्षा तेज़ करने (अध्याय 2.5), और सड़कें पक्की करने (अध्याय 8.4) पर खर्च करें। प्रभावशीलता को व्यावसायिक परिणामों से जोड़ें बिना किसी मेट्रिक को भ्रष्ट करने वाला लक्ष्य बनने दिए।

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

• Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity” (ACM Queue, 2021): बहुआयामी फ्रेमवर्क।
• Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler, “DevEx: What Actually Drives Productivity” (ACM Queue, 2023): फ़ीडबैक लूप, संज्ञानात्मक भार, और फ्लो।
• Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps (DORA मेट्रिक्स और उनका अनुसंधान आधार)।
• DORA, Accelerate State of DevOps Report (वार्षिक): चार मेट्रिक्स के पीछे चल रहा अनुसंधान कार्यक्रम।
• Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds., Site Reliability Engineering (टॉइल और उसका उन्मूलन)।
• Matthew Skelton and Manuel Pais, Team Topologies (एक प्रथम-श्रेणी डिज़ाइन चिंता के रूप में संज्ञानात्मक भार)।
• Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (फ्लो अवस्था की उत्पत्ति)।
• Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams (फोकस, व्यवधान, और प्रोडक्टिविटी का मानवीय पक्ष)।
• Goodhart, C. A. E., “Problems of Monetary Management: The UK Experience” (1975): गुडहार्ट के नियम की उत्पत्ति; Marilyn Strathern का व्यापक रूप से उद्धृत सूत्रीकरण भी देखें।
• U.S. Government Accountability Office (GAO) guidance on performance measurement: गैर-बाज़ार सार्वजनिक-क्षेत्र सेटिंग्स में मूल्य मापना।