وقتی قرار است یک نرمافزار اختصاصی برای یک کسب‌وکار ساخته شود، توافق شفاهی درباره «چه چیزی بسازیم» و «چقدر هزینه دارد» معمولاً کافی نیست. در پروژه‌های نرم‌افزاری، بسیاری از اختلاف‌ها از جایی شروع می‌شوند که یک طرف تصور میکند قابلیتی جزو پروژه بوده و طرف دیگر آن را خارج از تعهدات می‌داند. قرارداد خوب قرار نیست فقط مبلغ و تاریخ تحویل را ثبت کند؛ باید مشخص کند دقیقاً چه چیزی ساخته میشود، چگونه تحویل و پذیرش میشود، تغییرات چطور مدیریت می‌شوند و بعد از تحویل چه تعهداتی باقی می‌ماند.
نکته مهم: این مقاله یک چک‌لیست قراردادی و فنی است، نه جایگزین بررسی حقوقی قرارداد. برای پروژه‌های بزرگ، قرارداد را متناسب با وضعیت مالکیت، نوع طرفین و ریسک‌های پروژه با مشاور حقوقی بررسی کنید.
قرارداد طراحی نرمافزار چیست؟
قرارداد طراحی و توسعه نرمافزار توافقی میان کارفرما و مجری است که در آن موضوع پروژه، محدوده خدمات، خروجی‌ها، زمانبندی، مبلغ، شیوه پرداخت، مسئولیت‌های طرفین و شرایط تحویل مشخص میشود. در پروژه‌های اختصاصی، هرچه وابستگی نرمافزار به فرایندهای کسب‌وکار بیشتر باشد، اهمیت تعریف دقیق این موارد هم بیشتر میشود.
پیش از امضای قرارداد، بهتر است یک سند نیازمندی یا شرح خدمات هم تهیه شود. این سند میتواند جزئیات قابلیت‌ها، نقش‌های کاربری، خروجی‌ها، APIها، گزارش‌ها و محدودیت‌های فنی را مشخص کند تا متن قرارداد مجبور نباشد همه جزئیات را در چند صفحه فشرده کند.
۱. مشخصات دقیق طرفین قرارداد
نام و مشخصات قانونی کارفرما و مجری، نمایندگان مجاز، نشانی و اطلاعات تماس باید روشن باشد. اگر یکی از طرفین شرکت است، مشخصات ثبتی و شخصی که حق امضا دارد نیز باید مطابق اسناد شرکت درج شود. همچنین بهتر است مشخص شود چه کسی از طرف کارفرما مسئول تأیید نیازمندیها و تحویل‌گیری پروژه است.
۲. موضوع قرارداد و دامنه پروژه
عبارت‌هایی مثل «طراحی یک نرمافزار کامل» یا «ساخت یک سامانه حرفه‌ای» برای قرارداد کافی نیستند. باید خروجی قابل تحویل تعریف شود. برای مثال مشخص کنید نرمافزار شامل چه ماژول‌هایی است، چه نقش‌هایی دارد، چه فرایندهایی را پوشش می‌دهد، چه گزارش‌هایی ارائه میکند و چه یکپارچه‌سازی‌هایی در محدوده پروژه قرار دارند.
در صورت وجود نسخه اولیه یا MVP، آن را از قابلیت‌هایی که برای فازهای بعدی در نظر گرفته شده‌اند جدا کنید. همین تفکیک ساده میتواند از بسیاری از اختلاف‌ها درباره «قابلیت‌های وعده‌داده‌شده» جلوگیری کند.
۳. نیازمندی‌های فنی و معیار پذیرش
قرارداد بهتر است فقط فهرست قابلیت‌ها را نیاورد؛ معیار سنجش خروجی را هم مشخص کند. برای هر بخش مهم می‌توان معیار پذیرش تعریف کرد: چه ورودی‌ای دریافت میشود، چه نتیجه‌ای باید تولید شود، چه خطاهایی باید کنترل شوند و چه شرایطی باعث تأیید یا رد آن قابلیت میشود.
اگر نرمافزار API، پنل مدیریت، پرداخت آنلاین، پیامک، سرویس حسابداری یا سرویس دیگری دارد، وابستگی‌های خارجی را نیز مشخص کنید. برای سرویس‌های بیرونی بهتر است رفتار سیستم در زمان قطعی یا خطای سرویس هم از قبل تعریف شود.
۴. زمانبندی، مراحل اجرا و نقاط تحویل
به‌جای یک تاریخ کلی برای «تحویل نرمافزار»، بهتر است پروژه به چند مرحله تقسیم شود. برای هر مرحله می‌توان خروجی، زمان تقریبی و شرط تأیید تعریف کرد. در پروژه‌های پیچیده، این مدل از تعیین یک موعد نهایی بدون توجه به وابستگی‌های بین مراحل قابل اتکاتر است.
همچنین مشخص کنید تأخیر ناشی از چه عواملی خارج از کنترل مجری محسوب میشود؛ برای مثال تأخیر در ارائه اطلاعات، دسترسی‌ها، محتوای مورد نیاز یا سرویس‌های شخص ثالث. در صورت توافق، شرایط جبران تأخیر و سقف مسئولیت نیز باید شفاف باشد.
۵. مبلغ قرارداد و شیوه پرداخت
مبلغ کل، مالیات و هزینه‌های جانبی در صورت وجود، زمانبندی پرداخت و ارتباط هر پرداخت با یک milestone باید مشخص شود. اگر هزینه سرویس‌های خارجی، سرور، پیامک، دامنه، لایسنس یا ابزارهای تجاری بر عهده کارفرماست، این موارد را جداگانه بنویسید.
برای پروژه‌هایی که نیازمندی‌هایشان ممکن است در طول توسعه تغییر کند، قراردادهای زمان‌محور یا مدل‌های مرحله‌ای می‌توانند انعطاف بیشتری نسبت به قیمت ثابت داشته باشند. در قرارداد قیمت ثابت، تعریف دامنه پروژه و فرایند مدیریت Change Request اهمیت بیشتری پیدا میکند.
۶. مالکیت کد، داده و حقوق استفاده
این بخش را مبهم نگذارید. قرارداد باید مشخص کند حقوق مربوط به کد اختصاصی پروژه، طراحی UI/UX، مستندات، داده‌های کارفرما و خروجی‌های تولیدشده پس از تسویه چگونه خواهد بود. اگر مجری از کتابخانه‌ها، فریم‌ورک‌ها یا اجزای متن‌باز استفاده میکند، مجوزهای آن‌ها را نیز باید در نظر گرفت؛ «تحویل سورسکد» الزاماً به معنای انتقال حقوق هر جزء شخص ثالث نیست.
همچنین مشخص کنید کارفرما دقیقاً چه چیزهایی را در پایان پروژه دریافت میکند: سورسکد، فایل‌های Build، مستندات استقرار، تنظیمات محیط، فایل‌های طراحی، مستندات API و اطلاعات لازم برای نگهداری. این تفکیک، موضوع مالکیت و موضوع تحویل فنی را از هم جدا میکند.
۷. محرمانگی و امنیت اطلاعات
در پروژه نرم‌افزاری ممکن است مجری به اطلاعات مشتریان، داده‌های مالی، اطلاعات کارکنان، کلیدهای API یا زیرساخت دسترسی پیدا کند. قرارداد باید حدود استفاده از این اطلاعات، محرمانگی، دسترسی اشخاص ثالث و نحوه بازگرداندن یا حذف اطلاعات پس از پایان همکاری را مشخص کند.
برای پروژه‌های حساس، مسئولیت مدیریت Secretها، دسترسی به سرور، Backup و ثبت رویدادهای امنیتی نیز بهتر است جداگانه تعیین شود. اطلاعات محرمانه نباید صرفاً در یک ایمیل یا پیام‌رسان ردوبدل شود و سپس انتظار داشت قرارداد همه ریسک‌های عملیاتی را حل کند.
۸. فرایند تغییرات در حین پروژه
در بسیاری از پروژه‌ها نیازمندیها بعد از شروع توسعه تغییر می‌کنند. قرارداد باید یک فرایند روشن برای Change Request داشته باشد. هر درخواست جدید میتواند از نظر اثر روی زمان، هزینه و معماری بررسی و سپس تأیید یا رد شود.
برای مثال، اضافه‌شدن یک ماژول جدید نباید به‌صورت خودکار بخشی از مبلغ اولیه تلقی شود. بهتر است درخواست تغییر ثبت شود، اثر آن بر پروژه اعلام شود و پس از تأیید طرفین وارد برنامه توسعه شود.
۹. تست، تحویل و پذیرش نرمافزار
«تحویل شد» و «مورد قبول است» دو مفهوم متفاوت‌اند. قرارداد باید مشخص کند چه زمانی نرمافزار برای تست در اختیار کارفرما قرار میگیرد، مهلت بررسی چقدر است، ایرادها چگونه ثبت می‌شوند و چه زمانی یک مرحله پذیرفته‌شده محسوب میشود.
بهتر است بین Bug، درخواست تغییر و قابلیت جدید تفاوت گذاشته شود. رفع یک نقص نسبت به نیازمندی تأییدشده با افزودن قابلیت جدید یکسان نیست و نباید هر دو در یک دسته قرار بگیرند.
۱۰. گارانتی و پشتیبانی پس از تحویل
پشتیبانی را با رفع باگ یکی ندانید. قرارداد باید مدت گارانتی فنی، محدوده رفع نقص، کانال ثبت درخواست، زمان پاسخگویی و در صورت توافق، زمان رفع مشکل را مشخص کند. اگر پشتیبانی ماهانه یا سالانه جداگانه خریداری میشود، خدمات داخل و خارج از آن بسته نیز باید روشن باشد.
برای سامانه‌های عملیاتی، تعریف سطح خدمت یا SLA میتواند مفید باشد. در این صورت سطح‌های مختلف خطا، اولویت پاسخ و ساعات پشتیبانی را دقیق‌تر تعریف کنید.
۱۱. زیرساخت، استقرار و تحویل فنی
مشخص کنید مسئولیت خرید یا مدیریت سرور، دامنه، SSL، Database، Backup و سرویس‌های شخص ثالث با چه کسی است. اگر استقرار جزو پروژه است، محیط‌های Development، Staging و Production و مسئولیت Deploy اولیه را نیز مشخص کنید.
یکی از مواردی که گاهی فراموش میشود، تحویل دسترسی‌هاست. دسترسی‌های لازم برای نگهداری نرمافزار باید در پایان کار به شکل امن و قابل مدیریت تحویل شوند و بهتر است مالکیت حساب‌های زیرساختی از ابتدا مشخص باشد.
۱۲. فسخ قرارداد و حل اختلاف
شرایط فسخ، موارد نقض اساسی تعهدات، نحوه تسویه کار انجام‌شده و تکلیف فایل‌ها و اطلاعات پس از فسخ باید روشن باشد. همچنین مرجع یا سازوکار حل اختلاف را مطابق توافق طرفین و ملاحظات حقوقی پروژه تعیین کنید.
چک‌لیست کوتاه قبل از امضای قرارداد
| موضوع | سؤال کنترل |
|---|---|
| دامنه پروژه | آیا دقیقاً مشخص است چه قابلیت‌هایی داخل پروژه هستند و چه مواردی خارج از آن؟ |
| زمانبندی | آیا مراحل، نقاط تحویل و وابستگی‌های کارفرما مشخص شده‌اند؟ |
| هزینه | آیا مبلغ، اقساط و هزینه‌های جانبی روشن است؟ |
| مالکیت | آیا وضعیت سورسکد، طراحی، داده و اجزای شخص ثالث مشخص است؟ |
| تغییرات | آیا برای درخواست‌های جدید فرایند مشخصی وجود دارد؟ |
| پذیرش | آیا معیار تست و مهلت اعلام ایراد مشخص شده است؟ |
| پشتیبانی | آیا گارانتی، SLA و محدوده پشتیبانی تفکیک شده‌اند؟ |
| امنیت | آیا محرمانگی، دسترسی‌ها و اطلاعات حساس تعیین تکلیف شده‌اند؟ |
اگر پروژه شما قرار است به هسته فرایند کسب‌وکار تبدیل شود، قرارداد را فقط بر اساس قیمت و زمان تحویل نبندید. دامنه پروژه، معیار پذیرش، مالکیت و مسئولیت نگهداری در طول عمر نرمافزار به همان اندازه مهم‌اند.
اگر نرمافزار تحت وب است، چه چیزهایی را اضافه کنیم؟
در نرم‌افزارهای تحت وب، موضوعاتی مثل API، دسترسی کاربران، زیرساخت، Backup، Monitoring، امنیت و وابستگی به سرویس‌های بیرونی اهمیت بیشتری پیدا می‌کنند. اگر هنوز در مرحله انتخاب نوع راهکار هستید، مقاله نرمافزار تحت وب چیست و چه مزایایی برای کسب‌وکار دارد؟ میتواند برای مقایسه Web App با سایر مدل‌ها و بررسی مزایا و محدودیت‌های آن مفید باشد.
جمع‌بندی
یک قرارداد خوب برای طراحی نرمافزار باید تصویر مشترکی از پروژه بسازد. مشخصات طرفین، دامنه کار، نیازمندیها، معیار پذیرش، زمانبندی، هزینه، مالکیت، محرمانگی، تغییرات، تست، پشتیبانی، زیرساخت و فسخ باید به اندازه‌ای روشن باشند که هر دو طرف بتوانند بعداً به متن قرارداد مراجعه کنند و بدانند تعهدشان دقیقاً چیست.
هرچه پروژه پیچیده‌تر و ارزش کسب‌وکاری آن بیشتر باشد، سرمایه‌گذاری روی تعریف دقیق قرارداد و مستندات فنی قبل از شروع توسعه منطقی‌تر است. در پروژه‌های بزرگ، بررسی حقوقی متن قرارداد نیز باید بخشی از آماده‌سازی پروژه باشد.
منابع و مطالعه بیشتر
- قرارداد طراحی و توسعه نرم افزار، دکتر پیمان محمدپور؛ برای مرور ساختار، دامنه کار، پرداخت، مالکیت، تست، تحویل و پشتیبانی.
- نرمافزار تحت وب چیست و چه مزایایی برای کسب‌وکار دارد؟؛ امین فرانگر هوشمند.
برای پروژه‌های نرم‌افزاری اختصاصی، قبل از شروع توسعه درباره دامنه پروژه، خروجی‌ها و مسیر اجرا تصمیم بگیرید.
