उपयोगकर्ता की देखभाल करना, या ग्राहकों को त्रुटियों से कैसे बचाएं

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



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

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

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

1. उपयोगकर्ता को सीमित करने का कोई तरीका नहीं है, अर्थात्, उस पर भरोसा करें कि वह गलतियां न करें और खुद को या सिस्टम के मालिक को नुकसान न पहुंचाए।
2. आंशिक रूप से सीमा - उपयोगकर्ता एक गलती कर सकता है, लेकिन कम संभावना (या कम गंभीर)।
3. आवश्यक प्रतिबंधों का परिचय दें , लेकिन अत्यधिक नहीं - उपयोगकर्ता इतना सीमित है कि वह गलती नहीं कर सकता है, लेकिन प्रतिबंध सिस्टम का उपयोग करने में समस्याएं पैदा नहीं करता है। यह एक आदर्श विकल्प है।
4. यह सीमित करने के लिए अनावश्यक है - उपयोगकर्ता सीमित है ताकि यह उसे सिस्टम का उपयोग करने से रोकता है।
5. उपयोगकर्ता को पूरी तरह से सीमित करें , अर्थात् सुविधा को ब्लॉक करें।

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

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

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

• ऋणी को कॉल करने के लिए एक कार्य का असाइनमेंट;
• असाइन किए गए कार्य का कार्यान्वयन;
• बातचीत का परिणाम तय करना (उपयोगकर्ता द्वारा मैन्युअल रूप से);
• देनदार ^{1 के} साथ बातचीत की आवृत्ति पर रूसी संघ के कानून की आवश्यकताओं का अनुपालन सुनिश्चित करना।

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

उपयोगकर्ता अनुभव की सुविधाओं के बारे में क्या ज्ञात हो गया है? यह पता चला कि देनदार के मोबाइल तक पहुंचने के असफल प्रयास के मामले में, ऑपरेटर न केवल कार्य को स्थगित कर देगा, बल्कि यह भी कि यदि कोई अन्य नंबर देनदार को सौंपा गया है, तो तुरंत उन तक पहुंचने का प्रयास करें।

तंग समय सीमा को देखते हुए, विश्लेषक को फिर से परियोजना में विसर्जित करना अव्यावहारिक था, इसलिए हमारे क्यूए विशेषज्ञ को यह विचार करने के लिए कार्य मिला कि क्या मौजूदा कार्यान्वयन इस बात के अनुरूप है कि आवेदन को ग्राहक पक्ष में कैसे उपयोग करने की योजना है। विश्लेषण के दौरान, हमने निम्नलिखित तार्किक श्रृंखला बनाई:

1. ऋणी के पास कई नंबर (मोबाइल, घर, काम) हो सकते हैं, लेकिन आप केवल एक नंबर पर कॉल शेड्यूल कर सकते हैं।
2. यदि ऑपरेटर ग्राहक तक पहुंचने में विफल रहता है, तो कार्य स्थगित हो जाएगा, लेकिन फिर भी दूसरे नंबर पर कॉल करना असंभव होगा, क्योंकि लंबित कार्य अन्य नंबरों पर कॉल की नियुक्ति को भी रोक देगा।
3. इसलिए, किसी अन्य संख्या तक पहुंचने का प्रयास करने के लिए, उपयोगकर्ता को लंबित कार्य को मैन्युअल रूप से रद्द करने और एक नया असाइन करने की आवश्यकता है।
4. लेकिन एक ही समय में और अन्य संख्या के माध्यम से प्राप्त करने में सक्षम नहीं हो सकता है। और फिर डायलन की कमी के कारण कार्य स्थगित हो गए, यह पता चला, रद्द कर दिए गए थे। आपको बाद में फिर से कॉल करने के लिए उन्हें फिर से नियुक्त करने की आवश्यकता है।

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

इसके अलावा, घटनाओं की स्वचालित नियुक्ति (इसके बाद - ASANM) के लिए एक विश्लेषणात्मक प्रणाली के साथ कलेक्टर सॉफ्टवेयर को एकीकृत करने के लिए एक कार्यात्मक विकसित करने की योजना बनाई गई थी, जो ग्राहक पक्ष पर बनाई गई थी। सार इस प्रकार था:

• दैनिक (दिन में एक बार) एएसएएनएम उन कार्यों की एक सूची बनाता है जिन्हें अनुबंधों के तहत किया जाना चाहिए, और कलेक्टर सॉफ्टवेयर को एक अनुरोध भेजता है;
• सॉफ़्टवेयर प्राप्त सूची से कलेक्टर उन कार्यों को असाइन करता है जो इंटरैक्शन की सीमा से अधिक नहीं हैं।

क्यूए विशेषज्ञ के निष्कर्ष के अनुसार, मौजूदा कार्यान्वयन में, ऑपरेटर और एएसएएनएम दोनों सभी देनदार संख्याओं के लिए कॉल शेड्यूल नहीं कर पाएंगे।

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

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

• गतिविधियों के परिणामों के आधार पर इंटरैक्शन की संख्या की गणना करें;
• यदि सीमा समाप्त नहीं हुई है, तो उपयोगकर्ता / ASANM को प्रतिबंधों के बिना घटनाओं को शेड्यूल करने की अनुमति दें;
• यदि सीमा समाप्त हो गई है, तो अनावश्यक घटनाओं को रद्द करें और उनकी नियुक्ति पर रोक लगाएं।

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

निष्कर्ष

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

1. "पर्याप्त संख्या में nannies के साथ, बच्चा अपनी आंख नहीं खोएगा" - अर्थात, आपको उपयोगकर्ता को गलतियों से बचाने के लिए पर्याप्त रूप से रक्षा करने की आवश्यकता है जो उसे या सिस्टम के मालिक को नुकसान पहुंचा सकते हैं।
2. "भेड़ियों से डरना, लेकिन जंगल में जाना" - अनावश्यक प्रतिबंधों से बचा जाना चाहिए, क्योंकि अन्यथा उपयोगकर्ता के लिए विकसित उत्पाद का मूल्य खो जाता है।

---

¹ आवश्यकताएं 03.07.2016 के संघीय कानून द्वारा स्थापित की जाती हैं। एन 230-the "अधिकारों की सुरक्षा और व्यक्तियों के कानूनी हितों पर जब अतिदेय ऋणों को वापस करने और संघीय कानून" माइक्रोफाइनेंस एक्टिविटीज और माइक्रोफाइनेंस ऑर्गेनाइजेशन में संशोधन करने के लिए गतिविधियों को किया जाता है।