क्लाइंट के लिए एक प्रोग्रामर "सोचना" चाहिए?


12

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

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

एक निगम के लिए काम करते हुए, मैं फुर्तीले मॉडल को फिट करने के लिए संस्कृति को समायोजित करने की कोशिश कर सकता था जो हमें मदद करेगा (मेरे वेतन ग्रेड से ऊपर कोई छोटा काम नहीं)। या, गलीचा के नीचे बदसूरत विवरण स्वीप करें और सर्वश्रेष्ठ के लिए आशा करें। शायद मेरा ग्राहक कोड के बहुत करीब जाने की कोशिश कर रहा है?

"ग्राहक के लिए सोच" की समस्या को बहुत अधिक सवालों के साथ पेशाब किए बिना कैसे संभालता है?


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

@ डंक - माफ करना अगर मैं झरने के प्रशंसकों को नाराज करता हूं। मैं प्रोजेक्ट मैनेजर नहीं हूं। मैंने "" और मेरी परिभाषा के साथ प्रतिमान को अर्हता प्राप्त की जो हर किसी को समझने और झरने का उपयोग करने का तरीका हो भी सकता है और नहीं भी। मेरा मतलब केवल आम तौर पर समझे जाने वाले प्रतिमानों के साथ अपनी बात स्पष्ट करना है, न कि उन पर बात करना।
पी। ब्रायन। मैके

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

जवाबों:


16

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

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

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

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

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

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


4
इसके अलावा, आपको उस व्यवसाय को समझने में कुछ समय बिताने की आवश्यकता है जिसमें आप काम कर रहे हैं। प्रोग्रामिंग के कई प्रश्न इस बात से प्रभावित होंगे कि यदि आप समझते हैं कि व्यवसाय कैसे काम करता है।
माइकल के

सर्वश्रेष्ठ समग्र उत्तर, लेकिन @whatsisname लेख पोस्टिंग उत्तर के लिए एक अद्भुत प्रशंसा है (किसी अन्य ग्राहक को खोजने की आवश्यकता से असहमत हालांकि मुझे क्लाइंट के बारे में अपना दृष्टिकोण सुधारने की आवश्यकता है)।
पी। ब्रायन। मैके

6

यदि आप बहुत सारे प्रश्नों से 'उन्हें दूर कर रहे हैं', तो बेहतर ग्राहक प्राप्त करें।

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

ऐसा करने के लिए आपको यह सीखना होगा कि आप क्या कर रहे हैं। आपको यह नहीं पूछा जाना चाहिए कि "टेक्स्ट बॉक्स में नंबर डालने पर क्या होना चाहिए ?" क्या आपने उन्हें सिखाया है कि वे अपना काम कैसे करते हैं। और वे जो कहते हैं, उसे मत सुनो, क्योंकि वे नहीं जानते कि वे क्या चाहते हैं, लेकिन देखो कि वे क्या करते हैं और उनकी आँखें कहाँ जाती हैं

अधिक जानकारी के लिए इसे पढ़ें: http://www.joelonsoftware.com/articles/fog0000000356.html


3

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

यदि यह बहुत कठिन, दर्दनाक, अत्यंत अप्रिय या अवास्तविक लगता है, तो मेरी अंतिम सलाह होगी कि एक नई नौकरी की तलाश शुरू करें, जहां उनके पास व्यवसाय विश्लेषक हैं, क्योंकि यह आपके लिए कुछ प्रयास किए बिना आसान नहीं है।


2

यदि आप आवश्यकताएं एकत्रित कर रहे हैं तो इन सवालों को पूछना आपका काम है।

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

इसका साइड इफेक्ट यह है कि आपको क्लाइंट की जरूरतों को पूरा करने में मदद करनी चाहिए।

यह लागू होता है चाहे आप बिग डिज़ाइन अप फ्रंट या एजाइल कर रहे हों।


2

अफसोस की बात है कि क्लाइंट के लिए यह सोचना आपका काम है कि वह खुद ऐसा कर भी सकता है या नहीं।

मेरे पास दोनों संभावित परिणाम हैं:

  • ग्राहक खुश है कि आप वास्तव में सोच रहे हैं कि वह आपको क्या बताता है, उसे लगता है कि वह सही हाथों में है, या

  • ग्राहक नाराज है क्योंकि आप उसे अपनी आवश्यकताओं के बारे में फिर से सोचने के लिए मजबूर करते हैं। लेकिन फिर, इस प्रकार का ग्राहक आपके साथ वैसे भी, जल्दी या बाद में नाराज हो जाएगा। यदि वह शुरुआत में उसके बारे में नहीं सोचता है तो वह निश्चित रूप से बहुत नाराज हो जाएगा। मैं कहूँगा: यदि संभव हो तो इस प्रकार के ग्राहक से बचें :-)


1

एक रैपिड एप्लिकेशन डेवलपमेंट (आरएडी) इस समस्या को अच्छी तरह से संबोधित करता है।

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

ऐसा नहीं है कि वे नहीं जानते कि वे क्या चाहते हैं। यह है कि वे नहीं जानते कि वे क्या चाहते हैं जब तक वे इसे नहीं देखते हैं, और कभी-कभी आप यह निर्धारित कर सकते हैं कि वे क्या चाहते हैं। यही है, उन्हें कुछ दिखाना जो वे नहीं चाहते हैं और ध्यान दें कि वे इसकी आलोचना कैसे करते हैं।

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

यदि ग्राहक डिलिजेबल से खुश नहीं है तो यह केवल एक जीत है।


1

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


0

ईमानदारी से: जब तक यह 'बड़ी कार्यक्षमता' न हो, तब तक सबसे अधिक डोमेन ज्ञान रखने वाला व्यक्ति अपना सर्वश्रेष्ठ अनुमान लगा सकता है कि क्या होना चाहिए, और उस पर अमल करना चाहिए। यह स्वीकार्यता परीक्षण में बाहर हो जाएगा - जो कि इसके लिए है।

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