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