هل ترغب في صرف انتباهك عن طريق حل المشكلات الملحة في محادثات العمل أثناء أداء المهام الحالية؟ لا نعتقد ذلك!
تخيل موقفًا: فأنت تبدأ مهمة ، ولكن يصرف انتباهك إشعار في المحادثة ، حيث يُطلب منك على وجه السرعة المساعدة في طرح سؤال من المستخدم. والآن أنت تشارك بالفعل في مناقشة نشطة وتفهم ما إذا كان هذا خطأ أو ميزة.
تخيل الآن أنه بالإضافة إلى ذلك ، تضم غرفة الدردشة قسم التطوير بأكمله ، والذي يتكون من 80 شخصًا ، ويشارك كل من المشاركين في هذه المناقشات.
معنا في SuperJob ، يجري الدعم الفني في أي موقف غير مفهوم على الفور في سلاك ومن ثم صرف انتباه جميع المشاركين عن الأنشطة الحالية. لذلك ، حاولنا نحن ، قسم الاختبار ، تغيير عملية التعامل مع الأخطاء من المستخدمين.
في السابق ، كانت عملية التعامل مع الأخطاء من المستخدمين كما يلي:
- ردود الفعل الواردة من المستخدم وإرسالها إلى أخصائي الدعم الفني ؛
- اكتشف أحد أخصائي الدعم الفني التفاصيل ، لكنه لم يعيد إنتاج المشكلة ، ولكنه بدأ على الفور مهمة في جيرا في مشروع الدعم الفني ؛
- تم طرح المهمة في غرفة محادثة منفصلة في Slack (وكان هناك 6 غرف دردشة ، بالمناسبة: حول مشكلات المتقدمين وأرباب العمل ولكل منصة في التطبيقات) ؛
- في المحادثة ، قام المختبر بهذه المهمة وبدأ في فهم المشكلة وتحديد مكانها ومعرفة كيفية عملها ؛
- بالإضافة إلى الاختبار ، شارك المطورون أيضًا في الدردشة وشاركوا بنشاط في المناقشة ؛
- بعد كل التوضيحات ، قام المختبر بنقل المهمة إلى مشروع التطوير المطلوب وتغيير الاسم وتصحيح الوصف.
في النهاية ، اتضح أن الكثير من الوقت قد قضى في مناقشة مشكلة واحدة في وقت واحد من قِبل العديد من الخبراء. أيضًا ، لم يسمح لك وصف المهمة دائمًا بفهم جوهر المشكلة بسرعة ، لذا كان عليك فتح مراسلات الدعم الفني مع المستخدم ، ثم قضاء المزيد من الوقت في تحرير هذه المهمة.
العديد من المشاكل لم تكن أخطاء وعموما لا ينبغي أن تصل إلى المطورين. ولكن في الوقت نفسه ، كان المطورون مشاركين بالفعل في عملية المناقشة ، حيث صرفوا انتباههم عن مهامهم.
قررنا أننا بحاجة إلى تغيير هذه العملية وجعل الدعم الفني أكثر استقلالية.
أول شيء أردنا تغييره هو
التخلص من التدقيق المزدوج للخلل بواسطة المختبر.كان الحل هو: لقد وصفنا سير العمل الذي يعمل عليه المختبرون ، وقاموا بتحويله قليلاً ، وسلموه إلى متخصصي الدعم الفني. الآن عليهم أن يتصفحوها عند التعامل مع مشكلة من المستخدم.
صف بإيجاز سير العمل هذا ، الآن يقوم أخصائي الدعم الفني بالتحقق بشكل مستقل من المتطلبات قبل بدء تشغيل الخطأ ، ويعيد إنتاج الخطأ بالضرورة ويضع المهمة في مشروع التطوير.
إذا لم يتم إعادة إنتاج الموقف ، فستبدأ المهمة في مشروع الدعم الفني ويتم تعليقها حتى يتصل المستخدم التالي. إذا كانت هناك طلبات جديدة من المستخدمين ، فيتعين على المركز التقني إعادة المحاولة لإعادة إنتاج المشكلة ، وإذا كان يتكرر ، فقم بنقل المهمة إلى مشروع التطوير.
إذا لم يتم إعادة إنتاج الشكوى المتكررة ، فلا تزال المهمة تنقل إلى مشروع التطوير مع التعليق الإلزامي بأنه لا يمكن تكرار المشكلة. ربما في هذه الحالة ، سيكون بإمكان المطورين ، من جانبهم ، اكتشاف المشكلة وحلها.
لذلك نحن لا ننفق الكثير من الوقت على المكالمات الفردية وفقط في حالة المكالمات المتكررة نحن نربط المطورين.
الايجابيات: نحن نوفر وقت أخصائي الاختبار ، وغالبًا ما نطور أيضًا المطورين الذين رأوا السؤال في الدردشة ومتصلين بالتوضيحات.
مشكلتنا الثانية كانت
تصميم الأخطاء نفسها ، والتي كانت
اسم غير معلوماتي ، فوضوية ، وأحيانا مجرد وصف غامض.
على سبيل المثال:
الحل: من خلال الأمثلة ، قلنا وأظهرنا كيف نصنع اسمًا للخلل باستخدام مبدأ "ماذا؟ اين؟ متى؟ "
على سبيل المثال ، أصبح اسم المهمة "مشكلة من" وظائف على موقعك "بعد المعالجة أكثر شفافية:" وظائف في كتلة "وظائف على موقعك" لا يتم عرضها عند الانتقال إلى قسم البث "". أي نوع من "المتاعب" حدث ، أصبح واضحا للجميع فقط من الاسم.
اتفقنا على استخدام القوالب لوصفها. لقد أضفناهم إلى جيرا. عند إنشاء خطأ ، تحتاج إلى تحديد القالب المطلوب وفقًا للنظام الأساسي وتعبئته.
يتم تسجيل جميع المعلومات في الإرشادات الموجودة في Confluence ، والتي يمكن الوصول إليها دائمًا.
الايجابيات: أصبح من السهل البحث عن الأخطاء في جيرا ، وبالاسم يمكنك تحديد ما هو جوهرها على الفور دون الخوض في المهمة. أصبح الوصف منظمًا وأكثر قابلية للفهم للمطورين.
الهاء
الثالث للجميع هو
وجود العديد من غرف الدردشة مع الدعم الفني.
الحل: "المزيد من غرف الدردشة!"قررنا إجراء دردشة واحدة فقط #support ، وإغلاق الباقي. الآن يتم إقصاء جميع الموظفين الداخليين عن المشاكل التي تم العثور عليها فيها ، ولا يرد عليهم سوى فريق الدعم الفني. يقومون بإجراء عمليات إعادة الفحص وبدء المهام.
الايجابيات: الآن هناك نقطة دخول واحدة حيث يمكنك الإبلاغ عن مشكلة موجودة.
في السابق ، كان بإمكان المطورين رؤية نوع من الأخطاء ، لكن ببساطة لم يعرفوا مكان الإبلاغ عنها. أولاً ، كان عليك معرفة الدردشة التي تريد التخلص منها. إنه أمر صعب ... لذلك ، البعض ببساطة لم يكلف نفسه عناء ويترك كل شيء كما هو (حسناً ، أو أن الأشخاص الواعيين على وجه الخصوص ألقوا الاختبار).
ولكن ، بالطبع ، كانت هناك بعض الصعوبات في تنفيذ هذا النهج. على سبيل المثال ، لا يستطيع أخصائي الدعم الفني دائمًا ترجمة المشكلة بشكل صحيح ، وتحديد ما إذا كانت خلفية أم واجهة خلفية. ولهذا السبب ، هناك خطر من حدوث خطأ في المشروع الخطأ أو في الفريق الخطأ ، ثم مرة أخرى تضيع الوقت في نقل المهام من قسم إلى آخر.
لا تزال هناك أخطاء في أوصاف وأسماء الأخطاء. لذلك ، في حين أنه من الضروري النظر في المهام للقضاء على هذه العيوب ، إلا أن عددها ليس بالغ الأهمية.
بعد كل الابتكارات ، يبدو سير العمل لدينا كما يلي:
- لقد أصبح اختصاصيو الدعم الفني أكثر استقلالية ، ولا يحتاجون إلى الانتظار حتى يقوم القائمون على الاختبار بالتحقق من الخطأ ؛
- يبدأ خطأ من المستخدم في جيرا بشكل أسرع ويمكن أن يتم تطويره في وقت مبكر ؛
- المختبرين والمطورين لا يصرف انتباههم عن مهامهم ؛
- يمكن للمطورين الآن
ترتيب holivar للدردشة في غرف الدردشة حول مواضيع أكثر إثارة للاهتمام.
وكيف يتم ترتيب عملية التعامل مع الأخطاء من المستخدمين في شركتك؟ مشاركة الأمثلة الخاصة بك :)