असंगत मिलाएं: उत्पाद विकास और समर्थन टीम सभी एक में लुढ़क गई

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

आज मैं आपको इस बारे में बताना चाहता हूं कि हम Odobrim.ru पर असंगत, या बल्कि, कैसे विकास टीम उत्पादों का समर्थन कर सकते हैं गठबंधन करने में कामयाब रहे। यह एक ही समय में 2-3 समर्थन लाइन होना है।

Odobrim.ru क्रेडिट कार्ड, ऋण और व्यक्तियों के लिए ऋण, बैंकों से स्वतंत्र का चयन करने के लिए एक मुफ्त ऑनलाइन सेवा है।

हमारा कार्य : ग्राहक के कार्यों को हल करने वाले इष्टतम ऋण उत्पाद को प्राप्त करने और बनाए रखने में ग्राहक की मदद करना।

कॉल संभालने की प्रक्रिया निम्नानुसार संरचित है



1. "ग्राहक सेवा" हमारे ग्राहकों की देखभाल करता है - समर्थन की पहली पंक्ति। हाँ, हाँ, अच्छी जगहों पर यह मौजूद है :))

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

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

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



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

4. अगले चरण में, डेवलपर्स (ब्लॉकर, क्रिटिकल) द्वारा निश्चित बग तय किया जाता है। फिर सुधार और सत्यापन की पुष्टि ड्यूटी इंजीनियर द्वारा की जाती है

5. कहानी (कार्य) को प्राथमिकता के लिए पीओ (उत्पाद स्वामी) को हस्तांतरित किया जाता है।

2 वर्षों के लिए, विकास टीम ने हमारी व्यावसायिक इकाई और उपयोगकर्ताओं में से 270 से अधिक कॉलों को संसाधित किया है, जिसमें से समर्थन की पहली पंक्ति संभाल नहीं पाई।

इस दृष्टिकोण के पेशेवरों

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

इस दृष्टिकोण के विपक्ष

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

यदि आपको समान समर्थन संगठन योजनाओं का सामना करना पड़ा है, तो टिप्पणियों में अपना अनुभव साझा करें।