ما الذي يحدد تكلفة البرمجيات المخصصة

«كم تكلف هذه البرمجيات؟» هو السؤال الذي يُطرح علينا أكثر من غيره. جوابه ليس رقمًا واحدًا، وقول ذلك يبدو تهربًا. لكنه ليس كذلك. الرقم الذي يُعطى دون معرفة البنود التي تحدد التكلفة إما أعلى من اللازم، أو رقم سيرتفع في منتصف المشروع.

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

عدد الشاشات مقياس مضلل

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

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

التكاملات

نادرًا ما تعمل البرمجيات وحدها. نظام المحاسبة، والتحقق من الهوية، والدفع، والبريد الإلكتروني، والأنظمة القديمة للمؤسسة، أو خدمة حكومية. كل ربط عمل مستقل.

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

البيانات وترحيلها

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

الأمن والتشريعات

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

عدم اليقين

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

أفضل طريقة لتقليل عدم اليقين هي وضع مرحلة استكشاف قصيرة في بداية المشروع. في هذه المرحلة يتضح النطاق والتكاملات والبيانات. ويُسعَّر التطوير الفعلي بعد ذلك برقم أمتن.

الاختبار والقبول

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

بعد التسليم

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

عند قراءة عرض

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

باختصار

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