قالب جمع المتطلبات: 7 حيل أستخدمها في المشاريع

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

شاهدت مرة مشروعاً بمئات الآلاف من الدولارات ينهار لأن أحداً لم يجمع المتطلبات كما ينبغي. العميل توقع شيئاً، وفريق التطوير بنى شيئاً آخر. وحُمِّل الجميع اللوم، وعندها استُدعيت.

هذا النمط ليس غريباً. فقد وجد تقرير Pulse of the Profession الصادر عن PMI عام 2014 بشأن إدارة المتطلبات أن 47% من المشاريع غير الناجحة أخفقت في تحقيق أهدافها بسبب سوء إدارة المتطلبات. وقد رأيته يتكرر عشرات المرات.

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

أنفقت شركة صديق لي 350 ألف دولار على نظام CRM مخصص لا يستخدمه أحد. احتاجت المبيعات شيئاً، وأرادت إدارة التسويق شيئاً آخر، وبنى المطورون ما ظنوا أن الجميع يريده.

أهدر أحد عملائي في الرعاية الصحية 18 شهراً في تنفيذ نظام سجلات طبية إلكترونية (EMR) رفض الأطباء استخدامه. لم يسألهم أحد عمّا يحتاجونه في سير عملهم اليومي. فأُلغي المشروع وأُعيد من جديد.

الاكتشاف المتأخر مكلف. فقد وجدت دراسة لناسا عن تصاعد تكلفة الأخطاء أن خطأ في المتطلبات يُكتشف أثناء التكامل والاختبار تبلغ كلفة إصلاحه من 21 إلى 78 ضعف كلفة إصلاح خطأ يُكتشف أثناء مرحلة المتطلبات. وإذا اكتُشف في مرحلة التشغيل تراوح المضاعف بين 29 وأكثر من 1,500. وفي برنامج مؤسسي، هذا هو الفرق بين ورشة عمل وطلب تغيير بمئات الآلاف.

1. المتطلباتالتكلفة الأساسية للإصلاحيُكتشف والمتطلبات ما زالت قيد الكتابة
2. التكامل والاختبارمن 21 إلى 78 ضعف التكلفةيُكتشف بعد بناء النظام وهو قيد الاختبار
3. التشغيلمن 29 إلى أكثر من 1,500 ضعف التكلفةيُكتشف بعد أن يصبح النظام قيد التشغيل

المصدر: دراسة ناسا عن تصاعد تكلفة الأخطاء

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

1. ملخص تنفيذي مع خانة توقيع

لن يقرأ المديرون التنفيذيون المشغولون وثيقة متطلبات من 30 صفحة. ذات مرة اعتمد راعٍ مشروعاً دون أن يفهم ما يوقّع عليه، ثم فقد أعصابه حين رأى النتيجة. اجعله في صفحة واحدة: الأثر على الأعمال، والجدول الزمني، والموارد، والفائدة المتوقعة، وخانة توقيع في الصفحة نفسها، حتى لا يستطيع المعتمِدون الادعاء بأن التفاصيل الحاسمة فاتتهم.

2. رسم الأدوار والنفوذ

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

3. أهداف الأعمال لا المتطلبات التقنية

ما المشكلة التي نحلها، وكيف سنقيس النجاح؟ طبّق أحد عملائي في التصنيع برنامج مخزون وفق المواصفات تماماً، فأبطأ عمليات المستودع بنسبة 20%. ويجب أن يُلزم القالب أصحاب المصلحة بتعريف نجاح الأعمال بخط أساس حالي، لا بقائمة ميزات.

4. متطلبات وظيفية يستطيع المطورون الاستفادة منها

تخلَّ عن المصطلحات المعقدة. اجعل كل متطلب محدداً وقابلاً للاختبار. عبارة «يجب أن يحسّن النظام تجربة العملاء» لا قيمة لها. أما «يجب أن يتمكن المستخدمون من معالجة مرتجع وإصدار استرداد في أقل من 3 دقائق» فهي متطلب. وإن لم تستطع التحقق من أنه أُنجز، فأعد صياغته.

5. المتطلبات غير الوظيفية

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

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

القسم	ما يُدرج فيه	المسؤول	يعتمده
1. الملخص التنفيذي	المشكلة، والأثر على الأعمال، والجدول الزمني، والموارد، والفائدة المتوقعة. صفحة واحدة مع خانة توقيع	الراعي، ويصوغه قائد محللي الأعمال	الراعي والمالية
2. النطاق وخط أساس النشر	ما هو داخل النطاق وخارجه، والقيود. في SAP: الإصدار العام أو الإصدار الخاص أو التثبيت المحلي	مدير البرنامج	اللجنة التوجيهية
3. خريطة الأدوار والنفوذ	الإدارات، والممثلون، ومستوى النفوذ، والاستشارة أو الإبلاغ	قائد محللي الأعمال	الراعي
4. أهداف الأعمال	كل هدف مع مؤشر أداء رئيسي (KPI) وخط الأساس الحالي له والمستهدف	ملاك العمليات	الراعي
5. المتطلبات الوظيفية	المعرّف (مثل REQ-FUN-023)، والوصف، والمصدر، والأولوية، ومعايير القبول، وقرار Fit-to-Standard	القادة الوظيفيون	ملاك العمليات
6. المتطلبات غير الوظيفية	الأداء والأمان والامتثال والتوافر. وفي SAP، نهج الامتداد لكل فجوة	مهندس الحلول	تقنية المعلومات والأمن والامتثال
7. قائمة الانتظار (parking lot)	الطلبات المؤجلة، ومن طلبها، وموعد المراجعة التالي	قائد محللي الأعمال	لا أحد إلى أن تُرقّى
8. سجل المرفوضات	ما رُفض، ولماذا، ومتى، ومن رفضه	قائد محللي الأعمال	الراعي
9. سجل التغييرات	كل تغيير بعد التوقيع مع أثره على الوقت والتكلفة	مكتب إدارة المشاريع (PMO)	مجلس التغيير

1. استخدم «لماذا الخمسة» في مقابلات أصحاب المصلحة

اسأل «ماذا تحتاج؟» تحصل على قائمة أمنيات. اسأل عن الألم بدلاً من ذلك: «ما الذي يجعلك تريد رمي حاسوبك من النافذة؟» ثم اسأل لماذا، ثم لماذا مرة أخرى، خمس مرات. والمتطلب الحقيقي يختلف في الغالب عن الطلب الأول.

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

2. أنشئ قائمة انتظار للمتطلبات (parking lot)

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

3. طبّق قاعدة الثلاثة مع أصحاب المصلحة الذين يغيّرون رأيهم باستمرار

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

4. استخدم أسلوب توزيع التمويل لفرض ترتيب الأولويات

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

5. رقّم كل متطلب

اعتمد صيغة ثابتة مثل REQ-FUN-023. فهذا ينهي الالتباس القائم على «أي متطلب نتحدث عنه؟» الذي يضيع وقت الاجتماعات. وسجّل المصدر، أي من طلب ولماذا، لتعرف بمن تتصل حين يلزم حذف بعض البنود.

6. أعد عرض المتطلبات بلغة صاحب المصلحة

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

7. دوّن ما رُفض

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

تنجح الحيل السبع في أي مشروع. أما برامج SAP فتحتاج إلى ثلاثة أمور إضافية في القالب.

نموذج النشر يدخل في خط الأساس

سجّل نموذج النشر قبل أن تجمع المتطلبات الوظيفية: S/4HANA Cloud Public Edition (عبر GROW with SAP أو RISE)، أو Private Edition (عادةً عبر RISE)، أو التثبيت المحلي. فهو الذي يحدد ما هو ممكن. الإصدار العام لا يسمح بتعديل النواة، ولذلك يجب إعادة صياغة المتطلبات التي تعتمد على عمليات غير قياسية أو رفضها. أما الإصدار الخاص والتثبيت المحلي فيسمحان بأكثر من ذلك، على حساب جهد الترقية.

اجمع المتطلبات قبل ذلك القرار وستعيد كتابة كثير منها حين يصدر.

قرار امتداد لكل فجوة

يعني نهج Clean Core من SAP أن كل فجوة تحتاج إلى قرار مسجّل: إما تهيئتها، أو توسيعها باستخدام واجهات برمجة التطبيقات المعتمدة (released APIs)، إما داخل النظام (on-stack) باستخدام ABAP Cloud وإما بجانبه (side-by-side) على SAP BTP، أو رفضها. في الإصدار العام يفرض المنتج ذلك. وفي الإصدار الخاص والتثبيت المحلي هو توجيه قوي من SAP، وكل تعديل تسمح به يصبح عمل ترقية لاحقاً. ضع القرار في القسم 6 من القالب، بجانب الأداء والأمان، وامنح مهندساً واحداً صلاحية اعتماده. ويشرح دليلي عن Clean Core المستويات.

الذكاء الاصطناعي يصوغ والبشر يقررون

يساعد الذكاء الاصطناعي الآن في العمل الورقي. فتقدّم SAP Cloud ALM ميزة لتوليد المتطلبات تصوغ المتطلبات من محاضر ورش Fit-to-Standard داخل قالب، وتُدفع كلفتها عبر وحدات الذكاء الاصطناعي (AI units). وتصوغ المساعدات العامة مثل Microsoft Copilot الملخصات ومحاضر الاجتماعات من ملاحظات الاجتماعات.

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

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

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

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

للمشاريع الأصغر: Trello لنقل المتطلبات عبر مراحل الاعتماد، وGoogle Docs مع التعليقات للمراجعة، وMiro لرسم العمليات في الورش.

للبرامج المؤسسية: Jira مع إضافة لإدارة المتطلبات، وConfluence للمستندات الحية (وميزاته من الذكاء الاصطناعي تندرج الآن تحت علامة Rovo من Atlassian)، وModern Requirements إن كنت تستخدم Azure DevOps. وفي برامج SAP تحتفظ SAP Cloud ALM بالمتطلبات وقصص المستخدمين وحالات الاختبار في مكان واحد، مرتبطة بخارطة طريق SAP Activate.

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

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

ما المراحل الخمس لجمع المتطلبات؟

1. الاستخلاص: جمع المعلومات عبر المقابلات وورش العمل والملاحظة
2. التحليل: تنظيم المتطلبات وترتيب أولوياتها وحل التعارضات بينها
3. التوثيق: كتابة المواصفات (BRD أو FRD أو قصص المستخدمين بحسب المنهجية)
4. التحقق: التأكد من أن المتطلبات تعكس احتياجات حقيقية ويمكن اختبارها
5. الإدارة: تتبع التغييرات طوال ما تبقى من المشروع

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

ما الفرق بين BRD وFRD؟

تغطي وثيقة متطلبات الأعمال (BRD) احتياجات الأعمال: الخلفية والأهداف وأصحاب المصلحة والقيود والمتطلبات عالية المستوى. وهي تجيب عن سؤال «ما الذي تحتاجه الأعمال؟»

وتغطي وثيقة المتطلبات الوظيفية (FRD) كيف سيتصرف النظام: قصص المستخدمين وسلوك النظام والواجهات ومعايير القبول. وهي تجيب عن سؤال «ما الذي يجب أن يفعله النظام؟»

أبدأ دائماً بوثيقة BRD لتحقيق التوافق مع الأعمال قبل FRD. والفرق التي تقفز مباشرة إلى FRD كثيراً ما تبني نظاماً صحيحاً تقنياً يحل المشكلة الخاطئة.

ما أنواع المتطلبات الثلاثة؟

1. متطلبات الأعمال: سبب وجود المشروع وأهدافه ومقاييس نجاحه
2. المتطلبات الوظيفية: ما يجب أن يفعله النظام
3. المتطلبات غير الوظيفية: مدى جودة أدائه لذلك (الأداء والأمان وقابلية التوسع والامتثال)

معظم إخفاقات المشاريع التي رأيتها يعود إلى غياب المتطلبات غير الوظيفية. يفعل النظام ما طُلب منه، ثم ينهار تحت الحمل الحقيقي أو يرسب في تدقيق الامتثال.

كيف يغيّر نموذج نشر SAP عملية جمع المتطلبات؟

سجّله أولاً. لا يسمح S/4HANA Cloud Public Edition بتعديل النواة، ولذلك يجب إعادة صياغة المتطلبات المبنية على عمليات غير قياسية أو رفضها. أما Private Edition والتثبيت المحلي فيتيحان مرونة أكبر، لكن كل تعديل يضيف جهد ترقية.

اجمع المتطلبات الوظيفية قبل القرار وستعيد العمل على كثير منها. وأضف قرار امتداد مسجلاً (تهيئة، أو توسيع عبر واجهات برمجة التطبيقات المعتمدة، أو رفض) لكل فجوة.

ما الذي يجعل المتطلب قابلاً للاختبار؟

شرط واضح وقابل للقياس بنتيجة نجاح أو إخفاق. عبارة «يجب أن يكون النظام سريعاً» غير قابلة للاختبار. أما «يجب أن تُعاد نتائج البحث في أقل من ثانيتين لـ 95% من الاستعلامات عند الحمل المعتاد» فقابلة للاختبار.

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

كيف تمنع المتطلبات من التغير المستمر؟

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

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