چطور پیشنهادهای طراحی سایت را منصفانه مقایسه کنیم؟
روش پنج‌گامی برای مقایسهٔ شواهدمحور پیشنهادهای طراحی سایت: بریف واحد، جدول محدودهٔ یکسان، پرسش‌های قابل‌سنجش، هزینهٔ سال اول و امتیازدهی وزنی.
SE
7 min readSoheil Ebrahimpour
Founder & product engineer
برای مقایسهٔ منصفانهٔ پیشنهادهای طراحی سایت، اول باید همه را روی یک محدودهٔ مشترک بنشانید و بعد قیمت‌ها را ببینید. اگر هر شرکت جواب یک سؤال متفاوت داده باشد، مقایسهٔ مبلغ‌ها فقط مقایسهٔ عددهای بی‌ربط است. روش پیشنهادی این مقاله پنج گام دارد: یک بریف واحد، جدول محدودهٔ یکسان، پرسش‌های شواهدمحور، هزینهٔ سال اول، و امتیازدهی وزنی که تصمیم نهایی را مکتوب می‌کند. جمع‌بندی‌های روش، توصیهٔ نویسنده است و جز جاهایی که منبع آمده، یافتهٔ پژوهشی نیست.
گام ۱: همه باید به یک سؤال جواب داده باشند
یک خلاصهٔ مشترک برای همهٔ شرکت‌ها بفرستید: مخاطبان سایت، فهرست صفحه‌ها و ماژول‌ها، آمادگی محتوا، زبان‌ها، اتصال‌ها (مثل فرم، پرداخت یا CRM)، موعد دلخواه راه‌اندازی و مدل پشتیبانی. از هر شرکت بخواهید سه فهرست جدا بنویسد: چه چیزی در مبلغ پیشنهادی هست، چه چیزی اختیاری و جداگانه قیمت‌گذاری شده، و چه چیزی صریحاً خارج از پیشنهاد است. بدون این سه فهرست، عبارت‌هایی مثل «سایت شرکتی» یا «سئو شده» می‌توانند معنی‌های بسیار متفاوتی داشته باشند.
اگر هنوز بریف مکتوب ندارید، کار اصلی اول همان است. برای نوشتن بریف، برنامه‌ریزی پروژه پیش از نوشتن کد و برای تصمیم دربارهٔ فناوری مقایسهٔ WordPress و توسعهٔ اختصاصی را ببینید.
چرا قیمت‌ها اینقدر متفاوت‌اند؟
Steve McConnell در توضیح «مخروط عدم‌قطعیت» می‌نویسد برآوردی که در مرحلهٔ «ایدهٔ اولیه» ساخته می‌شود می‌تواند تا ۴ برابر بالا یا پایین باشد، و دقت برآورد به میزان روشنی تعریف نرم‌افزار بستگی دارد. این دربارهٔ برآورد نرم‌افزار به‌طور عام است و عددی برای سایت‌ها نمی‌دهد، اما نتیجهٔ عملی‌اش روشن است: اگر دو پیشنهاد فاصلهٔ زیادی دارند، قبل از اینکه یکی را «گران» یا «ارزان» بنامید، بپرسید هرکدام چه فرض‌هایی درباره محدوده، محتوا و تغییرات دارند. هرچه بریف دقیق‌تر باشد، پیشنهادها قابل‌مقایسه‌تر می‌شوند.
گام ۲: جدول محدودهٔ یکسان بسازید
ردیف‌ها را از بریف خودتان بسازید، نه از پیشنهاد یک شرکت. برای هر سلول فقط یکی از چهار وضعیت را ثبت کنید: «شامل (مکتوب)»، «جزئی»، «ندارد» یا «نامشخص». هر چیزی که در پیشنهاد ننوشته شده، «نامشخص» است نه «شامل».
| ردیف | شرکت الف | شرکت ب | شرکت ج |
|---|---|---|---|
| فهرست صفحه‌ها و تعداد دور بازبینی طراحی | |||
| مسئول تهیه و ورود محتوا | |||
| قابلیت‌ها: فرم‌ها، مدیریت محتوا، چندزبانگی | |||
| انتقال از سایت قدیمی و برنامهٔ ریدایرکت | |||
| معیار پذیرش: دسترس‌پذیری، سرعت، سئوی فنی | |||
| امنیت و پشتیبان‌گیری | |||
| مالکیت کد، دامنه، میزبانی و حساب‌ها | |||
| تحویل و آموزش | |||
| پشتیبانی بعد از انتشار و حدود آن | |||
| مواردی که صریحاً خارج از پیشنهاد است |
گام ۳: پرسش‌هایی که پاسخشان را می‌شود سنجید
به‌جای «سایت سریع و دسترس‌پذیر و امن» از هر شرکت بخواهید مشخص بنویسد چطور آنها را اندازه می‌گیرد. چند نمونه با پشتوانهٔ منبع:
دسترس‌پذیری
بپرسید هدف کدام نسخه و سطح WCAG است و کدام صفحه‌ها و فرایندها با چه روشی بررسی می‌شوند. W3C می‌گوید انتخاب سطح (A، AA یا AAA) اساساً تصمیم سیاستی است، تطابق برای صفحهٔ کامل تعریف می‌شود و در فرایندهای چندصفحه‌ای مثل خرید همهٔ صفحه‌های فرایند باید مطابق باشند. پس پیشنهادی که فقط می‌نویسد «سایت دسترس‌پذیر» چیز اندازه‌گیری‌شدنی نگفته است.
سرعت
بپرسید معیار سرعت چیست. web.dev برای Core Web Vitals آستانه‌های LCP تا ۲٫۵ ثانیه، INP حداکثر ۲۰۰ میلی‌ثانیه و CLS حداکثر ۰٫۱ را در صدک ۷۵ بارگذاری‌ها معرفی می‌کند. شرکتی که می‌گوید «سایت سریع می‌سازیم» باید بگوید روی چه صفحه‌هایی و با چه ابزاری این شاخص‌ها را گزارش می‌دهد؛ توجه کنید که این‌ها دادهٔ میدانی‌اند و برای سایت تازه یا کم‌بازدید ممکن است دادهٔ کافی وجود نداشته باشد.
سئوی فنی و انتقال
اگر سایت قدیمی دارید و آدرس‌ها تغییر می‌کند، بپرسید نقشهٔ ریدایرکت چطور ساخته می‌شود. راهنمای انتقال سایت Google توصیه می‌کند آدرس‌های قدیمی را از منابعی مثل sitemap، لاگ سرور یا ابزار تحلیل و Search Console فهرست کنید، آنها را به آدرس‌های جدید نگاشت کنید و تغییرات بزرگ را یکی‌یکی انجام دهید. دربارهٔ نتیجهٔ جست‌وجو هم هیچ شرکتی نباید رتبه تضمین کند: Google خودش می‌گوید تضمینی برای افزوده‌شدن سایت به نمایه وجود ندارد.
امنیت
پروژهٔ OWASP در «Secure Software Contract Annex» می‌نویسد بیشتر قراردادها دربارهٔ امنیت ساکت‌اند و طرفین اغلب برداشت‌های کاملاً متفاوتی از آنچه توافق شده دارند؛ و در همان سند به نقل از John Pescatore (Gartner) پیشنهاد می‌شود دست‌کم هر درخواست پیشنهاد نرم‌افزار از فروشنده بخواهد شرح بدهد محصولش را چگونه برای آسیب‌پذیری‌ها آزمایش می‌کند. خود OWASP تأکید می‌کند آن سند فقط راهنما است و باید با وکیل مشورت شود. NIST نیز در SSDF (نسخهٔ ۱٫۱) می‌گوید خریداران نرم‌افزار می‌توانند از آن زبان مشترک برای ارتباط با تأمین‌کنندگان استفاده کنند. برای پروژهٔ سایت لازم نیست این اسناد را کامل اجرا کنید؛ ولی می‌توانید بپرسید: بازبینی کد، به‌روزرسانی وابستگی‌ها، پشتیبان‌گیری و دسترسی‌ها چگونه مدیریت می‌شود؟
گام ۴: هزینهٔ سال اول را کامل جمع بزنید
قیمت ساخت فقط بخشی از هزینه است. برای هر پیشنهاد این ردیف‌ها را جدا بنویسید (بدون اینکه عدد بازار حدس بزنید؛ فقط از خود پیشنهادها و صورت‌حساب‌ها بردارید): ساخت، دامنه، میزبانی، لایسنس قالب یا افزونه، پشتیبانی بعد از انتشار، هزینهٔ تغییرات خارج از محدوده، و هزینهٔ انتقال یا تمدید. اگر عددی ننوشته‌اند، همان ردیف را «نامشخص» بگذارید و بپرسید.
گام ۵: امتیازدهی وزنی و ثبت دلیل تصمیم
برای هر معیار وزن بدهید (جمع وزن‌ها ۱۰۰ باشد) و برای هر پیشنهاد نمره‌ای بر اساس آنچه مکتوب آمده بدهید، نه آنچه در تماس تلفنی شنیدید. وزن‌ها باید از اولویت خود شما بیاید؛ مثال زیر کاملاً فرضی است:
| معیار | وزن (فرضی) | نمرهٔ الف (۰–۱۰) | نمرهٔ ب (۰–۱۰) |
|---|---|---|---|
| وضوح محدوده و خارج از محدوده | 30 | 8 | 5 |
| تحویل، مالکیت و دسترسی‌ها | 25 | 7 | 8 |
| معیار پذیرش قابل‌سنجش | 20 | 6 | 5 |
| پشتیبانی و شفافیت هزینه | 25 | 7 | 7 |
در این مثال، امتیاز هر شرکت جمع (وزن × نمره ÷ ۱۰) است. اما یک امتیاز بالا نباید یک نیاز حیاتی را بپوشاند: مثلاً اگر تحویل کد برایتان شرط است، پیشنهادی که آن را نمی‌دهد بدون توجه به امتیاز حذف می‌شود. در پایان دلیل انتخاب را در یک صفحه بنویسید تا بعداً قابل مراجعه باشد.
نشانه‌های هشدار
- پیشنهاد بدون فهرست صفحه‌ها، دور بازبینی و موارد خارج از محدوده.
- وعدهٔ رتبه یا ترافیک مشخص.
- تأکید بر قیمت یکجا بدون ریز و بدون توضیح هزینهٔ پس از انتشار.
- مبهم‌بودن مالکیت دامنه، کد و حساب‌ها.
- تمایل‌نداشتن به پاسخ مکتوب به پرسش‌های شما.
چک‌لیست سریع
- همه یک بریف مشترک گرفته‌اند.
- هر پیشنهاد سه فهرست شامل/اختیاری/خارج را دارد.
- جدول محدوده با چهار وضعیت پر شده است.
- پرسش‌های دسترس‌پذیری، سرعت، سئوی فنی و امنیت پاسخ مکتوب گرفته‌اند.
- هزینهٔ سال اول کامل جمع شده است.
- وزن‌ها پیش از دیدن امتیازها تعیین شده‌اند.
- دلیل انتخاب نهایی مکتوب شده است.
اگر می‌خواهید مسئله و محدودیت‌های پروژه‌تان را پیش از ارسال بریف برای شرکت‌ها مرور کنید، می‌توانید آن را در صفحهٔ شروع پروژه بنویسید؛ طبق توضیح خود صفحه، ارسال فرم تعهدی برای شروع پروژه ایجاد نمی‌کند.
منابع و مراجع
- Software Development's Cone of Uncertainty — Steve McConnell، Construx، White Paper نسخهٔ ۱، ژانویهٔ ۲۰۱۰.
- Understanding Conformance (WCAG 2.2) — W3C WAI.
- Web Vitals — web.dev (Google)، آخرین به‌روزرسانی ۳۱ اکتبر ۲۰۲۴.
- Site Moves and Migrations (How to move a site) — Google Search Central.
- Search Engine Optimization (SEO) Starter Guide — Google Search Central.
- Secure Software Contract Annex — OWASP Foundation (نویسنده: Jeff Williams).
- Secure Software Development Framework (SSDF) Version 1.1 (NIST SP 800-218) — NIST، فوریهٔ ۲۰۲۲.
Author
SE
Soheil Ebrahimpour is the founder of FutureForge. He works on product design, architecture, and getting custom software into production.
Related notes
If you are unsure about architecture or the build path, we can talk about the project.
Describe the problem and the constraints. If there is a fit, we will schedule a conversation.
