راهنمای کاملپیش از انتخاب مسیر، این پرسشها را پاسخ دهید: کسبوکار شما به کدام نیاز دارد، پنل مدیریت مشترک چه مزیتی میسازد، و سایت و اپلیکیشن شما کجا اجرا میشوند.
طراحی سایت و اپلیکیشن یکپارچه یعنی وبسایت و اپلیکیشن موبایل، بهجای دو محصول مستقل، روی یک Backend، یک پایگاه دادهٔ واحد و یک پنل مدیریت مشترک ساخته میشوند و از طریق یک API مشترک به هم متصلاند. در این مدل، محصول، قیمت، موجودی، سفارش، کاربر و محتوا فقط یکبار تعریف میشوند و هر دو کانال، همان داده را میخوانند و مینویسند. نتیجهٔ عملیاش این است که تغییر قیمت در پنل، همزمان روی سایت و اپ دیده میشود و سفارشی که کاربر در اپلیکیشن ثبت میکند، در همان فهرست سفارشهای سایت مینشیند — بدون هیچ همگامسازی دستی.
نقطهٔ مقابل این مدل، چیزی است که در عمل زیاد دیده میشود: سایتی که چند سال پیش با یک پیمانکار ساخته شده و اپلیکیشنی که بعدها با پیمانکار دیگری اضافه شده است. هر کدام پایگاه دادهٔ خودش را دارد، هر کدام پنل خودش را دارد و کارمند شما موجودی انبار را دو بار وارد میکند. تا وقتی همهچیز آرام است، این تفاوت به چشم نمیآید؛ اما روز حراج یا روز تغییر قیمت، اختلاف دو سیستم خودش را به شکل سفارش اشتباه، موجودی منفی و مشتری ناراضی نشان میدهد.
یک سوءتفاهم را هم همین ابتدا رفع کنیم: یکپارچگی به معنای «یک کد برای همهچیز» نیست. سایت و اپلیکیشن دو تجربهٔ کاربری متفاوتاند و لایهٔ نمایش هرکدام جداگانه ساخته میشود؛ آنچه مشترک است، لایهٔ منطق کسبوکار و داده است. ضمن اینکه یکپارچگی یک تصمیم معماری است، نه افزونهای که بعداً نصب شود: اگر از ابتدا در Specification پروژه دیده نشود، چسباندن دو سیستمِ جداساخته به یکدیگر در آینده، خودش یک پروژهٔ مستقل و پرهزینه خواهد بود. به همین دلیل این تصمیم جایش مرحلهٔ نیازسنجی است، نه پس از تحویل.
پاسخ کوتاه: اگر هنوز سایت ندارید، از سایت شروع کنید. سایت تنها کانالی است که در گوگل دیده میشود، برای هر بازدیدکنندهٔ تازه بدون نصب باز میشود و با هزینهٔ کمتری به نتیجه میرسد. اپلیکیشن، ابزار نگهداشتن مشتری است نه ابزار پیداکردن او؛ کاربر اپ کسبوکاری را نصب میکند که از قبل میشناسد و قرار است بارها به آن برگردد. بنابراین ترتیب طبیعی برای بیشتر کسبوکارها این است: اول سایت، و بعد — وقتی تکرار خرید یا تعامل ثابت شد — اپلیکیشن.
اما این قاعده استثنا دارد. اگر محصول شما ذاتاً موبایلی است — کار میدانی، اسکن بارکد، موقعیت مکانی، کار در حالت آفلاین یا اعلان لحظهای — اپلیکیشن دیگر مکمل نیست، خودِ محصول است و سایت نقش صفحهٔ معرفی و جذب را بازی میکند. و اگر از همان ابتدا میدانید هر دو کانال را لازم دارید، ساختن همزمان آنها روی یک Backend مشترک تصمیم درستی است؛ چون بزرگترین هزینهٔ پنهان در این حوزه، نوشتن دوبارهٔ همان منطق کسبوکار برای بار دوم است. جدول زیر رایجترین وضعیتها را کنار هم میگذارد:
اگر بعد از این جدول هنوز مردد هستید، معیار تصمیم را از «کدام جذابتر است» به «کاربر چند بار در ماه برمیگردد» تغییر دهید. برای کسبوکاری که مشتریاش سالی یکبار خرید میکند، اپلیکیشن روی گوشی میماند و باز نمیشود؛ هزینهاش پرداخت شده اما نصب و نگهداشتنش هرگز اتفاق نمیافتد. برای کسبوکاری که مشتریاش هفتگی برمیگردد، همان اپ یک کانال ارتباط مستقیم و بدون هزینهٔ تبلیغات مجدد در اختیارتان میگذارد. این عددی است که خودتان دارید — آن را از فروش فعلیتان استخراج کنید، نه از توصیهٔ فروشنده.
|
| کسبوکار تازهکار با بودجهٔ محدود | بله؛ نقطهٔ شروع درست همین است | خیر؛ هزینه پیش از اثبات بازار | در این مرحله زودهنگام است |
| هدف اصلی دیدهشدن در گوگل | بله؛ سئو فقط روی وب معنا دارد | اپ در نتایج جستوجو نمایش داده نمیشود | سایت مقدم است و اپ در فاز بعد |
| فروش تکخریدی یا خرید کمتکرار | بله؛ سایت فروشگاهی پاسخ میدهد | اپ نصبنشده باقی میماند | توجیه اقتصادی روشنی ندارد |
| خرید تکرارشونده و مشتری وفادار | برای بازگشت مشتری کافی نیست | بله؛ نصب روی گوشی و اعلان مستقیم | بهترین حالت؛ حساب و سبد مشترک |
| نیاز به اعلان و Push Notification | وبپوش محدود و کماثر است | بله؛ این کاربرد اصلی اپلیکیشن است | ارسال اعلان از یک پنل به هر دو کانال |
| فرایند داخلی سازمان و نیروی میدانی | پنل تحت وب برای دفتر پاسخ میدهد | بله؛ کار آفلاین، دوربین و موقعیت مکانی | دفتر روی وب و میدان روی اپ، با یک داده |
| رزرو، نوبتدهی و باشگاه مشتریان | رزرو ساده روی سایت شدنی است | اپ تجربهٔ سریعتر و پیگیری بهتری میسازد | یک تقویم و یک پروفایل واحد برای کاربر |
| کاتالوگ محصولات و اعتبار برند | بله؛ دقیقاً همان کاری که سایت میکند | اپ ارزش افزودهٔ محسوسی اضافه نمیکند | در این سناریو لازم نیست |
مزیت اصلی پنل مدیریت مشترک این است که هر داده فقط یک «خانهٔ اصلی» دارد. محصول، قیمت، موجودی، دستهبندی، کاربر، سفارش، کد تخفیف و محتوا یکبار در پنل ثبت میشوند و سایت و اپلیکیشن هر دو از طریق API همان داده را میخوانند. یعنی هیچگاه دو عدد متفاوت برای یک موجودی وجود ندارد و هیچ کارمندی مجبور نیست یک کار را دو بار انجام دهد. این نه یک قابلیت لوکس، بلکه شرط اولیهٔ ادارهکردن دو کانال فروش با یک تیم است.
اثر این تصمیم در کار روزمره دیده میشود، نه در دموی پروژه. تعریف یک کمپین تخفیف در سیستم دوپاره یعنی دو بار ورود اطلاعات، دو برابر احتمال خطا و دو تیم که باید با هم هماهنگ شوند. در سیستم یکپارچه، همان کمپین یکبار تعریف میشود و همزمان در هر دو کانال فعال است. همین منطق دربارهٔ حساب کاربری هم برقرار است: کاربری که در سایت ثبتنام کرده، با همان شماره و همان سبد خرید وارد اپ میشود؛ تجربهای که کاربر آن را «حرفهای بودن» میفهمد، بدون آنکه بداند علتش یک تصمیم معماری بوده است.
در معماری یکپارچه، پایگاه داده تنها مرجع رسمی است و سایت و اپ فقط نمایشدهندهاند. ارزش عملی این ساختار وقتی روشن میشود که اختلافی پیش بیاید: بهجای اینکه بپرسید «کدام سیستم درست میگوید؟»، فقط یک پاسخ وجود دارد. برای کسبوکارهایی که موجودی فیزیکی دارند یا سفارش را به انبار و حسابداری پاس میدهند، همین تفاوت مستقیماً جلوی خطای انسانی، فروش کالای ناموجود و سفارش لغوشده را میگیرد.
وقتی سفارشهای وب و موبایل در یک جدول ثبت میشوند، گزارش فروش شما یک عدد دارد، نه دو عدد که باید دستی جمع شوند. تفکیک کانال هم از دست نمیرود — هر سفارش برچسب منبع خودش را دارد — اما جمعبندی و مقایسه روی یک داشبورد انجام میشود. همین موضوع، پاسخ به پرسش «کدام کانال بیشتر میفروشد؟» را از یک پروژهٔ اکسلی پایانماه به یک فیلتر ساده تبدیل میکند.
هر قابلیت جدیدی که به منطق کسبوکار مربوط است — کیف پول، اشتراک، باشگاه مشتریان، تخفیف پلکانی، گزارشهای تازه — در لایهٔ Backend یکبار پیادهسازی میشود و بلافاصله برای هر دو کانال در دسترس قرار میگیرد. در دو پروژهٔ مستقل، همان قابلیت باید دو بار نوشته، دو بار تست و برای همیشه دو بار نگهداری شود. اینجا همان جایی است که هزینهٔ واقعی «دو سیستم جدا» خودش را نشان میدهد: نه در فاکتور اول، بلکه در فاکتور سوم و چهارم.
اعداد شروع در برتینا روشن است: طراحی سایت از ۷۰ میلیون تومان، ساخت اپلیکیشن از ۸۰ میلیون تومان و پروژهٔ کامل — یعنی سایت و اپلیکیشن یکپارچه — از ۱۸۰ میلیون تومان. هر سهٔ اینها «شروع از» هستند و قیمت نهایی پس از نیازسنجی و بر اساس امکانات، اتصالها، حجم داده و سطح پشتیبانی مشخص میشود. امکان پرداخت تا چهار مرحله و چهار مرحله بازبینی و اصلاح، مطابق محدودهٔ قرارداد در نظر گرفته میشود.
حالا صادقانه به این اعداد نگاه کنیم، چون جای سؤال دارد: جمع دو رقم شروعِ جداگانه ۱۵۰ میلیون تومان است و رقم پروژهٔ کامل ۱۸۰ میلیون. پس بر خلاف چیزی که شاید انتظار داشته باشید، «یکپارچه» ارزانتر از جمعِ دو عدد شروع نیست و ما این را پنهان نمیکنیم. علتش این است که آن دو عدد، دو محصول مستقل را توصیف میکنند و لایهای که آن دو را به هم میدوزد در هیچکدامشان نیست: API مشترک، مدل دادهٔ واحد، پنلی که هر دو کانال را اداره میکند، و نگهداری یکساله مطابق قرارداد که در پروژهٔ کامل دیده شده است.
صرفهجویی واقعی جای دیگری است: در کاری که دو بار انجام نمیشود. یک نیازسنجی بهجای دو نیازسنجی، یک مدل داده بهجای دو مدل ناسازگار، یک تیم پاسخگو بهجای دو پیمانکار که مسئولیت را به هم پاس میدهند، و از همه مهمتر، پروژهٔ سومی که هرگز لازم نمیشود — همان پروژهای که در آن باید دو سیستم جداساخته را به هم متصل کنید و معمولاً از هر دوی آنها گرانتر درمیآید. آن پروژهٔ سوم در فاکتور اولیه دیده نمیشود، اما در بسیاری از کسبوکارها بالاخره پرداخت میشود.
برای بودجهبندی واقعبینانه، سه هزینهٔ دیگر را هم از روز اول در محاسبه بیاورید: نگهداری ماهانه که از ۱۰ میلیون تومان در ماه شروع میشود و حداقل دورهٔ آن شش ماه است؛ هزینهٔ زیرساختی که سایت و اپ روی آن اجرا میشوند (دامنه، هاست یا سرور، SSL و ایمیل سازمانی)؛ و هزینهٔ حسابهای توسعهدهندهٔ مارکتها در صورتی که اپلیکیشن منتشر شود. هیچکدام از اینها غافلگیرکننده نیستند، به شرط آنکه در پروپوزال دیده شوند — و ما آنها را در پروپوزال میآوریم، نه در فاکتور بعدی.
سایت و اپلیکیشن، نرمافزارهایی نیستند که تحویل بگیرید و کار تمام شود؛ سرویسهایی هستند که باید هر ثانیه، جایی، روی سختافزاری روشن بمانند. حداقلِ چیزی که یک پروژهٔ سایت و اپلیکیشن برای زندهماندن لازم دارد این است: یک دامنه، یک هاست یا سرور، یک پایگاه داده، یک گواهی SSL، یک سرویس ایمیل سازمانی، بکاپ منظم، مانیتورینگ، و یک API که اپلیکیشن از طریق آن با Backend حرف میزند. این فهرست هشت قلم است — و در بیشتر پروژههای آژانسی، از چهار یا پنج فروشندهٔ مختلف تأمین میشود.
مشکل چندفروشندگی در روزهای خوب معلوم نمیشود؛ ساعت دو بامداد معلوم میشود. سایت بالا نمیآید و اپلیکیشن خطای اتصال میدهد. تقصیر کیست؟ شرکت طراحی میگوید کد سالم است و ایراد از سرور است؛ شرکت هاستینگ میگوید سرور بالاست و ایراد از کد است؛ فروشندهٔ دامنه میگوید DNS درست تنظیم شده؛ و شما، در نقش پیامرسان، بین سه پشتیبانی میچرخید در حالی که هیچکس مالک مسئله نیست. این توپاندازی، گرانترین بخش هر قطعی است — نه خود قطعی، بلکه دقایقی که صرف پیداکردن مسئول میشود، آن هم دقیقاً وقتی سرویس شما خواب است.
مزیت برتینا دقیقاً همینجاست و ادعای تازهای هم نیست: برتینا از سال ۱۳۸۳ فروشندهٔ همان زیرساخت است. هاست، سرور مجازی، سرور اختصاصی، کولوکیشن، دامنه، SSL، DNS و ایمیل سازمانی، همگی سرویسهای خودِ ما هستند و روی دیتاسنتر اختصاصی خودمان اجرا میشوند، با آپتایم ۹۹.۹٪ و پشتیبانی ۲۴ ساعته در تمام روزهای هفته. یعنی وقتی سایت و اپلیکیشنتان را به ما میسپارید، لایهٔ کد و لایهٔ زیرساخت زیر یک سقف میآیند و یک شمارهٔ تماس، مالک کل مسئله است. یک قرارداد، یک تیکت، یک مسئول.
این تفاوت را میشود در یک جمله خلاصه کرد: وقتی چیزی خراب میشود، شما فقط یک شماره میگیرید — ۰۲۱۴۹۱۳۵ — و کسی آنطرف خط هم به کد دسترسی دارد و هم به سروری که کد روی آن اجرا میشود. جدول زیر نشان میدهد یک پروژهٔ سایت و اپلیکیشن از چه اجزایی تشکیل شده و کدامیک را میتوانید از همان یک تأمینکننده بگیرید:
|
| دامنه | نشانی برند شما و پایهٔ ایمیل و گواهی امنیتی | ثبت و تمدید دامنهٔ ir. و بینالمللی به نام خودتان |
| هاست یا سرور | جایی که کد سایت و Backend اپلیکیشن اجرا میشود | هاست اشتراکی، سرور مجازی، سرور اختصاصی و کولوکیشن |
| پایگاه داده | خانهٔ محصول، سفارش، کاربر و محتوا | روی همان سرور یا سروری جدا، متناسب با بار پروژه |
| گواهی SSL | رمزنگاری ترافیک؛ شرط اعتماد مرورگر و مارکتها | صدور و نصب گواهی روی دامنهٔ شما |
| ایمیل سازمانی | فاکتور، بازیابی رمز و اطلاعرسانی به مشتری | ایمیل روی دامنهٔ اختصاصی با تنظیمات تحویلپذیری |
| بکاپ | تنها راه برگشت از خطای انسانی یا حادثه | نسخهٔ پشتیبان دورهای مطابق قرارداد سرویس |
| مانیتورینگ | فهمیدن قطعی، پیش از آنکه مشتری خبرتان کند | پایش زیرساخت توسط تیم فنی، بهصورت شبانهروزی |
| API | پلی که اپلیکیشن از آن با Backend حرف میزند | طراحی و میزبانی روی همان زیرساخت، بدون واسطهٔ بیرونی |
کمکردن تعداد فروشنده، پیش از هر چیز زمان بازیابی سرویس را کوتاه میکند. وقتی کد، سرور، دامنه و DNS در یک مجموعهاند، تشخیص اینکه ایراد از کجاست به تیمی سپرده میشود که به هر دو طرف دسترسی دارد و برای دیدن لاگ سرور لازم نیست منتظر پاسخ یک شرکت دیگر بماند. علاوه بر این، هزینهٔ پنهانِ «مدیریت تأمینکننده» هم حذف میشود: یک فاکتور و یک تاریخ تمدید، بهجای پنج تقویم تمدید که فراموششدن هرکدامشان میتواند سرویس را بخواباند. منقضیشدن دامنه یا SSL از فرط ازیادرفتن، یکی از رایجترین قطعیهای کاملاً قابل پیشگیری است.
محل اجرای زیرساخت یک تصمیم فنی با پیامد مستقیم تجاری است. اگر مخاطب شما داخل ایران است، اجرای سایت و API روی زیرساخت داخل کشور، مسیر شبکهٔ کوتاهتر و زمان پاسخ کمتری میدهد و همین مستقیماً روی سرعتِ درکشدهٔ سایت و اپ اثر میگذارد. اگر سرویس شما به سرویسهای بینالمللی وابسته است یا کاربر خارج از کشور دارید، زیرساخت خارج از ایران معنا پیدا میکند. برتینا هر دو را در اختیار دارد و انتخاب میان آنها در نیازسنجی و بر اساس مخاطب واقعی شما انجام میشود، نه بر اساس عادت یا موجودی انبار فروشنده.
تصور رایج این است که اپلیکیشن «روی گوشی کاربر» اجرا میشود، پس به سرور نیازی ندارد. این تصور فقط دربارهٔ اپهای کاملاً آفلاین درست است — مثل یک ماشینحساب یا یک بازی تکنفره. هر اپلیکیشنی که ورود کاربر، فهرست محصول، سفارش، پرداخت، چت یا اعلان دارد، در واقع یک نمایشدهندهٔ زیباست که تمام دادهٔ زندهاش را از سرور شما میگیرد. آنچه کاربر روی گوشی میبیند، پوستهٔ محصول است؛ محصول واقعی، روی زیرساخت شما اجرا میشود.
پیامدش روشن است: اگر آن سرور کند باشد، اپلیکیشن کند است؛ و اگر آن سرور بخوابد، اپلیکیشن روی گوشی کاربر باز میشود و خالی میماند. تفاوت مهم با سایت اینجاست که کاربرِ ناراضی اپ، نارضایتیاش را در محلی عمومی و ماندگار ثبت میکند: نظر و امتیاز در مارکت. به بیان دیگر، کیفیتی که کاربر از اپلیکیشن شما تجربه میکند، بیش از آنکه به کد اپ وابسته باشد، به سلامت زیرساختی وابسته است که پشت آن نفس میکشد — و این دقیقاً همان لایهای است که بیشتر شرکتهای طراحی، اصلاً آن را نمیفروشند.
فرایند در هشت مرحله انجام میشود، اما آنچه برای شما بهعنوان کارفرما تعیینکننده است، سه نقطهٔ تصمیم است نه هشت عنوان. نقطهٔ اول، جلسهٔ نیازسنجی است که در آن محدودهٔ پروژه — یعنی دقیقاً چه چیزی ساخته میشود و چه چیزی ساخته نمیشود — روی کاغذ میآید. نقطهٔ دوم، پروپوزال و Specification است که همان محدوده را به برآورد هزینه و مراحل تحویل ترجمه میکند. نقطهٔ سوم، بازبینیهاست: چهار مرحله بازخورد و اصلاح، مطابق محدودهٔ قرارداد. اگر سایت فعلی دارید، نقطهٔ شروع میتواند چکاپ رایگان باشد که گزارش PDF آن، ورودی همان جلسهٔ نیازسنجی میشود.
سرعت پروژه، بیش از آنکه به تیم فنی وابسته باشد، به آمادهبودن شما وابسته است. چیزهایی که در عمل پروژهها را معطل میکنند تقریباً همیشه یکساناند: محتوای صفحات و عکس محصولات، فهرست دقیق محصولات یا خدمات، دسترسی به سایت و پایگاه دادهٔ فعلی در پروژههای بازطراحی، مشخصنبودن فردی که در سازمان شما حق تصمیم نهایی دارد، و اطلاعات درگاه پرداخت و حسابهای توسعهدهندهٔ مارکت. اگر اینها را زودتر آماده کنید، مراحل بازبینی بهجای انتظار برای رسیدن یک فایل، صرف بهبود واقعی محصول میشود.
دربارهٔ زمان هم صادق باشیم: ما زمان تحویل قطعی و از پیشتعیینشده اعلام نمیکنیم، چون زمان واقعی به محدودهٔ پروژه، تعداد اتصالها و سرعت بازخورد شما بستگی دارد. زمانبندی در پروپوزال و بهصورت مرحلهای مشخص میشود و هر مرحله، تحویلی قابل مشاهده دارد — نه یک وعدهٔ کلی برای روز آخر. اگر پیمانکاری پیش از دیدن نیازهای شما تاریخ قطعی میدهد، آن تاریخ یک حدس است، نه یک تعهد؛ و حدسی که با امضا رسمی شود، معمولاً به بحث تبدیل میشود.
به همین دلیل، پروپوزال مهمترین سندی است که پیش از امضا میخوانید. فهرست زیر را بهعنوان چکلیست بردارید — چه با ما کار کنید، چه با هر پیمانکار دیگری:
- محدودهٔ دقیق پروژه: فهرست آنچه ساخته میشود و صریحاً آنچه ساخته نمیشود
- مراحل تحویل و اینکه هر پرداخت به کدام تحویل گره خورده است (پرداخت تا چهار مرحله)
- تعداد و شرایط بازبینیها و اینکه Change Request از کجا شروع میشود
- زیرساختی که پروژه روی آن اجرا میشود و اینکه هزینهاش داخل پروپوزال است یا جدا
- شرایط تحویل سورسکد، مستندات و دسترسیهای مدیریتی
- قرارداد نگهداری: چه چیزی داخل آن است، چه چیزی نیست و از چه زمانی شروع میشود
- اینکه دامنه و حسابهای مارکت به نام چه کسی ثبت میشوند
پاسخ کوتاه و بیتعارف: دامنه و دادههای کسبوکار از آنِ شماست، و شرایط تحویل سورسکد و مستندات چیزی است که در قرارداد مشخص میشود — نه چیزی که باید پس از تحویل دربارهٔ آن مذاکره کنید. توصیهٔ ما به هر کارفرما، حتی وقتی طرف قرارداد ما نیست، همین است: پیش از امضا، این سه مورد را جداگانه و بهصورت مکتوب روشن کنید. بیشتر اختلافهای پس از پروژه، از مبهمماندن دقیقاً همین سه بند شروع میشود.
دربارهٔ دامنه یک قاعدهٔ ساده وجود دارد که همیشه به نفع شماست: دامنه باید به نام کسبوکار خودتان ثبت شود، نه به نام پیمانکار. دامنه هویت برند شماست و اگر روی نام شخص یا شرکت دیگری ثبت شده باشد، در روز اختلاف به اهرم فشار تبدیل میشود. برتینا خودش ثبتکنندهٔ دامنه است و دامنه را به نام خودتان و در دسترس خودتان ثبت میکند؛ کنترل مدیریتی و امکان انتقال، همیشه با شماست. همین قاعده دربارهٔ حسابهای توسعهدهندهٔ مارکتها هم برقرار است و بهتر است در همان قرارداد تعیین تکلیف شود.
دادهها — مشتریان، سفارشها، محتوا و فایلها — دارایی کسبوکار شما هستند و باید در هر لحظه قابل استخراج باشند. پرسش درست این نیست که «داده مال کیست؟»، بلکه این است که «چطور میتوانم یک نسخهٔ کامل و قابل استفاده از آن بگیرم؟» اگر پاسخ این پرسش روشن نیست، شما در عمل قفل شدهاید، حتی اگر روی کاغذ مالک باشید. در پروژههای یکپارچه این کار سادهتر است، چون یک پایگاه دادهٔ واحد وجود دارد؛ خروجیگرفتن از یک سیستم، بهمراتب سادهتر از سرهمکردن داده از دو سیستم ناسازگار است.
دربارهٔ سورسکد هم بر خلاف تبلیغهای رایج، پاسخ یکسانی برای همهٔ پروژهها وجود ندارد و ما وعدهٔ کلی نمیدهیم: شرایط تحویل سورسکد و مستندات در قرارداد هر پروژه مشخص میشود. آنچه از روز اول قطعی است، دسترسیهای مدیریتی است — پنل مدیریت، کاربر مدیر و کنترل محتوا در اختیار شماست و آموزش کار با آن، بخشی از تحویل است. اگر تحویل کامل سورسکد برای شما اهمیت راهبردی دارد، جای طرح آن همان جلسهٔ نیازسنجی است، نه هفتهٔ بعد از انتشار.
انتشار، پایان پروژه نیست؛ نقطهای است که محصول تازه شروع میکند به تولید داده. از آن لحظه سه دستهٔ کار متفاوت آغاز میشود که خلطکردنشان رایجترین سوءتفاهم قراردادی در این حوزه است: نگهداری (کارِ زنده و سالم نگهداشتن)، پشتیبانی (پاسخ به مشکل و پرسش) و توسعه (افزودن چیز جدید). نگهداری ماهانه در برتینا از ۱۰ میلیون تومان در ماه شروع میشود و حداقل دورهٔ آن شش ماه است؛ محدودهٔ دقیق آن در قرارداد نگهداری تعریف میشود.
اما چرا نگهداری اختیاری نیست؟ چون محیط زیر پای محصول شما ثابت نمیماند. اندروید و iOS هر سال نسخهٔ جدید منتشر میکنند و اپلیکیشنی که بهروز نشود، دیر یا زود روی دستگاههای تازه دچار خطا میشود یا با قوانین جدید مارکتها ناسازگار میشود. مرورگرها، کتابخانهها، افزونهها و گواهیهای امنیتی هم همینطور. یک وصلهٔ امنیتی نصبنشده، یک SSL تمدیدنشده و یک کتابخانهٔ قدیمی، سه علتِ کاملاً قابل پیشگیریاند که سرویسهای رهاشده را از کار میاندازند — و هر سه، ماهها پیش از حادثه قابل رفع بودهاند.
توسعهٔ مرحلهای هم همان چیزی است که پروژه را از سرنوشت «یکبار ساختن و رهاکردن» نجات میدهد. بهجای ریختن همهٔ ایدهها در نسخهٔ اول — که هم هزینه را بالا میبرد و هم انتشار را عقب میاندازد — نسخهٔ اول را به هستهٔ ضروری محدود کنید و بقیه را به فازهای بعد بسپارید. مزیت پنهان این کار این است که فاز دوم را دیگر بر اساس حدس نمیسازید، بلکه بر اساس رفتار واقعی کاربران نسخهٔ اول میسازید؛ دادهای که پیش از انتشار بهسادگی وجود نداشت و هیچ جلسهای هم آن را تولید نمیکند.
در ماههای اول پس از انتشار، این نشانهها را زیر نظر بگیرید — همانهایی که تصمیم فاز بعدی را برایتان میسازند:
- خطاهایی که کاربران واقعی میبینند، نه فقط خطاهایی که در تست دیده شد
- صفحات و مسیرهایی که کاربر در آنها رها میکند و جلوتر نمیرود
- زمان پاسخ سرور و API زیر بار واقعی، نه بار آزمایشی روز تحویل
- نظرها و امتیازهای مارکت، که مستقیماً روی نصبهای بعدی اثر میگذارند
- حجم پایگاه داده و مصرف منابع سرور، تا ارتقا پیش از کندی انجام شود
- تاریخ تمدید دامنه، گواهی SSL و سرویسهای زیرساختی
