العوامل الحقيقية وراء تكلفة منصة الويب: الأدوار والتكاملات ونقل البيانات والتصميم واللغتان والأمن والاستضافة وشكل الفريق، وكيف تقلّص النطاق.
تتبع تكلفة منصة الويب تعقيدها لا عدد صفحاتها. وأكبر العوامل: كم نوعًا من المستخدمين تخدم وماذا يستطيع كل منهم أن يفعل، وكم نظامًا آخر تتصل به، وكم من البيانات القائمة يجب نقلها، وإلى أي عمق يذهب التصميم، وكم من الأمن والصيانة تحمل. ومعظم هذه العوامل تتضاعف ولا تُجمع، ولذلك قد تتفاوت منصتان متشابهتان في خريطة الموقع تفاوتًا كبيرًا في الجهد.
نقصد بمنصة الويب منتجًا يسجّل الناس الدخول إليه ويستخدمونه: بوابة، أو منتج SaaS، أو سوقًا إلكترونية، أو نظام حجز، أو لوحة عملاء. ولن تجد هنا أرقامًا، وهذا مقصود، فالرقم الذي يُذكر قبل وجود النطاق تخمين. تعلّم العوامل، وسيصبح أي عرض، منا أو من غيرنا، شيئًا تستطيع اختباره. ولنظير هذا المقال في الجوال اقرأ [كم تكلفة تطبيق الجوال](/blog/how-much-does-a-mobile-app-cost).
لماذا تتضاعف التكلفة ولا تُجمع
تخيّل المنصة شبكة. كل دور للمستخدم يحتاج إلى شاشاته وصلاحياته واختباراته. وكل لغة تحتاج إلى محتواها وفحص تخطيطها ومراجعتها. وكل تكامل يحتاج إلى معالجة أخطائه. فإضافة دور تغيّر ميزات كثيرة دفعة واحدة، وإضافة لغة تمس كل شاشة. ولذلك فأسرع طريق إلى خفض العرض هو تقليل أحد المضاعِفات، لا اقتطاع شيء صغير من كل ميزة.
المستخدمون والأدوار وسير العمل
المدير والعميل والشريك وموظف الدعم، كل منهم يرى شاشات مختلفة وينفذ إجراءات مختلفة ويحتاج إلى فحوص مختلفة. وقواعد الصلاحيات أغلى من الشاشات: عبارة مثل «يرى المدير سجلات فرعه فقط ويعتمد المرتجعات حتى حد معين» جملة واحدة تمس قاعدة البيانات والواجهة وسجل التدقيق والاختبارات. وضبط الوصول ضابط أمني أيضًا، فيحتاج إلى [نمذجة تهديدات](/glossary/threat-modelling) إلى جانب الشيفرة.
النموذج الذي يحفظ سجلًا رخيص. أما النموذج الذي يمرّر السجل عبر موافقات، ويعيد حساب المجاميع، ويُخطر ثلاثة أشخاص، ويعالج الاستثناءات فليس رخيصًا. اسأل أي القواعد حقيقية وأيها عادة، واكتبها بلغة بسيطة قبل أن يبدأ التصميم. فالاستثناء الذي يُكتشف على الورق لا يكلّف شيئًا، والذي يُكتشف في الاختبار يكلّف كثيرًا.
التكاملات والبيانات والمحتوى
كل اتصال بنظام آخر، كمزوّد دفع أو خدمة هوية أو نظام محاسبة أو تخطيط موارد، أو [واجهة برمجية API](/glossary/api) لشريك، يجلب معه توثيقًا يُقرأ وبيئة تجريبية وإجراءات اعتماد ومعالجة أخطاء ومراقبة. والمجهول يقع عند الطرف الآخر: اعتماد بطيء، وتوثيق شحيح، وحدود على عدد الطلبات. فأحصِ التكاملات، وسجّل أيها له توثيق جيد وبيئة تجريبية، وعامل الباقي بوصفه أخطر بنود التقدير.
يُستهان بنقل البيانات من النظام القديم لأن الانتباه يتجه إلى الجديد. والعمل الحقيقي في البيانات القديمة: تكرار، وحقول ناقصة، وصيغ غير متسقة، وسجلات تعتمد على قواعد لا يتذكرها أحد. حدّد مبكرًا ما يجب نقله وما يُؤرشف وما يبدأ من جديد. والمحتوى له المشكلة نفسها، فالصفحات والمستندات وأوصاف المنتجات يجب أن يكتبها أو ينظفها أو يترجمها أحد. وليست شيفرة الاستيراد هي الجزء الباهظ في الغالب، بل التحقق من أن البيانات وصلت سليمة.
التصميم واللغة والأمن
المكونات المألوفة والعدة الصغيرة تُبقي الجهد منخفضًا، والحركة المخصصة والرسوم الفريدة وكثرة أنواع الصفحات ترفعه. والبحث واختبار قابلية الاستخدام يضيفان وقتًا في البداية ويوفّران إعادة عمل مكلفة لاحقًا. أما [نظام التصميم](/glossary/design-system) فيكلّف أكثر في أوله ثم يُرجع ثمنه مع كل شاشة لاحقة، وإمكانية الوصول وفق [WCAG](/glossary/wcag) أرخص ما تكون حين تُبنى في المكونات نفسها، لا حين تُصلَح شاشةً شاشةً بعد ذلك.
العربية والإنجليزية معًا ليستا مهمة ترجمة في آخر المشروع. فالتخطيط من اليمين إلى اليسار يعكس التنقل والأيقونات والجداول والنماذج، والعربية تحتاج إلى خطوط خاصة ونصوص تُكتب بالعربية أصلًا. وإذا خُطط لها منذ الشاشة الأولى أضافت قدرًا معتدلًا من الجهد إلى كل شاشة. أما إضافتها لاحقًا فتعني فتح مكونات بُنيت للاتجاه من اليسار إلى اليمين. وحجم المحتوى عامل أيضًا: كل صفحة ورسالة بريد ورسالة خطأ موجودة مرتين ويجب أن تبقى متطابقة. راجع [قائمة تطوير المواقع بالعربية](/blog/arabic-website-development-checklist).
نمذجة التهديدات والبرمجة الآمنة وفحص الاعتماديات والاختبار والمراجعة قبل الإطلاق كلها تستغرق وقتًا، وكذلك تسجيل الدخول بـ[المصادقة متعددة العوامل](/glossary/multi-factor-authentication) وسجلات التدقيق والتعامل الحذر مع البيانات الشخصية. وتضيف القطاعات الخاضعة للتنظيم أسئلة عن مكان تخزين البيانات ومن يحق له الاطلاع عليها. وفعل ذلك في البداية أرخص من إضافته بعد تثبيت البنية. وتأكد من الالتزامات القانونية مع مستشار قانوني مؤهل؛ فهذا المقال ليس استشارة قانونية.
الأداء والاستضافة والصيانة
يصبح الأداء عاملًا في التكلفة مع البيانات الضخمة جدًا أو البحث الثقيل أو التحديثات اللحظية أو ذروات الزيارات الحادة. فالصفحات القياسية على بيانات متواضعة لا تحتاج إلى أكثر من الممارسة الجيدة، أما التصفية السريعة على جداول ضخمة فتحتاج إلى عمل تصميمي على قاعدة البيانات والتخزين المؤقت والمراقبة.
والاستضافة جزء منها سؤال بناء (كم بيئة، وكيف تتم الإصدارات والتراجع عنها)، وجزء تكلفة تشغيل تكبر مع الاستخدام. والنسخ الاحتياطية والمراقبة وخطة استعادة الخدمة تدخل في النطاق. وبعد الإطلاق تصبح تحديثات الاعتماديات والأمان وترقيات الإطار والتغييرات الصغيرة بندًا متكررًا لا مفاجأة. وتسرد [قائمة الأمان الافتراضي للويب](/blog/secure-by-default-web-checklist) ما ينبغي أن يتوفر في المنصة.
كيف يُنظَّم العمل
**النطاق الثابت** يسعّر منتجًا محددًا مسبقًا. وهو يناسب متطلبات واضحة ومستقرة، وكل إضافة جديدة تمر عبر طلب تغيير. أما **الفريق المخصص** فيُدفع له شهريًا مقابل طاقته، ويناسب منتجًا يواصل التطور. ويقارن مقال [نماذج التسعير](/company/pricing-models) بينهما، وتصف [صفحة الأسعار](/pricing) أشكال التعاقد الثلاثة لدينا، من سبرنت الاستكشاف إلى الفريق الشهري.
وجانبك من الطاولة مهم بالقدر نفسه. فمالك منتج واحد يجيب خلال يوم يُبقي الفريق متحركًا. ولجنة تراجع على جولات، أو نطاق يتبدل كل أسبوع، يضيفان كلفة أيًّا كان من يبني. وتساعد العروض الأسبوعية لأن الخلافات تظهر وهي ما زالت رخيصة الإصلاح.
كيف تقلّص النطاق دون أن تضر بالمنتج
| يمكن تأجيله | لا يُحذف أبدًا |
|---|---|
| الدور الثاني والثالث للمستخدمين | ضبط الوصول وأمان تسجيل الدخول |
| أتمتة الحالات النادرة | الاختبار ومراجعة الأمان قبل الإطلاق |
| التقارير المتقدمة والحركة المخصصة | النسخ الاحتياطية وخطة الاستعادة |
| لغات أخرى غير العربية والإنجليزية | مكونات يسهل الوصول إليها وأسس الاتجاه من اليمين إلى اليسار |
ماذا تسأل في عرض السعر
العرض الجيد يذكر افتراضاته، وهذه الأسئلة تكشفها:
- ما أدوار المستخدمين المشمولة، وماذا يستطيع كل دور أن يفعل؟
- ما التكاملات المشمولة، ومن يتعامل مع الأمر حين يتغير نظام طرف ثالث أو يتعطل؟
- ما المفترض في نقل البيانات والمحتوى، ومن يتحقق منه؟
- كم لغة، وهل التصميم من اليمين إلى اليسار جزء من الأساس أم إضافة؟
- ما الاختبار وأعمال إمكانية الوصول ومراجعة الأمان التي تجري قبل الإطلاق؟
- كم بيئة، وأين تُستضاف المنصة، ومن يدفع تكاليف التشغيل؟
- كيف يُسعَّر تغيير النطاق؟
- ماذا أتسلّم في النهاية: الشيفرة المصدرية، والتوثيق، والوصول إلى كل حساب؟ وماذا يغطي الدعم بعد الإطلاق؟
وحين يختلف عرضان، قارن افتراضاتهما بندًا بندًا قبل أن تقارن المجاميع، فالفجوة تقع عادة في بند أو بندين. ولمعرفة طريقتنا في هذا العمل راجع [تطوير المواقع](/services/web-development)، ومنه [منصات SaaS](/services/web-development/saas-platforms) و[التجارة الإلكترونية](/services/web-development/ecommerce).