تكلفة صيانة البرمجيات هي الرقم الذي يحوّل مشروعًا ناجحًا إلى محادثة صعبة بعد ثمانية عشر شهرًا. فمرحلة البناء جرى تقدير ميزانيتها والموافقة عليها وتسليمها على النحو المتفق عليه. أما ما يحدث بعد دخول النظام إلى الخدمة فقد وُصف بكلمة «الدعم» ومُنح رقمًا خمّنه أحدهم على عجل، وكان ذلك الرقم أصغر من اللازم في كل مرة تقريبًا.
والسبب في ذلك بنيوي وليس نتيجة إهمال. فمرحلة البناء لها نطاق يمكن تسعيره وجدولته والاتفاق عليه مسبقًا. أما الصيانة فلا نطاق لها، لأنها تُعرَّف بأشياء لم تقع بعد: مكتبة برمجية تظهر فيها ثغرة أمنية، ومورّد يغيّر واجهة برمجة التطبيقات الخاصة به، ومستخدم يقع في حالة لم يتوقعها أحد أثناء التصميم.
القاعدة التقريبية التي يستشهد بها الجميع هي من 15 إلى 20 في المئة من تكلفة البناء سنويًا، وقربها من الصواب هو ما يجعلها خطرة. فهي تصيب بما يكفي لتمنح شعورًا بالأمان، وتخطئ في اتجاه يمكن التنبؤ به: تقلّل من تقدير السنة الأولى التي تظهر فيها العيوب، وتنهار تمامًا مع الأنظمة ذات الالتزامات التنظيمية أو ذات التكاملات الكثيرة مع أطراف خارجية، حيث تقود العملَ أحداثٌ خارجية لا شيفرتك أنت.
ما الذي تغطيه تكلفة صيانة البرمجيات فعليًا
خمس فئات متمايزة، والخلط بينها هو بالضبط ما يُنتج الرقم الخاطئ في الميزانية.
العمل التصحيحي. إصلاح العيوب. يتركز هذا العمل في البداية، لأن معظم الأخطاء تظهر في الأشهر الأولى من الاستخدام الحقيقي، وهذه هي الفئة الوحيدة التي تتعامل معها قاعدة النسبة المئوية تعاملًا معقولًا.
العمل التكيّفي. مواكبة أشياء خارجة عن سيطرتك تمامًا. مكتبة تصدر ترقيعًا أمنيًا يجب تركيبه. مزوّد مدفوعات يوقف إصدارًا من واجهته البرمجية. متصفح يغيّر سلوكه في التعامل مع الصفحات. لا شيء من هذا يضيف ميزة جديدة، وكل هذا إلزامي لا خيار فيه.
العمل الوقائي. الترقية قبل أن تُجبَر عليها. تخطّيه لا يلغي التكلفة، بل يؤجلها ويضاعفها مع الوقت، وهكذا تتحول ترقية روتينية لإطار العمل إلى مشروع يمتد ثلاثة أشهر كاملة.
التشغيل اليومي. الاستضافة والمراقبة والنسخ الاحتياطي والشهادات، ووقت الأشخاص الذين يتابعون كل ذلك. يُحتسب غالبًا في بند منفصل، ولا بأس في ذلك ما دام أحدهم يحتسبه أصلًا.
التغييرات الصغيرة. ذلك التدفق المستمر من التعديلات الذي يولّده أي نظام حي بمجرد أن يستخدمه أشخاص حقيقيون. تافهة إذا نُظر إليها واحدة واحدة، لكنها مجتمعةً أكبر الفئات في معظم السنوات.
الفئة الأولى وحدها هي ما يقصده الناس عادةً بكلمة الصيانة. والفئات الأربع الأخرى هي السبب في نفاد الميزانية قبل نهاية العام.
لماذا تضلل قاعدة النسبة المئوية
لأنها ترتكز على الكمية الخاطئة. فجهد الصيانة يتبع عدد الأجزاء المتحركة والسرعة التي يغيّر بها العالم الخارجي تلك الأجزاء، لا ما كلّفته مرحلة البناء بمحض المصادفة.
نظامان بُنيا بالمبلغ نفسه قد يختلفان بمقدار ثلاثة أضعاف. تطبيق مكتفٍ بذاته له اعتماديتان اثنتان ولا تعرّض تنظيمي عليه يبقى رخيص التشغيل سنة بعد سنة. أما نظام يدمج ستة خدمات خارجية ويعالج بيانات شخصية ويخضع لقواعد قطاعية فليس كذلك، لأن كل تكامل من تلك التكاملات مصدر عمل لا تجدوله أنت ولا تتحكم في توقيته.
كما تفترض النسبة حالة استقرار لا وجود لها في السنة الأولى. فالاستخدام الحقيقي يعثر على العيوب، والأشهر الستة الأولى بعد الإطلاق تكون عادةً أعلى بكثير من المتوسط السنوي قبل أن تستقر الأمور عند مستوى قابل للتنبؤ.
التقدير الأفضل يبدأ من الأجزاء المتحركة نفسها. أحصِ التكاملات والالتزامات التنظيمية وعدد المستخدمين الذين يولّدون طلبات دعم، ثم سعّر الوقت الذي تستهلكه هذه الأمور واقعيًا. دليلنا حول تكلفة تطوير البرمجيات المخصصة يتناول جانب البناء من الحساب نفسه.
البنود التي تنساها الفرق
ترقية الاعتماديات. ليست اختيارية، لأن المكتبات غير المرقّعة هي الطريق الذي تُخترق عبره الأنظمة، والجهد هنا غير قابل للتنبؤ فعلًا لأنه يتوقف على ما يفعله القائمون على تلك المكتبات في المنبع.
تغيّرات واجهات الأطراف الخارجية. مورّد يوقف إصدارًا ويمنحك مهلة محددة. أنت لم تختر التوقيت، ولا تستطيع الاعتذار عن التنفيذ.
تجديد الشهادات وأسماء النطاقات. أمر تافه إلى أن تنتهي صلاحية إحداها في عطلة نهاية الأسبوع فيتوقف الموقع عن العمل.
المراقبة والاستجابة لها. التنبيهات بلا قيمة إن لم يكن هناك من يتفاعل معها، وهذا الاستعداد تكلفة حقيقية سواء تعطّل شيء أم لم يتعطل.
نقل المعرفة. الناس يرحلون. وما يكلّفه تعلّم الشخص التالي للنظام هو تكلفة صيانة، وحجمه يتناسب طرديًا مع قلة ما كُتب وُوثّق من قبل.
نمو البيانات. تكلفة التخزين ترتفع، والاستعلامات التي كانت سريعة تتباطأ، والعمل اللازم لمعالجة ذلك يصل وفق جدول يحدده نجاحك أنت. دليلنا حول أداء قواعد البيانات يشرح كيف يبدو ذلك عمليًا.
كم يكلف هذا في المملكة المتحدة
نطاقات سنوية تقريبية لصيانة نظام مخصص، بافتراض الاستعانة بمزوّد خارجي بدلًا من موظفين داخليين.
| شكل النظام | التكلفة السنوية المعتادة |
|---|---|
| أداة داخلية صغيرة بعدد قليل من التكاملات | من £6,000 إلى £15,000 |
| تطبيق موجّه للعملاء بعدة تكاملات | من £20,000 إلى £60,000 |
| منصة خاضعة للتنظيم أو ذات حركة مرور عالية | £60,000 فما فوق |
لا تشمل هذه الأرقام الاستضافة والتراخيص، فهي تُفوتر على حدة وتتفاوت تفاوتًا هائلًا. وهي تفترض كذلك أن النظام في حالة معقولة. أما صيانة شيء لم يوثّقه أحد، بلا اختبارات، ويفهمه شخص واحد فقط، فتكلف أكثر وتحمل مخاطرة لا يزيلها أي عقد صيانة مهما كانت صيغته.
كيف تنظّم الترتيب
عقد صيانة بساعات محددة يصلح حين يكون حجم العمل قابلًا للتنبؤ إجمالًا. أنت تشتري به جاهزية الاستجابة، وهي معظم ما تدفع مقابله، والساعات غير المستخدمة ليست هدرًا لأن البديل عنها هو ألا يكون لديك أحد أصلًا.
الدفع بالوقت والمواد يناسب الأنظمة قليلة التغيير، لكن زمن الاستجابة يصبح ما تسمح به التزامات المزوّد الأخرى، وهذه هي المقايضة التي تقبلها.
عقد دعم بسعر ثابت ينقل المخاطرة إلى المزوّد الذي يسعّرها ضمن أتعابه. وهو خيار معقول للأنظمة الحرجة حين تكون قابلية التنبؤ أثمن من هامش الربح.
أيًّا كان اختيارك، اتفق على ما يُعد صيانة وما يُعد ميزة جديدة قبل أن تحتاج إلى ذلك. هذا الحد الفاصل هو مصدر كل نزاع تقريبًا في علاقات الدعم، وتعريفه في البداية لا يكلف شيئًا على الإطلاق.
تتولى Mecanik صيانة أنظمة لم نبنِها نحن، كما نصون الأنظمة التي بنيناها بأنفسنا، ضمن عملنا في تطوير البرمجيات . والشهر الأول من أي عملية تسلّم يمضي عادةً في التوثيق، لأن ذلك هو ما يحدد تكلفة كل شهر يليه.
قراءات ذات صلة: عقد بسعر ثابت أم بالوقت والمواد؟ ، كيف تكتب كراسة شروط برمجية تجلب عروضًا مفيدة ، ضمان الشيفرة لدى طرف ثالث: من يحتاجه فعلًا وتطوير المنتج الأولي: النطاق والتكلفة والجدول الزمني .
الأسئلة الشائعة
كم تبلغ تكلفة صيانة البرمجيات سنويًا؟ القاعدة التقريبية الشائعة هي من 15 إلى 20 في المئة من تكلفة البناء سنويًا، لكنها تقلّل من تقدير السنة الأولى التي تظهر فيها العيوب، وتنهار تمامًا مع الأنظمة ذات التكاملات الكثيرة أو الالتزامات التنظيمية. النطاقات التقريبية في المملكة المتحدة تبدأ من £6,000 إلى £15,000 لأداة داخلية صغيرة، وتصل إلى £60,000 أو أكثر لمنصة خاضعة للتنظيم أو ذات حركة مرور عالية، من دون الاستضافة.
ماذا تشمل صيانة البرمجيات فعليًا؟ خمس فئات: العمل التصحيحي لإصلاح العيوب، والعمل التكيّفي لمواكبة الاعتماديات وتغيرات واجهات الأطراف الخارجية، والعمل الوقائي بالترقية قبل أن تُجبَر عليها، والتشغيل اليومي مثل الاستضافة والمراقبة، ثم التدفق المستمر من التغييرات الصغيرة التي يولّدها أي نظام حي. الفئة الأولى وحدها هي ما يقصده معظم الناس بالصيانة.
لماذا لا يُعتمد على قاعدة النسبة من تكلفة البناء؟ لأنها ترتكز على الكمية الخاطئة. فجهد الصيانة يتبع عدد الأجزاء المتحركة وسرعة تغيّر العالم الخارجي لها، لا ما كلّفه البناء. ونظامان بُنيا بالمبلغ نفسه قد يختلفان ثلاثة أضعاف تبعًا لعدد التكاملات والتعرّض التنظيمي وحجم طلبات الدعم.
ما تكاليف الصيانة التي تنسى الفرق إدراجها في الميزانية؟ ترقية الاعتماديات، وإيقاف واجهات الأطراف الخارجية بمُهَل لم تخترها أنت، وتجديد الشهادات وأسماء النطاقات، والجاهزية البشرية خلف تنبيهات المراقبة، ونقل المعرفة عند رحيل الأشخاص، وأثر نمو البيانات على تكلفة التخزين وسرعة الاستعلامات.
هل أختار عقد صيانة أم الدفع عند الحاجة؟ عقد الصيانة بساعات محددة يناسب الحجم القابل للتنبؤ ويشتري جاهزية الاستجابة، وهي معظم ما تدفع مقابله. والدفع بالوقت والمواد يناسب الأنظمة قليلة التغيير، لكن زمن الاستجابة يتوقف على التزامات المزوّد الأخرى. وأيًّا كان اختيارك، عرّف ما يُعد صيانة وما يُعد ميزة جديدة قبل أن تحتاج إلى ذلك.
التعليقات