ऐसा क्या करना है कि परियोजनाएं योजना की तुलना में 2-3 गुना अधिक समय नहीं लेती हैं? भाग २

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

• सुनिश्चित करें कि समय सीमा वास्तव में तंग है
• अवास्तविक समय-सीमा वाली परियोजनाओं को न लें
• "रेंगने वाली लहर" विधि का उपयोग करके योजना बनाएं
• परियोजना मूल्यांकन की समय-समय पर समीक्षा करें
• अनुभवजन्य रूप से परियोजना का मूल्यांकन करें
• प्रारंभिक मूल्यांकन में एक टीम को संलग्न करें

सुनिश्चित करें कि समय सीमा वास्तव में तंग है

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

अवास्तविक समय-सीमा वाली परियोजनाओं को न लें

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

"रेंगने वाली लहर" विधि का उपयोग करके योजना बनाएं

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

परियोजना मूल्यांकन की समय-समय पर समीक्षा करें

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

अनुभवजन्य रूप से परियोजना का मूल्यांकन करें

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

प्रारंभिक मूल्यांकन में एक टीम को संलग्न करें

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

संदर्भ

सॉफ्टवेयर विकास की जटिलता का आकलन करने में दस घातक पाप