تحليل أصحاب المصلحة: كيف تحدد من يقرر فعلياً متطلبات النظام

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

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

صاحب المصلحة ليس بالضرورة من يدفع الفاتورة

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

خريطة تصنيف بسيطة وفعالة

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

التناقضات بين أصحاب المصلحة أمر متوقع، لا استثناء

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

الخلاصة

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