الإجابة المختصرة: التطبيق ليس أصلًا يُشترى مرة، بل نظامًا حيًّا يحتاج إنفاقًا متكرّرًا. وصيانة التطبيق بعد الإطلاق تسعة بنود: خوادم وخدمات، ورسوم متاجر، وتحديثات إجبارية لمواكبة الأنظمة، وإصلاح أعطال، وتحديث مكتبات، ومراقبة، ودعم مستخدمين، وتحسينات صغيرة، وتجديد شهادات ومفاتيح. والحقيقة التي تفاجئ كثيرين: التطبيق الذي لا يُصان لا يبقى كما هو، بل يتوقف — إما بسقوطه من المتجر لتخلّفه عن متطلبات النظام، أو بانهياره بعد ترقية نظام لدى المستخدمين.
لماذا يتوقف التطبيق المهمَل؟
هذا ما لا يتوقعه أصحاب المشاريع: تطبيق يعمل بشكل ممتاز، لا أحد يلمسه، وبعد عام أو عامين تبدأ الشكاوى.
الأسباب الثلاثة المتكررة:
رفع الحد الأدنى لمستوى واجهة البرمجة. المتاجر ترفعه سنويًا، والتطبيق المتخلّف يختفي من نتائج البحث للأجهزة الجديدة ثم يُمنع تحديثه.
ترقيات الأنظمة عند المستخدمين. نظام جديد يغيّر سلوك أذونات أو واجهات، فينهار التطبيق فجأة بلا أن يتغيّر سطر في كودك.
خدمات خارجية تتغيّر. بوابة الدفع تحدّث واجهتها، ومزوّد الخرائط يغيّر شروطه، ومكتبة تتوقف عن الدعم. وأي منها يعطّل جزءًا من تطبيقك.
البنود التسعة
1. الخوادم والاستضافة. الواجهة الخلفية وقاعدة البيانات والتخزين. تكلفة شهرية تنمو مع عدد المستخدمين.
2. رسوم المتاجر. اشتراك سنوي عند آبل، ورسم تسجيل مرة واحدة عند جوجل. وانقطاع التجديد يعني اختفاء تطبيقاتك، كما فصّلنا في حساب مطور آبل وجوجل.
3. الخدمات الخارجية. الإشعارات، والخرائط، والرسائل النصية، والتحليلات، وبوابة الدفع. أغلبها بالاستخدام، فتنمو مع نموّك.
4. تحديثات المواكبة. إصدارات دورية لمواكبة متطلبات المتاجر والأنظمة الجديدة. هذا البند إلزامي ولا علاقة له بإضافة ميزات.
5. إصلاح الأعطال. الانهيارات والأخطاء التي تظهر في الاستخدام الحقيقي، وقراءتها شرحناها في انهيار التطبيق.
6. تحديث المكتبات. بما فيها الترقيات الأمنية. المكتبة المهملة ثغرة تنتظر.
7. المراقبة والتنبيه. أدوات تخبرك حين يتوقف شيء قبل أن يخبرك عميل غاضب.
8. دعم المستخدمين. الرد على الأسئلة والمراجعات، وحلّ حالات فردية. يحتاج وقتًا بشريًا لا برمجيًا.
9. الشهادات والمفاتيح والنطاقات. تنتهي صلاحياتها بصمت وتُعطّل خدمات كاملة يوم انتهائها.
جدول: البنود وتكرارها
| البند | التكرار | يزيد مع النمو؟ | |—|—|—| | استضافة وقواعد بيانات | شهري | نعم | | رسوم آبل | سنوي | لا | | رسوم جوجل | مرة واحدة | لا | | رسائل نصية | بالاستخدام | نعم بشدة | | إشعارات وخرائط | بالاستخدام | نعم | | بوابة دفع | نسبة من العمليات | نعم | | تحديثات المواكبة | 2–4 مرات سنويًا | لا | | إصلاح الأعطال | مستمر | قليلًا | | مراقبة وتنبيه | شهري | قليلًا | | دعم المستخدمين | مستمر | نعم | | شهادات ونطاقات | سنوي | لا |
كم تبلغ الصيانة؟
القاعدة المتداولة في الصناعة تقدّر الصيانة السنوية بنسبة من تكلفة البناء الأصلية، وتختلف بحسب تعقيد التطبيق وعدد التكاملات وحجم الاستخدام.
وما يرفعها فعليًا:
- التكاملات الكثيرة مع أنظمة خارجية — كل تكامل نقطة عطل محتملة.
- الدفع والاشتراكات — تتغيّر قواعدها وتحتاج متابعة.
- قاعدة مستخدمين كبيرة — دعم أكثر وخوادم أكبر.
- بيانات حسّاسة — امتثال ومراجعات أمنية.
وما يخفضها:
- بناء نظيف موثّق يسهّل على أي فريق العمل عليه لاحقًا.
- مكتبات قليلة ومشهورة بدل عشرات المكتبات النادرة.
- اختبارات آلية تكشف الانكسار قبل النشر.
- نطاق مركّز — التطبيق الذي يفعل شيئًا واحدًا يُصان بربع جهد الذي يفعل عشرة.
وهذه العلاقة تحديدًا تجعل قرارات ما قبل البناء تحدّد فاتورتك لسنوات، وهو ما ينعكس في تقديرنا لـتكلفة تصميم تطبيق.
ماذا يجب أن يتضمّن عقد الصيانة؟
هذه بنود غيابها يُنتج نزاعًا لاحقًا:
زمن الاستجابة حسب الخطورة. ما يُعدّ طارئًا (التطبيق لا يعمل، الدفع متوقف) وكم ساعة للرد عليه، وما يُعدّ عاديًا.
ساعات التغطية. أيام العمل فقط أم تشمل العطلات؟ الأعطال لا تحترم المواعيد.
ما هو مشمول وما هو خارج النطاق. الإصلاح مشمول، والميزة الجديدة مشروع منفصل. وهذا أكثر ما يُختلف عليه.
عدد التحديثات الدورية سنويًا لمواكبة الأنظمة.
ملكية الحسابات والمفاتيح — لك أنت لا للمورّد، وتفصيلها في نقل ملكية التطبيق.
تقرير دوري: ما حدث هذا الشهر، وما أُصلح، وما المؤشرات، وما التوصية.
وشرط الخروج: ماذا يحدث إن أردت تغيير المورّد؟ ما الذي يُسلَّم ومتى؟
روتين الصيانة: ماذا يحدث ومتى؟
الصيانة الجيدة إيقاع منتظم لا استجابة للأزمات. وهذا جدول يصلح لأغلب التطبيقات:
أسبوعيًا: قراءة تقارير الأعطال والمؤشرات الأساسية، والرد على المراجعات الجديدة، ومتابعة رسائل الدعم. عشرون دقيقة تكفي حين لا يوجد طارئ.
شهريًا: مراجعة فواتير الخدمات الخارجية، وتحديث المكتبات ذات الترقيات الأمنية، وقراءة اتجاه الاحتفاظ، وإصلاح أكثر ثلاثة أعطال أثرًا.
ربع سنويًا: إصدار تحديث ولو صغير — للحفاظ على حيوية التطبيق في المتجر ومواكبة المتطلبات، ومراجعة الأذونات والبيانات المعلنة، وفحص انتهاء صلاحيات الشهادات والمفاتيح.
سنويًا: مراجعة كبرى — مستوى واجهة البرمجة المستهدف، والحد الأدنى للأنظمة المدعومة، والمكتبات المهجورة، وتجديد رسوم الحسابات، ومراجعة العقود والخدمات.
وعند كل ترقية نظام كبيرة: اختبار على النسخة التجريبية قبل إطلاقها العام. هذا وحده يمنع موجة انهيارات عند ملايين المستخدمين الذين يرقّون أجهزتهم في أسبوع واحد.
من يفعل هذا؟
ثلاثة ترتيبات شائعة، ولكل منها ما يناسبه:
عقد مع شركة التطوير. الأسرع فهمًا للنظام، والأنسب لأغلب الشركات التي ليس التطبيق منتجها الأساسي. والشرط: بنود واضحة وملكية عندك.
فريق داخلي. منطقي حين يصير التطبيق قلب عملك ويحتاج تطويرًا مستمرًا. وتكلفته أعلى لكنه أسرع استجابة.
مزيج. فريق داخلي صغير يدير المنتج والمتابعة اليومية، وشركة خارجية للتطوير الكبير. وهو الترتيب الأشيع في الشركات المتوسطة.
وما لا ينجح: الاعتماد على مطوّر فرد بلا توثيق ولا بديل. حين يغادر أو ينشغل، يتوقف كل شيء — وهذه أكثر حالة طوارئ نُستدعى إليها.
علامات أن تطبيقك مهمَل
لم يصدر تحديث منذ أكثر من عام. ظاهر لأي مستخدم في صفحة المتجر، ويُقرأ كإشارة على أن الشركة تخلّت عن المنتج.
مراجعات حديثة تشتكي من عطل بلا رد.
لا أحد يعرف معدل الانهيار. إن سألت ولم تجد إجابة، فأنت لا تراقب شيئًا.
مفاتيح خدمات انتهت صلاحيتها وميزات توقفت بصمت بلا أن يلاحظ أحد.
نظام التشغيل الأدنى المدعوم قديم جدًا بحيث يشير إلى أن التطبيق لم يُبنَ منذ سنوات.
التكلفة الخفية: الدعم البشري
البند الذي لا يظهر في أي عرض تقني، ويستهلك وقتًا أكثر مما يُتوقع: الرد على المستخدمين.
ما يصلك يوميًا في تطبيق نشط: أسئلة عن الاستخدام، وشكاوى عن عملية لم تكتمل، وطلبات استرجاع، وحالات فردية تحتاج تدخّلًا في البيانات، ومراجعات في المتجر تنتظر ردًا.
وثلاثة إجراءات تخفّض هذا العبء إلى النصف:
صفحة أسئلة شائعة داخل التطبيق. مبنية على ما يُسأل فعلًا لا على ما تتخيّله. راجعها كل شهرين وأضف ما تكرّر.
رسائل خطأ تشرح الحل. كل رسالة خطأ غامضة تُنتج رسالة دعم. و«فشلت العملية» تكلّفك ردًا بشريًا، بينما «انتهت صلاحية البطاقة، جرّب وسيلة أخرى» تنهي الأمر.
شاشة حالة واضحة. المستخدم الذي يرى حالة طلبه لا يسأل عنها. وأغلب رسائل الدعم في تطبيقات الخدمات سؤال واحد: «أين طلبي؟».
والقاعدة: كل رسالة دعم متكرّرة هي عيب في المنتج لا عبء على الفريق. عالج السبب مرة بدل الرد ألف مرة.
متى تتحوّل الصيانة إلى تطوير؟
الحد بينهما مصدر أكثر الخلافات بين العميل والمورّد، ويمكن حسمه بقاعدة بسيطة:
صيانة: إبقاء ما هو موجود يعمل كما وُصف. إصلاح عطل، وتحديث مكتبة، ومواكبة نظام جديد، وضبط أداء تدهور.
تطوير: إضافة سلوك جديد أو تغيير سلوك قائم. شاشة جديدة، وتكامل جديد، وتغيير في قواعد العمل.
والحالات الرمادية تُحسم بسؤال: هل كان هذا يعمل ثم توقّف، أم لم يكن موجودًا أصلًا؟
أمثلة توضّح الحد:
- بوابة الدفع غيّرت واجهتها فتوقّف الدفع ⇒ صيانة.
- تريد إضافة وسيلة دفع جديدة ⇒ تطوير.
- التطبيق ينهار على نسخة نظام جديدة ⇒ صيانة.
- تريد دعم أجهزة لوحية بتخطيط مختلف ⇒ تطوير.
واكتب هذه الأمثلة في العقد نفسه. التعريف المجرّد يُختلف عليه، والأمثلة الملموسة تنهي النقاش قبل أن يبدأ.
أسئلة شائعة
هل أحتاج عقد صيانة إن كان التطبيق بسيطًا؟
تحتاج حدًا أدنى: تحديثات المواكبة، ومراقبة، وقناة لإصلاح الأعطال. أما حجم العقد فيتناسب مع تعقيد التطبيق وأهميته لعملك.
ماذا لو لم أحدّث التطبيق أبدًا؟
سيعمل مدة، ثم تبدأ الأعطال مع ترقيات الأنظمة، ثم يسقط من نتائج البحث للأجهزة الجديدة، ثم يُمنع تحديثه. والمسار ينتهي دائمًا بإعادة بناء أغلى من الصيانة التي تجنّبتها.
هل الصيانة تشمل الميزات الجديدة؟
لا في العقود المنضبطة. الصيانة تُبقي ما هو قائم يعمل، والميزات مشاريع تُقدَّر منفصلة. والخلط بينهما مصدر أكثر الخلافات.
من يحتفظ بالكود؟
أنت. اطلب مستودع الكود باسم شركتك من اليوم الأول، مع توثيق لكيفية البناء والنشر.
كيف أقلّل فاتورة الخدمات الخارجية؟
راجعها سنويًا: هل تستخدم كل خدمة فعلًا؟ وهل بدائلها أرخص لحجمك الحالي؟ والرسائل النصية تحديدًا تستحق مراجعة، فهي أسرع البنود نموًّا مع عدد المستخدمين.
متى يكون إعادة البناء أرخص من الصيانة؟
حين تصير كل ميزة صغيرة مكلفة، أو تعتمد على تقنية متوقفة الدعم، أو لا يفهم أحد الكود. عندها تحسب: كلفة سنتين من الصيانة المتعثرة مقابل إعادة بناء مدروسة.
هل الصيانة تشمل تحديثات الأمان؟
يجب أن تشملها صراحة في العقد، وهي ليست بندًا اختياريًا. الثغرة في مكتبة قديمة قد تكشف بيانات عملائك، والمسؤولية تقع عليك أمامهم لا على المورّد.
كم مرة يجب أن أصدر تحديثًا؟
مرتان إلى أربع سنويًا كحد أدنى حتى لو لم تتغيّر ميزة. الغياب الطويل عن المتجر يُقرأ كإهمال من المستخدمين ومن المتاجر معًا، وتفصيل إدارة الإصدارات في تحديثات التطبيق.
هل أحتاج فريقًا متفرغًا؟
نادرًا في البداية. عقد صيانة بساعات محددة شهريًا يكفي أغلب التطبيقات، ويتحوّل إلى فريق متفرغ حين يصير التطبيق منتجك الأساسي.
ما الذي يستحق المراقبة الآلية؟
المراقبة ليست ترفًا؛ الفرق بينها وبين غيابها هو الفرق بين معرفة العطل خلال دقائق ومعرفته من شكوى عميل بعد يومين.
راقب هذه الخمسة كحد أدنى:
توفّر الخدمة. فحص دوري يتأكد أن الواجهة الخلفية ترد، وتنبيه فوري إن توقفت.
زمن الاستجابة. البطء التدريجي علامة مبكرة على مشكلة قادمة — قاعدة بيانات تنمو، أو استعلام صار ثقيلًا.
معدل الأخطاء. ارتفاع نسبة الطلبات الفاشلة إنذار قبل أن يصير انقطاعًا.
مساحة التخزين والذاكرة. أكثر أسباب التوقف المفاجئ بدائية: قرص امتلأ.
انتهاء الصلاحيات. تنبيه قبل شهر من انتهاء أي شهادة أو مفتاح أو نطاق أو اشتراك.
والأهم من الأداة: أن يصل التنبيه إلى شخص يستطيع التصرّف، لا إلى بريد جماعي لا يفتحه أحد. حدّد المسؤول وقناة التنبيه ووقت الاستجابة المتوقع.
احسبها قبل أن توقّع
عند تقدير ميزانية التطبيق، أضف بندًا صريحًا للصيانة السنوية من السنة الأولى لا من الثانية.
لماذا من الأولى؟ لأن الأشهر التالية للإطلاق هي الأكثر احتياجًا للإصلاح والمتابعة، وهي بالضبط حين تكون الميزانية قد استُنفدت في البناء.
والمشروع الذي يُخطَّط له ببند صيانة واضح يعيش سنوات، والذي يُبنى بميزانية بناء فقط يتوقف عند أول متطلب نظام جديد.
الخلاصة: الصيانة ليست بندًا اختياريًا بل ثمن البقاء في المتجر. والتطبيق الذي لا ينفق عليه صاحبه لا يبقى ساكنًا، بل ينحدر ببطء حتى يسقط. احسب البنود التسعة في ميزانيتك من السنة الأولى، واكتبها في العقد بوضوح، وستدفع أقل بكثير مما يدفعه من اكتشفها متأخرًا وقت الأزمة. ونحن نقدّم هذا الترتيب صراحة لعملائنا في شركة تطوير تطبيقات الجوال.