قرارداد طراحی سایت امضا می‌شود، مبلغ پرداخت می‌شود، سایت تحویل داده می‌شود و همه راضی‌اند. چند ماه بعد، افزونه‌ای به‌روزرسانی نمی‌شود و فرم تماس از کار می‌افتد. بعد گواهی امنیتی منقضی می‌شود و مرورگرها به بازدیدکننده‌ها هشدار می‌دهند. بعد نسخه‌ی تازه‌ی سیستم مدیریت محتوا منتشر می‌شود و کسی نمی‌داند به‌روزرسانی آن چه چیزهایی را خراب می‌کند. هر کدام از این اتفاق‌ها یک تماس، یک مذاکره و یک فاکتور تازه است؛ هزینه‌ای که هیچ‌وقت در عدد اولیه‌ی قرارداد دیده نشده بود.
مدیرانی که با این وضعیت روبه‌رو می‌شوند، معمولا احساس می‌کنند فریب خورده‌اند. گاهی هم واقعا همین‌طور است. اما بیشتر وقت‌ها مشکل این است که هیچ‌یک از دو طرف، از ابتدا درباره‌ی زندگی سایت بعد از روز تحویل حرف نزده‌اند. موضع ما در گرین‌لبز این است: سایت و نرم‌افزار محصول تمام‌شده نیستند؛ دارایی زنده‌اند. قراردادی که فقط هزینه‌ی ساخت را می‌بیند و هزینه‌ی نگهداری را نمی‌بیند، نیمی از قیمت واقعی را پنهان کرده است.
نگهداری دقیقا شامل چه چیزهایی است
در مهندسی نرم‌افزار، نگهداری نرم‌افزار معمولا در چند دسته تعریف می‌شود: اصلاح خطاها، انطباق با تغییرات محیط، بهبود قابلیت‌ها و پیشگیری از مشکلات آینده. این دسته‌بندی برای سایت‌های کسب‌وکار هم کاملا صادق است، فقط با زبانی ملموس‌تر.
اصلاح خطا
هیچ نرم‌افزاری بدون خطا تحویل داده نمی‌شود. بعضی خطاها فقط وقتی دیده می‌شوند که کاربران واقعی با داده‌ی واقعی و دستگاه‌های متنوع از سایت استفاده می‌کنند. دوره‌ی تضمین بعد از تحویل معمولا بخشی از این خطاها را پوشش می‌دهد، اما خطاهایی که ماه‌ها بعد پیدا می‌شوند، باید جایی در برنامه داشته باشند.
انطباق با تغییر محیط
سایت شما در محیطی زندگی می‌کند که دائم تغییر می‌کند: نسخه‌های تازه‌ی مرورگرها، به‌روزرسانی‌های زبان برنامه‌نویسی و پایگاه داده روی سرور، تغییرات درگاه پرداخت و سرویس پیامک، و تغییر قواعد موتورهای جست‌وجو. حتی اگر خود سایت هیچ تغییری نکند، این محیط آن را آرام‌آرام کهنه و ناسازگار می‌کند.
امنیت
آسیب‌پذیری‌های تازه مدام در کتابخانه‌ها، افزونه‌ها و چارچوب‌ها کشف می‌شوند. فهرست OWASP Top Ten نشان می‌دهد رایج‌ترین خطرهای امنیتی وب چه دسته‌هایی‌اند و یکی از آنها دقیقا استفاده از اجزای آسیب‌پذیر و قدیمی است. سایتی که به‌روزرسانی نمی‌شود، با گذشت هر ماه هدف آسان‌تری می‌شود.
پشتیبان‌گیری و پایش
کسی باید مطمئن باشد که از سایت و داده‌هایش به‌طور منظم پشتیبان گرفته می‌شود، آن پشتیبان‌ها واقعا قابل بازگردانی‌اند و اگر سایت از دسترس خارج شد، کسی زودتر از مشتری‌ها باخبر می‌شود.
بهبود و تغییرات کوچک
کسب‌وکار تغییر می‌کند و سایت باید همراهش تغییر کند: محصول تازه، قیمت تازه، صفحه‌ی کمپین، فرم تازه. این تغییرات کوچک‌اند، اما اگر هر کدام یک پروژه‌ی جداگانه با مذاکره و قیمت‌گذاری مستقل باشد، هم کند می‌شوند و هم گران.
چرا این هزینه در قرارداد دیده نمی‌شود
دلیل اول، رقابت قیمتی است. در بازاری که کارفرما چند پیشنهاد را کنار هم می‌گذارد و معمولا پایین‌ترین عدد را انتخاب می‌کند، هر شرکتی که هزینه‌ی نگهداری را صادقانه در پیشنهادش بیاورد، گران‌تر به نظر می‌رسد. پس بسیاری ترجیح می‌دهند فقط هزینه‌ی ساخت را بگویند و بقیه را به بعد بسپارند.
دلیل دوم، نگاه پروژه‌ای کارفرما است. بسیاری از سازمان‌ها سایت را مثل خرید یک دستگاه می‌بینند: یک بار پول می‌دهی و تمام. در این نگاه، هزینه‌ی ماهانه یا سالانه برای «چیزی که ساخته شده» عجیب و حتی مشکوک به نظر می‌رسد.
دلیل سوم، نبود تعریف روشن است. حتی وقتی بندی درباره‌ی پشتیبانی در قرارداد هست، اغلب مبهم است: «پشتیبانی شش‌ماهه». اما پشتیبانی یعنی چه؟ رفع خطا؟ به‌روزرسانی امنیتی؟ تغییر محتوا؟ اضافه کردن صفحه؟ این ابهام، بعدها منبع اصلی اختلاف است. کارفرما فکر می‌کند همه چیز پوشش داده شده و تیم سازنده فکر می‌کند فقط رفع خطاهای واضح تعهدش است. هر دو با حسن نیت قرارداد را خوانده‌اند و هر دو برداشت متفاوتی دارند. اولین درخواستی که در این فاصله بیفتد، اعتماد بین دو طرف را می‌شکند، در حالی که یک پاراگراف روشن در قرارداد می‌توانست از آن جلوگیری کند. وقتی هم که این اعتماد شکست، معمولا کار به جایی می‌رسد که کارفرما تیم را عوض می‌کند و تیم تازه باید سایتی را بشناسد که هیچ مستنداتی ندارد؛ هزینه‌ای که باز هم در هیچ قراردادی دیده نشده بود.
در مقاله‌ی قیمت‌گذاری پروژه‌ی دیجیتال گفتیم که عدد قرارداد در واقع تصمیمی درباره‌ی آینده‌ی محصول است. هزینه‌ی نگهداری دقیقا همان بخشی از آینده است که بیشتر از همه نادیده گرفته می‌شود.
هزینه‌ی نگهداری نکردن
اگر نگهداری هزینه دارد، نگهداری نکردن هم هزینه دارد؛ فقط این هزینه دیرتر، ناگهانی‌تر و معمولا بزرگ‌تر پرداخت می‌شود.
بدهی فنی انباشته. سایتی که سال‌ها به‌روز نشده، روزی به جایی می‌رسد که به‌روزرسانی‌اش عملا یعنی بازسازی. فاصله‌ی نسخه‌ها آن‌قدر زیاد شده که هیچ مسیر ساده‌ای برای رسیدن به نسخه‌ی امروز وجود ندارد.
حادثه‌ی امنیتی. هک شدن سایت فقط مشکل فنی نیست. ممکن است داده‌ی مشتری‌ها افشا شود، سایت به ابزار ارسال هرزنامه یا بدافزار تبدیل شود و موتورهای جست‌وجو آن را با هشدار نشان دهند. پاک کردن این آسیب‌ها معمولا گران‌تر از سال‌ها نگهداری منظم است.
از دست رفتن فرصت. وقتی هر تغییر کوچک هفته‌ها طول می‌کشد، تیم بازاریابی و فروش دیگر سراغ سایت نمی‌روند. کمپین‌ها بدون صفحه‌ی مناسب اجرا می‌شوند و سایت آرام‌آرام از ابزار فروش به یک کارت ویزیت فراموش‌شده تبدیل می‌شود.
وابستگی و بی‌پناهی. وقتی قرارداد نگهداری روشنی وجود ندارد، در روز حادثه دست شما خالی است. ممکن است سازنده‌ی اولیه در دسترس نباشد یا قیمتی بخواهد که در شرایط اضطرار مجبور به پذیرفتنش هستید. اگر حتی دسترسی‌های اصلی هم به نام شما نباشد، وضعیت بدتر است؛ موضوعی که در مقاله‌ی دامنه و هاست به نام شما نیست؟ به آن پرداخته‌ایم.
مدل‌های رایج نگهداری
هیچ مدل واحدی برای همه‌ی کسب‌وکارها درست نیست. اما شناختن مدل‌های رایج کمک می‌کند انتخاب آگاهانه‌تری داشته باشید.
پرداخت به ازای هر درخواست
هر بار که مشکلی پیش می‌آید یا تغییری لازم است، درخواست می‌دهید و جداگانه هزینه‌اش را می‌پردازید. این مدل برای سایت‌های بسیار ساده که کمتر تغییر می‌کنند مناسب است. ضعفش این است که هیچ‌کس مسئول پیشگیری نیست؛ کسی سراغ به‌روزرسانی امنیتی نمی‌رود، چون کسی درخواستش را نداده است.
قرارداد ماهانه یا سالانه با دامنه‌ی مشخص
مبلغ ثابتی می‌پردازید و در مقابل، فهرست مشخصی از خدمات دریافت می‌کنید: به‌روزرسانی‌های امنیتی، پشتیبان‌گیری، پایش، رفع خطا و تعداد مشخصی ساعت برای تغییرات کوچک. این مدل برای بیشتر سایت‌های کسب‌وکار منطقی‌ترین انتخاب است، به شرط آنکه دامنه‌ی خدمات دقیق نوشته شده باشد.
تیم داخلی
برای کسب‌وکارهایی که سایت یا نرم‌افزارشان بخش اصلی عملیات است، داشتن نیروی فنی داخلی منطقی است. اما نیروی داخلی هم بدون مستندات، دسترسی‌های مرتب و فرایند روشن، ریسک وابستگی به یک نفر را جایگزین ریسک وابستگی به یک شرکت بیرونی می‌کند.
بودجه‌ی نگهداری را چطور برآورد کنیم
هیچ عدد جهانی برای هزینه‌ی نگهداری وجود ندارد و به هر کسی که بدون دیدن سایت شما درصد ثابتی می‌گوید، باید با احتیاط نگاه کرد. اما می‌شود عوامل اصلی این هزینه را شناخت و با آنها برآورد معقولی ساخت.
پیچیدگی فنی. یک سایت معرفی ساده با چند صفحه‌ی ثابت، نیاز نگهداری کمی دارد. فروشگاه اینترنتی با درگاه پرداخت، اتصال به انبار و حساب کاربری مشتری، یا نرم‌افزاری اختصاصی با منطق پیچیده، نیاز بسیار بیشتری دارد. هر اتصال به سرویس بیرونی، نقطه‌ای است که ممکن است روزی تغییر کند و کار را خراب کند.
تعداد اجزای شخص ثالث. هر افزونه، کتابخانه یا قالب آماده، جزئی است که باید به‌روز بماند. سایتی که روی ده‌ها افزونه ساخته شده، ممکن است ارزان ساخته شده باشد، اما نگهداری‌اش گران است.
نرخ تغییر کسب‌وکار. اگر هر ماه محصول، کمپین یا صفحه‌ی تازه دارید، بخش بزرگی از نگهداری، تغییرات محتوایی و ساختاری است. اگر سایت شما سال‌ها ثابت می‌ماند، این بخش کوچک است.
حساسیت داده و دسترس‌پذیری. سایتی که داده‌ی شخصی یا مالی نگه می‌دارد، یا هر ساعت از کار افتادنش فروش را متوقف می‌کند، به پایش و امنیت جدی‌تری نیاز دارد.
پیشنهاد عملی ما این است: در زمان دریافت پیشنهاد برای ساخت، از همان تیم بخواهید برآورد نگهداری سال اول را هم جداگانه و با فهرست خدمات بدهد. مقایسه‌ی پیشنهادها با جمع هزینه‌ی ساخت و نگهداری، تصویر بسیار صادقانه‌تری از مقایسه‌ی عدد ساخت به‌تنهایی می‌دهد.
سهم کارفرما در نگهداری
نگهداری فقط کار تیم فنی نیست. بخشی از آن، تصمیم‌ها و کارهایی است که فقط خود کسب‌وکار می‌تواند انجام دهد.
یک نفر در سازمان باید مالک سایت باشد: کسی که درخواست‌ها را جمع می‌کند، اولویت می‌دهد و با تیم فنی هماهنگ است. بدون این نقش، درخواست‌ها از چند نفر و با اولویت‌های متناقض می‌رسند و تیم فنی نمی‌داند کدام را اول انجام دهد.
محتوا هم بخشی از نگهداری است. قیمت‌هایی که عوض شده، کارمندی که رفته اما عکسش هنوز در صفحه‌ی تیم است، خدمتی که دیگر ارائه نمی‌شود؛ اینها را تیم فنی نمی‌داند، مگر کسی به او بگوید.
و در نهایت، بازبینی دوره‌ای. سالی یک بار با تیم نگهداری بنشینید و بپرسید سایت در چه وضعیتی است، چه ریسک‌هایی دیده می‌شود و آیا وقت بازسازی بخشی از آن رسیده است یا نه. این گفت‌وگو جلوی غافلگیری‌های بزرگ را می‌گیرد.
در قرارداد نگهداری چه چیزهایی باید روشن باشد
اگر قرارداد نگهداری می‌بندید، یا بخش پشتیبانی قرارداد ساخت را بازبینی می‌کنید، این موارد باید صریح نوشته شوند:
- فهرست خدمات منظم: دقیقا چه کارهایی به‌طور دوره‌ای و بدون درخواست شما انجام می‌شود و هر چند وقت یک بار.
- تعریف خطا و تغییر: چه چیزی رفع خطا حساب می‌شود و چه چیزی تغییر یا قابلیت تازه، و هر کدام چطور قیمت‌گذاری می‌شود.
- زمان پاسخ: برای مشکلات بحرانی، مثل از دسترس خارج شدن سایت، و برای درخواست‌های عادی، زمان پاسخ و زمان رفع جداگانه.
- پشتیبان‌گیری: هر چند وقت یک بار، کجا نگهداری می‌شود و آخرین بار کی آزمون بازگردانی انجام شده است.
- گزارش دوره‌ای: چه گزارشی و هر چند وقت یک بار به دست شما می‌رسد؛ تا بدانید برای چه پول می‌دهید.
- دسترسی‌ها و مستندات: همه‌ی دسترسی‌ها به نام شما باشد و در پایان قرارداد، همه چیز بدون شرط تحویل داده شود.
- شرایط پایان قرارداد: اگر خواستید سراغ تیم دیگری بروید، انتقال چطور و در چه مدتی انجام می‌شود.
آزمون سریع: سایت شما امروز نگهداری می‌شود؟
به این پرسش‌ها پاسخ «بله» یا «نه» بدهید:
- می‌دانید آخرین به‌روزرسانی امنیتی سایت کی انجام شده است؟
- می‌دانید آخرین پشتیبان کامل کی گرفته شده و کجاست؟
- اگر همین امشب سایت از دسترس خارج شود، کسی پیش از مشتری‌ها باخبر می‌شود؟
- می‌دانید برای یک تغییر کوچک در صفحه‌ی اصلی با چه کسی و در چه مدتی باید هماهنگ کنید؟
- قراردادی مکتوب دارید که این موارد را پوشش دهد؟
اگر بیش از یکی دو پاسخ «نه» است، سایت شما نگهداری نمی‌شود؛ فقط هنوز اتفاقی برایش نیفتاده است.
جمع‌بندی
هزینه‌ی ساخت سایت، هزینه‌ی ورود است، نه هزینه‌ی مالکیت. کسب‌وکاری که از ابتدا هزینه‌ی نگهداری را در بودجه ببیند، نه تنها از حادثه‌های گران در امان می‌ماند، بلکه سایتی دارد که همراه کسب‌وکار رشد می‌کند. پیشنهاد ساختی که درباره‌ی نگهداری سکوت کرده، ارزان‌تر نیست؛ فقط بخشی از قیمتش را برای بعد نگه داشته است.
اگر می‌خواهید بدانید سایت یا نرم‌افزار فعلی‌تان در چه وضعیتی از نظر نگهداری است، یا برای پروژه‌ی تازه از همان ابتدا هزینه‌ی واقعی مالکیت را بسنجید، تیم گرین‌لبز می‌تواند این بررسی را کنارتان انجام دهد. خدمات گرین‌لبز را ببینید.
