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