تُعد إدارة متطلبات المشاريع التقنية من أهم المراحل التي تحدد نجاح التطبيقات والمنصات والأنظمة الرقمية. فقد تمتلك المؤسسة ميزانية مناسبة، وفريق تطوير محترفًا، وشركة تنفيذ تمتلك خبرة جيدة، ومع ذلك يتعثر المشروع بسبب عدم وضوح ما يحتاج إليه المستخدم فعليًا.
تبدأ مشروعات كثيرة بفكرة عامة، مثل إنشاء تطبيق لخدمة العملاء أو أتمتة إجراءات الموظفين. لكن الفريق قد ينتقل إلى التصميم والبرمجة قبل توثيق العمليات والمشكلات والنتائج المطلوبة. وعند عرض النسخة الأولى، يكتشف المستخدمون أن النظام لا يعالج احتياجاتهم، فتبدأ التعديلات وتتوسع التكلفة والمدة.
ويتوافق الموضوع مع مجال Control Path Project Services، التي تقدم حلولًا في تقنية المعلومات وإدارة المشروعات، مع التركيز على الجودة والابتكار والكفاءة ودعم الأهداف الرقمية للمؤسسات.
ما المقصود بمتطلبات المشروع التقني؟
متطلبات المشروع هي الخصائص والقدرات والشروط التي يجب أن يحققها النظام حتى يعالج المشكلة ويقدم القيمة المطلوبة.
توضح المتطلبات ما يجب أن يفعله النظام، ومن سيستخدمه، والبيانات التي سيعالجها، والأنظمة التي سيتكامل معها، ومستوى الأداء والحماية المطلوب.
ويشير معهد إدارة المشاريع إلى أن إدارة المتطلبات تشمل مجموعة من المهام والمعارف والمهارات التي تساعد الفرق على تطوير حلول تلبي التوقعات، وتحسن الأداء، وتحقق النتائج والفوائد المطلوبة.
ولا يجب التعامل مع المتطلبات باعتبارها قائمة خصائص فقط، بل باعتبارها حلقة وصل بين أهداف المؤسسة والتنفيذ الفني.
لماذا تفشل المشروعات بسبب المتطلبات؟
قد يطلب أحد الأقسام إنشاء نظام جديد دون شرح خطوات العمل الحالية أو المشكلات التي يواجهها الموظفون. وقد يفهم المطور المصطلحات بطريقة مختلفة عن المستخدم، أو تعتمد المؤسسة متطلبات عامة لا يمكن اختبارها.
ومن الأسباب الشائعة لتعثر المتطلبات:
عدم إشراك المستخدمين الحقيقيين.
تعدد الآراء دون وجود صاحب قرار.
بدء البرمجة قبل اكتمال التحليل.
تغيير المتطلبات باستمرار.
عدم تحديد الأولويات.
الخلط بين الاحتياج والحل المقترح.
غياب معايير القبول.
عدم توثيق القرارات والتعديلات.
وترتبط الإدارة الضعيفة للمتطلبات بمشكلات مثل توسع النطاق، وتأخر الجدول الزمني، وتجاوز التكلفة، وضعف التواصل بين الأطراف.
ابدأ بفهم المشكلة قبل اختيار الحل
يجب ألا تبدأ إدارة متطلبات المشاريع التقنية بسؤال المستخدم عن الخصائص التي يريدها فقط، بل بفهم المشكلة التي يحاول حلها.
قد يطلب الموظف إضافة زر جديد، بينما تكون المشكلة الحقيقية هي تكرار إدخال البيانات. وقد تطلب الإدارة تطبيقًا جديدًا، رغم أن تطوير النظام الحالي يمكن أن يحقق النتيجة بتكلفة أقل.
يحتاج الفريق إلى معرفة:
كيف تُنفذ العملية حاليًا؟
من يشارك فيها؟
أين يحدث التأخير؟
ما البيانات المطلوبة؟
ما الأخطاء المتكررة؟
ما النتيجة التي يجب تحسينها؟
يساعد هذا التحليل على فصل الاحتياجات الحقيقية عن الحلول المقترحة بصورة مبكرة.
تحديد أصحاب المصلحة
يشمل أصحاب المصلحة جميع الأشخاص والإدارات المتأثرة بالمشروع أو القادرة على التأثير فيه، مثل الإدارة العليا والمستخدمين وفريق التقنية والأمن السيبراني والبيانات والموردين.
لا يكفي الاستماع إلى مدير الإدارة فقط، لأنه قد يعرف النتائج المطلوبة لكنه لا ينفذ الخطوات اليومية. كما لا يكفي الاعتماد على الموظفين وحدهم، لأنهم قد لا يمتلكون رؤية الأهداف الاستراتيجية أو المتطلبات التنظيمية.
يجب تحديد دور كل طرف، ومن يقدّم المتطلبات، ومن يراجعها، ومن يمتلك صلاحية اعتمادها أو رفض التغييرات عليها.
طرق جمع المتطلبات
يمكن استخدام أكثر من طريقة لتنفيذ تحليل متطلبات النظام، بحسب حجم المشروع وطبيعة المستخدمين.
تشمل الطرق الشائعة:
المقابلات الفردية مع المستخدمين والمديرين.
ورش العمل التي تجمع الإدارات المتأثرة.
مراقبة الموظفين أثناء تنفيذ المهام.
مراجعة النماذج والتقارير والأنظمة الحالية.
الاستبيانات عند وجود عدد كبير من المستخدمين.
إنشاء نماذج أولية للشاشات.
دراسة رحلة المستخدم والخطوات التي يمر بها.
ويُفضل استخدام مزيج من الطرق، لأن المقابلة قد تكشف الاحتياجات المعلنة، بينما تكشف الملاحظة خطوات ومشكلات اعتاد عليها الموظفون ولم يعودوا يذكرونها.
الفرق بين المتطلبات الوظيفية وغير الوظيفية
توضح المتطلبات الوظيفية الوظائف التي يجب أن ينفذها النظام، مثل إنشاء حساب، أو تقديم طلب، أو إصدار تقرير، أو إرسال إشعار.
أما المتطلبات غير الوظيفية فتحدد مستوى جودة النظام وطريقة أدائه، مثل السرعة والحماية والتوافر وسهولة الاستخدام وقابلية التوسع.
قد يعمل النظام من الناحية الوظيفية، لكنه يظل غير مناسب إذا استغرق فتح الصفحة وقتًا طويلًا أو تعطل عند ارتفاع عدد المستخدمين.
وتوضح إرشادات هيئة الحكومة الرقمية أن المتطلبات التقنية تتضمن جوانب مثل الأمن، والموثوقية، والأداء، وقابلية التوسع، وسهولة الاستخدام، لأنها تؤثر في فعالية التقنية واعتمادها.
كتابة المتطلبات بصورة قابلة للاختبار
يجب أن يكون توثيق المتطلبات واضحًا ومحددًا، بحيث يستطيع الفريق اختبار ما إذا تم تنفيذ كل مطلب أم لا.
بدلًا من كتابة: “يجب أن يكون النظام سريعًا”، يمكن كتابة: “يجب أن تظهر الصفحة الرئيسية خلال ثانيتين عند وجود ألف مستخدم متزامن”.
وبدلًا من كتابة: “يجب حماية البيانات”، يتم تحديد نوع التشفير، وصلاحيات الوصول، وتسجيل العمليات، ومدة الاحتفاظ بالمعلومات.
ويُفضل أن يحتوي كل مطلب على:
رقم تعريفي.
وصف واضح.
صاحب المطلب.
درجة الأولوية.
سبب الحاجة إليه.
معيار القبول.
الأنظمة أو المتطلبات المرتبطة به.
استخدام قصص المستخدم وحالات الاستخدام
تساعد قصص المستخدم على وصف الاحتياج من وجهة نظر الشخص الذي سيستخدم النظام.
يمكن كتابة القصة بالصورة التالية: “بصفتي موظف خدمة عملاء، أريد البحث برقم الطلب حتى أستطيع الرد على العميل بسرعة”.
ثم تُضاف معايير القبول التي تحدد شروط نجاح الوظيفة، مثل ظهور بيانات الطلب الصحيحة، وعدم إظهار المعلومات لمستخدم غير مصرح له.
أما حالات الاستخدام فتشرح خطوات التفاعل بين المستخدم والنظام بصورة أكثر تفصيلًا، بما يشمل المسار الأساسي والحالات البديلة والأخطاء المتوقعة.
ترتيب المتطلبات حسب الأولوية
لا يمكن دائمًا تنفيذ جميع المتطلبات في الإصدار الأول. ولذلك يجب تصنيفها إلى متطلبات أساسية، ومهمة، وتحسينية، ويمكن تأجيلها.
يساعد تحديد الأولويات على إطلاق نسخة أولية تحقق القيمة الرئيسية، ثم إضافة الخصائص الأقل أهمية في إصدارات لاحقة.
ويجب أن تعتمد الأولوية على قيمة المطلب للمستخدم، وتأثيره في العمليات، والمخاطر، والتكلفة، والمتطلبات التنظيمية، وليس على الشخص الأكثر إلحاحًا.
إدارة تغيير المتطلبات
تتغير بعض الاحتياجات بصورة طبيعية أثناء المشروع، خاصة عند ظهور تنظيم جديد أو اكتشاف معلومة لم تكن معروفة. لكن قبول كل طلب بصورة مباشرة يؤدي إلى تغيير نطاق المشروع دون السيطرة على الوقت والميزانية.
يجب تقديم طلب تغيير رسمي يوضح المطلب الجديد وسببه وتأثيره في التكلفة والمدة والأنظمة الأخرى والمخاطر.
بعد دراسة الأثر، يمكن اعتماد التغيير أو تأجيله أو رفضه. ويجب تحديث الوثائق والجدول والميزانية عند الموافقة عليه.
تتبع المتطلبات خلال المشروع
يعني تتبع المتطلبات ربط كل مطلب بالهدف الذي يدعمه، والتصميم الذي ينفذه، وحالة الاختبار الخاصة به.
تساعد مصفوفة التتبع على التأكد من أن كل مطلب تم تطويره واختباره، ومنع إضافة خصائص لا ترتبط باحتياج معتمد.
كما تساعد عند إجراء التغيير؛ فإذا تم تعديل قاعدة معينة، يستطيع الفريق معرفة الشاشات والتقارير والاختبارات التي ستتأثر بها.
دور محلل الأعمال
يعمل محلل الأعمال على فهم احتياجات الإدارات وتحويلها إلى متطلبات يستطيع الفريق التقني تنفيذها.
يجمع المحلل المعلومات، ويوثق العمليات، ويحلل المشكلات، ويساعد على ترتيب الأولويات، ويراجع الحلول المقترحة مع المستخدمين.
ولا يتخذ المحلل جميع القرارات بمفرده، بل يسهل التواصل بين الإدارة والمستخدمين والمطورين، ويقلل اختلاف تفسير المتطلبات.
اختبار قبول المستخدم
يأتي اختبار قبول المستخدم للتأكد من أن النظام يناسب العمليات الحقيقية، وليس للتأكد من خلوه من الأخطاء البرمجية فقط.
ينفذ المستخدمون سيناريوهات قريبة من عملهم اليومي، ثم يقارنون النتائج مع معايير القبول المعتمدة.
وتؤكد سياسات الحكومة الرقمية أهمية الاستفادة من دراسات تجربة المستفيد في جميع المراحل، بداية من تحديد المتطلبات والتحليل، وصولًا إلى التصميم والتطوير والاختبار والتنفيذ وقياس الأثر.
الأسئلة الشائعة
ما المقصود بإدارة متطلبات المشاريع التقنية؟
هي عملية جمع احتياجات المستخدمين وتحليلها وتوثيقها واعتمادها ومتابعة تنفيذها وإدارة التغييرات التي تطرأ عليها.
ما الفرق بين المتطلبات الوظيفية وغير الوظيفية؟
توضح المتطلبات الوظيفية ما يفعله النظام، بينما تحدد المتطلبات غير الوظيفية مستوى السرعة والحماية والموثوقية وسهولة الاستخدام.
من المسؤول عن اعتماد المتطلبات؟
يشارك المستخدمون ومحلل الأعمال ومدير المشروع في إعدادها، لكن يجب تحديد صاحب قرار يمتلك صلاحية اعتماد المتطلبات الأساسية.
كيف نمنع توسع نطاق المشروع؟
من خلال توثيق النطاق، وترتيب الأولويات، وتطبيق آلية رسمية لدراسة طلبات التغيير قبل اعتمادها.
متى يبدأ اختبار قبول المستخدم؟
يُخطط له منذ مرحلة المتطلبات، ثم يُنفذ بعد جاهزية الوظائف المطلوبة وقبل الإطلاق النهائي.
الخاتمة
تمثل إدارة متطلبات المشاريع التقنية الأساس الذي يُبنى عليه التصميم والتطوير والاختبار والتسليم. وكلما كانت المتطلبات واضحة وقابلة للقياس، انخفضت إعادة العمل وزادت فرصة تسليم نظام يلبي احتياجات المؤسسة.
ويبدأ النجاح بفهم المشكلة وإشراك أصحاب المصلحة، ثم تنفيذ تحليل متطلبات النظام وتوثيقها وترتيب أولوياتها وربطها بمعايير قبول واضحة.
ابدأ بمراجعة مشروعك الحالي، وحدد المتطلبات الغامضة أو غير القابلة للقياس، ثم أعد صياغتها مع المستخدمين وحدد معيار قبول لكل مطلب. شارك المقال مع فريق المشروع لتقليل الخلافات ومنع توسع النطاق وإعادة العمل.
0 تعليقات