समस्या का समाधान: 10 प्रबंधक नियम

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



मेरे लिए सब कुछ काम करता है!

एक आम धारणा है कि निष्पादक समस्याओं को हल करते हैं, और प्रबंधक केवल रास्ते में चलते हैं और प्राप्त करते हैं । हालांकि, अगर परियोजना पर कोई प्रबंधक नहीं है तो क्या होगा? एक स्थिति की कल्पना करें: एक गुस्सा पत्र समर्थन में आता है: "मैंने बटन दबाया, और 500 वीं त्रुटि है!" और पत्र एक नहीं आता है, अर्थात्, समस्या बड़े पैमाने पर है।


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

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

बेशक, यह एकमात्र संभव परिदृश्य विकास पाठ्यक्रम नहीं है। ऐसी टीमें हैं जिनमें परियोजना प्रबंधक के पद के साथ कोई व्यक्ति नहीं है, लेकिन फिर भी समस्याएं हल हो जाती हैं। हालांकि, यह इस तथ्य के कारण है कि टीम के सदस्यों में से एक वास्तव में एक प्रबंधक के कार्यों को करता है।

तो, ऊपर वर्णित स्थिति कैसे बदल जाएगी यदि हम मान लें कि परियोजना पर अभी भी पीएम हैं?

नियम # 1: कोई भी समस्या आपकी हो जाती है

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

नियम # 2: उपयोगकर्ता कभी भी झूठ नहीं बोलते हैं

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

नियम # 3: उपयोगकर्ता को छोड़कर ... किसी पर भी भरोसा न करें

डॉ। हाउस की शैली में यह थीसिस बहुत अच्छी तरह से विचाराधीन स्थिति में समझाया गया है: यदि आप मानते हैं कि हर कोई जो समर्थन को दरकिनार कर देता है, तो सच्चाई को प्राप्त करने की कोशिश कर रहा है, यह पता चलता है कि किसी को कोई समस्या नहीं है। लेकिन हमें याद है कि उपयोगकर्ता झूठ नहीं बोलते हैं!

नियम # 4: ऊपर से समस्या को हल करें

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

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

नियम # 5: हम लक्षण नहीं, बल्कि कारण को खत्म करते हैं

विचाराधीन स्थिति में, कारण की तह तक जाने के लिए, प्रबंधक लेआउट डिजाइनर के पास जाता है और यह पता लगाता है कि किन मामलों में वह UI पर पांच सौवीं त्रुटि प्रदर्शित करता है। लेआउट डिजाइनर क्या जवाब देगा? "जब मुझे सर्वर से गलत उत्तर मिला।" - "ठीक है, आपको सर्वर से क्या जवाब मिला?" - पीएम रुचि रखते हैं। "स्थिति 500," लेआउट डिजाइनर जवाब देता है। यहां हमें अंततः कुछ जानकारी मिलती है: उपयोगकर्ता 500 वीं त्रुटि देखता है जब सर्वर 500 कोड के साथ प्रतिक्रिया देता है। यदि यह सच है (और हमें याद है कि किसी पर भरोसा नहीं किया जा सकता है), तो आपको यह पता लगाना होगा कि सर्वर के साथ क्या होता है ऐसा व्यवहार करने लगता है।

नियम # 6: सबसे बड़ा आलस्य का सिद्धांत

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

नियम # 7: समस्या पीएम की जिम्मेदारी का क्षेत्र है

इस अवस्था में सशर्त अनुभवहीन पीएम कैसे कार्य कर सकते हैं? सर्वर प्रोग्रामर को लेआउट डिजाइनर को इस उम्मीद में भेजने की कोशिश करें कि "वे किसी तरह वहां आपस में सहमत होंगे।"

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

इसलिए, एक अच्छे प्रोजेक्ट मैनेजर को इस स्थिति में प्रोग्रामर के पास जाना चाहिए।

नियम # 8: हर कदम पर लॉगिंग

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

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

नियम # 9: मुख्य बात के बारे में मत भूलना

अगली गलती जो प्रबंधक कर सकता है, वह प्रोग्रामर को बताना है: “ठीक है। लॉगिंग बनाओ, ”और समस्या के बारे में भूल जाओ। इससे क्या होगा? सबसे पहले, ज़ाहिर है, डेवलपर लॉगिंग के साथ सभी मामलों को कवर नहीं करेगा, और दूसरी बात, लॉगिंग विकसित करने की प्रक्रिया में, वह, निश्चित रूप से, प्रारंभिक समस्या के बारे में भूल जाएगा।

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

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

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

नियम # 10: सुनिश्चित करें कि लक्षण दूर हो गए हैं

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

एक वैक्यूम में सही प्रबंधक

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

एकल नहीं

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

अगली श्रृंखला में

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

डेनिस एनिकिन,
Mail.Ru मेल के तकनीकी निदेशक