منظومة تشغيل النقل الطلابي — الاتحاد باص ستة منتجات مترابطة، تعمل حتى وقت انقطاع الإنترنت

The problem

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

The approach

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

What we built

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