طراحی سایت و اپلیکیشن اختصاصی

طراحی سایت و اپلیکیشن یکپارچه یعنی چه؟

طراحی سایت و اپلیکیشن یکپارچه یعنی وب‌سایت و اپلیکیشن موبایل، به‌جای دو محصول مستقل، روی یک Backend، یک پایگاه دادهٔ واحد و یک پنل مدیریت مشترک ساخته می‌شوند و از طریق یک API مشترک به هم متصل‌اند. در این مدل، محصول، قیمت، موجودی، سفارش، کاربر و محتوا فقط یک‌بار تعریف می‌شوند و هر دو کانال، همان داده را می‌خوانند و می‌نویسند. نتیجهٔ عملی‌اش این است که تغییر قیمت در پنل، هم‌زمان روی سایت و اپ دیده می‌شود و سفارشی که کاربر در اپلیکیشن ثبت می‌کند، در همان فهرست سفارش‌های سایت می‌نشیند — بدون هیچ همگام‌سازی دستی.

نقطهٔ مقابل این مدل، چیزی است که در عمل زیاد دیده می‌شود: سایتی که چند سال پیش با یک پیمانکار ساخته شده و اپلیکیشنی که بعدها با پیمانکار دیگری اضافه شده است. هر کدام پایگاه دادهٔ خودش را دارد، هر کدام پنل خودش را دارد و کارمند شما موجودی انبار را دو بار وارد می‌کند. تا وقتی همه‌چیز آرام است، این تفاوت به چشم نمی‌آید؛ اما روز حراج یا روز تغییر قیمت، اختلاف دو سیستم خودش را به شکل سفارش اشتباه، موجودی منفی و مشتری ناراضی نشان می‌دهد.

یک سوءتفاهم را هم همین ابتدا رفع کنیم: یکپارچگی به معنای «یک کد برای همه‌چیز» نیست. سایت و اپلیکیشن دو تجربهٔ کاربری متفاوت‌اند و لایهٔ نمایش هرکدام جداگانه ساخته می‌شود؛ آنچه مشترک است، لایهٔ منطق کسب‌وکار و داده است. ضمن اینکه یکپارچگی یک تصمیم معماری است، نه افزونه‌ای که بعداً نصب شود: اگر از ابتدا در Specification پروژه دیده نشود، چسباندن دو سیستمِ جداساخته به یکدیگر در آینده، خودش یک پروژهٔ مستقل و پرهزینه خواهد بود. به همین دلیل این تصمیم جایش مرحلهٔ نیازسنجی است، نه پس از تحویل.

کسب‌وکار من به سایت نیاز دارد، اپلیکیشن، یا هر دو؟

پاسخ کوتاه: اگر هنوز سایت ندارید، از سایت شروع کنید. سایت تنها کانالی است که در گوگل دیده می‌شود، برای هر بازدیدکنندهٔ تازه بدون نصب باز می‌شود و با هزینهٔ کمتری به نتیجه می‌رسد. اپلیکیشن، ابزار نگه‌داشتن مشتری است نه ابزار پیداکردن او؛ کاربر اپ کسب‌وکاری را نصب می‌کند که از قبل می‌شناسد و قرار است بارها به آن برگردد. بنابراین ترتیب طبیعی برای بیشتر کسب‌وکارها این است: اول سایت، و بعد — وقتی تکرار خرید یا تعامل ثابت شد — اپلیکیشن.

اما این قاعده استثنا دارد. اگر محصول شما ذاتاً موبایلی است — کار میدانی، اسکن بارکد، موقعیت مکانی، کار در حالت آفلاین یا اعلان لحظه‌ای — اپلیکیشن دیگر مکمل نیست، خودِ محصول است و سایت نقش صفحهٔ معرفی و جذب را بازی می‌کند. و اگر از همان ابتدا می‌دانید هر دو کانال را لازم دارید، ساختن هم‌زمان آن‌ها روی یک Backend مشترک تصمیم درستی است؛ چون بزرگ‌ترین هزینهٔ پنهان در این حوزه، نوشتن دوبارهٔ همان منطق کسب‌وکار برای بار دوم است. جدول زیر رایج‌ترین وضعیت‌ها را کنار هم می‌گذارد:

اگر بعد از این جدول هنوز مردد هستید، معیار تصمیم را از «کدام جذاب‌تر است» به «کاربر چند بار در ماه برمی‌گردد» تغییر دهید. برای کسب‌وکاری که مشتری‌اش سالی یک‌بار خرید می‌کند، اپلیکیشن روی گوشی می‌ماند و باز نمی‌شود؛ هزینه‌اش پرداخت شده اما نصب و نگه‌داشتنش هرگز اتفاق نمی‌افتد. برای کسب‌وکاری که مشتری‌اش هفتگی برمی‌گردد، همان اپ یک کانال ارتباط مستقیم و بدون هزینهٔ تبلیغات مجدد در اختیارتان می‌گذارد. این عددی است که خودتان دارید — آن را از فروش فعلی‌تان استخراج کنید، نه از توصیهٔ فروشنده.

پنل مدیریت مشترک و Backend یکپارچه چه مزیتی دارد؟

مزیت اصلی پنل مدیریت مشترک این است که هر داده فقط یک «خانهٔ اصلی» دارد. محصول، قیمت، موجودی، دسته‌بندی، کاربر، سفارش، کد تخفیف و محتوا یک‌بار در پنل ثبت می‌شوند و سایت و اپلیکیشن هر دو از طریق API همان داده را می‌خوانند. یعنی هیچ‌گاه دو عدد متفاوت برای یک موجودی وجود ندارد و هیچ کارمندی مجبور نیست یک کار را دو بار انجام دهد. این نه یک قابلیت لوکس، بلکه شرط اولیهٔ اداره‌کردن دو کانال فروش با یک تیم است.

اثر این تصمیم در کار روزمره دیده می‌شود، نه در دموی پروژه. تعریف یک کمپین تخفیف در سیستم دوپاره یعنی دو بار ورود اطلاعات، دو برابر احتمال خطا و دو تیم که باید با هم هماهنگ شوند. در سیستم یکپارچه، همان کمپین یک‌بار تعریف می‌شود و هم‌زمان در هر دو کانال فعال است. همین منطق دربارهٔ حساب کاربری هم برقرار است: کاربری که در سایت ثبت‌نام کرده، با همان شماره و همان سبد خرید وارد اپ می‌شود؛ تجربه‌ای که کاربر آن را «حرفه‌ای بودن» می‌فهمد، بدون آنکه بداند علتش یک تصمیم معماری بوده است.

هزینهٔ پروژهٔ یکپارچه در برابر دو پروژهٔ جداگانه چقدر است؟

اعداد شروع در برتینا روشن است: طراحی سایت از ۷۰ میلیون تومان، ساخت اپلیکیشن از ۸۰ میلیون تومان و پروژهٔ کامل — یعنی سایت و اپلیکیشن یکپارچه — از ۱۸۰ میلیون تومان. هر سهٔ این‌ها «شروع از» هستند و قیمت نهایی پس از نیازسنجی و بر اساس امکانات، اتصال‌ها، حجم داده و سطح پشتیبانی مشخص می‌شود. امکان پرداخت تا چهار مرحله و چهار مرحله بازبینی و اصلاح، مطابق محدودهٔ قرارداد در نظر گرفته می‌شود.

حالا صادقانه به این اعداد نگاه کنیم، چون جای سؤال دارد: جمع دو رقم شروعِ جداگانه ۱۵۰ میلیون تومان است و رقم پروژهٔ کامل ۱۸۰ میلیون. پس بر خلاف چیزی که شاید انتظار داشته باشید، «یکپارچه» ارزان‌تر از جمعِ دو عدد شروع نیست و ما این را پنهان نمی‌کنیم. علتش این است که آن دو عدد، دو محصول مستقل را توصیف می‌کنند و لایه‌ای که آن دو را به هم می‌دوزد در هیچ‌کدامشان نیست: API مشترک، مدل دادهٔ واحد، پنلی که هر دو کانال را اداره می‌کند، و نگهداری یک‌ساله مطابق قرارداد که در پروژهٔ کامل دیده شده است.

صرفه‌جویی واقعی جای دیگری است: در کاری که دو بار انجام نمی‌شود. یک نیازسنجی به‌جای دو نیازسنجی، یک مدل داده به‌جای دو مدل ناسازگار، یک تیم پاسخ‌گو به‌جای دو پیمانکار که مسئولیت را به هم پاس می‌دهند، و از همه مهم‌تر، پروژهٔ سومی که هرگز لازم نمی‌شود — همان پروژه‌ای که در آن باید دو سیستم جداساخته را به هم متصل کنید و معمولاً از هر دوی آن‌ها گران‌تر درمی‌آید. آن پروژهٔ سوم در فاکتور اولیه دیده نمی‌شود، اما در بسیاری از کسب‌وکارها بالاخره پرداخت می‌شود.

برای بودجه‌بندی واقع‌بینانه، سه هزینهٔ دیگر را هم از روز اول در محاسبه بیاورید: نگهداری ماهانه که از ۱۰ میلیون تومان در ماه شروع می‌شود و حداقل دورهٔ آن شش ماه است؛ هزینهٔ زیرساختی که سایت و اپ روی آن اجرا می‌شوند (دامنه، هاست یا سرور، SSL و ایمیل سازمانی)؛ و هزینهٔ حساب‌های توسعه‌دهندهٔ مارکت‌ها در صورتی که اپلیکیشن منتشر شود. هیچ‌کدام از این‌ها غافلگیرکننده نیستند، به شرط آنکه در پروپوزال دیده شوند — و ما آن‌ها را در پروپوزال می‌آوریم، نه در فاکتور بعدی.

زیرساخت: سایت و اپلیکیشن شما دقیقاً کجا اجرا می‌شوند؟

سایت و اپلیکیشن، نرم‌افزارهایی نیستند که تحویل بگیرید و کار تمام شود؛ سرویس‌هایی هستند که باید هر ثانیه، جایی، روی سخت‌افزاری روشن بمانند. حداقلِ چیزی که یک پروژهٔ سایت و اپلیکیشن برای زنده‌ماندن لازم دارد این است: یک دامنه، یک هاست یا سرور، یک پایگاه داده، یک گواهی SSL، یک سرویس ایمیل سازمانی، بکاپ منظم، مانیتورینگ، و یک API که اپلیکیشن از طریق آن با Backend حرف می‌زند. این فهرست هشت قلم است — و در بیشتر پروژه‌های آژانسی، از چهار یا پنج فروشندهٔ مختلف تأمین می‌شود.

مشکل چندفروشندگی در روزهای خوب معلوم نمی‌شود؛ ساعت دو بامداد معلوم می‌شود. سایت بالا نمی‌آید و اپلیکیشن خطای اتصال می‌دهد. تقصیر کیست؟ شرکت طراحی می‌گوید کد سالم است و ایراد از سرور است؛ شرکت هاستینگ می‌گوید سرور بالاست و ایراد از کد است؛ فروشندهٔ دامنه می‌گوید DNS درست تنظیم شده؛ و شما، در نقش پیام‌رسان، بین سه پشتیبانی می‌چرخید در حالی که هیچ‌کس مالک مسئله نیست. این توپ‌اندازی، گران‌ترین بخش هر قطعی است — نه خود قطعی، بلکه دقایقی که صرف پیداکردن مسئول می‌شود، آن هم دقیقاً وقتی سرویس شما خواب است.

مزیت برتینا دقیقاً همین‌جاست و ادعای تازه‌ای هم نیست: برتینا از سال ۱۳۸۳ فروشندهٔ همان زیرساخت است. هاست، سرور مجازی، سرور اختصاصی، کولوکیشن، دامنه، SSL، DNS و ایمیل سازمانی، همگی سرویس‌های خودِ ما هستند و روی دیتاسنتر اختصاصی خودمان اجرا می‌شوند، با آپ‌تایم ۹۹.۹٪ و پشتیبانی ۲۴ ساعته در تمام روزهای هفته. یعنی وقتی سایت و اپلیکیشن‌تان را به ما می‌سپارید، لایهٔ کد و لایهٔ زیرساخت زیر یک سقف می‌آیند و یک شمارهٔ تماس، مالک کل مسئله است. یک قرارداد، یک تیکت، یک مسئول.

این تفاوت را می‌شود در یک جمله خلاصه کرد: وقتی چیزی خراب می‌شود، شما فقط یک شماره می‌گیرید — ۰۲۱-۴۹۱۶۹۵۵۵ — و کسی آن‌طرف خط هم به کد دسترسی دارد و هم به سروری که کد روی آن اجرا می‌شود. جدول زیر نشان می‌دهد یک پروژهٔ سایت و اپلیکیشن از چه اجزایی تشکیل شده و کدام‌یک را می‌توانید از همان یک تأمین‌کننده بگیرید:

فرایند همکاری از نیازسنجی تا انتشار چگونه پیش می‌رود؟

فرایند در هشت مرحله انجام می‌شود، اما آنچه برای شما به‌عنوان کارفرما تعیین‌کننده است، سه نقطهٔ تصمیم است نه هشت عنوان. نقطهٔ اول، جلسهٔ نیازسنجی است که در آن محدودهٔ پروژه — یعنی دقیقاً چه چیزی ساخته می‌شود و چه چیزی ساخته نمی‌شود — روی کاغذ می‌آید. نقطهٔ دوم، پروپوزال و Specification است که همان محدوده را به برآورد هزینه و مراحل تحویل ترجمه می‌کند. نقطهٔ سوم، بازبینی‌هاست: چهار مرحله بازخورد و اصلاح، مطابق محدودهٔ قرارداد. اگر سایت فعلی دارید، نقطهٔ شروع می‌تواند چکاپ رایگان باشد که گزارش PDF آن، ورودی همان جلسهٔ نیازسنجی می‌شود.

سرعت پروژه، بیش از آنکه به تیم فنی وابسته باشد، به آماده‌بودن شما وابسته است. چیزهایی که در عمل پروژه‌ها را معطل می‌کنند تقریباً همیشه یکسان‌اند: محتوای صفحات و عکس محصولات، فهرست دقیق محصولات یا خدمات، دسترسی به سایت و پایگاه دادهٔ فعلی در پروژه‌های بازطراحی، مشخص‌نبودن فردی که در سازمان شما حق تصمیم نهایی دارد، و اطلاعات درگاه پرداخت و حساب‌های توسعه‌دهندهٔ مارکت. اگر این‌ها را زودتر آماده کنید، مراحل بازبینی به‌جای انتظار برای رسیدن یک فایل، صرف بهبود واقعی محصول می‌شود.

دربارهٔ زمان هم صادق باشیم: ما زمان تحویل قطعی و از پیش‌تعیین‌شده اعلام نمی‌کنیم، چون زمان واقعی به محدودهٔ پروژه، تعداد اتصال‌ها و سرعت بازخورد شما بستگی دارد. زمان‌بندی در پروپوزال و به‌صورت مرحله‌ای مشخص می‌شود و هر مرحله، تحویلی قابل مشاهده دارد — نه یک وعدهٔ کلی برای روز آخر. اگر پیمانکاری پیش از دیدن نیازهای شما تاریخ قطعی می‌دهد، آن تاریخ یک حدس است، نه یک تعهد؛ و حدسی که با امضا رسمی شود، معمولاً به بحث تبدیل می‌شود.

به همین دلیل، پروپوزال مهم‌ترین سندی است که پیش از امضا می‌خوانید. فهرست زیر را به‌عنوان چک‌لیست بردارید — چه با ما کار کنید، چه با هر پیمانکار دیگری:

• محدودهٔ دقیق پروژه: فهرست آنچه ساخته می‌شود و صریحاً آنچه ساخته نمی‌شود
• مراحل تحویل و اینکه هر پرداخت به کدام تحویل گره خورده است (پرداخت تا چهار مرحله)
• تعداد و شرایط بازبینی‌ها و اینکه Change Request از کجا شروع می‌شود
• زیرساختی که پروژه روی آن اجرا می‌شود و اینکه هزینه‌اش داخل پروپوزال است یا جدا
• شرایط تحویل سورس‌کد، مستندات و دسترسی‌های مدیریتی
• قرارداد نگهداری: چه چیزی داخل آن است، چه چیزی نیست و از چه زمانی شروع می‌شود
• اینکه دامنه و حساب‌های مارکت به نام چه کسی ثبت می‌شوند

پس از تحویل، مالکیت پروژه، سورس‌کد، دامنه و داده‌ها با کیست؟

پاسخ کوتاه و بی‌تعارف: دامنه و داده‌های کسب‌وکار از آنِ شماست، و شرایط تحویل سورس‌کد و مستندات چیزی است که در قرارداد مشخص می‌شود — نه چیزی که باید پس از تحویل دربارهٔ آن مذاکره کنید. توصیهٔ ما به هر کارفرما، حتی وقتی طرف قرارداد ما نیست، همین است: پیش از امضا، این سه مورد را جداگانه و به‌صورت مکتوب روشن کنید. بیشتر اختلاف‌های پس از پروژه، از مبهم‌ماندن دقیقاً همین سه بند شروع می‌شود.

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

داده‌ها — مشتریان، سفارش‌ها، محتوا و فایل‌ها — دارایی کسب‌وکار شما هستند و باید در هر لحظه قابل استخراج باشند. پرسش درست این نیست که «داده مال کیست؟»، بلکه این است که «چطور می‌توانم یک نسخهٔ کامل و قابل استفاده از آن بگیرم؟» اگر پاسخ این پرسش روشن نیست، شما در عمل قفل شده‌اید، حتی اگر روی کاغذ مالک باشید. در پروژه‌های یکپارچه این کار ساده‌تر است، چون یک پایگاه دادهٔ واحد وجود دارد؛ خروجی‌گرفتن از یک سیستم، به‌مراتب ساده‌تر از سرهم‌کردن داده از دو سیستم ناسازگار است.

دربارهٔ سورس‌کد هم بر خلاف تبلیغ‌های رایج، پاسخ یکسانی برای همهٔ پروژه‌ها وجود ندارد و ما وعدهٔ کلی نمی‌دهیم: شرایط تحویل سورس‌کد و مستندات در قرارداد هر پروژه مشخص می‌شود. آنچه از روز اول قطعی است، دسترسی‌های مدیریتی است — پنل مدیریت، کاربر مدیر و کنترل محتوا در اختیار شماست و آموزش کار با آن، بخشی از تحویل است. اگر تحویل کامل سورس‌کد برای شما اهمیت راهبردی دارد، جای طرح آن همان جلسهٔ نیازسنجی است، نه هفتهٔ بعد از انتشار.

پس از انتشار چه اتفاقی می‌افتد؟ نگهداری، پشتیبانی و توسعهٔ مرحله‌ای

انتشار، پایان پروژه نیست؛ نقطه‌ای است که محصول تازه شروع می‌کند به تولید داده. از آن لحظه سه دستهٔ کار متفاوت آغاز می‌شود که خلط‌کردنشان رایج‌ترین سوءتفاهم قراردادی در این حوزه است: نگهداری (کارِ زنده و سالم نگه‌داشتن)، پشتیبانی (پاسخ به مشکل و پرسش) و توسعه (افزودن چیز جدید). نگهداری ماهانه در برتینا از ۱۰ میلیون تومان در ماه شروع می‌شود و حداقل دورهٔ آن شش ماه است؛ محدودهٔ دقیق آن در قرارداد نگهداری تعریف می‌شود.

اما چرا نگهداری اختیاری نیست؟ چون محیط زیر پای محصول شما ثابت نمی‌ماند. اندروید و iOS هر سال نسخهٔ جدید منتشر می‌کنند و اپلیکیشنی که به‌روز نشود، دیر یا زود روی دستگاه‌های تازه دچار خطا می‌شود یا با قوانین جدید مارکت‌ها ناسازگار می‌شود. مرورگرها، کتابخانه‌ها، افزونه‌ها و گواهی‌های امنیتی هم همین‌طور. یک وصلهٔ امنیتی نصب‌نشده، یک SSL تمدیدنشده و یک کتابخانهٔ قدیمی، سه علتِ کاملاً قابل پیشگیری‌اند که سرویس‌های رهاشده را از کار می‌اندازند — و هر سه، ماه‌ها پیش از حادثه قابل رفع بوده‌اند.

توسعهٔ مرحله‌ای هم همان چیزی است که پروژه را از سرنوشت «یک‌بار ساختن و رهاکردن» نجات می‌دهد. به‌جای ریختن همهٔ ایده‌ها در نسخهٔ اول — که هم هزینه را بالا می‌برد و هم انتشار را عقب می‌اندازد — نسخهٔ اول را به هستهٔ ضروری محدود کنید و بقیه را به فازهای بعد بسپارید. مزیت پنهان این کار این است که فاز دوم را دیگر بر اساس حدس نمی‌سازید، بلکه بر اساس رفتار واقعی کاربران نسخهٔ اول می‌سازید؛ داده‌ای که پیش از انتشار به‌سادگی وجود نداشت و هیچ جلسه‌ای هم آن را تولید نمی‌کند.

در ماه‌های اول پس از انتشار، این نشانه‌ها را زیر نظر بگیرید — همان‌هایی که تصمیم فاز بعدی را برایتان می‌سازند:

• خطاهایی که کاربران واقعی می‌بینند، نه فقط خطاهایی که در تست دیده شد
• صفحات و مسیرهایی که کاربر در آن‌ها رها می‌کند و جلوتر نمی‌رود
• زمان پاسخ سرور و API زیر بار واقعی، نه بار آزمایشی روز تحویل
• نظرها و امتیازهای مارکت، که مستقیماً روی نصب‌های بعدی اثر می‌گذارند
• حجم پایگاه داده و مصرف منابع سرور، تا ارتقا پیش از کندی انجام شود
• تاریخ تمدید دامنه، گواهی SSL و سرویس‌های زیرساختی