परियोजना की अवधि का अनुमान। क्यों यह लगभग हमेशा बहुत समझ में आता है और इसके बारे में क्या करना है

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

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

त्रुटि की जड़

जब हम किसी कार्य के कार्यान्वयन की अवधि का मूल्यांकन करते हैं, तो हम सबसे संभावित आंकड़ा निर्धारित करते हैं। यह एक बिंदु पर या तीन बिंदुओं पर विशेषज्ञ मूल्यांकन हो सकता है, जैसा कि पीईआरटी में। एक जटिल परियोजना में, यह पैरामीट्रिक मॉडलिंग हो सकता है। सभी मामलों में, हम एक ही गलती करते हैं। तथ्य यह है कि सभी शास्त्रीय अनुमान विधियों में यह माना जाता है कि हमारे पास अनुमानित मूल्य का एक सामान्य वितरण है - गॉस के अनुसार। सिद्धांतवादी इस वितरण के बहुत शौकीन हैं।

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

इस तरह के वितरण के एक उदाहरण के रूप में तार्किक वितरण पर विचार करें। यह हमें वितरण के इस वर्ग की विशेषताएं दिखाएगा। सामान्य वितरण के लिए, माध्यिका और गणितीय अपेक्षा चरम से परे हैं:



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

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

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

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

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

क्या करें?

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

ब्रूक्स विधि : हम प्रोग्राम के कार्यान्वयन की अवधि "हेड-ऑन" पर विचार करते हैं (उपयोगकर्ता स्वयं प्रोग्रामर है) और सॉफ्टवेयर उत्पाद के लिए 3 से गुणा करें (उपयोगकर्ता लोगों का एक असीमित चक्र है) या सॉफ्टवेयर कॉम्प्लेक्स (वर्तमान वास्तविकताओं में - माइक्रोसिस्ट्रेट्स का एक सेट) और सिस्टम सॉफ्टवेयर उत्पाद के लिए 9 ( वर्तमान वास्तविकताओं में, संबंधित बुनियादी ढांचे के घटकों का एक सेट)। जहां से ये गुणांक आते हैं, ब्रूक्स की पुस्तक "पौराणिक मानव-महीना" के पहले अध्याय में सैद्धांतिक रूप से उचित ठहराया गया है और 1975 के इस विवरण को वर्तमान वास्तविकताओं में बदल दिया गया है।

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

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

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

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

समय का औचित्य

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

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