🙇🏼 🏴 🎪 आधुनिक परियोजना प्रबंधन प्रणालियों की आलोचना 🏂🏻 ♍️ 👉🏻

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

इस लेख में मैं कुछ महत्वपूर्ण का वर्णन करना चाहता हूं, मेरी राय में, कार्यक्षमता में अंतराल और इसे लागू करने के संभावित तरीके सुझाते हैं।

प्रोजेक्ट प्लान तैयार करने में मदद के लिए कोई स्पष्ट उपकरण नहीं हैं।

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

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

एक बदलती योजना के साथ काम करने के लिए असुविधाजनक

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

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

क्या था - कार्यों, श्रम लागत आदि के समय पर वास्तविक डेटा।
क्या बन गया है - जैसा कि हम खुद को वर्तमान क्षण से घटनाओं के विकास को देखते हैं।

समय के साथ, इन आवश्यकताओं को पूरा करने के लिए योजना को बदलना होगा। उसी समय, यह देखने का अवसर होना चाहिए कि योजना पहले क्या थी।

यह इस तथ्य को ध्यान में नहीं रखता है कि सभी लोग अलग-अलग हैं

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

कर्मचारियों की विशिष्टताओं और उत्पादकता के बारे में बुनियादी जानकारी का उपयोग करने से योजना तैयार करने में बहुत मदद मिल सकती है।

समस्या क्षेत्रों के निदान पर थोड़ा ध्यान दिया जाता है

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

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

सिस्टम बादलों में जाते हैं

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

मैं समझता हूं कि डेटा की एक स्थानीय प्रति का गायब होना गंभीर कारणों से है। यदि कई लोग एक ही समय में योजना के एक ही हिस्से में बदलाव करते हैं, तो उन्हें क्लाउड में संयोजित करना समस्याग्रस्त हो सकता है। हालांकि, यह तथ्य कि समस्या जटिल है, इसका मतलब यह नहीं है कि यह हल नहीं है।

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

निष्कर्ष

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

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

और आप परियोजना प्रबंधन प्रणालियों में क्या याद करते हैं?
आप उनसे क्या सुविधाएँ जोड़ना चाहेंगे?