محتويات المقال
في تطبيق أعمال مع لوحة تحكم يمرّ كل طلب بست محطات: المستخدم ينشئ الطلب داخل التطبيق، فيتحقق منه الخادم ويحفظه بحالة أولى، ثم يظهر في لوحة التحكم للموظف المختص، فيغيّر الموظف حالته، فيُرسل النظام إشعاراً إلى المستخدم، ويُسجَّل كل ذلك في سجل لا يُعدَّل. أضعف حلقة في هذه السلسلة هي الإشعار، لأنه يمر عبر خدمات Apple وGoogle خارج سيطرة التطبيق؛ لذلك تكون الحالة المحفوظة على الخادم هي المرجع دائماً، والإشعار مجرد تنبيه إليها. هذا المقال شرح توضيحي لطريقة عمل الدورة وما يجب تحديده في نطاق المشروع، وليس دراسة حالة لمشروع بعينه.
لمن هذا الشرح؟
لمدير عمليات أو صاحب منشأة يستقبل الطلبات اليوم عبر الهاتف أو واتساب أو جداول Excel، ويريد نقلها إلى تطبيق يطلب منه العميل ولوحة يتابع منها الفريق. السؤال الذي يهمه قبل التعاقد ليس «هل يمكن بناء تطبيق؟» بل: ماذا يحدث للطلب بين ضغطة العميل وردّ الموظف؟ ومن يعرف إن تعطّل شيء في المنتصف؟
الإجابة عن هذين السؤالين تحدد عدد شاشات لوحة التحكم، والأدوار والصلاحيات، والتكاملات المطلوبة مثل بوابة الدفع والرسائل النصية، وبالتالي تحدد النطاق والتقدير. لذلك يفيد أن تفهم الدورة كاملة قبل أن تكتب كلمة «إشعارات» أو «لوحة تحكم» في طلبك.
الدورة خطوة بخطوة
1. المستخدم ينشئ الطلب
يختار المستخدم الخدمة أو المنتج، ويملأ الحقول، وقد يرفق صورة أو موقعاً، ثم يضغط «إرسال». يتحقق التطبيق قبل الإرسال من الحقول الإلزامية وصيغها حتى لا يرسل طلباً ناقصاً. ويُرفق مع كل محاولة إرسال معرّفاً فريداً، فإذا ضغط المستخدم الزر مرتين أو أعاد التطبيق المحاولة بعد انقطاع الشبكة، يتعرّف الخادم على أنه الطلب نفسه ولا ينشئ نسخة مكررة.
2. الخادم يستقبل الطلب ويحفظه
تستقبل الواجهة الخلفية الطلب عبر واجهة API، فتتحقق من هوية المستخدم وصلاحيته ومن صحة البيانات مرة أخرى، لأن التحقق داخل التطبيق وحده يمكن تجاوزه. ثم تحفظ الطلب بحالة «جديد» وتعيد للمستخدم رقم الطلب ليظهر على شاشته. إذا كان الطلب مدفوعاً، فلا يُعتمد بناءً على رسالة من التطبيق بأن الدفع نجح، بل بعد وصول تأكيد من بوابة الدفع إلى الخادم مباشرة.
3. الطلب يظهر في لوحة التحكم
يظهر الطلب في قائمة الطلبات الجديدة لدى من يملك صلاحية رؤيته فقط: موظف فرع معيّن، أو قسم خدمة محددة، أو مشرف يرى الجميع. قواعد التوزيع هذه (حسب الفرع أو المنطقة أو نوع الخدمة) جزء من النطاق ويجب أن تُكتب صراحة، لأنها تغيّر تصميم الصلاحيات كله. وعادة يُضاف تنبيه داخل اللوحة أو بريد إلى الموظف حتى لا يبقى الطلب منتظراً دون أن يراه أحد.
4. الموظف يغيّر الحالة
قلب الدورة هو ما يسمى «آلة الحالات»: قائمة محددة بالحالات والانتقالات المسموحة بينها، مثل: جديد ← قيد المراجعة ← مقبول أو مرفوض ← قيد التنفيذ ← مكتمل، مع حالة «ملغى» في نقاط محددة. لا يُسمح بالقفز من «جديد» إلى «مكتمل»، ويكون سبب الرفض أو الإلغاء حقلاً إلزامياً. وإذا فتح موظفان الطلب نفسه في الوقت نفسه، يرفض النظام تحديث من بنى قراره على نسخة قديمة ويطلب منه إعادة التحميل، بدل أن يمسح أحدهما عمل الآخر بصمت.
5. الإشعار يعود إلى المستخدم
بعد حفظ الحالة الجديدة، لا قبله، يضع الخادم مهمة إرسال الإشعار في طابور مستقل. يُرسل الإشعار عبر خدمة Apple لأجهزة iOS وخدمة Google لأجهزة Android، وقد تُضاف رسالة نصية للحالات الحرجة. فصل الإشعار في طابور يعني أن بطء خدمة الإشعارات لا يعطّل شاشة الموظف، وأن الإرسال يمكن إعادته إذا فشل.
6. السجل
كل تغيير يُسجَّل: من غيّر، ومتى، ومن أي حالة إلى أي حالة، وما الملاحظة المرفقة، وهل أُرسل الإشعار ونتيجته. هذا السجل لا يُعدَّل ولا يُحذف من لوحة التحكم، وهو ما ترجع إليه عند شكوى عميل أو خلاف داخلي أو مراجعة أداء الفريق.
جدول الدورة ومعالجة الفشل
| الخطوة | الطرف | البيانات | معالجة الفشل |
|---|---|---|---|
| إنشاء الطلب | المستخدم في التطبيق | الخدمة، الحقول، المرفقات، الموقع، معرّف المحاولة | رسالة واضحة عند نقص الحقول، وإعادة محاولة آمنة عند انقطاع الشبكة دون تكرار الطلب |
| الاستقبال والحفظ | الواجهة الخلفية | هوية المستخدم، الطلب، الحالة الأولى، رقم الطلب | رفض البيانات غير الصالحة برسالة مفهومة، وعدم اعتماد الدفع قبل تأكيد البوابة |
| الظهور في اللوحة | الموظف أو المشرف | قائمة الطلبات حسب الصلاحية والفرع ونوع الخدمة | تنبيه للطلبات التي تجاوزت مدة انتظار يحددها النشاط، ومشرف يرى غير الموزَّع منها |
| تغيير الحالة | الموظف | الحالة الجديدة، السبب أو الملاحظة، رقم النسخة | منع الانتقالات غير المسموحة، ورفض التحديث المبني على نسخة قديمة |
| الإشعار | الخادم وخدمات الإشعار | نص الحالة، رمز الجهاز، قناة بديلة عند الحاجة | إعادة المحاولة، وحذف رموز الأجهزة المنتهية، وعلامة «لم يصل» في اللوحة |
| السجل | النظام | المستخدم، الوقت، الحالة السابقة واللاحقة، نتيجة الإشعار | سجل للإضافة فقط، لا يُعدَّل من الواجهة، ويُنسخ احتياطياً مع البيانات |
ماذا لو فشل الإشعار؟
افترض أن الإشعار سيفشل أحياناً، لأنه سيفشل فعلاً: قد يكون المستخدم أوقف الإشعارات من إعدادات جهازه، أو أعاد تثبيت التطبيق فانتهى رمز جهازه القديم، أو كان الجهاز مغلقاً مدة طويلة، أو لم تسلّم خدمة الإشعارات الرسالة. التصميم السليم لا يمنع هذا، بل يجعله غير مؤذٍ:
- الحالة الصحيحة تظهر داخل التطبيق كلما فتحه المستخدم، سواء وصل الإشعار أم لا.
- الخادم يعيد المحاولة على فترات متباعدة، ويحذف رموز الأجهزة التي تعيد الخدمة أنها لم تعد صالحة.
- الحالات التي لا يجوز أن تفوت المستخدم، مثل رفض طلب مدفوع أو تغيير موعد، تُرسل معها رسالة نصية أو بريد.
- لوحة التحكم تعرض للموظف أن الإشعار لم يُسلَّم، ليتصل بالعميل إن كان الأمر عاجلاً.
- لا يُرسل إشعار قبل نجاح حفظ الحالة، وإلا قد يصل المستخدم إشعار «تم قبول طلبك» بينما فشل الحفظ.
كيف نبني هذه الدورة في مشاريعنا، وما حدودها
في طريقتنا المعتادة تُبنى الواجهة الخلفية ولوحة التحكم أولاً أو بالتوازي مع التطبيق، ثم تُضاف التكاملات المتفق عليها مثل بوابة الدفع والإشعارات والرسائل النصية. ويحصل العميل على وصول إلى لوحة التحكم فور جاهزيتها ليبدأ إدخال بياناته الحقيقية، ويستلم عند التسليم دليل استخدام اللوحة. ويشمل الاختبار السلوك عند ضعف الشبكة، ودورة الدفع كاملة بنجاحها وفشلها وإلغائها واسترجاعها، ثم اختبار قبول يجرّب فيه فريقك التطبيق على بيانات حقيقية. تفاصيل الأدوار والشاشات في صفحة تطبيق أعمال مع لوحة تحكم.
أما الحدود فيجب أن تكون واضحة من البداية:
- لا يستطيع أي مطوّر أن يضمن وصول كل إشعار، لأن ذلك يتوقف على خدمات Apple وGoogle وإعدادات جهاز المستخدم. ما نلتزم به هو أن تكون الحالة صحيحة داخل التطبيق وأن يظهر فشل الإشعار في اللوحة.
- الرسائل النصية وبوابة الدفع خدمات من أطراف أخرى، رسومها وتعاقدها على الجهة.
- عدد الحالات والأدوار وقواعد التوزيع والتكامل مع أنظمتك الحالية كلها تدخل في النطاق وتؤثر في التقدير، ولا يمكن تحديدها بعبارة عامة.
أخطاء شائعة في تحديد هذه الدورة
- كتابة «إشعارات للمستخدم» في النطاق دون تحديد أي حالة ترسل إشعاراً، ولمن، وبأي نص.
- الاعتماد على الإشعار وحده لإبلاغ معلومة مهمة لا تظهر داخل التطبيق.
- حالات مبهمة مثل «قيد المعالجة» تُستخدم لكل شيء، بلا انتقالات محددة.
- لوحة تحكم بلا صلاحيات، فيرى كل موظف كل الطلبات ويعدّلها.
- سجل يمكن تعديله أو غياب السجل أصلاً، فلا يُعرف من غيّر ماذا.
- اختبار المسار الناجح فقط، دون تجربة الرفض والإلغاء وانقطاع الشبكة وفشل الإشعار.
قائمة تحقق قبل اعتماد النطاق
- قائمة مكتوبة بالحالات والانتقالات المسموحة، ومن يملك صلاحية كل انتقال.
- لكل حالة: هل ترسل إشعاراً؟ بأي نص؟ وهل لها قناة بديلة؟
- الأدوار في لوحة التحكم وما يراه ويعدّله كل دور، وقواعد توزيع الطلبات.
- آلية منع الطلب المكرر، وسلوك التطبيق عند انقطاع الشبكة أثناء الإرسال.
- اعتماد الدفع بتأكيد من البوابة إلى الخادم، لا من التطبيق.
- معالجة تعارض موظفين على الطلب نفسه.
- سجل للإضافة فقط، وشاشة لعرضه في اللوحة.
- سيناريو اختبار قبول يشمل: طلباً ناجحاً، ورفضاً بسبب، وإلغاءً، وفشل إشعار، وموظفَين على طلب واحد.
أسئلة شائعة
هل وصول الإشعار مضمون؟
لا. خدمات الإشعارات لدى Apple وGoogle لا تضمن التسليم، والمستخدم قد يوقفها. لذلك تُصمَّم الدورة بحيث تكون الحالة داخل التطبيق هي المرجع، ويظهر فشل الإشعار في اللوحة، وتُضاف قناة بديلة للحالات الحرجة.
هل يستخدم الموظفون لوحة ويب أم تطبيقاً على الجوال؟
يتوقف ذلك على طبيعة العمل. الموظف المكتبي يناسبه غالباً لوحة ويب، والموظف الميداني قد يحتاج تطبيقاً أو واجهة جوال مختصرة لتغيير الحالة. حدّد ذلك في طلبك لأنه يغيّر النطاق.
هل يمكن أن تنتقل الطلبات إلى نظامنا الحالي؟
نعم، عبر واجهات API إذا كان نظامك يتيحها، مثل أنظمة ERP أو CRM. اذكر النظام في طلبك، وجهّز توثيق الربط وبيئة اختبار، لأن التكامل يؤثر مباشرة في التقدير والجدول.
كم حالة يحتاجها الطلب؟
أقل عدد يعبّر عن قرارات فعلية يتخذها فريقك. كل حالة إضافية تعني انتقالات وصلاحيات واختبارات ونصوص إشعارات، فابدأ بالحالات التي يتغير عندها ما يفعله أحد الطرفين.
هل يُحذف الطلب الملغى من النظام؟
الأفضل ألّا يُحذف. يبقى بحالة «ملغى» مع سببه في السجل، ويُخفى من القوائم اليومية، حتى تبقى التقارير وتاريخ العميل صحيحين.
الخطوة التالية
إذا كانت لديك دورة طلب تعمل اليوم يدوياً، فاكتب حالاتها كما يستخدمها فريقك فعلاً، ومن يغيّر كل حالة، ومتى يجب أن يعرف العميل. هذه الورقة وحدها تختصر جزءاً كبيراً من جلسة الاكتشاف وتجعل التقدير أدق. اطلب عرض سعر لتطبيقك.
فريق العمل
فريق تطبيقات برو — نصمم ونطوّر تطبيقات iOS و Android للشركات والجهات في المملكة العربية السعودية، من الفكرة حتى الإطلاق وما بعده.
لديك مشروع تطبيق؟
أرسل تفاصيله واحصل على نطاق عمل مكتوب وعرض سعر مفصّل خلال 24 ساعة.
احجز استشارة مجانية