قرارداد فریلنسری؛ از شرح کار و پرداخت تا تحویل و تغییرات پروژه
قراردادها و معاملات
،۸ دقیقه
،تحریریه آرتاداد
«یک سایت ساده می‌خواهیم» یا «چند طرح برای شبکه اجتماعی» برای شروع گفت‌وگو مناسب است، اما برای اداره پروژه کافی نیست. سفارش‌دهنده ممکن است امکاناتی را بدیهی بداند که مجری در قیمت ندیده؛ مجری هم ممکن است تحویل فایل را پایان کار تلقی کند، درحالی‌که طرف مقابل انتظار پشتیبانی دارد. قرارداد فریلنسری باید همین فاصله برداشت‌ها را پیش از شروع کم کند.
چکیده ای از آنچه در این مقاله خواهید آموخت:
پنهان کردن فهرستنمایش فهرست
«یک سایت ساده می‌خواهیم» یا «چند طرح برای شبکه اجتماعی» برای شروع گفت‌وگو مناسب است، اما برای اداره پروژه کافی نیست. سفارش‌دهنده ممکن است امکاناتی را بدیهی بداند که مجری در قیمت ندیده؛ مجری هم ممکن است تحویل فایل را پایان کار تلقی کند، درحالی‌که طرف مقابل انتظار پشتیبانی دارد. قرارداد فریلنسری باید همین فاصله برداشت‌ها را پیش از شروع کم کند.
عنوان فریلنسری به‌تنهایی نوع رابطه را تعیین نمی‌کند
قرارداد خدمات مستقل می‌تواند در چارچوب قواعد عمومی قراردادها بررسی شود، اما نام «فریلنسری» یا «پروژه‌ای» به‌تنهایی برای کنار گذاشتن قانون کار کافی نیست. مواد ۲، ۳ و ۷ قانون کار به رابطه انجام کار در برابر حق‌السعی و طرف‌های آن می‌پردازند. نحوه واقعی همکاری، میزان استقلال، پرداخت و سایر شرایط باید بررسی شود. تعاریف و قرارداد کار در قانون کار (https://nezamat.ir/post-30105/)
این مقاله برای تنظیم عملی همکاری پروژه‌ای است و درباره شمول یا عدم شمول قطعی قانون کار بر هر پروژه حکم نمی‌دهد. اگر حضور مستمر، دستورهای روزانه و رابطه سازمانی دارید، پیش از استفاده از نمونه قرارداد خدمات، ماهیت رابطه را روشن کنید. تکالیف بیمه و مالیات نیز باید متناسب با همان رابطه بررسی شوند.
خروجی را به چیزی قابل مشاهده تبدیل کنید
به‌جای «طراحی حرفه‌ای»، فهرست خروجی‌ها، تعداد، قالب، زبان، کیفیت فنی قابل سنجش و موارد خارج از سفارش را بنویسید. برای نمونه، طراحی ظاهر صفحه با برنامه‌نویسی، ورود محتوا و نگهداری بعدی متفاوت است. در پروژه نوشتن، طول، منابع، مخاطب و مسئول تأیید اطلاعات را مشخص کنید.
اگر نمونه یا فایل مرجع وجود دارد، نسخه و تاریخ آن را در پیوست معرفی کنید. معلوم باشد نمونه فقط جهت بصری یا معیار دقیق پذیرش است. ارجاع مبهم به «مثل فلان سایت» می‌تواند برداشت‌های متفاوت بسازد. دسترسی به یک نمونه نیز به معنی اجازه کپی محتوای متعلق به دیگری نیست.
زمان‌بندی را به همکاری دو طرف وصل کنید
تاریخ شروع و تحویل را همراه پیش‌نیازها مشخص کنید: پرداخت اولیه، دریافت محتوا، تأیید طرح یا دسترسی لازم چه زمانی باید انجام شود؟ اگر سفارش‌دهنده دیر پاسخ دهد یا داده ناقص بدهد، برنامه چگونه بازبینی می‌شود؟ اگر مجری تأخیر کند، چه اطلاعی باید بدهد و چه راه‌حلی بررسی خواهد شد؟
در مواد ۲۱۹ و ۲۲۰ قانون مدنی، الزام به قرارداد معتبر و آثار قانونی و عرفی آن مطرح شده است. برای اجرای قابل پیش‌بینی، بهتر است وابستگی‌های مهم را صریح بنویسید و همه چیز را به برداشت از عرف نسپارید. تغییر برنامه را نیز با تأیید قابل بازیابی ثبت کنید. قواعد عمومی قرارداد در قانون مدنی (https://nezamat.ir/%D9%82%D8%A7%D9%86%D9%88%D9%86-%D9%85%D8%AF%D9%86%DB%8C/)
پرداخت مرحله‌ای و پذیرش مرحله را هماهنگ کنید
مبلغ کل، واحد پول، هزینه‌های جداگانه و زمان هر پرداخت باید روشن باشند. اگر خرید تصویر، دامنه، سرویس یا ابزار لازم است، تعیین کنید چه کسی آن را تهیه می‌کند و مالک حساب مربوط چه کسی خواهد بود. هزینه پیش‌بینی‌نشده را بدون اطلاع قبلی به صورتحساب نهایی اضافه نکنید.
برای هر مرحله، خروجی قابل تحویل و شخص مسئول بررسی را مشخص کنید. تأیید یک مرحله چه معنایی دارد: صرف دریافت، پذیرش ظاهری یا پذیرش فنی؟ بهتر است ایرادها در یک فهرست مشخص و قابل پیگیری اعلام شوند. سکوت مشتری را بدون توافق معتبر و بررسی شرایط، تأیید قطعی همه جزئیات فرض نکنید.
اصلاحات را از تغییر سفارش جدا کنید
رفع ایراد نسبت به شرح کار اولیه با درخواست قابلیت تازه تفاوت عملی دارد. تعداد دورهای اصلاح، روش تجمیع بازخورد و دامنه هر دور را تعریف کنید. اگر خواسته جدید مطرح شد، ابتدا اثر آن بر مبلغ، زمان و خروجی را روشن کنید و بعد شروع به اجرا کنید.
یک نمونه آموزشی: تغییر رنگ یک طرح مطابق راهنمای برند ممکن است در اصلاحات مورد توافق باشد؛ اضافه کردن یک مجموعه طرح جدید یا تغییر کامل هدف پروژه می‌تواند سفارش تازه محسوب شود. نتیجه به متن واقعی قرارداد وابسته است. تعریف روشن از ابتدا، از بحث فرسایشی درباره «تغییر کوچک» جلوگیری می‌کند.
فایل اصلی، حق استفاده و حساب‌ها را فراموش نکنید
تحویل خروجی نهایی، فایل قابل ویرایش، کد منبع و اجازه استفاده از ابزارهای ثالث موضوعات جداگانه‌اند. بنویسید دقیقاً چه فایل‌هایی با چه قالبی تحویل می‌شوند و آیا مستندات و دسترسی‌های مدیریتی هم جزو سفارش است. برای مجوز عکس، فونت، موسیقی یا نرم‌افزار، محدودیت استفاده را بررسی کنید.
درباره حقوق اثر، اجازه تغییر، انتشار در نمونه‌کار و استفاده مجدد از اجزای قبلی توافق روشن داشته باشید. قواعد حقوق مؤلف و نرم‌افزار بسته به نوع اثر و رابطه طرفین متفاوت‌اند؛ پرداخت مبلغ را به‌تنهایی پاسخ تمام پرسش‌های مالکیت ندانید. این راهنما قاعده یکسانی برای انتقال همه حقوق ارائه نمی‌کند.
محرمانگی نیز باید متناسب باشد: چه اطلاعاتی محرمانه‌اند، چه کسی اجازه دسترسی دارد و پس از پایان پروژه چه چیزی باید تحویل، نگهداری یا حذف شود؟ رمزها را در قرارداد یا گروه عمومی ننویسید. دسترسی لازم را محدود و در پایان با هماهنگی بازبینی کنید؛ حذف ناگهانی داده مشتری راه مناسبی برای حل اختلاف مالی نیست.
تأییدهای آنلاین را قابل بررسی نگه دارید
مواد ۱۲ و ۱۳ قانون تجارت الکترونیکی به قابلیت بررسی دلیل الکترونیکی و ارزش اثباتی آن می‌پردازند. پیام تأیید می‌تواند مهم باشد، اما باید معلوم باشد از طرف چه کسی و درباره کدام نسخه ارسال شده است. فایل «نهایی» را چند بار با همان نام جایگزین نکنید؛ شماره نسخه و تاریخ به تطبیق کمک می‌کند.
یک نفر را برای اعلام نظر نهایی معرفی کنید تا نظرهای پراکنده چند همکار، مجری را سرگردان نکند. نامه یا پیام تأیید را کنار نسخه مورد نظر نگه دارید. برای تحویل، فهرست فایل‌ها و موارد باز را ثبت کنید تا دریافت فایل با پذیرش همه تعهدها اشتباه نشود.
برای توقف پروژه هم تصمیم بگیرید
پیش از شروع روشن کنید در توقف توافقی، کار انجام‌شده چگونه ارزیابی می‌شود، پیش‌پرداخت چگونه تسویه خواهد شد و خروجی ناقص چه وضعی دارد. پشتیبانی پس از تحویل، رفع نقص و توسعه جدید را از هم تفکیک کنید. پایان قرارداد لزوماً همه تعهدهای باقی‌مانده مانند تسویه و محرمانگی را به یک شکل از بین نمی‌برد.
اگر حق فسخ یا خسارت قراردادی پیش‌بینی می‌کنید، سبب، شرایط و شیوه اعمال آن باید دقیق و متناسب باشد. قواعد مسئولیت و خسارت در مواد ۲۲۱ به بعد قانون مدنی مطرح‌اند؛ نوشتن جریمه بزرگ بدون تعریف تخلف، راه‌حل مطمئنی نیست. بند آماده را بدون بازبینی حقوقی وارد قرارداد نکنید.
چک‌لیست پیش از شروع
• خروجی و موارد خارج از سفارش روشن‌اند.
• پیش‌نیازها و مسئول ارائه اطلاعات مشخص شده‌اند.
• مبلغ و پرداخت‌ها به مراحل قابل تشخیص وصل‌اند.
• معیار پذیرش و مسئول تأیید معلوم است.
• تغییر سفارش و اصلاحات فرایند جدا و روشن دارند.
• فایل‌های اصلی، مجوز استفاده و دسترسی‌ها تعیین تکلیف شده‌اند.
• توقف، تسویه و پشتیبانی بعدی بررسی شده‌اند.
پرسش‌های متداول
آیا توافق در پیام‌رسان کافی است؟
امکان استناد باید با توجه به موضوع، کامل بودن توافق و انتساب پیام بررسی شود. برای پروژه مهم، داشتن متن منظم و تأیید روشن، ابهام را کمتر می‌کند.
پیش‌پرداخت در صورت توقف همیشه باید کامل برگردد؟
حکم واحدی ندارد. علت توقف، متن قرارداد، کار انجام‌شده و مبنای دریافت مبلغ باید بررسی شوند.
آیا هر درخواست مشتری شامل قیمت اولیه است؟
دامنه توافق تعیین‌کننده است. تغییر را پیش از اجرا ثبت کنید و درباره اثر مالی و زمانی آن توافق روشن داشته باشید.
مجری می‌تواند پروژه را در نمونه‌کار منتشر کند؟
باید اجازه انتشار، حقوق اثر، محرمانگی و اطلاعات اشخاص بررسی شوند. بهتر است محدوده مجاز از ابتدا مشخص شود.
بازبینی قرارداد پروژه
برای بررسی قرارداد با آرتاداد، شرح کار و پیشنهاد قیمت را همراه متن توافق آماده کنید. بسیاری از ابهام‌های حقوقی از ناهماهنگی این اسناد شروع می‌شوند.
منابع و دامنه مطلب
• قانون مدنی؛ متن بازنشرشده (https://nezamat.ir/%D9%82%D8%A7%D9%86%D9%88%D9%86-%D9%85%D8%AF%D9%86%DB%8C/)؛ مواد ۱۰، ۲۱۹ تا ۲۳۰؛ نظامات؛ پایگاه غیردولتی بازنشر قوانین
• قانون کار؛ متن بازنشرشده (https://nezamat.ir/post-30105/)؛ مواد ۲، ۳ و ۷؛ نظامات؛ پایگاه غیردولتی بازنشر قوانین
• قانون تجارت الکترونیکی؛ متن فارسی (https://natlex.ilo.org/dyn/natlex2/natlex2/files/download/91708/IRN91708.pdf)؛ مواد ۱۲ و ۱۳؛ NATLEX، سازمان بین‌المللی کار
تاریخ مراجعه به منابع: ۱۵ اکتبر ۲۰۲۶. این مطلب برای آشنایی عمومی با حقوق ایران تهیه شده است. متن بازنشرشده قوانین ممکن است همه تغییرات بعدی را یکجا نشان ندهد؛ در اقدام حقوقی، متن معتبر، مقررات خاص و شرایط پرونده باید بررسی شود.
آیین دادرسی و ادله اثبات
آیین دادرسی و ادله اثبات
آیین دادرسی و ادله اثبات
آیین دادرسی و ادله اثبات
قراردادها و معاملات
هنوز دیدگاهی منتشر نشده است؛ شما آغازگر این گفت‌وگو باشید.