# دليل تطوير الويب 2026: العملية والخيارات والمورد

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

## ما هو تطوير الويب، وأين يتوقف تصميم الويب؟

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

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

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

إن كان الخلل بنيياً فيحتاج إلى تطوير لا إلى تجميل، وإن كان بصرياً فهو عمل [تصميم الويب](/ar/services/web-design/). وتصف [اتجاهات تصميم الويب](/ar/blog/web-design-trends/) هذا العام إلى أي حدّ انتقل الجانب البصري إلى أنظمة التخطيط والخطوط لا إلى الصور.

## ما الذي يحدث في مشروع تطوير ويب من الموجز حتى الإطلاق؟

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

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

1. **الاستكشاف** — الهدف والجمهور والقيود والأنظمة القائمة.
2. **بنية المعلومات** — قائمة الصفحات والتنقّل ونموذج المحتوى.
3. **التصميم** — التخطيط والتفاعل على محتوى حقيقي.
4. **التنفيذ** — القوالب والمسارات والتكاملات في مقاطع قابلة للمراجعة.
5. **المحتوى** — الكتابة والترحيل والبيانات الوصفية على النموذج المُسلَّم.
6. **ضبط الجودة** — الأجهزة والمتصفحات والنماذج ومسارات الإحالات ومسارات لوحة المفاتيح.
7. **الإطلاق** — DNS ومسارات الإحالات وقياسات الأداء وخطة الاسترجاع ومراقب.
8. **الصيانة** — التحديثات والمراقبة والنسخ الاحتياطي والجولة التالية من التعديلات.

## ما خيارات البناء: كود مخصص، أم نظام إدارة محتوى، أم منشئ مواقع؟

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

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

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

الجانب المعماري ومسار العرض في [ووردبريس مقابل التطوير المخصص](/ar/blog/wordpress-vs-custom-development-guide-2026/)، وجانب الميزانية والجدول الزمني في [الدليل التجاري](/ar/blog/wordpress-vs-custom-development/)، ومتطلبات سلة الشراء والفهرس في [تصميم المتاجر الإلكترونية](/ar/blog/ecommerce-web-design-guide-2026/).

## ما الذي يجب أن يحتويه الموجز قبل أن يعرض أحد سعراً؟

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

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

- **جرد المحتوى** — أنواع الصفحات وحجمها ومن يكتبها، وهل يُرحَّل المحتوى القديم.
- **التكاملات** — الدفع وCRM والحجز والبريد وقياسات الأداء: سمِّ كل نظام.
- **القيود** — الموعد النهائي وسقف الميزانية واللغات والامتثال والعقود القائمة.
- **ملكية القرار** — من يعتمد، ومن يجيب، وكم تستغرق مدة الرد.

## كيف تقرأ عرض تطوير دون أن يخدعك؟

اقرأ العرض ثلاث مرات وبترتيب محدد: مرة لفهم ما سيُسلَم، ومرة لما لن يُسلَم، ومرة للكلفة عند تغيّر النطاق. ابدأ بحصر المخرجات والافتراضات التي خلف كل سطر، ثم انظر إلى من يتحمّل المحتوى والموافقات وما تملكه في النهاية. المجموع الواحد بلا تفصيل للساعات ليس سعراً؛ إنه تخمينٌ ينتظر توقيعك.

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

- **مراحل بساعات** — سطر واحد مجمّع لا يمكن مقارنته بشيء.
- **افتراضات مكتوبة** — من يوفّر المحتوى والصور والحسابات والموافقات ومتى.
- **استثناءات مسمّاة** — الفارق الحقيقي بين عرضين يقع هنا عادة.
- **شروط التسليم** — المستودع والحسابات والوثائق والتراخيص باسمك في النهاية.

## ما الذي يحدّد تكلفة مشروع تطوير الويب فعلياً؟

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

كلّ هذه العوامل تظهر في التقدير على شكل ساعات، والساعات هي الوحدة الصادقة الوحيدة قبل أن يستقرّ النطاق. ولجعلها ملموسة، خذ هذا التقدير الافتراضي: مطوّران يخصّص كل منهما 20 ساعة أسبوعياً لمدة ستة أسابيع، أي 2 × 20 × 6 = 240 ساعة، وسطر الأجور هو هذا المجموع مضروباً في أيّ سعر بالساعة يُطبَّق. وإدخال المحتوى ورسم خرائط الإحالات واختبار المتصفحات ساعات أيضاً، وهي الأسطر التي تختفي من عرض رخيص ثم تعود في صورة طلبات تعديل. قبل أن تقارن المجموعات، قارن الساعات في كل مرحلة. رقمان بُنيا على افتراضات مختلفة لا يمكن مقارنته مهما بدا دقيقين على الورق. وعرض يرفض تقسيم الساعات حسب المراحل لم يقدّر العمل بعد، إنما قدّر ما ستقبله. وإن طُلب منك تسعير الساعة الواحدة قبل تحديد النطاق، فاعتبره مؤشراً على أن هذا التقدير سيُراجَع أكثر من مرّة قبل أن يستقرّ.

[حاسبة التكلفة](/ar/tools/cost-calculator/) تنفّذ الحساب نفسه علناً، فالنطاق الذي تحمله إلى اجتماعك نطاق تستطيع الدفاع عنه لا رقماً سُلِّم إليك.

## ما حالات الفشل الشائعة، وما الذي يكلّفه كل منها؟

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

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

- **حالة نفسية بدل قائمة** — الكلفة: إعادة بناء الميزات حين يظهر المتطلب الحقيقي.
- **لا مالك للمحتوى** — الكلفة: تأجيل الإطلاق حتى يلحق الكتّاب بالبنية.
- **لا صاحب قرار واحد** — الكلفة: جولات تصميم مكرّرة واعتمادات معلّقة.
- **تصميم قبل نموذج البيانات** — الكلفة: إعادة كتابة القوالب بعد تحديد الحقول.
- **إطلاق بلا تمرين** — الكلفة: روابط مكسورة وقياسات ضائعة بلا استرجاع.

## ما الأسئلة التي يجب أن تطرحها على المورد قبل التوقيع؟

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

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

- **الملكية الآن** — المستودع والاستضافة والنطاق باسم من اليوم؟
- **سعر التعديل** — ما الذي استُثنى، وكيف يُسعَّر التعديل؟
- **نصيبكم** — من يكتب المحتوى ويعتمده ومتى؟
- **تسليم مشابه** — ما الذي سلّموا من شكل وعمق مقاربين؟
- **بعد الإطلاق** — أيّ مراقبة وتحديثات مشمولة وما الذي يُضاف ثمنه؟

## ما أكثر ما يسأله المشترون عن تطوير الويب؟

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

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

**كم يستغرق مشروع تطوير الويب؟** المدة تتبع الساعات الملتزم بها لا عدد الصفحات. اقسم ساعات كل مرحلة على الساعات الأسبوعية التي يخصّصها الفريق فعلياً، ثم أضف إدخال المحتوى والاختبار وتمرين الإطلاق إن حذفها العرض.

**هل أحتاج إلى تطوير مخصص أم يكفي ووردبريس؟** نظام إدارة المحتوى أسرع وأرخص في الصيانة حين يكون الموقع نصوصاً وصوراً في معظمه. والكود المخصص تُبرر كلفته حين يكون الأداء أو عمق التكامل مذكوراً في الموجز.

**كم تكلفة موقع على الويب؟** لا رقم صادق قبل أن يستقرّ النطاق. السعر يعود إلى ساعات كل مرحلة، والساعات تعود إلى النطاق والتكامل والمحتوى وسلاسل الاعتماد. احسب النطاق أنت بـ[حاسبة التكلفة](/ar/tools/cost-calculator/) قبل قراءة مجموع غيرك.

**لمن ملكية الموقع وكوده بعد الإطلاق؟** من يملك الحسابات والمستودع والنطاق يتحكّم في الموقع. اتفقوا على ذلك كتابياً قبل الإطلاق، وسمِّ من يتولّى التحديثات؛ [دليل الصيانة والأمان](/ar/blog/website-maintenance-security-guide-2026/) يغطّي هذا الروتين، وصفحة [خدمات تطوير الويب](/ar/services/web-development/) تسرد مراحل المشروع.

---
*WebABC Agency: https://webabc.ir/ar/blog/web-development-guide-2026/*