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