الموقع وتطبيق الجوال في حزمة واحدة: مثال Skymar

كثيرًا ما تبني الشركة اللوجستية حضورها الرقمي على مراحل متفرقة: يبني فريقٌ الموقع، ثم يُسند تطبيق الجوال بعد سنوات إلى فريق آخر، ويُحاوَل حل ربط البيانات بينهما لاحقًا. أما مع عميلنا Skymar Lojistik فقد سلكنا طريقًا مختلفًا: طوّرت الموقع المؤسسي، وتطبيق العملاء لنظامي iOS وAndroid، والواجهة الخلفية للتطبيق، والنشر في المتاجر من جهة واحدة. أنا Berke Özyaşar؛ وفي هذا المقال أشرح من خلال مثال Skymar لماذا ينجح هذا النهج، وما الذي أنتبه إليه في المشروع المتكامل.

مكوّنات الحزمة

• الموقع: www.skymar.com.tr، بالتركية والإنجليزية. صفحات النقل البحري والجوي والبري والسككي والتخزين، ونموذج لطلب عرض السعر يرسل الطلب بالبريد الإلكتروني، وحاسبة CBM، ودليل Incoterms 2023، ونموذج توظيف مع رفع السيرة الذاتية، والأخبار. يعمل بـASP.NET Web Forms على IIS.
• تطبيق الجوال: قاعدة شيفرة واحدة لنظامي iOS وAndroid بـReact Native 0.78.
• الواجهة الخلفية: Node.js وExpress، وPrisma وSQL Server؛ وSocket.IO للمحادثة الفورية، وFirebase Cloud Messaging للإشعارات.
• شاشات الموظفين والإدارة: إرسال الإشعارات، ومتابعة المستخدمين وسجلات العمليات، وإعدادات التطبيق.
• النشر في المتاجر: Google Play وApp Store، على حسابات Skymar الخاصة.

لماذا فريق واحد

الموقع والتطبيق وجهان لشركة واحدة؛ والعميل لا يراهما منتجين منفصلين، بل يرى فيهما الشركة نفسها. وعندما يعمل فريق واحد تظهر عدة فوائد ملموسة:

• لغة ومصطلحات متسقة: الطريقة التي يُشرح بها FCL أو HBL في الموقع هي نفسها في التطبيق. وتُعدّ النصوص التركية والإنجليزية في الجانبين وفق القرارات نفسها.
• جهة تواصل واحدة: إذا كان تغيير ما يمس الموقع والتطبيق معًا، فلا تحتاج الشركة إلى التنسيق بين مورّدَين مختلفين.
• قرارات الواجهة الخلفية تُتخذ من البداية: أي بيانات سيصل إليها التطبيق وبأي صلاحية، وعند أي أحداث تُرسل الإشعارات، وكيف تُعرض المستندات، كل ذلك يُخطَّط له منذ البداية.
• النشر والصيانة في جدول واحد: تحديثات المتاجر وتغييرات الخادم ومحتوى الموقع تصبح أجزاءً من الخطة نفسها.

واجهة خلفية مشتركة

في قلب الحزمة الواجهة الخلفية التي يتواصل معها تطبيق الجوال. فالتطبيق لا يتصل بقاعدة البيانات مباشرة؛ بل تتحقق واجهة API التي كتبتها بـNode.js وExpress من الهوية، ولا تعيد لكل عميل إلا شحناته ومستنداته وفواتيره هو. استخدمت Prisma للوصول إلى البيانات، والبيانات محفوظة في SQL Server. وتفصل هذه الطبقة واجهة التطبيق عن بنية البيانات: فإذا أُضيفت لاحقًا شاشة جديدة أو عميل برمجي آخر، أمكنه العمل عبر واجهة API نفسها، وتُدار الصلاحيات من نقطة واحدة.

ماذا يتضمن تطبيق العملاء

تُقسَّم الشحنات إلى تبويبات الحجز وفي الطريق والواصلة؛ ويجد العميل الشحنة التي يبحث عنها برقم B/L أو رقم الحاوية أو بمرجعه الخاص. ومن بطاقة الشحنة يُنتقل إلى مستندات HBL والفواتير. وتُصفّى الفواتير حسب حالة الدفع والفترة الزمنية، ويمكن تنزيلها ومشاركتها. وفي الخدمات اللوجستية سؤالان يطرحهما العملاء كثيرًا: "أين شحنتي؟" و"ما وضع فاتورتي؟". وقد بُنيت الشاشات الرئيسية للتطبيق حول هذين السؤالين.

الإشعارات والمحادثة

عبر Firebase Cloud Messaging تُرسل إشعارات فورية عند وصول السفينة، وعند ورود رسالة جديدة، وبشأن الفواتير. ومن المهم حصر الأحداث التي تُرسل عندها الإشعارات؛ فالمستخدم الذي يتلقى إشعارًا مع كل تغيير صغير ينتهي به الأمر إلى إيقاف الإشعارات. وفي جانب المحادثة يستطيع العميل أن يرسل إلى ممثله صورًا ومستندات ورسائل صوتية من داخل التطبيق، وتُنقل الرسائل فوريًا عبر Socket.IO. ووجود المحادثة في التطبيق يجمع المراسلات المتفرقة بين البريد الإلكتروني والهاتف في مكان واحد مع معلومات الشحنة.

شاشات الموظفين

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

النشر في المتاجر على حساب العميل

التطبيق منشور على Google Play، وعلى App Store منذ 23 يونيو 2026، عبر حسابات المطوّر الخاصة بـSkymar. ويضمن هذا الخيار أن يظهر التطبيق في المتجر باسم الشركة وأن يبقى الحساب ملكًا لها. ومن أجل النشر أعددت أيضًا صفحات سياسة الخصوصية، وطلب حذف الحساب، وسلامة الأطفال. وتخطيط هذا النوع من الصفحات التي تتطلبها مراجعة المتاجر بالتوازي مع جانب الويب ميزة أخرى للعمل بفريق واحد.

لغتان ومنصتان

الموقع والتطبيق كلاهما بالتركية والإنجليزية. وقاعدة الشيفرة الواحدة المكتوبة بـReact Native تغذّي إصداري iOS وAndroid معًا؛ فعند إضافة ميزة يمكن إطلاقها على المنصتين في الوقت نفسه. ولأن الواجهة الخلفية مشتركة، يرى العملاء على المنصتين البيانات نفسها.

كيف أخطط لمشروع متكامل

عندما يجتمع الموقع والتطبيق والواجهة الخلفية في مشروع واحد، يصبح ترتيب العمل مهمًا. ونهجي العام كالتالي:

• البيانات والصلاحيات أولًا: لا أصمم الشاشات قبل أن يتضح أي شحنات ومستندات وفواتير سيراها العميل، وأي عمليات سيجريها الموظفون.
• ثم الواجهة الخلفية: بمجرد إنشاء واجهة API والبنية التحتية للإشعارات، يمكن تطوير التطبيق ببيانات حقيقية.
• الموقع والتطبيق بالتوازي: لأن الموقع لا يعتمد على الواجهة الخلفية، يمكن أن يتقدم العمل فيه أثناء تطوير التطبيق؛ وتُكتب المصطلحات والنصوص للجانبين معًا.
• التحضير للمتاجر من البداية: تُجهَّز حسابات المطوّر الخاصة بالشركة، ونصوص الخصوصية، والحساب التجريبي للمراجعة بالتزامن مع التطوير؛ فلا ينتظر النشر حين يصبح التطبيق جاهزًا.

متى تكون الحزمة الواحدة منطقية

• إذا كان موقع الشركة سيُجدَّد وكان تطبيق الجوال مطروحًا أيضًا
• إذا كانت البيانات التي سيعرضها التطبيق تأتي من النظام الحالي للشركة، ويجب بناء هذا الربط مرة واحدة وبشكل صحيح
• إذا لم يكن لدى الشركة فريق برمجيات داخلي ينسّق بين الموقع والتطبيق والخادم

وإذا كانت الحاجة إلى موقع فقط أو إلى تطبيق فقط، فيمكن بطبيعة الحال تنفيذ كل جزء على حدة؛ فالحزمة الواحدة ليست إلزامًا، بل خيار يخفف عبء التنسيق.

مشاريع مشابهة

طوّرت سابقًا لعملاء شركات لوجستية تطبيقي Buzmavi وMitlog، وكلاهما منشور على App Store وGoogle Play عبر الحسابات الخاصة بالشركتين. وقد نقل Skymar هذه الخبرة إلى حزمة واحدة تضم أيضًا الموقع والواجهة الخلفية وشاشات الموظفين. وشرحت كيف أعمل في صفحة تطوير تطبيقات الجوال للجانب الخاص بالجوال، وفي صفحة تطوير مواقع الشركات للجانب الخاص بالموقع.