۱۰ نکته حیاتی حقوقی در قراردادهای طراحی اپلیکیشن و بازی
ضروریترین بندهای قرارداد طراحی اپلیکیشن و بازی
شفافسازی محدوده پروژه (Project Scope)
دقیقاً مشخص کنید چه چیزی میخواهید. جملات کلی مثل «یک اپلیکیشن شبیه اسنپ» خطرناکترین نوع توافق هستند. تمام ویژگیها، تعداد صفحات، منوها و حتی فرآیندهای جزئی باید به صورت پیوست فنی (RFP) مکتوب شوند تا طراح نتواند بابت هر تغییر کوچک، هزینهی اضافی مطالبه کند.
یک استارتاپ با طراح قرارداد میبندد که فقط میگوید: "یک اپلیکیشن رزرو سفر درست کن". پس از 2 هفته، طراح میگوید: "چت لایو در نظر نگرفتم" یا "سیستم پرداخت برای 5 درگاه مختلف در Scope نبود". حالا کارفرما یا باید بدون این ویژگیها قبول کند یا 50 میلیون تومان اضافی بپردازد!
زمانبندی مرحلهای (Milestones)
پروژه را به فازهای کوچک تقسیم کنید (مثلاً: طراحی ظاهر، کدنویسی سمت سرور، نسخه آزمایشی). برای هر فاز یک تاریخ تحویل دقیق تعیین کنید. این کار باعث میشود کنترل پروژه از دست شما خارج نشود و پیشرفت کار قابل اندازهگیری باشد.
یک بازی موبایل با مدت زمان 6 ماه. بدون milestoneهای واضح، در ماه سوم فکر میکنید کار هنوز در مرحلهی طراحی است! اما اگر milestoneها مشخص باشند (الف) طراحی UX - 20 مهر، ب) کدنویسی سمت کلاینت - 20 آبان، ج) نسخه آزمایشی - 20 آذر)، میتوانید درست کنید که کار به موقع است یا تأخیر دارد.
مدل پرداخت متناسب با پیشرفت
هرگز کل مبلغ یا بخش بزرگی از آن را در ابتدا پرداخت نکنید. بهترین روش، پرداختهای مرحلهای پس از تأیید هر فاز است. همیشه بخشی از مبلغ (مثلاً ۲۰ درصد) را برای مرحلهی «تحویل نهایی و رفع باگهای احتمالی» نگه دارید.
کارفرمایی 100 میلیون تومان کار سفارش میدهد و 75 میلیون را از فوری میپردازد! بعد از 3 ماه، طراح دلایلی میآورد و کار تکمیل نمیکند. اما کارفرما تقریباً تمام پول را داده است. نهتنها نمیتواند درست کند که کار به موقع است یا نیست، بلکه باید 6 ماه دیگر منتظر بماند. نهتنها نمیتواند درست کند که کار به موقع است یا نیست، بلکه باید 6 ماه دیگر منتظر بماند. اگر پرداخت مرحلهای بود (25 میلیون شروع، 25 میلیون بعد از طراحی، 25 میلیون بعد از کدنویسی، 25 میلیون نهایی)، میتوانست سهم خود را حفظ کند.
حقوق مالکیت در قرارداد طراحی اپلیکیشن و بازی
در قرارداد صراحتاً ذکر کنید که پس از تسویه حساب، «سورس کد»، فایلهای گرافیکی، پایگاه داده و تمام متعلقات پروژه، متعلق به کارفرماست. بدون این بند، شما فقط اجازه استفاده از اپلیکیشن را دارید و مالک واقعی آن نخواهید بود!
یک کسبوکار 15 میلیون تومان برای اپلیکیشن موبایلی میدهد و بعد از 6 ماه، میخواهد برای بازنویسی برخی ویژگیها از یک توسعهدهنده دیگر استفاده کند. اما متوجه میشود که سورس کد مالک طراح قدیم است! نهتنها نمیتواند کد را بررسیکند، بلکه باید دوباره 200 میلیون تومان برای یک اپلیکیشن جدید بپردازد!
تعداد دفعات بازنگری (Revision Policy)
برای جلوگیری از سلیقهای شدن کار، مشخص کنید که در هر مرحله (مثلاً طراحی گرافیک) چند بار حق درخواست تغییر رایگان دارید. این کار هم به نفع شماست و هم باعث میشود طراح با دقت بیشتری کار را پیش ببرد.
یک کارفرما برای طراحی صفحههای اصلی اپلیکیشن با طراح قرارداد میبندد. بدون تعیین تعداد revisionهای رایگان، بعد از 3 هفته، کارفرما 15 بار درخواست تغییر رنگ، فونت و تنظیمات را داشته است! طراح میگوید: "من دیگر برای اینها مسئول نیستم. اگر میخوای رفع کنم، 500 هزار تومان بده!" اما اگر قرارداد میگفت «30 دفعه revision رایگان»، این اختلاف پیش نمیآمد.
ضمانت اجرا و جریمه تأخیر
زمان در بازار تکنولوژی طلاست. اگر طراح بدون دلیل موجه پروژه را دیر تحویل دهد، باید بابت هر روز تأخیر مبلغی به عنوان جریمه از قرارداد کسر شود. این بند، قویترین انگیزه برای تحویل به موقع است.
یک استارتاپ برای رونمایی بازی خود تاریخ 1 فروردین را تعیین کرده و تبلیغات میدهد. اما طراح پروژه را تا 20 فروردین تحویل میدهد! رونمایی تأخیر میخورد و سرمایهگذاران ناراضی میشوند. اگر قرارداد میگفت "جریمه هر روز تأخیر: 10 میلیون تومان"، طراح برنامه ریزی دقیقی برای کار نگه داشت و کار را به موقع تحویل میداد.
فسخ قرارداد و خروج ایمن
شرایطی را پیشبینی کنید که اگر همکاری به بنبست رسید، چگونه میتوانید جدا شوید. در صورت فسخ، طراح موظف است تمام کارهای انجام شده تا آن لحظه را تحویل دهد و تسویه حساب بر اساس حجم کار واقعی انجام شود.
کارفرما و طراح پس از دو ماه از یک پروژه ششماهه دچار سوءتفاهم شدهاند. از آنجا که در قرارداد بندی برای «فسخ» در نظر گرفته نشده، هیچکدام نمیدانند تکلیف چیست. آیا کارفرما باید چهار ماه دیگر منتظر بماند؟ یا طراح باید بدون انجام کار، دستمزد کل شش ماه را دریافت کند؟ اگر در قرارداد ذکر شده بود که «در صورت فسخ، کارفرما میتواند ۴۰٪ از مبلغ کل را نگه دارد و ۶۰٪ به طراح تعلق میگیرد»، این اختلاف بهسادگی حل میشد.
پشتیبانی و رفع خطای پس از تحویل
اپلیکیشن بدون باگ وجود ندارد! قرارداد باید شامل یک دوره پشتیبانی رایگان (مثلاً ۳ تا ۶ ماه) برای رفع خطاهای احتمالی باشد. همچنین هزینه پشتیبانی و توسعههای آتی را از همین حالا پیشبینی کنید.
یک اپلیکیشن رزرو غذا وارد بازار میشود. دو ماه بعد، برخی از کاربران نمیتوانند از درگاه پرداخت استفاده کنند. کارفرما انتظار دارد طراح بدون دریافت هزینه اضافی این باگ را برطرف کند، اما طراح میگوید دیگر مسئولیتی در قبال پروژه ندارد و برای رفع مشکل ۵ میلیون تومان درخواست میکند. اگر در قرارداد ذکر شده بود که «۶ ماه پشتیبانی رایگان برای رفع خطاهای احتمالی ارائه میشود»، این اختلاف اصلاً شکل نمیگرفت.
معیارهای پذیرش (Acceptance Criteria)
مشخص کنید پروژه چه زمانی «تمام شده» تلقی میشود. مثلاً: اجرای بدون خطا در آخرین نسخه اندروید و iOS، سرعت لود زیر ۳ ثانیه و پاس کردن تستهای امنیتی. بدون این معیارها، تعبیر طراح از «پایان کار» با تعبیر شما متفاوت خواهد بود.
طراح اپلیکیشن یک بازی رقابتی پروژه را تحویل میدهد و اعلام میکند کار تمام شده است. اما کارفرما متوجه میشود که برنامه روی آیفونهای قدیمیتر کرش میکند، تستهای امنیتی را پاس نمیکند و پایگاه داده حتی توان پشتیبانی از ۱۰۰۰ کاربر همزمان را ندارد. طراح میگوید این موارد خارج از تعهدات پروژه بوده، در حالی که کارفرما آنها را جزو معیارهای «قبول نهایی» میداند. اگر در قرارداد مشخص شده بود که «قبول پروژه» شامل اجرا روی تمام دستگاههای iOS 12+ و Android 8+، قبولی در تستهای امنیتی OWASP و پشتیبانی از ۵۰۰۰ کاربر همزمان است، این اختلاف اصلاً بهوجود نمیآمد.
محرمانگی و عدم رقابت (NDA)
ایده و دیتای شما ثروت شماست. طراح باید متعهد شود که اطلاعات پروژه شما را فاش نمیکند و برای مدت مشخصی، پروژه مشابهی برای رقبای مستقیم شما طراحی نخواهد کرد.
یک استارتاپ ایدهای نوآورانه برای اپلیکیشن رزرو اتاقهای کار بدون تماس با مالک را در اختیار یک طراح قرار میدهد. شش ماه بعد، رقبای استارتاپ مانند اسنپ یا شرکتهای مشابه، اپلیکیشنی بسیار نزدیک به همان ایدهها عرضه میکنند. استارتاپ متوجه میشود که طراح، در نقش مشاور فنی، به آن شرکتها کمک کرده است. اگر در قرارداد، توافقنامه عدم افشای اطلاعات (NDA) و بند «عدم رقابت به مدت دو سال» پیشبینی شده بود، این مشکل بهوجود نمیآمد.
هشدار قرمز!
بسیاری از فریلنسرها یا شرکتهای تازهکار ممکن است از قراردادهای آماده اینترنتی استفاده کنند. دقت کنید که این قراردادها اغلب یکطرفه به نفع مجری نوشته شدهاند. هرگز پیش از مطالعه دقیق و شخصیسازی بندها، زیر بار امضا نروید.
مقایسه هوشمندانه
| ویژگی | در یک قرارداد حرفهای | در یک قرارداد ضعیف |
|---|---|---|
| تعهدات مجری | لیست دقیق تمام قابلیتهای فنی | عبارات مبهم مثل «طراحی طبق نظر کارفرما» |
| زمان تحویل | تاریخ شمسی دقیق برای هر فاز | «بسته به حجم کار تعیین میشود» |
| سورس کد | تحویل کامل فایلهای لایه باز و کد | فقط تحویل فایل نصبی (APK/IPA) |
| تغییرات | تعیین نرخ مشخص برای کارهای اضافه | درگیری مداوم بر سر قیمت کارهای جدید |
چکلیست نهایی قبل از امضا
یک نکته طلایی: طراحان و شرکتهای معتبر، نه تنها از قرارداد محکم نمیترسند، بلکه خودشان مشتاق آن هستند. قرارداد شفاف، از حقوق مجری هم در برابر درخواستهای بیپایان و غیرمنطقی محافظت میکند. پس شفافیت را نشانه حرفهایگری بدانید.
نظرات