ग्राहकों से अनुरोध के प्रकार "आप केवल कुछ और क्षेत्रों को कैसे जोड़ सकते हैं"?


12

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

  • हम कैसे सुनिश्चित कर सकते हैं कि ग्राहक को वास्तव में इन सुविधा अनुरोधों की आवश्यकता है?

  • हम विनम्रता से कैसे कहते हैं "आपको वास्तव में इसकी आवश्यकता नहीं है"?

वर्तमान में हम कुछ फ़ीचर अनुरोधों के लिए शुल्क लेना शुरू कर रहे हैं। (पहले, सुविधा अनुरोध आमतौर पर मुफ्त थे) क्या हम कुछ और कर सकते हैं?


मेरी सांस के नीचे बहुत से बड़बड़ाते और कोसते हुए>। <आखिर, वे मुझे पैसे दे रहे हैं ....
राहेल

जवाबों:


16

क्या वे अतिरिक्त सुविधाओं के लिए भुगतान कर रहे हैं? यदि हां, तो यह वास्तव में आपका व्यवसाय नहीं है कि वे उनका उपयोग कर रहे हैं या नहीं। उन्हें वह दें जो वे भुगतान करते हैं। यदि, हालांकि, ऐसा नहीं है, तो यह तय करना आपके नेतृत्व पर निर्भर है कि क्या वे बिना अतिरिक्त आय के सुविधाओं को जोड़ना चाहते हैं।


2
अच्छी तरह से वे भुगतान कर रहे हैं, लेकिन हम वास्तव में बड़े फीचर अनुरोधों पर ध्यान केंद्रित करना चाहते हैं जो कि वे (और वह हमें भविष्य में और अधिक ग्राहक प्राप्त कर सकते हैं) के बजाय तुच्छ छोटे अनुरोधों के बहुत सारे हैं जो कोड को अव्यवस्थित कर रहे हैं।
अर्लज़

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

2
यदि आप 5% ग्राहकों को खो कर 50% तक की कटौती कर सकते हैं, तो यह एक अच्छा सौदा है, पारंपरिक ज्ञान है। क्या ये कस्टम फील्ड वास्तव में थोड़ा इनाम के लिए बहुत अधिक पसीना है?
9000

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

3
@ मैं जिस रवैये का जिक्र कर रहा था, उसका प्रदर्शन करने के लिए धन्यवाद एम। ग्राहक तकनीक को नहीं समझ सकते हैं, लेकिन वे आमतौर पर बेवकूफ नहीं हैं। यह आमतौर पर डेवलपर है जो व्यवसाय की आवश्यकता को नहीं समझता है। इसके अलावा, यदि कोई फीचर जोड़ने से एप्लिकेशन की अखंडता समझौता हो जाती है, तो यह खराब एप्लिकेशन डिजाइन का संकेत है।
जॉन क्राफ्ट

3

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

बात करना आपको यह भी दिखाएगा कि क्या वे पूछ रहे हैं कि क्या वास्तव में यह महत्वपूर्ण है।


3

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

बड़ी संख्या में ग्राहक क्षेत्रों को संभालने के लिए अपने आवेदन को आसान बनाने के तरीकों पर विचार करना शुरू करें।

  1. मौजूदा फ़ील्ड का उपयोग करने के लिए ग्राहक द्वारा रिपोर्ट और फ़ॉर्म में लेबल की अनुमति दें।
  2. मौजूदा या अतिरिक्त कस्टम फ़ील्ड तालिकाओं में सामान्य फ़ील्ड (स्ट्रिंग 12) जोड़ें।
  3. एक उपयोगकर्ता परिभाषित क्षेत्र प्रणाली है जहां यह सब डेटा प्रविष्टि द्वारा नियंत्रित किया जाता है और तालिकाओं में नए कॉलम बनाने के लिए नहीं है (मुझे याद नहीं है कि इसे क्या कहा जाता है-सहायता)।

आप पा सकते हैं कि मौजूदा ग्राहक आपके सिस्टम को बढ़ा रहे हैं। उद्योग में बदलाव हो सकता है इसलिए नई आवश्यकताएं बढ़ रही हैं।

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


3

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

स्थिर स्तंभों के साथ WIDGET तालिका:

  • WIDGET_ID
  • WIDGET_NAME
  • WIDGET_COST
  • आदि।

उपयोगकर्ता-निश्चित कॉलम के साथ WIDGETCUSTOM तालिका:

  • WIDGET_ID
  • WIDGET_WEIGHT
  • DID_BOB_WORK_ON_WIDGET
  • आदि।

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

एक प्रोग्रामिंग दृष्टिकोण से, मैं देखता हूं कि यह कैसे समझदार रखेगा। हर ग्राहक के अपने कस्टम कॉलम हो सकते हैं, लेकिन वे कस्टम कॉलम आपके मुख्य तर्क के साथ हस्तक्षेप नहीं करते हैं।


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

1
अगर आप इसे एक साल में संभाल सकते हैं, तो इसमें क्या बड़ी बात है?
जेएफओ

@ जफ एक साल यह मानते हुए कि हम इन फीचर रिक्वेस्ट से मतलबी नहीं हो रहे हैं .. मूल रूप से निर्बाध विकास समय का एक वर्ष
अर्ल २३'११

1

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

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


2
याद रखें, हर समस्या के पीछे एक समाधान बनाने का अवसर होता है, और फिर उसे किसी को बेच दिया जाता है;)
Matt

0

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

मुझे यह समझने में कठिन समय हो रहा है कि आप इसकी देखभाल करते हैं कि वे इसका उपयोग करते हैं या नहीं। यह सरल है, आप जो चाहते हैं उसका निर्माण करते हैं और आप इसके लिए भुगतान करते हैं।

कोड आधार अव्यवस्था? यदि आपको नई सुविधा में काम करते समय अपने कोड को फिर से लिखने की आवश्यकता है, तो इसके लिए उन्हें चार्ज करें।


0

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

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


0

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


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

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

1
आयरनकोड, आप सही कह रहे हैं। मैं बैंक ऑफ अमेरिका में काम करता हूं और हमारी टीम बिजनेस यूनिट को बग्जिला बग प्राथमिकता के माध्यम से सुविधा अनुरोधों को प्राथमिकता देती है। वे बग दर्ज करते हैं, फिर कीड़े को प्राथमिकता देते हैं। वे कभी भी प्राथमिकता बदल सकते हैं, और हम समायोजित करते हैं। हां, कभी-कभी यह स्विचिंग की लागत को बढ़ाता है, लेकिन हमने पाया है कि यह व्यवसाय के लिए अधिक प्रभावी है। ध्यान दें कि यह संभवतः मूल पोस्टर के लिए काम नहीं करेगा, क्योंकि प्रबंधन के पास अपने ग्राहकों के लिए लक्ष्य हो सकते हैं। (एक तरफ एक झुकाव के रूप में, यह प्रबंधन दृष्टिकोण गुमराह लगता है)
क्रिस्टोफर महान

0

मुझे लगता है कि आपको अपने ग्राहक को "कार्यालय में एक दिन" के माध्यम से एक या अधिक डालने के लिए कहना चाहिए, यह देखने के लिए कि वे वास्तव में सॉफ़्टवेयर का उपयोग कैसे करते हैं ... प्रतीक्षा करें ... मुझे $ 250 / घंटे के लिए किराए पर लें और मैं पता लगाऊंगा। इसके अलावा, कृपया, गोल्डप्लेट न करें। इसे सिर्फ काम बनाओ। अधिकांश व्यवसाय यह ध्यान नहीं देते हैं कि जब यह अच्छी तरह से काम करता है तो यह बदसूरत दिखता है।


हमने ऐसा किया है। यही कारण है कि हम जानते हैं कि जब सुविधा अनुरोधों का उपयोग नहीं किया जाएगा।
अर्लज़

आह, ठीक है, तो ग्राहक कंपनी में राजनीतिक झगड़े हैं। तुम पागल हो। या आप Steaks और स्ट्रिपर्स उन्हें सकता है।
क्रिस्टोफर महान

0

अनुरोध ट्रैक करें। जैसा कि आप बड़ी विशेषताओं को डिजाइन / विकसित करने के लिए प्राप्त करते हैं, उस रिलीज में शामिल करने के लिए प्राथमिकता वाले अनुरोधों में से एक को चुनें।


0

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

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

0

यदि ग्राहक के पास आवेदन का कुल स्वामित्व है, तो वे वही करें जो वे पूछते हैं। उन्हें उनके पैसे उड़ा दें; यह उनका है।

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

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

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