محصول بر پایه کار واقعی
نقشها، وظایف و استثناهای فرایند به Story و معیار پذیرش تبدیل میشوند؛ لیست بلند قابلیتها جای تحلیل را نمیگیرد.
پنل، پورتال و سامانه اختصاصی
برای فرایندی که با یک سایت معرفی حل نمیشود، وباپلیکیشن، پنل مدیریتی یا پورتال اختصاصی طراحی و توسعه میکنیم.
از MVP تا توسعه — دامنه روشن، معماری قابل تغییر و انتشار مرحلهای
پیش از طراحی و اجرا
سایت شرکتی اطلاعات و مسیر تماس را ارائه میدهد؛ نرمافزار تحت وب به کاربر اجازه میدهد کاری را انجام دهد: رزرو کند، پرونده بسازد، وضعیت را تغییر دهد، گزارش بگیرد یا با نقشهای دیگر همکاری کند. نمونههای این نوع پروژه، از پلتفرم رزرو کارواش تا پنل مدیریت پکیج آژانس مسافرتی، در نمونه سامانههای تحت وب آمدهاند.
به همین دلیل نیت این صفحه با طراحی سایت متفاوت است. موضوع اصلی، منطق محصول، گردش داده، سطح دسترسی و قابلیت نگهداری سیستم است.
نقشها، وظایف و استثناهای فرایند به Story و معیار پذیرش تبدیل میشوند؛ لیست بلند قابلیتها جای تحلیل را نمیگیرد.
داشبورد و فرم بر اساس تصمیمی که کاربر باید بگیرد طراحی میشوند، نه برای پرکردن صفحه با نمودار.
معماری، تست و استقرار طوری برنامهریزی میشوند که نسخه اول قابل استفاده باشد و مسیر نسخههای بعد بسته نشود.
دامنه خدمت
دامنه نهایی بر اساس نیاز، زیرساخت و اولویت نسخه قابل اجرا مشخص میشود.
پنل مدیریت اختصاصی
پنل مدیریت اختصاصی (Custom Admin Panel) محیطی است که برای کارهای روزمره همان کسبوکار ساخته میشود، نه پیشخوان عمومی یک سیستم مدیریت محتوا. زمانی لازم میشود که تیم شما با دادهای کار میکند که محتوا نیست، مثل سفارش، پرونده، نوبت یا موجودی، و هر نقش فقط باید بخشی از آن را ببیند و تغییر دهد. اگر کار اصلی انتشار صفحه و مقاله است، پیشخوان وردپرس معمولاً کافی است و پنل اختصاصی فقط هزینه نگهداری اضافه میکند.
| معیار | پیشخوان آماده سیستم مدیریت محتوا | پنل مدیریت اختصاصی |
|---|---|---|
| نوع داده | صفحه، نوشته، رسانه و محصولی که با افزونه اضافه میشود. | هر موجودیت کاری مثل پرونده، قرارداد، نوبت یا درخواست، با فیلدها و رابطههای خودش. |
| نقش و دسترسی | نقشهای عمومی مثل مدیر و نویسنده؛ دسترسی دقیقتر با افزونه و محدودیت. | دسترسی در سطح عملیات و رکورد؛ مثلاً کارشناس فقط پروندههای واحد خودش را ببیند. |
| گردش کار | پیشنویس و انتشار؛ تأیید چندمرحلهای با افزونه یا کدنویسی. | وضعیتها، تأییدها و اعلانها طبق فرایند واقعی تیم ساخته میشوند. |
| گزارش | گزارشهای محدود یا ابزار بیرونی. | گزارش و داشبورد بر اساس تصمیمی که مدیر باید بگیرد. |
| هزینه و نگهداری | راهاندازی سریعتر و ارزانتر؛ بهروزرسانی هسته و افزونهها بر عهده شماست. | هزینه طراحی و توسعه بیشتر؛ هر تغییر بعدی توسعه و آزمون میخواهد. |
راه سومی هم هست: وردپرس برای محتوا و یک پنل جدا برای عملیات که از راه API به هم وصل میشوند. امکانات لازم، روش محاسبه هزینه و اشتباهات رایج سفارش پنل را در راهنمای طراحی پنل مدیریت اختصاصی ببینید.
پروژههای قابل بررسی
این مطالعهها منطق محصول، مسیر کاربر و دامنه اجرا را نشان میدهند، نه آمار رشد یا نتیجه فروش.

پلتفرم جستوجو و رزرو
مشتری کارواشها را با خدمت، قیمت و نزدیکترین نوبت مقایسه میکند و صاحب کارواش مسیر ثبت و پنل جدا دارد. دامنه کار از استراتژی محصول تا توسعه وباپلیکیشن بود.

محصول تولید محتوا با هوش مصنوعی
نقش ایران دیزاینر در این محصول، مشاوره طراحی و پیادهسازی بود. کاربر نوع خروجی را انتخاب میکند، بریف فارسی و مرجع میدهد و نتیجه را بازبینی میکند.

محصول آماده با پنل مدیریت
آژانس پیش از خرید، دموی زنده را میبیند و بعد از تحویل، تور، هتل، اسلاید و محتوای سایت را از پنل مدیریت فارسی خودش تغییر میدهد. فرانتاند و بکاند پکیج در دامنه کار بود.
فرایند همکاری
هر مرحله یک تصمیم، خروجی قابل بازبینی و معیار پذیرش روشن دارد.
کاربر، مسئله، فرایند و معیار پذیرش نسخه اول مشخص میشود.
نقشها، مسیرها، مدل داده و نقاط اتصال قبل از هزینه توسعه بررسی میشوند.
قابلیتها در بخشهای قابل تحویل ساخته و با سناریوی واقعی تست میشوند.
لاگ، خطا، پشتیبانی و بازخورد استفاده واقعی برای نسخه بعدی وارد Backlog میشود.
مثال توضیحی
مشتری درخواست را ثبت و وضعیت را میبیند؛ تیم عملیات آن را به مسئول مربوط تخصیص میدهد؛ مدیر گلوگاهها را در یک نمای خلاصه بررسی میکند. اعلان فقط برای تغییرهای مهم ارسال میشود و هر نقش به داده مورد نیاز خودش دسترسی دارد.
خروجی همکاری
فهرست نهایی با دامنه همان پروژه تنظیم میشود؛ این موارد چارچوب عمومی تحویل هستند.
فناوری و زیرساخت
رابط و منطق وباپلیکیشنهای اختصاصی با Next.js (فریمورک مبتنی بر React) ساخته میشود و جایی که بخش اصلی کار مدیریت محتواست، وردپرس کنار آن قرار میگیرد. پایگاه داده، میزبانی و سرویسهای جانبی بعد از کشف نیاز انتخاب میشوند، چون به حجم داده، محل نگهداری آن و اتصالهای لازم بستگی دارند. مرتضی ریاحی، مدیر ایران دیزاینر و توسعهدهنده فولاستک، مسئولیت معماری تجربه و کنترل نهایی این پروژهها را مستقیماً بر عهده دارد.
| لایه | ابزار یا تصمیم | پیش از قرارداد روشن کنید |
|---|---|---|
| رابط کاربری (Frontend) | Next.js و React؛ رندر سمت سرور برای صفحههایی که باید ایندکس شوند و رابط تعاملی برای پنل. | کدام صفحهها عمومی و قابل جستوجو هستند و کدام فقط پس از ورود دیده میشوند. |
| منطق سمت سرور و API | API میان رابط، داده و سامانههای بیرونی باید مستند باشد تا توسعهدهنده بعدی یا یک اپلیکیشن موبایل بتواند بدون بازنویسی از آن استفاده کند. | سامانههایی که باید وصل شوند (پرداخت، پیامک، CRM، حسابداری) و اینکه API مستند دارند یا نه. |
| پایگاه داده | بر اساس مدل داده و حجم آن در مرحله معماری انتخاب میشود. | چه دادهای و تا چه مدت نگهداری میشود و آیا داده شخصی یا مالی حساس در آن هست. |
| ورود و دسترسی | احراز هویت، نقشها و ثبت تغییرات (چه کسی، چه چیزی را، کی تغییر داد) بخشی از نسخه اولاند؛ افزودن آنها بعد از انتشار یعنی بازنویسی بخش بزرگی از منطق. | نقشها، روش ورود (رمز یا کد یکبارمصرف) و اینکه چه کسی نقشها را تعیین میکند. |
| میزبانی و استقرار | بعد از کشف نیاز انتخاب میشود؛ محیط آزمایشی جدا، پشتیبانگیری و ثبت خطا باید در دامنه کار باشند. | میزبانی داخل یا خارج ایران، با توجه به محل کاربران و سرویسهایی که باید در دسترس بمانند. |
| کد و مستندات | کد باید در مخزن نسخهبندیشده (Git) با دسترسی شما و همراه مستندات استقرار تحویل شود. | مخزن به نام چه کسی است و دسترسی مدیر آن بعد از تحویل با کیست. |
پیش از تصمیم
در وباپلیکیشن تعامل، داده و منطق فرایند هسته محصول است؛ سایت معمولاً بر معرفی، محتوا و تبدیل تمرکز دارد.
MVP (Minimum Viable Product) کوچکترین نسخهای است که کاربر واقعی با آن یک کار اصلی را از ابتدا تا انتها انجام میدهد و داده واقعی ثبت میکند. پروتوتایپ (Prototype) نمونهای تعاملی برای آزمودن مسیر و رابط پیش از توسعه است و معمولاً منطق و داده واقعی ندارد. روش آزمودن MVP پیش از ساخت محصول کامل را در راهنمای MVP ببینید.
در بیشتر پروژهها بله، اما دامنه MVP بعد از کشف تعیین میشود. گاهی ابتدا Prototype یا بررسی فنی اتصالها کمریسکتر است.
بله؛ پس از بررسی نیازها، قابلیتها اولویتبندی میشوند و دامنه هر مرحله متناسب با هدف همان فاز پیشنهاد میشود.
برآورد از دامنه نسخه اول میآید، نه از فهرست کامل ایدهها: تعداد نقشها و مسیرهای اصلی، پیچیدگی مدل داده، تعداد اتصال به سامانههای دیگر و سطح گزارشگیری. به همین دلیل برآورد قابل اتکا بعد از مرحله کشف داده میشود و هر فاز بعدی برآورد جدا میگیرد. هزینه نگهداری، میزبانی و سرویسهای پولی بیرونی را هم جدا از هزینه ساخت بپرسید.
این را باید پیش از شروع در قرارداد نوشت: مالکیت کد، دسترسی مدیر به مخزن، میزبانی و پایگاه داده، و حساب سرویسهای بیرونی مثل پیامک و درگاه. اگر این دسترسیها به نام توسعهدهنده ثبت شود، تغییر تیم یا میزبان بعداً پرهزینه میشود.
قدم بعدی
مسئله، کاربران و اتصالهای ضروری را بررسی میکنیم تا MVP قابل استفاده از یک دمو با قابلیتهای پراکنده جدا شود.