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

لماذا يبدأ العمل الحقيقي بعد الإطلاق؟

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

لذلك فالسؤال الإداري الصحيح ليس «كم يكلّف بناء التطبيق؟» بل «كم يكلّف تشغيله بشكل موثوق طوال عمره، ومن المسؤول عن ذلك؟».

ما الذي يحتاجه التطبيق بعد الإطلاق

١. استضافة الخلفية وتشغيلها

معظم تطبيقات المنشآت تعتمد على خلفية (Backend) تحفظ البيانات وتنفّذ العمليات. هذه الخلفية تحتاج خوادم أو بيئة سحابية تُدار: سعة تكفي أوقات الذروة، وتحديثات لأنظمة التشغيل وقواعد البيانات، وشهادات أمان تُجدَّد قبل انتهائها، وتكاليف استضافة تُراجَع حتى لا تتراكم موارد لا يستخدمها أحد.

٢. المراقبة وتقارير الأعطال

إن كان أول من يكتشف العطل هو العميل، فالمراقبة غير موجودة فعلياً. التشغيل السليم يعني متابعة مستمرة لتوفر الخلفية وسرعة استجابتها، وجمع تقارير الانهيار (Crash Reports) من أجهزة المستخدمين، وتنبيهات تصل إلى شخص محدد يعرف ماذا يفعل بها، لا إلى صندوق بريد لا يقرؤه أحد.

٣. تحديثات أنظمة التشغيل والمتاجر

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

٤. الترقيعات الأمنية

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

٥. النسخ الاحتياطي والاستعادة

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

من يملك المفاتيح؟

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

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

القاعدة البسيطة: الحسابات باسم المنشأة، والمزوّد يحصل على صلاحيات عليها، لا العكس.

اتفاقية مستوى خدمة للتطبيق

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

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

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

عند تغيير المزوّد: التسليم المنظّم

تغيير الجهة التي تطوّر التطبيق أو تشغّله قرار طبيعي، لكنه يتحول إلى أزمة حين لا تكون أصول التطبيق موثقة. التسليم الجيد يشمل:

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

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

كيف تبني الميزانية

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

الخلاصة

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