قرارداد طراحی نرم افزار اختصاصی؛ ۱۵ بند مهم قبل از امضا
قرارداد طراحی نرم افزار اختصاصی باید محدوده پروژه، زمانبندی، هزینه، مالکیت سورس کد، پشتیبانی، امنیت و شرایط تغییرات را شفاف کند. در این راهنما مهمترین بندهای قرارداد را بررسی میکنیم.
A
تیم تحریریه آرکوتکتحریریه مهندسی محصول
·۱۱ دقیقه مطالعه
قرارداد طراحی نرم افزار اختصاصی و بندهای مهم قرارداد توسعه نرم افزار
خلاصه اجرایی
قرارداد طراحی نرم افزار اختصاصی باید محدوده پروژه، زمانبندی، هزینه، مالکیت سورس کد، پشتیبانی، امنیت و شرایط تغییرات را شفاف کند. در این راهنما مهمترین بندهای قرارداد را بررسی میکنیم.
قرارداد طراحی نرم افزار اختصاصی یکی از مهمترین بخشهای شروع یک پروژه نرم افزاری است؛ زیرا حتی اگر تیم فنی قدرتمندی انتخاب کرده باشید، نبود قرارداد شفاف میتواند در ادامه باعث اختلاف درباره امکانات، زمان تحویل، هزینه، مالکیت سورس کد و پشتیبانی شود.
بسیاری از اختلافات پروژههای نرم افزاری نه به دلیل ضعف برنامهنویسی، بلکه به دلیل تعریف مبهم مسئولیتها در ابتدای پروژه ایجاد میشوند.
کارفرما تصور میکند قابلیتی جزو پروژه است، اما تیم توسعه آن را خارج از Scope میداند.
تیم توسعه تصور میکند پروژه بعد از تحویل نسخه نهایی تمام شده است، اما کارفرما انتظار چند ماه پشتیبانی رایگان دارد.
یا ممکن است بعد از پایان پروژه تازه مشخص شود که مالکیت سورس کد، دیتابیس یا زیرساخت در قرارداد بهوضوح تعیین نشده است.
به همین دلیل یک قرارداد طراحی نرم افزار اختصاصی حرفهای باید قبل از شروع توسعه، بخشهای فنی، مالی، اجرایی و حقوقی پروژه را تا حد ممکن شفاف کند.
این مقاله یک راهنمای عمومی برای شناخت بندهای مهم قرارداد پروژه نرم افزاری است و جایگزین بررسی قرارداد توسط مشاور حقوقی نیست.
چرا قرارداد طراحی نرم افزار اختصاصی اهمیت دارد؟
نرم افزار اختصاصی برخلاف خرید یک محصول آماده، پروژهای پویا است.
در طول توسعه ممکن است:
نیازهای جدید کشف شوند.
بعضی قابلیتها تغییر کنند.
Integration جدیدی اضافه شود.
طراحی UI/UX اصلاح شود.
Timeline جابهجا شود.
یک قابلیت پیچیدهتر از برآورد اولیه باشد.
کارفرما بخواهد نسخه جدیدی از یک ماژول توسعه داده شود.
اگر از ابتدا مشخص نباشد در چنین شرایطی چه فرایندی اجرا میشود، احتمال اختلاف افزایش پیدا میکند.
قرارداد خوب قرار نیست جلوی تمام تغییرات را بگیرد؛ بلکه باید مشخص کند تغییرات چگونه مدیریت میشوند.
۱. مشخصات دقیق طرفین قرارداد
در ابتدای قرارداد باید هویت و اطلاعات طرفین کاملاً روشن باشد.
برای شرکتها معمولاً اطلاعاتی مانند:
نام شرکت
شناسه ملی
شماره ثبت
آدرس
نماینده مجاز
اطلاعات تماس
و برای اشخاص حقیقی اطلاعات شناسایی مورد نیاز درج میشود.
همچنین باید مشخص شود چه کسی از سمت کارفرما اختیار تأیید:
طراحی
Scope
تغییرات
تحویل
پرداختها
را دارد.
این نکته در پروژههای سازمانی بسیار مهم است؛ زیرا وجود چند تصمیمگیرنده میتواند روند پروژه را کند کند.
تقریباً در تمام پروژههای نرم افزاری امکان تغییر نیازها وجود دارد.
فرض کنید در میانه پروژه کارفرما درخواست کند:
«علاوه بر سیستم فعلی، یک سیستم نمایندگی هم اضافه شود.»
این تغییر ممکن است روی:
دیتابیس
Permission
UI
Backend
گزارشها
تست
تأثیر بگذارد.
قرارداد باید مشخص کند درخواست جدید چگونه بررسی میشود.
یک فرایند استاندارد میتواند شامل:
ثبت درخواست
تحلیل فنی
بررسی اثر روی Timeline
بررسی هزینه
تأیید کارفرما
ورود به برنامه توسعه
باشد.
این روش باعث میشود توسعه پروژه کنترلشده باقی بماند.
۱۰. معیار تحویل و Acceptance Criteria
عبارت «نرم افزار تکمیل شود» معیار دقیقی برای تحویل نیست.
باید تا حد امکان مشخص شود چه زمانی یک قابلیت تحویلشده محسوب میشود.
برای مثال:
امکان ایجاد مشتری وجود داشته باشد.
دادهها در دیتابیس ثبت شوند.
Permissionها اعمال شوند.
خطاهای اصلی رفع شده باشند.
قابلیت در مرورگرهای مورد توافق اجرا شود.
سناریوی مشخص تست شود.
Acceptance Criteria به کارفرما و تیم توسعه کمک میکند تعریف یکسانی از «تمامشدن» داشته باشند.
۱۱. تفاوت Bug و قابلیت جدید
این موضوع در دوره پشتیبانی بسیار مهم است.
Bug یعنی قابلیتی که طبق Scope باید کار کند، اما عملکرد صحیح ندارد.
برای مثال:
طبق Scope کاربر باید بتواند فاکتور ثبت کند، اما دکمه ثبت خطا میدهد.
این یک Bug است.
اما اگر بعد از تحویل کارفرما درخواست کند:
«قابلیت صدور فاکتور چندارزی نیز اضافه شود.»
در حالی که چنین قابلیتی در Scope وجود نداشته است، این Feature جدید محسوب میشود.
تعریف این تفاوت در قرارداد باعث شفافیت دوره پشتیبانی میشود.
۱۲. مالکیت سورس کد
یکی از مهمترین مواردی که باید قبل از شروع پروژه روشن شود:
مالک سورس کد چه کسی است؟
مدلهای مختلفی وجود دارد.
ممکن است:
مالکیت کامل پس از تسویه به کارفرما منتقل شود.
یک License مشخص ارائه شود.
بخشی از Frameworkهای عمومی متعلق به شرکت توسعهدهنده باقی بمانند.
کتابخانههای Open Source طبق License خود استفاده شوند.
مهم این است که مدل مالکیت کاملاً شفاف باشد.
اگر کارفرما انتظار دارد Repository کامل پروژه را دریافت کند، این موضوع باید در قرارداد نوشته شود.
۱۳. مالکیت دیتابیس و اطلاعات کاربران
سورس کد تنها دارایی مهم نیست.
باید وضعیت موارد زیر نیز مشخص شود:
دیتابیس
اطلاعات کاربران
فایلهای آپلودشده
تصاویر
گزارشها
Backupها
بهخصوص در پروژههایی که اطلاعات مشتریان یا دادههای حساس ذخیره میشوند، مالکیت و نحوه دسترسی باید کاملاً روشن باشد.
۱۴. استفاده از سرویسها و کتابخانههای شخص ثالث
تقریباً هیچ نرم افزار مدرنی کاملاً از صفر و بدون ابزار خارجی ساخته نمیشود.
ممکن است پروژه از:
کتابخانه Open Source
سرویس پیامک
درگاه پرداخت
Cloud Storage
Email Provider
Map API
سرویس AI
سرویس احراز هویت
استفاده کند.
قرارداد بهتر است مشخص کند هزینه و مسئولیت این سرویسها چگونه مدیریت میشود.
مثلاً اگر Google Maps یا سرویس هوش مصنوعی قیمت خود را افزایش دهد، این هزینه الزاماً تحت کنترل تیم توسعه نیست.
۱۵. امنیت نرم افزار
سطح امنیت مورد انتظار باید متناسب با پروژه مشخص شود.
بسته به نوع سیستم ممکن است شامل:
Authentication
Authorization
Rate Limiting
رمزنگاری
Audit Log
Backup
مدیریت Session
محدودیت Upload
حفاظت از API
باشد.
در پروژههایی که داده حساس دارند، مسئولیتهای امنیتی باید بسیار دقیقتر تعریف شوند.
پشتیبانگیری و Backup
قرارداد باید مشخص کند:
Backup بر عهده چه کسی است؟
چند وقت یک بار گرفته میشود؟
کجا نگهداری میشود؟
چه مدت نگهداری میشود؟
فرایند Restore چگونه است؟
Backup زمانی ارزش دارد که امکان بازیابی آن نیز بررسی شده باشد.
زیرساخت و Hosting
باید مشخص شود نرم افزار روی چه زیرساختی Deploy میشود.
مثلاً:
VPS
Dedicated Server
Cloud
زیرساخت کارفرما
همچنین باید مشخص شود هزینه:
سرور
Domain
SSL
CDN
Storage
Backup
بر عهده چه کسی است.
پشتیبانی بعد از تحویل
یکی از مهمترین بخشها مدت و محدوده Support است.
پشتیبانی ممکن است شامل:
رفع Bug
بررسی Error
مانیتورینگ
Backup
بهروزرسانی امنیتی
باشد.
اما توسعه Feature جدید معمولاً باید جداگانه تعریف شود.
قرارداد باید مشخص کند:
پشتیبانی چند ماه است؟
ساعت پاسخگویی چگونه است؟
کانال ارتباطی چیست؟
چه مواردی رایگان هستند؟
چه مواردی هزینه جدا دارند؟
SLA چیست؟
در پروژههای حساس ممکن است Service Level Agreement نیز تعریف شود.
برای مثال:
خطای Critical باید در مدت مشخص بررسی شود.
یا Availability سیستم باید در سطح مشخصی نگهداری شود.
SLA بیشتر برای سامانههایی اهمیت دارد که توقف آنها مستقیماً روی عملیات کسبوکار اثر میگذارد.
مستندات پروژه
در پروژههای بزرگتر، Documentation اهمیت زیادی دارد.
ممکن است شامل:
معماری سیستم
API Documentation
دیتابیس
نحوه Deployment
Environment Variables
راهنمای مدیر سیستم
باشد.
وجود مستندات مناسب باعث میشود توسعه آینده سیستم وابستگی کمتری به افراد خاص داشته باشد.
شرایط فسخ قرارداد
اگر پروژه به هر دلیل متوقف شود، باید مشخص شود:
هزینه کار انجامشده چگونه محاسبه میشود؟
سورس فعلی تحویل داده میشود؟
اطلاعات پروژه چه میشوند؟
دسترسیها چگونه بازگردانده میشوند؟
تعهدات باقیمانده چیست؟
تعریف این شرایط قبل از بروز مشکل بسیار سادهتر از مذاکره در زمان اختلاف است.
محرمانگی اطلاعات
اگر تیم توسعه به اطلاعات حساس شرکت دسترسی پیدا میکند، بند Confidentiality اهمیت زیادی دارد.
ممکن است اطلاعات شامل:
داده مشتریان
مدل کسبوکار
اطلاعات مالی
فرایندهای داخلی
اسناد محرمانه
باشد.
در چنین شرایطی میتوان تعهد محرمانگی یا NDA نیز تعریف کرد.
حل اختلاف
هر قرارداد حرفهای باید مشخص کند در صورت ایجاد اختلاف چه فرایندی طی میشود.
برای مثال:
مذاکره مستقیم
بررسی توسط مدیران پروژه
داوری یا روش توافقشده
پیگیری حقوقی در صورت عدم حل اختلاف
جزئیات این بخش بهتر است توسط مشاور حقوقی متناسب با شرایط طرفین تنظیم شود.
قبل از امضای قرارداد این سؤالها را بپرسید
قبل از امضای قرارداد طراحی نرم افزار اختصاصی مطمئن شوید پاسخ این سؤالها روشن است:
دقیقاً چه چیزی ساخته میشود؟
چه چیزهایی ساخته نمیشوند؟
چه زمانی تحویل داده میشود؟
پرداختها چگونهاند؟
Feature جدید چگونه قیمتگذاری میشود؟
مالک سورس کد چه کسی است؟
دیتابیس متعلق به چه کسی است؟
زیرساخت با چه کسی است؟
پشتیبانی چند ماه است؟
Bug چگونه تعریف میشود؟
چه مستنداتی تحویل داده میشود؟
اگر پروژه متوقف شود چه اتفاقی میافتد؟
اگر پاسخ یک سؤال مهم مبهم است، بهتر است قبل از شروع پروژه شفاف شود.
رویکرد آرکوتک در قرارداد پروژههای نرم افزاری
در آرکوتک تلاش میشود پیش از شروع توسعه، پروژه تا حد امکان به اجزای قابل اندازهگیری تبدیل شود.
مسئله کسبوکار، کاربران، Scope، Integrationها، معماری کلی و نسخه اول مشخص میشوند تا کارفرما دید روشنتری نسبت به پروژه داشته باشد.
در پروژههای پیچیده، توسعه مرحلهای میتواند کمک کند هر فاز دارای خروجی مشخص باشد و تغییرات نیز از طریق فرایند Change Request مدیریت شوند.
اگر قصد سفارش یک سیستم سفارشی دارید، صفحه طراحی نرم افزار اختصاصی نقطه اصلی این خوشه در آرکوتک خواهد بود.
جمعبندی
یک قرارداد طراحی نرم افزار اختصاصی خوب فقط مبلغ و تاریخ تحویل نیست.
Scope، Deliverable، Timeline، پرداخت، Change Request، Acceptance Criteria، مالکیت سورس، دیتابیس، امنیت، زیرساخت، پشتیبانی، مستندات و شرایط فسخ همگی باید متناسب با پروژه بررسی شوند.
هرچه این موارد قبل از شروع شفافتر باشند، احتمال اختلاف در طول توسعه کمتر خواهد بود و تیم فنی و کارفرما میتوانند انرژی بیشتری روی ساخت یک محصول موفق بگذارند.
سوالات متداول
مهمترین بند قرارداد طراحی نرم افزار چیست؟
Scope یکی از مهمترین بندهاست؛ زیرا مشخص میکند دقیقاً چه قابلیتهایی باید توسعه داده شوند.
آیا سورس کد باید به کارفرما تحویل داده شود؟
این موضوع به مدل قرارداد بستگی دارد و باید قبل از شروع پروژه بهصراحت مشخص شود.
تغییرات جدید در طول پروژه چگونه مدیریت میشوند؟
بهتر است از فرایند Change Request استفاده شود تا اثر تغییر روی هزینه و زمان قبل از اجرا مشخص شود.
دوره پشتیبانی باید داخل قرارداد باشد؟
بله. مدت پشتیبانی، محدوده خدمات و تفاوت Bug با Feature جدید بهتر است شفاف تعریف شوند.
آیا برای قرارداد نرم افزار به مشاور حقوقی نیاز است؟
برای پروژههای مهم و قراردادهای دارای تعهدات مالی و حقوقی جدی، بررسی نسخه نهایی توسط مشاور حقوقی اقدام منطقیتری است.
