आप फ़ीचर अनुरोध और सॉफ़्टवेयर परिवर्तन कैसे प्रबंधित करते हैं? [बन्द है]

Question

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

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

Comments

इसे देखें: programmers.stackexchange.com/questions/874/…

— luis.espinal

और शायद यह भी: प्रोग्रामर.स्टैकएक्सचेंज.

— com

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

— एंजेलो

Answer 1

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

मैं आमतौर पर इस क्रम (YMMV) में अनुरोधों को वर्गीकृत करता हूं:

1. हाल ही में अपग्रेड या माइग्रेशन (सबसे महत्वपूर्ण) से संबंधित मुद्दे।
2. सुरक्षा ठीक करता है।
3. मौजूदा सिस्टम की टूटी हुई कार्यक्षमता।
4. आरसी और बीटा सुविधाओं में टूटी हुई कार्यक्षमता।
5. भुगतान सुविधा अनुरोध।
6. उपयोगकर्ता आधार के एक बड़े हिस्से से R & D सुविधा अनुरोध।
7. आर एंड डी केवल एक या दो उपयोगकर्ताओं से अनुरोध करता है।

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

Comments

आपका प्रोफेसर थोड़ी देर में आइवरी टॉवर से नीचे उतरना चाहता है।

— जेएफओ

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

— माइकल जे। सबल

कौन, भुगतान करने वाले ग्राहकों को बीटा सुविधाओं की तुलना में कम प्राथमिकता मिलती है ?

— JBRWilkinson

Answer 2

मुझे सिद्धांत पसंद हैं :

1. क्यूआई - महत्वपूर्ण और तत्काल
2. QII - महत्वपूर्ण लेकिन तत्काल नहीं
3. QIII - महत्वपूर्ण नहीं बल्कि तत्काल
4. QIV - महत्वपूर्ण और तत्काल नहीं

Comments

वह कहाँ से है?

— रुके

सबसे पहली बात (1994) एक स्वयं सहायता किताब स्टीफन कोवे और ए रोजर और रेबेका आर मेरिल द्वारा लिखित है en.wikipedia.org/wiki/First_Things_First_%28book%29

— Adamizer

@Rook - इसके अलावा अत्यधिक प्रभावी लोगों के कोवे की 7 आदतों में सूचीबद्ध है। महान पुस्तक।

— नेमी

Answer 3

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

Comments

ट्रैकिंग के लिए +1। मुझे यह w / सहकर्मियों से पहले करना पड़ा है। मैं उन्हें बताता हूं कि क्या यह वास्तव में मेरे लिए महत्वपूर्ण है, यह 5-10 मिनट का होना चाहिए जो उन्हें टिकट दर्ज करने के लिए ले जाएगा।

— GSto

Answer 4

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

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

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

Answer 5

यहाँ कुछ विचार हैं ...

बाजार में बहुत सारे सॉफ्टवेयर हैं जो आपकी मदद करते हैं, http://www.fogcreek.com/ फोगबुगज़ के साथ, जेनएक्सस यूएसए के साथ एक्सपीएम http://www.genexususa.com/xpm , आदि।

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

आपके पास समय, संसाधन और गुंजाइश है, इसमें से अपना सर्वश्रेष्ठ बनाएं।

हेनरी फोर्ड ने भी एक बार प्रसिद्ध कहा था, "अगर मैंने ग्राहकों की बात सुनी, तो मैंने उन्हें एक तेज़ घोड़ा दिया होगा" ...

व्यक्तिगत रूप से: गतिशील रहें, आपके द्वारा कहे गए नियमों को लागू न करें ... और अन्य लोगों के नियमों के साथ सावधान रहें ... वे अपने संदर्भ में अच्छा काम कर सकते हैं, लेकिन आप में नहीं।

Answer 6

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

Answer 7

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

Answer 8

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

यदि आप ग्राहक को तात्कालिकता स्थापित करने की अनुमति देते हैं, तो यह लगभग हमेशा "उच्च" (या अधिक) होगा।

आपको (आप या तो आप, या टीम, आपके सेटअप के आधार पर) इन अनुरोधों का मूल्यांकन करने की आवश्यकता होगी, और उन्हें अपने मानदंडों के आधार पर प्राथमिकता दें।