كيف تُقدّر تكلفة ومدة المشروع البرمجي قبل طلب عرض السعر؟
Project Estimation · Cost · Schedule عندما تسأل شركة تطوير «كم يكلف التطبيق وكم يستغرق؟» قبل تحديد ما سيُبنى، فأنت تطلب رقمًا قبل تعريف المسألة. التقدير الجيد ليس سعرًا سريعًا؛ هو نموذج يربط نطاق العمل بالجهد، الفريق، الاعتماديات، الاختبارات، المخاطر…
Project Estimation · Cost · Schedule
عندما تسأل شركة تطوير «كم يكلف التطبيق وكم يستغرق؟» قبل تحديد ما سيُبنى، فأنت تطلب رقمًا قبل تعريف المسألة. التقدير الجيد ليس سعرًا سريعًا؛ هو نموذج يربط نطاق العمل بالجهد، الفريق، الاعتماديات، الاختبارات، المخاطر والجدول. وكلما زادت المعلومات الحقيقية، ضاق نطاق عدم اليقين.
ماذا ستخرج به
- الفرق بين Effort وDuration وPrice ولماذا الخلط بينها يفسد مقارنة عروض الأسعار.
- ما المعلومات التي يحتاجها الفريق قبل تقديم تقدير يمكن الدفاع عنه.
- كيف يدخل التصميم والـBackend والتكامل والـQA والنشر ضمن الجهد الحقيقي.
- كيف تستخدم Range وافتراضات واضحة بدل تاريخ نهائي زائف الدقة.
- Checklist عملية لمقارنة عرضين حتى لو كان أحدهما أرخص بكثير من الآخر.
الإجابة المباشرة: كيف تُقدّر تكلفة ومدة المشروع البرمجي؟
ابدأ بتحديد Scope قابل للفهم، ثم قسّمه إلى Work Packages أو Features أصغر، وقدّر جهد كل جزء بمشاركة الأشخاص الذين سينفذون التصميم والتطوير والاختبار والنشر. بعد ذلك رتّب الاعتماديات، قدرة الفريق على العمل بالتوازي، المخاطر والافتراضات، ثم حوّل الجهد إلى Schedule وتكلفة.
GAO تضع ضمن التقدير الموثوق: الغرض والنطاق والجدول، الوصف التقني، Work Breakdown Structure، الافتراضات، البيانات، منهج التقدير، تحليل الحساسية والمخاطر، توثيق النتائج وتحديث التقديرات بالتكاليف الفعلية. [1]
Effort ≠ Duration ≠ Price
هذه أهم ثلاثة مصطلحات في المقال. مشروع يحتاج 100 يوم عمل بشري لا يعني بالضرورة أنه ينتهي في 100 يوم تقويمي، ولا يعني أن سعره يساوي «100 × سعر المبرمج».
الجهد
حجم العمل المطلوب من التصميم والتطوير والاختبار والتنسيق وغيرها. يمكن التعبير عنه بساعات أو أيام عمل أو Relative Estimates.
المدة
الوقت التقويمي حتى التسليم، ويتأثر بالاعتماديات، التوازي، توفر الأشخاص، الموافقات وإعادة العمل.
السعر
النموذج التجاري للتنفيذ: جهد الفريق، أسعار الأدوار، خدمات خارجية، إدارة، مخاطرة ونوع العقد.
GAO توضح أن الجدول الموثوق يربط الأنشطة واعتمادياتها، وأن تأخير Activity على المسار الحرج قد يؤثر في موعد البرنامج وتكلفته. [2]
قبل التقدير: ما الذي يجب أن تعرفه عن المشروع؟
- من هم المستخدمون والأدوار والصلاحيات؟
- ما الرحلات الأساسية التي يجب أن تعمل في الإصدار الأول؟
- هل يوجد تطبيق جوال، Web، Admin Panel أو أكثر من واجهة؟
- ما الـBackend والـAPIs المطلوبة؟
- ما الأنظمة الخارجية التي يجب التكامل معها؟
- هل توجد بيانات قديمة تحتاج Migration أو تنظيفًا؟
- ما متطلبات الدفع، الرسائل، الخرائط، الملفات أو الإشعارات؟
- ما متطلبات الأداء، الأمن، الخصوصية أو التدقيق؟
- ما المتصفحات والمنصات والإصدارات المستهدفة؟
- ما الذي يعني Done؟ ومن يعتمد التصميم والوظائف؟
لو هذه الأسئلة غير محسومة، لا يعني أن المشروع لا يمكن تقديره؛ يعني أن التقدير يجب أن يكون Range أوسع أو أن تسبق التنفيذ مرحلة Discovery لتقليل المجهول.
إذا لم توثّق احتياجك بعد، راجع دليل كتابة وثيقة متطلبات لمشروعك الرقمي قبل طلب مقارنة نهائية بين الأسعار.
قسّم المشروع قبل أن تقدّره
التقدير على مستوى «تطبيق توصيل» أو «منصة حجز» واسع جدًا. GAO تعتبر Work Breakdown Structure جزءًا أساسيًا من التقدير الموثوق، لأن الرقم النهائي يجب أن يكون مبنيًا على عناصر عمل أصغر يمكن تحليلها وتوثيقها. [1]
من يجب أن يشارك في التقدير؟
Atlassian تشدد على أن Estimation في البرمجيات عمل جماعي، وأن المطورين والمصممين والمختبرين ومن يتعامل مع النشر يرون أجزاء مختلفة من العمل والمخاطر. استبعاد أحد هذه الأدوار قد يخفي جهدًا مهمًا. [3]
| الدور | ما الذي قد يكشفه أثناء التقدير؟ |
|---|---|
| Product / BA | نطاق الرحلات، قواعد العمل، الحالات الاستثنائية والقبول. |
| UX/UI | عدد الحالات والشاشات، Design System، Responsive behavior والـStates. |
| Frontend / Mobile | تعقيد الواجهة، Offline behavior، Device APIs، تعدد المنصات. |
| Backend | Business Logic، البيانات، الصلاحيات، APIs، Jobs والتكاملات. |
| QA | حالات الاختبار، Regression، الأجهزة/المتصفحات، Test Data وإعادة الاختبار. |
| DevOps / Release | Environments، CI/CD، Cloud، Domains، monitoring والنشر. |
Story Points أم ساعات؟
Atlassian تعرف Story Points كتقدير نسبي للجهد يأخذ حجم العمل والتعقيد والمخاطر أو عدم اليقين في الاعتبار، ولا تعتبرها تحويلًا ثابتًا إلى ساعات. [3]
«كل Story Point = 6 ساعات، إذن السعر محسوم.»
Story Points معيار نسبي خاص بطريقة معايرة الفريق، وتحويلها مباشرة إلى ساعات ثابتة يخلق دقة زائفة.
«نستخدم Relative Estimate، ثم تاريخ الفريق الفعلي وVelocity/Throughput لتوقع ما يمكن إنجازه.»
التوقع يتحسن عندما يكون لدى الفريق بيانات سابقة مشابهة ويعيد معايرة تقديراته.
Atlassian توصي كذلك بمراجعة تقديرات سابقة والتعلم من العمل المكتمل لتحسين التوقعات المستقبلية. [3]
لماذا عرض السعر المبكر يكون Range وليس رقمًا نهائيًا؟
في مرحلة الفكرة، كثير من التفاصيل لم يُحسم. بدل إخفاء عدم اليقين داخل رقم واحد، الأفضل أن يكون التقدير Range مع الافتراضات التي قد تحركه. GAO توصي بتحليل المخاطر وعدم اليقين، واستخدام نطاقات مثل Best Case وMost Likely وWorst Case عند الحاجة. [4]
| مستوى المعرفة | شكل التقدير الأفضل | ما الذي تحتاجه لتضييقه؟ |
|---|---|---|
| فكرة عامة | Range واسع / ROM | Discovery، المستخدمون، Scope وأهم التكاملات. |
| متطلبات أولية | Range أقل اتساعًا | User Flows، Acceptance Criteria، Architecture assumptions. |
| Backlog واضح وتصميمات أساسية | Estimate تفصيلي نسبيًا | تفكيك العمل ومراجعة الفريق للمخاطر والاعتماديات. |
| أثناء التنفيذ | Forecast محدث | Actuals، Velocity/Throughput، تغييرات Scope والمخاطر الجديدة. |
التسميات في الجدول إطار تحريري عملي وليست Standard إلزاميًا لكل شركة.
ما الذي يغيّر مدة المشروع حتى لو لم يتغير عدد Features؟
Dependencies
قد ينتظر Mobile API، أو تنتظر QA اكتمال Flow، أو ينتظر التكامل موافقة طرف خارجي. الجهد لا يساوي مدة تقويمية.
Team Availability
وجود أربعة أشخاص على المشروع لا يعني أربع وحدات إنتاج متساوية؛ الأدوار مختلفة وقد يعمل بعضهم جزئيًا.
Feedback & Approvals
التصميم أو المتطلبات قد تتوقف بانتظار قرار Business. زمن الانتظار يجب أن يظهر كDependency لا كـ«بطء برمجة».
Unknown Integrations
API خارجية غير موثقة، Sandbox ناقص أو صلاحيات متأخرة قد تضيف بحثًا وتجربة وإعادة عمل.
QA & Rework
GAO تحذر من تجاهل الوقت والجهد اللازمين لإصلاح العيوب وإعادة الاختبار، وتعتبر جودة المتطلبات والاختبار من عوامل التكلفة والجدول.[4]
Scope Change
إضافة Feature تغير أكثر من عدد الساعات؛ قد تغير Architecture أو تصميمًا تم اعتماده أو Test Cases أو ترتيب Release.
لماذا لا يمكن ضغط الجدول بمجرد إضافة مبرمجين؟
بعض الأعمال يمكن تنفيذها بالتوازي، وبعضها لا. Backend وFrontend قد يتقدمان مع Contract واضح، لكن Discovery يجب أن يحسم أجزاء قبل التصميم، وبعض الاختبارات لا تبدأ قبل وجود Build قابلة للاختبار. كما أن إضافة أفراد جدد تحتاج Onboarding وتنسيقًا وقد لا تعالج النشاط الموجود على Critical Path.
GAO تربط موثوقية الجدول بتسلسل الأنشطة والاعتماديات والمسار الحرج، وتوضح أن Schedule Risk Analysis يدرس كيف تؤثر الانزلاقات في الأنشطة على تاريخ النهاية. [2]
ما الذي يدخل في تكلفة المشروع غير البرمجة؟
| البند | هل هو دائمًا موجود؟ | لماذا يجب أن يظهر في العرض؟ |
|---|---|---|
| Discovery / Analysis | حسب المشروع | يقلل المجهول ويثبت Scope وقرارات المنتج. |
| UI/UX | حسب حالة التصميم | الشاشات والـStates والتجربة جزء من العمل. |
| Development | نعم غالبًا | Frontend/Mobile/Backend حسب Architecture. |
| QA | يجب التخطيط له | اختبار الوظائف والتكامل وإعادة اختبار الإصلاحات. |
| Project / Product Management | حسب نموذج الفريق | تنسيق Scope، قرارات، اجتماعات وتسليمات. |
| Cloud / SaaS / Licenses | حسب الحل | قد تكون Pass-through أو على حساب العميل. |
| Data Migration | إذا يوجد نظام سابق | Mapping، cleaning، scripts، validation وcutover. |
| Deployment | نعم عند الإطلاق | Environments، CI/CD، إعداد Production والمتاجر عند الحاجة. |
| Support / Maintenance | بعد الإطلاق | يجب فصله عن تكلفة بناء الإصدار الأول إذا لم يكن ضمن العرض. |
مثال افتراضي: لماذا «60 يوم جهد» لا تعني «شهرين مدة»؟
لنفترض مثالًا تعليميًا فقط أن Backlog بعد التفكيك يساوي 60 Person-Days من الجهد بين تصميم وFrontend وBackend وQA. هذا ليس Benchmark لسوق ولا تقديرًا لمشروع حقيقي.
| العمل | جهد افتراضي | هل يمكن أن يعمل بالتوازي؟ |
|---|---|---|
| Flows + UI/UX | 10 أيام عمل | جزئيًا؛ يحتاج اعتمادًا قبل بعض التطوير. |
| Backend | 20 يوم عمل | يمكن بالتوازي مع الواجهة بعد وضوح العقود. |
| Frontend / App | 20 يوم عمل | جزئيًا بالتوازي مع Backend. |
| QA + Rework | 10 أيام عمل | يبدأ تدريجيًا لكن بعض E2E ينتظر تكامل الأجزاء. |
لو جمعت الجهد تحصل على 60 يوم عمل بشري، لكن المدة التقويمية تحتاج Schedule: من يبدأ أولًا؟ من ينتظر من؟ هل الأفراد متاحون Full-time؟ متى يصل Feedback؟ وهل هناك Buffer للمخاطر؟ لذلك قسمة 60 على عدد أفراد الفريق ليست طريقة موثوقة لاستخراج تاريخ النهاية.
كيف تحسب السعر من التقدير؟
طريقة التسعير تعتمد على نموذج العقد. بعض الشركات تعمل Fixed Price لنطاق محدد، وأخرى Time & Materials، أو Sprint/Team-based. لا يوجد نموذج أفضل في كل الحالات.
Fixed Price
يحتاج Scope وAssumptions وChange Process واضحين؛ عدم الوضوح يتحول غالبًا إلى Risk داخل السعر أو خلاف لاحق.
Time & Materials
السعر يتبع الجهد الفعلي ومعدل الأدوار، ويحتاج شفافية في Tracking وأولويات مستمرة.
Dedicated / Sprint Team
تشتري Capacity لفترة، بينما يتغير ترتيب الـBacklog حسب القيمة والمعلومات الجديدة.
مهما كان النموذج، اطلب أن تعرف: ما الذي يدخل في السعر، وما الذي لا يدخل، وما الافتراضات التي بُني عليها؟
كيف تقارن عرضي سعر بصورة عادلة؟
- هل العرضان يبنيان Scope نفسه فعلًا؟
- هل أحدهما يشمل التصميم والآخر يفترض أنه جاهز؟
- هل Backend وAdmin Panel والتكاملات ضمن الاثنين؟
- هل QA وRegression وإصلاح Bugs قبل الإطلاق مشمولة؟
- هل Data Migration ضمن النطاق؟
- هل Cloud والخدمات الخارجية Pass-through أم ضمن السعر؟
- ما Team Composition ومستوى الأدوار؟
- ما الافتراضات والاستثناءات Exclusions؟
- كيف تُدار Change Requests؟
- هل الجدول مرتبط بـMilestones وDependencies أم مجرد تاريخ؟
- ما الدعم بعد التسليم؟
- من يملك الحسابات والـRepository والـSource Code حسب الاتفاق؟
بعد توحيد نطاق المشروع وفهم ما يشمله السعر، لا تتوقف عند سؤال «كم سيكلف؟». اربط التكلفة بالقيمة المتوقعة من المشروع من خلال حساب العائد على الاستثمار التقني قبل طلب ميزانية المشروع، حتى تقارن الاستثمار بالتوفير أو القدرة التشغيلية أو الإيراد الإضافي الذي يفترض أن يخلقه.
بعد معرفة التكلفة: لا تنسَ سؤال القيمة
عرض أقل سعرًا ليس بالضرورة الاستثمار الأفضل، وعرض أعلى ليس دليل جودة. بعد أن توحد Scope والمخاطر وما يشمله كل عرض، قارن الاستثمار بالقيمة التي يفترض أن يخلقها المشروع: خفض تكلفة، Capacity، Revenue Contribution، تقليل مخاطر أو قدرة تشغيلية جديدة.
ولو كنت لا تزال غير متأكد هل يجب أصلًا بناء Custom Software أم شراء حل قائم، احسم هذا السؤال قبل مقارنة عروض التطوير؛ لأنك قد تكون تقارن حلولًا لمشكلة كان يمكن حلها بطريقة أخرى.
علامات تحذير في تقدير تكلفة ومدة المشروع
«التطبيق كله سينتهي في 30 يومًا»
بدون Scope، Team، Dependencies أو Assumptions موثقة، الرقم أقرب إلى وعد تسويقي منه إلى Estimate.
«هذا Range مبني على Scope الحالي، وهذه العناصر التي قد تغيره.»
يعطيك أساسًا لتحديث القرار بدل التمسك برقم قديم بعد تغير المعلومات.
سعر نهائي قبل فهم Scope
قد يكون Template Pricing لمنتج متكرر، لكن في مشروع Custom مع متطلبات غير معروفة يحتاج تفسيرًا واضحًا.
لا يوجد Breakdown
لا تعرف أين توجد التكلفة أو ما الذي يحدث عند حذف Feature.
الـQA «ضمنيًا» بلا جهد
الاختبار وإعادة الاختبار عمل، وتجاهله يجعل الجدول أكثر تفاؤلًا من الواقع.
لا توجد Assumptions
إذا كانت كل الافتراضات في رأس البائع، ستظهر لاحقًا كخلاف على ما كان «مفهومًا».
لا يوجد Change Process
Fixed Price مع Scope متحرك بدون آلية Change Request يجمع أخطر عنصرين في عقد واحد.
ما الذي يجب أن تستلمه مع Estimate محترمة؟
- Scope أو Backlog أو قائمة Deliverables مرتبطة بالتقدير.
- In Scope / Out of Scope.
- Assumptions واضحة.
- Dependencies على العميل أو Vendors خارجيين.
- Team Roles أو نموذج Capacity.
- طريقة التقدير المستخدمة على الأقل بصورة مفهومة.
- جدول أو Milestones وليس تاريخ نهاية فقط.
- Risk items الرئيسية.
- الخدمات والتكاليف الخارجية إن كانت معروفة.
- طريقة التعامل مع Change Requests.
- طريقة تحديث Forecast بعد بدء العمل.
أسئلة شائعة
هل يمكن معرفة تكلفة التطبيق من عدد الشاشات فقط؟
عدد الشاشات يعطي إشارة محدودة. شاشة واحدة قد تكون عرضًا بسيطًا، أو Workflow تحتوي صلاحيات وتكاملات وحالات متعددة. التقدير يحتاج فهم السلوك والـBackend والبيانات والاختبارات وليس UI count فقط.
هل عدد المبرمجين يقلل المدة دائمًا؟
لا. الأعمال القابلة للتوازي قد تستفيد، لكن Dependencies وCritical Path وOnboarding والتنسيق تحد من أثر إضافة الأشخاص. الجهد الكلي والمدة التقويمية مفهومان مختلفان.[2]
لماذا شركة تعطي Range وأخرى تعطي سعرًا ثابتًا؟
قد يكون لدى الثانية Scope ثابت ومكرر، أو تكون قد تحملت المخاطرة داخل السعر، أو ببساطة تقدم دقة زائفة. اسأل عن الافتراضات والـBreakdown قبل الحكم أن الرقم الثابت أفضل.
هل Story Points تحدد سعر المشروع؟
Story Points تقدير نسبي للجهد وليست عملة مالية أو عدد ساعات ثابتًا. يمكن استخدامها في Forecast عندما يكون الفريق معايرًا ولديه بيانات Velocity مناسبة.[3]
كم Buffer يجب إضافته للمشروع؟
لا توجد نسبة واحدة تصلح لكل مشروع. الأفضل تحديد المخاطر والافتراضات، تقدير أثر عدم اليقين، واستخدام Range أو Risk Analysis بدل إضافة نسبة عشوائية مخفية.
متى أطلب Fixed Price؟
يكون أسهل للدفاع عنه عندما يكون Scope واضحًا نسبيًا، والـAcceptance Criteria والافتراضات وآلية التغيير محددة. إذا كان Discovery نفسه جزءًا كبيرًا من العمل، فقد يكون تثبيت السعر مبكرًا أقل واقعية.
تريد عرض سعر يمكن مقارنته بدل رقم سريع؟
ابدأ بنطاق واضح: المستخدمون، الرحلات، الأنظمة، التكاملات وما الذي يدخل في الإصدار الأول. بعدها يمكن تحويل الـScope إلى Breakdown تقني، تقدير جهد، جدول ومخاطر بصورة أوضح.
ناقش نطاق مشروعك مع SpinesTech استعرض خدمات SpinesTechالمصادر والمراجع
- U.S. Government Accountability Office (GAO) — Cost Estimating and Assessment Guide. خطوات بناء تقدير تكلفة موثوق، WBS، الافتراضات، المخاطر وتحديث التقدير بالبيانات الفعلية.
- U.S. GAO — Schedule Assessment Guide. الاعتماديات، المسار الحرج، موثوقية الجدول وSchedule Risk.
- Atlassian — Story points and estimation. التقدير النسبي، مشاركة الفريق، المخاطر وعدم اليقين والتعلم من التقديرات السابقة.
- U.S. GAO — Cost Estimating and Assessment Guide — software estimation sections. مخاطر البرمجيات، المتطلبات غير المكتملة، الاختبار وإعادة العمل، ونطاقات عدم اليقين.
- Atlassian — Project estimation methods and best practices. توثيق الافتراضات وتحديث التقديرات وفق التقدم والتحديات.
