अपना टेक सपोर्ट दिया

क्या आपको वर्तमान कार्यों को करते समय वर्क चैट में तत्काल मुद्दों को हल करने से विचलित होना पसंद है? हमें नहीं लगता!

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

अब कल्पना कीजिए कि आपके अलावा, इस चैट रूम में संपूर्ण विकास विभाग है, जिसमें 80+ लोग शामिल हैं, और प्रत्येक प्रतिभागी इन चर्चाओं में शामिल है।

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



पहले, उपयोगकर्ताओं से बग के साथ काम करने की प्रक्रिया इस प्रकार थी:

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

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

कई समस्याएं बग नहीं थीं और आमतौर पर डेवलपर्स तक नहीं पहुंचनी चाहिए। लेकिन एक ही समय में, डेवलपर्स पहले से ही चर्चा प्रक्रिया में शामिल थे, अपने कार्यों से विचलित।

हमने तय किया कि हमें इस प्रक्रिया को बदलने और तकनीकी सहायता को और अधिक स्वतंत्र बनाने की आवश्यकता है।

पहली चीज जिसे हम बदलना चाहते थे, वह था परीक्षक द्वारा बग की दोहरी जाँच से छुटकारा पाना।

इसका समाधान यह था: हमने वर्कफ़्लो का वर्णन किया जो परीक्षक काम करते हैं, इसे थोड़ा बदल दिया और इसे तकनीकी सहायता विशेषज्ञों को सौंप दिया। उपयोगकर्ता की समस्या के साथ काम करने पर अब उन्हें इससे गुजरना पड़ा।


संक्षेप में इस वर्कफ़्लो का वर्णन करें, अब तकनीकी सहायता विशेषज्ञ बग को लॉन्च करने से पहले स्वतंत्र रूप से आवश्यकताओं की जांच करता है, आवश्यक रूप से त्रुटि को पुन: पेश करता है और कार्य को विकास परियोजना में डालता है।

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

यदि दोहराई गई शिकायत को भी पुन: प्रस्तुत नहीं किया जाता है, तो कार्य अभी भी विकास परियोजना को अनिवार्य टिप्पणी के साथ स्थानांतरित किया जाता है कि समस्या पुन: पेश नहीं की जा सकी। शायद इस स्थिति में, डेवलपर्स, अपने हिस्से के लिए, समस्या का पता लगाने और हल करने में सक्षम होंगे।

इसलिए हम सिंगल कॉल पर ज्यादा समय नहीं देते हैं और केवल बार-बार कॉल के मामले में हम डेवलपर्स को कनेक्ट करते हैं।

पेशेवरों: हम परीक्षण विशेषज्ञ के समय को बचाते हैं, और अक्सर डेवलपर्स को भी जो चैट में प्रश्न देखते हैं और स्पष्टीकरण से जुड़े हैं।

हमारी दूसरी समस्या बग्स का डिज़ाइन था, जो कि था
एकात्मक नाम, अराजक और कभी-कभी सिर्फ एक रहस्यमय विवरण।
उदाहरण के लिए:


समाधान: उदाहरणों के माध्यम से, हमने बताया और दिखाया कि कैसे हम “क्या” के सिद्धांत का उपयोग करते हुए बग के लिए नाम लिखते हैं? कहाँ? कब? ”

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

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


सभी जानकारी कॉनफ्लुएंस के निर्देशों में दर्ज की गई है, जिसे हमेशा एक्सेस किया जा सकता है।

पेशेवरों: जीरा में बग की खोज करना आसान हो गया, और नाम से आप तुरंत निर्धारित कर सकते हैं कि सार कार्य में जाने के बिना क्या है। विवरण डेवलपर्स के लिए संरचित और अधिक समझने योग्य बन गया है।

सभी का तीसरा विकर्षण तकनीकी सहायता के साथ कई चैट रूम की उपस्थिति है ।

समाधान: "अधिक चैटरूम!"


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

पेशेवरों: अब एक प्रवेश बिंदु है जहां आप पाई गई समस्या की रिपोर्ट कर सकते हैं।

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

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

सभी नवाचारों के बाद, हमारा वर्कफ़्लो इस तरह दिखता है:

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

और आपकी कंपनी में व्यवस्थित उपयोगकर्ताओं से बग के साथ काम करने की प्रक्रिया कैसी है? अपने उदाहरण साझा करें :)