قرارداد طراحی سایت؛ مفاد مهم و نمونه قرارداد Word
یک قرارداد طراحی سایت حرفهای فقط مبلغ، تاریخ تحویل و مشخصات طرفین را ثبت نمیکند. باید روشن کند دقیقاً چه سایتی با چه امکاناتی ساخته میشود، چه کارهایی خارج از پروژه هستند، مسئولیت هر طرف چیست، اصلاحات تا کجا ادامه دارند، درخواست قابلیت جدید چگونه مدیریت میشود، خروجی چه زمانی پذیرفتهشده محسوب میشود و پس از پایان پروژه چه فایلها، حسابها و دسترسیهایی باید تحویل داده شوند.
در این راهنما، مفاد مهم قرارداد را از زاویه همین ابهامهای واقعی بررسی میکنیم و در ادامه نیز یک نمونه قرارداد طراحی سایت کامل و قابل شخصیسازی میآید. نسخه Word همین نمونه نیز برای دانلود در دسترس خواهد بود تا بخشهای متغیر آن متناسب با پروژه واقعی تکمیل شوند. برای پروژههای پیچیده، پرارزش یا دارای شرایط حقوقی خاص، نمونه عمومی جای بررسی اختصاصی قرارداد را نمیگیرد.
قرارداد طراحی سایت باید دقیقاً چه چیزهایی را روشن کند؟
قرارداد زمانی واقعاً کارآمد است که دو طرف برای فهمیدن معنی توافق مجبور نباشند به حافظه، تماسهای قبلی یا پیامهای پراکنده رجوع کنند. عبارتهایی مثل «طراحی سایت فروشگاهی»، «پشتیبانی کامل» یا «اصلاحات تا تأیید کارفرما» در ظاهر روشناند، اما ممکن است برای مجری و کارفرما معنای یکسانی نداشته باشند.
پیش از امضا، حداقل باید پنج مرز مشخص باشد: چه چیزی ساخته میشود، چه چیزی ساخته نمیشود، چه چیزی اصلاح محسوب میشود، خروجی در چه شرایطی پذیرفته میشود و پس از تحویل چه مسئولیتی بر عهده هر طرف باقی میماند.
| موضوع | چیزی که باید روشن شود | محل مناسب ثبت |
|---|---|---|
| محدوده پروژه | صفحات، امکانات، خروجیها و موارد خارج از پروژه | قرارداد + پیوست فنی |
| زمان | شروع، وابستگیها، مهلتها و تحویل | قرارداد |
| تغییرات | مرز اصلاح، رفع نقص و قابلیت جدید | قرارداد + درخواست تغییر |
| پذیرش و تحویل | معیار پذیرش و اقلام قابل تحویل | قرارداد + پیوست |
| مالکیت و دسترسی | وضعیت هر دارایی و حساب پس از پروژه | قرارداد |
در حقوق ایران، ماده ۱۰ قانون مدنی قراردادهای خصوصی را در صورتی که مخالف صریح قانون نباشند نافذ میداند. این مبنا به معنی وجود یک قالب واحد و اجباری برای همه قراردادهای طراحی سایت نیست؛ مفاد قرارداد باید با شرایط واقعی همان پروژه و سایر مقررات قابل اعمال هماهنگ شود. ماده ۱۰ قانون مدنی
قبل از امضا، محدوده پروژه را دقیق مشخص کنید
یکی از مهمترین منشأهای اختلاف در پروژههای وب این است که کارفرما و مجری تعریف یکسانی از «طراحی سایت» ندارند. کارفرما ممکن است تصور کند هر قابلیتی که در طول پروژه به ذهنش برسد بخشی از مبلغ اولیه است، در حالی که مجری قیمت را براساس امکانات مشخصی محاسبه کرده است.
این مشکل با یک جمله حقوقی پیچیده حل نمیشود؛ باید محدوده کار (Scope) بهاندازه کافی روشن باشد.
موضوع قرارداد با شرح خدمات یکی نیست
موضوع قرارداد میتواند چنین باشد:
«طراحی و پیادهسازی وبسایت فروشگاهی کارفرما»
اما این جمله هنوز نمیگوید سایت دقیقاً چه خروجیهایی دارد. شرح خدمات باید موضوع کلی را به موارد قابل تشخیص تبدیل کند: چه نوع صفحاتی طراحی میشوند، چه قابلیتهایی وجود دارد، ورود محصول با چه کسی است، آیا اتصال به درگاه یا سرویس دیگری انجام میشود و مهاجرت اطلاعات سایت قبلی داخل پروژه هست یا خیر.
هرچه پروژه پیچیدهتر شود، ریختن تمام جزئیات در یک ماده طولانی قرارداد کاربرد کمتری دارد. در این شرایط بهتر است قرارداد اصلی به پیوست فنی یا شرح خدمات ارجاع دهد.
پیوست فنی چه چیزهایی را مشخص میکند؟
محتوای پیوست به نوع پروژه بستگی دارد. یک سایت شرکتی ساده با فروشگاهی که به چند سامانه خارجی متصل میشود، پیوست یکسانی ندارد.
در صورت ارتباط، پیوست میتواند موارد زیر را روشن کند:
- صفحات یا قالبهای صفحه مورد توافق؛
- امکانات اصلی هر بخش؛
- وضعیت طراحی واکنشگرا؛
- فرمها و فرایندهای کاربری؛
- سرویسها و اتصالهای خارجی؛
- انتقال یا ورود اطلاعات؛
- تعداد محصول، مقاله یا دادهای که ورود آن بر عهده مجری است؛
- زبانهای سایت؛
- خروجیهای طراحی و توسعه؛
- معیارهای فنی مهم برای پذیرش پروژه.
قرارداد اصلی رابطه دو طرف را تنظیم میکند؛ پیوست فنی توضیح میدهد دقیقاً قرار است چه چیزی ساخته شود.
موارد خارج از محدوده را هم بنویسید
تعریف پروژه فقط با نوشتن کارهایی که انجام میشوند کامل نیست. گاهی مشخصکردن موارد خارج از محدوده میتواند از یک اختلاف بزرگ جلوگیری کند.
اگر قرارداد فقط برای طراحی و راهاندازی سایت است، روشن کنید آیا خدماتی مانند سئو، تولید محتوا، ورود مستمر محصول، طراحی لوگو، مدیریت سایت، پشتیبانی بلندمدت یا توسعه قابلیتهای آینده جزو مبلغ هستند یا خیر.
بعد از راهاندازی سایت نیز معمولاً کار محتوایی تازه آغاز میشود. برای ساخت صفحات هدف، گسترش پوشش موضوعی، لینکسازی داخلی و تقویت سئوی محتوایی ممکن است به مقالات تازه نیاز باشد. اگر تولید محتوا داخل قرارداد طراحی سایت نیست، خرید محتوای آماده از اکسپرونال میتواند یکی از گزینههای تأمین محتوا باشد. اکسپرونال محتوای آماده را با تمرکز بر نگارش و اصول سئو عرضه میکند و طبق مدل فروش اعلامشده این مجموعه، هر فایل آماده فقط به یک خریدار فروخته میشود. برای طراحی ارتباط موضوعی میان صفحات نیز مطالعه تاپیک کلاستر چیست میتواند مکمل این موضوع باشد.
مفاد قرارداد طراحی سایت؛ بندهایی که باید دقیق باشند
یک متن قرارداد طراحی سایت حرفهای معمولاً چند محور اصلی دارد، اما کیفیت قرارداد با تعداد مواد آن سنجیده نمیشود. هر بند باید ابهام مشخصی را برطرف کند.
مشخصات طرفین و اختیار امضا
نام شخص حقیقی یا حقوقی، اطلاعات شناسایی و راههای ارتباطی لازم باید طوری ثبت شوند که مشخص باشد طرف قرارداد دقیقاً چه کسی است.
اگر یکی از طرفین شرکت یا شخص حقوقی است، بهتر است سمت شخص امضاکننده و مبنای اختیار او نیز متناسب با وضعیت واقعی روشن باشد.
کانال رسمی مکاتبات هم اهمیت دارد. اگر تأیید یک مرحله، اعلام ایراد یا درخواست تغییر از طریق ایمیل، سامانه مدیریت پروژه یا روش دیگری انجام میشود، بهتر است از ابتدا مشخص باشد کدام مسیر برای مکاتبات قراردادی پذیرفته شده است.
قانون تجارت الکترونیکی ایران «دادهپیام» و امضای الکترونیکی را شناسایی کرده است. ماده ۷ میگوید هرجا قانون وجود امضا را لازم بداند، امضای الکترونیکی کفایت میکند؛ با این حال، قانون برای «امضای الکترونیکی مطمئن» در ماده ۱۰ شرایط مشخصتری تعیین کرده است. بنابراین نباید هر پیام عادی در یک پیامرسان را بدون توجه به شرایط و اوضاع پرونده، خودکار معادل امضای الکترونیکی مطمئن دانست. قانون تجارت الکترونیکی
زمانبندی، مسئولیتها و وابستگیهای پروژه
صرف نوشتن «مدت اجرای پروژه ۳۰ روز است» کافی نیست اگر معلوم نباشد این مدت از چه زمانی شروع میشود.
ممکن است شروع واقعی کار وابسته به پرداخت مرحله اول، تحویل محتوای اولیه، تهیه هاست، دسترسی به دامنه یا تأیید طرح باشد. اگر کارفرما یکی از این موارد را دیر تحویل دهد، بخشی از برنامه مجری نیز تحت تأثیر قرار میگیرد.
بهتر است قرارداد روشن کند:
- پروژه از چه زمانی شروع میشود؛
- چه اطلاعات و دسترسیهایی پیشنیاز شروعاند؛
- هر مرحله چه وابستگیهایی دارد؛
- کارفرما چه زمانی باید خروجی را بررسی کند؛
- تأخیر در ارائه محتوا یا تأیید چه اثری بر برنامه دارد؛
- تأخیر مجری در انجام تعهد خودش چگونه مدیریت میشود؛
- تحویل نهایی بر چه مبنایی تعیین میشود.
عدد ثابت و مناسبی برای همه پروژهها وجود ندارد. مدت باید براساس حجم و ماهیت همان پروژه تعیین شود.
مبلغ، پرداخت و هزینههای خارج از قرارداد
اگر پرداخت مرحلهای است، فقط درصد هر قسط را ننویسید؛ مشخص کنید هر پرداخت بعد از چه رویدادی سررسید میشود.
مثلاً یک مرحله پرداخت میتواند به شروع پروژه، تأیید طرح، تکمیل بخش مشخصی از کار یا پذیرش خروجی وابسته باشد. درصد مراحل نیز باید حاصل توافق واقعی باشد، نه عددی که از یک نمونه قرارداد دیگر کپی شده است.
هزینههای شخص ثالث نیز بهتر است جدا شوند. مواردی مانند دامنه، هاست، قالب تجاری، افزونه پولی، سرویس پیامک، API، ابزار ایمیل یا اشتراک سرویس خارجی ممکن است داخل مبلغ مجری باشند یا جداگانه پرداخت شوند.
اگر مالیات، عوارض یا کسورات قانونی براساس وضعیت واقعی طرفین قابل اعمال است، قرارداد باید تکلیف آنها را روشن کند؛ اما یک نمونه عمومی نباید نرخ یا تکلیف خاصی را به همه پروژهها تعمیم دهد.
اصلاح، رفع باگ و تغییر محدوده را یکی نکنید
عبارت «اصلاحات تا تأیید کامل کارفرما» میتواند یکی از مبهمترین بخشهای قرارداد باشد، چون کلمه «اصلاح» چند معنای متفاوت پیدا میکند.
خطا یا باگ (Bug): خروجی با چیزی که قبلاً توافق شده منطبق نیست.
بازبینی (Revision): تغییر محدود در همان خروجی و داخل محدوده توافقشده.
تغییر نیاز: تصمیم قبلی کارفرما تغییر کرده است.
قابلیت جدید: کاری درخواست شده که از ابتدا داخل محدوده نبوده است.
فرض کنید پروژه در ابتدا یک فروشگاه معمولی بوده، اما پس از شروع کار اتصال دوطرفه به نرمافزار حسابداری درخواست میشود. این درخواست صرفاً یک «اصلاح» نیست؛ میتواند زمان، هزینه و حتی ساختار فنی پروژه را تغییر دهد.
برای چنین مواردی، قرارداد میتواند یک فرایند روشن برای درخواست تغییر (Change Request) داشته باشد:
- درخواست جدید ثبت شود.
- اثر آن بر زمان و هزینه بررسی شود.
- شرح تغییر و شرایط جدید به تأیید دو طرف برسد.
- سپس تغییر وارد محدوده پروژه شود.
این فرایند جلوی بسیاری از اختلافهای ناشی از جمله «فکر میکردم این هم جزو قرارداد است» را میگیرد.
تست، پذیرش و تحویل نهایی
تمامشدن توسعه، تست، پذیرش و تحویل نهایی یک اتفاق واحد نیستند.
مجری ممکن است اعلام کند اجرای قابلیتها تمام شده، اما خروجی هنوز باید براساس معیارهای توافقشده بررسی شود. بعد از رسیدگی به ایرادهای مرتبط با محدوده، پروژه میتواند پذیرفته شود و سپس تحویل نهایی داراییها و دسترسیها انجام شود.
قرارداد حرفهای علاوه بر معیارهای پذیرش، بهتر است سه سؤال دیگر را هم پاسخ دهد:
- کارفرما چه مدت برای بررسی خروجی فرصت دارد؟
- پذیرش یا اعلام ایراد از چه روشی ثبت میشود؟
- اگر کارفرما تا پایان مهلت پاسخ ندهد، چه اثری دارد؟
برای سؤال سوم پاسخ عمومی و خودکاری وجود ندارد. اگر طرفین میخواهند سکوت بعد از یک مهلت مشخص اثر قراردادی داشته باشد، بهتر است همان اثر را صریحاً در قرارداد بنویسند و آن را از یک نمونه اینترنتی کپی نکنند.
معیار پذیرش نیز میتواند براساس پروژه شامل مواردی مثل این باشد:
- صفحات مورد توافق ساخته شده باشند؛
- قابلیتهای تعریفشده قابل استفاده باشند؛
- خطاهای مؤثر مشخصشده باقی نمانده باشند؛
- خروجی روی محیط توافقشده قابل بررسی باشد؛
- اقلام تحویلی مشخص باشند.
در مرحله تحویل نیز باید معلوم باشد چه چیزهایی به کارفرما داده میشوند؛ مثلاً دسترسی مدیریت، هاست، دامنه، فایلهای مورد توافق، پایگاه داده، نسخه پشتیبان یا مستندات.
عبارت «سایت پس از تکمیل تحویل داده میشود» بهتنهایی پاسخ نمیدهد که تکمیل، پذیرش و تحویل دقیقاً چه زمانی رخ دادهاند.
مالکیت، مجوزها و داراییهای سایت
یکی از بندهایی که نباید با یک جمله کلی بسته شود، «مالکیت سایت» است.
یک پروژه وب ممکن است شامل چند دارایی متفاوت باشد:
- کد اختصاصی؛
- فایلهای طراحی؛
- محتوا و تصاویر؛
- پایگاه داده؛
- دامنه؛
- حساب هاست؛
- قالب آماده؛
- افزونه؛
- فونت؛
- کتابخانه نرمافزاری؛
- مجوز یا License؛
- حساب سرویس خارجی.
مالکیت یک فایل با حق استفاده از آن یا داشتن حساب خرید و تمدید همان دارایی لزوماً یک چیز نیست.
ماده ۶ قانون حمایت از حقوق پدیدآورندگان نرمافزارهای رایانهای برای حالتی که پدیدآوردن نرمافزار هدف استخدام یا قرارداد باشد یا جزء موضوع قرارداد قرار گیرد، مقرر میکند حقوق مادی مربوط به حق تغییر و توسعه نرمافزار متعلق به استخدامکننده یا کارفرماست، مگر اینکه در قرارداد ترتیب دیگری پیشبینی شده باشد. این حکم را نباید بدون بررسی به تمام اجزای یک سایت، از جمله قالب و افزونه شخص ثالث، تعمیم داد. قانون حمایت از حقوق پدیدآورندگان نرمافزارهای رایانهای
بهجای جمله مبهم «تمام حقوق سایت متعلق به کارفرماست»، برای داراییهای مهم مشخص کنید:
دارایی چیست، چه کسی آن را تهیه کرده، چه حقی منتقل میشود، حساب آن متعلق به چه کسی است و هزینه تمدید یا نگهداری بعدی با کدام طرف خواهد بود.
امنیت، دسترسیها و نسخه پشتیبان
امنیت نیز نباید با وعدهای مثل «سایت هیچگاه هک نمیشود» وارد قرارداد شود. امنیت یک وضعیت مطلق و دائمی نیست و بخشی از آن میتواند به نگهداری بعد از تحویل، سرویس میزبانی، بهروزرسانیها، رمزهای عبور و رفتار مدیران سایت وابسته باشد.
در صورت اهمیت این موضوع، قرارداد مشخص کند:
- چه اقدامات امنیتی اولیه داخل محدوده طراحی و تحویل هستند؛
- چه کسی حسابهای مدیریتی و رمزها را نگهداری میکند؛
- آیا فعالسازی یا تنظیم نسخه پشتیبان جزو پروژه است؛
- نسخه پشتیبان مستمر بعد از تحویل با چه کسی است؛
- بهروزرسانی نرمافزارها پس از تحویل در محدوده پشتیبانی هست یا خیر؛
- اگر سرویس پشتیبانی پایان یافت، مسئولیت نگهداری بعدی چگونه تعریف میشود.
هدف این بند، مشخصکردن مرز مسئولیت است؛ نه ایجاد تضمینی که از نظر فنی قابل کنترل نیست.
پشتیبانی، رفع باگ، نگهداری و توسعه بعدی
واژه «پشتیبانی» بدون توضیح، محدوده مشخصی ندارد.
ممکن است کارفرما از پشتیبانی انتظار بهروزرسانی افزونه، نسخه پشتیبان، رفع همه مشکلات و حتی اضافهشدن امکانات جدید را داشته باشد، در حالی که مجری فقط پاسخگویی درباره سایت را مدنظر داشته است.
چهار موضوع را از هم جدا کنید:
رفع نقص: اصلاح خروجیای که با محدوده توافقشده منطبق نیست.
پشتیبانی: خدمات مشخص بعد از تحویل.
نگهداری: کارهای مستمر مانند بهروزرسانی، نسخه پشتیبان یا پایش، در صورت توافق.
توسعه: ساخت قابلیت یا محدوده جدید.
اگر دورهای برای رفع باگ یا پشتیبانی وجود دارد، مدت و حدود آن را مشخص کنید. «یک سال پشتیبانی رایگان» یا هر مدت دیگری را نباید بهعنوان قاعده عمومی همه قراردادهای طراحی سایت فرض کرد.
خاتمه همکاری، شرایط خارج از اختیار و حل اختلاف
قرارداد باید حالت شکست پروژه را هم ببیند، نه فقط زمانی که همهچیز طبق برنامه پیش میرود.
در صورت پایان همکاری پیش از تکمیل پروژه، بهتر است وضعیت موضوعاتی مانند موارد زیر روشن باشد:
- هزینه کار انجامشده؛
- مبالغ پرداختشده؛
- خروجیهای کامل و نیمهکاره؛
- دسترسیها؛
- فایلها و داراییها؛
- اطلاعات محرمانه؛
- سرویسها و اشتراکهای ثالث.
برای شرایطی که اجرای تعهد به علت رخدادی خارج از اختیار متعارف طرف متعهد مختل میشود نیز میتوان سازوکار مشخصی تعریف کرد: نحوه اطلاعرسانی، اثر آن بر زمان و وضعیت ادامه یا توقف پروژه.
در بخش حل اختلاف هم نباید داوری را بهعنوان یک الزام عمومی برای تمام قراردادها معرفی کرد. روش حل اختلاف باید متناسب با توافق واقعی طرفین و قواعد قابل اعمال تعیین شود.
قرارداد طراحی سایت وردپرس چه نکات اضافهای دارد؟
در قرارداد طراحی سایت وردپرس اصول اصلی قرارداد تغییر نمیکنند، اما قالب، افزونه، مجوز و خدمات ثالث معمولاً اهمیت بیشتری پیدا میکنند.
ممکن است یک پروژه همزمان شامل WordPress، قالب تجاری، افزونه رایگان، افزونه پولی، سرویس خارجی و مقداری توسعه اختصاصی باشد. این موارد نباید همگی تحت عنوان کلی «سایت» یک دارایی واحد فرض شوند.
در صورت ارتباط، مشخص کنید:
- قالب آماده استفاده میشود یا طراحی اختصاصی؛
- افزونههای تجاری موردنیاز کداماند؛
- خرید آنها با چه کسی است؛
- حساب خرید متعلق به چه کسی خواهد بود؛
- وضعیت License Key پس از تحویل چیست؛
- تمدید اشتراک بعدی بر عهده چه کسی است؛
- بهروزرسانی قالب و افزونه بعد از پروژه با کدام طرف است؛
- نسخه پشتیبان و نگهداری سایت جزو قرارداد اصلی است یا خدمت جداگانه.
در اختیار داشتن فایل یک افزونه لزوماً به معنای مالکیت محصول، مالکیت حساب فروشنده یا برخورداری دائمی از بهروزرسانی و پشتیبانی آن نیست.
اگر پروژه هیچ سرویس تجاری یا دارایی ثالثی ندارد، بندهای نامرتبط را فقط برای طولانیتر و رسمیتر نشاندادن قرارداد اضافه نکنید.
نمونه قرارداد طراحی سایت
متن زیر یک نمونه قرارداد طراحی سایت عمومی و قابل شخصیسازی است. بخشهای داخل کروشه براساس پروژه واقعی تکمیل میشوند و بندهای نامرتبط نیز باید حذف یا اصلاح شوند.
ماده ۱ ـ طرفین قرارداد
این قرارداد در تاریخ [تاریخ] میان اشخاص زیر منعقد میشود:
کارفرما:
نام/نام شرکت: [نام کامل]
شماره ملی/شناسه ملی: [شماره]
نام و سمت نماینده در صورت شخص حقوقی: [نام و سمت]
نشانی: [نشانی]
شماره تماس: [شماره]
ایمیل/کانال رسمی مکاتبات: [اطلاعات]
و
مجری:
نام/نام شرکت: [نام کامل]
شماره ملی/شناسه ملی: [شماره]
نام و سمت نماینده در صورت شخص حقوقی: [نام و سمت]
نشانی: [نشانی]
شماره تماس: [شماره]
ایمیل/کانال رسمی مکاتبات: [اطلاعات]
که از این پس در قرارداد بهترتیب «کارفرما» و «مجری» نامیده میشوند.
ماده ۲ ـ موضوع و محدوده قرارداد
موضوع قرارداد عبارت است از طراحی، پیادهسازی و تحویل وبسایت [نوع سایت/نام پروژه] مطابق متن قرارداد و پیوست فنی شماره [شماره].
شرح کلی پروژه:
[شرح کوتاه و دقیق پروژه]
دامنه یا محیط هدف در صورت مشخص بودن:
[دامنه/محیط]
برای تعیین محدوده خدمات فنی مورد توافق، خدمات، خروجیها و امکانات پروژه مطابق این قرارداد و پیوستهای مورد تأیید طرفین تفسیر میشوند. درخواست فنی جدیدی که در محدوده توافقشده قرار ندارد، در صورت تأیید طرفین براساس سازوکار تغییرات به پروژه افزوده خواهد شد.
این بند نافی تعهدات و آثاری نیست که در موارد قابل اعمال به موجب قانون یا عرف معتبر از قرارداد ناشی میشوند.
ماده ۳ ـ اسناد و پیوستهای قرارداد
در صورت وجود، اسناد زیر جزء مجموعه توافق طرفین خواهند بود:
- متن اصلی قرارداد؛
- پیوست فنی و شرح خدمات؛
- فهرست امکانات و خروجیهای قابل تحویل؛
- برنامه زمانبندی مورد توافق؛
- درخواستهای تغییر یا الحاقیههای بعدی که مورد تأیید طرفین قرار گرفتهاند؛
- سایر اسنادی که طرفین صراحتاً بهعنوان جزء قرارداد مشخص کنند.
در صورت تعارض میان اسناد، ترتیب اعتبار آنها مطابق توافق زیر خواهد بود:
[ترتیب اعتبار اسناد مشخص شود]
ماده ۴ ـ مدت و زمانبندی
تاریخ یا شرط شروع پروژه:
[تاریخ/شرط شروع]
مدت پیشبینیشده اجرای پروژه:
[مدت]
شروع یا ادامه هر مرحله میتواند به انجام پیشنیازهای تعیینشده، از جمله پرداخت مرحله مربوط، تحویل محتوا، ارائه دسترسیها یا تأیید مرحله قبل وابسته باشد.
کارفرما متعهد است اطلاعات، محتوا، دسترسیها و تأییدهای موردنیاز را در بازههای توافقشده ارائه کند. اگر تأخیر کارفرما در انجام این موارد بر اجرای پروژه اثر بگذارد، زمانبندی بخش متأثر براساس اثر واقعی آن بازتنظیم خواهد شد.
تغییر مورد تأیید طرفین که بر محدوده کار اثر بگذارد نیز میتواند زمان تحویل را تغییر دهد.
ماده ۵ ـ مبلغ و شیوه پرداخت
مبلغ خدمات موضوع این قرارداد:
[مبلغ به عدد و حروف]
شیوه پرداخت:
مرحله اول: [مبلغ/درصد] پس از [رویداد]
مرحله دوم: [مبلغ/درصد] پس از [رویداد]
مرحله نهایی: [مبلغ/درصد] پس از [رویداد]
هزینه دامنه، هاست، قالب، افزونه، مجوز، API، سرویس خارجی و سایر خدمات شخص ثالث فقط در صورتی داخل مبلغ فوق محسوب میشوند که صراحتاً در قرارداد یا پیوست مالی درج شده باشند.
وضعیت مالیات، عوارض یا کسورات قانونی احتمالی نیز براساس قوانین قابل اعمال و شرایط واقعی طرفین تعیین میشود:
[وضعیت هزینهها و کسورات قانونی]
ماده ۶ ـ تعهدات مجری
مجری متعهد است:
- خدمات تعیینشده در محدوده کار و پیوست فنی را مطابق توافق اجرا کند.
- در صورت دریافت درخواست خارج از محدوده، پیش از اجرای آن اثر احتمالی بر زمان و هزینه را مطابق سازوکار تغییرات مشخص کند.
- مواردی را که واقعاً عدم انطباق خروجی با تعهدات توافقشده محسوب میشوند، مطابق شرایط قرارداد بررسی و اصلاح کند.
- از دسترسیهای کارفرما فقط در حدود موردنیاز برای اجرای پروژه استفاده کند.
- فایلها، اطلاعات و دسترسیهایی را که طبق قرارداد باید در پایان پروژه تحویل شوند، در فرایند تحویل ارائه کند.
- در صورت استفاده از سرویس یا دارایی ثالثی که ادامه عملکرد آن به مجوز، تمدید یا حساب مستقلی وابسته است، وضعیت مؤثر و شناختهشده آن را در محدوده مسئولیت خود به کارفرما اعلام کند.
- در صورت فعال بودن بند محرمانگی، از اطلاعات محرمانه کارفرما خارج از نیاز پروژه استفاده نکند.
- اقدامات امنیتی و پشتیبانگیریای را که صراحتاً داخل محدوده پروژه قرار گرفتهاند مطابق پیوست فنی اجرا کند.
تعهدات فنی اختصاصی مجری در پیوست فنی درج میشوند.
ماده ۷ ـ تعهدات کارفرما
کارفرما متعهد است:
- اطلاعات و دسترسیهای لازم را در زمان مورد توافق ارائه کند.
- محتوا، تصاویر، اطلاعات محصولات و سایر اقلامی را که تهیه آنها بر عهده اوست در زمان مناسب تحویل دهد.
- خروجیهای نیازمند تأیید را در مهلت توافقشده بررسی کند.
- مبالغ قرارداد را براساس مراحل و شرایط تعیینشده پرداخت کند.
- نسبت به مجاز بودن استفاده از محتوا، تصویر، فونت، فایل یا داراییای که برای پروژه در اختیار مجری قرار میدهد مسئولیت خود را رعایت کند.
- درخواستهای خارج از محدوده را از مسیر تعیینشده برای تغییرات اعلام کند.
- در صورت ارتباط، از ایجاد تغییر مستقیم در محیط پروژه که بتواند فرایند توسعه یا تشخیص خطا را مختل کند بدون هماهنگی لازم خودداری کند.
- پس از تحویل، از حسابها و رمزهایی که مسئولیت نگهداری آنها به او منتقل شده است به شکل مناسب نگهداری کند.
ماده ۸ ـ اصلاحات، رفع نقص و تغییر محدوده
طرفین میان «رفع نقص»، «بازبینی» و «تغییر محدوده» تفاوت قائل میشوند.
رفع نقص مربوط به حالتی است که خروجی با نیازمندی یا خروجی قابل تحویل مورد توافق منطبق نباشد.
بازبینی شامل تغییر محدود در همان محدوده است و تعداد یا حدود آن در صورت نیاز به شرح زیر تعیین میشود:
[تعداد/محدوده بازبینیها]
درخواست صفحه، قابلیت، فرایند، اتصال یا خروجی جدیدی که در محدوده اولیه وجود نداشته باشد، تغییر محدوده محسوب میشود.
در درخواست تغییری که بر هزینه یا زمان اثر دارد، ابتدا شرح درخواست و اثر آن بررسی میشود و پس از تأیید طرفین درباره هزینه، زمان و محدوده جدید، تغییر وارد پروژه خواهد شد.
روش ثبت و تأیید درخواست تغییر:
[روش مورد توافق]
ماده ۹ ـ تست، بررسی و پذیرش
پس از تکمیل خروجیهای مورد توافق، مجری آنها را برای بررسی در اختیار کارفرما قرار میدهد.
معیارهای اصلی پذیرش پروژه:
[معیارهای پذیرش پروژه]
روش ثبت ایراد:
[روش ثبت ایراد]
مهلت کارفرما برای بررسی هر خروجی یا نسخه نهایی:
[مدت]
روش اعلام پذیرش:
[ایمیل / سامانه پروژه / صورتجلسه / روش مورد توافق]
اگر کارفرما در مهلت تعیینشده پاسخ ندهد، اثر مورد توافق طرفین چنین خواهد بود:
[اثر عدم پاسخ بهصورت صریح تعیین شود؛ برای مثال تمدید مهلت، ارسال یادآوری، یا اثر دیگری که طرفین معتبر میدانند]
عدم پاسخ کارفرما صرفاً در صورتی اثری مانند پذیرش خواهد داشت که چنین اثری بهصورت روشن در قرارداد مورد توافق قرار گرفته باشد.
پس از رسیدگی به موارد مرتبط با محدوده و تحقق معیارهای پذیرش، پروژه مطابق سازوکار فوق پذیرفته میشود.
ماده ۱۰ ـ تحویل نهایی
پس از پذیرش پروژه و تحقق شرایط مالی یا اجرایی مورد توافق، اقلام زیر در صورت تعلق تحویل میشوند:
[دسترسی مدیریت سایت]
[دسترسی هاست]
[دسترسی دامنه]
[نسخه پشتیبان]
[فایلهای مورد توافق]
[پایگاه داده]
[مستندات]
[حسابها یا دسترسیهای سرویسهای ثالث]
[سایر اقلام]
تاریخ یا رویداد تکمیل تحویل:
[تاریخ/رویداد]
دارایی متعلق به مجری یا شخص ثالث فقط در حدود حقی تحویل یا قابل استفاده خواهد بود که قرارداد و مجوز مربوط اجازه میدهد.
ماده ۱۱ ـ مالکیت، مجوزها و داراییها
وضعیت هر دارایی اصلی پروژه باید جداگانه مشخص شود.
کد یا توسعه اختصاصی:
[وضعیت حقوق مادی/حق استفاده/تغییر و توسعه براساس توافق و قانون قابل اعمال]
فایلهای طراحی اختصاصی:
[وضعیت]
محتوای تولیدشده در قالب قرارداد:
[وضعیت]
دامنه:
[دارنده/مسئول مدیریت]
هاست:
[دارنده حساب/مسئول تمدید]
قالب و افزونههای تجاری:
[وضعیت خرید، مجوز، حساب و تمدید]
سرویسهای ثالث:
[وضعیت حساب، اشتراک و هزینه]
استفاده از نرمافزار، قالب، افزونه، فونت، تصویر، کتابخانه یا سایر داراییهای شخص ثالث تابع شرایط همان دارایی است و این قرارداد نباید بهگونهای تفسیر شود که حقی بیش از مجوز معتبر آن منتقل شده باشد.
در مورد نرمافزار اختصاصیای که پدیدآوردن آن هدف قرارداد یا جزء موضوع قرارداد است، وضعیت حقوق مربوط باید با رعایت قوانین قابل اعمال، از جمله قواعد مربوط به نرمافزار سفارشی، و هر توافق متفاوتی که طرفین بهصراحت ثبت کردهاند تعیین شود.
ماده ۱۲ ـ امنیت، حسابها و نسخه پشتیبان
اقدامات امنیتیای که مجری تا زمان تحویل متعهد به اجرای آنهاست:
[شرح اقدامات داخل محدوده]
وضعیت ایجاد یا تنظیم نسخه پشتیبان اولیه:
[شرح]
مسئول نسخه پشتیبان مستمر پس از تحویل:
[کارفرما / مجری در قالب پشتیبانی / ارائهدهنده هاست / مورد دیگر]
مسئول بهروزرسانی نرمافزارها، قالب و افزونهها پس از پایان پروژه:
[مسئول]
پس از تحویل دسترسیهای مدیریتی، مسئولیت نگهداری اطلاعات ورود و کنترل دسترسی مطابق توافق زیر خواهد بود:
[شرح]
تعهدات امنیتی این ماده به معنای تضمین مطلق جلوگیری از هر حمله یا رخداد امنیتی در آینده نیست و حدود مسئولیت هر طرف براساس تعهدات مشخص این قرارداد و شرایط قابل اعمال سنجیده میشود.
ماده ۱۳ ـ خدمات پس از تحویل
خدمات بعد از پذیرش نهایی فقط در حدودی ارائه میشوند که در این ماده یا توافق جداگانه مشخص شده باشند.
دوره رفع نقص در صورت توافق:
[مدت و شرایط]
خدمات پشتیبانی:
[شرح دقیق]
نگهداری و بهروزرسانی:
[داخل قرارداد / خارج از قرارداد / شرایط]
نسخه پشتیبان مستمر:
[مسئول]
افزودن قابلیتهای جدید پس از تحویل، در صورتی که صراحتاً در این ماده نیامده باشد، توسعه جدید محسوب میشود و به توافق جداگانه نیاز دارد.
ماده ۱۴ ـ محرمانگی در صورت نیاز
[در صورت عدم نیاز به محرمانگی اختصاصی، این ماده حذف یا متناسبسازی شود.]
در صورت وجود اطلاعات محرمانه، موارد مشمول این عنوان:
[تعریف اطلاعات محرمانه]
طرف دریافتکننده متعهد است از این اطلاعات فقط برای اجرای پروژه و در حدود مورد توافق استفاده کند و بدون مجوز در اختیار اشخاص غیرمجاز قرار ندهد؛ مگر در مواردی که افشا براساس قانون یا دستور مرجع صالح ضروری باشد.
مدت و استثناهای تعهد:
[شرایط]
ماده ۱۵ ـ شرایط خارج از اختیار طرفین
اگر اجرای بخشی از تعهدات به علت رخدادی خارج از اختیار متعارف طرف متعهد بهطور جدی مختل شود، طرف متأثر باید در اولین فرصت متعارف موضوع و اثر آن بر تعهدات را به طرف دیگر اطلاع دهد.
اثر وضعیت ایجادشده بر زمان، تعلیق یا امکان ادامه قرارداد با توجه به شرایط واقعی و مقررات قابل اعمال تعیین خواهد شد.
اگر وضعیت برای مدت [مدت در صورت توافق] ادامه پیدا کند، طرفین درباره ادامه، بازتنظیم برنامه یا پایان همکاری مطابق مفاد قرارداد تصمیم میگیرند.
ماده ۱۶ ـ خاتمه همکاری
شرایطی که براساس قرارداد میتوانند زمینه پایان همکاری را ایجاد کنند:
[شرایط دقیق]
در صورت توافق، طرفی که تعهد خود را نقض کرده است پیش از پایان همکاری برای رفع آن مهلت [مدت] خواهد داشت، مگر در مواردی که چنین مهلتی براساس قرارداد یا قانون موضوعیت نداشته باشد.
در پایان زودهنگام پروژه باید وضعیت موارد زیر تعیین شود:
- هزینه خدمات انجامشده؛
- مبالغ پرداختشده؛
- خروجیهای کامل یا نیمهکاره؛
- فایلها و داراییها؛
- اطلاعات و دسترسیها؛
- تعهدات محرمانگی؛
- سرویسها و اشتراکهای ثالث.
روش تسویه در این وضعیت:
[روش مورد توافق]
ماده ۱۷ ـ مکاتبات و تغییرات قرارداد
کانالهای رسمی مورد قبول طرفین:
[ایمیل / سامانه مدیریت پروژه / روش دیگر]
تغییر در محدوده، مبلغ، مدت یا سایر شرایط اصلی باید بهصورت قابل استناد و مورد تأیید طرفین ثبت شود.
الحاقیهها یا درخواستهای تغییر تأییدشده براساس شرایط قرارداد به اسناد پروژه افزوده میشوند.
مذاکرات یا درخواستهایی که به تأیید موردنیاز نرسیدهاند، بهتنهایی محدوده پروژه را تغییر نمیدهند.
ماده ۱۸ ـ حل اختلاف
طرفین تلاش خواهند کرد اختلاف مربوط به تفسیر یا اجرای قرارداد را ابتدا از طریق مذاکره و بررسی مستندات پروژه حل کنند.
در صورت حلنشدن اختلاف، روش مورد توافق طرفین:
[مراجعه به مرجع صالح / داوری با مشخصات کامل / روش قانونی مورد توافق دیگر]
اگر داوری انتخاب میشود، مشخصات داور یا روش انتخاب او و حدود توافق داوری باید بهاندازه کافی روشن باشد.
ماده ۱۹ ـ نسخهها و امضا
این قرارداد شامل [تعداد] ماده و [تعداد] پیوست در [تعداد] نسخه مورد توافق تنظیم شده است.
امضای کارفرما:
نام و سمت: [نام]
تاریخ: [تاریخ]
امضای مجری:
نام و سمت: [نام]
تاریخ: [تاریخ]
دانلود نمونه قرارداد طراحی سایت Word
چطور این نمونه قرارداد را برای پروژه خودتان شخصیسازی کنید؟
اشتباه رایج این است که نمونه قرارداد طراحی سایت Word دانلود شود و فقط نام طرفین و مبلغ عوض شود. شخصیسازی واقعی باید از محدوده پروژه شروع شود.
- طرفین و اختیار امضا را بررسی کنید. اطلاعات را با وضعیت واقعی افراد یا شرکتها تطبیق دهید.
- موضوع و پیوست فنی را برای پروژه خودتان بنویسید. صفحات، قابلیتها، سرویسها، تعداد اقلام و موارد خارج از محدوده را مشخص کنید.
- زمان و پرداخت را به رویدادهای واقعی وصل کنید. اعداد موجود در نمونههای دیگر را بدون دلیل کپی نکنید.
- مرز باگ، بازبینی و درخواست جدید را تعیین کنید. این بخش مانع گسترش بیضابطه پروژه میشود.
- مهلت بررسی و روش پذیرش را مشخص کنید. قرارداد نباید بعد از تحویل خروجی برای مدت نامعلوم باز بماند.
- اقلام تحویل نهایی را بنویسید. معلوم باشد چه حسابها، فایلها، نسخههای پشتیبان و دسترسیهایی تحویل میشوند.
- مالکیت و مجوز را داراییبهدارایی بررسی کنید. مخصوصاً قالب، افزونههای تجاری، حساب خرید و سرویسهای خارجی.
- امنیت و نگهداری پس از تحویل را تعیین کنید. مسئول بهروزرسانی، نسخه پشتیبان و مدیریت دسترسیها باید روشن باشد.
- بندهای مشروط را متناسب کنید. محرمانگی، پشتیبانی، مهاجرت داده یا خدمات دیگر فقط وقتی باقی بمانند که به پروژه مربوطاند.
- در پروژههای حساس از بررسی اختصاصی استفاده کنید. مبلغ بالا، توسعه نرمافزاری قابل توجه، داده حساس یا همکاری چند شرکت میتواند به قرارداد اختصاصیتری نیاز داشته باشد.
اشتباهات رایج در قرارداد طراحی وب سایت
موضوع قرارداد بیش از حد کلی است. «طراحی سایت فروشگاهی» بدون شرح خدمات هنوز درباره بسیاری از تعهدات چیزی نمیگوید.
موارد خارج از پروژه نوشته نشدهاند. در نتیجه ممکن است سئو، محتوا، پشتیبانی یا توسعه بعدی به اشتباه بخشی از مبلغ اولیه تلقی شوند.
اصلاحات نامحدود تعریف شدهاند. بدون مرزبندی، بازبینی میتواند به توسعه دائمی پروژه تبدیل شود.
باگ با قابلیت جدید یکی گرفته شده است. رفع نقص تعهد توافقشده با ساخت قابلیت جدید یک کار نیست.
مهلت پذیرش مشخص نشده است. اگر کارفرما زمان نامحدودی برای اعلام نظر داشته باشد و اثر عدم پاسخ نیز روشن نباشد، پایان پروژه میتواند مبهم بماند.
معیار پذیرش وجود ندارد. اگر پایان پروژه تعریف نشده باشد، هر طرف میتواند برداشت متفاوتی از «تحویل کامل» داشته باشد.
مالکیت سایت در یک جمله خلاصه شده است. کد اختصاصی، دامنه، حساب سرویس، افزونه و مجوز ممکن است وضعیتهای متفاوتی داشته باشند.
امنیت بهصورت تضمین مطلق نوشته شده است. قرارداد بهتر است اقدامات و مسئولیتها را تعریف کند، نه اینکه رخندادن هر حادثه امنیتی در آینده را تضمین کند.
پشتیبانی تعریف نشده است. واژه «پشتیبانی» بدون مدت و محدوده مشخص، زمینه اختلاف ایجاد میکند.
مهلت پروژه بدون وابستگیهای کارفرما تعیین شده است. اگر اجرا به محتوا، دسترسی یا تأیید کارفرما وابسته است، این وابستگی باید در برنامه دیده شود.
نمونه آماده بدون شخصیسازی امضا شده است. حتی یک نمونه مفصل هم جای توافق واقعی همان پروژه را نمیگیرد.
سخن پایانی
ارزش یک قرارداد طراحی سایت فقط در روزی که اختلافی ایجاد میشود مشخص نیست. قرارداد خوب قبل از شروع پروژه کمک میکند کارفرما و مجری درباره محدوده کار، هزینه، تغییرات، پذیرش خروجی و مسئولیتهای بعد از تحویل برداشت مشترکی داشته باشند.
اگر از نمونه این صفحه استفاده میکنید، مهمترین کار پرکردن جای خالیها نیست. محدوده و پیوست فنی را براساس پروژه واقعی بنویسید و بندهای تغییرات، پذیرش، تحویل، مالکیت، امنیت و خدمات بعد از تحویل را آگاهانه تنظیم کنید. هرچه پروژه پیچیدهتر شود، اتکا به یک متن عمومی بدون تطبیق اختصاصی ریسک بیشتری دارد.
سوالات متداول
۱. آیا یک نمونه قرارداد برای همه پروژههای طراحی سایت مناسب است؟
خیر. محورهایی مانند طرفین، محدوده، مبلغ، زمان، تغییرات و تحویل در بیشتر پروژهها اهمیت دارند، اما جزئیات باید با نوع سایت، شیوه همکاری، ابزارهای ثالث و خدمات بعد از تحویل تطبیق داده شوند.
۲. قرارداد طراحی سایت وردپرس چه تفاوتی با قرارداد معمولی دارد؟
اصول اصلی مشابهاند، اما در پروژه وردپرسی معمولاً وضعیت قالب، افزونه، License Key، حساب خرید، تمدید اشتراک، بهروزرسانی و مسئولیت نگهداری اهمیت بیشتری پیدا میکند.
۳. چرا نسخه Word برای نمونه قرارداد کاربردی است؟
چون بخش زیادی از قرارداد باید براساس پروژه تغییر کند. نسخه Word امکان ویرایش محدوده کار، مبلغ، زمان، تعهدات و بندهای مشروط را میدهد. پس از نهاییشدن قرارداد نیز میتوان نسخه ثابت مورد توافق را برای بایگانی نگه داشت.
۴. تعداد اصلاحات در قرارداد طراحی سایت چگونه تعیین شود؟
عدد واحدی برای همه پروژهها وجود ندارد. مهمتر از تعداد این است که «بازبینی» تعریف شود و با رفع باگ یا درخواست قابلیت جدید اشتباه نشود. تعداد یا محدوده بازبینی باید متناسب با نوع خروجی و فرایند تأیید پروژه تعیین شود.
۵. آیا پشتیبانی سایت باید داخل همان قرارداد طراحی سایت باشد؟
الزامی نیست. اگر خدمات پس از تحویل بخشی از توافق است، میتوان مدت و محدوده آن را در همان قرارداد مشخص کرد. برای نگهداری یا پشتیبانی گسترده و بلندمدت نیز ممکن است توافق جداگانه شفافتر باشد.