project-management - रबन - प्रोजेक्ट मैनेजमेंट बुक इन हिंदी




जीयूआई में सुविधा रेंगना प्रबंधन (19)

क्या किसी के पास कोई व्यावहारिक सुझाव है कि जीयूआई में फीचर रेंगने का प्रबंधन कैसे किया जाता है?

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

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


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

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

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

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


आप बस रेंगना सुविधा नहीं संभाल सकते - आपको अपने संपूर्ण विकास प्रक्रिया को उचित तरीके से व्यवस्थित करने की आवश्यकता है।

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

जब आप वास्तविक दुनिया के आंकड़ों के साथ साबित हो पाएंगे कि 'यह छोटा बटन' 5 सेकंड के बजाय 2-3 दिन लेगा, तो ग्राहक शायद मानते हैं कि यह होना चाहिए कि आप बातचीत के लिए बेहतर स्थिति में होंगे।

यदि आप स्पष्ट रूप से यह दिखाने में सक्षम होंगे कि प्रोजेक्ट की जाने वाली तारीख दो सप्ताह तक देरी होगी, क्योंकि नई सुविधाओं के कारण आप उन अनुरोधों को आसानी से लुप्त हो सकते हैं

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


आपके प्रश्न का उत्तर सिर्फ जीयूआई से व्यापक है फ़ीचर / स्कोप रेंगना हमेशा होता रहेगा, जब कोई अनुबंध पर ध्यान नहीं दे रहा है और जब परिवर्तन अनुरोधों को संभालने की कोई औपचारिक प्रक्रिया नहीं है

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


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

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

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

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


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

समस्या का कोई और सुधार तो फिर परिवर्तन नियंत्रण हो जाता है।


कुंजी सवाल में है।

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


चाल संस्करण के अनुक्रम के रूप में परियोजना को परिभाषित करने के लिए है। आपका प्रारंभिक डिजाइन संस्करण 2.0 के लिए है, लेकिन, वांछित पहला रिलीज संस्करण 1.0 है। सभी नए विचार (फीचर्स) का स्वागत किया जाता है लेकिन शेड्यूलिंग के कारण, संस्करण 1.0 जमे हुए है, नए विचारों को संस्करण 2.0 में जाना है।

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


ठीक है, मैं यहाँ चुस्त की आवाज़ होगी। इस प्रक्रिया के अंत में समस्या का हल नहीं किया जा सकता है, इसे अलग-अलग परियोजना के प्रबंधन से बचा जाना चाहिए।

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

इसके अलावा, आपको छोटे पुनरावृत्तियों (एक सप्ताह से एक महीने तक) में काम करना है, इसलिए उन्हें बीच में समायोजित करने की संभावना है।

हम SCRUM का उपयोग करते हैं और इसके बहुत अच्छे हैं कुछ पुनरावृत्तियों के बाद सभी व्यवसाय-स्तर और प्रक्रिया-स्तर की वस्तुओं का काम किया जाता है और आप वास्तव में अंत में क्या चाहते हैं, वितरित कर रहे हैं।


प्रबंधकों के लिए:

  • जितनी जल्दी उत्पाद को बाजार में जारी किया जाता है (यह मानना ​​है कि यह छोटा है), जितनी जल्दी कंपनी पैसा कमा सकती है और कैशफ्लो बेहतर कर सकती है।
  • नई सुविधा को पूरी तरह से बाहर नहीं मानें, लेकिन आप वैकल्पिक काम करने से प्राप्त मूल्य के खिलाफ संतुलन कर सकते हैं; अवसर की लागत समझाएं

सभी के लिए:

  • अगर नई फीचर यूआई में आपके चेहरे हैं, तो प्रयोज्यता पर विज़ुअल जटिलता के प्रभाव के बारे में बात करना शुरू करें - और उस से, आकर्षकता - पूरे उत्पाद का। लेकिन मुझे यकीन है कि आप पहले से ही ऐसा कर रहे हैं। मैं कुछ संदर्भ खुदाई करने की कोशिश करता हूँ ...

प्रोजेक्ट शुरू करने से पहले आपकी कंपनी अपेक्षाकृत स्पष्ट रूप से परिभाषित नहीं हो रही है, और यह केवल आँसू में खत्म होगा

मेरी नीति पहले से सभी आवश्यकताओं की स्पष्ट विखंडन प्राप्त करना है और सभी दलों को इन आवश्यकताओं को घुसपैठ करने के निहितार्थ हैं।

  1. प्रगतिशील विलंबित रिलीज़ समय
  2. बढ़ी हुई कीड़े
  3. अपूर्ण विशेषताएं
  4. स्टाफ तनाव
  5. स्टाफ के इस्तीफे
  6. अंतिम उत्पाद से और अधिक की अपेक्षा के लिए अतिरिक्त शुल्क से कीमत की घोषणा पर सहमति हुई (और यह वास्तव में खराब है)

यदि वे एक ऐसी प्रणाली का पालन नहीं करना चाहते हैं जो टिकाऊ और उत्पादक है, तो वह # 5 का विकल्प चुन सकता है या # 5 के साथ धमकी दे सकता है


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

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


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

इसके अलावा, यह एक व्यक्ति है जिसके माध्यम से सभी परिवर्तन आते हैं (स्कर्म में, वास्तव में एक अच्छा उत्पाद स्वामी) मददगार है।


संभव है कि सभी सुविधा अनुरोधों से बचें।

लेकिन प्रत्येक सुविधा अनुरोध के लिए लागत निर्दिष्ट करने का प्रयास करें। अगली योजना की बैठक या अगली रिहाई के लिए सुविधाओं का निर्णय लेने के आसपास इस के आसपास अनावश्यक लोगों को बाहर निकालने में मदद मिलेगी।


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

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

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


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

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

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


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


1) रिहाई से पहले का समय बढ़ गया है

2) बढ़ती लागत

3) घातीय रखरखाव लागत

4) कीड़े के लिए संभावित वृद्धि

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


आप "समझते हैं, यह संभव है, क्या आप अनुमान लगा सकते हैं कि यह परियोजना पूर्णता की तारीख को कितना आगे बढ़ाएगा? इसके अलावा, आपको यह अनुमान देने से परियोजना के अंत में एक दिन भी जोड़ा जाएगा।"

सुविधाओं को जोड़ने में कुछ भी गलत नहीं है, इसलिए जब तक हितधारकों को यह समझने में कोई खतरा होता है कि ऐसा करने से जुड़ा लागत है।


मान लीजिए कि आप ऐसा उत्पाद बनाते हैं जिसमें एक विशेषता है और आपके सभी 100 ग्राहक आपके उत्पाद को पसंद करते हैं और इसका उपयोग करना आसान लगता है। अब मान लीजिए कि आप अपने उत्पाद में दस और विशेषताएं जोड़ सकते हैं जो आपके केवल 10 ग्राहक उपयोग करेंगे अब आपको पता चल जाएगा कि आपके 90% ग्राहकों को आपके उत्पाद का उपयोग करने में अधिक परेशानी होती है, क्योंकि दस गुना अधिक विकल्प चुनते हैं, और जितनी चीजें जो आप कर सकते हैं वह आपकी मदद नहीं करेगा। शोर में अच्छी चीजें खो गई हैं।

यह निश्चित रूप से एक सरलीकरण है लेकिन वास्तविकता यह है कि आपके अधिकांश उपयोगकर्ता केवल आपके उत्पाद की सुविधाओं का एक छोटा सा हिस्सा उपयोग करेंगे।

सॉफ्टवेयर डिजाइन और UI डिज़ाइन पर कुछ अच्छी पुस्तकों को पढ़ें, और अपने प्रबंधक को भी उन्हें पढ़ने के लिए मिलें। जोएल स्पोलस्की की किताबें शुरू करने के लिए एक अच्छी जगह हैं - www.joelonsoftware.com