आप अपने ग्राहकों को कैसे शिक्षित करते हैं?


9

ग्राहकों को कुछ शिक्षा की आवश्यकता है क्योंकि वे अलग सोचते हैं। ग्राहक सोचते हैं:

  • परियोजना के किसी भी समय में परिवर्तन कोई समस्या नहीं है

  • विवरण महत्वपूर्ण नहीं हैं (अपवाद भी कम हैं)

  • समय पैसा खर्च नहीं करता है (वे एक तय मूल्य सहमत हैं)

  • विनिर्देश में एक वाक्य वास्तविक जरूरतों को पूरा करने के लिए स्वतंत्र रूप से बढ़ाया / पढ़ा जा सकता है - और यह अनुबंध को प्रभावित नहीं करता है। (यहां हम अक्सर "सामान्य ज्ञान" चर्चा - उदाहरण देखते हैं: "निश्चित रूप से जब हम लेखांकन प्रबंधन के बारे में बात करते हैं तो हमें एक चालान प्रबंधन स्क्रीन की आवश्यकता होती है - यह सामान्य ज्ञान है!"

  • सूची चलती जाती है...

मुख्य समस्या यह है कि ग्राहक (कोई फर्क नहीं पड़ता कि बाहरी या आंतरिक / विभाग) नहीं चाहता है या समझ नहीं सकता है। सॉफ्टवेयर निर्माण प्रक्रिया को समझने में मुझे कई साल लग गए और मैं अभी भी सीख रहा हूं, इसलिए वे कुछ महीनों में कैसे कर सकते हैं।

आपका अनुभव क्या है, ग्राहकों को शिक्षित करने का सबसे अच्छा तरीका क्या है?

जवाबों:


8

पिछली गर्मियों में, मैंने एक ग्राहक के साथ बहुत ही समान बातचीत की है।

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

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

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

मैं बस सभी संभावित ग्राहकों की कामना करता हूं कि यह पेशेवर हो और वास्तव में गुणवत्ता की कारीगरी हो।


+1; मैंने पहले इस दृष्टिकोण को नहीं देखा है लेकिन यह बहुत ही आशाजनक, बहुत यथार्थवादी लगता है। आप कह रहे हैं, "हमें पता है कि हमने सब कुछ कवर नहीं किया है, इसलिए हम एक्स% अतिरिक्त की अनुमति दे रहे हैं - लेकिन अगर वह बाहर निकलता है, तो हमारा मीटर वाई पर चलना शुरू हो जाता है।" फायदे का सौदा।
कार्ल मैन्स्टर

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

2

ग्राहक को शिक्षित करें । काश मैं आपके ग्राहक में से नहीं हूँ;)

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

समस्या यह है कि अधिकांश ग्राहक सॉफ़्टवेयर विकास के सभी निहितार्थों के बारे में नहीं जानते हैं और आप उनके व्यवसाय के बारे में जानकारी से अवगत नहीं हैं।

बस एक छोटी सी बात:

परियोजना के किसी भी समय में परिवर्तन कोई समस्या नहीं है

"कोई बात नहीं आप कितनी दूर एक गलत सड़क पर चले गए हैं, वापस मुड़ें।" तुर्की नीतिवचन

मुझे वह कहावत पसंद है, इसलिए जब मैं इसका इस्तेमाल कर सकता हूं, तो मुझे खुशी होगी। अवसर देने के लिए धन्यवाद ;)

यहाँ समाधान के एक जोड़े हैं:

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

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

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

एक और तरीका यह होगा कि संस्करण 1 के रूप में (कम बेकार और विकसित नहीं) आवश्यकताओं को समाप्त कर दिया जाए, और अपने नए विचारों के साथ एक संस्करण 2 को अलग कर दिया जाए।

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


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

प्रोटोटाइप निश्चित रूप से जाने का एक तरीका है, लेकिन प्रोटोटाइप अक्सर वास्तविक प्रणालियों से भिन्न होते हैं और हम उसी स्थिति में समाप्त होते हैं जैसा कि ऊपर वर्णित है।
user7876

शायद यह इसलिए है क्योंकि मैं एक देशी अंग्रेजी बोलने वाला नहीं हूं कि यह शब्द मेरे सिर में अजीब लगता है।

उसे सॉफ्टवेयर डिवेलपमेंट की ट्रेनिंग दें। मुझे यकीन है कि यह मदद करेगा, लेकिन मुझे यकीन नहीं है कि वह उस के लिए भुगतान करने के लिए सहमत होंगे :)

2

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

यह अधिकांश उद्योगों में व्यापक रूप से स्वीकृत अभ्यास है लेकिन कुछ ग्राहक इससे बहुत परेशान होंगे।

अगर आपको लगता है कि एक बड़ी समस्या है, अगर आपके पास "सामान्य ज्ञान" का तर्क है।

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

संदेश आखिरकार मिल गया लेकिन इसमें लंबा समय लग गया।


0

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

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

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

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