آلية التسعير الصحيحة للمشاريع التقنية - ليش الشركة اللي تسعّر بدون ما تفهم مشروعك غير مهنية

"كم ميزانيتك؟" لكن السؤال الحقيقي المفروض يكون مختلف تمامًا:

❓ كيف الشركة قدرت تسعّر مشروعك قبل ما تفهمه أصلًا؟

هنا تبدأ أول إشارة خطر يواجهها كثير من رواد الأعمال وأصحاب الشركات في السعودية.

لأن المشروع التقني مو منتج جاهز على رف تقدر تحط له سعر ثابت خلال مكالمة مدتها خمس دقائق. كل مشروع له نطاق مختلف، وظائف مختلفة، تكاملات مختلفة، وحتى أهداف تجارية مختلفة.

📉 المشكلة أن بعض الشركات تعطيك رقمًا سريعًا من أول اتصال بهدف كسب العميل بأسرع وقت، بينما الواقع أن أي تسعير احترافي يحتاج دراسة حقيقية للمشروع قبل الوصول لأي رقم.

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

⚙️ التسعير المهني لا يبدأ من "كم يكلف التطبيق؟"

بل يبدأ من:

🧠 وش المشكلة اللي يحلها المنتج؟
📊 وش الوظائف المطلوبة فعلًا؟
🏗️ كم جزء يتكون منه النظام؟
🔗 هل يحتاج تكاملات مع بوابات دفع أو خدمات حكومية أو أنظمة خارجية؟
💰 وما تكلفة التشغيل والصيانة بعد الإطلاق؟

لهذا السبب تعتمد الشركات الاحترافية على منهجية واضحة في تسعير المشاريع التقنية (Software Development Pricing) وتقدير تكلفة التطبيقات (Project Estimation) قبل تقديم أي عرض مالي.

وفي السعودية ظهرت شركات Product Studio تساعد رواد الأعمال على تحويل الأفكار إلى منتجات رقمية قابلة للنمو والاستثمار. أحد هذه النماذج هو Glow التي تعمل مع المؤسسين من مرحلة الفكرة حتى إطلاق المنتج، عبر منهجية واضحة تبدأ بالفهم والتحليل قبل التطوير والتنفيذ.

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

ليش الشركة اللي تعطيك سعر من أول اتصال غير مهنية؟

الشركات المبتدئة أو غير المُحترفة تعطيك رقمًا عشوائيًا قبل ما تعرف المتطلبات التفصيلية للمشروع. التسعير المفروض يبدأ بتحليل عميق لنطاق المشروع ووظائفه وطبيعة المستخدمين، لا بتخمين سريع.

على سبيل المثال، Glow تؤكد أن مثل هذه العروض المنخفضة جدًا (مثلاً تطبيق بـ10 آلاف ريال) تعتمد غالبًا على حلول جاهزة أو مبرمجين محدودي الخبرة، مما يؤدي إلى كود غير قابل للتوسع ومشاكل أمنية مستقبلية.

ببساطة: أي عرض سعر مقدم بدون تحري (وضع خطة) هو عرض بناءً على حظ، وغالبًا ما يخفي تكاليف مستقبلية أكبر أو جودة ضعيفة.

الشركات المحترفة تسأل عن المتطلبات بالتفصيل (وظائف النظام، المنصات، الجمهور المستهدف، إلخ) قبل أن تحدد أي رقم.

آلية التسعير المهنية: 5 خطوات قبل أي رقم

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

1. الخطوة 1: فهم النطاق – تحديد أهداف ومواصفات المشروع بالتفصيل.
2. الخطوة 2: تحديد أجزاء النظام – توزيع المشروع إلى مكونات (مثال: تطبيق توصيل يتضمن 3 تطبيقات + 3 لوحات تحكم + موقع تعريفي).
3. الخطوة 3: تقدير ساعات العمل – حساب الوقت اللازم لكل جزء بناءً على الخبرة أو بيانات سابقة.
4. الخطوة 4: تحديد التكاملات الخارجية – حصر كل الخدمات والشركات الأخرى (بوابات دفع، خرائط، خدمات حكومية، إلخ) التي يجب ربطها بالمشروع.
5. الخطوة 5: احتساب البنية التحتية والصيانة – تقدير تكاليف الاستضافة والسيرفرات والصيانة الدورية بعد الإطلاق.

الآن نشرح كل خطوة بالتفصيل:

الخطوة 1: فهم النطاق - وش بالضبط تبغى تبني؟

لازم تبدأ بتحديد نطاق المشروع بدقة. هذا يعني معرفة الوظائف والمزايا المطلوبة بوضوح قبل تسعيرها.

في هذه المرحلة، يجتمع فريق التطوير معك (بمشاركة الـUX/UI إن أمكن) لفهم فكرة المشروع تمامًا: من هم المستخدمون المستهدفون، وما هي مشاكلهم التي يحلها المنتج، وما هي الميزات الرئيسية، وما المخرجات المتوقعة (Wireframes أو وثيقة SRS مثلاً).

هذا يُعرَف بـ«متطلبات المشروع» أو (Project Requirements). حسب خبراء إدارة المشاريع، إجراء تحليل كامل لمتطلبات المشروع يساعد في تحديد نطاق العمل وتقدير التكاليف بدقة.

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

• وثيقة نطاق المشروع (Scope): تحتوي على الوظائف الأساسية والمواصفات الفنية.
• دراسة جدوى تقنية: لتحديد هل تحتاج MVP أو منتج كامل.
• أسئلة استيضاح: عن الجمهور المستهدف، الأجهزة، وKPIs.

الخطوة 2: تحديد أجزاء النظام (مثال: تطبيق توصيل = 3 تطبيقات + 3 لوحات تحكم + موقع تعريفي)

تقسيم المشروع إلى وحدات (نظامية/وظيفية) ضروري لمعرفة حجم كل جزء بشكل منفصل.

بعد فهم النطاق العام، النقطة الثانية هي تفصيل المشروع إلى مكونات. مثلاً، إن كان المشروع تطبيق توصيل، فيكون الجزء الأول تطبيق للمستخدم، الثاني تطبيق للسائق، الثالث للتاجر، بالإضافة إلى لوحات تحكم إدارية (إدارة المطاعم، إدارة الطلبات، إدارة النظام)، وربما موقع إلكتروني تعريفي. هذا ما يُعرف بـWork Breakdown Structure (WBS) في إدارة المشاريع.

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

الفائدة الرئيسية كما يشير دليل إدارة المشاريع Wrike، أن WBS يُربط النطاق بالتكلفة بحيث يعرف مدير المشروع «كم تحتاج الميزانية لكل مرحلة».

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

• هيكلية المشروع (WBS): تنظيم المكونات في هيكل واضح (تطبيقات، Backend، إلخ).
• تعريف الـDeliverables: وضع نقاط تسليم (مثل أول نموذج أولي، أو إطلاق النسخة الأولى).
• تقدير النطاق الثانوي: مثال: تحديد عدد واجهات الدفع، خريطة GPS، نظام إشعارات فورية.

الخطوة 3: تقدير ساعات العمل لكل جزء

احسب الوقت اللازم لكل جزء من المشروع بناءً على خبرتك أو بيانات مشاريع سابقة.

بعد تحديد مكونات المشروع، تأتي مرحلة التقدير الزمني (Work Effort Estimation) لكل جزء. يعتمد التقدير على خبرة فريق التطوير أو مقارنة بوظائف مماثلة تم تنفيذها سابقًا.

مثلاً، بناء واجهة تسجيل الدخول قد يستغرق «X» ساعات تطوير، وإنشاء نظام تتبع GPS قد يحتاج «Y» ساعات إضافية للاختبار والتكامل.

هناك أساليب مختلفة مثل Story Points أو Planning Poker في البيئات الأجايل، ولكن المبدأ نفسه: كل ميزة يُترجم وقتها إلى تكلفة (ساعات × أجر الساعة). هذا التقدير يضمن أن تأخذ في الحسبان كل طورة (Developing, Testing, Debugging) لكل ميزة.

مثلًا: تطوير تطبيق بسيط قد يستغرق بضعة أسابيع، أما تطبيق توصيل معقد فقد يستغرق شهورًا.

حساب ساعات العمل هو جوهر التسعير بالدولار/الريال (التسعير بالساعة)، والتقديرات الواقعية توفر شفافية لعميلك حول كيفية وصولك للسعر النهائي.

الخطوة 4: تحديد التكاملات الخارجية المطلوبة

عزِّل كل الخدمات الخارجية التي يحتاجها مشروعك واقدر جهد الربط معها.

الكثير من المشاريع التقنية اليوم تحتاج دمج خدمات خارجية ليست مضمّنة في التطوير الأساسي. مثلاً، قد تحتاج ربط التطبيق ببوابات دفع إلكترونية أو أنظمة مراسلة SMS أو خرائط تحديد المواقع أو خدمات حكومية.

كل تكامل من هذه التكاملات يتطلب وقت تطوير إضافي وغالبًا تراخيص أو عمولات مالية. على سبيل المثال في السعودية، يجب توفير مصادقة الهوية الحكومية (نفاذ) إذا كان التطبيق يتطلب تحققًا حكوميًا، وربط المنصة مع بوابات دفع مثل STC Pay، مدفوعات حكومية (سداد)، أو PayFort، بالإضافة إلى خدمات المراسلة النصية مثل Esendex, ICM لتأكيد الطلبات.

وحتى الدمج مع خدمات توصيل محلية مثل «أرامكس» أو «SMSA Express» لإرسال الطرود. جميع هذه التكاملات تقوي التطبيق ولكنها ترفع الكلفة والوقت. فمثلاً، كل تكامل جديد قد يحتاج «X» ساعات برمجة وفحص للتأكد من سلامته. لذا يجب تسجيل كل خدمة خارجية مع تقدير جهد الربط والتكاليف الإضافية (إن وُجدت عمولات). هذا يضمن عدم فوجئتك بتكاليف متكررة لاحقًا.

الخطوة 5: احتساب البنية التحتية والصيانة

لا تنسى تكاليف الاستضافة (سيرفر/سحابة) وخطط الصيانة الدورية بعد الإطلاق.

أخيرًا، بعد حساب كل ما سبق، ننظر إلى الموارد التشغيلية. أولاً، استضافة التطبيق: هل ستحتاج سيرفرات سحابية مثل AWS/Azure أو خوادم محلية؟ هذه لها قيمة شهرية أو سنوية. كما تنبغي وضع خطة لصيانة التطبيق بعد الإطلاق: تصحيح الأخطاء (Bug Fixing)، تحديثات الأمان، دعم فني أساسي، إلخ. خبراء تطوير التطبيقات يؤكدون أن إطلاق المنتج ليس النهاية بل البداية.

فمثلاً، إيجاد باقة صيانة شهرية تغطي 15–25% من تكلفة التطوير الأصلي شائع، البحث أظهر أن نحو 90% من تكلفة البرنامج على مدى عمره يأتي من الصيانة والتحديثات (التحديث الدوري يرفع الأمان والأداء ويطوّل عمر المنتج).

لذا في التقدير النهائي يجب إضافة تقدير للبنية التحتية (Hardware/Cloud) والصيانة أول فترة (مثلاً 6–12 شهر). حيث تشير المصادر إلى أن الصيانة المنتظمة توفر على المدى الطويل: "الاهتمام بصيانة البرامج يساعد الشركات على خفض التكاليف على المدى الطويل وزيادة عائد الاستثمار من خلال ضمان استقرار وموثوقية البرنامج طوال فترة استخدامه".

ليش الأسعار تبدأ من 70,000 ريال - تفصيل صريح

دوافع الأسعار المرتفعة هي تعقيد الوظائف وجودة التنفيذ. الشركات المحترفة تبدأ أسعارها من نحو 70,000 ريال لأن المشاريع التقنية في المملكة غالبًا ما تشمل أكثر من مجرد "فكرة بسيطة"؛ فهي تتطلب تصميم جرافيكي فاخر، كتابة كود متعدد المنصات، واختبارات أمان، وأحيانًا ذكاء اصطناعي.

حسب دراسة سوقية، تطبيقات الجوال البسيطة قد تكلف 80–150 ألف ريال، وبناء تطبيق متقدم يشمل ذكاء اصطناعي أو وظائف كُبرى قد يتجاوز الـ400 ألف ريال.

حتى Glow تذكر أن بعض مطوّري المشاريع يقدمون تطبيقات مبدئية بسيطة بـ5,000–8,000 ريال فقط (غالبًا بجودة منخفضة)، بينما يبدأ السعر الاحترافي الكامل من حوالي 70,000 ريال.

الأسباب وراء هذا النطاق العالي واضحة:

1. التعقيد الوظيفي: كل ميزة إضافية (مثل نظام تتبع GPS فوري، أو بوابة دفع متعددة العملات) تزيد من ساعات التطوير والاختبارات. حسب Wrike وTechugo، التطبيقات البسيطة قد تبدأ من ~80 ألف ريال، أما المتقدمة فتتعدى مئات الآلاف.
2. عدد المنصات: تطبيق واحد في iOS فقط أرخص بكثير من تطويره على iOS وAndroid معًا. تطوير نسختين تقليديًا قد يرفع التكلفة بنسبة 30–70%.
3. جودة التصميم والتجربة (UX/UI): تصميم احترافي ومتجاوب يخضع لاختبارات ويستهلك وقتًا أكثر، وهو جزء من السعر. فقدرة التطبيق على جذب المستخدمين وجودة التجربة يزيدان القيمة ويبرران السعر الأعلى.
4. التكاملات الخارجية: كما ذكرنا، ربط التطبيق بأنظمة الدفع أو الخدمات الحكومية أو الملحقات التقنية يزيد النفقات.
5. دعم ما بعد الإطلاق: معظم الشركات تضيف بندًا للصيانة والدعم الفني. طبقًا لـ Glow، باقة صيانة سنوية غالبًا ما تكون 15–25% من تكلفة التطوير للعام الأول. عدم تضمين مثل هذه البنود في عرض السعر يعني الإهمال.

علامات التسعير الجزاف: كيف تعرف إن الشركة ما تفهم مشروعك

شركات التسعير العشوائي تظهر علامات عدة. أهمها أنها تقدّم لك سعرًا قبل حتى ما تسأل عن وظائف المشروع.

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

• السعر المباشر بدون تفصيل: يرسلون لك رقمًا سريعًا كـ "60 ألف" دون حتى سؤال عن الوظائف التي تحتاجها. هذا يشبه المقامرة؛ فبدون تحليل وظائف ووثيقة اتفاق (Statement of Work) لا يمكن حصر نطاق العمل بدقة.
• غياب تفصيل أجزاء النظام: مثلا يقدمون «سعر للتطبيق» عامّ دون تفسير كم تكلف كل من تطبيقي المستخدم والسائق ولوحات التحكم. غياب جدول زمني ومرحل نهائي (Milestones) يعني أنهم لم يحددوا مكونات المشروع أصلاً. Glow تحذر: الشركات التي ترفض تقديم مقترح تفصيلي (SOW) واضح أو عقد مُفصل – ابتعد عنها.
• عدم ذكر الصيانة والتحديثات: لو العرض لا يتحدث أصلاً عن دعم ما بعد الإطلاق أو تحديثات الأمان، فغالبًا هذا لأنهم يتجاهلون تكاليف الصيانة. في الواقع، الإهمال هنا يُكلفك ضعف المبلغ لاحقًا. فقد أوضح خبراء التطوير أن الخطة المنظمة للصيانة بعد الإطلاق أساسية لحماية تطبيقك.

↳ تعطيك سعر بدون ما تسأل عن الوظائف

هذه أول علامة. أي شركة محترفة تسأل عن تفاصيل الوظائف المطلوبة (Features) قبل تسعير المشروع. إذا جاءك عرض سريع من غير تحقيق، تذكر أن السعر الرخيص غالبًا يعني قدرات محدودة أو مهام ناقصة.

↳ ما عندها تفصيل لأجزاء النظام

أيضًا، نقطة تفصيل النظام تُظهر جدية الفريق. في العرض الجيد تجد فقرات مخصصة لكل مكوّن (UI/UX، Backend، قاعدة بيانات، إلخ). إذا استلمت رقمًا شاملًا بدون ملحقات أو نقاط تسليم، فالشركة قد تكون اقتطعت على نفسها خطوتي التخطيط والتقدير.

↳ ما تذكر الصيانة والتحديثات في العرض

أحد الأخطاء الشائعة أن الشركات تروّج بأقل سعر دون ذكر بند الصيانة. لكن كما ذكرنا، الصيانة الدورية وحسابات الاستضافة والفواتير الأخرى (مثل نشر التطبيق على متاجر آبل وجوجل) ليست مجاناً.

الفرق بين Fixed Price و Time & Material - ومتى كل واحد

Fixed Price (السعر الثابت) يعني اتفاق على سعر شامل مقدمًا، وهو مناسب للمشاريع ذات نطاق واضح ومتفق عليه، أما Time & Material (حسب الوقت والمواد) فيعني الدفع مقابل الوقت الفعلي والأدوات المستخدمة، ويناسب المشاريع التي لا يمكن تقدير نطاقها بدقة في البداية أو يُتوقع أن تتغير مستقبلاً.

في نموذج السعر الثابت، تحددون الميزانية كاملة قبل بدء العمل، فيكون عبء المخاطرة على الشركة إذا زادت ساعات التطوير.

هذا النموذج يُعطيك راحة في تحكم المصاريف، لكن الشركات المحترفة تستخدمه فقط إذا كانت كل المتطلبات معروفة تمامًا.

حسب GainHQ، العقد السعري الثابت أفضل مع «متطلبات ثابتة ونطاق محدد جيدًا»، في المقابل التعاقد بالساعات (Time & Material) يجعلك تدفع قيمة العمل الفعلي – وهو مناسب حين تكون مواصفات المشروع غير محدّدة تمامًا أو قد تتغير. فعلى مشروع جديد قد يبدأ بمفهوم MVP ثم يتوسع، يكون التعاقد بالساعة منطقيًا لأنه «يبدأ العمل من دون تقدير كامل مسبق».

بالرغم من أن معدل الساعة قد يبدو أعلى، إلا أن مرونته تحميك من دفع فرق كبير إذا ما تغير النطاق. الخيار الأمثل يحدده مدى وضوح خطة المشروع لديك، فإذا كانت جميع المتطلبات واضحة من البداية يمكنك استخدام Fixed Price، وإن كان المشروع مرنًا أو يستدعي تغييرات، فاستخدام Time & Material يضمن دفع ما يحتاجه المشروع فعلاً.