10.15

View in English

10.15 आकलन और पूर्वानुमान

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

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

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

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

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

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

सिफ़ारिशें

आकलन, लक्ष्य और प्रतिबद्धता को अलग रखें

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

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

समझें आकलन क्यों गलत होते हैं, और किस दिशा में

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

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

विघटन और विशेषज्ञ निर्णय का उपयोग करें, और उनकी सीमाएँ जानें

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

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

अपने स्वयं के प्रवाह डेटा से प्रायिकतावादी पूर्वानुमान लगाएँ

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

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

बड़े कार्यक्रमों के लिए बाहरी दृष्टिकोण अपनाएँ

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

छोटे हिस्सों में बाँटकर कम आकलन करें, और विलंब की लागत के अनुसार क्रम तय करें

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

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

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

दृष्टिकोणफ़ायदेनुकसान
एकल-तिथि आकलनसरल; जो हितधारक माँगते हैं वहीसटीक रूप से गलत; जोखिम छुपाता है; अनजाने में प्रतिबद्धता बन जाता है
थ्री-पॉइंट / PERT आकलनअनिश्चितता को खुले में लाता है; सस्ताफिर भी एक अनुमान है; सूत्र झूठी कठोरता का आभास देता है
स्टोरी पॉइंट्स / टी-शर्ट साइज़तेज़; क्रम-निर्धारण और मोटी क्षमता के लिए अच्छाघंटे नहीं हैं; वेलोसिटी गणित एकल तारीखों को चुपके से वापस ले आती है
प्रायिकतावादी प्रवाह पूर्वानुमानप्रमाण-आधारित; स्वतः-अद्यतन; ईमानदार सीमाएँइतिहास और स्थिर प्रवाह चाहिए; कम “निश्चित” दिखता है
रेफरेंस क्लास फ़ोरकास्टिंगबड़े कार्यक्रमों पर आशावाद को सुधारता हैतुलनीय पिछले प्रयास चाहिए; सुनने में निराशाजनक
#NoEstimates (छोटे टुकड़े)अपव्यय हटाता है; गिनती से पूर्वानुमानअनुशासित टुकड़ों की ज़रूरत; आँकड़ा चाहने वाले फंडरों के लिए असहज

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

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

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

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

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

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

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

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

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

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

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

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

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

उदाहरण

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

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

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

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

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

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

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

  • एकल-तिथि प्रतिबद्धताएँ: एक सीमा जो एक आँकड़े में सिमट जाती है, फिर प्रमाणों से परे उसका बचाव किया जाता है।
  • आकलन-शोधन (estimate laundering): एक आशावान अनुमान जो शृंखला में ऊपर पहुँचते-पहुँचते एक अनुबंधित वादे में सख़्त हो जाता है।
  • शेड्यूल इंजन के रूप में वेलोसिटी: एक सटीक तारीख बनाने के लिए स्टोरी पॉइंट्स को वेलोसिटी से गुणा करना।
  • अंदाज़े से पैडिंग: पहले अनुमान पर टिका दूसरा अनुमान, जिसे दबाव में बातचीत करके हटा दिया जाता है।
  • केवल आंतरिक दृष्टिकोण: समान कार्यक्रमों में वास्तव में क्या लगा, इसे नज़रअंदाज़ करते हुए एक नई बॉटम-अप योजना पर भरोसा करना।
  • हर चीज़ का आकलन करना: ऐसे छोटे, समान टुकड़ों का आकार तय करना जिनका व्यक्तिगत आकलन किसी निर्णय को नहीं बदलता।
  • जमे हुए पूर्वानुमान: किकऑफ़ पर एक बार बनाई गई भविष्यवाणी जिसे वास्तविकता सामने आने पर कभी अद्यतन नहीं किया जाता।
  • सटीकता का प्रदर्शन (precision theatre): अनिश्चितता के शंकु के चौड़े मुँह पर घंटों को दो दशमलव स्थानों तक बताना।

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

  • स्तर 1, आरंभ (Initiate): आकलन अंतर्ज्ञान से बनाई गई एकल तारीखें होती हैं और उन्हें वादों के रूप में लिया जाता है; आकलन, लक्ष्य और प्रतिबद्धता के बीच कोई अंतर नहीं होता; पूर्वानुमान प्रतिक्रियाशील और तदर्थ होता है; समय-सीमा पार होना सबको आश्चर्यचकित करता है और इसका दोष टीम पर मढ़ा जाता है।
  • स्तर 2, विकास (Develop): कुछ संरचित आकलन मौजूद है (विघटन, स्टोरी पॉइंट्स, थ्री-पॉइंट आँकड़े), लेकिन प्रथा टीम-दर-टीम भिन्न होती है; आकलन अभी भी अधिकांशतः एकल आँकड़े होते हैं; तारीखों का अनुमान लगाने के लिए वेलोसिटी का उपयोग किया जाता है; पूर्वानुमान किकऑफ़ पर एक बार बनाए जाते हैं और शायद ही कभी पुनर्विचार किए जाते हैं।
  • स्तर 3, मानकीकरण (Standardize): पूरे संगठन में एक दस्तावेज़ीकृत मानक लागू किया जाता है: आकलन को बताई गई अनिश्चितता के साथ सीमाओं के रूप में व्यक्त किया जाता है, आकलन, लक्ष्य और प्रतिबद्धता को परिभाषा के अनुसार अलग-अलग रखा जाता है, टीमें थ्रूपुट को ट्रैक करती हैं और एक निश्चित लय पर पुनः-पूर्वानुमान करती हैं, और बड़े कार्यक्रमों के लिए रेफरेंस-क्लास तुलनाओं का उपयोग अनिवार्य होता है।
  • स्तर 4, प्रबंधन (Manage): प्रथा को डेटा से मापा और नियंत्रित किया जाता है। पूर्वानुमान की सटीकता को वास्तविक परिणामों के विरुद्ध ट्रैक किया जाता है और कैलिब्रेशन जाँचा जाता है, ताकि आप बता सकें कि क्या आपकी “80% तक” तारीखें वाकई दस में से आठ बार सही बैठती हैं; थ्रूपुट और साइकिल-टाइम बेसलाइन बनाए रखे जाते हैं; विलंब की लागत को परिमाणित किया जाता है; पूर्वानुमान के खिसकाव की सीमाओं के विरुद्ध निगरानी की जाती है और यह एस्केलेशन को ट्रिगर करता है; प्रतिबद्धताएँ आशावाद के बजाय प्रमाण के विरुद्ध बनाई जाती हैं।
  • स्तर 5, संचालन (Orchestrate): प्रवाह डेटा से प्रायिकतावादी पूर्वानुमान निरंतर होता है और भरोसेमंद माना जाता है क्योंकि कैलिब्रेशन के इतिहास ने इसे ईमानदार साबित किया है; प्रतिबद्धताएँ जानबूझकर लिए गए निर्णय होते हैं जो विश्वास को लागत के विरुद्ध तौलते हैं; काम को इतना छोटा बाँटा जाता है कि आकलन न्यूनतम हो और विलंब की लागत क्रम तय करे; आकलन को पोर्टफोलियो फंडिंग और जोखिम योजना के साथ एकीकृत किया जाता है, और जैसे-जैसे पूर्वानुमान बदलते हैं, संगठन नियमित रूप से दायरे को फिर से तय करता है और पुनर्संतुलन करता है, मूल आँकड़े का बचाव करने के बजाय योजना को प्रमाण के अनुसार ढालता है।

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

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

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

  • आकलन, लक्ष्य और प्रतिबद्धता को अलग-अलग रखें; इन्हें मिला देना ही वह तरीका है जिससे परियोजनाएँ अपने-आप से झूठ बोलना शुरू करती हैं।
  • आकलन ज्ञात दिशाओं में व्यवस्थित रूप से गलत होते हैं: अनिश्चितता का शंकु शुरुआती काम को चौड़ा करता है, और योजना भ्रम आशावाद को डिफ़ॉल्ट बना देता है।
  • ताज़े अनुमानों की तुलना में मापे गए थ्रूपुट से प्रायिकतावादी पूर्वानुमान को प्राथमिकता दें; सीमाएँ और विश्वास स्तर बताएँ, और लगातार पुनः-पूर्वानुमान करें।
  • बड़े कार्यक्रमों पर, जहाँ आशावाद सबसे महँगा पड़ता है, रेफरेंस-क्लास फ़ोरकास्टिंग के साथ बाहरी दृष्टिकोण अपनाएँ (अध्याय 10.1)।
  • छोटे टुकड़ों में बाँटें ताकि व्यक्तिगत आकलन मायने रखना बंद कर दें, और अंतर्ज्ञान के बजाय विलंब की लागत के अनुसार क्रम तय करें।
  • आकलन तभी करें जब वह किसी निर्णय को बदले; अन्यथा यह अपव्यय है। देखें अध्याय 10.6 (प्रोजेक्ट मैनेजमेंट), 11.2 (डिलीवरी), 11.3 (क्यूइंग थ्योरी), और 1.5 (निर्णय-निर्माण और गवर्नेंस)।

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

  • Steve McConnell, Software Estimation: Demystifying the Black Art.
  • Daniel Vacanti, Actionable Agile Metrics for Predictability and When Will It Be Done? (प्रवाह डेटा से प्रायिकतावादी पूर्वानुमान)।
  • Troy Magennis, Forecasting and Simulating Software Development Projects (मोंटे कार्लो पद्धतियाँ)।
  • Bent Flyvbjerg and Dan Gardner, How Big Things Get Done (रेफरेंस क्लास फ़ोरकास्टिंग और मेगाप्रोजेक्ट्स)।
  • Daniel Kahneman, Thinking, Fast and Slow (योजना भ्रम और बाहरी दृष्टिकोण)।
  • Donald Reinertsen, The Principles of Product Development Flow (विलंब की लागत और क्यू अर्थशास्त्र)।
  • Vasco Duarte, NoEstimates: How to Measure Project Progress Without Estimating.
  • Frederick Brooks, The Mythical Man-Month (सॉफ़्टवेयर शेड्यूल गलत क्यों होते हैं)।
  • Todd Little, “Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty” (IEEE Software, 2006)।