आदर्श आवश्यकताएं वापस आ रही हैं

पिछले भागों में

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

दूसरे भाग में, मैंने पूर्व-परियोजना की लगातार समस्याओं के बारे में बात की।

अंतिम पोस्ट में, हमने मूल सिद्धांतों के पहले भाग पर चर्चा की:

• आईटी सिस्टम का डिजाइन और आईटी उत्पादों का वर्गीकरण।
• वी-मॉडल का स्तर और सिस्टम जीवन चक्र।
• वित्तीय परिसंपत्ति के रूप में प्रणाली पर एक नजर।

इस नोट में, हम "कैसे करें" के विवरण के साथ समाप्त करेंगे, आगे चर्चा करेंगे कि क्या करना है अगर यह सही तरीके से काम नहीं करता है।

आप इस नोट से क्या सीखेंगे:

• अनिश्चितता और डिजाइन चरणों के शंकु पर।
• मूल्यांकन कैसे काम करता है।
• प्री-प्रोजेक्ट चरण के कार्यों के पूर्ण दायरे और एक ही समय में महसूस किए गए मूल्यों के बारे में।
• पूर्व-परियोजना के लिए पर्याप्त संसाधन कैसे प्राप्त करें।

यदि आप चक्र के अगले भागों की प्रतीक्षा नहीं करना चाहते हैं, तो आप मेरी रिपोर्ट का वीडियो देख सकते हैं, जिसके आधार पर लेखों की यह श्रृंखला लिखी गई है।

सिस्टम जीवन चक्र और अनिश्चितता के शंकु

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



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

• जब हमारे पास आधे पृष्ठ के संक्षिप्त में व्यक्त विचार होता है, तो लागत और वापसी का प्रसार परिमाण के कई आदेशों तक पहुंच सकता है।

• जब व्यावसायिक आवश्यकताएं होती हैं, जबकि व्यवसाय योजना या व्यवसाय मॉडल विकसित होता है, तो हम ऑर्डर में लागत / वापसी को कम करते हैं।

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

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

• केवल तकनीकी डिज़ाइन व्यवसाय के लिए स्वीकार्य त्रुटि के साथ लगभग सटीक अनुमान प्रदान करता है।

इससे क्या होता है:

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

• आपको यह भी समझने की आवश्यकता है कि आप एक विचार के साथ नहीं आ सकते हैं और तुरंत लागत को कम कर सकते हैं। जब आपको बताया जाता है कि यहां 20 मिलियन हैं और यह सुनिश्चित करने के लिए, केवल एक संक्षिप्त - विश्वास नहीं है, तो यह नहीं है।

• व्यावसायिक आवश्यकताओं और वैचारिक विकास की आवश्यकता है, क्योंकि वे अनिश्चितता को दूर करते हैं, लेकिन परियोजना शुरू नहीं होने पर यह बंद नहीं हो सकता है। नतीजतन, चरण जितना संभव हो उतना सस्ता होना चाहिए, लेकिन गुणवत्ता के तरीके से अनिश्चितता को दूर करना चाहिए।

मूल्यांकन कैसे काम करता है?

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



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

मूल्यांकन मोड के दृष्टिकोण से परियोजना के चरण इस प्रकार हैं:

• जब एक विचार आधे पृष्ठ के संक्षिप्त में व्यक्त किया जाता है, तो हम सादृश्य द्वारा मूल्यांकन करने में सक्षम होते हैं।

• जब हमने व्यावसायिक आवश्यकताओं, व्यवसाय योजना या व्यवसाय मॉडल पर काम किया है, तो हम सिस्टम के प्रमुख मापदंडों को उजागर कर सकते हैं और एक बड़े पैमाने पर कारक का उपयोग करके सादृश्य द्वारा मूल्यांकन कर सकते हैं।

• अवधारणा कई दर्जन भागों और कार्यों में एक विभाजन देती है, जो आपको सादृश्य द्वारा किए गए अनुमानों को संक्षेप में प्रस्तुत करने और प्रमुख जोखिम जोखिम योजना की गणना करने की अनुमति देती है।

• संदर्भ की शर्तें कार्य के प्रकार से आपूर्तिकर्ताओं के दायित्वों के साथ समानता से सिस्टम के कुछ हिस्सों के मूल्यांकन को प्रतिस्थापित करती हैं। सादृश्य द्वारा बनाए गए भागों के अनुमान विशेषज्ञ के अनुमानों में बदल दिए जाते हैं। मूल्यांकन में त्रुटि के जोखिम आपूर्तिकर्ताओं को दिए जाते हैं।

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

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

एक और सामान्य विचार है: "व्यावसायिक आवश्यकताओं को मापने योग्य नहीं होना चाहिए।" याद रखें - यह एक झूठ है!

प्री-प्रोजेक्ट में आपको क्या हासिल करना है

पिछले भागों में, समस्याओं के संदर्भ में इसका उल्लेख किया गया था। अब संक्षेप में दोहराएं कि किसी भी पूर्व-परियोजना में कौन से कार्य निर्धारित और पूरे किए जाने चाहिए:

1. लागत की योजना बनाने और जाने / निर्णय न लेने के लिए समय और लागत को समझें। प्रभाव की भविष्यवाणी करना और इस निर्णय में तेजी लाने के लिए वापसी करना उचित है।
2. सिस्टम बेचने के लिए:
   
   
   • ग्राहक को उसके लक्ष्यों की समझ दिखाएं।
   • उपयोगकर्ताओं को उनकी समस्याओं का समाधान दिखाएं।
   • बजट के लिए बोली को सफलतापूर्वक पूरा करें (यह हमेशा होता है)।
3. स्वीकृति के लिए एक आधार बनाने के लिए (परिणाम की मात्रा और गुणवत्ता के लिए एक अनुबंध एक तकनीकी कार्य है), सभी पार्टियों की अपेक्षाओं के व्यावहारिक औचित्य के दृष्टिकोण से परिणामी प्रणाली के सत्यापन को योजना में डालना न भूलें।
4. संसाधनों पर निर्णय लें: कलाकारों के अनुमानों की पुष्टि करने और सिस्टम की लागत तय करने के लिए प्रकार, चरण, समय, कार्य के स्रोत और संसाधनों के स्रोत।

यदि ऐसे कार्यों को स्पष्ट रूप से सेट नहीं किया गया है और उनके समाधान की योजना नहीं है, तो समय बर्बाद न करना बेहतर है - यह परियोजना केवल दुर्घटना के बाद ही सफल हो सकती है।

यह काम क्यों नहीं कर सकता है (या नहीं भी कर सकता है)

पिछले सभी विचारों के परिणामस्वरूप, हमारे पास 3 विरोधी स्थितियां हैं:

1. पूर्वनिर्धारित विश्लेषण को जल्दी से करने की आवश्यकता है।
2. प्रिडिजाइन विश्लेषण सस्ते में किया जाना चाहिए।
3. पूर्व-डिज़ाइन विश्लेषण गुणात्मक रूप से किया जाना चाहिए।

जो डिजाइन त्रिकोण नियम से परिचित हैं वे समझते हैं कि ऐसा नहीं होता है।

कुछ अतिरिक्त कठिनाइयाँ हैं:

1. पूर्व-परियोजना विश्लेषण प्रस्तावित समाधान पर कम वापसी दिखा सकता है, और यह ग्राहक और प्रायोजक के लिए दिलचस्प नहीं होगा।
2. एक पूर्व-परियोजना विश्लेषण परियोजना की मात्रा या प्रारंभिक मान्यताओं के सापेक्ष स्वामित्व की कुल लागत को बढ़ा सकता है, और यह फिर से ग्राहक और प्रायोजक के लिए निर्बाध हो जाएगा।
3. पूर्व-परियोजना विश्लेषण प्रारंभिक मान्यताओं के संबंध में परियोजना की मात्रा को कम कर सकता है, और यह अक्सर बाहरी ठेकेदार के लिए दिलचस्प नहीं है।

इन सभी कठिनाइयों के संबंध में, मैं चाहता हूं कि आप और मैं एक बात समझें: यदि हम प्रायोजक के साथ नहीं चलते हैं और आईटी परियोजना को वित्तीय संपत्ति के रूप में नहीं देखते हैं, तो पूर्व-परियोजना की समस्याएं अघुलनशील हैं।

अंतिम से पहले लेख में टिप्पणियों में, राय व्यक्त की गई थी: “पूर्व-परियोजना को यथासंभव जल्दी खोला जाना चाहिए, लेकिन यह ध्यान में रखना चाहिए कि पूर्व-परियोजना का दायरा इसकी प्रभावशीलता से सीमित है। ऐसे प्री-प्रोजेक्ट को प्रभावी माना जाता है, जिसके बाद प्रोजेक्ट लॉन्च किया जाएगा। यह पूर्व-परियोजना की प्रभावशीलता का मुख्य मुख्य संकेतक है। " (c) विजार्ड्रीब

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

दूसरी ओर, यदि प्रोजेक्ट मैनेजर अपना स्वयं का प्रोजेक्ट बंद कर देता है, तो वह अपने स्वयं के कार्यस्थल को कम कर देगा।

सही दृष्टिकोण यह है कि जितनी जल्दी हो सके एक खराब संपत्ति से छुटकारा पा लिया जाए। पूर्व-परियोजना में विश्लेषक और प्रबंधक का कार्य यह करना है।

प्री-प्रोजेक्ट के लिए बजट कैसे प्राप्त करें

एक आईटी परियोजना के आसपास अनिश्चितता के एक रचनात्मक और लगातार हटाने के लिए मार्ग को फैलाने के लिए, ग्राहक के साथ स्पष्टीकरण देना आवश्यक है और परियोजना के लिए वित्तीय स्थिति के रूप में रवैया के बारे में सामान्य स्थिति को प्रायोजित करना चाहिए।

तस्वीर अनिश्चितता, निवेश और रिटर्न के सामान्य अनुपात को दिखाती है।



जब तक अनिश्चितता बड़ी है, हमें कम निवेश करना चाहिए और इसे कम करना चाहिए।

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

ऐसा करने के लिए, प्रत्येक चरण के अंत में सटीकता के स्तर पर निवेश और रिटर्न के अनुपात का आकलन होना चाहिए जो वर्तमान चरण के लिए स्वाभाविक है।

ग्राहक को अनिश्चितता के वर्तमान स्तर, लाभों और लागतों के वर्तमान उचित मूल्यांकन को दिखाने की आवश्यकता है। यदि लाभ लागत से अधिक है, तो यह अनिश्चितता को दूर करने पर चर्चा करने के लिए समझ में आता है।

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

पूर्व-परियोजना के कुछ हिस्सों की लागत के अनुपात पर मेरी (बहुत औसत) सिफारिशें:

• निर्माण से पहले होने वाली हर चीज की लागत परियोजना के 10-30% से अधिक नहीं होनी चाहिए।

• एक पूर्व-परियोजना में परिमाण के एक आदेश की लागत कम होनी चाहिए - यह सिस्टम की अनुमानित लागत का 1-3% है।

• शुरुआती चरणों में, जब तक कोई व्यावसायिक आवश्यकताएं नहीं होती हैं, तब तक कोई अनुमानित मूल्य नहीं हो सकता है और गणना किए गए रिटर्न से पुनर्प्राप्त करने की आवश्यकता हो सकती है - आप व्यवसाय आवश्यकताओं को बनाने के लिए बजट पर सिस्टम के जीवन के लिए 0.1-0.2% ले सकते हैं (ध्यान में रखते हुए यह शुरू नहीं होता है) प्रत्येक प्रस्तावित परियोजना)।

उदाहरण के लिए, यदि हम एक प्रणाली बेचते हैं जिसकी लागत ~ 100 मिलियन (सादृश्य द्वारा) है। सभी अनुमानों की कम सटीकता को देखते हुए, यह समझ में आता है कि इसके संचालन पर रिटर्न कम से कम ~ 300-500 मिलियन है।

इस मामले में, निम्नलिखित लागतों को सामान्य माना जा सकता है:

• व्यावसायिक आवश्यकताएं - 0.5-1 मिलियन रूबल।

• अवधारणा 1-3 मिलियन रूबल है।

• तकनीकी परियोजना - 10-30 मिलियन रूबल।

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

संक्षिप्त सारांश

यहां हम सही पूर्व-परियोजना की समीक्षा पूरी करते हैं और सबसे महत्वपूर्ण बात दोहराते हैं:

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

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