چرا قرارداد نرم‌افزار متفاوت است؟
در قرارداد ساخت یک ساختمان، خروجی نسبتاً روشن است. در نرم‌افزار، خروجی تا میانه‌ی مسیر دقیق نمی‌شود و تقریباً همیشه تغییر می‌کند. قراردادی که این واقعیت را نپذیرد، به اختلاف می‌رسد — نه به دلیل بدنیتی طرفین، بلکه به دلیل نبود سازوکار برای تغییر.
دوازده بند ضروری
- تعریف دقیق دامنه: پیوستی که فهرست امکانات، سناریوهای کاربری و آنچه خارج از دامنه است را مشخص کند.
- معیار پذیرش: تعریف روشن اینکه «تحویل موفق» یعنی چه؛ بهتر است با موارد آزمون مشخص شود.
- سازوکار تغییر دامنه: فرآیند مکتوب درخواست تغییر، برآورد اثر زمانی و مالی و تأیید.
- زمان‌بندی و مراحل پرداخت: اتصال پرداخت به تحویل مرحله‌ای، نه صرفاً به تاریخ تقویمی.
- مالکیت کد و مالکیت فکری: تصریح انتقال مالکیت سورس‌کد و مستندات، و تعیین تکلیف کتابخانه‌های متن‌باز.
- محرمانگی و حفاظت داده: تعهد دوطرفه و تعیین تکلیف داده‌های واقعی در محیط تست.
- گارانتی و رفع نقص: مدت گارانتی و تفکیک «نقص» از «درخواست جدید».
- سطح خدمت (SLA): زمان پاسخ و زمان رفع به تفکیک شدت خطا، و ضمانت اجرای نقض آن.
- تحویل زیرساخت: انتقال حساب‌های سرور، دامنه، مخزن کد و کلیدهای دسترسی.
- مستندسازی و آموزش: مستندات فنی، راهنمای کاربر و ساعات آموزش.
- فسخ و خروج: شرایط فسخ و تعهد همکاری در انتقال پروژه به تیم دیگر.
- حل اختلاف: ارجاع به داوری یا کارشناس فنی مرضی‌الطرفین پیش از مراجعه به دادگاه.
نکته‌ای درباره قیمت ثابت در برابر زمان و مواد
قرارداد قیمت ثابت برای پروژه‌هایی مناسب است که دامنه‌شان واقعاً روشن است. برای محصولاتی که هنوز در حال کشف نیاز هستند، مدل زمان و مواد با سقف بودجه و بازبینی دوره‌ای منصفانه‌تر و کم‌ریسک‌تر است.
در تیم پویا، قراردادهای نرم‌افزاری را تیم حقوقی و تیم فنی مشترکاً تنظیم می‌کنند تا متن حقوقی با واقعیت فنی پروژه بخواند.
این مقاله بخشی از مجموعه راهنماهای کاربردی تیم پویاست. اگر درباره‌ی اجرای عملی این موضوع در سازمان خودتان سوال دارید، جلسه‌ی مشاوره‌ی رایگان رزرو کنید.