قرارداد طراحی و توسعه نرم‌افزار؛ بندهای ضروری، ریسک‌ها و نمونه ساختار

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

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

پاسخ سریع: قرارداد نرم‌افزار حداقل چه چیزهایی باید داشته باشد؟

پیش از امضا مطمئن شوید این موضوعات تعیین‌تکلیف شده‌اند:

1. مشخصات و اختیار امضای طرفین
2. موضوع، هدف و خروجی‌های دقیق پروژه
3. محدودهٔ کار و موارد خارج از محدوده
4. مراحل، نقاط عطف و زمان‌بندی
5. مسئولیت‌ها و وابستگی‌های هر دو طرف
6. مبلغ، مالیات، هزینهٔ ثالث و برنامهٔ پرداخت
7. فرایند درخواست و قیمت‌گذاری تغییرات
8. معیار پذیرش، تست و مهلت اعلام ایراد
9. تفکیک باگ، تغییر و قابلیت جدید
10. مالکیت سورس کد، مستندات و اجزای قبلی
11. مجوز کتابخانه‌ها، سرویس‌ها و نرم‌افزارهای ثالث
12. محرمانگی، امنیت، دادهٔ شخصی و دسترسی‌ها
13. استقرار، آموزش، گارانتی رفع نقص و پشتیبانی
14. ضمانت اجرا، تأخیر و محدودیت مسئولیت
15. تعلیق، فسخ، خاتمه و تحویل خروج
16. روش مکاتبه، مدیریت نسخهٔ اسناد و حل اختلاف

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

قرارداد توسعهٔ نرم‌افزار چیست؟

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

در حقوق ایران، قراردادهای خصوصی در صورتی که مخالف صریح قانون نباشند می‌توانند بر مبنای مادهٔ ۱۰ قانون مدنی تنظیم شوند و قرارداد قانونی طبق مادهٔ ۲۱۹ برای طرفین لازم‌الاتباع است. اما نتیجهٔ حقوقی هر بند به کل قرارداد و شرایط واقعی رابطه بستگی دارد؛ صرف نوشتن عنوان «پیمانکاری» یا «قرارداد توسعه» ماهیت تمام تعهدات را قطعی نمی‌کند.

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

چرا دانلود یک نمونه قرارداد و جایگزینی نام‌ها خطرناک است؟

نمونه قرارداد می‌تواند فهرست موضوعات را یادآوری کند، اما مدل پروژهٔ شما را نمی‌شناسد. قرارداد ساخت یک MVP سه‌ماهه با قرارداد توسعهٔ سامانهٔ مالی، محصول SaaS، اپلیکیشن متصل به سخت‌افزار یا نگهداری یک کد قدیمی یکسان نیست. ریسک‌های نمونه‌های عمومی معمولاً این‌ها هستند:

• محدودهٔ پروژه در چند خط کلی نوشته شده است
• همهٔ نیازها «طبق نظر کارفرما» فرض شده‌اند
• تحویل با ارسال فایل یا نمایش نرم‌افزار یکی دانسته شده است
• مالکیت سورس کد بدون تفکیک اجزای قبلی و ثالث نوشته شده است
• تغییر نیازها فرایند و اثر زمانی/مالی ندارد
• پشتیبانی، گارانتی و توسعهٔ جدید با هم مخلوط شده‌اند
• مسئولیت تأخیرهای ناشی از کارفرما یا سرویس ثالث روشن نیست
• در زمان خاتمه، تکلیف مخزن کد، کلیدها، حساب‌های ابری و مستندات مشخص نیست

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

مدل پیشنهادی انارچین: قرارداد + پنج پیوست اجرایی

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

موضوع قرارداد: نتیجه را بنویسید، نه فقط نام فناوری را

عبارت «طراحی یک اپلیکیشن با React و Node.js» موضوع مناسبی نیست؛ فناوری ابزار است، نه تعریف خروجی. موضوع باید نوع خدمت، محصول موردانتظار، کاربران، بسترها و پیوست مرجع را مشخص کند:

موضوع قرارداد عبارت است از تحلیل، طراحی، توسعه، تست و استقرار نسخهٔ نخست سامانهٔ [نام] برای [گروه کاربری]، شامل خروجی‌های مندرج در پیوست شرح خدمات نسخهٔ [شماره/تاریخ] و طبق معیارهای پذیرش پیوست [شماره].

محدوده و «خارج از محدوده» را کنار هم بنویسید

فهرست قابلیت‌ها به‌تنهایی کافی نیست. برای هر قابلیت مهم، نقش کاربر، سناریو، دادهٔ ورودی، خروجی، محدودیت و وابستگی را مشخص کنید؛ و هم‌زمان بخش «خارج از محدوده» را بنویسید (مثل تولید محتوا، خرید دامنه، طراحی هویت بصری، اپ iOS یا پشتیبانی ۲۴ ساعته).

روش قیمت‌گذاری را با میزان قطعیت پروژه هماهنگ کنید

قیمت ثابت برای پروژه‌ای که هنوز نیازهایش روشن نیست ریسک را حذف نمی‌کند، آن را به قیمت بالاتر، بندهای محدودکننده یا اختلاف تبدیل می‌کند. در مقابل، T&M بدون سقف، اولویت و شفافیت زمان هم می‌تواند هزینه را از کنترل خارج کند. برای برآورد، راهنمای هزینهٔ ساخت نرم‌افزار سفارشی را ببینید.

خروجی‌ها، نقاط عطف و معیار پذیرش

یک تاریخ پایان به‌تنهایی برنامه نیست. زمان‌بندی را به نقاط عطف قابل‌سنجش تقسیم کنید (پایان Discovery، تأیید UI/UX، نسخهٔ قابل تست فاز اول، تکمیل اتصال‌های ثالث، UAT، استقرار Production، تحویل مستندات). برای هر نقطهٔ عطف مشخص کنید خروجی چیست، چه کسی بررسی می‌کند، چند روز مهلت بازخورد دارد و آیا سکوت به معنای تأیید است یا خیر.

پذیرش باید تا حد ممکن قابل آزمون باشد. مثال ضعیف: «داشبورد سریع و کاربرپسند باشد.» مثال بهتر:

کاربر دارای نقش مدیر بتواند گزارش فروش بازهٔ انتخابی را با فیلتر شهر مشاهده و فایل XLSX دریافت کند، اعداد خروجی با دادهٔ مرجع در مجموعهٔ تست تطبیق داشته باشند و خطای Severity 1 و 2 باز باقی نمانده باشد.

قرارداد باید فرایند رد را هم مشخص کند: اعلام «مورد تأیید نیست» کافی نیست؛ ایراد باید به معیار پذیرش، سناریوی بازتولید و شدت خطا متصل شود.

باگ، تغییر و قابلیت جدید را تفکیک کنید

یکی از پرتکرارترین اختلاف‌ها این است که کارفرما درخواست را «رفع اشکال» و تیم توسعه آن را «توسعهٔ جدید» می‌داند. تعریف صریح لازم است:

فرایند Change Request

تغییر در پروژهٔ نرم‌افزاری طبیعی است؛ قرارداد حرفه‌ای آن را ممنوع نمی‌کند، بلکه قابل قیمت‌گذاری و ردیابی می‌کند:

تا پیش از تأیید، درخواست نباید تعهد اجرایی ایجاد کند. حذف یک قابلیت هم لزوماً به‌اندازهٔ هزینهٔ اولیه‌اش از قرارداد کم نمی‌کند، چون ممکن است بخشی از تحلیل یا زیرساخت آن انجام شده باشد.

مالکیت سورس کد؛ دقیقاً چه چیزی منتقل می‌شود؟

عبارت «سورس کد متعلق به کارفرماست» چند سؤال را بی‌پاسخ می‌گذارد: مالکیت از زمان ایجاد منتقل می‌شود یا پس از تسویه؟ انتقال انحصاری است یا مجوز استفاده؟ کدهای عمومی و ابزارهای قبلی مجری چه می‌شوند؟ دارایی‌ها را به چهار دسته تفکیک کنید:

تحویل سورس کد هم فقط ارسال یک فایل ZIP نیست؛ تحویل قابل‌استفاده شامل Repository با تاریخچه، نسخهٔ Release و Tag، راهنمای Build و Deployment، فایل نمونهٔ تنظیمات (بدون افشای Secret)، ساختار دیتابیس و Migrationها، مستند API، فهرست وابستگی‌ها و مجوزها، دسترسی حساب‌ها و Runbook پشتیبان‌گیری و بازیابی است.

محرمانگی، امنیت و داده

NDA یک جملهٔ کلی دربارهٔ «عدم افشا» نیست. باید تعریف اطلاعات محرمانه، موارد استثنا، افراد مجاز، مدت تعهد، روش بازگرداندن/حذف اطلاعات و پیامد نقض را مشخص کند. برای امنیت و داده حداقل دربارهٔ این موارد تصمیم بگیرید: چه داده‌ای در اختیار تیم توسعه قرار می‌گیرد، استفاده از دادهٔ واقعی در محیط تست مجاز است یا نه، دسترسی Production چگونه اعطا و ثبت می‌شود، Secretها کجا نگهداری می‌شوند، رخداد امنیتی به چه کسی گزارش می‌شود، و پس از خاتمه دسترسی‌ها چگونه حذف می‌شوند.

حساب‌ها و زیرساخت باید از روز اول تعیین‌تکلیف شوند

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

تست، کیفیت و شدت خطا

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

• S1 بحرانی: توقف خدمت اصلی، از دست‌رفتن داده یا رخداد امنیتی جدی بدون راه‌حل موقت
• S2 شدید: اختلال قابلیت مهم با اثر گسترده و راه‌حل موقت دشوار
• S3 متوسط: نقص محدود با Workaround قابل قبول
• S4 جزئی: ایراد ظاهری یا کم‌اثر

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

گارانتی، پشتیبانی و SLA یکی نیستند

اگر این چهار مورد تفکیک نشوند، کارفرما هر درخواست جدید را در دورهٔ پشتیبانی رایگان می‌داند و مجری هر ایراد را توسعهٔ جدید. در پیوست SLA، ساعات و کانال خدمت، سطوح شدت، زمان پاسخ هر سطح، Availability در صورت تعهد، پنجرهٔ نگهداری، موارد خارج از SLA و روش Escalation را مشخص کنید.

تأخیر، خسارت و محدودیت مسئولیت

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

تعلیق، فسخ، خاتمه و تحویل خروج

پروژه ممکن است به‌دلیل تغییر استراتژی، نبود بودجه، نقض تعهد یا توافق طرفین متوقف شود. قرارداد باید بین «تعلیق»، «فسخ به‌علت نقض» و «خاتمه با اعلام قبلی» تفکیک کند و سناریوی خروج را از قبل بنویسد: اخطار و مهلت رفع نقض، روش اندازه‌گیری و تسویهٔ کار انجام‌شده، تکلیف خروجی ناقص، مرحلهٔ انتقال حقوق و سورس کد، حذف/بازگرداندن دادهٔ محرمانه، انتقال دسترسی‌ها و کلیدها، مدت و هزینهٔ همکاری Transition و تعهدهای باقی‌مانده پس از خاتمه.

چک‌لیست ۳۰ سؤالی پیش از امضا

اگر پاسخ چند سؤال کلیدی «بعداً مشخص می‌کنیم» است، آن موارد باید یا پیش از امضا حل شوند یا صریحاً به‌عنوان خروجی فاز Discovery تعریف شوند.

• مسئله و نتیجهٔ کسب‌وکاری پروژه روشن است
• کاربران و نقش‌های اصلی مشخص‌اند
• قابلیت‌ها سناریو و معیار پذیرش دارند
• خارج از محدوده نوشته شده است
• فرض‌ها و وابستگی‌های ثالث ثبت شده‌اند
• برنامه به نقاط عطف تقسیم شده است
• مسئول هر ورودی و تأیید مشخص است
• اثر تأخیر هر طرف تعریف شده است
• محیط و روش تحویل روشن است
• مهلت و فرایند پذیرش مشخص است
• مدل قیمت‌گذاری با قطعیت دامنه سازگار است
• اقساط به خروجی قابل سنجش متصل‌اند
• هزینه‌های Cloud، API و لایسنس تعیین‌تکلیف شده‌اند
• فرایند Change Request وجود دارد
• فقط افراد مجاز تغییر مالی/زمانی را تأیید می‌کنند
• دارایی اختصاصی، قبلی و ثالث تفکیک شده‌اند
• زمان و شرط انتقال حقوق مادی روشن است
• تحویل Repository، تاریخچهٔ کد و مستندات مشخص است
• مجوز کتابخانه‌ها و سرویس‌های ثالث ثبت می‌شود
• مالک حساب‌های Cloud، دامنه و مارکت مشخص است
• تعریف باگ و قابلیت جدید نوشته شده است
• شدت خطا و آستانهٔ پذیرش مشخص است
• گارانتی، پشتیبانی، نگهداری و توسعه تفکیک شده‌اند
• SLA متناسب با اهمیت سرویس است
• Backup، Recovery و مانیتورینگ مسئول مشخص دارند
• محرمانگی و دسترسی به دادهٔ عملیاتی تعریف شده است
• رخداد امنیتی فرایند گزارش دارد
• تعلیق، فسخ و خاتمه از هم جدا شده‌اند
• Exit Plan شامل کد، داده، دسترسی و انتقال دانش است
• قرارداد توسط وکیل متناسب با پروژه بررسی شده است

خط قرمزها

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

جمع‌بندی: قرارداد خوب، اختلاف کمی را قابل تصمیم می‌کند

در پروژهٔ نرم‌افزاری، تغییر اجتناب‌ناپذیر است. هدف قرارداد این نیست که وانمود کند همه‌چیز از روز اول معلوم است؛ هدف این است که برای تصمیم‌های بعدی قاعده بسازد.

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

منابع

• قانون حمایت از حقوق پدیدآورندگان نرم‌افزارهای رایانه‌ای
• قانون تجارت الکترونیکی
• متن قانون مدنی ایران (PDF)
• WIPO — Copyright Protection of Computer Software
• OWASP — Software Assurance Maturity Model
• Open Source Initiative — Licenses