پیشنهاد قیمت را قبول کرده‌اید و پیمانکار قرارداد فرستاده؛ یا یک قرارداد آماده از اینترنت دارید و نمی‌دانید کدام بند را باید خودتان اضافه کنید. پاسخ کوتاه این است: قرارداد طراحی سایت و اپلیکیشن را از نُه بند اصلی چک کنید: موضوع و محدوده (با PRD پیوست)، مراحل و تحویل‌ها، پرداخت مرحله‌ای، معیار پذیرش، تغییر نیازمندی، مالکیت سورسکد و دسترسی‌ها، پشتیبانی پس از تحویل، محرمانگی، و تأخیر و فسخ.
این متن مشاورهٔ حقوقی نیست، قبل از امضا وکیل را ببینید.
در این راهنما برای هر بند می‌گوییم چه چیزی باید روشن شود، کجا معمولاً اشتباه میشود و چه سندی باید پیوستش باشد. چند نمونه‌جملهٔ عمومی با جای خالی هم آورده‌ایم تا بدانید دنبال چه چیزی بگردید.
قرارداد طراحی سایت و اپلیکیشن چه بندهایی دارد؟
قرارداد خوب جای حدس را می‌گیرد. هر جا قرارداد ساکت باشد، بعداً دو طرف برداشت خودشان را دارند. جدول زیر نُه بندی است که در قرارداد یک سایت یا اپ باید روشن باشد. محدودهٔ کار را بهتر است در یک مستند نیازمندی پروژه (PRD) بنویسید؛ سندی که میگوید محصول دقیقاً چه کارهایی میکند.
| بند | چه چیزی باید روشن شود | اشتباه رایج | پیوست یا سند مرتبط |
|---|---|---|---|
| ۱. طرفین و موضوع | چه کسی برای چه کسی چه می‌سازد | موضوع در یک جملهٔ کلی مثل «طراحی اپلیکیشن» | — |
| ۲. محدودهٔ کار | امکانات، صفحه‌ها، نقش‌های کاربری، و چیزهایی که در محدوده نیست | محدوده فقط در پیام‌ها و جلسه‌ها گفته شده | PRD |
| ۳. مراحل و تحویل‌ها | هر مرحله چه خروجی‌ای دارد و کی تحویل میشود | فقط یک تاریخ تحویل نهایی | جدول مراحل |
| ۴. پرداخت مرحله‌ای | هر قسط به کدام تحویل وصل است | پرداخت بر اساس زمان، نه تحویل | جدول مراحل |
| ۵. معیار پذیرش | «تمام‌شده» یعنی چه و چه کسی تأیید میکند | تأیید با سلیقه، بدون معیار نوشته‌شده | معیارهای پذیرش در PRD |
| ۶. تغییر نیازمندی | تغییر چطور درخواست، برآورد و تأیید میشود | «هر تغییری رایگان» یا «هیچ تغییری مجاز نیست» | فرم درخواست تغییر |
| ۷. سورسکد و دسترسی‌ها | سورسکد، مستندات، سرور، دامنه و حساب‌ها به نام کیست | تحویل اپ بدون سورسکد | فهرست تحویلی‌ها |
| ۸. پشتیبانی پس از تحویل | چه مدت، چه چیزی رفع خطاست و چه چیزی توسعهٔ جدید | «پشتیبانی دارد» بدون مدت و حدود | — |
| ۹. محرمانگی، تأخیر، فسخ و حل اختلاف | اطلاعات کسب‌وکار چطور حفظ میشود، اگر کار عقب افتاد یا متوقف شد چه میشود | فقط برای تأخیر یک طرف شرط نوشته شده | — |
مثال: قرارداد آماده‌ای که از اینترنت دانلود شده معمولاً بندهای ۱ و ۹ را کامل دارد، ولی بند ۲ در آن یک خط است. همین یک خط بعداً بیشتر از هر بند دیگری اختلاف می‌سازد.
بند محدوده: PRD را پیوست کنید
جملهٔ «طراحی اپلیکیشن فروشگاهی» محدوده نیست. محدوده یعنی فهرست امکانات، صفحه‌ها، نقش‌های کاربری و اتصال‌ها (مثل درگاه پرداخت یا پیامک). جای این فهرست متن قرارداد نیست؛ در PRD نوشته میشود و PRD پیوست قرارداد میشود. اگر نمی‌دانید PRD چه بخش‌هایی دارد، نمونه PRD و قالب Word را ببینید. فرق این سند با سند فنی‌تر را هم در SRS و PRD توضیح داده‌ایم.
دو چیز را حتماً در پیوست بنویسید:
- چیزهایی که در محدوده نیست. مثلاً «پنل فروشنده در این فاز ساخته نمی‌شود». این جمله بعداً جلوی سوءتفاهم را می‌گیرد.
- معیار پذیرش هر امکان. یعنی شرطی که با آن معلوم میشود یک امکان کامل شده است.
مثال فرضی: در قرارداد نوشته شده «اپ دارای سبد خرید». کارفرما انتظار کد تخفیف دارد و مجری آن را نساخته. اگر PRD پیوست بود و کد تخفیف در آن آمده بود یا نبود، بحث در یک دقیقه تمام می‌شد.
نمونه‌جملهٔ عمومی بند محدوده:
«محدودهٔ کار مطابق پیوست شمارهٔ ۱ (مستند نیازمندی) است. هر چیزی که در آن نیامده، تا زمانی که با توافق کتبی طرفین اضافه نشود، جزو تعهد مجری نیست.»
بند پرداخت و تحویل: پول را به تحویل گره بزنید
پرداخت باید به تحویل هر مرحله وصل باشد، نه به گذشت زمان. یعنی هر قسط وقتی پرداخت میشود که خروجی آن مرحله تحویل شده و طبق معیار پذیرش تأیید شده باشد. آخرین قسط هم بعد از پذیرش نهایی است.
برای این بند عدد پیشنهادی نمی‌دهیم. تعداد مرحله‌ها و سهم هر قسط را خودتان با پیمانکار توافق کنید و با وکیل چک کنید. چیزی که مهم است، این ارتباط است: مرحله، خروجی، معیار تأیید، قسط.
مثال فرضی: مرحلهٔ دوم «طراحی صفحه‌ها» است. خروجی آن فایل طراحی همهٔ صفحه‌های فهرست‌شده در PRD است. قسط دوم بعد از تأیید همین فایل پرداخت میشود، نه «یک ماه بعد از شروع».
نمونه‌جملهٔ عمومی بند پرداخت:
«مبلغ [ ] در [ ] مرحله پرداخت میشود و هر قسط پس از تحویل مرحلهٔ مربوط و تأیید کارفرما طبق معیار پذیرش پیوست پرداخت می‌گردد.»
محدودهٔ پروژه را با ما روشن کنید تا برآورد و پیوست قرارداد آماده‌تر باشد. فرم برآورد پروژه
بند تغییر نیازمندی: وسط کار نیاز عوض شد، چه میشود؟
تقریباً در هر پروژه‌ای وسط کار چیزی عوض میشود. مشکل خود تغییر نیست؛ مشکل تغییری است که روال ندارد. بدون این بند دو حالت خطرناک پیش می‌آید: یا هر تغییری «رایگان» فرض میشود و پروژه هیچ‌وقت تمام نمی‌شود، یا مجری هر درخواستی را رد میکند. به بزرگ شدن تدریجی و کنترل‌نشدهٔ محدوده Scope Creep می‌گویند.
روال ساده این است:
- تغییر کتبی درخواست میشود.
- مجری اثرش را روی زمان و هزینه برآورد میکند.
- کارفرما قبل از اجرا تأیید میکند.
- تغییر به پیوست محدوده اضافه میشود.
مثال فرضی: وسط ساخت اپ تصمیم می‌گیرید ورود با رمز یک‌بار مصرف پیامکی هم اضافه شود. با این بند، اول برآورد را می‌بینید و بعد تصمیم می‌گیرید که الان اضافه شود یا در فاز بعد.
نمونه‌جملهٔ عمومی بند تغییر:
«هر تغییر در محدوده، قبل از اجرا باید کتباً درخواست، برآورد زمان و هزینه و تأیید شود.»
مالکیت سورسکد، دسترسی‌ها و پشتیبانی
سورسکد متن اصلی برنامه است؛ بدون آن هیچ تیم دیگری نمی‌تواند سایت یا اپ را تغییر دهد. قرارداد باید روشن بگوید سورسکد، مستندات، مخزن کد (جایی که کد و تاریخچهٔ تغییراتش نگه داشته میشود)، سرور، دامنه و حساب‌های فنی به نام چه کسی است و کی تحویل میشود.
پشتیبانی پس از تحویل هم باید دو چیز را جدا کند: رفع خطای چیزی که طبق PRD ساخته شده، و امکان جدید که توسعه حساب میشود و قرارداد جدا یا برآورد جدا دارد.
تجربهٔ ما: در پروژههای تکنوراه، طبق صفحه‌های طراحی سایت اختصاصی و طراحی اپلیکیشن موبایل، سورسکد و دسترسی سرور از روز اول به نام مشتری است و بعد از تحویل ۶ ماه پشتیبانی اولیه برای رفع خطاها و پایدارسازی هست. لازم نیست شما هم همین را بخواهید، ولی هر چه توافق می‌کنید باید در قرارداد نوشته شود.
مثال فرضی: پیمانکار سرور را با حساب خودش گرفته و قرارداد دربارهٔ آن ساکت است. روزی که بخواهید تیم را عوض کنید، اول باید سر دسترسی سرور مذاکره کنید.
نمونه‌جملهٔ عمومی بند مالکیت و پشتیبانی:
«سورسکد، مستندات و دسترسی‌های فنی پس از تسویه و تحویل نهایی به [ ] منتقل میشود؛ پشتیبانی رایگان به‌مدت [ ] و برای رفع خطاهای [ ] است.»
سایت یا اپلیکیشن: چه بندی فرق میکند؟
بیشتر بندها برای سایت و اپ یکی است، ولی چند مورد فقط در یکی از آن‌ها پیش می‌آید. این‌ها را در قرارداد خودتان چک کنید:
| موضوع | در قرارداد سایت | در قرارداد اپلیکیشن |
|---|---|---|
| حساب‌ها و نام مالک | دامنه و میزبانی به نام چه کسی ثبت میشود | حساب‌های انتشار در فروشگاه‌های اپ به نام چه کسی است |
| محتوا | متن و تصویر صفحه‌ها را چه کسی تهیه میکند | متن و تصویرهای صفحهٔ اپ در فروشگاه را چه کسی تهیه میکند |
| تست | روی کدام مرورگرها و اندازه‌های صفحه تست میشود | روی کدام دستگاه‌ها و نسخه‌های سیستم‌عامل تست میشود |
| نسخه‌ها | یک نسخهٔ وب | اندروید، iOS یا هر دو؛ هر کدام صریح نوشته شود |
| انتشار | راه‌اندازی روی سرور نهایی | انتشار در فروشگاه‌ها و مسئول رسیدگی به بازخورد بررسی فروشگاه |
اگر هنوز بین وب‌اپ و اپ نصبی تصمیم نگرفته‌اید، PWA یا اپلیکیشن نیتیو کمک میکند. PWA وب‌سایتی است که مثل اپ روی گوشی نصب میشود.
مثال فرضی: قرارداد اپ فقط «اپلیکیشن موبایل» نوشته و شما انتظار نسخهٔ iOS هم داشته‌اید. یک کلمه در قرارداد این ابهام را از بین می‌برد.
اگر هنوز پیشنهاد نگرفته‌اید
قرارداد مرحلهٔ آخر است. اگر هنوز از چند تیم پیشنهاد نگرفته‌اید، اول یک درخواست یکسان برای همه بفرستید تا پیشنهادها قابل مقایسه باشند؛ نمونه RFP و قالب آماده برای همین است. اگر هنوز نمی‌دانید با چه تیمی و با چه شکلی کار کنید، راهنمای انتخاب شرکت و بستن قرارداد را بخوانید.
چک‌لیست قبل از امضا
قبل از امضا این هشت مورد را تیک بزنید:
- محدودهٔ کار در PRD نوشته شده و PRD پیوست قرارداد است.
- مراحل کار و تاریخ تحویل هر مرحله مشخص است.
- هر قسط پرداخت به تحویل یک مرحله گره خورده است.
- معیار پذیرش نوشته شده و معلوم است چه کسی تأیید میکند.
- روال تغییر نیازمندی (درخواست کتبی، برآورد، تأیید) در قرارداد هست.
- سورسکد، مستندات و دسترسی‌ها (سرور، دامنه، حساب‌ها) به نام شما منتقل میشود.
- مدت پشتیبانی و حدودش (رفع خطا در برابر توسعهٔ جدید) روشن است.
- شرایط تأخیر، توقف کار و فسخ برای هر دو طرف نوشته شده است؛ و در آخر، متن را وکیل دیده است. این متن مشاورهٔ حقوقی نیست، قبل از امضا وکیل را ببینید.
اگر هنوز نمی‌دانید پروژه‌تان در چه بازهٔ زمانی و هزینه‌ای قرار می‌گیرد، هزینه ساخت اپلیکیشن را ببینید تا با دید روشن‌تری سر قرارداد بنشینید.
جمع‌بندی و قدم بعدی
قرارداد طراحی سایت و اپلیکیشن وقتی از شما محافظت میکند که جای حدس نگذارد. سه قدم کافی است:
- PRD را بنویسید و پیوست کنید تا محدوده و معیار پذیرش روی کاغذ باشد.
- نُه بند را با جدول و چک‌لیست این صفحه چک کنید، مخصوصاً پرداخت، تغییر نیازمندی و مالکیت سورسکد.
- قبل از امضا متن را به وکیل نشان دهید. این متن مشاورهٔ حقوقی نیست، قبل از امضا وکیل را ببینید.
اگر می‌خواهید محدودهٔ پروژه‌تان روشن شود و برآوردی بگیرید که بشود پیوست قرارداد کرد، فرم برآورد را پر کنید.
سوالات متداول
نمونه قرارداد طراحی سایت و اپلیکیشن شامل چه بندهایی است؟
نُه بند اصلی: طرفین و موضوع، محدودهٔ کار با پیوست PRD، مراحل و تحویل‌ها، پرداخت مرحله‌ای، معیار پذیرش، تغییر نیازمندی، مالکیت سورسکد و دسترسی‌ها، پشتیبانی پس از تحویل، و محرمانگی، تأخیر، فسخ و حل اختلاف. این فهرست بندهاست، نه متن قطعی قرارداد.
این نمونه را مستقیم امضا کنم؟
نه. نمونهجملههای این صفحه متن عمومی با جای خالیاند. این متن مشاورهٔ حقوقی نیست، قبل از امضا وکیل را ببینید.
پرداخت چطور تقسیم شود؟
هر قسط به تحویل یک مرحله و تأیید آن طبق معیار پذیرش وصل شود و آخرین قسط بعد از پذیرش نهایی باشد. نسبت قسط‌ها عدد استانداردی ندارد؛ آن را با پیمانکار توافق کنید و با وکیل چک کنید.
سورسکد بعد از ساخت مال کیست؟
همان کسی که قرارداد میگوید، پس باید صریح نوشته شود. در پروژههای تکنوراه سورسکد و دسترسی سرور از روز اول به نام مشتری است.
وسط کار نیاز عوض شود چه میشود؟
تغییر کتبی درخواست میشود، مجری اثرش را روی زمان و هزینه برآورد میکند و کارفرما قبل از اجرا تأیید میکند. بند تغییر نیازمندی دقیقاً همین روال را در قرارداد ثبت میکند.