توسعه دهندگان سنتی یا قدیمی نرم افزار، رازی را از ما پنهان کرده اند که چندان هم پنهان نیست. رازی پیدا که نه تنها بحثی در آن نیست بلکه جزیی از مدل کاری آنهاست.
رازی که هم شرکت های بزرگ و هم شرکت های تولید نرم افزارمورد استفاده در زندگی روزمره و تجاری ما، می توانند از آن بهره ببرند. اما راز آنها چیست، هزینه های اضافی که نه تنها پنهان نمیکنند بلکه ما نیز به پرداخت آن عادت داریم.
بسیاری از فروشندگان قدیمی نرم افزار، از طریق نگهداری و مراقبت از نرم افزارهایی که می نویسند درآمد بیشتری کسب میکنند.
اگر قانع نشده اید می توانید عبارت "هزینه کلی مالکیت" را در اینترنت سرچ کنید. با سرچ این عبارت تعاریف بسیاری مانند تعریفی که Granter از TCO یا همان هزینه های کلی مالکیت ارائه داده است را خواهید یافت. اما تعریف Granter:
هزینه های کلی مالکیت عبارت است از هزینه های تکمیل، اجرا، پشتیبانی و نگهداری یا ادامه و حذف یک اپلیکیشن.
بعلاوه این مقاله که توسط دانشگاه استفورد ارائه شده اثبات میکند که هزینه ی نگهداری بالغ بر 60 تا 90 درصد از TCO یا هزینه های کلی مالکیت را شامل میشود.
بی توجهی به نگهداری از اپلیکیشن
مشکل فعلی صنعت توسعه وب، عدم توجه و تمرکز بر نگهداری از اپلیکیشن وب است. بنابراین باید پیشنهاد نگهداری از اپلیکیشن را در فهرست خدمات خود بگنجانیم.
صحبت نکردن از بهینه سازی ها و upgrade ها و موکول کردن آن به بعد، امری بی سابقه نیست. علت ،عدم اطمینان از تمایل مشتری به پرداخت هزینه هایی است که از نظر ما برای پیشرفت ضروریست. صحبت نکردن بطور شفاف و آشکارا درباره ی این موارد دلیل بر عدم نیاز اپلیکیشن به نگهداری نیست.
دلیل این پنهان کاری هرچه هست واضح است که ما مشکلات را به آینده موکول میکنیم. اپلیکیشن های نرم افزاری ساخته شده توسط ما مدت های طولانی استفاده خواهند شد. ما باید همچون فروشندگان قدیمی و سنتی نرم افزار فکر کنیم. نرم افزارهای تولید شده، ده یا پانزده سال عمر خواهند کرد و در طول این مدت ما باید بخوبی از آنها نگهداری کنیم.
برای تغییر این رویه چه باید کرد؟ چگونه باید از امنیت، بروز رسانی و حمایت از مشتریان خود اطمینان حاصل کنیم؟ چگونه سهم خودمان از نگهداری را ادا کنیم؟
تعریف مراقبت و نگهداری
سال 2012، Heather Smith و James Mckeen در مقاله ای با عنوان تاثیر نگهداری بر اپلیکیشن، منظور از نگهداری را اینگونه تعریف کردند: انتقال اپلیکیشن به یک سرور جدید، ارتباط با یک سیستم اجرایی جدید، ارتقا به نسخه ی جدید، تغییر جدول مالیات یا سازگاری با قوانین جدید.همه ی اپلیکیشن ها به نگهداری نیاز دارند. درنتیجه می توان گفت پایه و اساس نگهداری بر ارتقا یا upgrading یک اپلیکیشن استوار است تا از این طریق از بازدهی آن اطمینان حاصل شود. بعبارت دیگر نگهداری از اپلیکیشن عبارت است از رفع معایب اپلیکیشن از طریق هرگونه تغییر یا اصلاح در آن و یا سازگاری اپلیکیشن با محیط یا ملزومات تغییر یافته. بنابراین منظور از نگهداری یا مراقبت از اپلیکیشن فقط افزودن کارایی جدید به آن نمی باشد.
بعبارت دیگر نگهداری کاریست ضروری که باید حتما انجام شود تا اپلیکیشن ایمن و قابل اطمینان به کار خود ادامه دهد.
افزودن فیچرهای جدید، چک کردن فایل های log یا تضمین اجرای بک آپ ها هیچکدام در نگهداری از اپلیکیشن جایی ندارند. درواقع منظور از نگهداری از اپلیکیشن، کار کردن روی کدها و اصول پلتفرم بمنظور بروز رسانی و عملکرد طبق انتظارات کاربران است. به چند مثال توجه کنید:
تغییرات پلتفرم و فناوری
کتابخانه های شخص ثالث باید بروز رسانی شوند. زبان مورد استفاده باید بروز رسانی شود. نگهداری یعنی کنترل تغییراتی از این قیبل و گاهی نیز تغییر در کد نویسی.
مقیاس گذاری
همگام با رشد اپلیکیشن مشکلات منبعی نیز بوجود می آیند. روتین های کدی که با ده هزار تراکنش در روز بخوبی کار میکنند با افزایش به ده هزار تراکنش در ساعت ، با مشکل مواجه خواهند شد. بنابراین اپلیکیشن باید بخوبی نظارت شده و با مشاهده هرگونه تغییر، اقدام درست انجام شود.
رفع باگ
با اینکه مساله رفع باگ موردی کاملا واضح است اما ارزش شفاف سازی را دارد. هر نرم افزاری باگ هایی دارد که باید حل شوند. بنابراین تمام مشتریان شما باید حتی اگر شده برای یک دوره کوتاه مدت بعد از تحویل پروژه مبلغی برای رفع باگ ها پرداخت کنند.
فروش دشوار؟
بیشتر همکاران ما بر این باورند که قانع کردن مشتریان به نیاز مبرم به نگهداری کاریست دشوار. آنها از این واهمه دارند که مراجعه کنندگانشان بودجه کافی نداشته باشند.
درواقع فروش این خدمات کار چندان دشواری نیست. ما با افرادی سرو کار داریم که همگی اهل تجارت هستند بنابراین کافیست درباره شرایط مالی نگهداری از اپلیکیشن با آنها صحبت کنیم. آنها بخوبی درک میکنند سرمایه یا دارایی آنها به نگهداری و مراقبت نیاز دارد و در غیر اینصورت ضرر خواهند کرد. کافیست این سرویس را به آنها پیشنهاد دهیم و پیگیر باشیم.
پیشنهاد یک نگهدارنده ((retainer که شامل نگهداری میشود یک متد کاملا تاثیر گذار است. پیشنهادی که مرکز و هسته ی آن نگهداری است مزایا و ارزش های دیگری نیز برای مشتری دارد. به برخی از این مزایا دقت کنید:
گزارش پیشرفت در مقابل KPI ها مانند (ترافیک، تبادلات، حجم سرچ)
فری تایم محدود ماهانه برای تغییرات کوچک در سایت.
گزارش درباره ی زمان توقف، آپدیت های سرور یا تکمیل توسعه.
دسترسی تلفنی به شما یا افراد مشخصی از تیم شما برای پاسخگویی به سوالات.
درواقع شما می توانید نگهدارنده را به عاملی برای پس انداز و ذخیره ی پول مشتری مبدل کنید. بعنوان مثال نیاز مشتری به گرفتن یک گزارش ساده یا خروجی ماهانه از پایگاه داده ها برای پردازش آفلاین. وظیفه ای جزیی برای شما که ارزش زیادی برای مشتری دارد.
مثالی کاربردی
شکی نیست که هر شخص برای پروپوزال نویسی شیوه ی خاص خود را دارد اما در این قسمت به مواردی جزیی برگرفته از نمونه ای کاربردی اشاره میشود.
در بخشی از پروپوزال خود آنجا که باید تصویر خود از آینده را ترسیم کنید می توانید به نگهداری نیز اشاره کنید. درواقع فرصتی است برای استارت روابط بلند مدت.
شما بدنبال فرصتی برای کاهش ریسکی بلند مدت هستید. شما می خواهید از عملکرد خوب اپلیکیشن خود، امنیت مداوم و کار کردن آسان با آن مطمئن شوید. همچنین از اهمیت نگهداری برای سرمایه تجاری بخوبی آگاه هستید.
سپس در بخش قابل تحویل می توانید قسمتی درباره نگهداری بعنوان گزینه ای مستقل یا جزیی از نگهدارنده مداوم اضافه کنید.
در مثال زیر توجه کنید:
ما باور داریم که مشتریان ما نگهداری را هزینه ای ضروری برای و بسایت خود میدانند. اپلیکیشن های وب مدرن درست مانند خانه یا ماشین شما به نگهداری نیاز دارند. به این ترتیب ریسک های محسوسی که در آینده به سرمایه ی شما لطمه میزنند کاهش خواهند یافت.
قطعا شما بعنوان مشتری شدیدا نسبت به حفظ سرمایه و نگهداری اپلیکیشن خود و همچنین اضافه شدن فیچرهای جدید حساس هستید بنابراین پشنهاد ما نگهداری کلی و ریتینر توسعه بصورت ماهیانه و به تعداد X روز در ماه است. بدین ترتیب توسعه دهنده ای که بصورت دوره ای (هفتگی یا ماهانه) روی سیستم شما کار میکند میتواند زمان بیشتری به سایر مسائل از جمله فیچرهای جدید بپردازد .
همانطور که پیشتر اشاره شد این روش فرصتی است بینظیر برای ترکیب نگهداری با سایرسرویس های با ارزش همچون گزارش عملکرد، چک کردن بک آپ ها و یا شاید تماس بمنظور گفتگو درباره پیشرفت و الویت ها.
احتمالا متوجه خواهید شد که بعد از اتمام کار اشاره ی دوباره به ریتینر نخواهد شد. قابل درک است که با وجود مزایای بسیار هم برای شما و هم برای مشتری باید همان ابتدای پروژه به آن اشاره شود اما معرفی دوباره آن در مراحل بالاتر بلامانع است.
چه در فاز دوم پروژه یا مرحله نهایی ، ارائه فاکتور یادآوری نگهداری را فراموش نکنید. آموزش مداوم، گزارش و در دسترس بودن برای پشتیبانی را به آنها یادآوری کنید. تاکید زیادی بر ریتینر داشته باشید و حتما در قالب عبارات مالی، درباره ی آن صحبت کنید مثلا سرمایه ی شما برای حفظ درخشش خود به نگهداری نیاز دارد.
آیا نگهداری می تواند آزاردهنده باشد؟
یکی از تصورهای غلط درباره نگهداری این است که ریتینرهای نگهداری باری است اضافی بر مسئولیت های شما. برخی دلواپس تماس های وقت و بی وقت مشتریان و پرسیدن سوالاتی درباره توییک های کوچک بعنوان جزیی از ریتینر هستند. این نگرانی بیشتر در میان تیم های کوچک و مشاوران انفرادی دیده میشود.
شاید مشتری در آغاز کار لیستی از موانعی دارد که باید روی آن کارشود که البته طبیعی بوده و شما درصورت باتجربه بودن باید انتظار آنرا داشته باشید. اما می توانید براحتی و از طریق تقویت کانال های ارتباطی این مسائل را مدیریت کنید.
با رشد و بلوغ اپلیکیشن، شما نیز به تدریج تنبل خواهید شد. در این حالت ریتینر برای هر دو طرف(هم شما و هم مشتری) ارزش بیشتری می یابد. البته بیشتر به این بستگی دارد که شما چگونه ریتینر را برنامه ریزی کرده اید. شما می توانید هرماه ارزشمند بودن خود به مشتری یادآوری کنید. مثلا می توانید هرماه گزارشی برای آنها فرستاده و از نحوه ی رفع کندی سرعت برای آنها بگویید. بعلاوه باید برای کار کردن روی فیچرهای جدید درخواستی در دسترس باشید. مشتری باید حضور شما را احساس کرده پیشرفت های بدست آمده را ببیند و در نهایت نگرانی خود درباره ی وبسایت را از لیستش حذف کند.
اگر مشتری شما خواهان بهترین خدمات در ازای حق پرداخت ماهانه ی اندک می باشد باید دوباره با وی مذاکره کنید. ارزش کار و خدماتی که ارائه میدهید را به آنها یادآور شوید.
نگهداری آسانتر
درنهایت بمنظور ضمانت بهترین ها برای مشتریان خود و آسانتر کردن زندگی برای خودتان بهنگام ساختن اپلیکیشن های خود از تاکتیک های نامبرده در زیر استفاده کنید:
پشتیبانی بلند مدت (LTS)
استفاده از پلتفرم های فناوری همراه با پشتیبانی بلند مدت تایید شده و upgrade paths.
سیستم عامل پایدار، فریم ورک و CMS upgrades باید در نظر گرفته شده و محاسبه شوند.
همه چیز باید در نسخه ی ساپورت شده اجرا شود.
سلامت پروژه
توافق با مشتری بر سر اولویت ها و معرفی خدمات نگهداری بطور عمومی در بک لاگ فیچر یا سیستم ردیابی مشکلات و مخفی نکردن آنها.
تست های فانکشنال و کد لول امکان کنترل کدهای مشکل زا را به شما داده و به بیرون آمدن مودال ها برای فاکتورینگ دوباره کمک میکنند.
اپلیکیشن را مانیتور کنید تا خطاها و تنگناها را شناسایی کنید. می توان مشکلات مختلف را به بک لاگ توسعه اضافه کرده و آنها را اولویت بندی کرد.
درخواست های پشتیبانی را مانیتور کنید. بدین ترتیب می توانید از بازخورد های مفید کاربران استفاده کرد و از این طریق به نیاز برای نگهداری اشاره کنید.
اپلیکیشن های پرتابل (قابل حمل)
راه اندازی و کار با سیستم باید به آسانی و برای تمام توسعه دهندگان مقدور باشد نه فقط شما. استفاده از سرورهای مجازی و container ها برای تضمین تبادل پذیری یا تشابه نسخه های توسعه یافته ی اپلیکیشن ها.
اپلیکیشن باید بخوبی داکیومنت شده باشد. آرایش استراتژیک ، روند کار و تمام تعاملات ویژه باید نوشته شوند.
نگهداری یک معامله ی برد برد
نگهداری عملی است که حتما باید روی اپلیکیشن انجام شود تا در بلند مدت بدرستی اجرا شده و کار کند. هزینه ی صرف شده برای آن یک هزینه ی تجاری استاندارد است. بطور متوسط 75 درصد از کل هزینه های مالکیت در طول حیات یک اپلیکیشن نرم افزاری را شامل میشود.
ما بعنوان افرادی حرفه ای وظیفه داریم درباره نگهداری به مشتریان خود آموزش داده و اطلاع رسانی کنیم. نگهداری علاوه بر فرصتی عالی برای کسب درآمد اضافی، برای مشتری نیز ارزشمند است. درواقع نگهداری فرصتی است برای حفظ تداوم روابط تجاری با مشتری و درصورت نیاز آنها به تجهیزات جدید شما نخستین فرد برای مراجعه هستید.
ادامه ی حفظ ارزش ها از طریق ریتینر منجر به اعتماد سازی بین شما و مشتری میشود. پلتفرمی برای پیشنهاد فیچرهای جدید و ارتقا نرم افزارها. شانسی بینظیر برای بردی حتمی. کاهش هزینه های مادام العمر، کاهش ریسک و عدم نگرانی درمورد عملکرد و امنیت از جمله مزایای نگهداری برای مشتری هستند. با اطلاع رسانی درباره ی اهمیت نگهداری اپلیکیشن وب در حق خود، مشتری و کل این صنعت لطف می کنید.