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