التواصل مع أصحاب المصلحة

التواصل مع أصحاب المصلحة (Stakeholder Communication) هو التدفق المخطط للمعلومات بين الاختبار وكل من له مصلحة في المنتج: المطورون، ومالك المنتج، ومدير الإصدار، وراعي المشروع (Sponsor)، وفرق الدعم والتشغيل، وأحياناً العميل أو مسؤول الامتثال. وهو يحدد أيّ الحقائق تصل إلى من، ومتى، وبأي صيغة، ليتخذ كل منهم قراره في الوقت المناسب.

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

لماذا يهم

كثير من أزمات الإصدار لا يسببها العيب بقدر ما تسببها المفاجأة: راعٍ يعلم يوم الإطلاق أن جزءاً من المنتج لم يُختبر قط، أو فريق دعم يسمع عن مشكلة معروفة من العملاء. والوقت يُسقط الخيارات أيضاً: فقبل الإصدار بأسبوعين يمكن تعديل النطاق أو الأشخاص، أما يوم الإصدار فلا يبقى إلا «الإطلاق مع الخطر» أو «تأجيل الموعد».

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

من يحتاج ماذا، ومتى

صاحب المصلحة (Stakeholder) هو كل من يؤثر في المنتج وفي القرارات التي يغذّيها الاختبار، أو يتأثر بها. ابنِ خريطة التواصل انطلاقاً من القرارات لا من الهيكل التنظيمي: دوّن لكل صاحب مصلحة القرار الذي يملكه، والمعلومات التي يحتاجها هذا القرار دون زيادة، والإيقاع المعتاد للتحديثات، والمحفّزات (triggers) التي لا تحتمل انتظار التحديث التالي.

وتبدأ بعض الفرق بوضع أصحاب المصلحة على مصفوفة القوة والاهتمام (Power/Interest Grid)، وهي أداة شائعة في إدارة المشاريع: القوة العالية (أي التأثير في القرار) مع الاهتمام العالي تعني إشراكاً عن قرب؛ والقوة العالية مع الاهتمام المنخفض تعني ملخصات قصيرة تُبقي أصحابها راضين؛ والقوة المنخفضة مع الاهتمام العالي، كمكتب الدعم، تعني إطلاعاً منتظماً؛ وانخفاضهما معاً يعني تحديثاً عاماً بين حين وآخر.

  • أدرج أيضاً من يسهل نسيانهم: الدعم والتشغيل والأمن، والتسويق حين يكون موعد الإطلاق معلناً، والعميل الخارجي.
  • استخرج المعلومات من القرار: فالراعي الذي يقرر الإطلاق يحتاج إلى الخطر المتبقي وتكلفة كل خيار، لا إلى أعداد حالات الاختبار.
  • اتفق مسبقاً على المحفّزات: عيب حاجب (Blocker) أو حرج (Critical) في ميزة لا غنى عنها، أو تعطّل البيئة نصف يوم، أو توقّع عدم استيفاء معايير الخروج.
  • اتفق على من يُبلغ من: المختبِر يُبلغ صاحب القرار، ومالك المنتج، لا المختبِر، هو من يُبلغ التسويق أو العميل بتغيّر الموعد.
ستة من أصحاب المصلحة في إصدار ما، مع القرار الذي يملكه كل منهم، وما يحتاجه من الاختبار، وإيقاعه المعتاد، والمحفّزات التي تعني إبلاغه فوراً بدل انتظار التحديث التالي. نموذج مفاهيمي
صاحب المصلحةالقرار الذي يملكهما يحتاجه من الاختبارالإيقاع المعتادأبلِغه فوراً حين
المطورون وقائد التطويرماذا يُصلَح أولاً، وكيفمعرّفات العيوب والخطوات والسجلات والاختبارات الفاشلة والمحجوبةباستمرار: أداة التتبع والمحادثة والاجتماع اليوميعيب حاجب، أو تعطّل بيئة الاختبار
مالك المنتجالأولوية والنطاق والموعد وأيّ المخاطر تُقبَلالتقدم حسب الميزة والخطر، والعيوب المفتوحة حسب الخطورة، والقرارات المطلوبةيومياً أو في كل سبرنتخطر على ميزة لا غنى عنها أو على النطاق أو الموعد
مدير الإصدار أو التسليمخطة الإصدار والأشخاص والتنسيق؛ وينظّم اجتماع المضي أو التوقفالتوقع مقارنةً بالخطة، والعوائق، ومخاطر المشروعأسبوعياً، وفي اجتماع المضي أو التوقفتوقّع عدم استيفاء معايير الخروج
راعي المشروع أو الإدارة العلياالإطلاق والميزانية ومخاطر العملالحالة بكلمات بسيطة، والخطر المتبقي، وتكلفة كل خيارعند كل مرحلة رئيسية، في صفحة واحدةخطر على الموعد أو الميزانية أو السمعة، عادةً عبر مالك المنتج
الدعم والتشغيلكيف يستعدون للإصدار وكم شخصاً يلزمهمالمشكلات المعروفة والحلول البديلة والسلوك المتغير وموعدا الإصدار والتراجعقبل كل إصدارستصدر مشكلة معروفة مع الإصدار، أو تغيّر موعده
العميل أو مسؤول الامتثالالقبول، أو الالتزام بالقواعدأدلة رسمية وتتبّععند المراحل المتفق عليهاكما يشترط العقد أو اللوائح
  • العمود المحدَّد: محفّزات لا تنتظر التحديث المعتاد

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

الأخبار السيئة مبكراً، ومعها الخيارات

اطرح المشكلة بمجرد تأكيدها وقدرتك على وصف أثرها، لا حين يُعرف الإصلاح. فعدم اليقين خبر أيضاً: عبارة «يصل التقدير الساعة 15:00» تتيح لصاحب القرار أن يخطط، أما الصمت فيجعله يفترض أن كل شيء على ما يرام. وتعمل فرق كثيرة بقاعدة «لا مفاجآت»: لا ينبغي لمسؤول عن قرار أن يسمع بالمشكلة أول مرة في اجتماع أو من عميل.

والحالة التي تبقى خضراء بينما العمل تحتها يتعثر، وتسميها بعض الفرق «حالة البطيخة» (Watermelon Status) لأنها خضراء من الخارج حمراء من الداخل، تنشأ عادةً من تأخيرات صغيرة بدا كل منها أصغر من أن يُبلَّغ عنه. والمحفّزات المتفق عليها مسبقاً تجعل التحول إلى اللون الكهرماني (Amber)، لون التحذير بين الأخضر والأحمر، قاعدةً لا اجتهاداً.

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

  • العنوان الرئيسي: ما المعرَّض للخطر وما القرار المطلوب، في جملة واحدة.
  • الحقائق: ما لاحظته، والدليل، ومدى يقينك.
  • الأثر بلغة القارئ: المستخدمون أو المال أو الموعد أو السمعة.
  • الخيارات مع تكلفة كل منها وخطره، ومنها قبول الخطر، وتوصيتك موسومةً بأنها رأيك.
  • من يجب أن يقرر، وآخر موعد للقرار، وموعد تحديثك التالي.

اختيار الصيغة

يذكر منهج ISTQB للمستوى التأسيسي الوسائل المعتادة: الحديث مع الفريق وأصحاب المصلحة الآخرين، ولوحات المتابعة (Dashboards)، والبريد الإلكتروني والمحادثة، والتوثيق المنشور على الإنترنت، والتقارير الرسمية للاختبار، مع تواصل أكثر رسمية للفرق التي تفصلها المسافات أو المناطق الزمنية. واختر بينها بأربعة أسئلة: ما مدى الاستعجال؟ وهل يحتاج الأمر إلى نقاش؟ وهل يجب توثيقه؟ وكم من الوقت لدى القارئ؟

  • تحدّث أولاً حين يكون الخبر عاجلاً أو سيئاً أو يسهل فهمه خطأً، ثم أكّده كتابةً خلال ساعة.
  • المحادثة للتنسيق السريع داخل الفريق، والقرارات المتخذة فيها تضيع مع تتابع الرسائل، فانقلها إلى السجل.
  • البريد الإلكتروني أو التحديث المكتوب للحالة الدورية ولكل ما يجب توثيقه: الحالة في سطر الموضوع، والخلاصة في السطر الأول (وتسمي بعض الفرق ذلك BLUF، أي الخلاصة أولاً). ويمكن إرسال ملخص من صفحة واحدة إلى العميل بصيغة PDF.
  • لوحات المتابعة للاتجاهات التي يطّلع عليها القرّاء بأنفسهم، ولا تغني أبداً عن إبلاغ شخص بأن مشكلة ما تمسّه.
  • الاجتماعات للقرارات التي تحتاج إلى عدة أشخاص: فرز العيوب، واجتماع المضي أو التوقف (Go/No-Go)، وفي Scrum مراجعة السبرنت (Sprint Review) مع أصحاب المصلحة الرئيسيين. أما Scrum اليومي (Daily Scrum) فحدث للمطورين، لا قناة لتصعيد الأمور إلى أصحاب المصلحة.
  • سجل القرارات للمخاطر المقبولة: ماذا، ومن، ومتى، ولماذا. ومع اختلاف المناطق الزمنية، اكتب كل موعد نهائي مع منطقته الزمنية.

جرّبها: منسّق Markdown جرّبها: عدّاد الكلمات جرّبها: محوّل المناطق الزمنية جرّبها: تحويل Markdown إلى PDF

مثال تطبيقي: عيب حرج قبل الإطلاق بيومين

يطلق تطبيق لتوصيل البقالة الإصدار 3.8 يوم الخميس الساعة 10:00 مع حملة تسويقية. ويوم الثلاثاء الساعة 11:20 يؤكد المختبِر العيب GR-214: عند إعادة محاولة الدفع بالبطاقة بعد انتهاء المهلة، تُخصم نقاط الولاء مرتين. وتستغرق إعادة الاختبار واختبار الانحدار بعد الإصلاح نحو يوم، فيجب أن يصل الإصلاح قبل الأربعاء الساعة 10:00.

في الساعة 11:30 يتصل المختبِر بالمطور ومالكة المنتج معاً، وفي الساعة 12:15 يرسل التصعيد أدناه إلى مالكة المنتج ومدير الإصدار. ولا ينشر في قناة الشركة ولا يراسل التسويق: فمالكة المنتج تملك الموعد، وهي من تُبلغ التسويق والدعم.

  • في الساعة 15:00 يصل التقدير: يومان. وفي الساعة 15:30 تختار مالكة المنتج الخيار ب، ويُبلغ مدير الإصدار راعيَ المشروع، ويتلقى الدعم ملاحظة بالمشكلة المعروفة.
  • يسجّل المختبِر القرار (استبدال النقاط موقوف في 3.8، والإصلاح في 3.8.1، مالكة المنتج، الثلاثاء 15:30)، ويضيف اختباراً يتحقق من أن علم الميزة (Feature Flag) يُخفي الاستبدال فعلاً.
  • وفي اجتماع المضي أو التوقف يوم الأربعاء لا جديد: فكل خطر وصل إلى صاحبه من قبل.
إلى: سارة (مالكة المنتج)، فيصل (مدير الإصدار)
نسخة: عمر (قائد التطوير)
الموضوع: معرَّض للخطر - الإصدار 3.8 (الخميس 10:00)، القرار مطلوب قبل الأربعاء 10:00

الإصدار 3.8 معرَّض للخطر: وُجد اليوم عيب حرج، ولا يوجد تقدير للإصلاح بعد.

الحقائق
- GR-214: عند إعادة محاولة الدفع بالبطاقة بعد انتهاء المهلة، تُخصم نقاط
  الولاء مرتين. تكرّر في 4 من 4 محاولات على البناء rc2.
- يتأثر كل عميل يدفع جزءاً من المبلغ بالنقاط وتنتهي مهلة محاولته الأولى للدفع.
- سيقدّم مطوّر الدفع تقديراً اليوم الساعة 15:00.

الأثر
- يخسر العملاء نقاطاً أثناء الحملة؛ نتوقع تذاكر دعم.
- بعد الإصلاح: نحو يوم واحد لإعادة الاختبار واختبار انحدار الدفع.

الخيارات
أ. الإصلاح وإعادة الاختبار والإطلاق يوم الخميس كما هو مخطط، فقط إذا
   وصل الإصلاح قبل الأربعاء 10:00.
ب. الإطلاق يوم الخميس مع إيقاف استبدال النقاط بعلم ميزة (feature flag)،
   والإصلاح في 3.8.1. يحتاج الدعم إلى ملاحظة بالمشكلة المعروفة.
ج. نقل الإصدار والحملة إلى يوم الأحد.

توصيتي: نقرر بعد تقدير الساعة 15:00، ونختار ب إذا تعذّر وصول الإصلاح
قبل الأربعاء 10:00.

التحديث التالي: اليوم 15:30، بعد وصول التقدير.

جرّبها: حاسبة التواريخ

أخطاء شائعة

  • انتظار الإصلاح أو اليقين قبل طرح المشكلة، فيخسر صاحب القرار الأيام التي كان يحتاجها.
  • التصعيد دون خيارات: عبارة «لدينا مشكلة» تُلقي تحليلك على عاتق القارئ.
  • تجاوز صاحب القرار، أو كشف عيب في عمل مطوّر أول مرة في اجتماع الحالة.
  • إرسال الرسالة نفسها إلى الجميع: أعداد الاختبارات للراعي، وسطر مختصر للمطور الذي يحتاج إلى السجلات.
  • ترك القرارات في مكالمة أو محادثة دون سجل لمن قبِل أيّ خطر.
  • إبقاء الحالة خضراء حتى اليوم الأخير لأن كل تأخير بدا صغيراً.

من منظور ضمان الجودة

اكتب خريطة التواصل في بداية الإصدار، في خطة الاختبار أو في صفحة ويكي قصيرة، وراجعها مع مالك المنتج ومدير الإصدار. فتلك اللحظة الهادئة هي وقت الاتفاق على المحفّزات والقنوات ومن يُبلغ من.

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

تمرين عملي

خطّط للتواصل بشأن مشكلة وُجدت قبل إصدار يلي عطلة نهاية الأسبوع

المطلوب

أنت المختبِر الوحيد في بوابة لسداد الرسوم الدراسية لمجموعة مدارس خاصة. يُطلق الإصدار 2.0 يوم الأحد الساعة 08:00، حين يتلقى أولياء الأمور رسالة SMS بالرابط. الآن الخميس الساعة 13:00، وهو آخر يوم عمل قبل الإطلاق.

خطّط لمن يسمع ماذا، وكيف، وقبل متى، واكتب التصعيد الخاص بالعيب FEE-31 في ما لا يزيد على 150 كلمة.

المادة
البوابة: رسوم المدارس 2.0 · الإطلاق الأحد 08:00 · رسالة SMS لكل أولياء الأمور 08:00
الآن: الخميس 13:00 (الجمعة والسبت ليسا يومَي عمل)

أصحاب المصلحة
  خالد    قائد فريق التطوير
  هدى     مالكة المنتج
  منى     المديرة المالية لمجموعة المدارس (العميل؛ توافق على الإطلاق)
  الدعم   موظفان، يبدآن الأحد 07:30
  طارق    رئيس تقنية المعلومات في المجموعة (يدير الخوادم وحساب SMS)

النتائج
  FEE-31   حرج: بعد القسط الثاني من ثلاثة، ما زالت الشاشة وإيصال PDF
           يعرضان المبلغ كاملاً مستحقاً. البيانات في قاعدة البيانات صحيحة.
           تكرّر في 3 من 3 محاولات على المرشّح للإصدار.
  BLK-4    اختبار رابط SMS محجوب: حساب SMS التجريبي غير مُعدّ.
           تُرسَل الرسالة الحقيقية إلى كل أولياء الأمور الأحد 08:00.
الخطوات
  1. ارسم خريطة لأصحاب المصلحة الخمسة: القرار، والاحتياجات، والإيقاع، والمحفّزات.
  2. قرّر من يسمع بكل نتيجة أولاً، وبأي صيغة، وقبل أي ساعة.
  3. اكتب التصعيد الخاص بالعيب FEE-31.
  4. اذكر ما تسجّله، وأين.
إظهار الإجابة النموذجية
الإجابة النموذجية

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

الترتيب: قبل الساعة 13:30 اتصل بخالد وهدى معاً، فلن يبقى بعد اليوم يوم عمل قبل الإطلاق، وقد يُقرأ البريد الإلكتروني وحده بعد فوات الأوان. وفي المكالمة نفسها أخبر هدى أن BLK-4 خطر مفتوح، لأن الرابط غير المختبَر سيصل إلى كل أولياء الأمور. وفي الساعة 14:00 أرسل التصعيد إلى هدى مع نسخة إلى خالد، وتُبلغ هدى منى. واتصل بطارق الآن بشأن BLK-4، فهو وحده من يستطيع إعداد الحساب التجريبي. ولا تتواصل بنفسك مع منى أو أولياء الأمور.

التصعيد: «معرَّض للخطر: بوابة الرسوم 2.0 (الأحد 08:00)، القرار مطلوب اليوم قبل 16:00. FEE-31 (حرج): بعد القسط الثاني من ثلاثة، تعرض الشاشة وإيصال PDF المبلغ كاملاً مستحقاً، والبيانات في قاعدة البيانات صحيحة (3 من 3 على المرشح للإصدار). الأثر: قد يدفع أولياء الأمور أقساطاً سبق أن دفعوها، وستضطر المالية إلى ردّ المبالغ. الخيارات: أ) الإصلاح اليوم وأعيد الاختبار هذا المساء (نحو 3 ساعات)، فقط إذا وصل الإصلاح قبل 18:00؛ ب) الإطلاق مع إخفاء الأقساط، والإصلاح في 2.0.1؛ ج) تأجيل الإطلاق ورسالة SMS أسبوعاً. التوصية: الخيار أ إذا أكّد خالد قبل 15:00 أن الإصلاح سيصل قبل 18:00، وإلا فالخيار ب. التحديث التالي: 15:30.»

السجل: القرار، ومن اتخذه ومتى، في سجل القرارات؛ وBLK-4 خطراً مفتوحاً يملكه طارق. واتفق مع هدى على من يُبلغ الدعم اليوم: ملاحظة بالمشكلة المعروفة إذا اختير ب، أو الموعد الجديد إذا اختير ج، لأن الدعم يبدأ الأحد الساعة 07:30 والجمعة والسبت ليسا يومَي عمل. والإجراء البديل بشأن BLK-4، بالاتفاق مع طارق: إرسال الرسالة الحقيقية إلى هواتف عدد من الموظفين يوم الأحد الساعة 07:30، والتحقق من الرابط قبل وصولها إلى أولياء الأمور.

أسئلة شائعة

هل التواصل مع أصحاب المصلحة هو نفسه تقارير الاختبار؟

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

هل يصعّد المختبِر مباشرةً إلى الإدارة العليا؟

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

متى يكون طرح المشكلة مبكراً أكثر من اللازم؟

اطرحها حين تتأكد منها وتستطيع وصف أثرها، حتى لو لم تعرف السبب أو الإصلاح. وقبل ذلك تفيد ملاحظة قصيرة لصاحب المجال («أتحقق من أمر قد يؤثر في الدفع، وسأوافيك بالمزيد قبل 15:00»)، لكنها ليست بعدُ خبراً لجمهور واسع.

المراجع

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
  • The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020تعريف Scrum: مسؤولياته وأحداثه ومخرجاته، بما فيها تعريف الإنجاز (Definition of Done) الذي يساعد الاختبار على تحقيقه.
  • Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024منهج ISTQB المتقدم لإدارة الاختبار: التخطيط والتقدير، والاختبار المبني على المخاطر، والمتابعة، والمقاييس والتقارير.

تدرّب بأدوات متقن

توحيد تنسيق Markdown (العناوين والقوائم والجداول والتأكيد) ومعاينة النتيجة المعروضة.

التنسيق

عدّ الكلمات والجمل والفقرات ووقت القراءة وتكرار الكلمات المفتاحية.

التنسيق

حوّل التاريخ والوقت بين المناطق الزمنية (الرياض، عمّان، دلهي، UTC، نيويورك، لندن…).

أدوات مساعدة

أضف أو اطرح أياماً أو أسابيع أو أشهراً أو سنوات أو ساعات أو دقائق من تاريخ.

أدوات مساعدة

حوّل ملفات Markdown (md.) إلى PDF في متصفحك: العناوين والقوائم والجداول وكتل الشيفرة والاقتباسات والروابط والصور منسّقة بخطوط مضمّنة.

تحويل PDF

للتعمّق أكثر

تقدّمك في هذا الموضوع

جزء من مسار تعلم ضمان الجودة