परियोजना के दायरे के लिए निर्णय लेना: विकल्पों की तुलना करें

यह तुलना वास्तव में क्या तय कर रही है

यह लेख अमूर्त में “अच्छे विचारों” के बारे में नहीं है। यह परियोजना के दायरे के लिए निर्णय लेने में एक कठिन विकल्प के बारे में है: दायरे का विस्तार करें, इसे स्थिर करें, इसके एक भाग को काटें, या इसे फिर से क्रमबद्ध करें ताकि परियोजना समय पर पूरी हो सके। चार विकल्प। एक कैलेंडर।

यह सरल लगता है जब तक कि एक प्रायोजक कहता है कि लॉन्च की तारीख निश्चित है, एक डेवलपर कहता है कि एक विशेषता दो सप्ताह जोड़ेगी, और ग्राहक “बस एक और चीज” की मांग करता है। तब निर्णय अब स्वाद के बारे में नहीं होता। यह इस सवाल में बदल जाता है कि वर्तमान बजट, टीम की क्षमता, और समय सीमा के दबाव के बिना क्या जीवित रह सकता है।

इसे एक दायरा बोर्ड के रूप में सोचें, न कि एक दायरा इच्छा सूची के रूप में। एक परियोजना केवल इतनी ही परिवर्तन सहन कर सकती है इससे पहले कि कार्यक्रम ऐसे तरीकों से मुड़ने लगे जिनकी किसी ने योजना नहीं बनाई थी। यदि टीम पहले से ही सीमा के करीब है, तो एक और डिलीवर करने से पूरे योजना को टालने योग्य पुनः कार्य में धकेल सकता है।

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

विकल्पों की तुलना करने से पहले महत्वपूर्ण मानदंड

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

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

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

टीम की क्षमता सबसे सरल मानदंड है और यह वह है जिसे लोग अक्सर नजरअंदाज करते हैं। यदि टीम के पास पहले से ही एक रिलीज के लिए 3 इंजीनियर और 1 डिज़ाइनर प्रतिबद्ध हैं, तो एक नया अनुरोध 'मुफ्त' नहीं है सिर्फ इसलिए कि यह बैकलॉग में फिट होता है। क्षमता एक मूड नहीं है। यह एक सीमा है।

डेडलाइन का दबाव हर अन्य मानदंड को बदल देता है। एक विशेषता जो सप्ताह 2 में स्वीकार्य है, वह सप्ताह 8 में लापरवाह हो सकती है जब परीक्षण चक्र, अनुमोदन, और हैंडऑफ कार्य पहले से निर्धारित हैं। एक ही अनुरोध एक कैलेंडर तिथि के आधार पर "उचित" से "जोखिमपूर्ण" में बदल सकता है।

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

सामान्य दायरे के विकल्पों की साइड-बाय-साइड तुलना

नीचे दी गई तालिका चार विकल्पों की तुलना करती है जिनका सामना अधिकांश टीमें वास्तव में करती हैं। यह एक सिद्धांत अभ्यास नहीं है। यह व्यावहारिक शॉर्टलिस्ट है जो लोगों को एक बैठक में निर्णय लेने में मदद करती है, तीन में नहीं।

“योजना के अनुसार रखें” सुनने में सतर्क लगता है, लेकिन यह केवल तब सुरक्षित है जब योजना अभी भी यथार्थवादी हो। यदि कार्यक्रम में पहले से ज्ञात बाधाएं शामिल हैं, तो सब कुछ अपरिवर्तित रखना कमरे में सबसे जोखिम भरा विकल्प हो सकता है। एक जमी हुई खराब योजना अभी भी एक खराब योजना है।

“दायरा घटाएं” अक्सर असफलता के रूप में गलत समझा जाता है। यह नहीं है। कभी-कभी एक फीचर को छोड़ने से बाकी रिलीज को बनाए रखा जा सकता है, और यह व्यापार उस समय की तुलना में अधिक समझदारी है जब पूरी सूची अभी भी संभव है। सबसे अच्छे टीमें एक ट्रिम और एक पतन के बीच का अंतर जानती हैं।

“चरणों में विभाजित करें” तब सबसे अच्छा काम करता है जब पहले चरण का अपना वास्तविक मूल्य हो। यदि चरण 1 चरण 2 के बिना खड़ा नहीं हो सकता, तो विभाजन केवल सौंदर्यात्मक है। इस तरह का विभाजन कागज पर साफ दिखता है और बाद में समस्याएँ उत्पन्न करता है।

“डिले फीचर्स” सबसे साफ विकल्प है जब मूल्य वास्तविक हो लेकिन समय गलत हो। यह बाहरी निर्भरताओं वाले परियोजनाओं में सामान्य है, जैसे एक विक्रेता API, एक कानूनी समीक्षा, या एक सामग्री अनुमोदन चक्र। कुंजी जानबूझकर डिले करना है, न कि भटकाव द्वारा।

जब एक बड़ा दायरा इसके लायक हो

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

यहां एक मामला भी है जहां बड़ा दायरा भविष्य के काम को हटा देता है। यदि एक अतिरिक्त कार्य अब तीन अलग-अलग सुधारों से बचाता है, तो यह जोड़ना समझदारी हो सकती है। हालांकि, वह तर्क विशिष्ट होना चाहिए। “हमें यह कभी न कभी चाहिए हो सकता है” पर्याप्त नहीं है।

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

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

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

जब दायरा घटाना समझदारी भरा कदम है

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

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

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

यहाँ एक फ्रीलांसर को सुरक्षित रूप से कैसे भर्ती करें व्यावहारिक रूप से प्रासंगिक हो जाता है: एक स्पष्ट ब्रीफ वाला फ्रीलांसर मूल्यांकन करना आसान होता है, और एक छोटा ब्रीफ ईमानदार बनाए रखना आसान होता है। एक संकुचित दायरा गलतफहमी के छिपने के लिए कम स्थान देता है।

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

बिना अनुमान के निर्णय कैसे लें

एक पांच-चरणीय अनुक्रम का उपयोग करें। चरण 1: वर्तमान दायरे को एक वाक्य में लिखें। चरण 2: विचार किए जा रहे परिवर्तन को सूचीबद्ध करें। चरण 3: पहले से नामित छह मानदंडों के खिलाफ परिवर्तन को स्कोर करें। चरण 4: प्रत्येक मालिक से पूछें कि यदि परिवर्तन को मंजूरी दी जाती है तो क्या टूटता है। चरण 5: चार दायरा विकल्पों में से एक चुनें और कारण को रिकॉर्ड करें।

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

किसे शामिल होना चाहिए? न्यूनतम, उत्पाद मालिक, डिलीवरी लीड, और वह व्यक्ति जो उस निर्भरता के सबसे करीब है जो टूट सकती है। यदि विशेषता लॉन्च संदेश को प्रभावित करती है, तो विपणक को शामिल करें। यदि यह बिलिंग को प्रभावित करती है, तो वित्त या संचालन को शामिल करें। एक गायब आवाज “स्वीकृत” को दो दिन बाद “फिर से खोला गया” में बदल सकती है।

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

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

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

ईमानदार निर्णय: दबाव में कौन सा विकल्प आमतौर पर जीतता है

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

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

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

यदि आपकी परियोजना में पहले से ही एक नाजुक निर्भरता श्रृंखला है, तो छोटे विकल्प के साथ बने रहें जब तक कि जोड़ा गया दायरा बड़े नुकसान को रोकने में मदद न करे। वह एक वाक्य कई वास्तविक दुनिया की परियोजनाओं को एक आशावादी योजना से बेहतर ढंग से कवर करता है।

तेज़ दायरा निर्णयों के लिए त्वरित तालिका

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

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