كيف تعد RFP لتطوير تطبيق يحصل على عروض قابلة للمقارنة؟
عروض بأطوال وهياكل مختلفة، وكل منها يسعّر نطاقًا مختلفًا؟ هذه المقالة للمشتريات ومسؤولي المشاريع ومديري التقنية: كيف تكتب طلب العروض بحيث يجيب كل متقدم عن الأسئلة نفسها بالصيغة نفسها، فتقارن الإجابات لا العروض.
العروض تأتي قابلة للمقارنة حين يثبّت طلب العروض ثلاثة أشياء، لا شيئًا واحدًا. الأول ما تطلبه: متطلبات مرقمة قابلة للاختبار، وظيفية وغير وظيفية، مع التكاملات والأمن والاستضافة والدعم. والثاني كيف يُرد عليك: مصفوفة امتثال لكل متطلب، وجدول تسعير ببنود تحددها أنت، وقائمة افتراضات واستثناءات، وفريق بأدوار، وجدول بالمراحل. والثالث كيف ستقيّم: معايير وأوزان معلنة، وحد أدنى فني قبل فتح العروض المالية. إعداد RFP لتطوير تطبيق بهذه الأقسام يجعل كل شركة تجيب عن الأسئلة نفسها بالصيغة نفسها، فتقارن الإجابات بدل أن تترجم العروض.
أغلب لجان الفحص تكتشف المشكلة بعد فتح المظاريف: عرض من ثمانين صفحة وعرض من خمس، وأحدهما يسعّر بالمراحل والآخر بالمنصات والثالث بالساعات، وكل منها يفترض نطاقًا مختلفًا. عندها لا تقيّم اللجنة الشركات، بل تحاول ترجمة عروضها إلى لغة واحدة، وتضطر إلى جولة استيضاح طويلة أو إلى قرار على أساس غير متساوٍ. هذا لا يُصلح في مرحلة التقييم؛ يُصلح في الكراسة نفسها.
لماذا تأتي العروض غير قابلة للمقارنة؟
ثلاث فجوات في طلب العروض تنتج ثلاثة أنواع من الاختلاف في الردود:
- فجوة المتطلبات: «تطبيق لحجز الخدمات مع لوحة تحكم وتقارير» تقرؤه كل شركة بحجم مختلف، فتسعّر كل منها مشروعًا مختلفًا.
- فجوة صيغة الرد: حين لا تحدد كيف يُكتب الرد، يكتب كل متقدم بالطريقة التي تُظهر عرضه أفضل، ويخفي ما لا يريد إظهاره في فقرات عامة.
- فجوة التقييم: حين لا تعلن المعايير، يركز المتقدمون على ما يظنون أنه يهمك، وغالبًا يكون السعر، فيحذفون ما لا تراه.
- عروض بأطوال وهياكل مختلفة
- أسعار إجمالية لا تُفكَّك بالبنود نفسها
- افتراضات مخفية في فقرات عامة
- جولة استيضاح طويلة بعد فتح العروض
- قرار يميل إلى أقل سعر لأنه الرقم الوحيد القابل للمقارنة
- رد على كل متطلب مرقم: ملتزم، أو جزئي، أو غير ملتزم
- جدول تسعير بالبنود نفسها لدى الجميع
- قائمة افتراضات واستثناءات منفصلة
- أسئلة استيضاح قبل التقديم، وإجاباتها لكل المتقدمين
- تقييم فني بدرجات، ثم مقارنة مالية بين المؤهلين
هيكل طلب العروض: عشرة أقسام وما يضيفه كل منها للمقارنة
هذا الهيكل يصلح لشركة خاصة تطرح مشروع تطبيق على عدة مزودين، ويصلح أساسًا للأقسام الفنية في كراسة جهة حكومية. إن كانت جهتك حكومية، فالكراسة تُعد وتُطرح وفق نظام المنافسات والمشتريات الحكومية ولائحته والنماذج المعتمدة لدى جهتك، وتضع هذه الأقسام داخل ذلك الإطار لا بديلًا عنه.
| القسم | ما يحتويه | ما يضيفه لقابلية المقارنة |
|---|---|---|
| 1. الخلفية والأهداف | من أنتم، والمشكلة، وما سيتغير بعد الإطلاق، ومقاييس النجاح | يفهم المتقدم لماذا تُطلب كل ميزة، فيقترح بدائل بدل أن يضخّم النطاق |
| 2. المستخدمون والأدوار | أنواع المستخدمين، وعدد تقريبي لكل نوع، وما يفعله كل دور | يسعّر الجميع العدد نفسه من التطبيقات والواجهات والصلاحيات |
| 3. المتطلبات الوظيفية | متطلبات مرقمة، ولكل منها أولوية (إلزامي، مرغوب، اختياري) ومعيار قبول | كل رد يُقاس على القائمة نفسها، والأولوية تمنع تسعير الاختياري كإلزامي |
| 4. المتطلبات غير الوظيفية | الأداء والأحمال، والأجهزة والإصدارات، واللغات، والإتاحة، والتوافر | تمنع أن يسعّر أحدهم نظامًا لمئة مستخدم والآخر لعشرة آلاف |
| 5. التكامل | الأنظمة المطلوب الربط بها، وما تتيحه من واجهات، وتوثيقها في ملحق | التكامل أكثر بند يُسعّر بالتخمين؛ التوثيق المرفق يحوله إلى تقدير |
| 6. الأمن والاستضافة والبيانات | تصنيف البيانات، ومتطلبات موقعها، والاستضافة المطلوبة أو المتاحة، والدخول الموحد إن وجد | يعرف الجميع أين سيعمل النظام وبأي ضوابط قبل أن يسعّروا البنية |
| 7. التنفيذ والتسليم | المراحل المتوقعة، والمخرجات، وطريقة القبول، والملكية والحسابات، والتوثيق ونقل المعرفة | مخرجات التسليم نفسها لدى الجميع، لا «تسليم الكود» عند أحدهم ومستودعًا موثقًا عند الآخر |
| 8. الدعم والتشغيل | فترة الضمان المطلوبة، ومستوى الخدمة بعدها، وساعات التغطية | تكلفة ما بعد الإطلاق تُسعّر بالافتراضات نفسها |
| 9. صيغة الرد المطلوبة | مصفوفة الامتثال، وجدول التسعير، والافتراضات، والفريق، والجدول، وحدود الطول | القسم الذي يصنع المقارنة فعلًا، ويُفصل أدناه |
| 10. التقييم ومواعيد الطرح | المعايير وأوزانها، والحد الأدنى الفني، ومواعيد الاستيضاح والتقديم | يعرف المتقدمون ما يهمك، فيستثمرون في الإجابة عنه |
إن لم تكن المتطلبات جاهزة بهذا المستوى، فكتابتها خطوة تسبق الطرح. خدمة تحليل المتطلبات وإعداد وثيقة SRS تنتج وثيقة يملكها العميل ويمكن طرحها على أي جهة تنفيذ، ولصاحب المشروع الذي يريد بداية أبسط قالب مختصر في مقالة نموذج متطلبات تطبيق جوال.
كيف تكتب متطلبًا قابلًا للاختبار؟
المتطلب القابل للاختبار يجيب عن سؤال واحد: كيف ستحكم لجنة القبول أنه نُفذ؟ إذا لم تستطع أن تتخيل اختبارًا ينجح أو يفشل، فالمتطلب سيُسعّر بطرق مختلفة ويُسلَّم بطرق مختلفة. رقّم كل متطلب (مثل FR-07 للوظيفي وNFR-03 لغير الوظيفي) ليُشار إليه في الردود والعقد والاختبار.
مثال افتراضي للتوضيح الأرقام في العمود الثالث أمثلة للصياغة فقط، وتضع بدلها قيمًا تناسب مشروعك وجمهورك.
| المجال | صياغة غامضة | صياغة قابلة للاختبار |
|---|---|---|
| التقارير | «تقارير شاملة للإدارة» | FR-21 (إلزامي): تقرير يومي بعدد الطلبات المكتملة والملغاة وسبب الإلغاء لكل فرع، يطّلع عليه مدير العمليات من اللوحة، ويُصدَّر إلى Excel |
| لوحة التحكم | «لوحة تحكم متكاملة» | FR-30 إلى FR-38: وحدات اللوحة مسماة واحدة واحدة (الطلبات، الموظفون، الأسعار، العروض، المحتوى، الصلاحيات، سجل التغييرات) مع الأدوار التي تصل إلى كل وحدة |
| الأداء | «التطبيق سريع ويتحمل الضغط» | NFR-02: يتحمل النظام 1,500 مستخدم متزامن في الذروة، ولا يتجاوز زمن الاستجابة ثانيتين في 95% من الطلبات، ويُثبت ذلك باختبار أحمال قبل الإطلاق |
| الأجهزة | «يعمل على جميع الأجهزة» | NFR-05: يعمل على آخر ثلاثة إصدارات رئيسية من iOS وAndroid، ويُختبر على قائمة أجهزة يقدمها المتقدم في رده |
| التكامل | «ربط مع النظام المحاسبي» | FR-44: تُرحَّل كل فاتورة مكتملة إلى النظام المحاسبي عبر واجهته الموثقة في الملحق (4)، وتظهر حالات فشل الترحيل في اللوحة مع إمكانية إعادة المحاولة |
| الأمن | «مستوى أمان عالٍ» | NFR-09: قفل الحساب مؤقتًا بعد محاولات دخول فاشلة متكررة، وسجل تدقيق لكل تغيير في الصلاحيات، واختبار اختراق قبل الإطلاق تُعالج نتائجه الحرجة قبل القبول |
| اللغة | «دعم العربية والإنجليزية» | NFR-11: كل الشاشات والإشعارات والرسائل باللغتين، باتجاه صحيح لكل لغة، والمحتوى يُدخل باللغتين من اللوحة |
لاحظ أن الصياغة الجيدة لا تحدد طريقة التنفيذ (أي قاعدة بيانات، أي إطار عمل)، بل النتيجة التي تُقاس. تحديد التقنية في الكراسة يستبعد مقترحات أفضل، إلا إن كان لديك قيد حقيقي مثل التوافق مع بنية قائمة. وصياغة معايير القبول بالتفصيل لكل ميزة موضوع مقالة معايير القبول في مشروع التطبيق.
صيغة الرد المطلوبة: القسم الذي يصنع المقارنة
إن كان في الكراسة قسم واحد لا تتنازل عنه، فهو هذا. حدد فيه ما يجب أن يحتويه كل رد، وبأي ترتيب، وبأي نموذج، واذكر أن الرد الذي لا يلتزم بالصيغة قد لا يُقيَّم.
1. مصفوفة الامتثال
جدول تقدمه أنت بكل المتطلبات المرقمة، ويملأ المتقدم أمام كل متطلب: ملتزم، أو ملتزم جزئيًا، أو غير ملتزم، أو بديل مقترح، مع تعليق مختصر وإحالة إلى صفحة التفصيل في عرضه. هذه المصفوفة تكشف فورًا ما يتجاوزه كل عرض، بدل أن تكتشفه في التنفيذ.
2. جدول التسعير الموحد
لا تترك تقسيم السعر للمتقدم. حدد البنود، واطلب سعرًا لكل بند، وافصل تكاليف الأطراف الثالثة عن أتعاب التطوير:
| البند | مشمول؟ | السعر | الافتراضات المرتبطة |
|---|---|---|---|
| التحليل والتصميم والنموذج الأولي | |||
| تطبيق iOS وAndroid لكل دور | |||
| الخوادم وواجهات الربط | |||
| لوحة التحكم | |||
| كل تكامل على حدة | |||
| الاختبار والأمن واختبار الأحمال | |||
| النشر والتوثيق ونقل المعرفة والتدريب | |||
| فترة الضمان | |||
| الدعم السنوي بمستوى الخدمة المطلوب | |||
| تكاليف الأطراف الثالثة المتوقعة (استضافة، رسائل، خرائط، تراخيص)، تُدفع لمزوديها |
3. الافتراضات والاستثناءات
قائمة منفصلة بكل ما بنى عليه المتقدم سعره، وكل ما استثناه من النطاق. اطلب ألا تُدفن الافتراضات في نص العرض، وأن تُرقم لتُناقش في الاستيضاح وتنتقل إلى العقد.
4. الفريق والجدول والمنهجية
جدول بأدوار الفريق المقترح ومن يقود التقنية، وجدول بالمراحل ومخرج كل مرحلة، ووصف مختصر لإيقاع التقارير والنسخ التجريبية. وحدد حدًا أقصى لعدد الصفحات في القسم الفني؛ الحد يجبر المتقدم على الوضوح ويوفر وقت اللجنة.
اطلب العرض الفني والمالي منفصلين، ولا يُفتح المالي إلا لمن تجاوز الحد الأدنى الفني. هذا الترتيب يمنع أن يؤثر الرقم على قراءة الجودة. وفي المنافسات الحكومية يحدد نموذج الكراسة نفسها طريقة تقديم العرضين وفتحهما.
معايير التقييم: أعلنها في الكراسة لا بعد التقديم
إعلان المعايير والأوزان ليس تساهلًا مع المتقدمين، بل توجيه لهم لإنفاق جهدهم على ما يهمك. إن قلت إن الأمن ونقل المعرفة يحملان وزنًا كبيرًا، فستجد في الردود تفصيلًا لهما بدل صفحات عن تاريخ الشركة.
مثال افتراضي للتوضيح توزيع يصلح بداية لمشروع تطبيق متوسط التعقيد: التقييم الفني 70 والمالي 30، وحد أدنى فني 70 من 100 لفتح العرض المالي. ويتوزع الفني مثلًا على فهم المتطلبات والحل المقترح (25)، والمعمارية والأمن والاستضافة (20)، والفريق وخبرته المماثلة (20)، والمنهجية والجدول (15)، والاختبار والقبول (10)، والدعم ونقل المعرفة (10).
النسب ليست قاعدة، وتغيرها طبيعة مشروعك. تفصيل نموذج الدرجات الفنية والأدلة المطلوبة لكل معيار في مقالة تقييم العروض الفنية لمشروع تطبيق، وتوحيد العروض المالية وتكلفة الملكية على مدة العقد في مقالة تقييم العروض المالية لمشروع برمجي.
مواعيد الطرح وجولة الاستيضاح
أفضل الكراسات تُحسَّن بأسئلة المتقدمين. أسئلة الاستيضاح تكشف الغموض الذي لم تره، وطريقة التعامل معها تحدد عدالة المقارنة.
- نشر الكراسةمع الملاحق وتوثيق الأنظمة واتفاقية السرية إن لزمتالجهة
- أسئلة الاستيضاحمكتوبة، حتى موعد محددالمتقدمون
- إجابة موحدةتُرسل لكل المتقدمين، وتُعدَّل الكراسة إن لزمالجهة
- التقديم والتقييم الفنيمصفوفة الامتثال والدرجات، وعروض تقديمية إن لزمتلجنة الفحص
- فتح المالي والترسيةللمتجاوزين الحد الفني فقطالجهة
اترك بين آخر موعد للأسئلة وآخر موعد للتقديم وقتًا كافيًا ليعدّل المتقدمون عروضهم بعد الإجابات. والإجابة الموحدة لا تحتاج إلى ذكر من سأل.
أخطاء شائعة في إعداد RFP لتطوير تطبيق
- نسخ كراسة مشروع سابق: تحمل متطلبات لا تخص مشروعك، وتغيب عنها التي تخصه، فيسعّر المتقدمون ما لا تحتاجه.
- تحديد التقنية دون قيد حقيقي: يستبعد مقترحات قد تكون أنسب وأقل تكلفة، ويحوّل التقييم إلى مطابقة كلمات.
- قائمة مزايا بلا أولويات: تجعل كل شيء إلزاميًا، فترتفع الأسعار ويصعب اختيار نطاق إصدار أول.
- نسيان لوحة التحكم والتقارير: تصف تطبيق المستخدم بدقة وتكتب «ولوحة تحكم» في سطر، وهي غالبًا بحجم تطبيق مستقل.
- ذكر التكامل دون توثيق: «ربط مع نظام الموارد البشرية» بلا توثيق لواجهاته يعني أن كل متقدم سيخمّن حجمه.
- سعر إجمالي فقط: لا يمكنك معرفة ما حُذف لخفضه، ولا التفاوض على بند بعينه.
- إخفاء المعايير أو تغييرها بعد التقديم: يفقد العملية عدالتها، ويفقد اللجنة حجتها في قرارها.
- مهلة تقديم قصيرة لمشروع كبير: تستبعد الشركات الجادة التي تحتاج وقتًا لدراسة المتطلبات، وتبقي من يرد بعرض عام.
ما تجهزه قبل الطرح، وما تطلبه من الشركات المتقدمة
قبل كتابة الكراسة، جهّز ما لا تستطيع الشركات أن تخمنه عنك:
- أصحاب القرار ومن يعتمد المتطلبات، ولجنة الفحص وأدوار أعضائها.
- الأنظمة المطلوب الربط بها وتوثيق واجهاتها، أو اسم من يستطيع توفيره.
- تصنيف البيانات التي سيعالجها التطبيق، ومتطلبات موقع الاستضافة إن وجدت.
- الحجم المتوقع للمستخدمين في الإطلاق وبعد فترة التشغيل الأولى.
- الميزانية المعتمدة أو نطاقها الداخلي، لتعرف مبكرًا هل النطاق واقعي، حتى لو لم تُعلنها.
- مواعيد الطرح والاستيضاح والتقديم والترسية، مع هامش للإجابات.
واطلب من كل شركة متقدمة، بصيغة ملزمة في الكراسة:
- مصفوفة الامتثال مملوءة لكل متطلب مرقم.
- جدول التسعير الموحد، مع فصل تكاليف الأطراف الثالثة.
- قائمة الافتراضات والاستثناءات مرقمة ومنفصلة.
- الفريق المقترح بأدواره، والتزامًا بإبلاغك قبل تغيير الأدوار الرئيسية.
- الجدول بالمراحل ومخرجاتها، وطريقة القبول المقترحة.
- ما تقترحه لما بعد الإطلاق: الضمان ومستوى الخدمة ونقل المعرفة.
- أسئلتها المكتوبة في موعد الاستيضاح، لا بعد التقديم.
وإن كانت جهتك حكومية، فالأقسام الفنية الخاصة بالهوية الرقمية والإتاحة والتشغيل طوال العقد مفصلة في مقالة كراسة شروط تطبيق حكومي.
الخلاصة: الكراسة تحدد جودة المقارنة قبل أن تحدد جودة العروض
العروض غير القابلة للمقارنة نتيجة طبيعية لكراسة تصف المشروع ولا تحدد صيغة الرد. اكتب متطلبات مرقمة قابلة للاختبار، واطلب مصفوفة امتثال وجدول تسعير ببنودك أنت وقائمة افتراضات منفصلة، وأعلن المعايير والحد الأدنى الفني، وأجب عن أسئلة الاستيضاح للجميع. بعدها تقضي لجنتك وقتها في تقييم الشركات، لا في ترجمة عروضها.
وإن كانت كراستك جاهزة، فأرسلها عبر صفحة إرسال كراسة الشروط أو طلب العروض. نوقع اتفاقية السرية قبل مراجعة التفاصيل إن طُلبت، ونرسل أسئلة الاستيضاح في موعدها، ثم نقدم العرض الفني والمالي وفق النموذج المطلوب، ونبلغكم مبكرًا إن كان المشروع خارج نطاقنا. وإن كانت متطلباتك غير جاهزة بعد، فصفحة كيف يتم تقدير مشروع التطبيق توضح العوامل التي يجب أن تغطيها الكراسة ليُبنى عليها تقدير دقيق.
أسئلة شائعة
ليس إلزاميًا. إعلانها يساعد المتقدمين على اقتراح نطاق واقعي، لكنه قد يجعل العروض تقترب منها تلقائيًا. الحل الوسط أن تحدد أولويات المتطلبات بوضوح، وتطلب تسعير الإلزامي والمرغوب والاختياري منفصلة، فتختار النطاق الذي يناسب ميزانيتك بعد التقديم.
في الطرح الخاص يكفي غالبًا من ثلاث إلى خمس شركات مؤهلة مسبقًا. أكثر من ذلك يطيل التقييم ويقلل جدية الردود، لأن الشركات الجيدة تتردد في استثمار جهد كبير في منافسة واسعة. أما المنافسات العامة فتحكمها أنظمة الجهة وإجراءاتها.
حددها فقط إن كان لديك قيد حقيقي، مثل فريق داخلي سيستلم الكود بتقنية معينة أو بنية قائمة يجب التوافق معها. وفي غير ذلك اطلب من المتقدم أن يقترح التقنية ويعلل اختياره، فالتعليل نفسه دليل على الفهم.
وثيقة المتطلبات تصف ما يجب أن يفعله النظام بالتفصيل، وطلب العروض يضيف إليها شروط الطرح: صيغة الرد، وجدول التسعير، ومعايير التقييم، والمواعيد، وبنود التعاقد المتوقعة. الأفضل أن تكون الوثيقة ملحقًا بالكراسة.
إن نصت الكراسة على أن الالتزام بالصيغة شرط للتقييم فطبق ذلك على الجميع بالتساوي. وإن كانت المخالفة شكلية، فاطلب من المتقدم استكمال مصفوفة الامتثال أو جدول التسعير في مهلة قصيرة، ولا تكمله أنت بتفسيرك لعرضه.
خدمات وصفحات مرتبطة
اقرأ أيضًا
كراستك جاهزة؟ أرسلها لنرد وفق نموذجها
أرفق الكراسة ومواعيدها، ونرسل أسئلة الاستيضاح في موعدها، ثم عرضًا فنيًا وماليًا بالصيغة التي تطلبها الكراسة.