11.1 डिस्कवरी पाइपलाइन

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

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

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

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

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

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

सिफारिशें

OKR के साथ दिशा को फ़्रेम करें

रणनीति को टीम निष्पादन से जोड़ने के लिए उद्देश्य और मुख्य परिणाम (OKR) का उपयोग करें। एक उद्देश्य एक इच्छित अंतिम अवस्था का गुणात्मक, प्रेरणादायक विवरण है (“पहली बार ऑनबोर्डिंग को सहज बनाएं”)। मुख्य परिणाम मापने योग्य परिणामों की एक छोटी संख्या (आमतौर पर 2–4) हैं जो साबित करते हैं कि उद्देश्य पूरा हो रहा है (“7-दिन सक्रियण को 40% से बढ़ाकर 60% करें”; “ऑनबोर्डिंग सपोर्ट टिकट को 30% कम करें”)। मुख्य परिणाम परिणाम व्यक्त करते हैं, कार्य नहीं: “नया विज़ार्ड शिप करें” एक कार्य है जो परिणाम का भेष धारण किए हुए है।

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

KPI के साथ स्वास्थ्य की निगरानी करें

मुख्य प्रदर्शन संकेतक (KPI) को OKR से अलग करें। OKR उस परिवर्तन का वर्णन करते हैं जो आप इस अवधि में चाहते हैं; KPI उस चल रहे स्वास्थ्य का वर्णन करते हैं जिसे आपको बनाए रखना चाहिए चाहे आप जो भी बदल रहे हों (अपटाइम, रूपांतरण दर, प्रति लेनदेन लागत, ग्राहक संतुष्टि)। एक मीट्रिक दोनों हो सकता है (एक KPI जिसे आप सक्रिय रूप से हिलाने की कोशिश कर रहे हैं वह एक मुख्य परिणाम बन जाता है), लेकिन अधिकांश KPI गार्डरेल हैं जिन्हें आप निगरानी करते हैं, लक्ष्य नहीं जिनकी ओर आप स्प्रिंट करते हैं।

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

सिस्टम गुणवत्ता विशेषताओं को स्पष्ट रूप से निर्दिष्ट करें

कार्यात्मक आवश्यकताएं बताती हैं कि सिस्टम क्या करता है। सिस्टम गुणवत्ता विशेषताएं (“-ility” गुण: विश्वसनीयता, प्रदर्शन, स्केलेबिलिटी, सुरक्षा, एक्सेसिबिलिटी, अनुरक्षणीयता, संचालनीयता) बताती हैं कि इसे कितना अच्छा करना चाहिए। इनकी नियमित रूप से कम-खोज होती है: हर कोई इन्हें मान लेता है, कोई इन्हें निर्दिष्ट नहीं करता, और ये उत्पादन घटनाओं के रूप में सामने आती हैं। इन्हें प्रथम-श्रेणी डिस्कवरी आउटपुट के रूप में मानें। हर पहल के लिए आर्किटेक्चरल रूप से महत्वपूर्ण आवश्यकताएं (वे गुणवत्ता मांगें जो आर्किटेक्चर को भौतिक रूप से आकार देती हैं) की पहचान करें। इन्हें मात्रात्मक बनाएं (“वर्तमान लोड के 10× पर p99 विलंबता 200 ms से कम”; “WCAG (वेब कंटेंट एक्सेसिबिलिटी गाइडलाइंस) 2.2 AA”; “15 मिनट का पुनर्प्राप्ति समय उद्देश्य”)। और जहाँ आप कर सकते हैं, इन्हें स्वचालित फ़िटनेस फ़ंक्शन (कार्यान्वित जाँच जो लगातार एक गुणवत्ता विशेषता को सत्यापित करती है) के रूप में एनकोड करें जिसे डिलीवरी पाइपलाइन जाँच सके। यह अध्याय 3.1 (आर्किटेक्चर मूल सिद्धांत) और अध्याय 3.5 (स्केलेबिलिटी, प्रदर्शन, लचीलापन) का डिस्कवरी-पक्ष पूरक है।

हर लक्ष्य को SMART बनाएं

चाहे आप एक मुख्य परिणाम, एक स्वीकृति मानदंड, या एक गुणवत्ता लक्ष्य लिख रहे हों, SMART परीक्षण लागू करें:

विशिष्ट (Specific): एक स्पष्ट, असंदिग्ध परिणाम का नाम लेता है।
मापने योग्य (Measurable): इसमें एक मीट्रिक और सत्य का स्रोत है।
प्राप्य (Achievable): बाधाओं और सबूत को देखते हुए यथार्थवादी है।
प्रासंगिक (Relevant): एक उच्च उद्देश्य और उपयोगकर्ता मूल्य तक सीढ़ी की तरह जुड़ता है।
समय-सीमित (Time-bound): इसकी एक समयसीमा या समीक्षा तारीख है।

“प्रदर्शन सुधारें” हर अक्षर में विफल होता है। “Q3 के अंत तक मोबाइल उपयोगकर्ताओं के लिए मध्यम चेकआउट समय को 8s से 3s तक कम करें, वास्तविक-उपयोगकर्ता निगरानी द्वारा मापा गया” सभी पाँच में उत्तीर्ण होता है। SMART मानदंड अस्पष्ट महत्वाकांक्षा को एक खंडन योग्य दावे में बदल देते हैं जिसे डिस्कवरी टेस्ट कर सकती है और डिलीवरी सत्यापित कर सकती है।

सतत, सबूत-संचालित डिस्कवरी चलाएं

डिस्कवरी को एक बार का चरण नहीं, एक दोहराने योग्य पाइपलाइन के रूप में संरचित करें:

महसूस करें (Sense)। संकेत इकट्ठा करें: उपयोगकर्ता शोध, सपोर्ट डेटा, एनालिटिक्स, बाज़ार और अनुपालन इनपुट।
फ़्रेम करें (Frame)। अवसरों को मैप करें (एक अवसर-समाधान वृक्ष एक इच्छित परिणाम को उपयोगकर्ता आवश्यकताओं और उम्मीदवार समाधानों से जोड़ता है जो इसे आगे बढ़ा सकते हैं)।
परिकल्पना बनाएं (Hypothesize)। मान्यताओं को खंडन योग्य दावों के रूप में बताएं: “हम मानते हैं कि [परिवर्तन][खंड] के लिए [परिणाम] पैदा करेगा, और हम जानेंगे कि क्या [माप] हिलता है।”
प्रयोग करें (Experiment)। सबसे सस्ते टेस्ट के साथ सबसे जोखिम भरी मान्यताओं को मान्य करें: साक्षात्कार, प्रोटोटाइप, फ़ेक-डोर टेस्ट (वास्तविक मांग मापने के लिए एक अभी-तक-न-बनी हुई फ़ीचर का विज्ञापन करना), A/B प्रयोग (दो वेरिएंट की यादृच्छिक तुलना, अध्याय 7.4)।
निर्णय लें (Decide)। जारी रखें, दिशा बदलें, या छोड़ दें, और जीवित बचे हुओं को उनके जुड़े SMART सफलता मानदंडों के साथ डिलीवरी बैकलॉग में फ़ीड करें।

डिस्कवरी पाइपलाइन का आउटपुट एक फ़ीचर सूची नहीं है; यह डिलीवरी के लिए तैयार मान्य, मापने योग्य दांवों की एक धारा है।

समझौते: फ़ायदे और नुकसान

दृष्टिकोण	फ़ायदे	नुकसान
परिणाम-आधारित लक्ष्य (OKR)	टीमों को प्रभाव के साथ संरेखित करता है; कैसे में स्वायत्तता को सशक्त बनाता है	अच्छी तरह लिखना कठिन; कार्यों से बैकफ़िल करने का प्रलोभन; शोरगुल वाला श्रेय
आउटपुट/फ़ीचर रोडमैप	अनुमानित, संवाद और अनुबंध करना आसान	प्रभाव के बजाय शिपिंग को पुरस्कृत करता है; गलत-चीज़ जोखिम छुपाता है
भारी अग्रिम डिस्कवरी	बिल्ड अपव्यय को कम करता है; मज़बूत आवश्यकताएं	शुरुआत को धीमा करता है; विश्लेषण पक्षाघात का जोखिम; मान्यताएं अभी भी अनटेस्ट
सतत दोहरी-पथ डिस्कवरी	लगातार जोखिम कम करता है; तेज़ फ़ीडबैक	शोध क्षमता और अनुशासन की आवश्यकता; अनुसूचित करना कठिन
SMART लक्ष्यों के रूप में स्पष्ट गुणवत्ता विशेषताएं	“-ility” आश्चर्यों को रोकता है; ऑडिट योग्य	मात्रात्मक बनाने का प्रयास; शुरुआती खोज को अधिक-सीमित कर सकता है

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

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

आपकी टीम में वास्तव में डिस्कवरी का स्वामी कौन है, और क्या उनके पास इसे एक बार के स्प्रिंट के बजाय लगातार चलाने की क्षमता है? दोहरी-पथ विकास तभी काम करता है जब कोई हर सप्ताह डिस्कवरी ट्रैक को खुला रखे, न कि केवल तिमाही की शुरुआत में। एक बड़े संगठन में, डिस्कवरी के पास अक्सर कोई समर्पित स्वामी नहीं होता, इसलिए यह उसी के पास गिर जाती है जिसके पास फ़ुर्सत का समय है, जो कोई नहीं है, और टीम डिफ़ॉल्ट रूप से निर्माण करने लगती है। सबूत लाएं: गिनें कि आपकी पिछली दस फ़ीचरों में से कितनी बिल्ड से पहले एक दस्तावेज़ीकृत परिकल्पना और एक सस्ते टेस्ट से गुज़रीं, बनाम सीधे बैकलॉग में चली गईं। एंटरप्राइज़ और सरकारी सेटिंग्स में, जहाँ एक गलत-संरेखित पहल कई टीम-तिमाहियों को बर्बाद कर सकती है, महसूस-फ़्रेम-परिकल्पना-प्रयोग-निर्णय लूप के लिए जवाबदेह एक प्रोडक्ट स्वामी या एक त्रयी (प्रोडक्ट, डिज़ाइन, इंजीनियरिंग) का नाम लें। यदि कोई इसका स्वामी नहीं है, तो किसी और चीज़ पर बहस करने से पहले इसे स्टाफ़ करें।
आपकी वर्तमान पहलों में से किसमें ऐसी आर्किटेक्चरल रूप से महत्वपूर्ण आवश्यकताएं हैं जिन्हें आपने कभी मात्रात्मक नहीं बनाया, और क्या आप किसी को फ़िटनेस फ़ंक्शन के रूप में एनकोड कर सकते हैं? “-ility” गुण (विश्वसनीयता, प्रदर्शन, सुरक्षा, एक्सेसिबिलिटी) मान लिए जाते हैं और फिर उत्पादन घटनाओं के रूप में सामने आते हैं। हर सक्रिय पहल के माध्यम से चलें, पूछें कि कौन सी गुणवत्ता विशेषताएं आर्किटेक्चर को भौतिक रूप से आकार देती हैं, और जाँचें कि क्या हर एक के पास एक संख्या और सत्य का स्रोत है: “10x लोड पर p99 200 ms से कम,” “WCAG 2.2 AA,” “15 मिनट का पुनर्प्राप्ति समय उद्देश्य।” एंटरप्राइज़ और सरकार के लिए, अमात्रात्मक एक्सेसिबिलिटी या सुरक्षा आवश्यकताएं सीधा कानूनी और ऑडिट एक्सपोज़र पैदा करती हैं। लाने के लिए संकेत आपकी पिछली तीन घटनाएं हैं: कितनी वापस किसी ऐसी गुणवत्ता विशेषता तक ट्रेस हुईं जिसे किसी ने निर्दिष्ट नहीं किया था? जहाँ आप एक लक्ष्य को एक स्वचालित फ़िटनेस फ़ंक्शन में बदल सकते हैं जिसे डिलीवरी पाइपलाइन जाँचती है, वहाँ ऐसा करें, क्योंकि एक निर्दिष्ट लेकिन अप्रवर्तित लक्ष्य भटक जाता है।
जब आपने आखिरी बार एक समाधान के प्रति प्रतिबद्ध हुए, तो क्या आपने सबसे जोखिम भरी मान्यता पहले टेस्ट की, या सबसे आसान वाली? टीमें विश्वसनीय रूप से उस मान्यता को मान्य करती हैं जिसके साथ वे सबसे सहज हैं और उसे छोड़ देती हैं जो वास्तव में विचार को मार सकती है। हर पहल के लिए, इसकी मान्यताओं (वांछनीयता, व्यवहार्यता, साध्यता) की सूची बनाएं और उन्हें “यदि हम यहाँ गलत हैं तो यह विचार कितना मृत है” के अनुसार रैंक करें, फिर उस सूची के शीर्ष पर सबसे सस्ता टेस्ट लक्षित करें। यह बड़े पैमाने पर मायने रखता है क्योंकि एक आत्मविश्वासी, वरिष्ठ टीम एक अनटेस्ट किए गए विश्वास के लिए एक तिमाही की इंजीनियरिंग प्रतिबद्ध कर सकती है, और लागत लॉन्च तक अदृश्य रहती है। कलाकृति लाएं: आपकी पिछली परिकल्पना “हम मानते हैं कि [परिवर्तन][खंड] के लिए [परिणाम] पैदा करता है, [मीट्रिक] द्वारा मापा गया” के रूप में बताई गई, और पूछें कि क्या आपने इसे टेस्ट किया या सिर्फ़ बना दिया। यदि आप सबसे जोखिम भरी मान्यता का नाम नहीं ले सकते, तो आप बिल्ड क्षमता के प्रति प्रतिबद्ध होने के लिए तैयार नहीं हैं।
आपके कितने मुख्य परिणाम वास्तविक परिणाम हैं, और कितने कार्य या शिप तारीखें हैं जो परिणाम के कपड़े पहने हुए हैं? परिणाम-आधारित योजना में सबसे आम विफलता उस काम के साथ मुख्य परिणामों को बैकफ़िल करना है जिसे आपने पहले ही करने की योजना बनाई थी (“नया विज़ार्ड लॉन्च करें”) बजाय उस परिवर्तन के जिसे वह काम पैदा करने वाला है (“7-दिन सक्रियण को 40% से बढ़ाकर 60% करें”)। बड़े पैमाने पर यह चुपचाप पूरे मुद्दे को हरा देता है: दर्जनों टीमें हरा रिपोर्ट करती हैं जबकि कोई व्यावसायिक मीट्रिक नहीं हिलता, क्योंकि हर कोई खुद को शिपिंग पर ग्रेड करता है। प्रतिस्पर्धी खिंचाव वास्तविक है, आउटपुट रोडमैप संवाद, अनुबंध, और पूर्वानुमान करना आसान है, जो ठीक वही कारण है जिससे वे वापस रेंगते हैं। अपना वर्तमान OKR सेट लाएं और हर मुख्य परिणाम को परिणाम या आउटपुट के रूप में चिह्नित करें, फिर जाँचें कि क्या OKR ग्रेडिंग मुआवज़े से उलझी हुई है, क्योंकि वेतन से जुड़े परिणाम जल्दी सैंडबैग हो जाते हैं। एंटरप्राइज़ और सरकारी पोर्टफ़ोलियो के लिए, जहाँ धन बताए गए लक्ष्यों के खिलाफ़ प्रतिबद्ध है, बिना किसी परिणाम माप के आउटपुट का एक रोडमैप एक ऑडिट खोज है जो होने का इंतज़ार कर रही है; ज़ोर दें कि हर पहल एक समस्या और एक मापने योग्य परिणाम के प्रति दृढ़ता से प्रतिबद्ध हो जबकि समाधान को ढीले ढंग से पकड़े।
आपके कौन से KPI तब भी बढ़ते रहेंगे भले ही उत्पाद खराब हो रहा हो, और आप सक्रिय रूप से हिलाने की कोशिश कर रहे मीट्रिक की रक्षा कौन से गार्डरेल करते हैं? हर मीट्रिक जिसे आप एक लक्ष्य तक ऊपर उठाते हैं वह गुडहार्ट के नियम को आमंत्रित करता है: एक बार जब एक माप लक्ष्य बन जाता है, तो लोग उस चीज़ के बजाय माप को अनुकूलित करते हैं जिसे यह प्रतिनिधित्व करने वाला था। घमंडी मीट्रिक (कच्चे पेज व्यू, संचयी पंजीकृत उपयोगकर्ता) विश्वसनीय रूप से बढ़ते हैं और कुछ भी भविष्यवाणी नहीं करते, जबकि बिना गार्डरेल के पीछा किया गया एक अकेला मुख्य परिणाम किसी ऐसी चीज़ को बिगाड़कर पूरा किया जा सकता है जिसका आपने कभी नाम नहीं लिया। तनाव यह है कि अग्रणी संकेतक आपको जल्दी दिशा तय करने देते हैं लेकिन शोरगुल वाले और छेड़छाड़ योग्य होते हैं, जबकि पिछड़ते संकेतक भरोसेमंद होते हैं लेकिन कार्रवाई के लिए बहुत देर से पुष्टि करते हैं। अपनी मीट्रिक सूची लाएं जिसे अग्रणी या पिछड़ता, और लक्ष्य या गार्डरेल के रूप में वर्गीकृत किया गया है, और यह पूछकर हर लक्ष्य को तनाव-टेस्ट करें कि “एक चतुर टीम उत्पाद को खराब बनाते हुए इस संख्या को कैसे हासिल कर सकती है।” नियमित और सार्वजनिक सेटिंग्स में, गार्डरेल को लक्ष्यों के साथ प्रकाशित करें, क्योंकि एक निगरानी निकाय जो केवल हेडलाइन मीट्रिक देखता है वह वास्तविक सार्वजनिक मूल्य को एक छेड़छाड़ की गई संख्या से अलग नहीं बता सकता।
जब डिलीवरी कुछ शिप करती है, तो वास्तविक-दुनिया का परिणाम वास्तव में डिस्कवरी में कैसे फिर से प्रवेश करता है, या लूप खुला रहता है? दोहरी-पथ विकास तभी जमा होता है जब डिलीवर किए गए परिणाम अगले दौर के लिए सबूत के रूप में वापस बहते हैं; जब लूप खुला रहता है, तो टीमें शिप करती हैं, जश्न मनाती हैं, और कभी नहीं सीखतीं कि दांव सफल रहा या नहीं, इसलिए वही अनटेस्ट की गई मान्यताएं फिर से होती हैं। एक बड़े संगठन में फ़ीडबैक पथ वह है जहाँ जवाबदेही सबसे अधिक संभावना है कि एक अंतराल से गुज़र जाए: डिलीवरी रिलीज़ की स्वामी है, एनालिटिक्स डैशबोर्ड की स्वामी है, और वादा किए गए मुख्य परिणाम की देखे गए परिणाम से तुलना करने का कोई स्वामी नहीं है। अपनी पिछली दस शिप की गई पहलों को लाएं और पूछें, हर एक के लिए, क्या किसी ने परिणाम मीट्रिक को मूल SMART लक्ष्य के खिलाफ़ जाँचा और क्या उस जाँच ने बाद के किसी निर्णय को बदला। बहु-वर्षीय धन प्रतिबद्ध करने वाले एंटरप्राइज़ और सरकारी कार्यक्रमों के लिए, ऐसी फ़ीचरों को सेवानिवृत्त करने या पुनः-दायरा देने के लिए लय और स्वामी का नाम लें जो अपने मीट्रिक को हिलाने में विफल रहीं, क्योंकि एक शिप की गई फ़ीचर जिसे कोई दोबारा नहीं देखता वह बिना किसी जवाबदेह समीक्षा के स्थायी लागत बन जाती है।

क्षेत्र लेंस

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

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

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

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

उदाहरण

स्टार्टअप। हेयर सैलून के लिए एक शेड्यूलिंग ऐप बना रही एक चार-व्यक्ति सीड-स्टेज टीम एक ऑनलाइन-बुकिंग विजेट बनाने के लिए ललचाई जाती है क्योंकि कुछ ज़ोरदार उपयोगकर्ताओं ने इसकी मांग की थी। इसके बजाय वे डिस्कवरी का एक सप्ताह चलाते हैं: पाँच मालिक साक्षात्कार, मार्केटिंग साइट पर एक फ़ेक-डोर “ऑनलाइन बुक करें” बटन, और एक एकल अग्रणी संकेतक (अपॉइंटमेंट का प्रतिशत जो नो-शो में समाप्त होता है)। साक्षात्कार और क्लिक डेटा से पता चलता है कि नो-शो, बुकिंग नहीं, वास्तविक दर्द है, इसलिए वे एक SMART मुख्य परिणाम लिखते हैं (इस तिमाही पायलट सैलून के लिए नो-शो को 22% से घटाकर 10% से कम करें) और पहले एक छोटी जमा-राशि-और-अनुस्मारक फ़ीचर शिप करते हैं, बुकिंग विजेट की एक लाइन लिखने से पहले उसे मार देते हैं।

एंटरप्राइज़। एक रिटेल बैंक का पेमेंट समूह एक फ़ीचर-गिनती रोडमैप को तीन त्रैमासिक OKR से बदलता है, जिनमें से एक है “रोज़मर्रा के भुगतान को तत्काल महसूस कराएं” जिसमें p95 ट्रांसफ़र पुष्टिकरण समय, पहले-प्रयास सफलता दर, और भुगतान-संबंधित सपोर्ट संपर्कों के लिए मुख्य परिणाम हैं। सिस्टम गुणवत्ता विशेषताएं पहले से निर्दिष्ट हैं (99.99% उपलब्धता, उप-सेकंड पुष्टिकरण, PCI-DSS (पेमेंट कार्ड इंडस्ट्री डेटा सिक्योरिटी स्टैंडर्ड) दायरे को कम से कम किया गया) और फ़िटनेस फ़ंक्शन के रूप में डिलीवरी में तार से जोड़ी गई हैं। इंजीनियरिंग प्रतिबद्ध करने से पहले डिस्कवरी साप्ताहिक ग्राहक साक्षात्कार और फ़ेक-डोर टेस्ट चलाती है। दो उम्मीदवार फ़ीचरों को अग्रणी संकेतकों को हिलाने में विफल रहने के लिए डिस्कवरी में मार दिया जाता है (अनुमानित दो तिमाहियों का बिल्ड प्रयास बचाते हुए), जबकि एक छोटा, गैर-चमकदार विलंबता फ़िक्स मुख्य परिणाम को सबसे अधिक हिलाता है।

सरकार। एक राष्ट्रीय कर एजेंसी जो ऑनलाइन फ़ाइलिंग को आधुनिक बना रही है, “साधारण करदाताओं के लिए फ़ाइलिंग के बोझ को कम करें” का एक कार्यक्रम उद्देश्य तय करती है, जिसमें SMART मुख्य परिणाम हैं: माध्य फ़ाइल-करने-का-समय 45 से घटाकर 20 मिनट करें, सफल स्व-सेवा पूर्णता को 60% से बढ़ाकर 85% करें, और गैर-परक्राम्य गुणवत्ता विशेषताओं के रूप में WCAG 2.2 AA और सरल-भाषा मानकों को पूरा करें। KPI (फ़ाइलिंग सीज़न के दौरान अपटाइम, कॉल-सेंटर वॉल्यूम) को गार्डरेल के रूप में निगरानी किया जाता है। डिस्कवरी हर रिलीज़ से पहले वास्तविक करदाताओं के साथ मॉडरेट उपयोगिता टेस्टिंग का उपयोग करती है, जिसमें सहायक-तकनीक उपयोगकर्ता शामिल हैं। क्योंकि सफलता को डिलीवर किए गए मॉड्यूल के बजाय करदाता परिणामों के रूप में परिभाषित किया गया है, कार्यक्रम निगरानी निकायों को मापने योग्य सार्वजनिक मूल्य दिखा सकता है, केवल खर्च नहीं।

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

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

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

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

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

रणनीति का भेष धारण करने वाले फ़ीचर रोडमैप: बिना बताए गए परिणाम या माप के आउटपुट सूचियां।
मुख्य परिणाम जो कार्य हैं: “X लॉन्च करें” के बजाय “Y को Z से सुधारें।”
OKR थियेटर: लक्ष्य लिखे गए, फ़ाइल किए गए, और कभी समीक्षा या ग्रेड नहीं किए गए।
सैंडबैग किए गए या वीरतापूर्ण OKR: 100% गारंटी करने के लिए सेट किए गए लक्ष्य (कुछ नहीं सीखा गया) या बिना किसी योजना के कल्पना खिंचाव।
अनिर्दिष्ट गुणवत्ता विशेषताएं: विश्वसनीयता, सुरक्षा, और एक्सेसिबिलिटी को मात्रात्मक बनाने के बजाय मान लिया जाता है, फिर उत्पादन में खोजा जाता है।
घमंडी मीट्रिक: माप जो हमेशा ऊपर जाते हैं और कुछ भी भविष्यवाणी नहीं करते।
एक बार के चरण के रूप में डिस्कवरी: अग्रिम में एक “डिस्कवरी स्प्रिंट,” फिर कोई निरंतर सत्यापन नहीं।
मान्यता टेस्ट करने से पहले समाधान बनाना: सबसे सस्ते प्रयोग को छोड़ना क्योंकि टीम आत्मविश्वासी है।
मीट्रिक जुनून और गुडहार्ट का नियम: एक बार जब एक माप लक्ष्य बन जाता है, यह एक अच्छा माप होना बंद कर देता है; गार्डरेल KPI से संतुलित करें।

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

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

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

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

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

डिस्कवरी पाइपलाइन तय करती है क्या और क्यों, और डिलीवरी संसाधन प्रतिबद्ध करने से पहले सफलता को परिभाषित करती है।
जिस परिवर्तन को आप चाहते हैं उसके लिए OKR का उपयोग करें, जिस स्वास्थ्य को आप बनाए रखते हैं उसके लिए KPI का, और मीट्रिक को अग्रणी या पिछड़ते के रूप में वर्गीकृत करें।
सिस्टम गुणवत्ता विशेषताओं को स्पष्ट, मात्रात्मक, टेस्ट करने योग्य आवश्यकताओं के रूप में मानें, मान्यताओं के रूप में नहीं।
हर लक्ष्य, मुख्य परिणाम, और स्वीकृति मानदंड को SMART बनाएं।
डिस्कवरी को डिलीवरी के साथ लगातार और समानांतर रूप से चलाएं; सबसे जोखिम भरी मान्यताओं को सस्ते में मान्य करें।
प्रमुख ROI टाला गया अपव्यय है: बिल्ड लागत और अनुपयोगी फ़ीचरों की स्थायी TCO दोनों।
लूप बंद करें: डिलीवर किए गए परिणाम मीट्रिक (अध्याय 11.2) डिस्कवरी के अगले दौर के लिए प्राथमिक सबूत हैं।

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

Measure What Matters, by John Doerr (on OKRs).
Radical Focus, by Christina Wodtke (on OKRs in practice).
Continuous Discovery Habits, by Teresa Torres (opportunity-solution trees, dual-track discovery).
Inspired and Empowered, by Marty Cagan (product discovery and outcome teams).
Lean Analytics, by Alistair Croll and Benjamin Yoskovitz (leading indicators, vanity metrics).
The Lean Startup, by Eric Ries (build-measure-learn, validated learning).
Escaping the Build Trap, by Melissa Perri (outcomes over outputs).
Outcomes Over Output, by Joshua Seiden.
Software Architecture in Practice, by Bass, Clements, Kazman (quality attributes).
Doran, G. T., “There’s a S.M.A.R.T. way to write management’s goals and objectives” (Management Review, 1981): origin of SMART criteria.