قرارداد توسعه نرم‌افزار: ۱۲ بندی که جلوی اختلاف را می‌گیرد
راهنمای بند به بند قرارداد برنامه‌نویسی و پروژه نرم‌افزاری از نگاه یک مهندس؛ از شروع کار و پذیرش تحویل تا پرداخت مرحله‌ای، SLA پشتیبانی، وجه التزام و مالکیت کد.
- قرارداد توسعه نرم‌افزار
- نمونه قرارداد برنامه‌نویسی
- قرارداد پروژه نرم‌افزاری
- SLA پشتیبانی
بیشتر قراردادهای نرم‌افزاری از روی یک قالب عمومی نوشته می‌شوند: موضوع، مبلغ، مدت و چند جمله درباره محرمانگی. این قالب تا روزی که همه چیز خوب پیش می‌رود کافی به نظر می‌رسد. مشکل از جایی شروع می‌شود که کارفرما می‌گوید «هنوز پروداکشن نشده، پس قسط را نمی‌دهم» و مجری می‌گوید «مشکل از سرویس بیرونی است، به من ربطی ندارد». اگر قرارداد برای این لحظه‌ها جواب نداشته باشد، هر دو طرف حق دارند و هیچ‌کدام راهی برای اثبات آن ندارند.
این راهنما را از روی ساختار قراردادی واقعی برای یک پروژه مالی نوشته‌ام و نام طرف‌ها و مبالغ را حذف کرده‌ام. نگاه من نگاه مهندس نرم‌افزار است، نه وکیل. پس از این متن برای فهمیدن اینکه چه چیزهایی باید روشن شود استفاده کنید و متن نهایی را به مشاور حقوقی نشان دهید.
۱. تعهد دقیقاً به چه چیزی است؟
جمله «ساخت نرم‌افزار» برای موضوع قرارداد کافی نیست. موضوع باید به یک فایل نیازمندی با نسخه و تاریخ مشخص ارجاع بدهد و بگوید کار شامل چه چیزهایی است: پیاده‌سازی، آزمون، تحویل کد، مستندات، انتقال دانش و پشتیبانی.
نکته مهم‌تر این است که بنویسید مجری چه چیزی را تضمین نمی‌کند. هیچ مهندسی نمی‌تواند نبودن مطلق باگ یا در دسترس بودن همیشگی یک سرویس بیرونی را تضمین کند. تعهد واقعی این است: نرم‌افزار با نیازمندی‌های مصوب منطبق باشد و اشکالات مربوط به کار مجری رفع شوند.
۲. زمان شروع، تاریخ امضا نیست
اگر مجری برای شروع به مستندات، دسترسی یا محیط آزمایشی نیاز دارد، شمارش مهلت از روز امضا منصفانه نیست. زمان شروع را این‌طور تعریف کنید: لحظه‌ای که ورودی‌های فهرست‌شده تحویل شده و پیش‌پرداخت انجام شده باشد. این زمان را با تاریخ و ساعت در یک صورت‌جلسه یا پیام قابل استناد ثبت کنید.
در مقابل، مجری هم نباید تا روز تحویل سکوت کند. یک مهلت کوتاه مثل ۲۴ ساعت برای اعلام نواقص ورودی‌ها بگذارید. تأخیر کارفرما هم فقط به اندازه اثر واقعی و مستندش مهلت را جابه‌جا می‌کند، نه بیشتر.
۳. تحویل یعنی چه چیزهایی؟
«کد را تحویل دادم» معنای مشخصی ندارد. بسته تحویل را فهرست کنید:
- کد منبع کامل در مخزن تحت کنترل کارفرما، با شماره نسخه و شناسه مشخص
- فایل‌های ساخت و اجرا و تنظیمات نمونه بدون اطلاعات محرمانه
- مستندات نصب، معماری، رابط‌ها و روش تشخیص خطا
- نتایج آزمون‌ها و فهرست اشکالات و محدودیت‌های شناخته‌شده
- یک جلسه انتقال دانش برای تیم فنی کارفرما
ممنوع بودن دسترسی پنهان، توقف عمدی نرم‌افزار و وابستگی اعلام‌نشده به حساب شخصی را هم صریح بنویسید. این بند از هر دو طرف محافظت می‌کند.
۴. پذیرش؛ پرهزینه‌ترین جای خالی قراردادها
بیشتر اختلاف‌ها همین‌جا اتفاق می‌افتد، چون پرداخت به پذیرش وابسته است و پذیرش تعریف نشده. چهار چیز را مشخص کنید:
- مهلت بررسی: مثلاً سه روز کاری پس از تحویل کامل.
- رد مستند: رد کردن باید بگوید کدام نیازمندی محقق نشده و با چه آزمونی. جمله‌هایی مثل «مورد تأیید نیست» رد مستند حساب نمی‌شوند.
- پذیرش در صورت سکوت: اگر پس از مهلت و یک اخطار، پاسخی نیامد، تحویل پذیرفته‌شده محسوب شود.
- معیار پذیرش: صفر بودن باگ شرط پذیرش نیست. نبود یک قابلیت اساسی باید اصلاح شود، ولی اشکالات کوچک‌تر ثبت می‌شوند و در دوره پشتیبانی رفع می‌شوند.
اگر آزمون واقعی ممکن نیست، مثلاً چون محیط آزمایشی وجود ندارد، آزمون جایگزین را از قبل مشخص کنید. انجام نشدن آزمون واقعی هم باید صریح ثبت شود، تا نتیجه شبیه‌سازی به جای تراکنش واقعی معرفی نشود.
۵. پرداخت را به چیزی وصل کنید که دست مجری است
یک تقسیم‌بندی رایج و منطقی این است:
| مرحله | سهم نمونه | شرط پرداخت |
|---|---|---|
| پیش‌پرداخت | ۲۰ درصد | تحویل ورودی‌ها و شروع کار |
| تحویل | ۵۰ درصد | پذیرش تحویل |
| قسط نهایی | ۳۰ درصد | پایان دوره پشتیبانی، پس از کسورات مجاز |
درصدها قابل مذاکره‌اند، ولی این دو جمله را حتماً بنویسید: پرداخت به استقرار نهایی توسط تیم کارفرما یا آغاز بهره‌برداری تجاری وابسته نیست، مگر اینکه آن کار جزء تعهد مجری باشد. قسط آخر هم به «دو ماه بدون باگ» یا تمام شدن همه اختلاف‌ها وابسته نیست. بدون این جمله‌ها، تصمیم کارفرما برای عقب انداختن انتشار می‌تواند پرداخت را تا مدت نامعلومی متوقف کند.
۶. پشتیبانی را با عدد تعریف کنید
«پشتیبانی دو ماهه» به‌تنهایی قابل اجرا نیست. اولویت‌ها را بر اساس اثر واقعی تعریف کنید و برای هر کدام دو مهلت جدا بگذارید:
| اولویت | تعریف | شروع بررسی | رفع |
|---|---|---|---|
| بحرانی | توقف عملیات اصلی یا خطر امنیتی و مالی فوری | ۳۰ دقیقه | ۴ ساعت |
| بالا | اختلال جدی بدون راهکار موقت | ۲ ساعت | ۲۴ ساعت |
| متوسط | اختلال محدود با راهکار جایگزین | ۶ ساعت | ۳۶ ساعت |
| پایین | اشکال ظاهری یا متنی | ۱۲ ساعت | ۷۲ ساعت |
این عددها نمونه‌اند و برای پوشش شبانه‌روزی نوشته شده‌اند. اگر پوشش شما فقط ساعت اداری است، همین را بنویسید و قیمت را هم متناسب با آن تعیین کنید. پشتیبانی شبانه‌روزی کار جداگانه‌ای است و هزینه خودش را دارد.
کلمه‌ها را هم تعریف کنید. شروع بررسی یعنی اقدام فنی قابل اثبات، نه پاسخ خودکار. رفع یعنی اصلاح آزموده‌شده و قابل اعمال، نه غیرفعال کردن قابلیت اصلی. آغاز مهلت هم زمان ثبت گزارش در کانال رسمی است، نه زمانی که مجری آن را می‌بیند.
۷. وجه التزام باید سقف داشته باشد
اگر برای تأخیر در رفع اشکال جریمه تعیین می‌کنید، سه چیز را روشن کنید:
- مبلغ برای هر رخداد مستقل فقط یک بار حساب می‌شود، نه به تعداد گزارش یا ساعت تأخیر.
- مجموع جریمه‌ها سقف دارد، مثلاً برابر قسط نهایی.
- کارفرما پیش از کسر، فهرست رخدادها و محاسبه را اعلام می‌کند و به مجری فرصت اعتراض می‌دهد.
این را هم بنویسید که بروز باگ، حتی باگ بحرانی، به‌تنهایی به معنای مسئولیت نسبت به همه خسارت‌ها نیست. در مقابل، سقف جریمه تأخیر نباید پوششی برای تخلف‌های جدی‌تر مثل سوءاستفاده از دسترسی یا افشای اطلاعات باشد.
۸. وابستگی به سرویس بیرونی
هر پروژه‌ای که به درگاه پرداخت، بانک یا سرویس دیگری وصل است، روزی با اختلال آن روبه‌رو می‌شود. قرارداد خوب نه همه چیز را گردن مجری می‌اندازد و نه اجازه می‌دهد هر مشکلی به سرویس بیرونی نسبت داده شود:
جمله «مشکل از سرویس بیرونی است» کافی نیست. مانع، زمان شروع، اقدام لازم و شواهد باید ثبت شوند.
فقط زمانی که اثر مستقیم مانع ثابت شده باشد از مهلت رفع کم می‌شود. شروع بررسی و تشخیص اولیه معمولاً متوقف نمی‌شوند. نقص‌هایی مثل مدیریت نکردن خطاهای قابل پیش‌بینی یا جلوگیری نکردن از تراکنش تکراری هم با این بهانه از مسئولیت مجری خارج نمی‌شوند.
۹. محرمانگی، دسترسی و آزمون
رمز و کلید واقعی نباید در متن قرارداد، کد یا پیام‌های ناامن بیاید. دسترسی‌ها حداقلی باشند و پس از پایان کار قطع شوند. اگر آزمون روی محیط واقعی انجام می‌شود، مجوز کتبی، حساب‌های مجاز و سقف مبلغ را از قبل بنویسید و هزینه آن را هم بر عهده کارفرما بگذارید. استفاده از ابزارهای عمومی پردازش کد و داده را هم مشخص کنید؛ این موضوع حالا برای بیشتر تیم‌ها یک سؤال واقعی است.
۱۰. مالکیت کد و اجزای قبلی
حقوق مادی کد اختصاصی معمولاً به کارفرما می‌رسد. ولی اگر مجری از کتابخانه یا ابزاری که قبلاً ساخته استفاده می‌کند، مالکیت آن منتقل نمی‌شود و فقط مجوز استفاده داده می‌شود. پس این اجزا را در یک پیوست فهرست کنید و اگر چیزی نیست، بنویسید «فاقد مورد».
جمله دیگری هم هست که به آرامش هر دو طرف کمک می‌کند: اختلاف مالی مجوز حذف کد، بستن دسترسی‌ها یا متوقف کردن نرم‌افزار نیست. مطالبه مالی از مسیر قراردادی و قانونی پیگیری می‌شود.
۱۱. تغییر نیازمندی و پایان همکاری
افزودن قابلیت باید پیش از اجرا با شرح، مبلغ و مهلت توسط افراد مجاز تأیید شود. نماینده فنی معمولاً اختیار تغییر مبلغ یا دامنه کار را ندارد و این را هم بنویسید. اصلاح چیزی که با نیازمندی اولیه منطبق نبوده، تغییر محسوب نمی‌شود و هزینه جدا ندارد.
برای فسخ هم اخطار کتبی با مهلت رفع و روش تسویه را مشخص کنید. ارزش کار انجام‌شده، مبالغ پرداختی و کسورات حساب می‌شود، نه اینکه تمام مبلغ خودکار قابل مطالبه یا قابل استرداد باشد. مجری هم آخرین کد و مستندات را در مهلت مشخصی تحویل می‌دهد.
۱۲. مالیات، بیمه و ماهیت همکاری
بنویسید مبلغ ناخالص است یا خالص، و ارزش افزوده داخل آن است یا بیرون آن. کارفرما فقط کسوری را اعمال می‌کند که مبنای قانونی دارد و مستند آن را ارائه می‌کند. نگهداشت قانونی بیمه هم باید از جریمه قراردادی جدا ثبت شود. اگر مجری کارمند همان شرکت است، ماهیت این رابطه را حتماً با مشاور بررسی کنید، چون نوشتن عنوان «پروژه مستقل» رابطه واقعی را تغییر نمی‌دهد.
پیش از امضا، عددها را با هم جمع بزنید
یک خطای ساده ولی رایج: مبلغ به عدد و حروف یکی نیست، یا جریمه و سقف آن از مبلغ دیگری حساب شده‌اند. قرارداد معمولاً چند بار ویرایش می‌شود و عددها در جاهای مختلف یکسان تغییر نمی‌کنند. این موارد را جداگانه بررسی کنید:
- مبلغ به عدد و حروف با هم برابرند.
- جمع اقساط دقیقاً برابر مبلغ کل است.
- درصد جریمه و سقف آن با همان مبلغ کل و همان قسط هم‌خوانی دارند.
- تعداد پیوست‌هایی که در متن آمده با پیوست‌های واقعی یکی است.
- جاهای خالی شماره قرارداد، تاریخ، شبا و کانال‌های رسمی پر شده‌اند.
جمع‌بندی
قرارداد خوب قرار نیست طرف مقابل را گیر بیندازد. قرار است هر دو طرف پیش از شروع کار بدانند در لحظه‌های سخت چه اتفاقی می‌افتد. اگر فقط وقت سه کار را دارید، این سه را انجام بدهید: معیار پذیرش را بنویسید، پرداخت را از تصمیم‌های خارج از اختیار مجری جدا کنید و پشتیبانی را با عدد تعریف کنید.
برای مرور سریع‌تر، چک‌لیست قرارداد و تحویل پروژه را ببینید. پیش از قرارداد هم شرح پروژه روشن لازم دارید. اگر پروژه‌ای دارید و می‌خواهید دامنه کار و شرایط تحویل را روشن کنید، با من تماس بگیرید.