बेहतर त्रुटि विवरण भेजने के लिए अपने उपयोगकर्ताओं / ग्राहकों को कैसे सिखाना है

16

मुझे अक्सर ग्राहकों या उपयोगकर्ताओं से निपटना पड़ता है जो अनुप्रयोगों में त्रुटियों की रिपोर्ट कर रहे हैं। अधिकांश समय उनकी सामग्री कुछ बेकार होती है

त्रुटि !!!
x काम नहीं करता है

अधिक जानकारी के बिना।

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

आप अपने उपयोगकर्ताओं / ग्राहकों को अधिक विवरणों के साथ समस्याओं का वर्णन करने के लिए कैसे कहते हैं ताकि दोनों पक्षों के लिए पूरी प्रक्रिया आसान हो सके?

संपादित करें

यह सवाल सामाजिक कौशल के बारे में अधिक है कि लॉग और त्रुटि जानकारी के प्रोग्रामेटिक संग्रह को कैसे प्राप्त किया जाए। मैं इस तथ्य से अवगत हूं कि यह अच्छे सॉफ्टवेयर डिजाइन का हिस्सा होना चाहिए।

debugging client-relations errors

— ccellar
स्रोत

24

आप नहीं करते हैं, आप अपने सॉफ़्टवेयर को त्रुटि लॉग / संदेश भेजने के लिए डिज़ाइन करते हैं।

— महमूद होसम

8

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

— temptar

1

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

— FrustratedWithFormsDesigner

1

"दोनों पक्षों के लिए आसान"? दोनों पक्षों? वे पहले से ही कर रहे हैं जो उनके लिए सबसे आसान है।

— 4

1

आप एप्लिकेशन को नियंत्रित नहीं कर सकते, लेकिन आपको लगता है कि आप उपयोगकर्ताओं को नियंत्रित कर सकते हैं? आप गलत क्षेत्र में हैं।

— जेएफओ

5

अच्छी बग रिपोर्ट के लिए अपने उपयोगकर्ताओं को पुरस्कृत करें, उन्हें बुरे लोगों के लिए दंडित करें (अच्छी तरह से कम से कम थोड़ा)।

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

तो पहली प्रतिक्रिया कुछ इस तरह की हो सकती है "ठीक है, मैंने आपकी रिपोर्ट पढ़ ली है, लेकिन मुझे नहीं पता कि कहां से शुरू किया जाए। क्या आप मुझे बता सकते हैं: क्या यह एक बार हुआ है? क्या यह आवर्ती फेनोमेनन है? क्या आप एक्स की कोशिश कर सकते हैं और मुझे बता सकते हैं कि क्या है?" Y उसके बाद जैसा दिखता है? " और इसी तरह।

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

हां, यह एक चरण-दर-चरण प्रक्रिया है और कल सुबह तक संचार की सभी समस्याओं को ठीक नहीं करेगी, लेकिन फिर भी यह एक शुरुआत है।

— perdian
स्रोत

2

उन्हें बुरी खबरों के लिए सजा दें: उन सवालों की एक सूची के साथ जवाब दें, जिनका उन्हें जवाब देने की जरूरत है, और जानकारी होने पर उनके समर्थन अनुरोध को फिर से सबमिट करने के लिए कहें। पीछे कतार में!

— कर्क ब्रॉडहर्स्ट

कभी-कभी मेटा सूचना के साथ बग / त्रुटि का एक उचित एनोटेट स्क्रीनशॉट होना पर्याप्त होता है। Usersnap एक छोटा बटन है जिसे आप आसान बग रिपोर्टिंग सक्षम करने के लिए अपने वेब प्रोजेक्ट में जोड़ सकते हैं।

— ग्रेगोर

17

एक चीज जो मैंने कई ओपन-सोर्स प्रोजेक्ट देखी है, वह है बग रिपोर्ट के लिए एक मानक "फ़ॉर्म" लिखना, जिसमें आमतौर पर आवश्यक जानकारी के लिए अनुभाग होते हैं।

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

आपके मामले के लिए, यह कुछ इस तरह हो सकता है:

URL where the error occurred:

What you did:

What you expected to happen:

What actually happened:

<Some other information you (ckeller & colleagues) often find useful>:

Any extra information you think might be relevant:

("आप" यहां ग्राहकों को संदर्भित करता है)

विचार यह है कि उन्हें उस तरह की जानकारी प्रदान करने के लिए उपयोगी जानकारी प्रदान करने के लिए प्रोत्साहित करें जो सबसे अधिक बार उपयोगी होती है।

— फ्रिट्स
स्रोत

1

+1: जब किसी टेम्प्लेट का सामना किया जाता है, तो लोग आमतौर पर इसे भरने की कोशिश करते हैं। और यदि वे ऐसा नहीं करते हैं, तो आपको रिपोर्ट भरने के लिए कहने में अधिक समय नहीं लगता है। इसके अलावा, उन्हें ध्यान से निर्देशित करके, आप ठेठ "यह काम नहीं करता है" से बच सकते हैं!

— मथिउ एम।

5

हमने काम पर इस पैटर्न को लागू किया। सभी बग रिपोर्ट के 75% में "मैं अपेक्षा करता हूं कि यह" अपेक्षित "क्षेत्र में" काम करने के लिए "और" वास्तविक "क्षेत्र में" यह काम नहीं किया "। आह।

— चार्ल्स

1

@Charles: फिर "हल: कोई क्रिया नहीं" की टिप्पणी के साथ रिपोर्ट को बंद करें।

— डोनल फेलो

@ डॉनल फेलो - मैं इसे "डुप्लिकेट" के रूप में अस्वीकार कर दूंगा।

— मौविसील

7

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

मुझे अभी भी अवसर पर अधिक जानकारी के लिए उन्हें कॉल करना है, लेकिन अक्सर मैं स्क्रीनशॉट को देखकर समस्या को देख सकता हूं

लेकिन मैं @ महमूद की टिप्पणी से सहमत हूं कि उपयोगकर्ताओं पर भरोसा करने के बजाय आपको त्रुटियों को भेजने के लिए आवेदन प्राप्त करने का सबसे अच्छा तरीका है।

— राहेल
स्रोत

1

आपके पास कभी ऐसा मामला नहीं है जहां आपको संवाद बॉक्स का स्क्रीनशॉट मिलता है या ऐसा कुछ छोटा होता है जो उपयोगकर्ता सोचता है कि प्रासंगिक है लेकिन वास्तव में ऐसा नहीं है? मैं यह सब समय मिलता है ...

— sevenseacat

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

— राहेल

5

निराशावादी लेना: आप नहीं कर सकते। यह 40 साल पहले की तरह ही स्थिति है, इसके अलावा अधिक उपयोगकर्ता, अधिक सिस्टम, अधिक एप्लिकेशन हैं।

(ध्यान दें कि एक निराशावादी अनुभव के साथ एक आशावादी है।)

— इंगो
स्रोत

5

उन्हें करना आसान है या वे ऐसा नहीं करेंगे।

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

एक विस्तृत लॉग फ़ाइल रखना, और इसे त्रुटि रिपोर्ट संलग्न करना एक शुरुआत है।

— Alb
स्रोत

3

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

यदि उनमें से अधिकांश एक बार कॉल करने वाले हैं, तो "एरोर" को अपडेट करना सबसे अच्छा हो सकता है! पाठ के साथ स्क्रीन जो कहती है "आपको हमारे प्रतिनिधियों से बात करने से पहले डेटा आइटम ए, बी, सी, ... इकट्ठा करना चाहिए"। यह वास्तव में इस बात पर निर्भर करेगा कि आपके पास ऐप पर कितना नियंत्रण है, इसलिए यह संभव नहीं है। यह निश्चित रूप से आग का रास्ता नहीं है, लेकिन उम्मीद है कि यह ग्राहक के सिर में विचार आएगा जो चिल्लाएगा "ERRORZ PLZ HLP !!!" काफी नहीं है।

— FrustratedWithFormsDesigner
स्रोत

2

आधुनिक अनुप्रयोगों में त्रुटि संदेशों के साथ समस्या यह है कि सभी संदर्भों को शामिल करना लगभग असंभव है जो प्रासंगिक हो सकता है। प्रोसेसर आर्किटेक्चर से दिन के समय तक कुछ भी प्रासंगिक हो सकता है, यही वजह है कि त्रुटि रिपोर्टिंग और त्रुटि हैंडलिंग दोनों विज्ञान की तुलना में अधिक कला हैं। सिस्टम की तरह apport-bugउपयोगी है कि वे प्रासंगिक जानकारी एकत्र करते हैं और आपको इसे प्रस्तुत करते हैं। दुर्भाग्य से, जब तक मामला प्रतिकृति, समय यात्रा और हाइजेनबर्ग कम्पेसाटर के दिनों तक, यह सुनिश्चित करने का कोई तरीका नहीं है कि उपयोगकर्ताओं से प्राप्त जानकारी आपको डिबग करने या समस्या को पुन: उत्पन्न करने के लिए पर्याप्त होगी।

— l0b0
स्रोत

2

अपनी जरूरत की हर चीज को लॉग इन करें । हमारे पास x mb की रोलिंग लॉग फ़ाइल है। यदि कुछ बुरा होता है, तो उपयोगकर्ता लॉगफ़ाइल भेजता है और अक्सर यह समस्या को ठीक करने के लिए पर्याप्त होता है।

एक अन्य विकल्प यह है कि अपने आप को देखने के लिए एक दूरस्थ डेस्कटॉप क्लाइंट का उपयोग करें जो गलत है। इन दिनों कि ग्राहक के रूप में एक निर्वासित देना आसान है।

— Carra
स्रोत

1

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

— ब्रायन
स्रोत

1

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

-एक उपयोगकर्ता से कम से कम पूछने की कोशिश करें कि क्या आपका ऐप खुद डेटा प्राप्त कर सकता है। स्क्रीन रिज़ॉल्यूशन, ओएस संस्करण, उपयोगकर्ता नाम, लॉगिन, अंतिम क्रियाएं और लॉग

-एक उपयोगकर्ता को टिकट दें और उसे एक लिंक प्रदान करें, ताकि वह जान सके कि उसके पास www.yoursite.issues / 1234 पर बग नंबर 1234 है

-एक उपयोगकर्ता को जो उसने हासिल करने की कोशिश की थी।

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

— ZeusTheTrueGod
स्रोत

-2

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

— Bogo
स्रोत

1

यह लिंक-ओनली उत्तर की तुलना में थोड़ा अधिक है। यदि आपका उपकरण ओपी के प्रश्न का उत्तर देता है, तो आपका उत्तर अधिक मजबूत और अधिक मूल्यवान होगा।