انتخاب شرکت طراحی سایت؛ Scorecard و Due Diligence

سه شرکت جلسه خوبی برگزار می‌کنند. اولی ۴۰ نمونه‌کار نشان می‌دهد اما نقش خودش در آن‌ها نامعلوم است؛ دومی پیشنهاد فنی ۷۰صفحه‌ای دارد اما تیم اجرا پس از فروش عوض می‌شود؛ سومی قیمت بالاتری می‌دهد، یک ریسک جدی را صریح می‌گوید و حاضر است Content، CRM، Failure، Export و Rollback را در Pilot واقعی نشان دهد. اگر معیار فقط ظاهر و قیمت باشد، مهم‌ترین تفاوت دیده نمی‌شود: کدام ادعا قابل‌راستی‌آزمایی و کدام ریسک قابل‌کنترل است؟

چگونه شرکت طراحی سایت مناسب را انتخاب کنیم؟ ابتدا مسئله و معیار را برای همه یکسان کنید، سپس Claim را به Evidence تبدیل کنید، تیم واقعی و Operating model را بسنجید، ریسک Security/Continuity/Ownership/Exit را بررسی کنید و برای بخش پرریسک یک Pilot پولی و زمان‌دار اجرا کنید. انتخاب خوب یافتن «بهترین شرکت جهان» نیست؛ یافتن کم‌ریسک‌ترین Fit برای Context شماست.

پاسخ کوتاه: فرایند انتخاب در ۹ گام

1. Readiness و Brief مشترک بسازید؛
2. Knockout criteria و Scorecard را پیش از پیشنهادها تعیین کنید؛
3. Longlist را با Evidence عمومی غربال کنید؛
4. RFP یکسان و Clarification log مشترک بدهید؛
5. نمونه‌کار و Reference را مستقل راستی‌آزمایی کنید؛
6. با تیم واقعی Discovery/Delivery جلسه بگذارید؛
7. فنی، امنیت، داده، عملیات و Exit را Due diligence کنید؛
8. Pilot نماینده اجرا و Evidence را مقایسه کنید؛
9. Decision record، Risk و شرط مذاکره قرارداد را ثبت کنید.

اگر Problem، Journey، Scope و Acceptance هنوز مبهم‌اند، نخست نقشه آمادگی شروع طراحی سایت را تکمیل کنید. Vendorها نباید سه مسئله متفاوت را قیمت‌گذاری کنند.

انتخاب را از «نام شرکت» به «مدل تحویل» ببرید

شرکت بزرگ، استودیو کوچک، تیم تخصصی یا Freelancer هرکدام می‌توانند Fit یا Anti-fit باشند. برچسب اندازه به‌تنهایی این پرسش‌ها را پاسخ نمی‌دهد:

گام ۱: Buying brief یکسان بسازید

context/problem/outcome/guardrail
priority audience/journey
current assets/content/data/systems
must/should/won't/no-go
quality/security/privacy/SEO/operations targets
budget range + timeline constraint
ownership/support/exit expectation
risk/assumption/dependency
response format + evidence requested

RFP صدصفحه‌ای لازم نیست؛ اما همه نامزدها باید Scope و سؤال یکسان ببینند. پاسخ Clarification یک شرکت که Scope را تغییر می‌دهد، برای همه نامزدها منتشر شود تا مقایسه منصفانه بماند.

Knockout criteria را پیش از ارائه‌ها تعیین کنید

برخی شروط امتیازی نیستند؛ نبودشان نامزد را از فرایند خارج می‌کند. نمونه، بسته به ریسک:

• پذیرش کنترل سازمان بر Domain/DNS/Cloud/CMS/Repo/Data؛
• افشای Subcontractor و محل/نوع دسترسی به داده؛
• MFA، Role و Offboarding برای دسترسی حساس؛
• پذیرش Security/Privacy/A11y/SEO acceptance نسخه‌دار؛
• امکان Export و Exit rehearsal؛
• نبود تعارض منافع افشانشده‌نشده؛
• پذیرش Incident/Vulnerability notification؛
• عدم استفاده از داده واقعی در Demo/AI بدون مجوز؛
• توان ارائه تیم نام‌برده و ظرفیت آن؛
• پذیرش مالک Risk و Evidence برای Go-live.

Knockout را بعد از دیدن Vendor محبوب تغییر ندهید؛ اگر استثنا لازم است، Risk owner و دلیل را ثبت کنید.

Scorecard را Evidence-weighted طراحی کنید

وزن بالا را به Risk همان پروژه بدهید. فروشگاه متصل به ERP با سایت معرفی ساده یک Scorecard ندارد.

مقیاس امتیاز، کیفیت Evidence را جدا کند

0 = پاسخ/توان وجود ندارد
1 = ادعا یا متن بازاری، بدون شاهد
2 = فرایند توضیح داده شده، شاهد ضعیف/نامرتبط
3 = شاهد مرتبط و قابل‌بررسی، Gap شناخته
4 = شاهد مرتبط + محدودیت/نتیجه/مالک روشن
5 = شاهد مستقل/اجرایی + یادگیری/بهبود + Fit دقیق

Confidence و Red flag را جدا از Score ثبت کنید. میانگین عددی نباید Knockout یا ریسک فاجعه‌بار را پنهان کند.

گام ۲: Longlist و تضاد منافع

Website، LinkedIn یا معرفی شبکه فقط Lead است. برای Shortlist این موارد را بررسی کنید:

• هویت حقوقی/فاکتور/آدرس و کانال رسمی؛
• سابقه نام، دامنه و ادعاهای قابل‌پیگیری؛
• مالک/مدیران و تعارض با تأمین‌کننده/تبلیغ/Hosting؛
• Project fit و ظرفیت زمانی؛
• سیاست Privacy/Security و راه تماس Incident؛
• نوع قرارداد با Freelancer/Subcontractor؛
• وابستگی به یک فرد کلیدی؛
• نحوه استفاده از Logo/Case/Review مشتری.

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

نمونه‌کار را از Screenshot به Case evidence تبدیل کنید

client/context + problem/outcome
scope/constraints + exact vendor role
named disciplines/subcontractors
before baseline + method
artifact/live URL + date/version
quality/operations evidence
result + attribution limits
failure/learning + client permission

سایت زنده را با Mobile، Keyboard، Form، Error، Performance و URLها ببینید. اما وضعیت امروز ممکن است پس از تحویل توسط مشتری تغییر کرده باشد؛ Vendor باید نسخه/نقش و محدودیت Attribution را توضیح دهد.

سؤال‌های نمونه‌کار که جواب حفظی را می‌شکنند

• کدام فرض اولیه اشتباه درآمد و چه چیزی تغییر کرد؟
• چه کاری را عمداً نساختید و چرا؟
• سخت‌ترین Failure/Integration چه بود؟
• نتیجه را چگونه از روند قبلی یا عامل بیرونی جدا کردید؟
• کدام بخش کار Subcontractor یا تیم مشتری بود؟
• چه Defectی بعد از Launch رخ داد و پاسخ چه بود؟
• اگر دوباره اجرا کنید چه چیزی عوض می‌شود؟
• امروز چه کسی سیستم را نگهداری می‌کند؟

پاسخ دقیق درباره شکست و محدودیت معمولاً از ادعای «همه‌چیز عالی پیش رفت» قابل‌اعتمادتر است.

Reference check را مستقل و سناریومحور انجام دهید

فقط با مشتری کاملاً راضی معرفی‌شده صحبت نکنید. اگر مجاز است، هویت Contact را از کانال رسمی سازمان مقصد تأیید کنید. سؤال‌ها:

• تیم فروخته‌شده با تیم اجرا یکی بود؟
• Scope/Time/Cost چگونه تغییر کرد و چه کسی زود هشدار داد؟
• کیفیت Content/UX/Code/Test/Docs چگونه بود؟
• در اختلاف یا Incident چه رفتاری داشتند؟
• دسترسی و مالکیت در پایان کامل بود؟
• پس از خروج Vendor توان ادامه داشتید؟
• چه هزینه/وابستگی‌ای در Proposal روشن نبود؟
• با همین Context دوباره انتخاب می‌کنید؟ چرا؟

Reference یک Data point است؛ NDA، زمان گذشته و Selection bias را ثبت کنید.

با تیم واقعی کارگاه بگذارید، نه فقط Sales

Product/Project lead، Content/UX، Technical lead و فرد مسئول QA/Ops متناسب با Scope در جلسه حاضر شوند. یک Scenario واقعی بدهید و نحوه سؤال/تفکر/اختلاف را مشاهده کنید:

سناریو: callback پرداخت دو بار می‌رسد، سفارش در ERP دیر ثبت می‌شود
و مشتری صفحه موفقیت دیده است.
چه سؤال‌هایی می‌پرسید؟ source of truth چیست؟
چگونه idempotency/reconciliation/support/telemetry/acceptance می‌سازید؟

هدف آزمون رایگان چندروزه یا گرفتن طراحی کامل نیست؛ دیدن کیفیت Reasoning و همکاری روی مسئله محدود است.

تیم نام‌برده، Capacity و جایگزینی را بررسی کنید

رزومه فردی که در پروژه حضور ندارد امتیاز نیست.

فرایند را با Artifact واقعی بسنجید

از Vendor بخواهید نمونه Redacted این موارد را نشان دهد:

• Discovery question/decision/risk log؛
• Content model و Claim review؛
• Journey/Prototype test evidence؛
• ADR و Integration contract؛
• Definition of Done و Test result؛
• Change request با اثر Time/Cost/Risk؛
• Release/rollback/incident record؛
• Handover/Runbook/Export inventory.

Template زیبا کافی نیست؛ بپرسید Artifact چگونه تصمیم را عوض کرده است. برای مدل جریان خوب از فرایند طراحی سایت کمک بگیرید.

Architecture را بر اساس Trade-off بسنجید

پاسخ خوب «همیشه WordPress/Next.js/Custom» نیست. Vendor باید Context، گزینه‌ها و Consequence را توضیح دهد:

• Capability و change frequency؛
• Content author workflow؛
• Team skill و operating model؛
• Integration/Data/Source of truth؛
• Performance/A11y/Security/SEO؛
• Hosting/License/Update/Support؛
• Portability/Export/Exit/TCO.

راهنمای انتخاب روش ساخت سایت Builder/CMS/Headless/Custom را بدون تعصب مقایسه می‌کند. Vendor باید Anti-fit راه‌حل خودش را نیز بگوید.

Due diligence امنیت؛ سؤال، Requirement و شاهد

NCSC Supplier assurance questions مسئول Security، Incident/Recovery، Network/Cloud، Data، Personnel، Assurance مستقل و شروط قراردادی را بررسی می‌کند. Cloud و Subcontractor خارج Scope امنیت Vendor نیستند.

NIST SSDF و OWASP ASVS را درست استفاده کنید

NIST SSDF 1.1 فعالیت‌ها را در Prepare، Protect، Produce و Respond گروه‌بندی می‌کند؛ یعنی توسعه امن فقط Pen test آخر نیست. از Vendor بپرسید Requirement/Risk/Decision و Provenance Component چگونه Track می‌شوند و Vulnerability پس از Release چگونه پاسخ می‌گیرد.

OWASP ASVS 5.0.0 مبنای Requirement و Verification فنی در Procurement است. Requirementهای مرتبط را با Version/ID/Applicability انتخاب کنید؛ درخواست «کاملاً ASVS» بدون Scope/Level/Evidence قابل‌ارزیابی نیست.

Privacy و استفاده از ابزار AI را شفاف کنید

• چه داده‌ای برای چه Purpose جمع/پردازش می‌شود؟
• Vendor/Subprocessor/کشور/محل ذخیره چیست؟
• Retention، Backup، Delete و Export چگونه‌اند؟
• آیا Prompt، Code، Content، Log یا داده مشتری به AI می‌رود؟
• آیا Provider داده را برای Training نگه می‌دارد؟
• Secret/PII/Production data چگونه از ابزار عمومی دور می‌ماند؟
• Human review، IP/license و Incident response چیست؟

نام Tool جای Data-flow و Control را نمی‌گیرد. پاسخ باید با قرارداد و تنظیمات واقعی هماهنگ باشد.

Quality را از «تست می‌کنیم» به Portfolio تبدیل کنید

Vendor باید Risk→Test→Environment→Evidence→Owner→Release decision را نشان دهد. حداقل بر اساس Scope:

• Content/visual/RTL/mobile؛
• Unit/component/contract/integration/E2E؛
• Accessibility automated/manual/user؛
• Security/privacy؛
• Performance field/lab budget؛
• SEO HTTP/source/render/index؛
• Migration/reconciliation؛
• Deploy/backup/restore/rollback.

برای تشخیص عمق ادعا از راهنمای Test portfolio وب استفاده کنید.

عملیات و پشتیبانی را پیش از خرید شبیه‌سازی کنید

راهنمای Observability سایت برای سؤال‌های SLO/Alert/Runbook مفید است.

مالکیت را Asset-by-Asset بسنجید

asset/account | legal/business owner | admin | MFA/recovery
billing/renewal | license/IP | export format | handover evidence
vendor dependency | emergency access | deletion/offboarding

Domain، DNS، Hosting/Cloud، Repo، CMS، Design file، Content/Media، Font، Data، Analytics/Search Console، Tag manager، Email/SMS/Payment و Documentation هرکدام قرارداد متفاوت دارند. «مالکیت کامل سایت» بدون Inventory مبهم است.

Exit test را قبل از Entry اجرا کنید

GOV.UK Open Standards Principles بر انعطاف، انتقال داده و برآورد هزینه Exit/Migration از ابتدای پروژه تأکید دارد. برای پروژه شما الزام حقوقی ایجاد نمی‌کند، اما یک اصل خرید قوی می‌دهد: قابلیت خروج را پیش از Lock-in بسنجید.

• نمونه Export Content/Data/Media/Config؛
• Build/deploy در حساب سازمان؛
• Repo history و dependency/license inventory؛
• DNS/Cloud/CMS admin recovery؛
• Runbook/ADR/schema/redirect/test evidence؛
• Knowledge transfer و Transition assistance؛
• Return/delete data و تأیید Offboarding؛
• هزینه/زمان/فرمت Exit و محدودیت Proprietary.

برای اجرای فنی Exit و مهاجرت از راهنمای مهاجرت و Cutover استفاده کنید.

قیمت را فقط پس از نرمال‌سازی Scope مقایسه کنید

Rate یا Lump sum را کنار Assumption، Exclusion، Currency/Tax، Third-party، Payment trigger و Change mechanism ببینید. راهنمای TCO و هزینه‌های پنهان سایت مقایسه را کامل می‌کند.

پیشنهاد را با «Compliance matrix» بخوانید

requirement_id | vendor response(comply/partial/no/alternative)
assumption/dependency | evidence link | owner
cost/time impact | exception/risk | clarification/decision

عبارت «مطابق RFP» بدون Mapping قابل‌بررسی نیست. Alternative می‌تواند بهتر باشد؛ Vendor باید Trade-off را توضیح دهد.

Pilot پولی، کوچک و نماینده اجرا کنید

کار رایگان طولانی اخلاقی و قابل‌اعتماد نیست. Pilot را محدود، مالکیت‌دار و قابل‌پرداخت طراحی کنید. یک Vertical slice پرریسک انتخاب کنید: مثلاً Service→Form→CRM یا Product→Payment sandbox.

Pilot نباید فقط صفحه Home باشد اگر ریسک اصلی Integration یا Migration است.

Blind review و کنترل Bias

• وزن و معیار پیش از نام/قیمت نهایی؛
• دو ارزیاب مستقل برای بخش‌های کلیدی؛
• Evidence note کنار هر Score؛
• Price review پس از Technical threshold؛
• ثبت Conflict و رابطه قبلی؛
• عدم امتیازدهی به Presentation polish خارج معیار؛
• جلسه Calibration برای اختلاف Score؛
• Decision record شامل نامزد ردشده و دلیل.

ارزان‌ترین یا آشناترین گزینه ممکن است درست باشد؛ فرایند باید نشان دهد چرا.

Risk-adjusted score از جمع ساده بهتر است

Score بالا با یک Knockout امنیتی یا Exit ناممکن برنده نیست. تصمیم نهایی سه نما داشته باشد:

weighted fit score
+ confidence/evidence quality
+ residual risk & mitigation/owner
+ normalized TCO/range
+ pilot result
= decision with conditions

شرط مذاکره مانند «قبل از امضا Subcontractor register» یا «قبل از Build Export test» تاریخ و Owner بگیرد.

نشانه‌های هشدار جدی

• تضمین رتبه اول یا امنیت ۱۰۰٪؛
• قیمت/تاریخ قطعی بدون Brief و Assumption؛
• نمونه‌کار بی‌URL، نقش یا اجازه؛
• تیم فروش قوی و تیم اجرا نامعلوم؛
• امتناع از افشای Subcontractor/Cloud/Data flow؛
• Domain/Hosting/Repo فقط در حساب شخصی Vendor؛
• «کد اختصاصی» بدون Export/Docs/License؛
• Pen test/Certificate بی‌Scope، تاریخ یا Remediation؛
• Production data در Demo، Laptop یا AI عمومی؛
• عدم وجود Staging/Review/Backup/Restore/Rollback؛
• پشتیبانی بدون Severity/SLA/Exclusion؛
• Change شفاهی و Invoice مبهم؛
• فشار پرداخت کامل پیش از Evidence؛
• حذف Quality برای تاریخ بدون Risk record؛
• مقاومت در برابر Pilot یا Exit test معقول.

نمونه Decision record نهایی

decision/scope/date/decision owner
candidates & knockout result
weighted scores + evidence confidence
reference/pilot findings
normalized cost/TCO/range
top residual risks + owner/mitigation
conditions before contract/build/launch
why selected / why alternatives rejected
review trigger + approval

این سند جای قرارداد نیست؛ ورودی مذاکره قرارداد مقاله ۱۷۸۰ است و از تحریف دلیل انتخاب جلوگیری می‌کند.

منابع و وضعیت زمانی

این راهنما در ۱۲ اوت ۲۰۲۶ بازبینی شده است. Security، Tool، قوانین و وضعیت Vendor تغییر می‌کنند؛ Evidence را با Scope و تاریخ همان خرید تازه کنید.

• NCSC: Supplier assurance questions
• NIST: Secure Software Development Framework 1.1
• OWASP ASVS 5.0.0
• GOV.UK: Open Standards Principles

سؤالات متداول انتخاب شرکت طراحی سایت

چند شرکت طراحی سایت را مقایسه کنیم؟

عدد جهانی وجود ندارد. Longlist را با Knockout غربال و Shortlist کوچکی بسازید که ارزیابی عمیق آن ممکن باشد؛ معمولاً دو تا چهار نامزد جدی از ده Proposal سطحی مفیدترند. زمان Reference، workshop و Pilot را نیز حساب کنید.

نمونه‌کار مهم‌تر است یا قیمت؟

هیچ‌کدام تنها کافی نیست. نمونه‌کار باید نقش، Context، محدودیت و Evidence داشته باشد؛ قیمت نیز باید روی Scope، Assumption، Quality، TCO و Exit یکسان نرمال شود. Fit، ریسک باقیمانده و توان تحویل تصمیم را می‌سازند.

چطور ادعای نتیجه یک شرکت را بررسی کنیم؟

Baseline، روش، بازه، نقش دقیق، URL/version، عوامل بیرونی، اجازه مشتری و Reference را بخواهید. Correlation یا Revenue بعد از Launch به‌تنهایی Attribution نیست؛ محدودیت ادعا باید روشن باشد.

آیا Pilot قبل از قرارداد اصلی لازم است؟

برای پروژه پرریسک یا Vendor ناشناخته بسیار مفید است. Pilot کوچک، پولی، زمان‌دار و نماینده ریسک باشد و Acceptance/مالکیت/محرمانگی خودش را داشته باشد؛ صفحه نمایشی رایگان جای Pilot نیست.

از کجا بفهمیم به شرکت طراحی سایت وابسته نمی‌شویم؟

کنترل سازمان بر حساب‌ها، Repo و Data؛ Export واقعی؛ استاندارد/فرمت مستند؛ License روشن؛ Runbook/ADR/Test evidence؛ Knowledge transfer؛ Subcontractor register و Exit rehearsal را بررسی کنید. وعده «تحویل کامل» بدون Asset inventory کافی نیست.

جمع‌بندی: بهترین پاسخ، بهترین Evidence است

شرکت مناسب لزوماً بزرگ‌ترین Portfolio یا پایین‌ترین قیمت را ندارد. مسئله را بهتر Reframe می‌کند، محدودیت راه‌حل خودش را می‌گوید، تیم واقعی و Risk را شفاف می‌کند، Security/Quality/Operations را قابل‌آزمون می‌سازد و خروج شما را نیز طراحی می‌کند.

پیش از جلسه بعد، فقط سه کار انجام دهید: Knockoutها را بنویسید، Scorecard را وزن دهید و از هر Claim یک Evidence قابل‌بررسی بخواهید. اگر تصمیم را نمی‌توان با سندی کوتاه برای مدیر غایب توضیح داد، هنوز احتمالاً Presentation را انتخاب کرده‌اید، نه شریک تحویل را.