معنی اصطلاحات این مقاله
- API
- رابط ارتباط میان دو نرمافزار یا سرویس
- CRM
- سیستم مدیریت ارتباط با مشتری و پیگیری فروش
- UI
- رابط کاربری؛ ظاهر و اجزای قابل تعامل
قرارداد طراحی نرم افزار اختصاصی یکی از مهمترین بخش‌های شروع یک پروژه نرم افزاری است؛ زیرا حتی اگر تیم فنی قدرتمندی انتخاب کرده باشید، نبود قرارداد شفاف می‌تواند در ادامه باعث اختلاف درباره امکانات، زمان تحویل، هزینه، مالکیت سورس کد و پشتیبانی شود.
بسیاری از اختلافات پروژههای نرم افزاری نه به دلیل ضعف برنامه‌نویسی، بلکه به دلیل تعریف مبهم مسئولیت‌ها در ابتدای پروژه ایجاد می‌شوند. کارفرما تصور میکند قابلیتی جزو پروژه است، اما تیم توسعه آن را خارج از محدوده پروژه می‌داند. تیم توسعه تصور میکند پروژه بعد از تحویل نسخه نهایی تمام شده است، اما کارفرما انتظار چند ماه پشتیبانی رایگان دارد.
یا ممکن است بعد از پایان پروژه تازه مشخص شود که مالکیت سورس کد، دیتابیس یا زیرساخت در قرارداد به‌وضوح تعیین نشده است.
به همین دلیل یک قرارداد طراحی نرم افزار اختصاصی حرفه‌ای باید قبل از شروع توسعه، بخش‌های فنی، مالی، اجرایی و حقوقی پروژه را تا حد ممکن شفاف کند.
این مقاله یک راهنمای عمومی برای شناخت بندهای مهم قرارداد پروژه نرم افزاری است و جایگزین بررسی قرارداد توسط مشاور حقوقی نیست.
چرا قرارداد طراحی نرم افزار اختصاصی اهمیت دارد؟
نرم افزار اختصاصی برخلاف خرید یک محصول آماده، پروژه‌ای پویا است. در طول توسعه ممکن است:
- نیازهای جدید کشف شوند.
- بعضی قابلیت‌ها تغییر کنند.
- اتصال به سیستم‌های دیگر جدیدی اضافه شود.
- طراحی رابط و تجربه کاربری اصلاح شود.
- زمان‌بندی جابه‌جا شود.
- یک قابلیت پیچیده‌تر از برآورد اولیه باشد.
- کارفرما بخواهد نسخه جدیدی از یک ماژول توسعه داده شود.
اگر از ابتدا مشخص نباشد در چنین شرایطی چه فرایندی اجرا می‌شود، احتمال اختلاف افزایش پیدا میکند. قرارداد خوب قرار نیست جلوی تمام تغییرات را بگیرد؛ بلکه باید مشخص کند تغییرات چگونه مدیریت می‌شوند.
۱. مشخصات دقیق طرفین قرارداد
در ابتدای قرارداد باید هویت و اطلاعات طرفین کاملاً روشن باشد. برای شرکت‌ها معمولاً اطلاعاتی مانند:
- نام شرکت
- شناسه ملی
- شماره ثبت
- آدرس
- نماینده مجاز
- اطلاعات تماس
و برای اشخاص حقیقی اطلاعات شناسایی مورد نیاز درج می‌شود. همچنین باید مشخص شود چه کسی از سمت کارفرما اختیار تأیید:
- طراحی
- محدوده پروژه
- تغییرات
- تحویل
- پرداخت‌ها
را دارد. این نکته در پروژههای سازمانی بسیار مهم است؛ زیرا وجود چند تصمیم‌گیرنده می‌تواند روند پروژه را کند کند.
۲. موضوع قرارداد باید دقیق باشد
عباراتی مانند: «طراحی یک نرم افزار مدیریتی» یا: «ساخت CRM اختصاصی» برای موضوع قرارداد کافی نیستند. موضوع باید تا حد ممکن مشخص کند پروژه شامل چه نوع محصولی است. برای مثال: «تحلیل، طراحی، توسعه، تست و استقرار یک وب اپلیکیشن اختصاصی برای مدیریت مشتریان، فروش، قراردادها و گزارش‌های مدیریتی بر اساس محدوده پروژه پیوست قرارداد.» هرچه موضوع قرارداد دقیق‌تر باشد، احتمال برداشت‌های متفاوت کمتر می‌شود.
۳. محدوده پروژه یا محدوده پروژه
یکی از مهمترین بخش‌های قرارداد طراحی نرم افزار اختصاصی، محدوده پروژه است. محدوده پروژه مشخص میکند تیم توسعه دقیقاً چه چیزی باید تحویل دهد. برای مثال یک CRM اختصاصی ممکن است شامل:
- ورود و مدیریت کاربران
- مدیریت مشتریان
- مدیریت سرنخ‌ها
- پیگیری‌ها
- مراحل فروش
- مدیریت قرارداد
- فایل‌ها
- پیامک
- اعلان‌ها
- داشبورد مدیریتی
- گزارش‌ها
- نقش‌های کاربری
- سطح دسترسی
باشد. اما همین فهرست نیز باید در صورت امکان دقیق‌تر شود. مثلاً اگر نوشته شده است «گزارش‌گیری»، باید مشخص شود چه نوع گزارش‌هایی جزو نسخه فعلی هستند.
چرا محدوده پروژه حیاتی است؟
زیرا بسیاری از اختلافات پروژه با جمله‌ای شبیه این شروع می‌شوند:
«ما فکر می‌کردیم این قابلیت هم داخل پروژه است.»
محدوده پروژه دقیق این مشکل را تا حد زیادی کاهش می‌دهد. اگر هنوز در مرحله تعریف پروژه هستید، مطالعه مقاله مراحل طراحی نرم افزار اختصاصی می‌تواند دید بهتری نسبت به فرایند تحلیل و تعیین محدوده ایجاد کند.
۴. موارد خارج از محدوده پروژه
فقط مشخص‌کردن امکانات داخل پروژه کافی نیست. در بعضی پروژه‌ها بهتر است موارد مهمی که جزو پروژه نیستند نیز نوشته شوند. برای مثال:
- اپلیکیشن Android در نسخه فعلی وجود ندارد.
- اپلیکیشن iOS جزو قرارداد نیست.
- ورود اطلاعات قدیمی بر عهده کارفرما است.
- تولید محتوای متنی جزو خدمات نیست.
- هزینه سرویس پیامک جداگانه است.
- خرید سرور جداگانه محاسبه می‌شود.
- اتصال به سیستم‌های دیگر با سیستم حسابداری در فاز اول انجام نمی‌شود.
این بخش باعث می‌شود انتظارات دو طرف واقعی‌تر باشند.
۵. خروجی‌ها و Deliverableهای پروژه
قرارداد باید مشخص کند در پایان پروژه دقیقاً چه چیزهایی تحویل داده می‌شوند. بسته به پروژه ممکن است شامل:
- نسخه نهایی نرم افزار
- سورس کد رابط سمت کاربر
- سورس کد بخش سرور
- دیتابیس
- فایل‌های طراحی
- مستندات
- دسترسی سرور
- مخزن
- اطلاعات استقرار
- حساب‌های مدیریتی
- راهنمای استفاده
باشد. اگر موردی برای کارفرما اهمیت دارد، نباید فرض شود که «طبیعتاً تحویل داده می‌شود». بهتر است صریحاً در قرارداد درج شود.
۶. زمان‌بندی پروژه: قرارداد باید زمان‌بندی پروژه را مشخص کند. اما برای پروژههای بزرگ بهتر است فقط یک تاریخ نهایی نوشته نشود. پروژه می‌تواند به Milestoneهای مختلف تقسیم شود. برای مثال:
فاز اول: تحلیل و طراحی
فاز دوم: توسعه هسته سیستم
فاز سوم: توسعه ماژول‌های اصلی
فاز چهارم: تست و اصلاح
فاز پنجم: استقرار این ساختار باعث می‌شود وضعیت پروژه قابل اندازه‌گیری باشد. برای شناخت عوامل مؤثر بر زمان‌بندی می‌توانید مقاله مدت زمان ساخت نرم افزار اختصاصی را نیز مطالعه کنید.
۷. مسئولیت تأخیرهای ناشی از کارفرما
همه تأخیرها ناشی از تیم توسعه نیستند. گاهی پروژه به دلیل تأخیر در:
- تأیید UI
- ارائه اطلاعات
- ارسال دسترسی‌ها
- انتخاب سرویس
- پاسخ به سؤالات
- تحویل API
- پرداخت مرحله‌ای
متوقف می‌شود. بهتر است قرارداد مشخص کند اگر اطلاعات یا تأیید مورد نیاز در زمان مشخص ارائه نشود، زمان‌بندی پروژه چگونه تغییر خواهد کرد.
۸. مبلغ قرارداد و روش پرداخت
بخش مالی باید کاملاً روشن باشد. برای مثال پرداخت می‌تواند بر اساس Milestone انجام شود:
- درصدی هنگام شروع پروژه
- درصدی بعد از طراحی
- درصدی بعد از نسخه آزمایشی
- درصدی هنگام تحویل نهایی
در پروژههای بزرگ، پرداخت مرحله‌ای معمولاً برای هر دو طرف منطقی‌تر است. همچنین باید مشخص شود:
- مالیات چگونه محاسبه می‌شود؟
- هزینه سرویس‌های جانبی با چه کسی است؟
- هزینه سرور جزو قرارداد است؟
- APIهای پولی چگونه محاسبه می‌شوند؟
- هزینه توسعه قابلیت‌های خارج از محدوده پروژه چگونه تعیین می‌شود؟
اگر هنوز در مرحله بودجه‌بندی هستید، مقاله هزینه ساخت نرم افزار اختصاصی عوامل اصلی قیمت پروژه را بررسی کرده است.
۹. Change Request یا مدیریت تغییرات
این بند یکی از حیاتی‌ترین بخش‌های قرارداد است. تقریباً در تمام پروژههای نرم افزاری امکان تغییر نیازها وجود دارد. فرض کنید در میانه پروژه کارفرما درخواست کند: «علاوه بر سیستم فعلی، یک سیستم نمایندگی هم اضافه شود.» این تغییر ممکن است روی:
- دیتابیس
- مجوز دسترسی
- UI
- بخش سرور
- گزارش‌ها
- تست
تأثیر بگذارد. قرارداد باید مشخص کند درخواست جدید چگونه بررسی می‌شود. یک فرایند استاندارد می‌تواند شامل:
- ثبت درخواست
- تحلیل فنی
- بررسی اثر روی زمان‌بندی
- بررسی هزینه
- تأیید کارفرما
- ورود به برنامه توسعه
باشد. این روش باعث می‌شود توسعه پروژه کنترل‌شده باقی بماند.
۱۰. معیار تحویل و Acceptance Criteria
عبارت «نرم افزار تکمیل شود» معیار دقیقی برای تحویل نیست. باید تا حد امکان مشخص شود چه زمانی یک قابلیت تحویل‌شده محسوب می‌شود. برای مثال:
- امکان ایجاد مشتری وجود داشته باشد.
- داده‌ها در دیتابیس ثبت شوند.
- مجوزهای دسترسی اعمال شوند.
- خطاهای اصلی رفع شده باشند.
- قابلیت در مرورگرهای مورد توافق اجرا شود.
- سناریوی مشخص تست شود.
Acceptance Criteria به کارفرما و تیم توسعه کمک میکند تعریف یکسانی از «تمام‌شدن» داشته باشند.
۱۱. تفاوت خطای نرمافزار و قابلیت جدید
این موضوع در دوره پشتیبانی بسیار مهم است. خطای نرمافزار یعنی قابلیتی که طبق محدوده پروژه باید کار کند، اما عملکرد صحیح ندارد. برای مثال: طبق محدوده پروژه کاربر باید بتواند فاکتور ثبت کند، اما دکمه ثبت خطا می‌دهد. این یک خطای نرمافزار است. اما اگر بعد از تحویل کارفرما درخواست کند: «قابلیت صدور فاکتور چندارزی نیز اضافه شود.» در حالی که چنین قابلیتی در محدوده پروژه وجود نداشته است، این قابلیت جدید محسوب می‌شود.
تعریف این تفاوت در قرارداد باعث شفافیت دوره پشتیبانی می‌شود.
۱۲. مالکیت سورس کد
یکی از مهمترین مواردی که باید قبل از شروع پروژه روشن شود:
مالک سورس کد چه کسی است؟
مدل‌های مختلفی وجود دارد. ممکن است:
- مالکیت کامل پس از تسویه به کارفرما منتقل شود.
- یک License مشخص ارائه شود.
- بخشی از چارچوب توسعه‌های عمومی متعلق به شرکت توسعه‌دهنده باقی بمانند.
- کتابخانه‌های Open Source طبق License خود استفاده شوند.
مهم این است که مدل مالکیت کاملاً شفاف باشد. اگر کارفرما انتظار دارد مخزن کامل پروژه را دریافت کند، این موضوع باید در قرارداد نوشته شود.
۱۳. مالکیت دیتابیس و اطلاعات کاربران
سورس کد تنها دارایی مهم نیست. باید وضعیت موارد زیر نیز مشخص شود:
- دیتابیس
- اطلاعات کاربران
- فایل‌های آپلودشده
- تصاویر
- گزارش‌ها
- نسخه پشتیبان‌ها
به‌خصوص در پروژه‌هایی که اطلاعات مشتریان یا داده‌های حساس ذخیره می‌شوند، مالکیت و نحوه دسترسی باید کاملاً روشن باشد.
۱۴. استفاده از سرویس‌ها و کتابخانه‌های شخص ثالث
تقریباً هیچ نرم افزار مدرنی کاملاً از صفر و بدون ابزار خارجی ساخته نمی‌شود. ممکن است پروژه از:
- کتابخانه Open Source
- سرویس پیامک
- درگاه پرداخت
- Cloud Storage
- Email Provider
- Map API
- سرویس هوش مصنوعی
- سرویس احراز هویت
استفاده کند. قرارداد بهتر است مشخص کند هزینه و مسئولیت این سرویس‌ها چگونه مدیریت می‌شود. مثلاً اگر Google Maps یا سرویس هوش مصنوعی قیمت خود را افزایش دهد، این هزینه الزاماً تحت کنترل تیم توسعه نیست.
هزینه نرمافزار شما به چه امکاناتی بستگی دارد؟
فرایند اصلی، نقش کاربران و اتصال‌های موردنیاز را توضیح دهید تا امکانات نسخه اول، زمان اجرا و هزینه پروژه‌تان بررسی شود. برای شروع، داشتن طرح فنی کامل لازم نیست.
۱۵. امنیت نرم افزار
سطح امنیت مورد انتظار باید متناسب با پروژه مشخص شود. بسته به نوع سیستم ممکن است شامل:
- احراز هویت
- کنترل مجوز دسترسی
- محدودیت تعداد درخواست
- رمزنگاری
- سابقه اقدام‌ها
- نسخه پشتیبان
- مدیریت نشست
- محدودیت Upload
- حفاظت از API
باشد. در پروژه‌هایی که داده حساس دارند، مسئولیت‌های امنیتی باید بسیار دقیق‌تر تعریف شوند.
پشتیبان‌گیری و نسخه پشتیبان
قرارداد باید مشخص کند:
- نسخه پشتیبان بر عهده چه کسی است؟
- چند وقت یک بار گرفته می‌شود؟
- کجا نگهداری می‌شود؟
- چه مدت نگهداری می‌شود؟
- فرایند Restore چگونه است؟
نسخه پشتیبان زمانی ارزش دارد که امکان بازیابی آن نیز بررسی شده باشد.
زیرساخت و Hosting
باید مشخص شود نرم افزار روی چه زیرساختی استقرار می‌شود. مثلاً:
- VPS
- Dedicated Server
- Cloud
- زیرساخت کارفرما
همچنین باید مشخص شود هزینه:
- سرور
- Domain
- SSL
- CDN
- ذخیره‌سازی
- نسخه پشتیبان
بر عهده چه کسی است.
پشتیبانی بعد از تحویل
یکی از مهمترین بخش‌ها مدت و محدوده پشتیبانی است. پشتیبانی ممکن است شامل:
- رفع خطای نرمافزار
- بررسی خطا
- مانیتورینگ
- نسخه پشتیبان
- به‌روزرسانی امنیتی
باشد. اما توسعه قابلیت جدید معمولاً باید جداگانه تعریف شود. قرارداد باید مشخص کند:
- پشتیبانی چند ماه است؟
- ساعت پاسخگویی چگونه است؟
- کانال ارتباطی چیست؟
- چه مواردی رایگان هستند؟
- چه مواردی هزینه جدا دارند؟
SLA چیست؟
در پروژههای حساس ممکن است Service Level Agreement نیز تعریف شود. برای مثال: خطای Critical باید در مدت مشخص بررسی شود. یا Availability سیستم باید در سطح مشخصی نگهداری شود. SLA بیشتر برای سامانه‌هایی اهمیت دارد که توقف آن‌ها مستقیماً روی عملیات کسب‌وکار اثر می‌گذارد.
مستندات پروژه
در پروژههای بزرگ‌تر، مستندات اهمیت زیادی دارد. ممکن است شامل:
- معماری سیستم
- API Documentation
- دیتابیس
- نحوه استقرار
- Environment Variables
- راهنمای مدیر سیستم
باشد. وجود مستندات مناسب باعث می‌شود توسعه آینده سیستم وابستگی کمتری به افراد خاص داشته باشد.
شرایط فسخ قرارداد
اگر پروژه به هر دلیل متوقف شود، باید مشخص شود:
- هزینه کار انجام‌شده چگونه محاسبه می‌شود؟
- سورس فعلی تحویل داده می‌شود؟
- اطلاعات پروژه چه می‌شوند؟
- دسترسی‌ها چگونه بازگردانده می‌شوند؟
- تعهدات باقی‌مانده چیست؟
تعریف این شرایط قبل از بروز مشکل بسیار ساده‌تر از مذاکره در زمان اختلاف است.
محرمانگی اطلاعات
اگر تیم توسعه به اطلاعات حساس شرکت دسترسی پیدا میکند، بند Confidentiality اهمیت زیادی دارد. ممکن است اطلاعات شامل:
- داده مشتریان
- مدل کسب‌وکار
- اطلاعات مالی
- فرایندهای داخلی
- اسناد محرمانه
باشد. در چنین شرایطی می‌توان تعهد محرمانگی یا NDA نیز تعریف کرد.
حل اختلاف
هر قرارداد حرفه‌ای باید مشخص کند در صورت ایجاد اختلاف چه فرایندی طی می‌شود. برای مثال:
- مذاکره مستقیم
- بررسی توسط مدیران پروژه
- داوری یا روش توافق‌شده
- پیگیری حقوقی در صورت عدم حل اختلاف
جزئیات این بخش بهتر است توسط مشاور حقوقی متناسب با شرایط طرفین تنظیم شود.
قبل از امضای قرارداد این سؤال‌ها را بپرسید
قبل از امضای قرارداد طراحی نرم افزار اختصاصی مطمئن شوید پاسخ این سؤال‌ها روشن است:
- دقیقاً چه چیزی ساخته می‌شود؟
- چه چیزهایی ساخته نمی‌شوند؟
- چه زمانی تحویل داده می‌شود؟
- پرداخت‌ها چگونه‌اند؟
- قابلیت جدید چگونه قیمت‌گذاری می‌شود؟
- مالک سورس کد چه کسی است؟
- دیتابیس متعلق به چه کسی است؟
- زیرساخت با چه کسی است؟
- پشتیبانی چند ماه است؟
- خطای نرمافزار چگونه تعریف می‌شود؟
- چه مستنداتی تحویل داده می‌شود؟
- اگر پروژه متوقف شود چه اتفاقی می‌افتد؟
اگر پاسخ یک سؤال مهم مبهم است، بهتر است قبل از شروع پروژه شفاف شود.
رویکرد آرکوتک در قرارداد پروژههای نرم افزاری
در آرکوتک تلاش می‌شود پیش از شروع توسعه، پروژه تا حد امکان به اجزای قابل اندازه‌گیری تبدیل شود. مسئله کسب‌وکار، کاربران، محدوده پروژه، اتصال به سیستم‌های دیگر، معماری کلی و نسخه اول مشخص می‌شوند تا کارفرما دید روشن‌تری نسبت به پروژه داشته باشد. در پروژههای پیچیده، توسعه مرحله‌ای می‌تواند کمک کند هر فاز دارای خروجی مشخص باشد و تغییرات نیز از طریق فرایند Change Request مدیریت شوند.
اگر قصد سفارش یک سیستم سفارشی دارید، صفحه طراحی نرم افزار اختصاصی نقطه اصلی این خوشه در آرکوتک خواهد بود.
جمع‌بندی
یک قرارداد طراحی نرم افزار اختصاصی خوب فقط مبلغ و تاریخ تحویل نیست. محدوده پروژه، Deliverable، زمان‌بندی، پرداخت، Change Request، Acceptance Criteria، مالکیت سورس، دیتابیس، امنیت، زیرساخت، پشتیبانی، مستندات و شرایط فسخ همگی باید متناسب با پروژه بررسی شوند. هرچه این موارد قبل از شروع شفاف‌تر باشند، احتمال اختلاف در طول توسعه کمتر خواهد بود و تیم فنی و کارفرما می‌توانند انرژی بیشتری روی ساخت یک محصول موفق بگذارند.
پرسش‌های متداول
مهمترین بند قرارداد طراحی نرم افزار چیست؟
محدوده پروژه یکی از مهمترین بندهاست؛ زیرا مشخص میکند دقیقاً چه قابلیتهایی باید توسعه داده شوند.
آیا سورس کد باید به کارفرما تحویل داده شود؟
این موضوع به مدل قرارداد بستگی دارد و باید قبل از شروع پروژه به‌صراحت مشخص شود.
تغییرات جدید در طول پروژه چگونه مدیریت می‌شوند؟
بهتر است از فرایند Change Request استفاده شود تا اثر تغییر روی هزینه و زمان قبل از اجرا مشخص شود.
دوره پشتیبانی باید داخل قرارداد باشد؟
بله. مدت پشتیبانی، محدوده خدمات و تفاوت خطای نرمافزار با قابلیت جدید بهتر است شفاف تعریف شوند.
آیا برای قرارداد نرم افزار به مشاور حقوقی نیاز است؟
برای پروژههای مهم و قراردادهای دارای تعهدات مالی و حقوقی جدی، بررسی نسخه نهایی توسط مشاور حقوقی اقدام منطقیتری است.
