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