مقالات

ما يكلّفه التطبيق بعد إطلاقه

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

بقلم أنس حمداوي5 دقائق قراءة
  • mobile
  • maintenance
  • operations
كل المقالات

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

ما الذي يتغيّر تحت تطبيق لا يلمسه أحد؟

أربعة أشياء، ولا يحتاج أي منها إلى تغيير منك.

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

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

ما نوعا التحديث، ولماذا يُفصلان؟

تحديث الإبقاء، والتغيير. لكل منهما مُشغّل مختلف ومقياس نجاح مختلف، وفي أي ميزانية صادقة مال مختلف.

النوع ما يفعله كيف يُقرَّر
الإبقاء يُبقي التطبيق قابلًا للتثبيت والدخول عاملًا تقويم ومراقبة، لا طلب من أحد
التغيير يغيّر ما يفعله التطبيق للمستخدمين قرار عمل له تاريخ وصاحبه

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

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

أي هاتف قديم يجب أن تظل تدعمه؟

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

ابدأ من الأجهزة لا من تفضيل. تقارير التحليلات تعرض إصدارات أنظمة من يفتح التطبيق، وأدنى تلك القائمة ليس ضجيجًا؛ إنه أسماء عملاء ستفقدهم.

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

ثم يتحرك الحد حين تقرر أنت أنه يتحرك: بتاريخ، ويُفضَّل قبل سنة، وبرسالة داخل التطبيق لمن هم دونه.

ما الذي يحتاج التطبيق إلى من يراقبه؟

تقارير الأعطال، وشخص يقرأها. النصفان شرط معًا؛ ولوحة لا يفتحها أحد زينة.

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

وللمتجر تقاريره في لوحته أيضًا؛ اقرأها حيث تُنشر، واعتبرها رأيًا ثانيًا لا الصورة كاملة.

متى يكون التطبيق جوابًا خاطئًا؟

حين يكون الاستعمال شهريًا أو أقل.

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

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

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

بأي ترتيب ترصد وتدير؟

  1. اكتب الحد: أقدم إصدار نظام تدعمه، وتاريخ مراجعته.
  2. اكتب عمل الإبقاء لكل مدة — العمل نفسه لا رقمًا — وضع تواريخه في التقويم.
  3. أبقِ قائمة التغييرات منفصلة، واطلب مواصفات مكتوبة وتقديرًا لكل بند فيها.
  4. أطلق تقارير الأعطال مع أول إصدار، بإصدار التطبيق مرفقًا بكل تقرير، وسمِّ من يقرأها.
  5. احفظ جهاز اختبار عند الحد، وبناءً لآخر نسخة سليمة مع الخادم الذي ما زال يجيبها.
  6. ثبّت العادة الأسبوعية: نسبة الأعطال، وفشل الدخول، وأقدم إصدار مدعوم.
  7. اقرأ قواعد المتجر الحالية لفئتك قبل كل إصدار عند مصدرها، وراجع رقم الاستعمال مرة في السنة: هل ما زال التطبيق يستحق التثبيت الذي يطلبه؟

أين يخطئ هذا

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

ما لا يغطيه هذا المقال

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

نبني تطبيقات يُقصد بها أن تبقى حيّة، ونقول ذلك حين لا يكون التطبيق هو الجواب الصادق.

ابدأ مشروعًا

لديك شيء تريد بناءه؟

ملخص قصير يكفي. تحصل على نطاق مكتوب وسعر ثابت قبل أن يبدأ أي شيء.