सामान्य परियोजना प्रबंधन मुद्दे (वेब)

परिचय।

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

और यह, इस तथ्य के बावजूद कि "रेक" हमेशा एक ही था।



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



So.



सामान्य रवैया:

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



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



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

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



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



यह त्रुटियों के प्रति सामान्य दृष्टिकोण को ध्यान देने योग्य है। ऐसा भी होता है कि अधिकारियों के डर के कारण कुछ समस्याओं को आवाज नहीं दी जाती है। जो कुछ समय के बाद समस्या को और अधिक गंभीर परिणाम दे सकता है यदि समस्या को प्रारंभिक चरण में हल किया गया था। ("कालीन के नीचे रेकिंग कचरा" का पलटा ध्यान नहीं दिया गया - अच्छी तरह से, ठीक है।)



और सबसे कठिन मामला: "प्रबंधकों ने मेरा पीछा किया, अब मैं पीछा कर रहा हूं"।

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



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



समय

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



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

और, जैसा कि अभ्यास से पता चलता है, जटिलता को कम से कम एक चौथाई से कम करके आंका जा सकता है।



यह भी होता है कि ग्राहक द्वारा समय सीमा लगाई जाती है। यह इतना बुरा विकल्प नहीं है जितना लगता है। लेकिन केवल इस शर्त पर कि ग्राहक काम की राशि पर सहमत होने और एक बजट (या इसके विपरीत) अपनाने के लिए तैयार है।



परियोजना योजना का अभाव

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



आवश्यकताएँ प्रबंधन

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



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



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



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

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

जोखिम प्रबंधन।

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

हां, इस तरह के आरक्षण से, आप एक साधारण ग्राहक को डरा सकते हैं, जो केवल एक प्रतियोगी के पास भाग जाएगा, क्योंकि "ये लोग सब कुछ जल्दी और अनावश्यक परेशानियों के बिना करेंगे।"

यह भी एक जोखिम है। और नियमित रूप से याद की गई डेडलाइन - क्या यह आपकी प्रतिष्ठा को बर्बाद करने का जोखिम नहीं है?



बैठक

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



हैंडलिंग में त्रुटि

मेरे परिचितों में से कुछ पीएम के मुझे उन परियोजनाओं की संख्या बता सकते हैं जिनमें उन्होंने भाग लिया था। खराब मेमोरी में समस्या इतनी ज्यादा नहीं है। कितना कुछ है कि कुछ लोग परियोजना के परिणामों का विश्लेषण करते हैं। इस लेख को लिखने की प्रक्रिया में, मैंने रुचि के लिए, एक सर्वेक्षण भी किया। प्रकाशन के समय, अग्रणी राय थी "मैं अपने दिमाग में नोट करता हूं, लेकिन दस्तावेज़ नहीं करता" - 25.32%। इसके अलावा, एक ही वोट से यह स्पष्ट है कि केवल 35% उत्तरदाताओं ने परियोजना का पूर्ण विश्लेषण किया है।



यह पता चला है कि परियोजना प्रबंधन में अनुभव जमा नहीं होता है। चूंकि प्रासंगिक दस्तावेजों को खींचने की आदत के अभाव में, उनका ज्ञान कंपनी प्रबंधकों को भी छोड़ देगा, जिन्हें हमेशा मामलों को सौंपने के दौरान साझा नहीं किया जा सकता है। तदनुसार, प्रबंधन में विकास प्रक्रिया बेहद धीमी गति से आगे बढ़ सकती है।



कुल:



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



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



और शायद तथ्य यह है कि ग्राहक अभी भी गुणवत्ता के विकास के लिए हजारों डॉलर के कई दसियों (सैकड़ों) का भुगतान करने के लिए तैयार नहीं हैं। और सच्चाई यह है कि, क्यों, अगर छात्रों के दोस्त एक ही काम करते हैं, केवल एक हजार और एक के लिए ...



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



यहां मूल