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