روایت یک پروژه · ۲۰۲۵
Rojaboom
پلتفرم آنلاین رزرو اقامتگاههای باکیفیت و لوکس در ایران
Frontend Developer · از صفر تا محصول لانچشده
مشاهده نسخه زندهrojaboom.vercel.app۰۲ — از صفر تا لانچ
کمتر از دو ماه تا ورژن 1
پروژه با deadline فشرده شروع شد؛ هدف این بود که نسخه اول در کمتر از دو ماه به محصولی قابللانچ و استاندارد برسد.
طراحیهای Figma همزمان با توسعه آماده و تحویل میشدند. development موازی با design پیش میرفت؛ یعنی تصمیمها روی بوم ثابت نمیماندند و باید در میانه ساخت، با تغییرهای واقعی کنار میآمدند.
- شروع از صفر تا محصول قابللانچ
- طراحی و توسعه موازی
- تمرکز روی استاندارد بودن ورژن 1
- فشار زمان بدون قربانی کردن پایهٔ محصول
۰۳ — یک پلتفرم، سه نقش
Guest، Host و Admin؛ سه زاویه به یک محصول.
روجابوم فقط صفحهٔ رزرو نبود. سه نقش اصلی، scope واقعی محصول را تعریف میکردند.
Frontend مربوط به Guest و Host با من بود. پنل Admin بهخاطر محدودیت شدید زمانی، در ادامه با Laravel پیادهسازی شد.
Guest
جستوجو، مشاهده اقامتگاه، انتخاب تاریخ و تکمیل مسیر رزرو.
تجربهای که باید ساده به نظر برسد؛ حتی وقتی پشت آن تقویم، قیمت و موجودی پیچیده باشد.
Host
ثبت اقامتگاه، مدیریت رزروها، تقویم، اطلاعات ملک و عملیات مالی.
جایی که عمق محصول دیده میشود؛ داشبورد عملیاتی برای میزبان واقعی.
Admin
لایه مدیریتی پلتفرم برای عملیات داخلی و پشتیبانی.
بهدلیل فشار زمان، این بخش در ادامه با Laravel ساخته شد.
۰۴ — تجربه Host
پشت یک تجربه ساده، یک سیستم کامل بود.
میزبان فقط «اقامتگاه ثبت نمیکرد». باید رزرو، تقویم، اطلاعات ملک و پول را در یک جریان بههمپیوسته مدیریت میکرد.
Host Dashboard باید همزمان شفاف و عملیاتی میبود: مسیرهای چندمرحلهای، جدولهای پویا، فرمهای ساده و پیچیده، و تعاملهایی که در کار روزمره میزبان معنا داشته باشند.
- داشبورد میزبان
- مدیریت رزروها
- مدیریت تقویم
- اطلاعات اقامتگاه
- عملیات مالی
- جریانهای چندمرحلهای
۰۵ — دوازده مرحله تا ثبت اقامتگاه
یک business flow پیچیده؛ نه فقط یک فرم طولانی.
ثبت اقامتگاه توسط Host دوازده مرحله وابسته داشت که باید با ترتیب مشخص تکمیل میشدند.
در طول توسعه، ساختار مراحل، اطلاعات موردنیاز، validationها، dependency بین مراحل و حتی ترتیب UX بارها تغییر کرد. کار اصلی نگه داشتن انسجام این جریان بود؛ وقتی محصول هنوز در حال تعریف خودش بود.
دوازده مرحله وابسته
- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 01
وابستگی بین مراحل
هر مرحله به داده و تصمیم مرحله قبل تکیه داشت. نمیشد flow را مثل صفحههای مستقل طراحی کرد.
- 02
تغییر مداوم requirements
ساختار مراحل و اطلاعات لازم چند بار عوض شد؛ سیستم باید قابلبازآرایی میماند، نه شکننده.
- 03
Validation زنده
قواعد اعتبارسنجی با محصول عوض میشدند. باید خطاها شفاف میماندند و مسیر کاربر نمیشکست.
- 04
بازطراحی ترتیب اطلاعات
UX و اولویتبندی فیلدها چند بار جابهجا شد. معماری flow باید با این نوسان کنار میآمد.
۰۶ — تقویمی که از صفر ساخته شد
تقویم؛ یکی از ستونهای فنی محصول.
تقویم روجابوم از صفر پیادهسازی شد؛ نه بهعنوان ویجت تزئینی، بلکه بهعنوان سطح تعامل اصلی رزرو و مدیریت موجودی.
اینجا UX و engineering به هم میرسیدند: انتخاب بازه، قیمت روزانه، روزهای مسدود، حالتهای مختلف نمایش و مدیریت state در تعاملهای واقعی.
- 01
انتخاب بازهای
Range selection برای مسیر رزرو؛ با رفتار قابلپیشبینی در شروع، پایان و اصلاح بازه.
- 02
قیمت هر روز
نمایش قیمت روزانه داخل خود تقویم؛ نه جدا از تصمیم کاربر.
- 03
روزهای پرشده توسط Host
مسدود بودن یا پر بودن روزها باید در لحظه خوانا و قابلاتکا میبود.
- 04
حالتهای Single و Double
دو mode نمایش برای سناریوهای متفاوت انتخاب و مرور تاریخ.
- 05
Modal و صفحه کامل
همان تقویم هم در Modal باز میشد، هم در صفحه اقامتگاه بهصورت کامل نمایش داده میشد.
- 06
تعطیلات و state پیچیده
نمایش تعطیلات در کنار مدیریت interactionها و stateهایی که یک پلتفرم رزرو واقعی به آن نیاز دارد.
۰۷ — چهلوسه صفحه پشت تجربه
عرض واقعی محصول؛ نه فقط چند صفحهٔ ویترینی.
نسخه نهایی حدود ۴۳ صفحه داشت. عدد مهم نیست؛ نوع کار مهم است.
این صفحات ترکیب workflowهای رزرو، رابطهای عملیاتی Host، فرمهای سبک و سنگین، جدولهای پویا، انتخاب موقعیت روی نقشه و جریانهای چندمرحلهای بودند.
43
رزرو از سمت Guest
مسیر کشف اقامتگاه تا انتخاب تاریخ و تکمیل رزرو.
ثبت و مدیریت اقامتگاه
جریانهای ساخت، ویرایش و نگهداری اطلاعات ملک توسط Host.
عملیات روزانه Host
رزروها، تقویم، داشبورد و تصمیمهای روزمره میزبان.
فرمها و جدولها
از فرمهای ساده تا فرمهای پیچیده، به همراه dynamic tables.
جریانهای چندمرحلهای
فرآیندهایی که باید مرحلهبهمرحله پیش بروند و حالت را حفظ کنند.
انتخاب موقعیت روی نقشه
تعامل map-based برای مشخص کردن موقعیت اقامتگاه.
۰۸ — ساختن زیر محدودیت
Ship کردن وقتی زیرساخت همکار نیست.
بخشی از توسعه و deployment در شرایط سخت اینترنت و زیرساخت انجام شد؛ از قطعی اینترنت بینالملل تا محدودیت دسترسی به package registryها و مشکلات دیتاسنتر.
این بخش داستان درام نیست. نمونهای است از حل مسئله وقتی ابزارهای همیشگی در دسترس نیستند و محصول باید همچنان بیرون برود.
- 01
قطع دسترسیها
قطعی اینترنت بینالملل و محدودیت registryها، مسیر معمول نصب و انتشار را میبست.
- 02
مشکلات زیرساختی
نوسان دیتاسنتر و شرایط ناپایدار، debugging و deployment را از حالت روتین خارج میکرد.
- 03
مسیر جایگزین انتشار
در یکی از deploymentهای سخت، پروژه با Liara CLI و registry mirrorهای داخلی جایگزین برای نصب packageها deploy شد.
نتیجه برای من روشن بود: کیفیت مهندسی فقط در شرایط ایدهآل سنجیده نمیشود؛ در توانایی رساندن محصول وقتی محدودیت واقعی است هم سنجیده میشود.
۰۹ — فراتر از لانچ
محصول بعد از لانچ تمام نشد.
Version 1 فقط نقطه شروع بود. روجابوم بیش از یک سال در محیط واقعی کار کرد و با ترافیک واقعی پلتفرم روبهرو شد.
در این مدت featureهای جدید، bug fixها، تغییر requirementها و نیازهای عملیاتی مختلف روی همان پایه ادامه پیدا کرد.
- 01
لانچ فشرده
رسیدن Version 1 به محصول قابلاستفاده در کمتر از دو ماه.
- 02
استفاده واقعی
بیش از یک سال کار با کاربر، رزرو و عملیات واقعی روی پلتفرم.
- 03
تکرار و نگهداری
feature، اصلاح باگ، تغییر نیازها و پاسخ به فشارهای عملیاتی روزمره.
۱۰ — وقتی stack عوض شد
Migration؛ تصمیم سازمانی، نه حکم فنی.
بیش از یک سال بعد، کل پروژه به Laravel منتقل شد.
اینجا نقطه مهمی است: این جابهجایی را نباید شکست Next.js خواند. نسخه Next.js از نظر فنی مشکل نداشت و در محیط واقعی هم درست کار میکرد.
تصمیم migration بیشتر به دلایل سازمانی و operational گرفته شد؛ نه بهخاطر ناتوانی فنی stack قبلی.
چه چیزی تصمیم را شکل داد
نیاز به پشتیبانی سریعتر
کسبوکار به تغییر و پاسخ عملیاتی مداوم نیاز داشت.
هماهنگی Frontend و Backend
featureهای جدید به هماهنگی نزدیکتر بین دو سمت احتیاج داشتند.
ساختار تیم
سه Laravel developer در تیم بودند؛ تخصص Frontend تنها بود.
کاهش ریسک عملیاتی
سادهتر شدن پشتیبانی و توسعه برای تیمی که از قبل روی Laravel متمرکز بود.
انتخاب تکنولوژی فقط مسئله technical capability نیست؛ باید با ساختار تیم، عملیات و نیاز کسبوکار هم همراستا باشد.
۱۱ — آنچه بر عهده من بود
Scope واقعی مسئولیت.
از معماری Frontend تا deployment؛ اینها بخشهایی بودند که در پروژه واقعاً انجام دادم.
- 01معماری Frontend
- 02تجربه Guest
- 03داشبورد Host
- 04جریانهای رزرو
- 05فرآیند ثبت اقامتگاه
- 06تقویم سفارشی
- 07فرمها و validation
- 08Dynamic tables
- 09تعامل با نقشه
- 10اتصال به API
- 11UI واکنشگرا
- 12رفع باگ
- 13Deployment
روجابوم فقط یک لانچ سریع نبود.
تمرینی بود برای ساختن محصول واقعی، زیر فشار زمان، تغییر مداوم و محدودیتهای عملیاتی.