سير عمل خالٍ من الألم للإبلاغ عن المشكلات وحلها

(هذا منشور برعاية.) لا بد أن تظهر الأخطاء والأخطاء والمشكلات الأخرى في تطوير الويب. حتى لو لم تكن أخطاء صريحة ، فغالبًا ما يكون لدى العملاء ملاحظات حول كيفية تصميم شيء ما ، ومكان وضعه أو كيفية عمل عناصر معينة. إنه مجرد جزء من الحفلة.

يمكن أن يكون جزءًا مؤلمًا جدًا من الحفلة أيضًا.

خذ هذا السيناريو ، على سبيل المثال:

البريد الإلكتروني رقم 1 من العميل: "لا يمكنني رؤية الزر بعد الآن. هل يمكنك إعادته إلى الصفحة الرئيسية من فضلك؟ "

البريد الإلكتروني رقم 2 منك: "إلى أي زر تشير؟ هل يمكنك أن ترسل لي لقطة شاشة؟ "

تحاول الاتصال بالعميل ، ولكن تحصل على بريده الصوتي بدلاً من ذلك.

البريد الإلكتروني رقم 3 من العميل: "الزر لحجز عرض توضيحي."

تنظر إلى لقطة الشاشة المرفقة وترى أن قسم Book a Demo سليم ، لكن الزر لا يظهر. يمكنك سحب موقع الويب على Chrome و Safari ورؤيته في كلا المستعرضين: زر أزرق كبير يقول "جدولة العرض التوضيحي". تسحبه على جهاز iPhone الخاص بك وتراه هناك أيضًا.

الرسالة الإلكترونية رقم 4 منك: "هل يمكنك إخباري بالجهاز والمتصفح الذي تظهر عليه المشكلة؟"

البريد الإلكتروني رقم 5 من العميل: "هاتفي".

أنت تعرف كيف ستسير هذه السلسلة من الرسائل وستؤدي فقط إلى الإحباط من كلا الطرفين. ناهيك عن تكلفة عملك في كل مرة تضطر فيها إلى التوقف مؤقتًا عن العمل لمحاولة تفسير تقرير خطأ ثم العمل من خلاله.

بعد ذلك ، هناك تكلفة الأخطاء التي يتكبدها عملاؤك والتي يتعين عليك التفكير فيها. عندما يحدث خطأ ما بعد الإطلاق ويحاول عميلك بنشاط إرسال حركة المرور إلى موقع الويب ، فقد يؤدي الخطأ إلى الإضرار بمبيعاته.

عندما يحدث ذلك ، من تعتقد أنهم سيأتون بعد؟

سير عمل خالٍ من الألم للإبلاغ عن المشكلات والإصلاحات

لا يهم حجم الخطأ أو المشكلة. عندما يتم الكشف عنها والإبلاغ عنها ، يجب التعامل معها. هناك عدد من الأسباب لماذا.

بالنسبة للمبتدئين ، إنها الطريقة الوحيدة التي ستجعل عميلك يسجل الخروج من المشروع على أنه مكتمل. بالإضافة إلى ذلك ، يؤدي الحل السريع والفوري للأخطاء إلى علاقات أفضل مع عميلك الذي يرى مدى استثمارك في إنشاء موقع ويب مثير للإعجاب (وخالٍ من الأخطاء) لأعماله. وبالطبع ، كلما تمكنت من حل الأخطاء بشكل أكثر كفاءة ، زادت سرعة عودتك إلى إنهاء هذه المهمة والانتقال إلى الآخرين!

لذا ، إليك ما عليك القيام به لمعالجة هذه المشكلات بشكل أكثر فاعلية وبدون ألم.

1. تعيين شخص ما لفرز
2. استخدم سير عمل حل المشكلات
3. امنح المستخدمين أداة الإبلاغ عن الأخطاء
4. امنح مدير الفرز الخاص بك منصة تتبع
5. العمل في منصة اختبار محلية
6. أغلق الحلقة دائمًا

1. تعيين شخص ما لفرز

أول شيء يجب فعله هو تحديد من سيقوم بفرز المشكلات.

إذا كنت تعمل بمفردك ، فإن هذه المسؤولية تقع على عاتقك. إذا كنت تعمل ضمن فريق ، فيجب أن ينتقل إلى مدير المشروع أو مدير التطوير الذي يمكنه إدارة المشكلات التي تم الإبلاغ عنها بنفس فعالية إدارة عبء عمل الفريق.

سيكون هذا الشخص بعد ذلك مسؤولاً عن:

• مراقبة المشكلات المبلغ عنها.
• إضافة البق إلى قائمة الانتظار.
• إرشادهم من خلال سير عمل القرار.
• حل وإغلاق تقارير الأخطاء.
• تحليل الاتجاهات ومراجعة العمليات لتقليل احتمالية ظهور الأخطاء المتكررة مرة أخرى.

بمجرد أن تعرف من سيدير ​​العملية ، فقد حان الوقت لتصميم سير عملك وبناء سلسلة من الأدوات حوله.

2. استخدم سير عمل حل المشكلات

لا يمكن لمدير الفرز القيام بذلك بمفرده. سيحتاجون إلى عملية يمكنهم متابعتها عن كثب لنقل كل مشكلة من النقطة أ (الكشف) إلى النقطة ب (الدقة).

للتأكد من أنك غطيت كل خطوة ، استخدم أداة تصور مثل Lucidchart لتخطيط خطوات أو مراحل سير عملك.

فيما يلي مثال على الشكل الذي قد يبدو عليه مخطط التدفق الخاص بك:

دعنا نقسمها:

ستبدأ بتحديد مكان اكتشاف المشكلة والقناة التي تم الإبلاغ عنها من خلالها. هذا المثال ليس محددًا للغاية ، ولكن لنفترض أن المشكلة الجديدة التي تم اكتشافها هي المشكلة المذكورة من قبل: زر حجز عرض توضيحي مفقود في الصفحة الرئيسية.

الشيء التالي الذي يجب فعله هو الإجابة على السؤال: "من وجدها؟" في معظم الحالات ، ستكون هذه تعليقات يرسلها عميلك من برنامج تتبع الأخطاء (المزيد عن ذلك قريبًا).

بعد ذلك ، ستنتقل إلى المراحل المختلفة التي ستمر بها مشكلاتك:

هذا هو الجزء من العملية حيث سيحدد مدير الفرز مدى خطورة مشكلة زر "حجز عرض تجريبي" المفقود (وهو "خطير" لأنه سيكلف تحويلات العميل). سيقومون بعد ذلك بنقله إلى المطور للتحقق منه.

اعتمادًا على عدد المطورين أو الخبراء المتخصصين المتاحين لحل المشكلة ، قد ترغب أيضًا في تفكيك هذه المرحلة بناءً على نوع الخطأ (مثل الوظائف المعطلة مقابل تحديثات التصميم).

بغض النظر ، بمجرد التحقق من الخطأ ، وتحت أي سياق (مثل ما إذا كان متوفرًا فقط على iPhone 7 أو أقدم) ، يتم نقل التذكرة إلى "قيد التقدم".

أخيرًا ، يجب أن يوضح مخطط التدفق الخاص بك الخطوات اللاحقة للمشكلات التي يمكن حلها:

يمكنك تسمية هذه الخطوات كيفما تختار. في المثال أعلاه ، توضح كل خطوة على وجه التحديد ما يجب أن يحدث:

• مشكلة جديدة
• في تقدم
• اختبار
• يصلح
• يؤكد
• حل
• إغلاق حلقة.

لتبسيط الأمور ، يمكنك بدلاً من ذلك استخدام تدفق الدقة مثل هذا:

• مشكلة جديدة
• لكى يفعل
• عمل
• منجز
• أرشيف.

ومع ذلك اخترت إعداد سير عمل التصحيح الخاص بك ، فقط تأكد من اختبار تصحيح الخطأ والتحقق منه قبل إغلاق التذكرة.

3. امنح المستخدمين أداة للإبلاغ عن الأخطاء

عندما يتعلق الأمر باختيار أداة للإبلاغ عن الأخطاء لموقعك على الويب ، فأنت تريد أداة تسهل على فريقك وعملائك ترك تعليقاتهم بل ويسهل عليك معالجتها.

إحدى هذه الأدوات التي تعمل بشكل جيد تسمى BugHerd.

في الأساس ، يعد BugHerd طريقة بسيطة للأشخاص غير التقنيين لإبلاغك عن المشكلات بصريًا وسياقًا. نظرًا لعدم وجود حاجة لتدريب المستخدمين على كيفية الدخول إلى أداة الإبلاغ عن الأخطاء أو استخدامها ، فهذا شيء أقل عليك قضاء وقتك فيه في هذه العملية.

علاوة على ذلك ، يوفر لك BugHerd عناء الاضطرار إلى التعامل مع الترجمات المستمرة التي تحدث عندما يتم توصيل التعليقات شفهيًا وخارج السياق.

مع BugHerd ، على الرغم من ذلك ، يقوم المستخدمون بإسقاط تعليقاتهم على موقع الويب بنفس السهولة التي يتركون بها ملاحظة لاصقة على مكتبك. علاوة على ذلك ، يتم تثبيت التعليقات في المكان المحدد حيث يوجد الخطأ.

دعني أريك كيف تعمل:

عندما تضيف موقع الويب الخاص بالعميل لأول مرة إلى BugHerd (إنها الخطوة الأولى) ، سيُطلب منك تثبيت ملحق متصفح BugHerd. هذا ما يسمح لـ BugHerd بتثبيت شريط الملاحظات على موقع الويب.

تبدو هكذا:

يجعل شريط الملاحظات المثبت هذا من السهل للغاية على العملاء ترك تعليقات دون تغيير موقع الويب المباشر فعليًا.

هذا ما تبدو عليه النافذة المنبثقة لتتبع الأخطاء:

كما ترى ، شكل بسيط للغاية. وفي الحقيقة ، كل ما يحتاجه عملاؤك هو تحديد العنصر الذي يحتوي على الخطأ في الصفحة ، ثم إدخال التفاصيل. الباقي يمكن ملؤها من قبل مدير الفرز الخاص بك.

عند إضافة تعليقات جديدة ، يتم تثبيت التعليقات في الصفحة التي تركوها فيها. علي سبيل المثال:

ستلاحظ أيضًا في لقطة الشاشة أعلاه أن المهام التي تم تعيين مستوى خطورة لها تم تمييزها على هذا النحو. يتم سردها أيضًا من أعلى إلى أسفل لمعرفة مدى أهميتها.

من جانبك للأشياء ، لديك خيار فيما يتعلق بالمكان الذي ترى فيه ملاحظاتك. يمكنك فتح الموقع ومراجعة الملاحظات المثبتة في كل صفحة. أو يمكنك الدخول إلى تطبيق BugHerd ومراجعة التعليقات من لوحة Kanban الخاصة بك:

بشكل افتراضي ، تدخل جميع الأخطاء في Backlog للبدء. إن مهمة مدير الفرز الخاص بك هي ملء كل خطأ بالتفاصيل المفقودة ، وتعيينه إلى مطور ونقله عبر خطوات الحل.

ومع ذلك ، يتولى BugHerd الكثير من العمل الشاق المتمثل في التقاط تقارير الأخطاء نيابة عنك. على سبيل المثال ، عند النقر فوق أي من الأخطاء المبلغ عنها في لوحة كانبان ، سيظهر الشريط الجانبي "تفاصيل المهمة":

توفر هذه اللوحة تفاصيل إضافية حول المشكلة ، وتعرض لقطة شاشة توضح مكان وجودها على الموقع ، وتتيح لك أيضًا معرفة من ترك التعليق.

علاوة على ذلك ، يلتقط BugHerd "معلومات إضافية":

بهذه الطريقة ، لا داعي للقلق بشأن عدم قيام العميل بتزويدك بالسياق الكامل للمشكلة. تخبرك هذه التفاصيل بالجهاز والمتصفح الذي يستخدمونه ، وكم كانت الشاشة كبيرة ودقة اللون التي كانوا يشاهدونها من خلالها.

يمكنك أيضًا إلقاء نظرة على رمز عنصر عربات التي تجرها الدواب. إذا كان هناك شيء مكسور بالفعل أو تم ترميزه بشكل غير صحيح ، فقد تتمكن من اكتشافه من هنا.

الكل في الكل ، BugHerd هي أداة رائعة لتبسيط مقدار ما يجب على الجميع القيام به من جميع الجوانب والتأكد من معالجة كل طلب في الوقت المناسب.

4. امنح مدير الفرز الخاص بك منصة تتبع

إذا كنت تريد الحفاظ على سير العمل بسيطًا قدر الإمكان ، فيمكنك استخدام لوحة معلومات BugHerd لتتبع وإدارة طلباتك:

من المحتمل أن يرغب مدير الفرز وفريق التطوير في استخدام شيء ما لاستكمال قدرات الإبلاغ عن الأخطاء في BugHerd. لكن حظًا سعيدًا في مطالبة عميلك باستخدام نظام أساسي مثل Jira لمساعدتك في إدارة الأخطاء.

في هذه الحالة ، أوصي بإضافة أداة أخرى إلى سير العمل هذا.

لحسن الحظ ، يتكامل BugHerd بسلاسة مع برامج تتبع المشكلات ومكتب المساعدة مثل Jira و Zendesk و Basecamp ، لذلك لا داعي للقلق بشأن استخدام أدوات متعددة لإدارة أجزاء مختلفة من نفس العملية. بمجرد إجراء الاتصال بين النظامين الأساسيين لديك ، سيتم تلقائيًا نسخ أي مهمة تم إنشاؤها في BugHerd إلى مركز حل المشكلات لديك.

الآن ، إذا كانت هناك أداة يستخدمها فريقك بالفعل ، ولكن BugHerd لا يتكامل معها بشكل مباشر ، فلا بأس بذلك. يمكنك استخدام Zapier لمساعدتك على التواصل مع المزيد من المنصات.

على سبيل المثال ، هذا هو مدى سهولة إنشاء "zap" على الفور يقوم بنسخ مهام BugHerd الجديدة إلى بطاقات Trello. وكل هذا يحدث من داخل BugHerd!

بمجرد إجراء الاتصال ، يمكن لمدير الفرز بدء العمل من إدارة المهام أو منصة تتبع المشكلات التي يختارها. في هذه الحالة ، هذا ما يحدث عندما يربط Zapier BugHerd و Trello:

هذه مهمة جديدة أنشأتها للتو في BugHerd. في غضون ثوانٍ ، تم وضع البطاقة في مشروع Trello الدقيق والقائمة التي قمت بتكوين zap من أجلها:

هذا سيجعل مهمة مدير الفرز أسهل بكثير حيث لن تكون مقيدة بالمراحل المتاحة في BugHerd بينما لا يزال لديهم نفس المعلومات بسهولة في متناول أيديهم.

5. العمل في منصة اختبار محلية

عندما يتم الإبلاغ عن الأخطاء ، فأنت لا ترغب في اختبار وتنفيذ الإصلاحات المفترضة على موقع الويب المباشر. هذا محفوف بالمخاطر.

بدلاً من ذلك ، اعمل على حل المشكلات من منصة اختبار محلية. تحتوي هذه المقالة على بعض الاقتراحات الرائعة حول أدوات التطوير المحلية لـ WordPress التي يمكنك استخدامها لهذا الغرض.

تمكنك هذه الأدوات من:

• بسرعة قم بعمل نسخة من موقع الويب الخاص بك.
• أعد إنتاج الخطأ بنفس شروط الخادم.
• اختبر الإصلاحات الممكنة حتى تجد الحل المناسب.

عندها فقط يجب أن تعمل على تصحيح الخطأ على الموقع.

6. أغلق الحلقة دائمًا

أخيرًا ، الأمر متروك لمدير الفرز الخاص بك لإغلاق كل مشكلة رسميًا.

أولاً ، يجب عليهم إبلاغ العميل (أو الزائر) الذي أبلغ عن المشكلة في الأصل أنه تم حلها. سيعطي هذا النوع من الشفافية والمساءلة وكالتك مظهرًا أكثر مصقولًا بينما يساعدك على بناء الثقة مع العملاء الذين قد يشعرون بالقلق من اكتشاف الأخطاء في المقام الأول.

بمجرد إغلاق الأشياء من جانب العميل ، يمكن لمدير الفرز بعد ذلك أرشفة تقرير الخطأ.

لا ينبغي أن ينتهي هناك رغم ذلك.

مثل مديري المشاريع التقليديين ، يجب على مدير الفرز تتبع الاتجاهات بانتظام بالإضافة إلى الخطورة الإجمالية للأخطاء الموجودة على مواقع الويب الخاصة بهم. قد تكشف البيانات أن هناك مشكلة أعمق في اللعب. بهذه الطريقة ، يمكن لفريقك التركيز على حل المشكلة الأساسية والتوقف عن قضاء الكثير من الوقت في إصلاح نفس أنواع الأخطاء والمشكلات.

تغليف

فكر في جميع الطرق التي يمكن من خلالها الإبلاغ عن المشكلات والأخطاء: من خلال نموذج الاتصال أو البريد الإلكتروني أو الهاتف أو الدردشة أو الأسوأ من ذلك ، في منتدى عام مثل وسائل التواصل الاجتماعي.

الآن ، فكر في جميع الأشخاص المختلفين الذين قد يبلغونك بهذه المشكلات: فريقك ، أو العميل ، أو عميل عميلك ، أو الشخص الذي وجده عشوائيًا أثناء البحث في موقع الويب وما إلى ذلك.

يوجد عدد كبير جدًا من المتغيرات في هذه المعادلة ، مما يجعل من السهل إغفال المشكلات المفتوحة. والأسوأ من ذلك ، عندما تأتي التعليقات من خلال غامضة أو ذاتية أو غير قادرة على تفسيرها دون أي سياق ، يصبح من الصعب جدًا حل المشكلات تمامًا أو في الوقت المناسب.

مع وجود النظام الصحيح لإعداد التقارير وتتبع وتنظيم الملاحظات ، على الرغم من ذلك ، يمكنك تنظيم هذه الفوضى والقضاء على الأخطاء الموجودة على موقع الويب الخاص بك بشكل أكثر فعالية.