क्या सॉफ्टवेयर डेवलपर की यह जिम्मेदारी है कि वह समझे कि ग्राहक उसके अनुरोध का क्या मतलब है?


12

एक हाँ / नहीं सवाल और क्यों की तरह?

क्या सॉफ्टवेयर डेवलपर की जिम्मेदारी यह समझने की है कि ग्राहक उसके अनुरोध का क्या मतलब है या क्या यह ग्राहक की जिम्मेदारी है कि वह डेवलपर को उसके अनुरोध को ठीक से समझा सके?

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

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

मैं सिस्टम का तीसरा या चौथा डेवलपर हूं (अंतिम डेवलपर्स ने नौकरी छोड़ दी) और यही कारण हो सकता है कि ग्राहक डेवलपर्स की ओर से कुछ समझ की उम्मीद करता है।

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

मैं वास्तव में नौकरी छोड़ने के बारे में सोच रहा हूं, लेकिन अभी तक नहीं दिया है, क्योंकि मुझे यकीन नहीं है कि कौन सही है और कौन गलत है।


1
वहाँ रहा है ... T_T
सांगो

6
यह दो से टैंगो लेता है
gnat

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

14
@ जॉन्नेवरमोर: मैं तर्क देता हूं कि टीम लीड को सवालों के घेरे में लाएगी। यह आपके प्रभाव के दायरे से परे है कि आपके सामने डेवलपर्स कहाँ हैं, और यह आपको समस्या को समझने की आवश्यकता नहीं है। यदि वह जवाब देने से इनकार करता है, तो दौड़ें।
कीपला

4
अपने गधे को कवर करें, एक ईमेल प्राप्त करें आपको बताया गया था कि प्रश्न पूछने और बाद में उपयोग के लिए सहेजने के लिए नहीं अगर कोई आपके पास वापस आता है। फिर आपके द्वारा दिए गए समय का कोड। आपकी जिम्मेदारी आदेशों या जोखिम को मानने की है।
फिल हैनेंट

जवाबों:


41

यदि यह समझने के लिए आपका काम है, तो यह सवाल करना है कि आप क्या करते हैं

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

लेकिन, अंत में कुछ प्रकार का संचार होना चाहिए। यदि वे इसका खंडन करते हैं (और कुछ दस्तावेज प्रदान करते हैं जिन्हें आप नहीं समझते हैं कि प्रभावी रूप से संचार से इनकार कर रहे हैं), तो आपको ऐसा करना चाहिए जैसा कि आपके पूर्ववर्तियों ने किया था: जल्दी से भाग जाओ।


22
एक सूत्र के रूप में: हर बार जब मैंने इस तरह का व्यवहार देखा, तो यह था कि ग्राहक को आश्वासन दिया गया था कि यह सुविधा पहले से ही लागू थी , और अगर कोई इसे कैसे करना है पर सवाल होगा, तो यह उनके झूठ का पर्दाफाश करेगा।
कीपला

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

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

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

6

जब आपके ग्राहक और वरिष्ठ आपको एक गन्दा कागज निशान के साथ छोड़ देते हैं, तो केवल एक चीज जो आप कर सकते हैं, वह उतना ही समझ में आता है जितना आपके पास है और यह समझने के लिए कि कैसे ज्ञान के बारे में ज्ञान है। सिस्टम को व्यवहार करना चाहिए।

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

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


6

मेरी राय में दोनों (ग्राहक और डेवलपर) को समस्या और इसके समाधान के बारे में समान समझ प्राप्त करनी होगी ।

यदि आप अनुरोध को नहीं समझते हैं तो आप समाधान नहीं बना सकते हैं।

तो आपको चश्मा पढ़ना होगा। यदि कल्पना पर्याप्त रूप से स्पष्ट नहीं है (या कोई लिखित युक्ति नहीं है) तो कोई ऐसा व्यक्ति होना चाहिए जो उत्तर दे सके।

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


3

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

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

कुछ कारण हैं कि परियोजना प्रबंधक आपको सवाल पूछने की अनुमति नहीं दे सकता है:

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

IMO कारण 2 की संभावना नहीं है। कारण 1 को खत्म करने के लिए, उसके लिए विकल्पों की व्याख्या करने का प्रयास करें और उसे उन दोनों के बीच एक स्पष्ट विकल्प बनाने के लिए कहें - ग्राहक को झुंझलाहट को कम करने के लिए समस्या को समझाने का सुझाव दें। कारण 3 को खत्म करने के लिए, इसे लिखित रूप में करें ताकि आप यह साबित कर सकें कि आप संभावित प्रोब्लम्स के बारे में पहले से जानते थे और उन्हें ठीक करने का प्रयास किया था। लेकिन ईमानदार होने के लिए, यदि आपको संदेह है कि यह आवश्यक है तो आपको संभवतः जल्दी से जल्दी वहां से निकल जाना चाहिए।


2

मुझे लगता है कि यह सुनिश्चित करना हमेशा सेवा प्रदाता की जिम्मेदारी है कि वे ग्राहकों के इरादों को समझें।

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

मेरा मानना ​​है कि ग्राहक केंद्रित दृष्टिकोण चीजों को करने का तरीका है, यह एक आजमाया हुआ और परीक्षण किया गया व्यावसायिक मॉडल है।


2

ग्राहक और डेवलपर्स को सिस्टम की अपनी समझ को परिष्कृत करने के लिए एक साथ काम करने की आवश्यकता है।

सॉफ्टवेयर कंपनी को क्लाइंट के साथ एक समझौते पर आने की जरूरत है क्योंकि प्रत्येक पार्टी की आवश्यकता है, जो एक अनुबंध का मूलभूत पहलू है। यदि "मन की बैठक" नहीं है, तो बहुत वास्तविक अर्थों में, कोई अनुबंध नहीं है।

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


2

यह मूल प्रश्न पर टिप्पणियों में कुछ नई जानकारी पर आधारित है।

कथन है कि

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

परियोजना के नेता से आता है; कहा गया तर्क है

चूँकि मैं सिस्टम का पहला डेवलपर नहीं हूं, इसलिए हमें ग्राहक के प्रतिनिधि को अधिक प्रश्नों से परेशान नहीं करना चाहिए, लेकिन यदि आवश्यक हो, तो प्रश्न की व्याख्या करने के लिए अतिरिक्त समय बिताने की कोशिश करें

तो जो आपको विशेष रूप से बचने के लिए कहा जा रहा है वह ग्राहकों को सवालों से परेशान कर रहा है

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

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

ये लोग क्या चाहते हैं ??? "

कुछ ऐसा पूछें,

आवश्यकताओं दस्तावेज़ के पैराग्राफ 17 में, यह कहता है कि फ़ॉबर को फ्रोज़ल को भूनना चाहिए; इन तीन में से कौन सी फ्रोजल का उल्लेख है? "

या, यदि आवश्यकताएँ वास्तव में इतनी बुरी तरह से लिखी गई हैं कि आप उन्हें समझ नहीं सकते हैं, तो उन्हें बताएं।

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


प्रोजेक्ट लीड में इसे आगे बढ़ाने के लिए +1। यह सुनिश्चित करना हर किसी के पास जरूरी संसाधन है कि प्रोजेक्ट लीड की मुख्य जिम्मेदारी है - इसमें आवश्यक जानकारी होना शामिल है।
sleske

1

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

आपके प्रश्न का उत्तर देने के लिए, डेवलपर को वास्तव में समझना चाहिए कि ग्राहक क्या चाहता है, और एक लिखित दस्तावेज है ताकि दोनों पक्ष एक ही दृष्टि से सहमत हों।

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

यदि आपकी स्थिति में नहीं है, तो मैं कोशिश करूँगा और पिछले डेवलपर्स से जानकारी प्राप्त करूँगा, यह मानते हुए कि वे निश्चित रूप से कार्य को समझ गए हैं।


1

मुझे लगता है कि इन आवश्यकताओं में से कुछ के आधार पर वास्तविक आवश्यकताओं को ध्यान में रखने वाली वास्तविक भूमिका अलग-अलग होती है

  • समुहआकार
  • कंपनी के मानक
  • जिस तरह से बॉस को काम करने के लिए इस्तेमाल किया जाता है
  • टीम के सदस्यों के बीच विभिन्न विशेषज्ञता

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

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

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