في هذه الصفحة
دراسة حالة · التنقل والمواقف

حرّكHarrak

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

تطبيق حرّك لإيجاد أقرب موقف سيارات
  • شهرانمدة البناء
  • 2منصات النشر

الوضع الذي بُني له حرّك#

حرّك منتج من داخل الشركة، بُني حول ملاحظة واحدة: المواقف موجودة في المدن السعودية، لكنها ليست حيث يحتاجها السائق ولا في الوقت الذي يحتاجها فيه.

في الشارع الواحد مواقف خاصة تبقى فارغة ساعات طويلة كل يوم، بينما تدور سيارات على بُعد أمتار منها بحثاً عن مكان. لا ينقص المدينة موقف بقدر ما ينقصها وسيلة تصل بين مالك مكان فارغ وسائق يحتاجه الآن.

الطرفان يخسران في الوضع الحالي. السائق يدفع وقتاً ووقوداً وتوتراً قبل موعد لا يحتمل التأخير، ومالك الموقف يملك أصلاً لا يدرّ شيئاً في الساعات التي لا يستخدمه فيها.

التحدي#

المنتج سوق ذو طرفين، وهذا أصعب من تطبيق يخدم فئة واحدة. الطرفان يجب أن يصلا معاً: تطبيق مليء بالسائقين ولا مواقف فيه لا قيمة له، وتطبيق مليء بالمواقف ولا سائقين فيه لا يعطي المالك سبباً لتحديث بياناته.

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

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

والقيد الثالث أن الاستخدام يحدث في السيارة قبل الانطلاق أو أثناء البحث، أي في أسوأ سياق ممكن للتصفح: شاشة صغيرة، وانتباه منقسم، وثوانٍ معدودة قبل أن يقرر السائق العودة إلى الدوران.

ما قررنا ألا نبنيه#

استبعدنا الدفع داخل التطبيق من النسخة الأولى. بوابة دفع في سوق ذي طرفين تعني محافظ ومستحقات وتسويات ومردودات ونزاعات بين طرفين لا يعرف أحدهما الآخر، وهي منظومة أكبر من التطبيق نفسه ولا معنى لبنائها قبل أن نتأكد أن الطرفين يستخدمان الخدمة أصلاً.

واستبعدنا كذلك أجهزة استشعار في المواقف. حساسات ترصد الإشغال آلياً تعطي دقة أعلى، لكنها تحوّل المنتج من تطبيق إلى مشروع تركيبات وصيانة ميدانية، وتحصر التغطية في المواقف التي ندفع كلفة تجهيزها.

ما نفّذناه#

تطبيق جوال واحد بواجهتين حسب الدور، وخادم خلفي، ولوحة تحكم للإدارة، وصفحة تعريفية للمنتج. الواجهات صُمِّمت ضمن تصميم واجهات وتجربة المستخدم، والتطبيق بُني ضمن برمجة تطبيقات الجوال.

تطبيق السائق#

يفتح السائق التطبيق فيرى المواقف المتاحة حوله على الخريطة، ويختار ما يناسب وجهته ويحجزه. رتّبنا الشاشة الأولى حول الخريطة لا حول قائمة، لأن قرار الموقف قرار مكاني قبل أن يكون قرار سعر.

واجهة مالك الموقف#

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

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

الخادم ولوحة التحكم#

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

صفحة المنتج#

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

القرارات التي حسمت المشروع#

القرار الأول: تطبيق هجين لا تطبيقان أصليان. الفرق بين المسارين ومتى يستحق كل منهما شرحناه في الفرق بين التطبيق الأصلي والهجين، وهنا رجّحت الكفة قاعدة كود واحدة تصل إلى أندرويد وiOS معاً في شهرين.

لو بنيناه أصلياً

أداء أعلى في الرسوم الثقيلة، مقابل بناء كل شاشة مرتين وصيانتها مرتين، ومدة تقارب الضعف قبل أول مستخدم.

ما بنيناه فعلاً

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

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

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

النتيجة#

بُني حرّك في شهرين بفريق صغير، وهو منشور اليوم على App Store وGoogle Play وعمره نحو أربعة أشهر منذ اكتمال بنائه. تطبيق المتاجر تجاوز مراجعة المتجرين، وهي خطوة تتعثر فيها تطبيقات كثيرة لأسباب لا صلة لها بالكود.

النسخة التجريبية قرار لا نقص. سوق ذو طرفين يُفتح للعامة قبل أن يمتلئ أحد طرفيه يحرق انطباع مستخدميه الأوائل، لأن السائق الذي يفتح خريطة خالية من المواقف لا يعود إليها بعد شهر ليرى إن امتلأت. نفتح على دفعات ونتابع كل دفعة.

المنظومة تعمل بطرفيها: مالك يضيف موقفه ويحدد أوقات إتاحته، وسائق يجد الموقف على الخريطة ويحجزه. القيمة التي بُني لأجلها قائمة في النسخة الحالية، حتى قبل إضافة الدفع.

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

ما بعد الإطلاق#

المنتج في مرحلة تجريبية، ولا ننشر أرقام تحميل ولا حجوزات عنه. الرقم في هذه المرحلة يقيس دعوات ومحاولات أكثر مما يقيس سوقاً، ونشره يضلل أكثر مما يفيد.

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

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

الخطوة التالية

لديك مشروع مشابه؟

احصل على استشارة مجانية وعرض سعر تفصيلي خلال يوم عمل واحد.

ماذا يحدث بعد ذلك؟

  • استشارة مجانية لمدة 30 دقيقة
  • عرض سعر تفصيلي خلال يوم عمل واحد
  • بداية التطوير خلال أسبوع