अनुमान क्यों विफल होते हैं (और फिर भी क्यों ज़रूरी हैं)

• सॉफ़्टवेयर विकास में काम का अनुमान लगाना Complex क्षेत्र में आता है, और टीम कितनी भी अनुभवी हो, स्वभावतः सटीक अनुमान संभव नहीं है
• #NoEstimates आंदोलन इस वास्तविकता के खिलाफ एक वैध प्रतिक्रिया था कि अनुमानों का performance target की तरह दुरुपयोग होता है, लेकिन अनुमान को पूरी तरह ठुकराने से संगठन की coordination क्षमता खत्म हो जाती है
• अनुमान का असली मूल्य भविष्य बताना नहीं, बल्कि अनिश्चितता के बीच communication और coordination है, और यह बाहरी contract, टीमों के बीच dependency, और ROI निर्णयों के लिए अनिवार्य है
• Steve McConnell के Cone of Uncertainty के अनुसार, प्रोजेक्ट की शुरुआत में अनुमान की त्रुटि 4 गुना तक हो सकती है, और यह दायरा केवल सीखने के साथ ही संकरा होता है
• संगठनों को उस आदत को बदलना होगा जिसमें अनुमान को commitment में बदल दिया जाता है, और range-based, assumptions-explicit, progressive refinement वाली estimation पद्धति अपनानी होगी

---

#NoEstimates आंदोलन ने वास्तव में कौन-सी समस्या हल की

• बार-बार यह पैटर्न दोहराया जाता है कि टीम से उस समय अनुमान मांगा जाता है जब उसे समस्या के बारे में लगभग कुछ पता नहीं होता, फिर वही संख्या roadmap में चली जाती है और ग्राहकों से वादा बन जाती है
• जब वास्तविकता अनुमान से मेल नहीं खाती, तो टीम पर "deadline miss कर दी" का आरोप लगता है, जबकि वह शुरुआत से सहमति वाला deadline था ही नहीं
• मूल रोग यह है कि अनुमान, prediction न रहकर commitment में बदल जाता है
• "आओ अनुमान ही न लगाएँ" जैसा समाधान, खराब thermometer के जवाब में तापमान की अवधारणा को ही नकारने जैसा है
• Maarten Dalmijn के शब्दों में, अनुमान वास्तविक काम की मात्रा नहीं बदलता; किसी feature को बनने में जितना समय लगना है, उतना लगेगा
  • अनुमान जिस चीज़ को प्रभावित करता है, वह काम नहीं बल्कि उसके आसपास की expectations हैं
  • expectations को ईमानदारी और स्पष्टता से संभालना अपने-आप में पूरी तरह मूल्यवान काम है

संगठन को वास्तव में अनुमान की ज़रूरत क्यों होती है

• #NoEstimates बहस में एक बात लगभग गायब रहती है: अनुमान काम करने वाली टीम के लिए नहीं, उसके आसपास के संगठन के लिए होता है

• तीन ऐसी स्थितियाँ हैं जहाँ अनुमान अपरिहार्य है

• External commitments: ग्राहक contract, marketing campaign के साथ जुड़ी release, regulatory deadline जैसी स्थितियों में व्यवहार्यता समझने के लिए काम की अवधि का कोई मॉडल अनिवार्य है

  • "हम अनुमान नहीं लगाते" ऐसा जवाब ग्राहक को नहीं दिया जा सकता; इससे contract भी जा सकता है

• Inter-team dependencies: जब टीम B को टीम A के पूरा होने का इंतज़ार है, और टीम A कोई अनुमानित संकेत ही नहीं देती, तो टीम B योजना नहीं बना सकती

  • एक मोटा संकेत ("शायद 6 हफ्ते, अधिकतम 8 हफ्ते") चुप्पी से अनंत गुना बेहतर है; यह control नहीं बल्कि downstream टीम सदस्यों के प्रति सम्मान है

• ROI calculation: feature X या feature Y में क्या बनाना है, यह तय करने के लिए relative cost model चाहिए

  • अगर सब कुछ अगम्य मान लिया जाए, तो तर्कसंगत trade-off असंभव हो जाते हैं; और अगर अनुमान लगाना ही है, तो स्पष्ट assumptions के साथ structured guess बेहतर है

Joseph Pelrine ने अनुमान की अंतर्निहित कठिनाई कैसे दिखाई

• Joseph Pelrine यूरोप के पहले Certified Scrum Trainer थे, जिन्होंने social complexity science के lens से software agile का अध्ययन किया
• उन्होंने agile software development में काम करने वाले 300 से अधिक लोगों पर एक प्रयोग किया, जिसमें रोज़मर्रा की गतिविधियों को Cynefin framework (Dave Snowden का sensemaking model) के क्षेत्रों में रखा गया
  • Cynefin समस्याओं को Clear, Complicated, Complex, और Chaotic चार क्षेत्रों में बाँटता है
• काम का अनुमान लगाना लगातार और दोहराए जाने योग्य तरीके से Complex क्षेत्र में रखा गया
• Complicated और Complex का अंतर यहाँ मुख्य है:
  • Complicated क्षेत्र में cause-and-effect संबंध समझे जा सकते हैं, experts उन्हें trace कर सकते हैं, और विशेषज्ञता भरोसेमंद prediction दे सकती है
  • Complex क्षेत्र में cause-and-effect केवल बाद में समझ आता है, क्योंकि सिस्टम बहुत उलझा हुआ, context-dependent, और छोटे बदलावों के प्रति संवेदनशील होता है
• यही कारण है कि software development manufacturing नहीं है: आप लगभग हमेशा ऐसी चीज़ बना रहे होते हैं जो पहले मौजूद नहीं थी, वह भी एक अलग codebase और अलग team dynamics पर
  • carpenter वाली analogy इसलिए नहीं चलती कि cabinet दूसरी cabinet जैसी मोटे तौर पर हो सकती है, लेकिन एक feature दूसरी feature जैसी मोटे तौर पर नहीं होती
• बेहतरीन टीमें भी अनुमान में औसत स्तर तक ही पहुँचती हैं; कारण skill की कमी नहीं, बल्कि Complex क्षेत्र में accuracy की अंतर्निहित सीमा है
• लक्ष्य अनुमान को बिल्कुल सही बनाना नहीं, बल्कि उसकी अंतर्निहित अशुद्धि के बावजूद उपयोगी निर्णय लेना है

Cone of Uncertainty हमें क्या बताता है

• Steve McConnell का Cone of Uncertainty कहता है कि प्रोजेक्ट की शुरुआत में अनुमान की त्रुटि दोनों दिशाओं में 4 गुना तक हो सकती है
• जैसे-जैसे प्रोजेक्ट आगे बढ़ता है और अज्ञात बातें सुलझती हैं—requirements स्पष्ट होते हैं, architecture तय होता है, कठिन समस्याएँ मिलती और सुलझती हैं—वैसे-वैसे cone संकरा होता है
• विडंबना यह है कि अनुमान सबसे सटीक तब होता है जब काम लगभग पूरा होने वाला होता है, और वही समय होता है जब उसकी सबसे कम ज़रूरत होती है
  • शुरुआत में, जब वह सबसे उपयोगी हो सकता है और दिशा बदलना या प्रोजेक्ट रोकना संभव होता है, तब हमें सबसे कम जानकारी होती है
  • फिर भी ज़्यादातर संगठन ठीक उसी शुरुआती बिंदु पर सबसे कठोर commitment कर देते हैं
• इसके दो और महत्वपूर्ण संकेत हैं:
  • यह cone कुशल estimators के best-case को दर्शाता है; ज़्यादातर टीमें इससे भी कमजोर होती हैं
  • concept stage में तारीख तय कर देना planning नहीं, बल्कि इच्छा करना और उसके हिसाब से schedule बना देना है
  • यह cone समय से नहीं, अनिश्चितता हटाने वाले निर्णयों से संकरा होता है
  • scope definition, architecture के unknowns सुलझाना, असली code लिखना और कठिनाइयाँ पकड़ना cone को संकरा करते हैं; 3 हफ्ते सिर्फ़ meetings करने से नहीं
• stakeholders को साफ़-साफ़ बताना चाहिए कि "अनुमान की quality इस पर निर्भर करती है कि हम cone में कहाँ खड़े हैं"
  • पहले हफ्ते में 2 हफ्ते वाला सटीक नंबर नहीं दिया जा सकता, लेकिन एक range दी जा सकती है और यह बताया जा सकता है कि उसे संकरा करने के लिए क्या confirm होना चाहिए
  • ज़्यादातर stakeholders यह बात समझ लेते हैं; बस उन्हें कभी बताया ही नहीं गया कि वे range मांग सकते हैं

Fibonacci scale का उपयोग क्यों किया जाता है

• Fibonacci scale (1, 2, 3, 5, 8, 13, 21) की nonlinearity एक epistemic काम करती है
• 2 और 3 का अंतर सिर्फ़ "मोटे फर्क की पहचान" जैसा होता है, लेकिन 8 से 13 की छलांग यह encode करती है कि अनिश्चितता का band अनुमान से भी बड़ा है
  • 13-point story का मतलब "ठीक 13" नहीं, बल्कि "8 से साफ़ तौर पर ज़्यादा अनिश्चित, लेकिन 21 जितनी नहीं" वाली category है
• Fibonacci संख्याओं के बीच बढ़ता अंतर उस तरह को दर्शाता है जिस तरह complexity वास्तव में फैलती है
  • छोटी चीज़ों का अनुमान मोटे तौर पर लगाया जा सकता है, लेकिन बड़ी चीज़ों में unknowns, integration points, और अप्रत्याशित स्थितियाँ बढ़ जाती हैं, इसलिए prediction ज्यामितीय रूप से कठिन होती जाती है
  • 21 (या 13) से बड़ी story का अर्थ अक्सर यह होता है कि "हम अभी तक काम को समझते नहीं हैं, इसलिए इसे तोड़ना होगा"
• Fibonacci estimation का एक और कम आंका गया उपयोग है: अनुमान वाली बातचीत के दौरान क्या होता है
  • अगर एक व्यक्ति 3 कहता है और दूसरा 13, तो संख्या खुद कम महत्वपूर्ण है; असली प्रश्न यह है कि एक ही टीम एक ही story को इतना अलग क्यों देख रही है
  • हो सकता है किसी एक ने dependency देखी हो, या ticket में न लिखा गया technical constraint पता हो
• अनुमान का सबसे बड़ा मूल्य संख्या नहीं, बल्कि यह जाँचना है कि shared understanding बनी है या नहीं
  • अगर यह forcing function हटा दिया जाए, तो shared understanding अक्सर तब तक नहीं बनती जब तक कोई व्यक्ति काम के तीसरे दिन छिपी complexity से नहीं टकरा जाता
• यही वजह है कि "estimation meeting बेकार है" वाले #NoEstimates तर्क से सहमत होना मुश्किल है: अगर उसे अच्छी तरह चलाया जाए, तो उसी बातचीत में alignment बनता है
  • खराब तरीके से चलने वाली meeting का जवाब meeting को खत्म करना नहीं है

Commitment Trap और उससे बचने के तरीके

• #NoEstimates आंदोलन जिस सबसे गहरी dysfunction पर प्रतिक्रिया था, वह यह है कि अनुमान logic से नहीं, social pressure से commitment में बदल जाता है
• एक संबंधित failure mode यह है: जो लोग काम नहीं करेंगे, वही timeline बनाकर टीम पर फेंक देते हैं; इससे गलत अनुमान + उस संख्या के प्रति ownership के बिना टीम जैसा सबसे खराब संयोजन बनता है
  • जब वास्तविकता अलग निकलती है, तो किसी को पता नहीं होता ज़िम्मेदार कौन है, इसलिए सब एक-दूसरे को दोष देते हैं
  • अनुमान की ownership हमेशा उन लोगों के पास होनी चाहिए जो काम करेंगे; दूसरों पर अनुमान थोपना optimism नहीं, बल्कि blame game की शुरुआत है
• जब deadline obsession जम जाती है, तो हर बातचीत "deadline कैसे पूरी करें?" पर सिमट जाती है, और क्या हम सही चीज़ बना भी रहे हैं यह सवाल गायब हो जाता है
• ज़्यादातर संगठनों को तीन चीज़ों में फर्क करना सीखना चाहिए:
  1. Estimate: मौजूदा uncertainty level पर आधारित probabilistic prediction, जिसके साथ range और assumptions का स्पष्ट बयान होना चाहिए
     • उदाहरण: "अगर requirements नहीं बदलतीं और अगले शुक्रवार तक API सवालों के जवाब मिल जाते हैं, तो हमें 4–6 हफ्ते लगेंगे"
  2. Plan: परिणाम नहीं, बल्कि प्रक्रिया के बारे में commitment
     • उदाहरण: "हम 2 हफ्ते काम करके प्रगति की समीक्षा करेंगे और updated prediction देंगे"
  3. Commitment: परिणाम को लेकर वादा, जो कम ही किया जाना चाहिए और तभी जब cone काफ़ी संकरा हो चुका हो
     • concept stage की शुरुआत में commitment करना साहस नहीं, लापरवाही है
     • अगर commitment देने का दबाव हो, तो timeline की जगह priority के प्रति commitment देने की कोशिश करें; और अगर वह भी संभव न हो, तो confidence level को commitment का हिस्सा बनाइए
• अनुमान को बोलते ही commitment मान लेने की संगठनात्मक आदत ही dysfunction की जड़ है
  • #NoEstimates का राजनीतिक समाधान—संख्याएँ ही न बोलना—समझ में आता है, लेकिन उसकी कीमत यह है कि संगठन resource allocation, dependency sequencing, और बाहरी stakeholders से ईमानदार संवाद की क्षमता खो देता है
• बेहतर समाधान है cone को सिखाना, stakeholders को शिक्षित करना, और हर संख्या देते समय estimate और commitment का फर्क स्पष्ट करना
  • यह अनुमान को ठुकराने से कठिन और समय लेने वाला है, लेकिन यह भरोसा टूटने की स्थितियों से भागने के बजाय भरोसा बनाता है

अच्छे अनुमान के व्यवहारिक तरीके

• देर से estimate करें: cone केवल सीखने से संकरा होता है, इसलिए पहले spike करें, exploratory code लिखें, और integration करने वाली टीमों से बात करें
  • अर्थपूर्ण संख्या देने लायक सीखने से पहले नंबर देने के दबाव का विरोध करना चाहिए
• शुरुआत में ज़रूरत से ज़्यादा decomposition न करें: uncertainty देखते ही काम को छोटे हिस्सों में तोड़ने का मन होता है, लेकिन सिर्फ़ breakdown कर देने से reliable estimate नहीं बनता
  • बहुत विस्तृत upfront planning अक्सर rigid हो जाती है, और टीम उससे तब भी चिपकी रहती है जब वह वास्तविकता को दिखाना बंद कर चुकी होती है; इससे अंततः अंतर और ज़्यादा भ्रम पैदा करता है
  • शुरुआत ऐसी सरल योजना से करें जिसे समायोजित करना आसान हो
• point estimate नहीं, range दें: "3–5 हफ्ते" कहना "4 हफ्ते" कहने जितना ही उपयोगी है, लेकिन ज़्यादा ईमानदार है
  • अगर single number ही देना पड़े, तो range का midpoint दें और यह भी बता दें कि वह midpoint है
  • stakeholders के साथ Cone of Uncertainty के उपयोग पर सहमति बनाइए और हर estimate देते समय उसका संदर्भ दीजिए
• assumptions को दृश्य बनाइए: अनुमान assumptions जितना ही अच्छा होता है, इसलिए यह साफ़ होना चाहिए कि scope नहीं बदलेगा, कोई खास technical approach अपनाई जाएगी, या दूसरी टीम किसी खास तारीख तक कुछ deliver करेगी
  • दिमाग़ में छिपी assumptions सबसे बुरे समय पर उभरने वाली गलतफ़हमी बन जाती हैं
• accuracy को track करें, लेकिन दंड न दें: उद्देश्य blame नहीं, calibration होना चाहिए
  • जो टीमें 6 महीनों तक साथ estimate करती हैं और accuracy की समीक्षा करती हैं, उनमें यह shared sense विकसित होता है कि वे व्यवस्थित रूप से कहाँ overestimate या underestimate करती हैं
  • अगर गलत अनुमान पर दंड दिया जाएगा, तो टीमें रक्षात्मक होकर अनुमान फुलाने लगेंगी, और फुलाया हुआ अनुमान ईमानदार लेकिन अनिश्चित अनुमान से भी कम उपयोगी होता है
  • Complex क्षेत्र में गलत अनुमान character flaw नहीं, बल्कि उस क्षेत्र की प्रकृति है
• 8 से ऊपर हो तो split करें: Fibonacci में 13 या 21 point की story लगभग हमेशा ऐसी छिपी complexity रखती है जो अभी सामने नहीं आई है
  • split करने की क्रिया आपको साफ़-साफ़ बताने पर मजबूर करती है कि आप वास्तव में क्या जानते हैं
  • अक्सर पता चलता है कि 3 sub-stories में से 2 छोटी हैं, और सारी uncertainty एक ही हिस्से में केंद्रित है

एक असुविधाजनक सच, दोनों पक्षों के लिए

• अनुमान calculation नहीं, बल्कि communication का एक रूप है; इसका उद्देश्य भविष्य बताना नहीं, बल्कि अनिश्चितता के बीच coordination और decision-making को सहारा देना है
• अनुमान की failure modes random नहीं, बल्कि systematic हैं: बहुत जल्दी अनुमान लगाना, range को point की तरह लेना, अनुमान को commitment की तरह लेना, Cone of Uncertainty की epistemic स्थिति को नज़रअंदाज़ करना, और executors पर अनुमान थोपना
• Dalmijn के अनुसार Complex Work Estimation Fallacy यह विश्वास है कि अगर हम बार-बार अनुमान लगाएँ, process सुधारें, और लंबे समय तक साथ काम करें, तो आखिरकार सटीक अनुमान आने लगेंगे
  • Complex क्षेत्र में estimation accuracy की सीमा team maturity का function नहीं, बल्कि खुद उस क्षेत्र का function है
  • आप बेहतर हो सकते हैं, लेकिन बिल्कुल accurate नहीं; और इन दोनों को गड़बड़ाने पर संगठन टीम को ऐसी चीज़ के लिए दंडित करता है जो मूल रूप से उसके नियंत्रण से बाहर है
• अनुमान से इनकार करना अक्सर coordination game से बाहर निकल जाना भर है
  • पूरी तरह स्वतंत्र रूप से चलने वाली, continuous deployment करने वाली, और बिना external commitments वाली टीमों में यह संभव है, लेकिन ज़्यादातर करियर ऐसे context में नहीं होते
• असली चुनाव "खराब अनुमान" बनाम "कोई अनुमान नहीं" नहीं है, बल्कि अचेतन और कम-गुणवत्ता वाले अनुमान (जो संगठन आपके बिना भी बना लेगा) बनाम स्पष्ट, विनम्र, range-based, assumptions-visible अनुमान है
• क्योंकि काम का अनुमान Complex क्षेत्र में आता है, इसे complexity mindset से लेना चाहिए: explore, observe, respond, estimate, track, calibrate की पुनरावृत्ति
• cone इंतज़ार से नहीं, सीखने से संकरा होता है