اشتباهات رایج در سفارش نرم‌افزار اختصاصی؛ ۱۴ خطای پرهزینه

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

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

سفارش موفق فقط به توانایی برنامه‌نویس وابسته نیست. کارفرما نیز باید مسئله، کاربران، مسئول تصمیم‌گیری، اولویت‌ها و روش تأیید خروجی را مشخص کند. همکاری منظم میان کارفرما و تیم توسعه، تحویل مرحله‌ای و امکان واکنش کنترل‌شده به تغییرات، از اصول پذیرفته‌شده توسعه چابک هستند.

اولین تصمیم این نیست که نرم‌افزار با چه زبان یا فناوری‌ای ساخته شود. ابتدا باید مشخص شود آیا توسعه اختصاصی بهترین راه‌حل است یا خیر.

در بعضی شرایط، یک نرم‌افزار آماده، ابزار ابری، افزونه، اتصال میان دو سیستم یا اصلاح فرایند فعلی می‌تواند مسئله را با هزینه و ریسک کمتر حل کند.

ساخت نرم‌افزار سفارشی معمولاً زمانی توجیه بیشتری دارد که:

فرایند کسب‌وکار واقعاً اختصاصی باشد.

ابزارهای آماده بخش مهمی از نیاز را پوشش ندهند.

یکپارچه‌سازی چند واحد یا سامانه ضروری باشد.

تعداد کاربران یا تراکنش‌ها قابل‌توجه باشد.

محدودیت امنیتی یا عملیاتی مشخصی وجود داشته باشد.

نرم‌افزار برای کسب‌وکار مزیت رقابتی ایجاد کند.

سازمان برنامه بلندمدتی برای توسعه محصول داشته باشد.

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

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

تیم توسعه باید بداند مشکل فعلی چیست، چه افرادی با آن روبه‌رو هستند و حل آن چه نتیجه‌ای ایجاد می‌کند.

به‌جای این جمله:

«یک داشبورد مدیریتی کامل می‌خواهیم.»

بهتر است نوشته شود:

«مدیر فروش برای تهیه گزارش عملکرد شعب به سه روز زمان نیاز دارد و هدف این است که اطلاعات فروش به‌صورت روزانه و یکپارچه نمایش داده شوند.»

تعریف مسئله باید حداقل شامل این موارد باشد:

وضعیت فعلی

افراد درگیر

هزینه یا پیامد مشکل

نتیجه مورد انتظار

شاخص اندازه‌گیری موفقیت

محدودیت‌های اصلی

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

مدیران اهداف و سیاست‌های سازمان را می‌شناسند، اما همیشه جزئیات اجرای روزانه را نمی‌دانند.

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

در نیازسنجی باید با گروه‌های مختلف صحبت شود:

مدیران تصمیم‌گیر

کاربران اصلی

مدیران واحدها

واحد فناوری اطلاعات

مسئول امنیت

واحد مالی و حقوقی

مشتریان یا تأمین‌کنندگان، در صورت ارتباط

تیم پشتیبانی

کاربران شعب یا دورکار

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

محدوده مشخص می‌کند تیم دقیقاً چه چیزی باید تحویل دهد و چه مواردی فعلاً در پروژه قرار ندارند.

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

برای جلوگیری از این اختلاف، محدوده باید در چند سطح ثبت شود:

فرایندهای داخل پروژه : ثبت سفارش، تأیید، پرداخت و گزارش

قابلیت‌های اصلی : کاربران، نقش‌ها، اعلان‌ها و داشبورد

کاربران : مدیر، کارشناس، مشتری و تأمین‌کننده

سامانه‌های متصل : حسابداری، سایت و پیامک

بسترها : وب، موبایل یا دسکتاپ

موارد خارج از پروژه : باشگاه مشتریان و هوش مصنوعی

نسخه‌های آینده : اپلیکیشن و گزارش‌ساز پیشرفته

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

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

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

قابلیت‌ها را می‌توان در چهار گروه قرار داد:

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

قیمت پایین ممکن است نتیجه استفاده از راهکار ساده‌تر باشد، اما همیشه به معنای انتخاب اقتصادی‌تر نیست.

برآوردی که بسیار کمتر از سایر پیشنهادهاست ممکن است بعضی هزینه‌ها را نادیده گرفته باشد:

تحلیل نیازمندی‌ها

طراحی UI و UX

تست

امنیت

انتقال اطلاعات

استقرار

مستندات

آموزش

پشتیبانی

زیرساخت و سرویس‌های جانبی

اصلاحات پس از تحویل

برای مقایسه پیشنهادها، فقط رقم نهایی را بررسی نکنید.

داشتن چند تصویر زیبا از پروژه‌های قبلی برای ارزیابی کافی نیست.

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

پیش از قرارداد درباره این موضوعات سؤال کنید:

مدیر پروژه چه کسی است؟

تحلیل نیازمندی را چه کسی انجام می‌دهد؟

طراحی رابط بر چه اساسی تأیید می‌شود؟

توسعه فرانت‌اند و بک‌اند توسط چه افرادی انجام می‌شود؟

مسئول تست و امنیت چه کسی است؟

کد چگونه بازبینی می‌شود؟

نسخه‌ها کجا نگهداری می‌شوند؟

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

در صورت تغییر عضو تیم چه اتفاقی می‌افتد؟

چه کسی پاسخ‌گوی نهایی کارفرماست؟

وجود یک نماینده مشخص از طرف کارفرما نیز ضروری است. تصمیم‌گیری چند مدیر با نظرات متناقض می‌تواند پروژه را متوقف کند.

عبارت‌هایی مانند «طراحی کامل نرم‌افزار»، «داشبورد حرفه‌ای» یا «رابط کاربرپسند» قابل‌اندازه‌گیری نیستند.

برای هر مرحله باید مشخص شود چه چیزی تحویل داده می‌شود و کارفرما چگونه آن را تأیید می‌کند.

معیار پذیرش می‌تواند شامل این موارد باشد:

کاربر بتواند درخواست جدید ثبت کند.

فیلدهای ضروری بدون مقدار قابل‌ثبت نباشند.

درخواست بر اساس مبلغ به مدیر مناسب ارجاع شود.

تغییر وضعیت در سابقه سیستم ذخیره شود.

گزارش با فیلتر بازه زمانی کار کند.

سطح دسترسی هر نقش مطابق جدول تأییدشده باشد.

اطلاعات در فرمت موردتوافق خروجی گرفته شوند.

معیار پذیرش فهرستی از نتایج قابل‌آزمایش است که نشان می‌دهد قابلیت نیاز کاربر را برآورده کرده است.

موضوع :مواردی که باید روشن شوند

موضوع قرارداد :محصول، ماژول‌ها و بسترها

محدوده :امکانات داخل و خارج پروژه

خروجی‌ها :کد، پایگاه داده، مستندات و طراحی‌ها

زمان‌بندی :مراحل، نقاط تحویل و وابستگی‌ها

پرداخت :مبلغ هر مرحله و شرط پرداخت

پذیرش :معیار تست و مدت بررسی کارفرما

تغییرات :روش ثبت و قیمت‌گذاری درخواست جدید

مالکیت :حقوق کد، طراحی، داده و ابزارهای ثالث

محرمانگی :اطلاعات محرمانه و تعهدات طرفین

امنیت :الزامات، تست‌ها و مسئولیت‌ها

پشتیبانی :گارانتی، SLA و هزینه دوره بعد

فسخ :شرایط توقف و نحوه تحویل دارایی‌ها

حل اختلاف :مسیر مذاکره و مرجع رسیدگی

خروج امن :تحویل دسترسی‌ها، اطلاعات و مستندات

قراردادهای نمونه فارسی نیز معمولاً موضوع، مدت، شرح خدمات، پرداخت، تحویل و پشتیبانی را از اجزای اصلی همکاری معرفی می‌کنند. جزئیات حقوقی باید با توجه به قانون حاکم و با نظر متخصص حقوقی تنظیم شود.

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

موضوعات مهم عبارت‌اند از:

مالکیت سورس‌کد اختصاصی

حق تغییر و توسعه توسط تیم دیگر

مالکیت طراحی UI و UX

مالکیت ساختار پایگاه داده

مالکیت داده‌های ثبت‌شده

حق استفاده از کتابخانه‌ها و کدهای عمومی

مجوز سرویس‌ها و ابزارهای ثالث

دسترسی به مخزن کد

تحویل نسخه قابل‌اجرا

تحویل کلیدها و حساب‌های زیرساخت

استفاده مجدد پیمانکار از اجزای پروژه

وضعیت مالکیت پس از فسخ

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

تغییر نیازها در پروژه نرم‌افزاری طبیعی است. مشکل زمانی ایجاد می‌شود که درخواست‌ها شفاهی، پراکنده و بدون بررسی اثر اجرا شوند.

هر درخواست تغییر باید حداقل شامل این موارد باشد:

شرح تغییر

دلیل درخواست

ارزش تجاری

بخش‌های تحت‌تأثیر

هزینه تقریبی

اثر بر زمان تحویل

اثر بر تست و امنیت

اولویت

تأیید مسئول کارفرما

نسخه‌ای که تغییر در آن انجام می‌شود

پرداخت کامل در ابتدای پروژه، قدرت کنترل کارفرما را کاهش می‌دهد. از طرف دیگر، نگه داشتن بخش بسیار بزرگی از مبلغ تا انتهای پروژه نیز می‌تواند برای پیمانکار نامتعادل باشد.

پرداخت بهتر است به خروجی‌های قابل‌بررسی متصل شود:

تکمیل نیازسنجی و محدوده

تأیید نمونه اولیه

تحویل نسخه اول

تکمیل ماژول‌های اصلی

تست پذیرش

استقرار

تحویل مستندات و آموزش

پایان دوره رفع اشکال

ملاک پرداخت نباید فقط گذشت زمان باشد. هر مرحله باید خروجی مشخص و شرایط تأیید داشته باشد.

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

اصلاح یک صفحه در Prototype بسیار کم‌هزینه‌تر از تغییر همان صفحه پس از اتصال به پایگاه داده، قوانین و گزارش‌هاست.

نمونه اولیه باید برای سناریوهای واقعی آزمایش شود:

ثبت یک مشتری

ایجاد سفارش

تأیید درخواست

اصلاح اطلاعات

جست‌وجوی سوابق

مشاهده گزارش

انجام کار با موبایل

رسیدگی به یک حالت استثنا

هدف Prototype فقط تأیید رنگ و ظاهر نیست. باید مشخص کند کاربر چگونه به نتیجه می‌رسد.

تیم فنی باید نرم‌افزار را تست کند، اما کارفرما و کاربران نیز باید سناریوهای کسب‌وکار را بررسی کنند.

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

تست پذیرش باید موارد زیر را پوشش دهد:

سناریوهای اصلی

شرایط استثنا

سطح دسترسی‌ها

محاسبات

گزارش‌ها

ورود و خروج اطلاعات

خطاهای کاربری

عملکرد با داده واقعی

نسخه موبایل و مرورگرها

اتصال به سامانه‌های دیگر

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

امنیت یک قابلیت جانبی نیست که پس از تکمیل نرم‌افزار اضافه شود.

از ابتدا باید مشخص شود:

چه اطلاعات حساسی ذخیره می‌شوند؟

هر نقش به چه داده‌ای دسترسی دارد؟

ورود کاربران چگونه محافظت می‌شود؟

سابقه تغییرات چگونه ثبت می‌شود؟

نسخه پشتیبان با چه فاصله‌ای تهیه می‌شود؟

بازیابی اطلاعات چگونه آزمایش می‌شود؟

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

کتابخانه‌ها چگونه به‌روزرسانی می‌شوند؟

رخداد امنیتی چگونه گزارش می‌شود؟

داده کاربر چگونه حذف یا منتقل می‌شود؟

NIST توصیه می‌کند فعالیت‌های توسعه امن در تمام چرخه توسعه نرم‌افزار ادغام شوند. OWASP ASVS نیز مجموعه‌ای از نیازمندی‌ها و معیارهای قابل‌تست برای کنترل‌های امنیتی برنامه‌های وب ارائه می‌دهد.

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

پیش از قرارداد یا تحویل درباره این موارد تصمیم بگیرید:

مدت گارانتی رفع اشکال

تعریف دقیق خطا

ساعات و کانال پشتیبانی

زمان پاسخ و زمان رفع مشکل

هزینه پشتیبانی پس از گارانتی

به‌روزرسانی امنیتی

مانیتورینگ سرور و سرویس‌ها

تهیه نسخه پشتیبان

آموزش کاربران جدید

توسعه قابلیت‌های بعدی

تمدید سرویس‌های جانبی

روش خروج و انتقال به تیم دیگر

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

تحویل نرم‌افزار فقط دریافت یک آدرس و نام کاربری نیست.

بسته به پروژه، اقلام تحویلی می‌توانند شامل این موارد باشند:

سورس‌کد و تاریخچه نسخه‌ها

راهنمای نصب و استقرار

معماری کلی سیستم

مدل پایگاه داده

مستند API

فهرست سرویس‌های ثالث

اطلاعات مجوزها

حساب‌ها و سطح دسترسی‌ها

تنظیمات محیط اجرا

راهنمای نسخه پشتیبان و بازیابی

راهنمای کاربری

راهنمای مدیر سیستم

سناریوهای تست

فهرست خطاهای شناخته‌شده

برنامه انتشار نسخه‌ها

اطلاعات تماس پشتیبانی

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

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

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

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

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

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