نکات مهم در قرارداد طراحی سایت؛ چک‌لیست کارفرما قبل از امضا

۲۶ شهریور ۱۴۰۵

نکات مهم در قرارداد طراحی سایت به سه بند برمی‌گردد: دامنه به نام خود شما ثبت شود، همهٔ دسترسی‌ها و کد نهایی بعد از تسویه تحویل شما شود، و مرز «پشتیبانی رایگان» با «کار جدید» روشن باشد. بقیهٔ بندها، از زمان تحویل تا فسخ، با یک سؤال سنجیده می‌شوند: اگر فردا پیمانکار در دسترس نبود، سایت شما از کجا ادامه پیدا می‌کند؟

بیشتر نمونه‌قراردادهای اینترنتی از دید پیمانکار نوشته شده‌اند. کار شما پیدا کردن جای خالی و خواستن جملهٔ مشخص برای هر بند ضعیف است.

نکات مهم در قرارداد طراحی سایت در یک جدول ده‌دقیقه‌ای

قرارداد را ردیف‌به‌ردیف با این جدول بسنجید. ستون دوم جمله‌ای است که در نگاه اول ایرادی ندارد؛ ستون سوم جایگزینی است که کتبی درخواست می‌کنید. ردیفی که در قرارداد شما اصلاً نیامده، از ردیف ضعیف خطرناک‌تر است.

بند جملهٔ ضعیف جملهٔ قابل قبول اگر نباشد
دامنه «پیمانکار دامنه را تهیه می‌کند.» «دامنه با مشخصات کارفرما به‌عنوان دارنده و رابط اداری ثبت می‌شود.» اینماد و تمدید دامنه به پیمانکار گره می‌خورد.
هاست و دسترسی‌ها «هاست یک‌ساله در اختیار کارفرما قرار می‌گیرد.» «حساب هاست به نام کارفرماست و دسترسی مدیر کل در روز تحویل داده می‌شود.» بدون پیمانکار نه می‌توانید بکاپ کامل بگیرید، نه هاست را عوض کنید.
کد و فایل‌ها «مالکیت طرح پس از تسویه با کارفرماست.» «کد سفارشی، فایل‌های طراحی و دیتابیس پس از تسویه با همهٔ حقوق مادی تحویل کارفرما می‌شود.» روشن نیست «طرح» کد را هم شامل می‌شود؛ پیمانکار بعدی ممکن است از صفر شروع کند.
لایسنس قالب و افزونه اغلب اصلاً نیامده. «لایسنس‌های تجاری با حساب کاربری کارفرما خریداری می‌شوند.» بعد از جدایی، به‌روزرسانی و وصلهٔ امنیتی نمی‌گیرید.
زمان تحویل و تأخیر «سایت حداکثر دو ماه پس از امضا تحویل می‌شود.» «زمان‌بندی مرحله‌ای؛ مدت تأخیر کارفرما به مهلت اضافه می‌شود؛ جریمهٔ دوطرفه با سقف.» دعوا بر سر اینکه تأخیر تقصیر چه کسی بود.
پذیرش و اصلاحات «اصلاحات تا رضایت کامل کارفرما انجام می‌شود.» «تعداد مشخص نوبت اصلاح در هر مرحله؛ تغییر خارج از شرح خدمات با برآورد کتبی.» «رضایت» سنجیدنی نیست؛ پروژه یا تمام نمی‌شود یا با دلخوری تمام می‌شود.
پشتیبانی «شش ماه پشتیبانی رایگان.» «رفع ایراد، نگهداری و توسعه جدا تعریف شده، با زمان پاسخ و هزینهٔ تمدید.» هر درخواست بعد از تحویل به بحث «رایگان است یا نه» می‌رسد.
فسخ «در صورت تخلف، طرف مقابل حق فسخ دارد.» «هنگام فسخ، کار انجام‌شده و همهٔ دسترسی‌ها در مهلت مشخص تحویل و مرحلهٔ جاری تسویه می‌شود.» پول چند مرحله را داده‌اید و چیزی در دست ندارید.

سه ردیف اول غیرقابل‌مذاکره‌اند: دامنه، دسترسی‌ها و کد. درصد پیش‌پرداخت، مدت پشتیبانی رایگان یا نام طراح در پایین صفحه را می‌شود چانه زد؛ مالکیت آنچه پولش را می‌دهید را نه.

مالکیت دامنه: به نام شما، نه با شناسهٔ پیمانکار

طبق موافقت‌نامهٔ ثبت دامنهٔ ir. در سایت ایرنیک، مالک دامنه «دارنده» است، یعنی کسی که دامنه به نام او ثبت شده. رابط اداری طرف مکاتبات و درخواست‌هاست و رابط فنی سرور نام را نگهداری می‌کند؛ انتقال به دارندهٔ دیگر هم فقط طبق رویهٔ ایرنیک و با پرداخت هزینهٔ انتقال ممکن است.

این تفاوت اول در اینماد خودش را نشان می‌دهد: طبق راهنمای اینماد در سایت پرتال، نماد اعتماد فقط به کسی داده می‌شود که دامنه به اسم او ثبت شده. فرض کنید یک فروشگاه لوازم آرایشی در اصفهان سه سال پیش سایتش را سفارش داده و طراح، دامنهٔ ir. را با اطلاعات خودش ثبت کرده. حالا فروشگاه برای راه‌اندازی سایت فروشگاهی اینماد می‌خواهد و طراح جواب نمی‌دهد؛ تغییر دارنده ممکن است، ولی مدرک و زمان می‌خواهد و فروش آنلاین تا آن وقت عقب می‌افتد.

جای دوم تمدید است. طبق دستورالعمل تمدید ایرنیک، دامنهٔ منقضی‌شده غیرفعال می‌شود و ۳۰ روز می‌شود با پرداخت هزینهٔ تمدید فعالش کرد. بعد قفل می‌شود و ۳۰ روز دیگر فقط با جریمه‌ای برابر هزینهٔ یک سال تمدید، علاوه بر خود تمدید، باز می‌شود و پس از آن تعلیق. صورت‌حساب تمدید را رابط اداری از پنلش درخواست می‌کند؛ اگر رابط اداری پیمانکاری باشد که جواب نمی‌دهد، این دو ماه زود می‌گذرد.

پس در بند دامنه، شما دارنده و رابط اداری باشید و پیمانکار در صورت نیاز فقط رابط فنی. برای دامنهٔ بین‌المللی مثل com. بنویسید دامنه در حساب کاربری خود کارفرما نزد شرکت ثبت‌کننده ثبت می‌شود. بعد از ثبت، مشخصات دارنده را خودتان در Whois ببینید.

مالکیت کد، فایل‌ها و لایسنس‌ها

پیش‌فرض قانون به نفع شماست. بند «ب» مادهٔ ۶ قانون حمایت از حقوق پدیدآورندگان نرم‌افزارهای رایانه‌ای (مصوب ۱۳۷۹) می‌گوید وقتی پدید آوردن نرم‌افزار موضوع قرارداد است، حقوق مادی و «حق تغییر و توسعهٔ» آن متعلق به کارفرماست، «مگر این که در قرارداد به صورت دیگری پیش‌بینی شده باشد». پس خطر اصلی نبودن بند مالکیت نیست؛ بندی است که همین پیش‌فرض را برعکس یا کوچک کند.

مثلاً در نمونه‌قرارداد طراحی سایتی که وبلاگ راست‌چین منتشر کرده، کارفرما هزینهٔ همهٔ طرح‌های پیشنهادی را می‌دهد ولی فقط مالک طرح انتخاب‌شده است. چنین متنی حق شما را به یک طرح محدود می‌کند و دربارهٔ کد ساکت می‌ماند. به پیش‌فرض قانون تکیه نکنید؛ صریح بنویسید چه تحویل می‌شود: کد سفارشی، فایل‌های لایه‌باز طراحی، دیتابیس و محتوا.

دو خواستهٔ پیمانکار معمولاً منطقی است: استفادهٔ دوباره از کتابخانه‌های عمومی خودش و آوردن نام پروژه در نمونه‌کارهایش. این‌ها را با مالکیت کد اختصاصی سایت شما مخلوط نکنید. شکل تحویل به مسیر ساخت برمی‌گردد؛ تفاوت دو مسیر را در مقالهٔ وردپرس یا برنامه‌نویسی اختصاصی نوشته‌ایم.

سایت وردپرسی: لایسنس را با حساب چه کسی بخرید

هستهٔ وردپرس طبق صفحهٔ مجوز wordpress.org متن‌باز و تحت مجوز GPL است، ولی قالب و افزونهٔ تجاری به‌روزرسانی و پشتیبانی را از راه لایسنس فروشنده می‌گیرد. مثلاً در راست‌چین هر خرید فقط روی یک دامنه فعال می‌شود، تغییر دامنه تا پنج بار از حساب کاربری خریدار ممکن است و پشتیبانی رایگان شش ماه است. اگر لایسنس با حساب پیمانکار خریده شود، هر تغییر دامنه و هر نسخهٔ تازه به او وابسته می‌ماند. بند پیشنهادی: «قالب و افزونه‌های تجاری با حساب کاربری کارفرما خریداری می‌شوند و فهرستشان پیوست قرارداد است.»

برنامه‌نویسی اختصاصی: «تحویل کد» دقیقاً یعنی چه

اگر سایت یا پنل با برنامه‌نویسی اختصاصی ساخته می‌شود، یک فایل فشرده در روز آخر «تحویل کد» نیست. دسترسی به مخزن کد با تاریخچهٔ تغییرات، نسخهٔ کامل دیتابیس، توضیح نصب روی سرور تازه و فهرست سرویس‌های بیرونی (پیامک، درگاه، نقشه) را بخواهید. آزمونش ساده است: برنامه‌نویس دیگری بتواند فقط با همین تحویلی‌ها سایت را روی سرور دیگری بالا بیاورد.

هاست و دسترسی‌ها: فهرست تحویلی‌ها را در قرارداد بنویسید

«دسترسی‌ها تحویل می‌شود» معیار نیست، چون یک کاربر محدود هم دسترسی است. این فهرست را پیوست قرارداد کنید و قسط آخر را به تحویل کامل آن گره بزنید:

  • دسترسی مدیر کل هاست یا سرور، نه فقط یک کاربر FTP؛ بدون آن نمی‌توانید سایت را به هاست دیگری ببرید.
  • دسترسی پنل دامنه (پنل ایرنیک یا حساب شرکت ثبت‌کننده)؛ برای تمدید و تغییر DNS لازمش دارید.
  • کاربر مدیر سایت با بالاترین سطح؛ در وردپرس نقش Administrator، چون «ویرایشگر» نمی‌تواند افزونه‌ها را مدیریت کند.
  • بکاپ کامل فایل‌ها و دیتابیس در روز تحویل، روی حافظه‌ای که دست خودتان است؛ نسخهٔ مرجع برای وقتی چیزی خراب شد یا اختلافی پیش آمد.
  • Search Console و آنالیتیکس با ایمیل کسب‌وکار شما به‌عنوان مالک؛ دادهٔ بازدید و ایندکس نباید با عوض شدن پیمانکار از دست برود.
  • حساب درگاه پرداخت و پنل پیامک به نام کسب‌وکار خودتان؛ پول مشتری و پیامک تأیید سفارش نباید از حساب شخص دیگری بگذرد.
  • مستندات کوتاه: فهرست افزونه‌ها و سرویس‌های بیرونی، روش بکاپ‌گیری و محل نگهداری رمزها.

زمان تحویل و جریمهٔ تأخیر: عددی که واقعاً اجرا شود

یک تاریخ نهایی برای کل پروژه جای دعوا باز می‌گذارد، چون بخشی از تأخیر از طرف کارفرماست: محتوا دیر می‌رسد یا تأیید طرح دو هفته روی میز مدیرعامل می‌ماند. زمان‌بندی را مرحله‌ای بنویسید (طرح، اجرا، ورود محتوا، تست، انتشار) و قید کنید مدت تأخیر کارفرما به مهلت پیمانکار اضافه می‌شود. مهلت تأیید شما هم عدد بخواهد؛ در نمونه‌قرارداد راست‌چین چهار روز کاری آمده. اگر پروژه به اسفند و فروردین می‌خورد، روشن کنید تعطیلات نوروز جزء روز کاری است یا نه.

دربارهٔ جریمه، مادهٔ ۲۳۰ قانون مدنی می‌گوید اگر مبلغی به‌عنوان خسارت تخلف شرط شده باشد، دادگاه نمی‌تواند متخلف را به بیشتر یا کمتر از آن محکوم کند؛ عددی که امضا می‌کنید همان است که می‌گیرید یا می‌دهید.

در یکی از راهنماهای پرجستجوی قرارداد طراحی سایت «کاهش ۵٪ از هزینهٔ نهایی به ازای هر روز تأخیر» آمده که بعد از ۲۰ روز کل مبلغ را صفر می‌کند؛ چنین عددی یا مذاکره را به بن‌بست می‌رساند یا به دعوا ختم می‌شود. جریمهٔ قابل اجرا متناسب با مبلغ همان مرحله است، سقف دارد و دوطرفه است.

پرداخت را به تحویل هر مرحله گره بزنید، نه به تاریخ. در نمونهٔ راست‌چین ۵۰٪ پیش‌پرداخت، ۳۰٪ بعد از طرح گرافیکی و ۲۰٪ بعد از تحویل نسخهٔ کدنویسی‌شده آمده؛ این درصدها قابل مذاکره‌اند. اجزای مبلغ کل را در مطلب هزینهٔ واقعی طراحی سایت باز کرده‌ایم.

محدودهٔ کار، دفعات اصلاح و پذیرش نهایی

عبارت کلی «طراحی سایت شرکتی» در موضوع قرارداد، سرچشمهٔ بیشتر اختلاف‌های وسط پروژه است. پیوستی به نام «شرح خدمات» بخواهید با فهرست صفحه‌ها، امکانات مشخص (فرم تماس، پرداخت، رزرو، چندزبانه) و اینکه متن و عکس را چه کسی آماده می‌کند. هر چیزی که در این پیوست نیست، در قیمت هم نیست.

برای هر مرحله تعداد نوبت اصلاح را مشخص کنید و بنویسید درخواست تغییر خارج از شرح خدمات کتبی ثبت می‌شود و پیمانکار پیش از اجرا هزینه و زمانش را اعلام می‌کند؛ این جلوی صورت‌حساب غافلگیرکننده در پایان پروژه را می‌گیرد.

«سایت کامل تست می‌شود» معیار پذیرش نیست؛ این‌ها معیارند: صفحه‌ها روی موبایل و دسکتاپ درست نمایش داده شوند، فرم‌ها به ایمیل یا پنل برسند، یک پرداخت آزمایشی روی درگاه واقعی انجام شود، و شما مهلت مشخصی برای اعلام ایراد بعد از تحویل داشته باشید. اگر سرعت سایت برایتان مهم است، ابزار سنجش و عدد هدف را در قرارداد بنویسید؛ «سایت سریع» قابل اندازه‌گیری نیست.

پشتیبانی: رفع ایراد، نگهداری و توسعه را جدا بنویسید

در نمونه‌های رایج، پشتیبانی رایگان از سه ماه تا یک سال دیده می‌شود. ولی عدد بدون تعریف تقریباً بی‌معناست، چون «پشتیبانی» سه کار متفاوت است:

نوع کار شامل چه چیزی رایگان یا پولی
رفع ایراد خطای کاری که تحویل شده: فرمی که ارسال نمی‌کند، صفحه‌ای که در موبایل به‌هم می‌ریزد در دورهٔ تعیین‌شده رایگان؛ بخشی از همان کاری است که پولش را داده‌اید
نگهداری به‌روزرسانی هسته و افزونه‌ها، بکاپ دوره‌ای، پایش امنیت گاهی داخل دورهٔ اول؛ بعد از آن با قرارداد ماهانه یا سالانه
توسعه صفحه یا امکان تازه‌ای که در شرح خدمات نبوده پولی، با برآورد جدا

فرض کنید قرارداد یک کلینیک فقط نوشته «شش ماه پشتیبانی رایگان» و ماه چهارم کلینیک نوبت‌دهی آنلاین می‌خواهد. پیمانکار می‌گوید توسعه است و پولی؛ کلینیک می‌گوید پشتیبانی است. هر دو از دید خودشان حق دارند، چون قرارداد تعریفی نداده.

کنار تعریف بنویسید درخواست از چه راهی ثبت می‌شود (تیکت، ایمیل یا پیام‌رسان) و پاسخ در چه مدتی می‌آید. هزینهٔ تمدید هم از روز اول معلوم باشد؛ در نمونهٔ راست‌چین تمدید سالانه ۲۰٪ مبلغ قرارداد است. سایت وردپرسی که افزونه‌هایش به‌روز نمی‌شود، در برابر حمله‌هایی مثل آنچه در مطلب جلوگیری از حملات SQL در وردپرس آمده آسیب‌پذیرتر است.

قرارداد پشتیبانی سایت جدا لازم است؟

معمولاً بله. دورهٔ رفع ایراد رایگان جزء تحویل است و داخل قرارداد اصلی می‌آید. نگهداری بعد از آن را در قرارداد جدا و قابل فسخ ببندید تا اگر راضی نبودید، بدون درگیری با قرارداد اصلی پیمانکار نگهداری را عوض کنید.

فسخ، محرمانگی و حل اختلاف

بند فسخ در بیشتر نمونه‌ها فقط می‌گوید چه وقت می‌شود فسخ کرد، نه اینکه بعدش چه می‌شود. بنویسید کار انجام‌شده با همهٔ دسترسی‌ها و فایل‌ها ظرف چند روز تحویل می‌شود و پول مرحلهٔ جاری چطور تسویه یا برگردانده می‌شود؛ وگرنه فسخ یعنی از صفر شروع کردن با پیمانکار دیگر.

محرمانگی را دوطرفه بنویسید؛ پیمانکار به اطلاعات مشتریان و سفارش‌های شما دسترسی دارد و تعهد عدم افشا باید بعد از پایان قرارداد هم بماند. برای حل اختلاف، مادهٔ ۴۵۴ قانون آیین دادرسی مدنی اجازه می‌دهد طرفین با توافق، اختلافشان را به داوری یک یا چند نفر بسپارند. نام داور یا روش انتخابش را در خود قرارداد بیاورید؛ «اختلاف به داوری ارجاع می‌شود» به‌تنها، سر انتخاب داور اختلاف تازه‌ای باز می‌کند.

چه وقت قرارداد ساده کافی است و چه وقت وکیل لازم دارید

برای یک سایت معرفی چندصفحه‌ای با قالب آماده، قرارداد ده‌صفحه‌ای لازم نیست. یک توافق‌نامهٔ کوتاه کافی است که پنج بند حیاتی را روشن نوشته باشد: دامنه به نام شما، فهرست دسترسی‌های تحویلی، شرح خدمات، پرداخت مرحله‌ای و تعریف پشتیبانی.

ولی اگر فروشگاه با درگاه پرداخت می‌سازید، نرم‌افزار اختصاصی سفارش می‌دهید، سایت باید به حسابداری یا ERP وصل شود، یا مبلغ قرارداد برای کسب‌وکارتان بالاست، متن را یک حقوق‌دان هم ببیند. این راهنما جای مشاورهٔ حقوقی را نمی‌گیرد؛ کمک می‌کند بدانید از وکیل یا پیمانکار چه بپرسید.

قدم بعدی: پیش از امضا این پنج سؤال را کتبی بپرسید

جواب‌ها را کتبی بگیرید و پیوست قرارداد کنید. سؤالی که جواب روشن نگرفت، همان بندی است که باید پیش از امضا نوشته شود.

  1. دامنه با مشخصات چه کسی به‌عنوان دارنده ثبت می‌شود؟ جواب قابل قبول: کسب‌وکار شما، با رابط اداری خودتان.
  2. قالب، افزونه‌ها و سرویس‌های پولی با حساب چه کسی خریده می‌شوند؟ اگر با حساب پیمانکار، به‌روزرسانی بعدی به او وابسته است.
  3. در روز تحویل دقیقاً چه دسترسی‌هایی می‌دهید؟ جواب را با فهرست بخش هاست و دسترسی‌ها تطبیق دهید.
  4. پشتیبانی رایگان شامل چه چیزی نیست؟ جواب این سؤال از فهرست «شامل چه» روشن‌تر است.
  5. اگر وسط کار جدا شدیم، چه چیزی و در چند روز تحویل می‌دهید؟ جواب مبهم یعنی بند فسخ باید بازنویسی شود.

اگر هنوز پیمانکار را انتخاب نکرده‌اید، همین پنج سؤال را از همهٔ پیشنهاددهنده‌ها بپرسید و جواب‌ها را کنار قیمت‌ها بگذارید. برای شروع نیازسنجی پروژه‌تان با منگو، از صفحهٔ تماس با ما پیام بگذارید.

نمونه قرارداد طراحی سایت را از اینترنت دانلود کنم کافی است؟

به‌عنوان نقطهٔ شروع بله، به‌عنوان متن نهایی نه. بیشتر نمونه‌های پرجستجو را طراح‌ها و فروشگاه‌های قالب نوشته‌اند و مالکیت کد، دسترسی مدیر کل هاست، لایسنس قالب و تحویل هنگام فسخ در آن‌ها نیامده. نمونه را با جدول اول همین مقاله بسنجید.

اگر دامنه به نام طراح ثبت شده، مالکیت را چطور منتقل کنم؟

از راه «تغییر دارنده» در ایرنیک، که مدرک و زمان می‌خواهد. تا طراح در دسترس است و پیش از نزدیک شدن تاریخ انقضا اقدام کنید، چون بعد از انقضا فقط ۳۰ روز فرصت فعال‌سازی عادی دارید و بعد از آن جریمه‌ای برابر هزینهٔ یک سال تمدید اضافه می‌شود.

در قرارداد طراحی سایت فروشگاهی چه بندهای اضافه‌ای لازم است؟

چهار بند: دامنه به نام کسب‌وکار باشد تا اینماد بگیرید، حساب درگاه پرداخت و پنل پیامک به نام خودتان باز شود، پرداخت آزمایشی روی درگاه واقعی جزء معیار پذیرش باشد، و بکاپ دیتابیس سفارش‌ها و مشتریان در نگهداری تعریف شود. اتصال به انبار یا نرم‌افزار حسابداری را هم اگر لازم است از اول در شرح خدمات بیاورید.

طراحی سایت و سئو را در یک قرارداد بیاوریم؟

می‌شود، به شرطی که خروجی و معیار تحویل هر کدام جدا نوشته شود؛ مثلاً ساختار تیترها و آدرس‌ها در طراحی، و تولید محتوا یا گزارش ماهانه در سئو. تعهد «رتبهٔ اول گوگل» را قبول نکنید، چون هیچ پیمانکاری کنترل الگوریتم گوگل را ندارد؛ به‌جایش کارهایی را بنویسید که انجامشان قابل بررسی است.

جریمهٔ تأخیر را چقدر تعیین کنیم؟

عدد استاندارد یا حداقل قانونی برایش نیست و قابل مذاکره است. جریمه را درصدی از مبلغ همان مرحله بنویسید نه کل قرارداد، برای مجموعش سقف بگذارید و همان منطق را برای تأخیر در پرداخت هم اعمال کنید. چون طبق مادهٔ ۲۳۰ قانون مدنی دادگاه مبلغ شرط‌شده را کم یا زیاد نمی‌کند، عددی ننویسید که خودتان حاضر به پرداختش نیستید.

منابع

تاریخ مراجعه به همهٔ منابع: ۲۵ شهریور ۱۴۰۵.

اطلاعات تماس شما

0/600