نرم‌افزار آماده یا اختصاصی؛ چگونه تصمیم بگیریم؟

سه گزینه را ببینید: آماده، اختصاصی و ترکیبی

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

منبع فنی این بخش: Government Digital Service [۱]

شرط‌های حیاتی را پیش از امتیازدهی تعیین کنید

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

هزینه مالکیت را با فرض‌های مشترک محاسبه کنید

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

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

همان سناریو را به همه گزینه‌ها بدهید

برای مثال آموزشی یک عمده‌فروش، سناریو را از سفارش مشتری با قیمت قراردادی تا رزرو موجودی، تأیید و لغو دنبال کنید. از هر عرضه‌کننده بخواهید با داده بی‌نام همین مسیر را اجرا کند؛ فیلم معرفی یا اسکرین‌شات جای اجرای سناریو را نمی‌گیرد. اگر اتصال واقعی در آزمون ممکن نیست، این بخش را اثبات‌نشده ثبت کنید. در گزینه اختصاصی هم نمونه اولیه فقط فرض‌های آزموده‌شده را اثبات می‌کند، نه همه قابلیت‌های آینده را.

• نتیجه هر نیاز را به «مشاهده‌شده»، «تعهد کتبی» و «اثبات‌نشده» تفکیک کنید.
• کاربر روزانه، مسئول داده و مسئول بهره‌برداری را در ارزیابی وارد کنید.
• یک خطا یا استثنا مانند موجودی ناکافی و یک آزمون دسترسی را کنار مسیر موفق اجرا کنید.

پرسش‌های مالکیت، ارتقا و خروج را مکتوب کنید

مالکیت کد به‌تنهایی انتقال‌پذیری ایجاد نمی‌کند؛ دسترسی به مخزن، روش ساخت، مجوز وابستگی‌ها و راهنمای بهره‌برداری هم باید روشن باشد. در محصول آماده، حق خروج داده به معنی خروج قابل استفاده نیست؛ قالب، پیوست‌ها، شناسه‌ها، هزینه و زمان دریافت را بپرسید. برای هر گزینه، تغییر عرضه‌کننده یا تیم پشتیبان را به یک تمرین قابل بررسی تبدیل کنید. جزئیات تعهدها باید در قرارداد متناسب با پروژه بررسی شوند.

• چه کسی نسخه پشتیبان را تهیه می‌کند و چه کسی بازیابی را آزمایش می‌کند؟
• ارتقای محصول چه اثری بر افزونه‌ها و اتصال‌ها دارد و آزمون آن با کیست؟
• پس از پایان همکاری، کدام دسترسی‌ها، مستندات و داده‌ها تحویل می‌شود؟
• برای رخداد، تغییر ضروری و پایان پشتیبانی، مسئول و مسیر ارتباط چیست؟

چه زمانی هر رویکرد ارزش بررسی دارد؟

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

یک یادداشت تصمیم قابل بازبینی بسازید

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

• تهیه بریف و معیار پذیرش پس از تصمیم ساخت
• بررسی دامنه خدمات نرم‌افزار اختصاصی