لا تقارن السعر الإجمالي لعرضين لإنشاء موقع قبل أن تتأكد أنهما يشملان المخرجات نفسها. عبارة «موقع من عشر صفحات بلغتين» قد تعني تصميمًا فقط، أو تصميمًا وتطويرًا، أو إدخال نصوص جاهزة دون كتابتها. وقد يشمل أحد العرضين نقل الروابط والاختبارات والتدريب، بينما يتركها الآخر للعميل. المقارنة العادلة تبدأ بتوحيد النطاق والافتراضات، ثم النظر إلى السعر.
هذه طريقة شراء لموقع شركة، وليست قائمة أسعار سوقية. لا يوجد رقم مسؤول يمكن اقتراحه دون معرفة الصفحات والوظائف والمحتوى والاعتمادات. والمقصود ليس اختيار الأغلى أو الأرخص تلقائيًا، بل معرفة ما الذي تحصل عليه وما الذي ستضطر لتدبيره لاحقًا.
اطلب جدول مخرجات مشتركًا
أرسل للمزوّدين الأسئلة نفسها، واطلب إجابة «مشمول، غير مشمول، أو يحتاج تحديدًا»، مع وصف قصير. لا تحوّل الفراغ إلى موافقة ضمنية. وإذا كانت الإجابة «حسب الحاجة»، فاسأل من يقرر الحاجة وكيف يؤثر القرار على العمل والسعر.
| البند | ما يجب توضيحه |
|---|---|
| الصفحات والقوالب | عدد نسخ المحتوى مقابل عدد التخطيطات المختلفة |
| التصميم | الجوال، حالات التفاعل، وملفات التسليم |
| المحتوى | كتابة أم تحرير أم إدخال نص جاهز؟ |
| اللغات | ترجمة ومراجعة وتنسيق وإدخال كل لغة |
| التطوير | النظام والحقول والوظائف والتكاملات |
| النقل | المحتوى والملفات والعناوين القديمة |
| الاختبار والإطلاق | السيناريوهات والأدلة وصاحب قرار النشر |
| التسليم والدعم | حسابات وتدريب وضمان عيوب وحدود صيانة |
يفصل تصميم المواقع الإلكترونية بين تجربة الصفحات ومواصفات تنفيذها، بينما يغطي تطوير أنظمة إدارة المحتوى البناء والإدارة وفق نطاقه. شراء التصميم لا يعني تلقائيًا شراء موقع منشور، ووجود الموقع لا يثبت أن فريقك يستطيع تحديثه.
اكتب قبولًا يمكن رؤيته
بدل «نموذج تواصل احترافي»، اكتب: «يرسل الزائر طلبًا بالعربية أو الإنجليزية، ويُظهر النظام الخطأ عند نقص حقل ضروري، ويصل الطلب إلى الوجهة المعتمدة». هذه صياغة يمكن اختبارها ومناقشة تكلفتها. يعرّف دليل GOV.UK معايير القبول بوصفها نتائج للتحقق من تلبية الحاجة. دليل قصص المستخدم.
استخدم اكتشاف المنتج وتوثيق المتطلبات عندما تكون الوظائف غير محسومة. قد تكون مرحلة تحديد صغيرة أفضل من طلب سعر ثابت لمجهول كبير، بشرط أن تكون مخرجاتها واضحة ويمكن استخدامها في قرار التنفيذ اللاحق.
مثال افتراضي: عنوان واحد ونطاقان مختلفان
تتلقى شركة عرضين بعنوان «موقع من عشر صفحات بلغتين». المثال للتوضيح فقط ولا يمثل عروضًا فعلية أو أسعارًا من LAB. العرض الأول يشمل أربعة قوالب، وإدخال نصوص يسلّمها العميل، ونموذجًا يرسل بريدًا. العرض الثاني يشمل ستة قوالب، وتحرير المحتوى، وإدخال اللغتين، وربط النموذج بنظام قائم مع اختبار التسليم.
لا تستنتج أن الثاني أفضل قبل السؤال: هل تحتاج الشركة القالبين الإضافيين؟ هل لديها بالفعل نصوص معتمدة؟ هل التكامل ضروري الآن؟ قد يكون الأول مناسبًا إذا أضيفت مراجعة واضحة، وقد يكون الثاني أوضح إذا كانت الأعمال الإضافية مطلوبة فعلًا.
ثم يتبين أن أحد العرضين يفترض أن العميل سينقل الملفات، والآخر يفترض وجود حساب استضافة جاهز. تُضاف الافتراضات إلى الجدول، ويُطلب تسعير الخيارات الناقصة على الأساس نفسه. لا تجمع أرقامًا لا تغطي الشيء نفسه ثم تسمي فرقها «توفيرًا».
انتبه إلى تكلفة الاعتماد والتغيير
قد يتأخر الموقع لأن العميل لم يحدد صاحب النص، لا لأن المطوّر لم يبدأ. اكتب ما يحتاجه المزوّد ومتى، ومن يراجع التصميم، وكيف تجمع الملاحظات، وما معنى جولة تعديل. تصحيح خطأ في تنفيذ موافق عليه يختلف عن إضافة وظيفة جديدة بعد اعتماده.
اطلب إجراء تغيير بسيطًا: وصف الطلب، وأثره على المخرجات والموعد والتكلفة، ثم موافقة قبل التنفيذ. لا يلزم تعقيد إداري؛ المهم ألا تتحول محادثة عابرة إلى التزام غير مفهوم. وكذلك يجب ألا تُستخدم عبارة «خارج النطاق» لحجب عيب يمنع مخرجًا متفقًا عليه من العمل.
قارن ملكية التشغيل بعد الإطلاق
من يملك النطاق والاستضافة وحساب النظام؟ ما التراخيص المتكررة؟ هل يمكن تصدير المحتوى؟ من يحدّث الإضافات؟ وما الفرق بين إصلاح العيوب والدعم والإضافات الجديدة؟ اطلب هذه الإجابات دون افتراض أن الحزمة تشمل تشغيلًا دائمًا.
ضمن ضمان الجودة، حدّد الصفحات والمهام والأجهزة واللغات التي ستُختبر، وكيف تعالج العيوب قبل القبول. كلمة «اختبار شامل» وحدها لا تحدد التغطية. كما أن موعد التسليم يحتاج معرفة جاهزية المحتوى والصلاحيات والاعتمادات، وليس رغبة أحد الأطراف فقط.
كيف تتخذ القرار بعد توحيد النطاق؟
قارن وضوح الإجابات، وملاءمة الحل، وأدلة القدرة التي يمكن التحقق منها، ومسؤولية التشغيل، ثم السعر. استبعد الوعود التي لا ترتبط بمخرجات قابلة للفحص، مثل ضمان المرتبة الأولى أو انعدام الأعطال. واطلب توضيحًا مكتوبًا لأي اعتماد خارجي لا يملكه المزوّد.
قائمة قبل الموافقة
- الأعمال الإلزامية والاختيارية منفصلة في كل عرض.
- عدد اللغات والقوالب ونسخ المحتوى واضح.
- مسؤوليات الكتابة والترجمة والاعتماد محددة.
- التكاملات والحسابات والتكاليف المتكررة معلومة أو مسجلة كفجوة.
- معايير القبول وإجراء التغيير والقيود موثقة.
- التسليم يتضمن ما يحتاجه الفريق لتشغيل الموقع المتفق عليه.
أسئلة شائعة
هل السعر الثابت أفضل دائمًا؟
يناسب نطاقًا مفهومًا وافتراضات واضحة. إذا كانت الوظائف مجهولة، قد يكون تقدير مشروط أو مرحلة اكتشاف أكثر صدقًا من رقم ثابت يخفي الاستثناءات.
هل أطلب تفاصيل تقنية كثيرة؟
اطلب ما يؤثر على المخرجات والملكية والتكلفة والصيانة. لا يلزم تقييم كل مكتبة برمجية لتفهم ما تشتريه.
هل عدد جولات التصميم مؤشر جودة؟
ليس وحده. الأهم ما يشمله كل اعتماد، وكيف تُجمع الملاحظات، وكيف يُعالج ما يخالف المتطلبات.
هل ضمان العيوب يساوي الصيانة؟
لا تفترض ذلك. اطلب تعريفًا لكل منهما ومدته ونطاقه، مع توضيح ما يحدث عند تعديل الموقع من طرف آخر.
اجعل العرض قابلًا للمقارنة
شارك LAB جدول المخرجات والأسئلة المفتوحة، واطلب بيانًا منفصلًا للتصميم والتطوير والمحتوى والاختبار والتسليم. سيكون القرار أوضح من مقارنة إجماليين وراءهما عملان مختلفان.
المصادر
- GOV.UK: معايير القبول في قصص المستخدم، روجع في 26 أكتوبر 2026؛ لا يتضمن هذا المقال تقديرات لأسعار السوق.
