लगातार आवश्यकताओं में परिवर्तन से कैसे निपटें?


9

मैं अपने वर्तमान कार्य स्थान में बहुत तनावपूर्ण (मेरी राय में) स्थिति से निपट रहा हूं।

हमने नई परियोजना विकसित करना शुरू कर दिया है, कुछ आवश्यकताओं को प्राप्त करें, इसे लागू करें और फिर किसी ऐसे व्यक्ति को दिखाएं जिसे आप 'व्यवसाय सलाहकार' कह सकते हैं (वह व्यक्ति जो व्यावसायिक आवश्यकताओं को जानता है लेकिन कार्यक्रम का उपयोग नहीं करेगा)। उस व्यक्ति को ग्राहकों के दृष्टिकोण से आवेदन का मूल्यांकन करना है, इसका परीक्षण करना है आदि।

यहाँ 'प्रक्रिया' कैसी दिखती है:

  1. व्यापार सलाहकार शाम को अपने दूत के साथ विंडोज़ मैसेंजर पर घंटे या दो के लिए बातचीत करते हैं
  2. अगले दिन मुझे उस वार्तालाप की प्रति के साथ ईमेल प्राप्त हुआ। मुझे उस से कार्य चुनने हैं, रिपोर्ट किए गए बग्स की जाँच करें (जो अक्सर बग नहीं होते हैं, बस खराब परीक्षण और पिछले प्रतिष्ठानों के बारे में भूल जाते हैं)
  3. मैं परिवर्तनों को लागू करता हूं, कार्यान्वयन स्वीकार किया जाता है और फिर एक या दो सप्ताह में यह पता चलता है कि वे नहीं चाहते हैं (वे कुछ संभावित ग्राहक के साथ बात करते हैं जिन्होंने 5 मिनट के लिए सॉफ्टवेयर देखा है और उन्होंने बदलाव का सुझाव दिया है) - मुझे नए बदलाव करने हैं

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

उसी समय हम चुस्त समय सीमा पर काम कर रहे हैं और मुझे आभास है कि हमारे सॉफ्टवेयर के साथ आगे बढ़ने के बजाय हम सर्कल बना रहे हैं।

मैं आपसे सलाह लेना चाहता हूं कि इस स्थिति से कैसे निपटें? क्या यह सामान्य स्थिति है और मैं इसके बारे में सिर्फ हाइपरसेंसिटिव हूं?


जब तक वे यह नहीं कहते हैं - "पिछले साल # $ @ $ का जो ब्लास्ट हुआ था, वह खत्म हो जाना चाहिए था, तो आपको इतना लंबा समय क्यों लगता है?", और समय पर भुगतान करें, यह ठीक है।
कोडर

आपके अंतिम प्रश्न के जवाब में: यह हो सकता है, क्या यह सामान्य है - नहीं, आपको ध्यान रखना चाहिए - हाँ, क्या आपको स्थिति में सुधार करने की कोशिश करनी चाहिए - हाँ। परियोजना की सफलता में सभी शामिल होना चाहिए। कैसे स्थिति में सुधार के लिए - नीचे मेरा जवाब पढ़ें।
डैनी वारोड

यह pm.stackexchange.com के लिए एक बहुत अच्छा सवाल होगा। यहां कोई भी मॉडरेटर्स को लगता है कि इसे स्थानांतरित किया जाना चाहिए?
डैनी व्रोड

क्षमा करें, विरोध नहीं कर सकता: dilbert.com/strips/comic/2007-02-02
Heinzi

रैंडल ओवर xkcd में एक स्पष्ट फ़्लोचार्ट है जो बताता है कि बदलती आवश्यकताओं से कैसे निपटें: xkcd.com/844
जेसन लुईस

जवाबों:


6

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

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

स्टोरी कार्ड

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


आपने इसे रद्द कर दिया है: बिना आवश्यकताओं के सॉफ़्टवेयर न लिखें। आवश्यकताएँ भोजन की तरह होती हैं ..... आप बिना किसी को पकाए खा सकते हैं, लेकिन यह स्वादिष्ट नहीं होगा। यदि "प्रबंधन" एक प्लेट पर आवश्यकताओं को नहीं बढ़ा रहा है, तो आपको रसोई में जाने और खाना पकाने की आवश्यकता है।
मटनज़

1
आवश्यकताएँ भोजन की तरह हैं? आवश्यकताएँ व्यंजनों की तरह हैं। वास्तव में, आवश्यकताएं एक मेनू की तरह हैं ... व्यंजनों एल्गोरिदम हैं, और भोजन स्वयं सॉफ्टवेयर का कार्यान्वयन है।
रॉबर्ट हार्वे

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

3

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

ऐसा लगता है कि यहां सबसे बड़ी समस्या यह है कि बहुत ही तदर्थ तरीके से बदलाव को प्रबंधित किया जाता है। आपके पास क्या है जो चुस्त / स्क्रम एक "उत्पाद के मालिक" पर विचार करता है, जो प्रतिक्रिया देता है, लेकिन प्रक्रिया खराब दस्तावेज है, और खराब सोचा है।

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

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


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

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

मैंने कई बार बिजनेस एडवाइजर से बात की है - उनके लिए पिछले फैसले को संशोधित करना कोई समस्या नहीं है;)
पीटर

1
@Peter, scrum के बारे में चीजों में से एक यह है कि आपने पुनरावृत्ति सीमाओं (आमतौर पर दो सप्ताह) को परिभाषित किया है जिसके दौरान कुछ भी नहीं बदला जाता है। यह आपके लिए बहुत अच्छा हो सकता है।
कार्ल बेज़ेलफेल्ट

1
... तो, अगर यह पूर्ण ज्ञान में किया जाता है कि यह आवश्यकताओं को बदल रहा है, और यह उस परिवर्तन की लागत के पूर्ण ज्ञान में किया जाता है, तो वे आपको उन परिवर्तनों के साथ भुगतान करने के लिए भुगतान कर रहे हैं। ;)
डैनियल पिटमैन

1

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

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

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

मैं जानता हूं कि इस प्रकार के दस्तावेज बनाना ऐसा नहीं है कि आप एक प्रोग्रामर क्यों बने, लेकिन आप इन सूचियों को फेंकने का जोखिम उठा सकते हैं या अपने हार्ड-कोड को दूर फेंक सकते हैं।

पीछे धकेलना। प्रभारी को यह देखने की जरूरत है कि ये अनुरोध कितना महंगा है।


1

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

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


1

आपकी प्रक्रिया कुछ चुस्त सिद्धांतों से लाभान्वित हो सकती है, जैसे पुनरावृत्तियों में बंद। मुझे लगता है कि इस तरह के तेज गति के बदलावों के साथ एक सप्ताह उचित है। 2 सप्ताह अंततः बेहतर काम कर सकते हैं।

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

यदि सप्ताह के मध्य में परिवर्तन आते हैं, तो इन जादुई शब्दों को बोलें:

मैं [यह नई सुविधा], [यह नया परिवर्तन], [आदि] कर सकता हूं , लेकिन आप क्या नहीं करना चाहते हैं ?

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

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


0

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

  1. अंत उपयोगकर्ता को जल्द से जल्द खुश करने और त्वरित प्रगति दिखाने की प्रबंधन की महत्वाकांक्षा।

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

  3. आवश्यकताओं के सत्यापन और पुष्टि के लिए एक औपचारिक प्रक्रिया का अभाव, अनुमोदन के बाद।

  4. गलत व्यक्ति को एक या एक से अधिक भूमिकाएं करने के लिए कहना, वे व्यवसाय विश्लेषक या सिस्टम विश्लेषक भूमिका के लिए आवश्यक रूप से प्रशिक्षित नहीं हैं।

  5. सीमित प्रोटोटाइप।

  6. यह धारणा / आशंका कि यह जल्दी से किया जाना है और अगर इसके आईटी को दोष नहीं देना है।

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


0

मुझे लगता है कि आपको कुछ दिशाओं से यह दृष्टिकोण करना चाहिए:

  1. व्यवसाय सलाहकार के साथ सभी हितधारकों (संपूर्ण विकास टीम सहित) से मिलें (ऑफ़लाइन / ऑनलाइन), डोमेन, दृष्टि और फिर मंथन आवश्यकताओं को एक साथ समझने की कोशिश करें।

  2. आवश्यकताओं / उपयोगकर्ता कहानियों को औपचारिक बनाना, प्रत्येक को ग्रेड करना:
    a। प्राथमिकता (तात्कालिकता / महत्व)
    b। परिपक्वता (इसे कितनी अच्छी तरह परिभाषित किया गया है - अधिकांश हितधारकों द्वारा समझ और सहमति *)
    c। जटिलता (किसी न किसी अनुमान)

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

  3. प्रत्येक कार्यान्वयन से पहले डिजाइन करते समय कुछ कदम आगे सोचने की कोशिश करें - एक लचीली वास्तुकला डिजाइन करें जिसमें परिवर्तनों को समायोजित करने के लिए कमरा हो।

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

आपको मॉडरेटर्स से इस सवाल को PM.stackexchange.com (इसे फ्लैग करके) को स्थानांतरित करने पर विचार करना चाहिए, भले ही यह सवाल यहां फिट हो, लेकिन यह वहां बेहतर होगा।

(*) समझौते के लिए दांव धारक: व्यापार, विपणन, परियोजना प्रबंधन, विकास और क्यूए।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.