قبل از امضا، ابهامها را از پروژه حذف کنید
بیشتر اختلافهای طراحی سایت از «بد بودن طرفین» شروع نمیشود؛ از جملههایی شروع میشود که دقیق تعریف نشدهاند: سایت حرفهای، پشتیبانی کامل، سئوی اولیه، تحویل سریع یا امکانات نامحدود.
یک قرارداد خوب فقط سند حقوقی نیست؛ نقشه مشترک پروژه است. باید مشخص کند چه چیزی، در چه زمانی، با چه معیار و توسط چه کسی تحویل میشود. این چکلیست ۲۵ موردی کمک میکند قبل از پرداخت و شروع کار، نقاط مبهم را روشن کنید.
خلاصه چکلیست در یک نگاه
| بخش | چیزی که باید روشن شود |
|---|---|
| هدف | مسئله کسبوکار و نتیجه مورد انتظار |
| دامنه کار | صفحات، امکانات، نقشها و اتصالها |
| طراحی | خروجی، تعداد اصلاحات و تأیید نهایی |
| فنی | فناوری، هاست، امنیت، سرعت و مرورگرها |
| محتوا و سئو | مسئول محتوا، متادیتا، آدرسها و انتقال |
| مالکیت | کد، دامنه، فایلها، حسابها و دادهها |
| زمان و هزینه | مراحل، پرداخت، تأخیر و تغییرات |
| پشتیبانی | مدت، محدوده، زمان پاسخ و توسعه بعدی |
بخش اول: هدف و دامنه پروژه
۱. هدف تجاری سایت را یک جمله بنویسید
«داشتن سایت» هدف نیست. هدف میتواند افزایش درخواست مشاوره، فروش آنلاین، معرفی نمونهکار یا کاهش تماسهای تکراری باشد. این جمله روی طراحی و اولویت امکانات اثر میگذارد.
۲. مخاطب اصلی را مشخص کنید
مخاطب سازمانی، مصرفکننده نهایی، مشتری محلی یا کاربر حرفهای مسیرهای متفاوتی میخواهد. اگر چند مخاطب دارید، اولویت آنها را بنویسید.
۳. فهرست دقیق صفحات را پیوست کنید
صفحه اصلی، خدمات، درباره ما، تماس، وبلاگ، دستهبندی، قوانین، پروفایل و صفحات فرود را نام ببرید. عبارت «و سایر صفحات لازم» قابل اندازهگیری نیست.
۴. امکانات را به ضروری و مرحله دوم تقسیم کنید
نسخه اول را با امکانات حیاتی منتشر کنید. قابلیتهایی که برای آیندهاند در فاز جداگانه قرار بگیرند تا پروژه بیانتها نشود.
۵. نقشهای کاربری و سطح دسترسی را تعریف کنید
مدیر ارشد، نویسنده، پشتیبان، مشتری یا فروشنده چه چیزهایی را میبیند و چه کاری میتواند انجام دهد؟ سطح دسترسی باید سمت سرور نیز کنترل شود.
۶. اتصال به سرویسهای بیرونی را دقیق بنویسید
درگاه پرداخت، پیامک، نقشه، حسابداری، CRM، انبار یا API هرکدام محدودیت و هزینه دارند. نام سرویس، مسئول تهیه حساب و وضعیت مستندات روشن باشد.
بخش دوم: طراحی و تجربه کاربری
۷. مشخص کنید طراحی اختصاصی است یا مبتنی بر قالب
نمونه مرجع، فایل طراحی، سیستم رنگ و تایپوگرافی و میزان سفارشیسازی باید شفاف باشد. اگر هنوز بین فناوریها مردد هستید، مقایسه وردپرس یا سایت اختصاصی را بخوانید.
۸. خروجی مرحله طراحی را تعیین کنید
آیا وایرفریم، طرح موبایل، طرح دسکتاپ و نمونه تعاملی تحویل میشود؟ پروژه در چه نقطهای وارد کدنویسی خواهد شد؟
۹. تعداد و روش اصلاحات را بنویسید
اصلاح نامحدود معمولاً تعریف خوبی نیست. تعداد دور بازخورد، زمان ارسال نظر و تفاوت «اصلاح» با «تغییر دامنه» مشخص شود.
۱۰. نسخه موبایل را یک خروجی اصلی بدانید
ریسپانسیو بودن فقط کوچک شدن عناصر نیست. منو، جدول، فرم، تصویر، مودال و پنل کاربری باید در عرضهای مختلف تست شوند.
۱۱. معیار تأیید طراحی را تعیین کنید
تأیید کتبی هر مرحله جلوی برگشتهای پرهزینه را میگیرد. یک نفر نیز باید نماینده نهایی کارفرما برای جمعبندی بازخورد باشد.
بخش سوم: فنی، امنیت و کیفیت
۱۲. فناوری و دلیل انتخاب آن را بخواهید
نام فناوری کافی نیست. مجری باید توضیح دهد انتخابش چگونه با امکانات، زمان، نگهداری و رشد پروژه هماهنگ است.
۱۳. دامنه، هاست و SSL را تعیین تکلیف کنید
مالک حساب چه کسی است؟ تمدید با چه کسی است؟ منابع هاست چقدر است؟ گواهی SSL چگونه فعال میشود؟ دسترسیها پس از تحویل باید در اختیار مالک کسبوکار باشد.
۱۴. الزامات امنیتی پایه را ثبت کنید
اعتبارسنجی سمت سرور، کنترل دسترسی، سیاست رمز، محدودسازی تلاشهای ناموفق، ثبت رخداد، پشتیبانگیری و بهروزرسانی باید متناسب با پروژه تعریف شوند.
۱۵. معیارهای سرعت را قابل سنجش کنید
بهجای «سرعت عالی»، درباره وزن تصاویر، کش، تعداد درخواستها، عملکرد روی موبایل و شرایط تست توافق کنید. سرعت به هاست و محتوای نهایی نیز وابسته است.
۱۶. مرورگر و دستگاههای تحت پشتیبانی را مشخص کنید
نسخههای رایج Chrome، Safari، Firefox و مرورگرهای موبایل را تعیین کنید. تست باید روی صفحات و فرایندهای اصلی انجام شود.
۱۷. سیاست پشتیبانگیری و بازیابی را بنویسید
تناوب بکاپ، محل نگهداری، مدت حفظ نسخهها و مسئول بازیابی مشخص باشد. بکاپی که بازیابی آن آزمایش نشده، تضمین کاملی نیست.
بخش چهارم: محتوا و سئو
۱۸. مسئول تولید و ورود محتوا را مشخص کنید
متن، تصویر، اطلاعات خدمات و قوانین را چه کسی و تا چه تاریخی میدهد؟ چند صفحه توسط مجری وارد میشود؟ تأخیر محتوا نباید مبهم بماند.
۱۹. خروجی سئوی فنی را فهرست کنید
عنوان و متا، headingها، canonical، robots.txt، sitemap.xml، صفحات خطا، داده ساختاریافته لازم و بهینهسازی تصاویر را دقیق بنویسید. «سئوی پایه» بهتنهایی تعریف کافی ندارد.
۲۰. ساختار آدرسها و انتقال سایت قبلی را بررسی کنید
اگر سایت قبلی دارید، URLهای مهم، ریدایرکت ۳۰۱، انتقال محتوا و جلوگیری از صفحات تکراری باید قبل از انتشار برنامهریزی شود.
۲۱. ابزارهای اندازهگیری را فراموش نکنید
اتصال Search Console و ابزار آمار، ثبت رویدادهای مهم و تعریف تبدیلها باید معلوم باشد. بدون داده نمیتوان موفقیت سایت را سنجید.
بخش پنجم: مالکیت، هزینه و تحویل
۲۲. مالکیت همه داراییها را شفاف کنید
کد، طرح، تصاویر خریداریشده، دامنه، هاست، دیتابیس، حساب پیامک، درگاه و فایلهای منبع را نام ببرید. دسترسی اصلی بهتر است به نام کارفرما باشد.
۲۳. زمانبندی و نقاط تحویل را مرحلهای کنید
تحلیل، طراحی، توسعه، ورود محتوا، تست و انتشار هرکدام تاریخ و مسئول دارند. وابستگیها و اثر تأخیر کارفرما نیز نوشته شود.
۲۴. پرداخت را به خروجی قابل بررسی متصل کنید
پیشپرداخت، پرداخت هر مرحله و تسویه نهایی باید با تحویل مشخص هماهنگ باشد. هزینه سرویسهای شخص ثالث و مالیات نیز جدا شود.
۲۵. پشتیبانی و فرایند تغییرات را تعریف کنید
مدت رفع باگ، کانال پشتیبانی، ساعات پاسخ، موارد خارج از پشتیبانی و هزینه توسعه جدید را بنویسید. فرق «باگ» و «قابلیت جدید» باید روشن باشد.
پنج سؤال که حتماً از مجری بپرسید
- اگر همکاری تمام شود، برای ادامه کار چه چیزهایی تحویل میدهید؟
- اگر یک سرویس بیرونی تغییر کند، مسئول هماهنگسازی کیست؟
- چه چیزهایی دقیقاً خارج از قیمت پیشنهادی است؟
- تست و تأیید نهایی بر اساس چه سناریوهایی انجام میشود؟
- بعد از انتشار، چه کسی سلامت سایت را پایش میکند؟
علائم هشدار در پیشنهاد طراحی سایت
- قیمت بدون شرح دامنه و امکانات ارائه شده است.
- زمان تحویل قطعی است اما هنوز نیازها بررسی نشدهاند.
- مالکیت دامنه یا هاست در اختیار مجری میماند.
- همه چیز «نامحدود» توصیف شده اما معیار ندارد.
- امنیت و سئو فقط با نصب افزونه توضیح داده میشوند.
- نسخه موبایل و تست فرمها در خروجی ذکر نشدهاند.
- درباره انتقال، بکاپ و پشتیبانی پاسخ روشن وجود ندارد.
یک روش ساده برای مقایسه پیشنهادها
به هر پیشنهاد از صفر تا پنج امتیاز دهید:
| معیار | وزن پیشنهادی |
|---|---|
| درک مسئله و شفافیت دامنه | ۲۵٪ |
| تجربه کاربری و کیفیت طراحی | ۲۰٪ |
| معماری، امنیت و نگهداری | ۲۰٪ |
| زمانبندی و فرایند اجرا | ۱۵٪ |
| مالکیت و کیفیت تحویل | ۱۰٪ |
| قیمت | ۱۰٪ |
این روش کمک میکند ارزانترین عدد بهتنهایی برنده نشود. برای شناخت اجزای بودجه نیز راهنمای هزینه طراحی سایت در سال ۱۴۰۵ را ببینید.
قبل از شروع، یک جلسه کشف نیاز برگزار کنید
در جلسه کشف نیاز، هدف، مخاطب، مسیر کاربر، امکانات، محتوا، اتصالها و محدودیتها بررسی میشوند. خروجی این جلسه باید به یک دامنه کار قابل اندازهگیری تبدیل شود، نه فهرستی از اصطلاحات مبهم.
اگر برای تبدیل ایده به سند نیازمندی کمک میخواهید، از صفحه تماس با آرتمیسلند پیام بفرستید تا قبل از قرارداد، مسیر پروژه شفاف شود.
سؤالات متداول
آیا قرارداد طراحی سایت باید خیلی طولانی باشد؟
نه؛ باید دقیق باشد. پیوست امکانات، جدول تحویل و مسئولیتها گاهی از متن حقوقی طولانی مهمترند.
سورس سایت باید تحویل داده شود؟
نحوه مالکیت و تحویل باید صریحاً در قرارداد بیاید. در پروژه اختصاصی، کد و مستندات لازم برای ادامه نگهداری اهمیت زیادی دارند.
سئوی سایت در قرارداد طراحی شامل چه چیزهایی است؟
حداقل خروجی فنی باید مشخص شود. تولید محتوا، لینکسازی و رشد رتبه معمولاً خدمات جداگانهاند و نباید با «سئوی پایه» اشتباه شوند.
پشتیبانی رایگان یعنی چه؟
باید مدت و محدوده داشته باشد؛ مثلاً رفع خطاهای ناشی از تحویل. تغییر طراحی، افزودن صفحه یا قابلیت جدید معمولاً توسعه جدید محسوب میشود.
اگر هنوز همه امکانات را نمیدانیم چه کنیم؟
نسخه اول را بر اساس اهداف و سناریوهای ضروری تعریف کنید و برای امکانات بعدی بکلاگ جدا بسازید.
مهمترین بند قرارداد کدام است؟
یک بند بهتنهایی کافی نیست؛ اما دامنه کار، معیار تحویل، مالکیت و پشتیبانی بیشترین اختلافهای عملی را پوشش میدهند.
دیدگاهها و تجربهها
برای نوشتن دیدگاه وارد شو
بعد از ورود، دیدگاهت برای بررسی به پنل مدیریت ارسال میشود و پس از تأیید در همین بخش نمایش داده خواهد شد.
ورود به حساب