پاسخ کوتاه
یک قرارداد پروژه برنامهنویسی خوب باید دستکم محدوده و خروجی هر مرحله، معیار پذیرش، مبلغ و تغییرات، مالکیت و مجوز استفاده از کد و داراییها، مالکیت مخزن و حسابها، نحوه تحویل داده و مستندات، امنیت و محرمانگی، پشتیبانی و قاعده پایان همکاری را روشن کند. این راهنما جای مشاوره حقوقی نیست؛ متن نهایی باید با نوع پروژه و مقررات مرتبط توسط مشاور حقوقی بررسی شود.
مالکیت سورسکد دقیقاً چه چیزی را حل میکند؟
بحث مالکیت فقط یک فایل یا مخزن Git نیست. در یک محصول واقعی، کد، طراحی، پایگاه داده، دامنه، حساب ابری، حساب انتشار، کلیدهای سرویس، مستندات و داده هرکدام دارایی جدا هستند. ممکن است کد به کارفرما داده شده باشد، اما دامنه یا حساب استقرار همچنان زیر کنترل شخص دیگری باقی بماند.
در متن قرارداد باید روشن شود چه حقوقی نسبت به خروجی سفارشی منتقل یا اعطا میشود، چه بخشهایی از قبل وجود داشتهاند، و نرمافزارهای متنباز یا خدمات ثالث با چه مجوز و محدودیتی استفاده شدهاند. بیان حقوقی نهایی را نباید از یک متن عمومی کپی کرد.
کد و طراحی سفارشی
- آنچه باید روشن شود
- دامنه حق استفاده، تغییر، توسعه و انتقال طبق قرارداد
- شاهد تحویل
- مخزن، Tag نسخه و فهرست اقلام تولیدشده
کد یا کتابخانه قبلی
- آنچه باید روشن شود
- مالک فعلی، مجوز استفاده و محدودیت بازاستفاده
- شاهد تحویل
- فهرست وابستگی و مجوزها
حسابها و زیرساخت
- آنچه باید روشن شود
- مالک حساب، نقش مدیر و روش انتقال یا واگذاری دسترسی
- شاهد تحویل
- ورود آزمایشی با حساب سازمانی کارفرما
داده و مستندات
- آنچه باید روشن شود
- مسئول نگهداری، قالب تحویل و محرمانگی
- شاهد تحویل
- Backup قابل بازیابی و راهنمای عملیاتی
بندهای اجرایی که باید پیش از امضا روشن شوند
- شرح مسئله، محدوده هر مرحله و مواردی که صریحاً خارج از محدودهاند
- خروجی قابل تحویل: کد، طراحی، دیتابیس، مستندات، آموزش، استقرار و گزارش تست
- معیار پذیرش قابل آزمون، مسئول اجرای UAT و مهلت اعلام نتیجه
- مدل پرداخت، وابستگیهای کارفرما و اثر تأخیر در ارائه داده یا تصمیم
- فرایند ثبت، تحلیل اثر، تأیید و قیمتگذاری درخواست تغییر
- تفکیک باگ از تغییر محصول و قاعده اولویتبندی اصلاح
- محرمانگی، داده شخصی، دسترسی تیم و الزامهای امنیتی متناسب با پروژه
- پشتیبانی پس از تحویل، گارانتی رفع ایراد، SLA و شرایط پایان همکاری
مخزن، دامنه، حساب ابری و Secretها را چگونه مدیریت کنیم؟
ایمنترین الگو این است که حسابهای حیاتی از ابتدا زیر سازمان کارفرما ایجاد شوند و تیم اجرا دسترسی نقشمحور و قابل بازبینی بگیرد. اگر این کار در ابتدای پروژه ممکن نیست، زمان و روش انتقال، فهرست حسابها و مسئول چرخش رمزها و کلیدها باید دقیقاً ثبت شود.
Secretها نباید در صورتجلسه، ایمیل یا فایل کدشده ظاهری تحویل شوند. بعد از تغییر مالکیت یا پایان همکاری، دسترسیها را بازبینی و Secretهای حساس را چرخش دهید. انتقال مخزن نیز بهتنهایی جای این بازبینی را نمیگیرد.
مخزن کد
- کنترل پیشنهادی
- مالک یا سازمان کارفرما، مدیران مشخص، دسترسی حداقلی
- زمان بررسی
- شروع، هر انتشار و تحویل نهایی
دامنه و DNS
- کنترل پیشنهادی
- حساب سازمانی و ثبت اطلاعات مالکیت
- زمان بررسی
- پیش از استقرار و تحویل
سرور و Cloud
- کنترل پیشنهادی
- حساب پرداخت و مالک سازمانی، ثبت نقشها
- زمان بررسی
- شروع و پایان همکاری
API Key و رمزها
- کنترل پیشنهادی
- Vault یا مسیر امن، Scope حداقلی و Rotation
- زمان بررسی
- پس از هر تغییر دسترسی مهم
حساب انتشار و پیامک/پرداخت
- کنترل پیشنهادی
- مالکیت سازمانی و دسترسی تفکیکشده
- زمان بررسی
- پیش از انتشار نسخه عملیاتی
پذیرش و تحویل را به روز آخر موکول نکنید
معیار پذیرش باید پیش از ساخت هر قابلیت مهم قابل مشاهده باشد. این معیار میگوید کاربر مشخص در وضعیت مشخص چه کاری انجام میدهد و چه نتیجهای باید ببیند. در روز تحویل، همان معیارها و سناریوهای UAT مبنای تصمیم هستند، نه برداشت شفاهی طرفین.
صورتجلسه تحویل باید نسخه تحویلی، نتایج آزمون، موارد باز، موعد و مسئول آنها، فهرست داراییها و وضعیت حسابها را در بر بگیرد. اگر تحویل مشروط است، شرطها و اثر آنها بر بهرهبرداری باید روشن ثبت شود.
مرز این راهنما با مشاوره حقوقی
قوانین مالکیت فکری، قرارداد، مالیات، داده، استخدام و شرایط هر صنعت میتواند بر قرارداد اثر بگذارد. وجود قانون یا یک بند نمونه بهتنهایی مشخص نمیکند که در اختلاف، حقوق هر طرف چگونه تفسیر میشود. برای قراردادهای مهم، متن نهایی و شرایط انتقال حقوق را با مشاور حقوقی آشنا با موضوع نرمافزار بررسی کنید.
نکته: این صفحه راهنمای عملی برای کاهش ابهام در سفارش و تحویل نرمافزار است و مشاوره یا متن حقوقی آماده محسوب نمیشود.
پرسشهای متداول
آیا تحویل سورسکد یعنی همه چیز تحویل شده است؟
خیر. علاوه بر کد، نسخه مشخص، روش Build و استقرار، دیتابیس، مستندات، حسابهای زیرساختی، سرویسهای بیرونی و دسترسیها باید قابل استفاده و قابل بررسی باشند.
آیا حساب GitHub یا GitLab باید متعلق به کارفرما باشد؟
برای پروژهای که ادامه و نگهداری آن برای کارفرما مهم است، مالکیت یا کنترل سازمانی حساب و مدیران آن باید از ابتدا یا در زمانبندی انتقال روشن باشد. صرف داشتن یک عضو در مخزن کافی نیست.
چگونه باگ را از درخواست تغییر جدا کنیم؟
اگر نتیجه با معیار پذیرش مصوب متفاوت باشد، معمولاً باگ است. اگر معیار رعایت شده اما رفتار جدیدی مطلوب است، درخواست تغییر محسوب میشود و باید اثر، زمان و هزینهاش جدا بررسی شود.
آیا این راهنما جای نمونه قرارداد است؟
خیر. این راهنما فهرست موضوعهایی است که باید روشن شوند. متن حقوقی نهایی باید با نوع کسبوکار، روش همکاری، داراییها و مقررات مرتبط توسط متخصص حقوقی بررسی شود.
خدمت و راهنماهای مرتبط
برای ادامه مسیر، صفحه خدمت مرتبط، نمونهکار و راهنماهای مکمل را ببینید.
منابع و مبنای تدوین
این راهنما با استفاده از مستندات فنی و منابع تخصصی زیر تدوین شده است. تصمیم نهایی هر پروژه باید با دادهها، قرارداد و شرایط واقعی همان سازمان تطبیق داده شود.