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

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

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

परियोजना प्रबंधकों के बीच समस्याग्रस्त व्यक्तित्व निम्नलिखित हैं:

बैठक नियोजक

परियोजना प्रबंधक, जो मानता है कि परियोजना की सभी समस्याएं संचार और समन्वय की कमी के कारण होती हैं, और बैठकों की एक भरपूर संख्या समाधान होगी।

आंकड़ों में परिवर्तन कर सकते हैं
पेटेंट लेखक जैसे उत्पाद प्रबंधक के साथ संयोजन में खतरनाक
सुधार की संभावना: उच्च
परियोजना के लिए खतरा: कम

समस्या

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

इस प्रकार की प्रबंधक बैठकों के विशाल बहुमत में निहित तीन मुख्य समस्याओं का सामना करते हैं:

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

निर्णय

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

इस परियोजना प्रबंधक को एक सरल निर्देश के साथ तय किया जा सकता है:

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

परियोजना को पूरा करने के लिए बैठकों की आवश्यकता होती है, लेकिन सबसे महत्वपूर्ण:

हर बैठक को यथासंभव प्रभावी बनाएं।
प्रदर्शन पर नकारात्मक प्रभाव को कम करें।

जैसे ही मीटिंग प्लानर को यह समझ में आता है, उसका व्यवहार तुरंत बेहतर के लिए बदल जाएगा।

सांख्यिकी

एक परियोजना प्रबंधक जो केवल सामग्री की परवाह किए बिना सूची बनाने और आइटम की जाँच करने में शामिल है।

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

समस्या

किसी भी परियोजना को पूरा करने के लिए दो आवश्यक चरणों की आवश्यकता होती है:

एक टू-डू सूची बनाएं।
जो सूची बनाई गई है, उससे आइटम चिह्नित करें।

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

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

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

निर्णय

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

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

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

wrongheaded

प्रबंधक को परियोजना की वास्तविकताओं से इतना तलाक दिया जाता है कि वह इच्छुक पार्टियों को गलत जानकारी देता है।

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

समस्या

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

निम्नलिखित प्रमुख वाक्यांश हैं जो आपको प्रोजेक्ट मैनेजर को बादलों में पहचानने की अनुमति देते हैं:

"मुझे बुरा लग रहा है।"
"मुझे नहीं लगता कि हम इस समय तक समय पर पहुंचेंगे।"
"मुझे लगता है कि हमारे साथ सबकुछ ठीक हो जाएगा।"
"मुझे कोई समस्या नहीं दिख रही है।"
"यह निर्णय मुझे भ्रमित करता है।"

"I" और "हम" के उपयोग पर ध्यान दें - ये अच्छे मार्कर हैं जो प्रबंधक की धारणा व्यक्तिपरक छापों पर आधारित हैं, न कि एकत्रित और विश्लेषण किए गए डेटा पर।

एक गुमराह प्रबंधक, निराशावादी और एक आशावादी के बीच अंतर को नोट करना महत्वपूर्ण है:

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

यह उन कुछ व्यक्तित्वों में से एक है जो अपने दम पर पूरी परियोजना को बर्बाद कर सकते हैं। यदि ऐसा प्रबंधक अक्सर हितधारकों के साथ मिलता है, तो सतर्कता बढ़ाई जानी चाहिए क्योंकि निम्नलिखित हो सकता है:

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

निर्णय

सौभाग्य से, ऐसे प्रबंधक को दो कार्यों में तय किया जा सकता है:

उससे पूछें कि उसे क्या लगता है वह क्यों महसूस करता है।
उसे उसकी प्रवृत्ति के विपरीत मात्रात्मक और गुणात्मक डेटा दिखाएं।

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

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

निराशावादी

एक प्रबंधक जो आत्मविश्वास से परियोजना की विफलता की बात करता है, और इसके विपरीत उसे समझाना असंभव है।

ग़लती से हो सकता है
यह एक अलार्म जैसे परीक्षक के साथ संयोजन में खतरनाक है
सुधार की संभावना: नहीं
प्रोजेक्ट खतरा: अत्यंत उच्च

समस्या

अधिकांश सॉफ्टवेयर विकास परियोजनाओं को एक तरफ से असफल कहा जा सकता है:

अतिरिक्त बजट।
अधिक समय सीमा।
सभी आवश्यक कार्यक्षमता का अभाव।
प्रदर्शन, स्थिरता, या मापनीयता के मुद्दे।
बड़ी संख्या में कीड़े।

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

एक निराशावादी को दो प्रमुख विशेषताओं द्वारा आसानी से पहचाना जाता है:

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

ऐसी स्थिति अधिकारियों को आश्वस्त कर सकती है कि परियोजना निराशाजनक है, और यह वास्तव में रद्द कर दिया गया है।

निर्णय

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

आशावादी

एक परियोजना प्रबंधक, जिसने परियोजना के सफलता के लिए खुद को आश्वस्त किया है, इसके विपरीत सबूतों की परवाह किए बिना।

टीम के कप्तान या ग़लती से म्यूट कर सकते हैं
एक आशावादी डेवलपर के साथ संयुक्त होने पर खतरनाक
सुधार संभावना: कम
प्रोजेक्ट खतरा: अत्यंत उच्च

समस्या

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

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

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

एक आशावादी प्रबंधक अक्सर किसी परियोजना को विफल करने का कारण बनता है, क्योंकि यह उन समस्याओं की अनदेखी करता है जो विफलता का कारण बन सकती हैं। प्रोजेक्ट जितना लंबा समय लेगा, उतना बुरा असर पड़ेगा।

निर्णय

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

संगठन साहसी नेताओं को बढ़ावा देने का प्रयास करते हैं। नतीजतन, एक आशावादी प्रबंधक के पास पदोन्नति का एक उच्च मौका है यदि वह अपने वरिष्ठों को समझा सकता है कि परियोजना उनके नियंत्रण से परे कारणों से विफल रही।

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

टीम के कप्तान

एक प्रोजेक्ट मैनेजर जो सभी प्रोग्रामर को खुश करने पर ध्यान केंद्रित करता है न कि प्रोजेक्ट की सफलता पर।

एक आशावादी में बदल सकता है
जब एक शांति विकास प्रबंधक के साथ संयुक्त खतरनाक
सुधार की संभावना: उच्च
परियोजना के लिए खतरा: कम

समस्या

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

टीम के कप्तान और आशावादी एक सकारात्मक दृष्टिकोण रखते हैं, लेकिन इसकी अभिव्यक्ति मौलिक रूप से अलग है:

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

टीम के कप्तान को हाजिर करना बहुत आसान है:

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

ऐसा व्यक्ति एक आदर्श परियोजना प्रबंधक की तरह लगता है, लेकिन चिंता के दो कारण हैं:

ये सभी घटनाएं केवल अस्थायी रूप से मनोबल को बढ़ाती हैं, जो लोगों की परियोजना की वास्तविकताओं को याद रखने पर जल्दी दूर हो जाती हैं।
वे अल्पकालिक प्रोत्साहन को प्राथमिकता देते हुए कम नैतिकता के मूल कारणों को समाप्त नहीं करते हैं।

इस प्रकार, टीम के कप्तान अंततः सभी को पसंद करते हैं, लेकिन वास्तव में परियोजना प्रबंधक का काम नहीं करते हैं।

निर्णय

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

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

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

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

तानाशाह

एक प्रबंधक जो प्रोजेक्ट सदस्यों के साथ कड़ी मेहनत करने के लिए उनकी प्रेरणा के नाम पर अवमानना करता है।

एक में उत्परिवर्तित कर सके निराशावादी
चीन की एक दुकान में सैनिकों और हाथियों जैसे डेवलपर्स के संयोजन में खतरनाक
सुधार की संभावना: उच्च
प्रोजेक्ट खतरा: अत्यंत उच्च

समस्या

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

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

अत्याचारियों के साथ वास्तविक समस्याओं का पता लगाना मुश्किल है, लेकिन वे परियोजना के लिए अविश्वसनीय रूप से हानिकारक हैं।

, , , .
, , , .

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

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

निर्णय

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

पहला, मात्रात्मक डेटा प्रदान करना जो उनकी परियोजना प्रबंधन शैली को दर्शाता है:

कितने मूल्यवान कर्मचारियों ने राज्य छोड़ दिया।
प्रतिभा को आकर्षित करने में सफलता।
कितने फीचर जारी किए
कितने कीड़े पंजीकृत हैं।
कितनी गुम हुई तारीखें

इस जानकारी की तुलना करते समय, समयरेखा विशेष रूप से प्रभावी हैं।

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

वे कर्मचारियों के साथ कैसा व्यवहार करते हैं।
वे परियोजनाओं की विफलताओं और सफलताओं पर चर्चा करते हैं।
कैसे पहचानें और असंगत परियोजना प्रतिभागियों को मात दी।
सक्षम प्रतिभागियों को कैसे आकर्षित और बनाए रखना है।

बशर्ते कि इस तरह के प्रशिक्षण के लिए एक उपयुक्त विशेषज्ञ है, तो प्रबंधक-अत्याचारी को पूरी तरह से ठीक किया जा सकता है, क्योंकि निम्नलिखित विशेषताएं स्वाभाविक रूप से एक व्यक्ति में निहित हैं:

लोग मतलबी नहीं होना चाहते।
लोग प्यार करना पसंद करते हैं।
लोगों को प्रभावी होना पसंद है।

मुख्य बात यह है कि अतीत में अत्याचारी की प्रतिष्ठा के बावजूद, टीम एक नया दृष्टिकोण लेती है। समस्या को बहुत सरल रूप से हल किया जा सकता है, उदाहरण के लिए, "मैं माफी चाहता हूँ" थीम के साथ एक बैठक बुलाना और "मैं बेहतर के लिए बदल गया हूं।"

प्रक्रिया के साथ पालन किया

प्रबंधक इस प्रक्रिया से इतना प्रभावित होता है कि वह अपने कार्य के बारे में भूल जाता है - ताकि परियोजना को सफलता मिल सके।

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

समस्या

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

प्रक्रियाओं की दो व्यापक श्रेणियां हैं जो निम्नलिखित हैं:

झरना जुनून
फुर्तीली विकास के साथ जुनून (फुर्तीली)

शायद प्रशिक्षण प्रक्रिया या पुस्तक इन प्रक्रियाओं को अलग तरह से बुलाती है, लेकिन आप आसानी से उन्हें निम्नलिखित परीक्षा में डालकर सही श्रेणी में रख सकते हैं:

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

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

निर्णय

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

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

ढुलमुल

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

आंकड़ों में परिवर्तन कर सकते हैं
चीन की एक दुकान में सैनिकों और हाथियों जैसे डेवलपर्स के संयोजन में खतरनाक
सुधार की संभावना: उच्च
परियोजना के लिए खतरा: कम

समस्या

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

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

एक असुरक्षित प्रबंधक को व्यापक रूप से दूसरे नाम से जाना जाता है: माइक्रो-प्रबंधक। उनकी परियोजना प्रबंधन विधियों को परियोजना टीम के सदस्यों द्वारा किसी भी या सभी निम्नलिखित के रूप में व्याख्या की जाती है:

आक्षेप
उत्पीड़न
चिंता
व्याकुलता
व्यवधान
छेड़छाड़

अक्सर, कर्मचारियों को एक अनिश्चित परियोजना प्रबंधक के प्रति गहरी नाराजगी पैदा होती है, क्योंकि उनकी धारणा में:

प्रबंधक को उनके समय प्रबंधन कौशल पर भरोसा नहीं है।
प्रबंधक उनकी समय सीमा के आकलन पर विश्वास नहीं करता है।
प्रबंधक समस्याओं को हल करने के लिए अकेले रहने की आवश्यकता नहीं समझता है।
प्रबंधक के पास कुछ भी करने को नहीं है लेकिन स्थिति पूछ और रिपोर्ट करें।

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

निर्णय

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

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

यह भी देखें:

परियोजना प्रबंधकों के बीच समस्या व्यक्ति

बैठक नियोजक

समस्या

निर्णय

सांख्यिकी

समस्या

निर्णय

wrongheaded

समस्या

निर्णय

निराशावादी

समस्या

निर्णय

आशावादी

समस्या

निर्णय

टीम के कप्तान

समस्या

निर्णय

तानाशाह

समस्या

निर्णय

प्रक्रिया के साथ पालन किया

समस्या

निर्णय

ढुलमुल

समस्या

निर्णय

More articles: