لوحة التحكم الخاصة بك على الأرجح لا تمنحك التغذية الراجعة التي تحتاجها
لديك لوحة تحكم. تعرض معدلات الأخطاء، وأوقات الاستجابة، والطلبات الفاشلة. تتحدّث الرسوم البيانية في الوقت الفعلي. الألوان أخضر، أصفر، وأحمر. تشعر أن لديك رؤية واضحة.
لكن اسأل نفسك: من يقرأ تلك البيانات فعليًا؟ متى يقرؤونها؟ وماذا يفعلون بعد قراءتها؟
العديد من الفرق لديها لوحات تحكم تبدو مبهرجة ولكنها لا تؤدي إلى أي إجراء مفيد تقريبًا. المشكلة ليست في البيانات. المشكلة هي أن البيانات لا تصل إلى الشخص المناسب في الوقت المناسب وبالشكل المناسب. لوحة التحكم هي مجرد عرض. نظام التغذية الراجعة هو شيء يغير طريقة عمل الفريق.
يجب أن تصل التغذية الراجعة إلى الشخص القادر على التصرف
عندما ترتفع معدلات الأخطاء بعد النشر، من يكتشف ذلك أولاً؟ هل هو الفريق الذي قام بالنشر للتو، أم فريق آخر موجود في الخدمة؟
في العديد من المؤسسات، الفريق الذي ينشر ليس هو الفريق الذي يتلقى التنبيه. يذهب التنبيه إلى فريق عمليات منفصل أو مهندس متناوب ليس لديه أي فكرة عما تغير للتو. يقضي أول عشرين دقيقة في محاولة فهم ما حدث. يتفقد سجل Slack. ينظر إلى سجل النشر. يسأل الجميع. بحلول الوقت الذي يفهمون فيه الموقف، يكون الفريق الذي نشر قد غادر المنزل بالفعل.
هذه حلقة تغذية راجعة معطلة.
يجب أن يكون الفريق الذي قام بعملية النشر هو أول من يتلقى التغذية الراجعة حول هذا النشر. هم يعرفون ما الذي تغير. يعرفون لماذا تغير. يمكنهم اتخاذ قرار بالتراجع، أو الإصلاح للأمام، أو ترك الأمور كما هي. إرسال التغذية الراجعة لشخص آخر أولاً يضيف فقط تأخيرًا وارتباكًا.
ليست كل التغذية الراجعة تحتاج إلى تنبيه استدعاء
غالبًا ما ترتكب الفرق خطأ معاملة جميع التغذية الراجعة بنفس الطريقة. كل مقياس له حد. كل حد يؤدي إلى إشعار. كل إشعار يذهب إلى نفس القناة. النتيجة هي ضوضاء، وإرهاق، وفي النهاية يتجاهل الناس التنبيهات تمامًا.
تحتاج التغذية الراجعة إلى أن تتطابق مع السياق.
بعض التغذية الراجعة عاجلة. إذا قفزت الطلبات الفاشلة من 1% إلى 30% أثناء النشر، فهذا يحتاج إلى اهتمام فوري. يجب استدعاء شخص ما. يجب أن ينظر شخص ما إلى الشاشة الآن.
التغذية الراجعة الأخرى بطيئة وتراكمية. الزيادة التدريجية في معدل الخطأ على مدى أسبوعين ليست حالة طارئة. إنها إشارة إلى أن شيئًا ما يتدهور. إنها تنتمي إلى تقرير يومي أو مراجعة أسبوعية. لا تحتاج إلى إيقاظ أي شخص في الساعة 2 صباحًا.
عندما تعامل التغذية الراجعة البطيئة مثل التغذية الراجعة العاجلة، يتعلم فريقك أن معظم التنبيهات هي إنذارات كاذبة. يتوقفون عن الاستجابة. ثم عندما يحدث طارئ حقيقي، لا يلاحظه أحد.
حدد كيفية الاستجابة، وليس فقط ما يجب النظر إليه
النمط الشائع هو أن الفرق تبني لوحات التحكم ثم تتوقف. يفترضون أنه إذا كانت البيانات مرئية، فسيجد شخص ما يعرف ماذا يفعل. هذا الافتراض خاطئ دائمًا تقريبًا.
عندما تصل التغذية الراجعة، يحتاج الفريق إلى نمط استجابة واضح. الخطوة الأولى ليست إلقاء اللوم. الخطوة الأولى هي الفهم. هل حدثت هذه المشكلة من قبل؟ هل هناك تغيير حديث يمكن أن يفسرها؟ هل يمكننا التراجع، أم نحتاج إلى إصلاح أمامي؟
الفرق التي تتعامل مع التغذية الراجعة بشكل جيد لديها عادة بسيطة: يتحققون، يتصرفون، يسجلون. يتحققون مما تخبرهم به التغذية الراجعة. يتصرفون بناءً على ما يعرفونه. يسجلون ما تعلموه حتى في المرة القادمة التي يظهر فيها نفس النمط، يتعرفون عليه بشكل أسرع.
هذا يبدو بديهيًا، لكن معظم الفرق تتخطى خطوة التسجيل. يصلحون المشكلة ويمضون قدمًا. بعد ثلاثة أشهر، تحدث نفس المشكلة مرة أخرى، ولا أحد يتذكر كيف حلوها في المرة السابقة.
التغذية الراجعة الأكثر قيمة غالبًا ما تأتي من خارج نظامك
لوحات التحكم الخاصة بك تقيس ما قررت قياسه. إنها لا تقيس ما لم تفكر فيه.
أحيانًا يبلغ مستخدم أن ميزة ما تشعر بالبطء، على الرغم من أن جميع مقاييسك الفنية تظهر أرقامًا طبيعية. أحيانًا يتلقى فريق الدعم شكاوى لا تظهر في أي لوحة تحكم لأن المشكلة تحدث فقط على جهاز معين أو حالة شبكة معينة.
إذا كان نظام التغذية الراجعة الخاص بك يتضمن فقط البيانات الآلية، فستفوتك هذه الإشارات. المستخدم وفريق الدعم هما جزء من نظام التغذية الراجعة الخاص بك، سواء صممته بهذه الطريقة أم لا. السؤال هو ما إذا كنت تستمع إليهم.
اجعل من السهل على المستخدمين الإبلاغ عن المشكلات. اجعل من السهل على فريق الدعم تصعيد الأنماط. تعامل مع شكوى المستخدم بنفس جدية الارتفاع المفاجئ في معدل الخطأ. المستخدم يخبرك بشيء لا تستطيع مراقبتك رؤيته.
أنظمة التغذية الراجعة تحتاج إلى صيانة أيضًا
النسخة الأولى من نظام التغذية الراجعة الخاص بك لن تكون صحيحة. ستكون الحدود خاطئة. ستذهب التنبيهات إلى الأشخاص الخطأ. ستحتوي التقارير على ضوضاء كثيرة جدًا أو إشارة قليلة جدًا.
هذا طبيعي. الشيء المهم هو معاملة نظام التغذية الراجعة نفسه كشيء يحتاج إلى تغذية راجعة.
في كل مرة يستجيب فريقك لتنبيه، اسأل: هل وصل هذا التنبيه في الوقت المناسب؟ هل كان مفيدًا؟ هل ذهب إلى الشخص المناسب؟ إذا كانت الإجابة لا، قم بتغييره. اضبط الحد. غير المستلم. بسط التنسيق. أزل التنبيه بالكامل إذا لم يؤدِ أبدًا إلى إجراء.
نظام التغذية الراجعة الجيد لا يُصمم مرة واحدة ويُترك. إنه ينمو مع تعلم الفريق ما هو مهم وما هو غير مهم.
قائمة مرجعية عملية قصيرة
إذا كنت تريد التحقق مما إذا كان نظام التغذية الراجعة الخاص بك يعمل بالفعل، راجع هذه الأسئلة:
- من يتلقى التنبيه الأول بعد النشر؟ هل هو الفريق الذي نشر؟
- هل التنبيهات العاجلة منفصلة عن الإشارات البطيئة والتراكمية؟
- هل لدى الفريق نمط استجابة واضح عندما تصل التغذية الراجعة؟
- هل هناك طريقة للمستخدمين وفريق الدعم لتقديم تغذية راجعة إلى النظام؟
- هل تم تعديل نظام التغذية الراجعة في الشهر الماضي بناءً على ما تعلمه الفريق؟
إذا أجبت بـ "لا" على أي من هذه، فلديك نقطة بداية للتحسين.
الخلاصة الحقيقية
لوحة التحكم التي لا يتصرف أحد بناءً عليها ليست تغذية راجعة. إنها ديكور. التغذية الراجعة موجودة فقط عندما تصل إلى شخص يمكنه اتخاذ قرار، بشكل يمكنه استخدامه، في وقت لا يزال مهمًا. ابنِ نظام التغذية الراجعة الخاص بك حول هذا المبدأ، وستتوقف عمليات النشر لديك عن كونها مصدر قلق وستصبح مصدرًا للتعلم.