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