يستغرق تطوير برنامج مخصص لشركة في الغالب من شهرين إلى ستة أشهر، وقد يتجاوز ذلك في الأنظمة المؤسسية الكبيرة التي تُسلَّم على مراحل. ففي مشاريعنا في HBS يأخذ النظام بوحدة أو وحدتين عادة من شهرين إلى ثلاثة أشهر، والنظام متعدد الوحدات والتكاملات من أربعة إلى ستة أشهر. ولا يحدد المدة عدد الشاشات وحده، بل وضوح المتطلبات وحجم البيانات المرحَّلة وعدد التكاملات وسرعة اتخاذ القرار داخل شركتك.
في هذا الدليل نعرض المدة المعتادة حسب حجم المشروع، ثم نشرح كل مرحلة وما تستلمه فيها، والأسباب التي تطيل الجدول الزمني، وكيف تختصره دون أن تخسر الجودة، ونختم بقائمة لما يجب أن تجهزه شركتك قبل البدء.
كم يستغرق تطوير برنامج مخصص للشركات فعلًا؟
أدق إجابة تبدأ من حجم النظام. يلخص هذا الجدول المدد المعتادة في مشاريع HBS كما نشرناها في دليل الأسعار، وهي مدد تقديرية تتأكد بعد جلسة الاكتشاف وفهم عملياتك:
| حجم النظام | ما يشمله عادة | المدة المعتادة |
|---|---|---|
| نظام البداية | وحدة أو وحدتان أساسيتان مثل المبيعات والعملاء أو المخزون والمشتريات | من شهرين إلى ثلاثة أشهر |
| نظام النمو | عدة وحدات مع تكاملات مع أنظمة أخرى وتقارير للإدارة | من أربعة إلى ستة أشهر |
| نظام مؤسسي | منصة متكاملة بأدوار متعددة وتكاملات كثيرة ومنطق عمل معقد | أكثر من ستة أشهر على مراحل |
ولمعرفة الأسعار التي ترافق كل حجم من هذه الأحجام وما يدخل فيها، راجع دليلنا عن تكلفة برمجة نظام ERP أو CRM مخصص في 2026. وإذا لم تحسم بعد هل تحتاج إلى برمجة نظام أصلًا، فابدأ بمقارنتنا بين برمجة نظام خاص وشراء برنامج جاهز.
ما مراحل تطوير برنامج مخصص وماذا تستلم في كل مرحلة؟
المراحل متشابهة في أغلب المشاريع، لكن وزن كل مرحلة يختلف من مشروع إلى آخر. والمهم أن تعرف ما الذي يُنتَج في كل مرحلة وما الذي يحدد طولها:
| المرحلة | ما يحدث فيها | ما تستلمه وتعتمده | ما يحدد مدتها |
|---|---|---|---|
| الاكتشاف وتحليل العمليات | جلسات مع المسؤولين عن كل عملية لفهم ما يحدث فعلًا | نطاق مكتوب للمرحلة الأولى وخريطة للعمليات | عدد الأقسام المشاركة وسرعة ترتيب الجلسات |
| تصميم الواجهات والنموذج الأولي | رسم الشاشات الأساسية ورحلة المستخدم بالعربية والإنجليزية | نموذج أولي قابل للتجربة تعتمده قبل البرمجة | عدد الأدوار وعدد جولات الملاحظات |
| التصميم المعماري وخطة البيانات | تحديد بنية النظام وقاعدة البيانات والصلاحيات وطريقة الربط | وثيقة معمارية وخطة لترحيل البيانات | عدد التكاملات وحساسية البيانات |
| التطوير على دورات قصيرة | بناء الوحدات على دورات من أسبوعين مع عرض ما اكتمل في نهاية كل دورة | أجزاء تعمل فعلًا تراجعها وتعلّق عليها | حجم النطاق وعدد التغييرات أثناء البناء |
| ترحيل البيانات والتكاملات | نقل بياناتك القديمة وربط النظام بالفاتورة الإلكترونية وبوابات الدفع وغيرها | بيانات منقولة ومراجَعة وتكاملات مختبرة | جودة البيانات القديمة وجاهزية الجهات الخارجية |
| اختبار القبول مع فريقك | يجرب موظفوك النظام على حالات حقيقية من عملهم | قائمة ملاحظات مغلقة وموافقة على الإطلاق | توفر المختبِرين من فريقك وعدد الملاحظات |
| الإطلاق والتدريب | تشغيل النظام وتدريب كل دور على عمله اليومي | نظام في التشغيل الفعلي ومواد تدريب | عدد المستخدمين والفروع |
مرحلة الاكتشاف هي الأكثر تعرضًا للاختصار، وهي آخر مرحلة يصح اختصارها. فدليل الخدمات الرقمية في الحكومة البريطانية يعدّ مدة تتراوح بين أربعة وثمانية أسابيع أمرًا معتادًا لمرحلة الاكتشاف في الخدمات العامة، ويرى أن التوقف بعدها ليس فشلًا إذا أظهر البحث أن هذا هو القرار الصحيح. أما مشروع شركتك فقد يحتاج وقتًا أقل إذا كانت عملياتك موثقة وصاحب القرار متاحًا.
وفي مرحلة التطوير يعمل أغلب الفرق بدورات قصيرة ثابتة الطول، ويحدد دليل Scrum طول الدورة بشهر واحد أو أقل. والفائدة لك أنك ترى أجزاء تعمل كل بضعة أسابيع بدلًا من انتظار موعد تسليم واحد في نهاية المشروع.
ما الذي يطيل مدة المشروع أكثر من المتوقع؟
نادرًا ما يتأخر المشروع بسبب البرمجة نفسها. أغلب التأخير يأتي من هذه الأسباب:
- متطلبات غير مكتوبة. حين تبقى القواعد في رؤوس الموظفين يكتشفها الفريق أثناء البناء، فيعيد بناء ما بناه.
- تغيير النطاق أثناء التطوير. كل ميزة جديدة تُضاف في المنتصف تؤجل ما بعدها. سجّلها في قائمة للمرحلة التالية بدل أن تدخلها فورًا.
- بيانات قديمة غير منظمة. جداول Excel بأسماء مكررة وأكواد مختلفة للصنف نفسه تحتاج تنظيفًا قبل نقلها، وهذا وقت لا يظهر في أغلب العروض.
- تكاملات مع جهات خارجية. الربط مع منظومة الفاتورة الإلكترونية المصرية أو بوابات الدفع يعتمد على تسجيل حساباتك وبيئات الاختبار لديها، لا على فريق التطوير وحده.
- بطء الموافقات داخل شركتك. سؤال ينتظر ردًا أسبوعًا كاملًا يوقف جزءًا من العمل أسبوعًا كاملًا.
- غياب صاحب قرار واحد. حين يعطي مديران رأيين مختلفين في الشاشة نفسها، يتحول الأسبوع إلى نقاش بدل أن يكون تطويرًا.
هل يمكن تقصير المدة دون التضحية بالجودة؟
نعم، بشرط أن تختصر النطاق لا المراحل. هذه الطرق تقصّر الجدول الزمني فعلًا:
- ابدأ بأكثر عملية تستنزف وقتك. مرحلة أولى صغيرة تعمل خلال أسابيع أفضل من نظام كامل ينتظر شهورًا، ثم تضيف الوحدات بعد أن ترى النتيجة.
- اعمل على البيانات بالتوازي. نظّف بياناتك القديمة أثناء مرحلة التصميم، لا بعد انتهاء التطوير.
- استخدم مكونات جاهزة لما ليس مميزًا. تسجيل الدخول والدفع والإشعارات لا تحتاج إلى بنائها من الصفر في كل مشروع.
- حدد مواعيد ثابتة للمراجعة. اجتماع قصير في نهاية كل دورة يحسم الأسئلة المفتوحة قبل أن تتراكم.
- استفد من أدوات التطوير الحديثة. التطوير بمساعدة الذكاء الاصطناعي يسرّع أجزاء من العمل، وقد شرحنا حدوده في مقالنا عن البرمجة التقليدية مقابل التطوير بمساعدة الذكاء الاصطناعي.
أما ما لا يقصّر المدة فهو حذف الاختبار أو تخطي الاكتشاف أو إضافة مطورين جدد في منتصف المشروع. فهذه الخطوات توفر أيامًا في البداية ثم تكلفك أسابيع من الإصلاح بعد الإطلاق.
ما الذي تجهزه شركتك قبل بدء المشروع؟
جزء كبير من الجدول الزمني في يدك أنت. جهّز هذه البنود قبل الجلسة الأولى:
- صاحب قرار واحد للمشروع. شخص يعتمد الشاشات ويحسم الأولويات ويرد على الأسئلة خلال أيام قليلة.
- وصف مكتوب لطريقة العمل الحالية. النماذج الورقية والتقارير التي تُطبع اليوم وخطوات الموافقة كما تحدث فعلًا.
- عينة حقيقية من بياناتك. ملف العملاء أو الأصناف كما هو، حتى يقدّر الفريق وقت التنظيف والترحيل بدقة.
- قائمة بالأنظمة التي يجب الربط معها. المحاسبة والفاتورة الإلكترونية وبوابات الدفع والمتجر وواتساب، مع من يملك بيانات الدخول لكل منها.
- تعريف النجاح لكل مرحلة. مثل الوقت اللازم لإصدار عرض سعر أو عدد الطلبات التي تُتابَع يدويًا.
- أسماء من سيختبر النظام من فريقك. مع وقت محجوز لهم في جدولهم خلال مرحلة الاختبار.
- خطة للتدريب والإطلاق. متى يتوقف النظام القديم، ومن يتدرب أولًا، وكيف ستتعامل مع الأسابيع الأولى بعد التشغيل.
هل ينتهي المشروع يوم الإطلاق؟
لا. يوم الإطلاق هو بداية الاستخدام الحقيقي، وأول أسابيع التشغيل تكشف دائمًا حالات لم تظهر في الاختبار: صلاحية ناقصة لموظف في فرع، أو تقرير يحتاج إلى عمود إضافي، أو خطوة موافقة يتجاوزها الفريق. لذلك احسب في جدولك فترة استقرار بعد الإطلاق يكون فيها فريق التطوير قريبًا ويستجيب بسرعة.
وبعدها يبدأ إيقاع مختلف: صيانة وتحديثات أمنية بعقد دعم واضح، ثم مرحلة ثانية تُبنى على ما تعلمته من الاستخدام الفعلي لا على التوقعات. وكثير من الشركات تكتشف أن أهم ميزات المرحلة الثانية لم تكن في قائمتها الأولى أصلًا، وهذا سبب إضافي لأن تبدأ بنطاق صغير وتترك مساحة لما ستتعلمه.
كيف تقرأ الجدول الزمني في عرض السعر؟
الجدول الزمني في العرض يكشف الكثير عن الشركة التي كتبته. انتبه إلى هذه العلامات:
- موعد تسليم واحد دون مراحل وسيطة. يعني أنك لن ترى شيئًا يعمل حتى النهاية، ولن تكتشف سوء الفهم إلا متأخرًا.
- لا وقت لترحيل البيانات أو التدريب. هاتان مرحلتان حقيقيتان، وغيابهما من الجدول لا يلغيهما بل يؤجلهما إلى ما بعد الموعد.
- مدة محددة قبل أي جلسة اكتشاف. الرقم الذي يُعطى قبل فهم عملياتك تخمين، مهما بدا دقيقًا.
- غياب مسؤولياتك أنت. الجدول الجيد يذكر ما تحتاجه الشركة منك ومتى، مثل البيانات والموافقات ووقت المختبِرين.
ولتقييم الشركة نفسها وليس جدولها فقط، راجع ثمانية معايير لاختيار شريك تطوير البرمجيات.
كيف ندير الجدول الزمني في HBS؟
نبدأ في HBS بمرحلة اكتشاف نفهم فيها عملياتك كما تحدث فعلًا، ثم نصمم البنية المعمارية قبل كتابة أي كود، ونطور على دورات من أسبوعين تعرض في نهاية كل منها ما اكتمل لتراجعه وتعلّق عليه. ونقسّم المشاريع الكبيرة إلى مراحل، لكل مرحلة نطاق مكتوب ومقياس نجاح، ثم نواصل الدعم والتطوير بعد التسليم.
ونحسب التدريب ضمن الجدول الزمني لا بعده. فحين بنينا لوحة التحكم LDY CMS لشركة لبيب دميان يوسف وشركاه لتحل محل نظام جاهز كانت تعمل عليه، كان جزء من مرحلة الإطلاق تدريب الفريق حضوريًا في مقر الشركة وعبر ويبينارات مباشرة، شرحنا فيها لكل دور عمله اليومي على النظام. وأعددنا فيديوهات شرح قصيرة بالعربية لكل جزء في النظام، ودليلًا لطريقة استخدام كل شاشة، حتى يبقى الفريق قادرًا على الرجوع إليها بعد التشغيل.
لو عايز تعرف مشروعك هياخد قد إيه بالظبط، احكيلنا عن طريقة شغلك والأنظمة اللي عندك دلوقتي. فريقنا هيقعد معاك في جلسة اكتشاف مجانية ويطلعلك جدول زمني واضح بالمراحل، وتقدر تعرف أكتر عن خدمة تطوير الأنظمة والبرامج المخصصة للشركات من HBS.








