स्क्रम में, डेवलपर्स को ग्राहकों से सीधे बात करनी चाहिए (पीओ को दरकिनार करके)?


12

एक उत्पाद के मालिक को टीम से बहुत विस्तृत प्रश्नों के साथ उन विशेषताओं के बारे में कैसे व्यवहार करना चाहिए जिन्हें वे लागू कर रहे हैं कि वह तुरंत खुद को जवाब नहीं दे सकते हैं? जब यह स्पष्ट रूप से डेवलपर के लिए ग्राहक से सीधे बात करने का तेज़ समाधान होगा?

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

क्या स्क्रम में सबसे अच्छा अभ्यास है?


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

"जब यह स्पष्ट रूप से तेज समाधान होगा ..." बस स्पष्ट इंगित करना चाहते हैं: तेजी से जरूरी बेहतर नहीं है।
एरिक किंग

जवाबों:


23

यह हमेशा एक अच्छा विचार है (विशेष रूप से तथाकथित फुर्तीली परियोजनाओं में) कुछ कार्गो पंथ या पाठ्य पुस्तक से यह न कहने के लिए कि "आपको किससे (किससे बात नहीं करनी चाहिए"), लेकिन अपने मस्तिष्क पर स्विच करें और जो कुछ भी सबसे अच्छा काम करता है परियोजना।

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

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

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


"फुर्तीली विकास का पूरा विचार है - कुछ कार्गो पंथ या पाठ्य पुस्तक से चिपकना नहीं, बल्कि अपने मस्तिष्क पर स्विच करना और जो कुछ भी परियोजना में सबसे अच्छा काम करता है।": सच है, लेकिन यह विचार चुस्त करने के लिए विशिष्ट नहीं है।
जियोर्जियो

1
+ 1 अगर फुर्तीले तरीके से काम किया जाए, तो एक व्यवसाय विशेषज्ञ शायद टीम का हिस्सा होगा और वैसे भी उपलब्ध होगा ...
मार्जन वेनमा

1
सही। पीओ को कभी गेट कीपर नहीं होना चाहिए। इसके बजाय, पीओ उत्पाद के लिए अंततः जिम्मेदार है।
रोबोट

@StevenBurnap का मतलब होगा कि पीओ को शुरुआत से ही क्षेत्र में एक विशेषज्ञ होने की जरूरत है ... मेरे अनुभव में, हमेशा ऐसा नहीं होता है।
tizenegy

3
@ जिओर्जियो: बिल्कुल, IMHO "फुर्तीली विकास" सिर्फ एक चर्चा है जो कुछ अच्छी आदतों को शामिल करता है जो शब्द की तुलना में बहुत पुराने हैं, और खुद तक सीमित नहीं हैं।
डॉक्टर ब्राउन

2

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

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


सभी के लिए लक्ष्य बजट के तहत और लक्ष्य पर सर्वोत्तम संभव उत्पाद पहुंचाना होना चाहिए। यह केवल यह है कि ऐसा कैसे करें कि चर्चा का एक संभावित स्रोत है।
27'15 को शाम

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

1

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

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


"लाइनें वास्तव में आपके भावी उपयोगकर्ता को कोडिंग करते समय आपके बगल में बैठने से कम नहीं हो सकती हैं :)": क्या यह हमेशा अच्छा होता है यह संदिग्ध है।
जियोर्जियो

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

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

@ जियोर्जियो: "उत्पाद मालिक एक वरिष्ठ अंतिम उपयोगकर्ता और डोमेन विशेषज्ञ हैं जो मौके पर डिजाइन निर्णयों को प्राधिकृत करने के लिए पूर्ण अधिकार के साथ हैं" जो आपके पीओ की तरह लगता है कि डेवलपर्स के हर सवाल का जवाब दे सकता है। मैं एक अलग स्थिति पर भरोसा कर रहा था: एक पीओ जो अभी भी ग्राहकों के रूप में विशेषज्ञता के समान स्तर पर नहीं है और इसलिए उन्हें और अधिक कठिन सवालों के जवाब देने के लिए नियमित आधार पर उन्हें वापस लेने की आवश्यकता है।
tizenegy
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.