وقتی کارفرما میگوید «اپلیکیشنی شبیه اسنپ میخواهم»، معمولاً منظورش کپی ظاهر یک برند نیست؛ منظور یک محصول چندنقشی است که مسافر درخواست ثبت میکند، راننده نزدیک درخواست را میبیند، سفر روی نقشه پیش میرود، پرداخت انجام میشود و تیم عملیات از پشت صحنه همهچیز را کنترل میکند. ارزش اصلی چنین محصولی در هماهنگی این بخشهاست.
نام «اسنپ» در این مقاله صرفاً برای توضیح یک الگوی شناختهشده محصول چندنقشی استفاده شده است؛ این مطلب درباره معماری محصول مستقل است و هیچ ادعای ارتباط، نمایندگی یا کپیبرداری از برند دیگری ندارد.
یک سامانه تاکسی اینترنتی چند محصول همزمان است
نسخه واقعی این مدل معمولاً حداقل سه تجربه دارد: اپ مسافر، اپ راننده و داشبورد مدیریت. هرکدام رابط و نیاز متفاوتی دارند اما حساب کاربری، سفر، پرداخت، اعلان و قوانین کسبوکار باید از یک هسته مشترک دریافت شوند.
اپ مسافر چه مسئولیتی دارد؟
ثبت مبدأ و مقصد، مشاهده برآورد، درخواست خودرو، دیدن وضعیت راننده، ارتباط با پشتیبانی، پرداخت و ثبت امتیاز مسیر اصلی مسافر است. هر مرحله باید وضعیت واضح داشته باشد؛ کاربر نباید نداند درخواستش ارسال شده، راننده قبول کرده یا سفر لغو شده است.
اپ راننده فقط نسخه دیگری از اپ مسافر نیست
راننده نیاز به وضعیت آنلاین و آفلاین، دریافت درخواست، پذیرش یا رد، مسیریابی، شروع و پایان سفر، مشاهده درآمد و سوابق دارد. طراحی این اپ باید مصرف باتری، کیفیت GPS، اینترنت ضعیف و عملیات سریع هنگام رانندگی را جدی بگیرد.
چرخه سفر باید مثل یک ماشین حالت طراحی شود
درخواستشده، در انتظار راننده، پذیرفتهشده، راننده در مسیر مسافر، سفر شروعشده، تکمیلشده و لغوشده نمونه وضعیتهای اصلی هستند. اگر این وضعیتها در بکاند دقیق تعریف نشوند، اپ راننده، مسافر و پنل مدیریت خیلی زود اطلاعات متفاوت نشان میدهند.
نقشه و موقعیت لحظهای؛ فقط گذاشتن یک Marker نیست
ارسال موقعیت راننده باید با فاصله زمانی و دقت مناسب انجام شود تا هم تجربه کاربر روان بماند و هم مصرف باتری و شبکه کنترل شود. انتخاب راننده مناسب نیز میتواند بر اساس فاصله، منطقه خدمت، وضعیت فعال، ظرفیت و قواعد کسبوکار انجام شود.
پرداخت، کیف پول و تسویه
پرداخت آنلاین، اعتبار داخلی، تخفیف، بدهی، کمیسیون و تسویه راننده باید از همان ابتدا مدل داده مشخصی داشته باشند. حتی اگر نسخه اول فقط پرداخت ساده داشته باشد، طراحی درست تراکنشها جلوی بازنویسی پرهزینه در فاز بعد را میگیرد.
پنل مدیریت مرکز عملیات محصول است
اپراتور باید سفرهای فعال، رانندگان، کاربران، شکایتها، لغوها، پرداختها و رخدادهای مهم را سریع ببیند. گزارشهای عملیاتی زمانی ارزش دارند که از داده واقعی سفر ساخته شوند؛ نه اینکه تیم مجبور باشد دوباره اطلاعات را در فایل دیگری وارد کند.
نسخه اول را کوچک اما کامل تعریف کنید
MVP خوب لازم نیست از روز اول همه قابلیتهای سوپراپ را داشته باشد. کافی است یک شهر یا محدوده، یک مدل خودرو، یک روش قیمتگذاری، سفر کامل، پرداخت و پنل عملیات بهدرستی کار کنند. بعد از استفاده واقعی میتوان کیف پول پیشرفته، باشگاه مشتریان، چند سرویس و الگوریتمهای تخصیص پیچیدهتر را اضافه کرد.
Android، iOS و وباپ چگونه کنار هم قرار میگیرند؟
اگر API و بکاند مستقل طراحی شوند، اپ Android با Kotlin یا React Native، نسخه iOS و حتی وباپ میتوانند روی همان کاربران و سفرها کار کنند. داشبورد نیز از همان سرویسها استفاده میکند و بنابراین تغییر وضعیت در یک بخش بلافاصله برای بخشهای دیگر قابل مشاهده است.
برای شروع چه اطلاعاتی لازم است؟
شهر یا محدوده سرویس، نقشها، نوع خودرو یا خدمت، روش محاسبه هزینه، نحوه پذیرش سفر، پرداخت، کمیسیون، لغو، پشتیبانی و خروجیهای نسخه اول مهمترین ورودیهای نیازسنجی هستند. بعد از مشخص شدن این موارد میتوان معماری و محدوده واقعی پروژه را تعیین کرد.
جمعبندی
ساخت اپلیکیشن با مدل تاکسی اینترنتی بیش از طراحی چند صفحه موبایل است. محصول موفق از هماهنگی اپ مسافر، اپ راننده، نقشه، بکاند، پرداخت و پنل عملیات ساخته میشود. بهتر است بهجای شروع از فهرست امکانات یک برند موجود، مسیر اصلی کسبوکار خودتان را تعریف کنید و نسخه اول را بر همان اساس بسازید.
اگر این پروژه را برای کسبوکار خودتان میخواهید
مسیرهای تخصصی مرتبط با این مقاله
درباره نویسنده
رضا اسماعیل گل
طراح سایت، اپلیکیشن و سامانههای خدماتی با ۲۰ سال تجربه کاری. در این بلاگ تجربههای اجرایی پروژههای فارسی را به زبان کاربردی منتشر میکنم.
این موضوع را برای پروژه خودتان میخواهید؟
نیاز، بودجه و نسخه اول پروژه را بررسی میکنیم تا قبل از توسعه مشخص شود چه چیزی واقعاً باید ساخته شود.