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