मूल्य कहाँ स्थित है, उसमें बदलाव
पहला ड्राफ्ट बनाना सस्ता हो गया
व्यापार और ज्ञान-आधारित कार्य दोनों में, एक संभाव्य पहला ड्राफ्ट बनाना: एक नोट, एक क्वेरी, एक डिज़ाइन, एक स्लाइड डेक, या कोड का एक ब्लॉक: अब लगभग निःशुल्क है। स्वचालित प्रणालियाँ मांग पर आत्मविश्वास से आउटपुट उत्पन्न करती हैं। लेकिन वे यह तय नहीं कर सकतीं कि आउटपुट सही प्रश्न का उत्तर देता है या नहीं।
यह बदलाव एक पेशेवर की लीवरेज (leverage) को अपस्ट्रीम (upstream) ले जाता है। दुर्लभ कौशल अब पहली संस्करण टाइप करना नहीं है। यह समस्या का ढांचा (framing) बनाना, विनिर्देश (spec) लिखना, कार्य को विभाजित करना, एक सटीक प्रश्न पूछना, और वापस आने वाले परिणाम का मूल्यांकन करना है।
यह पाठ चार ऐसी अनुशासनों (disciplines) पर केंद्रित है जो एक साथ जुड़कर प्रभाव बढ़ाती हैं:
- समस्या की परिभाषा: प्रस्तुत लक्षण (presenting symptom) को वास्तविक समस्या से अलग करना।
- विनिर्देश (Specification): एक अस्पष्ट अनुरोध को सटीक, परीक्षण योग्य सफलता मानदंडों और प्रतिबंधों में बदलना।
- विभाजन (Decomposition): एक बड़ी समस्या को स्वतंत्र, सत्यापन योग्य उप-समस्याओं में संरचित करना।
- सही प्रश्न पूछना: एक हितधारक, डेटासेट या स्वचालित प्रणाली से, जहाँ प्रश्न की सटीकता उत्तर की मूल्यवृद्धि की सीमा तय करती है।
गलत प्रश्न का आत्मविश्वास से दिया गया उत्तर, कोई उत्तर न देने से भी बदतर है, क्योंकि वह पूरा हुआ प्रतीत होता है और उसे जारी (ship) कर दिया जाता है। पेशेवर का काम यह सुनिश्चित करना है कि किसी भी व्यक्ति द्वारा उत्तर देने से पहले, प्रश्न का उत्तर दिया जाना उचित था।
एग्जीक्यूटिव अनुरोध (The Executive Ask)
लक्षण को समस्या से अलग करें
प्रस्तुत लक्षण (presenting symptom) वह है जो कोई व्यक्ति रिपोर्ट करता है। असली समस्या वह मूल स्थिति है जिसने इसे उत्पन्न किया। लक्षण को अच्छी तरह हल करने से असली समस्या अछूती रह सकती है, और आत्मविश्वास से भरा प्रस्तुतीकरण (delivery) उस विफलता को छिपा देता है, जब तक कि यह बाद में महंगे नुकसान के रूप में सामने न आ जाए।
एक VP आकर कहता है: "हमारा सेल्स डैशबोर्ड बहुत धीमा है। क्वार्टर के अंत तक हमें एक तेज़ डैशबोर्ड बनाओ।" यह एक लक्षण है जिसे समाधान के रूप में प्रस्तुत किया गया है। निर्देश में पहले से ही एक तकनीक (डैशबोर्ड) और एक समाधान (तेज़) का नाम लिया गया है, जो बेहतर विकल्पों को चुपचाप बंद कर देता है।
गलत समस्या को अच्छी तरह हल करने की लागत ही वह जाल है। एक टीम एक सुंदर और तेज़ डैशबोर्ड लॉन्च कर सकती है, डेडलाइन पूरा कर सकती है, प्रशंसा पा सकती है, और फिर भी विफल हो सकती है, क्योंकि VP को वास्तव में यह पहचानने की आवश्यकता थी कि चर्न रिस्क (churn risk) कब है ताकि वे कार्रवाई कर सकें, और वे मूल रूप से डैशबोर्ड को रोज़ देखते ही नहीं थे।
अस्पष्ट अनुरोध से टेस्टेबल मानदंडों तक
एक स्पेक (Spec) राय को टेस्ट में बदलता है
एक अस्पष्ट अनुरोध ("ऑनबोर्डिंग बेहतर बनाओ", "डेटा साफ़ करो", "खोज जोड़ो") को डिलीवर या सत्यापित नहीं किया जा सकता, क्योंकि कोई भी यह नहीं कह सकता कि यह कब पूरा हुआ। एक विनिर्देश (specification) विशेषणों (adjectives) को टेस्टों से बदल देता है। यह सफलता के मानदंडों को किसी ऐसे शब्दों में बताता है जिन्हें मापा जा सकता है, और उन प्रतिबंधों को जो समाधान का पालन करना चाहिए।
दो घटक एक स्पेक को वास्तविक बनाते हैं:
- टेस्टेबल सफलता मानदंड: एक ऐसी स्थिति जिसे बिना बहस किए पास या फेल के रूप में जाँचा जा सकता है। "तेज़" एक राय है; "200 रिक्वेस्ट प्रति सेकंड पर p95 रिस्पॉन्स 400 ms से कम" एक टेस्ट है। "बेहतर ऑनबोर्डिंग" एक राय है; "80% नए उपयोगकर्ता अपनी पहली सत्र (session) के दौरान चरण 3 पूरा करते हैं" एक टेस्ट है।
- स्पष्ट प्रतिबंध: वे सीमाएँ जिनके अंदर समाधान को रहना चाहिए: बजट, अंतिम तिथि, वह डेटा जिससे छुआ नहीं जा सकता, वे सिस्टम जिन्हें बदला नहीं जा सकता, और वे विनियमों (regulations) जिनका पालन करना अनिवार्य है। प्रतिबंध बाधाएँ नहीं हैं; वे सही उत्तर की परिभाषा का आधा हिस्सा हैं।
एक उपयोगी अनुशासन। पूछे जाने वाले प्रश्न (ask) में मौजूद हर विशेषण (adjective) के लिए, वह माप (measurement) लिखें जो इसे निपटाने (settle) के लिए उपयोगी हो, और वह प्रतिबंध (constraint) जो इसे सीमित करता है। यदि आप टेस्ट नहीं लिख सकते, तो आपने अनुरोध को शुरू करने के लिए पर्याप्त रूप से समझा नहीं है।
जब पहले ड्राफ्ट को बनाना (generate) सस्ता होता है, तो स्पेक (spec) ही यह बताती है कि ड्राफ्ट अच्छा है या नहीं। एक सटीक स्पेक एक पुनर्भोग्य (reusable) निर्णय है। यह हर संभावित उत्तर को एक ही तरह से ग्रेड देती है।
स्वतंत्र, सत्यापनीय उप-समस्याएँ
पत्थर को जाँच योग्य छोटे टुकड़ों में तोड़ें
एक बड़ी समस्या का मूल्यांकन इसलिए कठिन होता है क्योंकि यह पता लगाना मुश्किल होता है कि कौन सा हिस्सा गलत है। विभाजन (Decomposition) इसे उन उप-समस्याओं में संरचित करता है जो प्रत्येक अपने आप में इतनी छोटी होती हैं कि उन्हें अलग से सत्यापित किया जा सके। अच्छे विभाजन में दो गुण होते हैं।
- स्वतंत्रता: उप-समस्याएँ एक-दूसरे से जितना कम हो सकें उतनी कम ओवरलैप करती हैं, ताकि एक में बदलाव दूसरे को चुपचाप तोड़े नहीं। जब भाग स्वतंत्र होते हैं, तो उन्हें समानांतर रूप से काम किया जा सकता है, परखा जा सकता है और यहां तक कि स्वचालित भी किया जा सकता है, और एक विफलता फैलने के बजाय स्थानीय स्तर पर सीमित रहती है।
- सत्यापनीयता: प्रत्येक उप-समस्या का अपना सफलता परीक्षण होता है, ताकि आप पूरा समूह बनाने से पहले पुष्टि कर सकें कि वह हल हो गई है। वह भाग जिसकी जाँच नहीं की जा सकती, उसे भरोसा नहीं किया जा सकता।
एक अच्छी तरह से विभाजित समस्या यह भी बताती है कि सीमित मानवीय निर्णय क्षमता को कहाँ लगाना है। अधिकांश उप-समस्याएँ रूटीन होती हैं और इन्हें स्वचालित प्रणाली या जूनियर कर्मचारी को सौंपा जा सकता है और उनके परीक्षण के विरुद्ध जाँची जा सकती है। एक या दो उप-समस्याएँ मूल बिंदु (crux) होती हैं, जिनमें उच्च अनिश्चितता और उच्च परिणाम होते हैं, और जिनमें आत्मविश्वास के साथ गलती करना आसान होता है। विशेषज्ञ का ध्यान इन पर बना रहता है।
एक भ्रामक विभाजन का ध्यान रखें: ऐसे भाग जो केवल अलग होने जैसे लगते हैं लेकिन एक छिपी हुई निर्भरता साझा करते हैं, जिससे "पूर्ण" टुकड़े एक कार्यशील समग्र में नहीं बन पाते। विभाजन का परीक्षण यह है कि क्या प्रत्येक भाग को, प्रत्येक सत्यापित करके, हल करने से मूल समस्या वास्तव में हल हो जाती है।
प्रश्न उत्तर की सीमा तय करता है
गंदी प्रश्न, आत्मविश्वासी गंदी उत्तर
चाहे आप किसी स्टेकहोल्डर, डेटासेट, या स्वचालित प्रणाली से प्रश्न पूछें, आपके प्रश्न की सटीकता उत्तर की उपयोगिता की सीमा तय करती है। एक अस्पष्ट प्रश्न शोर मचाकर विफल नहीं होता। यह उस प्रश्न का एक प्रवाहपूर्ण, आत्मविश्वासी और संभाव्य उत्तर लौटाता है जिसे आप पूछने का इरादा नहीं कर रहे थे, और वह उत्तर पूर्ण प्रतीत होता है।
एक अस्पष्ट डेटा अनुरोध पर विचार करें: "हमें हमारे सर्वोत्तम ग्राहक भेजें।" हर महत्वपूर्ण शब्द अपरिभाषित है। 'सर्वोत्तम' किस आधार पर: कुल राजस्व, मार्जिन, रिटेंशन, वृद्धि दर, या रेफरल्स? किस अवधि के लिए: जीवनकाल, पिछले बारह महीने, या इस तिमाही? कौन से ग्राहक गिने जाएंगे: केवल सक्रिय, चर्न्ड (churned) सहित, या ट्रायल्स सहित? डेटासेट खुशी-खुशी उस संस्करण का उत्तर देगा जो क्वेरी में संयोगवश कोड किया गया है, और अनुरोधकर्ता इसे उसी तरह कार्रवाई के लिए उपयोग करेगा जैसे यह उसका मस्तिष्क में मौजूद संस्करण था।
एक सटीक प्रश्न चार चीजों को पक्का करता है: सटीक मात्रा या इकाई, वह जनसंख्या जिस पर यह लागू होता है, समय की अवधि, और टाई-ब्रेकर या थ्रेशोल्ड। वही अनुशासन एक व्यक्ति के लिए भी लागू होता है ("जब आप 'सर्वोत्तम' कहते हैं, तो क्या आपका मतलब इस साल सबसे लाभदायक है, या नवीनीकरण की सबसे अधिक संभावना रखने वाला?") और एक स्वचालित प्रणाली के लिए भी, जहां एक अपर्याप्त रूप से निर्दिष्ट प्रॉम्प्ट गलत प्रश्न का आत्मविश्वासी उत्तर देता है।
व्यावसायिक कौशल यह पहचानना है कि अस्पष्टता उत्तर आने से पहले है, क्योंकि एक आत्मविश्वासी गलत उत्तर को बाद में पकड़ना महंगा होता है। प्रश्न में सटीकता बाद में सुधार से सस्ती होती है।
आपका लीवरेज अब कहाँ स्थित है
एक प्रथम प्रतिलेख (First Draft) सस्ता है; फ्रेमिंग और निर्णय नहीं
सूतकों को एक साथ जोड़ें। जब लगभग किसी भी चीज़ की एक संभाव्य प्रथम संस्करण (plausible first version) मांग पर तैयार किया जा सकता है, तो मूल्यवान कार्य वह है जिसे स्वचालित प्रणाली आपके लिए नहीं कर सकती: यह तय करना कि कौन सा समस्या हल करने लायक है, यह निर्दिष्ट करना कि "सही" का अर्थ क्या है, समस्या को इस प्रकार विभाजित करना कि उसे जांचा जा सके, प्रश्न को सटीक रूप से पूछना, और यह निर्णय लेना कि वापस आया उत्तर वास्तव में विनिर्देश (spec) को पूरा करता है या नहीं।
किसी भी अस्पष्ट कार्य में, एक भी प्रतिलेख (draft) बनाने से पहले, इस फ्रेमिंग चेकलिस्ट को साथ रखें:
- समस्या: प्रस्तुत लक्षण क्या है, और मूल समस्या क्या है? गलत समस्या को हल करने का खर्च क्या होगा?
- सफलता: "पूर्ण और सही" होने के लिए परीक्षण योग्य मानदंड क्या हैं? क्या दो लोग इस बात पर असहमत हो सकते हैं कि क्या प्रत्येक मानदंड पूरा हुआ है? यदि हाँ, तो इसे और स्पष्ट करें।
- प्रतिबंध: समाधान को किन सीमाओं का पालन करना चाहिए: बजट, समयसीमा, डेटा, प्रणालियाँ, नियम?
- अmbito: क्या जानबूझकर अambito के बाहर है?
- विभाजन: यह किस प्रकार के स्वतंत्र, व्यक्तिगत रूप से सत्यापन योग्य उप-समस्याओं में विभाजित होता है? मानवीय निर्णय के लिए कौन सी समस्या मूल बिंदु (crux) है?
- प्रश्न: किसी व्यक्ति, डेटासेट या प्रणाली के लिए किसी भी पूछताछ के मामले में, क्या मापदंड, जनसंख्या, समय-अवधि (window), और टाई-ब्रेकर (tie-breaker) स्पष्ट रूप से निर्धारित हैं? कौन सी अस्पष्टता एक आत्मविश्वास से भरा गलत उत्तर लौटा सकती है?
- निर्णय: जब उत्तर आता है, तो कौन सा परीक्षण मुझे बताता है कि यह सही है, न कि केवल प्रवाहमान (fluent)?
इस युग के पेशेवर पहले ड्राफ्ट के सबसे तेज उत्पादक नहीं हैं। वे व्यक्ति हैं जो समस्या को इतनी अच्छी तरह से फ्रेम करते हैं कि एक अच्छा उत्तर जाँच योग्य बन जाता है, और एक गलत उत्तर दिखाई देने लगता है।
आप आगे क्या ले जा रहे हैं
दो वाक्य जो याद रखने लायक हैं
आपने लक्षण और समस्या को अलग करने, स्पष्ट प्रतिबंधों के साथ परीक्षण योग्य सफलता मानदंड लिखने, समस्या को स्वतंत्र और सत्यापनीय भागों में विभाजित करने, और प्रश्न को इतना तीक्ष्ण बनाने का अभ्यास किया है कि यह एक आत्मविश्वास से भरा गलत उत्तर वापस नहीं कर सके। ये चार चालें एक ही कौशल हैं: फ्रेमिंग (समस्या को सही ढंग से परिभाषित करना)।
गलत समस्या को अच्छी तरह हल करना ज्ञान-आधारित कार्य में सबसे महंगा गलती है, क्योंकि यह सफलता जैसा दिखता है। और आपके प्रश्न की सटीकता किसी भी उत्तर की सीमा तय करती है, चाहे वह किसी व्यक्ति, डेटासेट, या स्वचालित प्रणाली से हो।
पहला ड्राफ्ट बनाना अब सस्ता है और और भी सस्ता हो रहा है। समस्या को फ्रेम करना, स्पेसिफिकेशन (spec) लिखना, और परिणाम का मूल्यांकन करना वही जगह है जहां एक पेशेवर की लिवरेज (प्रभावीता) निहित होती है। चेकलिस्ट साथ रखें। तीक्ष्ण प्रश्न पूछें। शुरू करने से पहले 'पूर्ण' (done) की परिभाषा तय करें।