Microsoft प्रोजेक्ट डेलेंडा एस्ट

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

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

डिस्क्लेमर और ओटमीज़ी

लेखक पाठ में प्रयुक्त पेशेवर स्लैंग अंग्रेजी की विशाल संख्या के लिए अग्रिम में माफी माँगता है, लेकिन मानता है कि यह उनके बिना उनके साथ बेहतर है।

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

• प्रोजेक्ट टीम के सदस्य दिन में औसतन 8 घंटे और सप्ताह में 40 घंटे काम करते हैं और शायद ही कभी इन स्तरों को डेढ़ से अधिक बार पार करते हैं।
• निष्पादित परियोजनाओं का मुख्य लक्ष्य ग्राहक की व्यावसायिक समस्या को सफलतापूर्वक हल करना है।

व्यावसायिक संदर्भ: एक सॉफ्टवेयर परियोजना कैसे की जाती है

यह अध्याय किसी भी तरह से सॉफ्टवेयर परियोजना प्रबंधन अनुशासन का पूर्ण विवरण नहीं है। यह केवल जटिलता के सबसे बुनियादी स्तर का वर्णन करता है और कुछ अवधारणाओं का परिचय देता है।

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

बिक्री के लिए

बिक्री के दौरान, हमें खुद को और ग्राहक को निम्नलिखित सवालों के जवाब देने के लिए उत्पन्न कलाकृतियों (अनुमान, परियोजना की योजना, प्रस्ताव आदि) का उपयोग करना चाहिए:

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

अन्य मुद्दे जो अक्सर संकीर्ण अर्थ में "अनुमान" के बाहर हो सकते हैं, लेकिन एक पूर्ण परियोजना योजना उत्पन्न करने के लिए महत्वपूर्ण है:

• निर्भरता। क्या सामग्री, सूचना, कार्य, आदि। क्या परियोजना टीम ग्राहक से या तीसरे पक्ष से उम्मीद करती है? किन बिंदुओं पर?
• स्वीकृति। हम यह कैसे निर्धारित करते हैं कि परियोजना के दौरान प्राप्त परिणाम ग्राहक के समझौतों और जरूरतों के अनुरूप हैं?

इसके अलावा:

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

क्रियान्वयन

परियोजना के निष्पादन के दौरान, हम निगरानी करते हैं कि परियोजना प्रबंधन उपकरणों की मदद से क्या हो रहा है और समय-समय पर (ज्यादातर मामलों में 1 से 7 दिनों की अवधि में) स्थिति की समीक्षा करें और प्रश्नों का उत्तर दें:

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

आमतौर पर, परियोजना निष्पादन चरण में निम्नलिखित सही है:

• नई आवश्यकताएं और कार्य दिखाई देते हैं, और पुराने को गुंजाइश से घटाया जा सकता है।
• स्कूप के हिस्सों को प्रसव के बीच ले जाया जा सकता है (आमतौर पर "अगले चरण के लिए अलग सेट" के रूप में)।
• अधिकांश लोग बिना रुकावट के पूर्णकालिक परियोजना पर काम करते हैं, अर्थात्। दिन में 8 घंटे, सप्ताह में 40 घंटे, परियोजना में शामिल होने के क्षण से परियोजना छोड़ने के क्षण तक। कभी-कभी एक व्यक्ति ओवरटाइम में एक परियोजना पर काम कर सकता है, लेकिन हम अनुमान चरण में बहुत कम ही इसे प्राप्त करते हैं। फटे लोडिंग के साथ अंशकालिक भूमिकाएं मौजूद हैं, लेकिन 99% मामलों में, इन भूमिकाओं की भागीदारी परियोजना में श्रम के कुल स्तर का 10-20% से अधिक नहीं है और ये आमतौर पर विशेष भूमिकाएं (अंशकालिक पीएम, डिजाइनर, आदि) हैं।

परियोजना के निष्पादन में सर्वोत्तम प्रथाओं में शामिल हैं:

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

दीक्षा के आधार, वे भी नरक के घेरे हैं

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

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

जूनियर एमएस प्रोजेक्ट डिजाइनर

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

काफी कुंवारी शुरुआत करने वाले अक्सर प्रोजेक्ट को एक्सेल के रूप में उपयोग करते हैं - कार्यों की एक सूची दर्ज करें (अक्सर पदानुक्रमित भी नहीं), कार्यों को घंटे असाइन करें और इसे एक मसौदा अनुमान के रूप में समीक्षा के लिए भेजें।

अधिक सामान्य विकल्प तब होता है जब अनुमान के लेखक ने अपने जीवन में गैंट चार्ट देखा और जानता है कि "सॉसेज" को ऊपर से नीचे तक, बाएं से दाएं तक व्यवस्थित किया जाना चाहिए। इस विकल्प में, हमें सॉसेज के एक या अधिक रैखिक बंडल मिलते हैं, जो ऑटो लिंक के माध्यम से एक दूसरे से बंधे होते हैं।

यह महत्वपूर्ण है कि नए लोगों को संसाधन आवंटन पर पता नहीं है या रोकना नहीं है, और परियोजना में बस संसाधन नहीं हैं। एमएस प्रोजेक्ट में बनाई गई योजना में संसाधनों की कमी एक जूनियर का महत्वपूर्ण संकेत है।

मध्य एमएस परियोजना डिजाइनर

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

मिडल से सबसे आम योजना दोष खराब योजनाबद्ध आर्किटेक्चर और असमान टीम लोडिंग (प्रोजेक्ट शब्दों में, कार्य असाइनमेंट स्तर पर) हैं।

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

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

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

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

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

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

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

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

घड़ियों और मैन-आवर्स के साथ एक और बड़ी समस्या यह है कि व्यावहारिक अनुभव के आधार पर, प्रोजेक्ट के बारे में उनकी समझ में 90% क्लाइंट "मध्य" के आधार स्तर से ऊपर नहीं उठते हैं और अक्सर यह नहीं समझते हैं कि किस कॉलम को देखना है और इस कॉलम में क्या है यह लिखा है। ऐसे ग्राहकों से विशिष्ट प्रश्न जब उन्हें परियोजना में पूरी योजना के साथ पेश किया जाता है, उदाहरण के लिए, "आपने कहा था कि परियोजना चार सप्ताह तक चलेगी, और किसी कारण से आपके पास कुल काम के 560 घंटे हैं - आप मुझे बेवकूफ क्यों बना रहे हैं?"

सीनियर एमएस प्रोजेक्ट डिजाइनर

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

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

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

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

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

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

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

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

सी / सी ++ विकास रूपक (शायद इन दिनों थोड़ा पुराना) के साथ जारी रखते हुए, जटिल लिपियों में प्रोजेक्ट का पूरा उपयोग करना ऐसा लगने लगा है कि बिना मेक / चींटी का उपयोग किए बिना एक बहुत बड़े और जटिल सी / सी ++ सिस्टम बनाने की कोशिश की जा रही है और यदि पुस्तकालय जिसके लिए हमारे निपटान में उपलब्ध हेडर (.h) और बाइनरी (.a / .लिब और .so / .dll) फ़ाइलों के बीच पत्राचार की गारंटी नहीं है। सैद्धांतिक रूप से, यह किया जा सकता है, लेकिन इसके लिए बहुत ध्यान देने योग्य प्रयासों और अच्छी योग्यता की आवश्यकता हो सकती है, और इकट्ठे सिस्टम में महत्वपूर्ण कीड़े हो सकते हैं।

सब कुछ प्राकृतिक असंगत है, या अच्छे के बारे में संक्षेप में

एमएस प्रोजेक्ट की समस्याओं और जाल पर चर्चा करने के बाद, सवाल उठ सकता है - माइक्रोसॉफ्ट ने इस तरह की बकवास को क्यों विकसित और बढ़ावा दिया? हम Microsoft को गैर-लाभकारी और दुर्भावनापूर्ण होने के लिए दोषी ठहराने से बहुत दूर हैं। समस्याओं पर चर्चा जारी रखने से पहले, हम संक्षेप में चर्चा करेंगे कि एमएस प्रोजेक्ट क्या उपयुक्त है और इसकी कई विशेषताओं की व्याख्या करने का प्रयास करें, जो पहली नज़र में भयावह लगते हैं।

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

1. परियोजना योजना की संरचना (मुख्य रूप से हम डब्ल्यूबीएस की संरचना के बारे में बात कर रहे हैं) या तो गतिविधि के संबंधित क्षेत्र के मानकों द्वारा निर्धारित की जाती है (उदाहरण के लिए, एक मानक तकनीकी प्रक्रिया का वर्णन करता है), या कम से कम योजना बनने के बाद नहीं बदलती है।
2. कार्यों और / या संसाधनों की संख्या छोटी है।
3. कार्य एक दूसरे से स्वतंत्र हैं, और संसाधन समान और विनिमेय हैं।

सॉफ्टवेयर विकास के क्षेत्र में एक न्यूनतम जटिल परियोजना के लिए, इनमें से कोई भी स्थिति आमतौर पर पूरी नहीं होती है, हालांकि निष्पादन के दौरान बहुत सरल परियोजनाएं नहीं बदल सकती हैं और / या केवल 30-40 कार्य और 1-2 निष्पादक होते हैं (बाद वाले मामले में, यह सच है कि इस तरह का उपयोग एमएस प्रोजेक्ट की तरह "भारी" उपकरण अभी भी संदेह में है)।

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

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

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

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

वास्तविक दुनिया में एमएस प्रोजेक्ट

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

फिर भी, कई लोग अपने अभ्यास में एमएस प्रोजेक्ट का उपयोग करना जारी रखते हैं - नेतृत्व और ग्राहक के दबाव के कारण, पूर्वाग्रह, अज्ञानता या आदत। वे इसे कैसे करते हैं?

उत्तर सरल और अनुमानित है - एमएस प्रोजेक्ट उपयोगकर्ता अपने कार्य को सरल बनाकर व्यवहार्य बनाते हैं। इसका सरलीकरण विभिन्न तरीकों से प्राप्त किया जा सकता है: जानबूझकर या अनजाने में परियोजना के कुछ वास्तविक पहलुओं को अनदेखा करना, या एमएस प्रोजेक्ट के समानांतर में किसी अन्य उपकरण का उपयोग करके खुद को जानबूझकर परियोजना को सरल बनाना।

Procrustean बिस्तर

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

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

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

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

आनंदित अज्ञान

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

इस स्थिति की एक विशेषता यह है कि समीक्षक के सवाल पर "आप अपनी योजना में एक्स को कैसे ट्रैक करते हैं?" लेखक के आत्मविश्वास की डिग्री के आधार पर कोई भी ऐसा नहीं करता है। उत्तर की एक और भिन्नता है "यह एक्स वास्तव में किसकी परवाह करता है?" (जो धन और शर्तों के संदर्भ में विशेष रूप से आश्वस्त लगता है)।

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

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

बैसाखी और विकल्प

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

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

अधिक व्यवहार्य संस्करण में, प्रोजेक्ट में योजना को कुछ अन्य कलाकृतियों या योजना और निगरानी कलाकृतियों के साथ समानांतर में समर्थित किया गया है। प्रबंधक और टीम दो तरह से इस विकल्प पर आते हैं।

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

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

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

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

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

निष्कर्ष: गैंट के बाद का जीवन

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

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

हम जो उपयोग करने की सलाह देते हैं, उस पर एक अलग लेख में चर्चा की जाएगी।