دو شرکت برای یک «سایت شرکتی» قیمت ۸۰ و ۲۴۰ میلیون تومان میدهند. آیا دومی سه برابر گرانتر است؟ تا وقتی ندانیم هر پیشنهاد دقیقاً چه Outcome، صفحهالگو، قابلیت، محتوا، Integration، آزمون، تحویل و پشتیبانیای را پوشش میدهد، این دو عدد اصلاً قابل مقایسه نیستند. قیمت طراحی سایت حاصل جمع چند صفحه نیست؛ بهای تبدیل یک مسئله کسبوکار به Scope قابل تحویل، همراه با سطح کیفیت و ریسکی مشخص است.
این راهنما بهجای اعلام تعرفهای که با زمان، نرخ ارز، فناوری و دامنه پروژه تغییر میکند، یک روش قابلممیزی برای برآورد هزینه طراحی سایت میسازد: ابتدا Cost boundary را مشخص میکنیم، سپس Scope را به WBS تبدیل میکنیم، محرکهای هزینه را میسنجیم، عدمقطعیت را به بازه تبدیل میکنیم و در پایان Quoteهای فروشندگان را همسطح مقایسه میکنیم. خروجی مطلوب یک عدد جادویی نیست؛ یک Estimate مستند است که فرضها، استثناها و شرایط تغییرش روشناند.
اول زبان مشترک بسازید: Price، Cost، Estimate، Budget و TCO
بخش بزرگی از اختلاف بر سر «هزینه سایت» از اینجا میآید که واژههای متفاوت را یکسان فرض میکنیم. مدیر ممکن است درباره سقف پرداخت حرف بزند، تیم فنی درباره نفرـروز ساخت و فروشنده درباره مبلغ قرارداد. پیش از هر محاسبه، تعریف عملیاتی این واژهها را در صورتجلسه Discovery ثبت کنید.
| مفهوم | پرسش | آنچه باید ثبت شود | خطای رایج |
|---|---|---|---|
| Price / قیمت | فروشنده برای تعهد قراردادی چه مبلغی میخواهد؟ | مالیات، شرایط پرداخت، ارز، اعتبار زمانی Quote | یکیدانستن قیمت با کل هزینه مالکیت |
| Cost / هزینه | برای تولید و بهرهبرداری چه منابعی مصرف میشود؟ | نیروی داخلی، خرید خارجی، زمان، زیرساخت و ریسک | نادیدهگرفتن وقت تیم کارفرما |
| Estimate / برآورد | با دانستههای فعلی، هزینه محتمل چقدر است؟ | بازه، تاریخ، مبنا، فرض، Confidence و روش | نمایش یک عدد دقیق در مرحله مبهم |
| Budget / بودجه | سازمان چه سقف و زمانبندی منابعی تصویب کرده؟ | Cap، Cash flow، Reserve و اختیار تصویب | تغییر Scope برای جا دادن عدد بدون ثبت Trade-off |
| Quote / پیشنهاد قیمت | تأمینکننده در برابر چه Deliverable و Acceptance متعهد است؟ | شمول، استثنا، وابستگی، مالک، تغییر و ضمانت | مقایسه فقط رقم انتهای پیشنهادها |
| TCO / هزینه کل مالکیت | ساخت، بهرهبرداری، تغییر و خروج در افق تصمیم چه هزینهای دارند؟ | Setup، تکرارشونده، متغیر، داخلی، ریسک و Exit | انتخاب ارزانترین Build با عملیات گران |
این مقاله مالک «محرک هزینه و روش Estimate پیش از دریافت Quote» است. اگر مسئله شما سقف بودجه، پرداخت مرحلهای و کنترل تغییر است، راهنمای بودجه طراحی سایت مسیر کاملتری دارد. برای ثبت هزینههای تمدید، خرابی، عملیات و خروج نیز از راهنمای TCO و هزینههای پنهان سایت استفاده کنید.
مدل برآورد هزینه طراحی سایت: عدد از کجا میآید؟
یک مدل ساده و شفاف میتواند نقطه شروع باشد؛ نه قانون ثابت قیمتگذاری:
Estimate = مجموع (Work package × Effort × Loaded rate) + خرید شخص ثالث + ذخیره ریسک − ارزش داراییهای واقعاً قابل استفاده مجدد
Effort میتواند نفرـساعت یا نفرـروز باشد. Loaded rate فقط دستمزد برنامهنویس نیست و سهم مدیریت، طراحی، QA، ابزار و سربار قابل انتساب را نیز بازتاب میدهد. خرید شخص ثالث شامل License، سرویس ابری یا محتوای دارای مجوز است. ذخیره ریسک باید از Risk register و عدمقطعیت شناختهشده بیاید؛ نه درصدی پنهان که فروشنده نتواند توضیح دهد. دارایی قابل استفاده مجدد نیز تنها زمانی کاهنده هزینه است که از نظر کیفیت، License و تناسب با معماری جدید بررسی شده باشد.
راهنمای Cost Estimating دفتر پاسخگویی دولت آمریکا بر جامع، مستند، دقیق و معتبر بودن برآورد و بهروزرسانی آن با داده واقعی تأکید میکند. این اصول را میتوان برای پروژه وب کوچک هم بهصورت سبک اجرا کرد: هر عدد باید به Scope، فرض و شاهد قابل ردیابی باشد، نه به حس فروشنده یا «قیمت بازار». منبع: GAO Cost Estimating and Assessment Guide.
| ویژگی Estimate قابل دفاع | شاهد حداقلی | آزمون بازبینی |
|---|---|---|
| جامع | WBS، کار داخلی و بیرونی، هزینه شخص ثالث و ریسک | آیا کاری برای Launch لازم است اما Owner یا هزینه ندارد؟ |
| مستند | نسخه Scope، تاریخ نرخ، فرضها، منبع داده و روش | آیا فرد دیگری میتواند محاسبه را بازسازی کند؟ |
| معتبر | بازه، تحلیل حساسیت و سناریوی ریسک | کدام سه فرض بیشترین تغییر را در نتیجه میدهند؟ |
| کالیبره | Estimate-to-actual پروژههای مشابه | خطای برآورد قبلی در کدام Work package بیشتر بود؟ |
| بهروز | Re-estimate پس از Discovery، طراحی و تغییر Scope | آیا Baseline هنوز با واقعیت تحویل همخوان است؟ |
بلوغ برآورد را با بلوغ اطلاعات هماهنگ کنید
در اولین جلسه فقط میتوان یک بازه ابتدایی یا Rough order ساخت. بعد از Discovery و روشنشدن Journey، محتوا، Integration و سطح کیفیت، بازه باریکتر میشود. Baseline زمانی معنا دارد که Requirement و Acceptance به اندازه کافی تثبیت شده باشند. هرچه اطلاعات کمتر است، نمایش رقم دقیقتر نشانه حرفهایبودن نیست؛ نشانه پنهانکردن عدمقطعیت است.
| مرحله | ورودی موجود | خروجی مناسب | تصمیم مجاز |
|---|---|---|---|
| ایده | Outcome، کاربران و محدودیتهای درشت | بازه بسیار اولیه و Analogous | ارزش ادامه Discovery |
| Discovery | Journey، Content inventory، گزینههای فنی و ریسکها | Scenario estimate و اولویت آزمایش | انتخاب MVP و مسیر اجرا |
| تعریف Scope | WBS، Deliverable، NFR و Acceptance | Bottom-up range و Quote pack | مقایسه تأمینکننده |
| قرارداد/Baseline | Scope مصوب، Assumption log و Change route | Cost baseline و Reserve | تعهد، پرداخت و Governance |
| اجرا | Actual effort، تغییر و ریسک تحققیافته | Estimate at completion | اصلاح ظرفیت، Scope یا زمان |
قبل از قیمتگیری، Scope قابل قیمتگذاری بسازید
Scope خوب با فهرست صفحه شروع نمیشود؛ با Outcome و نیاز کاربر شروع میشود. GOV.UK توصیه میکند پیش از طراحی راهحل، بفهمید کاربران چه کسانیاند، چه میخواهند انجام دهند، اکنون چگونه این کار را انجام میدهند و چه مانعی دارند. این نگاه جلوی قیمتگذاری یک راهحل ازپیشفرضشده را میگیرد. منابع: Starting with user needs و Scoping your service.
یک Scope basis فشرده باید حداقل این هشت جزء را روشن کند:
- Outcome: چه تغییر قابلاندازهگیری برای کسبوکار یا کاربر مطلوب است؟
- User و task: کدام گروه، کدام کار را در چه شرایطی انجام میدهد؟
- Journey و boundary: تجربه از کجا آغاز و کجا تمام میشود؛ چه بخشهایی خارجاند؟
- Content و data: چه چیزی ساخته، پاکسازی، مهاجرت، ترجمه یا آرشیو میشود؟
- Capability: سامانه باید چه رفتاری داشته باشد، نه صرفاً چه صفحهای نشان دهد؟
- NFR: معیار Performance، Accessibility، Security، Availability و Privacy چیست؟
- Operations: پس از Launch چه تیمی محتوا، سفارش، خطا و درخواست کاربر را اداره میکند؟
- Acceptance: چه شاهدی تحویل موفق هر جزء را اثبات میکند؟
اگر این اطلاعات هنوز معلوم نیست، یک Discovery زمانبندیشده را بهعنوان Work package مستقل قیمتگذاری کنید. Discovery قرار نیست ماهها تحلیل بدون خروجی باشد؛ باید عدمقطعیتهای پرهزینه را کم و گزینههای قابل اجرا را مقایسه کند. منبع: How the discovery phase works.
Scope را به WBS تحویلپذیر تبدیل کنید
WBS پروژه وب، کار را به بستههایی میشکند که بتوان برایشان Owner، Effort، Deliverable، Dependency و Acceptance تعریف کرد. WBS نباید صرفاً نام نقشها یا فازهای مبهمی مثل «برنامهنویسی کامل» باشد.
| Work package | خروجی نمونه | محرک Effort | شاهد پذیرش |
|---|---|---|---|
| Discovery و معماری خدمت | Journey، Scope boundary، Options و Risk log | تعداد گروه کاربر، ذینفع و ابهام | تصمیمهای ثبتشده و فرضهای قابل آزمون |
| UX و Content design | Flow، Wireframe، Information architecture و Content model | تنوع Task و سطح پژوهش | Task test و Approval مشخص |
| Visual/UI system | Token، Component و State | سطح تمایز، تعداد Component و حالتها | Responsive states و Accessibility review |
| Frontend | Template و interaction قابل استفاده | Component complexity، Device و Browser matrix | Functional، Visual و Performance tests |
| Backend/CMS | Content type، Workflow، Role و Business rule | Rule، permission، state و volume | Role tests و editorial acceptance |
| Data و migration | Mapping، transformation، import و reconciliation | حجم، کیفیت، منبع و حساسیت داده | Count/checksum/sample reconciliation |
| Integration | API، webhook، retry و monitoring | بلوغ API، auth، failure mode و ownership | Contract test و سناریوی failure/recovery |
| QA و Release | Test plan، defect evidence، runbook و rollback | Risk، NFR، browser/device و environment | Exit criteria و Release sign-off |
| Training و handover | راهنما، آموزش، دسترسی و repository | تعداد نقش و پیچیدگی عملیات | تست انجام کار توسط تیم دریافتکننده |
عوامل اصلی مؤثر بر هزینه طراحی سایت
۱. تعداد Page template و Component؛ نه فقط تعداد URL
صد مقاله که همگی با یک Template و داده ساختیافته نمایش داده میشوند ممکن است ارزانتر از پنج صفحه با Flow و Stateهای متفاوت باشند. برای Estimate، صفحات را به Template، Component، State، Rule و Content type بشکنید. «صفحه محصول» فقط یک صفحه نیست؛ حالت موجود/ناموجود، تخفیف، Variant، خطای قیمت، گالری، Review و Structured data دارد.
| واحد ظاهری | واحد واقعی برآورد | پرسش تعیینکننده |
|---|---|---|
| ۱۰ صفحه شرکتی | ۳ Template + ۱۴ Component + CMS fields | چه چیزی مشترک و چه چیزی واقعاً یکتاست؟ |
| صفحه فرم | Field، validation، error، consent، storage و notification | داده کجا میرود و شکست چگونه مدیریت میشود؟ |
| داشبورد | Role، dataset، filter، state، permission و export | حجم و freshness داده و حق مشاهده چیست؟ |
| Landing page | Experiment variant، tracking plan و reusable block | یکبار مصرف است یا تیم باید مستقل بسازد؟ |
۲. قابلیت و منطق کسبوکار
دو سایت با ظاهر مشابه میتوانند هزینه کاملاً متفاوتی داشته باشند. رزرو نوبت با ظرفیت، لغو، بازپرداخت، تقویم و پیامک پیچیدهتر از یک فرم تماس است. برای هر Feature قرارداد کوچکی بنویسید: Trigger، Actor، input data، rule، state transition، output، exception، owner و acceptance. این کار قابلیت مبهم را به واحد قابل تخمین تبدیل میکند.
در فروشگاه، تعداد SKU بهتنهایی تعیینکننده نیست. Variant، منبع حقیقت قیمت و موجودی، State سفارش و پرداخت، روش ارسال، مرجوعی، تخفیف، دسترسی ادمین، Reconciliation و اتصال حسابداری Effort را تغییر میدهند. برای تعیین Scope این حوزه، چکلیست امکانات و عملیات فروشگاه اینترنتی را به Requirementهای قابل پذیرش تبدیل کنید.
۳. محتوا و داده
«محتوا با کارفرما» هزینه را صفر نمیکند. باید معلوم باشد چه کسی Inventory میگیرد، Duplicate را حذف میکند، Taxonomy را میسازد، متن فارسی را ویرایش میکند، تصویر و مجوز را کنترل میکند، Redirect map میدهد و رکوردهای مهاجرت را تطبیق میدهد. یک Excel تمیز با ۵۰۰ رکورد میتواند از ۵۰ رکورد ناسازگار ارزانتر باشد.
| محرک داده/محتوا | کمریسک | پرریسک | شاهد لازم |
|---|---|---|---|
| منبع | یک CMS مستند | چند فایل، سایت و دیتابیس ناسازگار | Source inventory |
| کیفیت | Fieldهای کامل و یکتا | Duplicate، HTML خراب، encoding یا تاریخ مبهم | Profiling sample |
| Mapping | یکبهیک | تبدیل Taxonomy، relation و media | Mapping specification |
| حساسیت | محتوای عمومی | PII، سوابق سفارش یا دسترسی محدود | Data classification |
| پذیرش | Count و نمونهبرداری | Reconciliation مالی/عملیاتی | Acceptance query و exception report |
۴. Integration و API
عبارت «اتصال به درگاه/CRM/ERP» یک واحد قیمت نیست. API مستند با Sandbox، Credential روشن و تیم پاسخگو با سامانهای که فقط نمونه کد قدیمی دارد یکسان نیست. احراز هویت، محدودیت نرخ، Timeout، Retry، Idempotency، Webhook، Reconciliation، داده آزمایشی، Monitoring و مسئولیت خطا باید قبل از Estimate بررسی شوند.
| پرسش Integration | اثر محتمل بر هزینه | کاهش عدمقطعیت |
|---|---|---|
| Sandbox و مستندات معتبر وجود دارد؟ | نبود آن Spike و زمان هماهنگی را زیاد میکند | Proof of concept زمانبندیشده |
| Authentication و دسترسی چه زمانی آماده است؟ | وابستگی بیرونی میتواند Idle/rework بسازد | Owner و تاریخ تحویل Credential |
| خطا و Timeout چه معنایی دارد؟ | Retry غلط Duplicate سفارش/پرداخت میسازد | Failure matrix و Idempotency contract |
| منبع حقیقت کدام سامانه است؟ | ابهام، مغایرت داده و پشتیبانی را افزایش میدهد | Data ownership و reconciliation rule |
| چه چیزی Monitor میشود؟ | بدون Telemetry، عیبیابی پس از Launch گران است | Metric، log، alert و runbook |
۵. UX، پژوهش و سطح تمایز طراحی
هزینه UX فقط تعداد Screen در Figma نیست. پیچیدگی Task، تنوع کاربر، ریسک خطا، دسترسی به شرکتکننده، تعداد دور Prototype و نوع شاهد پذیرش مهماند. کپیکردن الگوی بصری ممکن است Design effort را کم کند، اما اگر مدل ذهنی کاربر یا عملیات شما متفاوت باشد، هزینه Rework را بالا میبرد.
برای یک سایت کمریسک ممکن است مصاحبه محدود، Prototype سبک و Usability check کافی باشد. در خرید اعتباری B2B، ثبت اطلاعات حساس یا Journey چندنقشی، پژوهش و آزمون بیشتر یک هزینه تزئینی نیست؛ ابزار کاهش ریسک ساخت قابلیت اشتباه است.
۶. کیفیتهای غیرعملکردی: Performance، Accessibility، Security و Reliability
عبارت «سایت امن و سریع» قابل قیمتگذاری نیست. معیار باید Testable باشد: بودجه Performance تحت Device/Network مشخص، سطح دسترسپذیری هدف، Threat model، روش مدیریت Secret، Backup/restore، RPO/RTO، پشتیبانی Browser، Availability و Observability. هر معیار Effort طراحی، پیادهسازی و آزمون دارد؛ اما افزودن دیرهنگام آن معمولاً Rework بیشتری میسازد.
NIST در SSDF پیشنهاد میکند فعالیتهای توسعه امن در چرخه توسعه ادغام شوند. W3C نیز برای دسترسپذیری بر برنامه، مسئولیت، منابع و ارزیابی زودهنگام تأکید دارد. منابع: NIST Secure Software Development Framework، W3C accessibility planning و W3C implementation and early evaluation.
| NFR | تعریف مبهم | ورودی قابل برآورد | Evidence |
|---|---|---|---|
| Performance | خیلی سریع | Page type، Device/Network، budget و percentile | Lab + field plan |
| Accessibility | مناسب همه | Target، Component scope و Assistive-tech matrix | Automated + manual + user checks |
| Security | کاملاً امن | Threat، data class، control و response route | Review، test و remediation record |
| Reliability | همیشه بالا | SLO، dependency، RTO/RPO و degradation | Monitor، alert و recovery drill |
| Privacy | حفظ حریم خصوصی | Data inventory، purpose، retention و access | Flow map و deletion/access test |
۷. Platform، قالب، CMS و استفاده مجدد
قالب آماده همیشه ارزان و توسعه اختصاصی همیشه گران نیست. اگر قالب با Content model، RTL، Performance و قابلیتهای اصلی سازگار باشد، میتواند Design/Frontend effort را کم کند. اگر برای هر تغییر باید Override شکننده ساخت، هزینه QA و Upgrade بالا میرود. توسعه اختصاصی نیز ممکن است برای Workflow خاص سادهتر از انباشتن چند افزونه ناسازگار باشد.
سایتساز و No-Code هزینه شروع را کم میکنند، اما Limit، Usage fee، Lock-in و Exit cost دارند. WordPress یا CMS متنباز License هسته را حذف میکند، نه هزینه معماری، توسعه، امنیت، محتوا و عملیات را. اگر میان مدلهای اجرا تصمیم نگرفتهاید، مقایسه سایتساز، طراح و تیم اختصاصی با TCO و Pilot را ببینید.
۸. تیم، نرخ و مدل همکاری
نرخ پایینتر الزاماً پروژه ارزانتر نمیسازد. هزینه هر Work package تابع Effort و نرخ بارگذاریشده است؛ تجربه مناسب میتواند Effort یا Rework را کاهش دهد، اما نام «آژانس» یا «فریلنسر» تضمینی برای کیفیت یا قیمت نیست. باید نقش، Seniority لازم، Availability، وابستگی بین نقشها، Review gate و Bus factor را ببینید.
| عامل تیم | پرسش قیمتگذاری | ریسک پنهان |
|---|---|---|
| نقش و ظرفیت | چه کسی چند درصد و در کدام هفته در دسترس است؟ | فروش نام نقش بدون ظرفیت واقعی |
| تخصص دامنه | کدام تجربه مستقیماً Effort را کم میکند؟ | Premium بدون شاهد مرتبط |
| QA و Review | چه کسی کار را با چه Gateای بازبینی میکند؟ | انتقال Defect به انتهای پروژه |
| هماهنگی | چند تیم/فروشنده و Dependency وجود دارد؟ | جلسه، انتظار و Rework بدون Owner |
| تداوم | در غیبت فرد کلیدی چه میشود؟ | Bus factor و تأخیر تحویل |
| Handover | مستندات، دسترسی و دانش چگونه منتقل میشوند؟ | وابستگی دائمی به سازنده |
۹. زمانبندی، وابستگی و شرایط انتشار
فشردهکردن تقویم لزوماً Effort را کم نمیکند. گاهی به کار موازی، هماهنگی بیشتر، ظرفیت گرانتر یا پذیرش ریسک نیاز دارد. تأخیر کارفرما در محتوا، دسترسی، تأیید و داده نیز باید Dependency ثبتشده باشد. تاریخ نمایشگاه یا کمپین، Freeze سازمان، دسترسی به سامانه قدیمی و پنجره Release هزینه واقعی میسازند.
بخش سئو و انتشار را نیز «در پایان چک میکنیم» نگذارید. URL map، Redirect، Crawl/Index، Canonical، Structured data، Analytics و Rollback باید از Scope طراحی و مهاجرت معلوم باشند. چکلیست سئو از Staging تا انتشار این Acceptanceها را به Gate قابل شاهد تبدیل میکند. برای خرید جداگانه خدمات Search نیز راهنمای هزینه و قرارداد سئو مرز Scope را روشن میکند.
محرکهای ویژه پروژههای وب در ایران
مدل برآورد باید شرایط اجرای واقعی را ببیند، بیآنکه نرخ روز را داخل مقاله دائمی کند. نرخ ارز و License خارجی، امکان پرداخت و تمدید سرویس، محدودیت ارائهدهنده، دسترسی شبکهای، جایگزین داخلی/خارجی و ریسک مهاجرت میتوانند سناریوی فنی را عوض کنند. این موارد را به Assumption و Risk تبدیل کنید، نه جمله کلی «ممکن است گران شود».
| عامل ایران | اثر بر Scope/Effort | سؤال قبل از Quote | کنترل |
|---|---|---|---|
| ریال/تومان و قیمت | نمایش، ذخیره، گردکردن و گزارش | واحد حقیقت در DB و قرارداد چیست؟ | Money model و Acceptance نمونه |
| تقویم و منطقه زمانی | ورودی شمسی، ذخیره زمانی و گزارش | UTC، تهران و DST چگونه مدیریت میشوند؟ | قواعد تبدیل و تست مرزی |
| آدرس و ارسال | استان/شهر، کدپستی، Zone و SLA | منبع داده و منطق نرخ کدام است؟ | Dataset، Owner و exception flow |
| پرداخت | Callback، verify، timeout و reconciliation | مرجع نهایی وضعیت پرداخت چیست؟ | State machine و تست Duplicate |
| پیامک | Template، OTP، consent، failover و هزینه مصرف | Provider، Limit و مسیر شکست چیست؟ | Adapter و monitoring |
| License/FX | خرید، تمدید، دسترسی و جایگزینی | ارز مبنا و تاریخ اعتبار قیمت چیست؟ | سناریوی نرخ و Exit option |
| RTL و فارسی | Typography، عدد، جستوجو و content QA | فارسیسازی واقعی است یا فقط راستچین؟ | Component/content test فارسی |
| دسترسی سرویس | Availability، Latency و عملیات | از شبکه کاربران هدف قابل اتکاست؟ | Probe مجاز و fallback plan |
سه سناریو؛ چرا بدون تعرفه ثابت هم میتوان دقیق تصمیم گرفت؟
اعداد این سناریوها عمداً حذف شدهاند، چون نرخ بدون تاریخ، Scope و کیفیت گمراهکننده است. هدف نشاندادن تفاوت Cost driver است.
| سناریو | محرک غالب | Discovery لازم | چیزی که نباید از روی نام سایت فرض شود |
|---|---|---|---|
| شرکت خدمات صنعتی در تهران | Content inventory، Case study، فرم Lead، فارسی/انگلیسی و مهاجرت URL | گفتوگو با فروش و مشتری، Audit محتوا | «شرکتی» به معنی چند صفحه ثابت نیست |
| فروشگاه پوشاک با ارسال سراسری | Variant، موجودی، قیمت، تخفیف، پرداخت، ارسال، مرجوعی و پشتیبانی | مدل سفارش و عملیات انبار تا بازپرداخت | تعداد محصول بهتنهایی Effort را تعیین نمیکند |
| پرتال سفارش B2B قطعه | Role، قیمت قراردادی، اعتبار، تأیید چندمرحلهای، ERP و گزارش | Journey نقشها، API spike و Data ownership | ظاهر ساده داشبورد نشاندهنده منطق ساده نیست |
اگر سقف منابع پایین است، ابتدا Outcome و ریسک حیاتی را حفظ و Scope را مرحلهبندی کنید؛ استانداردهای پایه را کورکورانه حذف نکنید. راهنمای کاهش هزینه طراحی سایت با MVP و تحویل مرحلهای روش انتخاب برش کوچک اما عملیاتی را توضیح میدهد.
روشهای برآورد: هر روش کجا بهدرد میخورد؟
| روش | بهترین زمان | ورودی | محدودیت |
|---|---|---|---|
| Analogous / قیاسی | ایده و بررسی امکان | پروژه واقعاً مشابه و تعدیل تفاوتها | شباهت ظاهری، پیچیدگی پنهان را مخفی میکند |
| Top-down | بررسی سناریو و سقف اولیه | Outcome، constraint و سهم Workstream | برای تعهد جزئی کافی نیست |
| Parametric | کار تکرارشونده با داده تاریخی | Unit معتبر مانند Template یا migration batch | Unit بد، دقت کاذب میسازد |
| Bottom-up | پس از تعریف WBS | Work package، effort، rate و dependency | برای Scope مبهم زمانبر و شکننده است |
| Three-point | کارهای دارای عدمقطعیت | Optimistic، most likely و pessimistic | سه عدد بدون دلیل Risk analysis نیست |
| Timeboxed spike | Integration/فناوری ناشناخته | پرسش، زمان ثابت و خروجی تصمیم | نباید به Prototype بیپایان تبدیل شود |
| Rolling estimate | تحویل مرحلهای | Actual، backlog و risk update | نیازمند Governance تغییر است |
عدمقطعیت را به بازه و سناریو تبدیل کنید
برای Work package پرریسک سه مقدار ثبت کنید: خوشبینانه وقتی فرضهای خوب برقرارند، محتمل بر اساس اطلاعات فعلی، و بدبینانه وقتی ریسکهای تعریفشده رخ میدهند. مهمتر از فرمول میانگین، توضیح سناریوی پشت هر مقدار است. سپس تحلیل حساسیت نشان میدهد کدام فرض—مثلاً کیفیت API یا آمادگی محتوا—بیشترین اثر را دارد و Discovery باید کجا خرج شود.
Contingency برای عدمقطعیت و ریسکهای شناختهشده داخل Cost baseline است و باید قاعده مصرف داشته باشد. Management reserve برای ناشناختههای مدیریتی و بیرون Baseline نگهداری میشود. Padding پنهان، قابلیت اعتماد و مقایسه را خراب میکند. نام و سطح این ذخیرهها باید با شیوه مالی سازمان شما هماهنگ شود؛ واژهها در همه قراردادها یک کاربرد ندارند.
| Risk/assumption | احتمال/اثر | نشانه Trigger | پاسخ | اثر Estimate |
|---|---|---|---|---|
| API حسابداری Sandbox ندارد | متوسط/زیاد | عدم دسترسی تا پایان Discovery | Spike + Adapter + fallback import | بازه Integration وسیعتر |
| محتوا تا Sprint دوم آماده است | متوسط/زیاد | Inventory بدون Owner | نمونه واقعی، deadline و escalation | احتمال Rework و تأخیر |
| قالب موجود قابل استفاده مجدد است | نامعلوم/متوسط | Accessibility یا performance fail | Technical audit پیش از لحاظ صرفهجویی | صرفهجویی مشروط، نه قطعی |
| License خارجی تمدید میشود | متوسط/زیاد | تغییر دسترسی یا FX | قیمت با تاریخ، جایگزین و Exit plan | سناریوی ارزی جداگانه |
چگونه پیشنهاد قیمت طراحی سایت را همسطح مقایسه کنیم؟
یک Brief مشترک برای همه فروشندگان بفرستید و پاسخ را در Workbook واحد Normalize کنید. اگر یکی مهاجرت، QA و آموزش را شامل کرده و دیگری فقط Build را، مقایسه رقم کل غلط است. ابهام را با پرسش روشن کنید؛ خودتان جای خالی پیشنهاد را با فرض مطلوب پر نکنید.
| ستون Quote normalization | پرسش کنترل |
|---|---|
| Outcome و Scope version | پیشنهاد دقیقاً به کدام نسخه Brief پاسخ میدهد؟ |
| Deliverable/WBS | خروجی ملموس هر مبلغ چیست؟ |
| Included/Excluded | محتوا، داده، Integration، QA، انتشار و آموزش شاملاند؟ |
| Assumption/Dependency | فروشنده چه چیزی را آماده و بیخطا فرض کرده؟ Owner کیست؟ |
| Acceptance/Evidence | تحویل چگونه و توسط چه کسی پذیرفته میشود؟ |
| Team/Capacity | نقش، Seniority، تخصیص و جایگزین چیست؟ |
| Timeline/Milestone | Dependency و Critical path دیده شده یا فقط تاریخ وعده است؟ |
| Change route | تغییر چگونه Estimate، تصویب و ثبت میشود؟ |
| Warranty/Support | Defect چیست، چند وقت، با چه SLA و چه استثنایی؟ |
| IP/License/Data | مالک Code، Design، Account، داده و حق خروج کیست؟ |
| Commercial | مالیات، ارز، اعتبار Quote، پرداخت و توقف چگونهاند؟ |
| Risk/Contingency | کدام ریسک قیمتگذاری شده و مسیر مصرف Reserve چیست؟ |
امتیازدهی فقط به قیمت، انتخاب کمهزینه را تضمین نمیکند
اول Knockoutها را بسنجید: مالکیت و دسترسی، توان انجام Integration حیاتی، امنیت داده، تعارض منافع و پذیرش شرایط خروج. سپس با وزنهای ازپیشثبتشده به شواهد Scope understanding، approach، team، quality، operations، risk و commercial امتیاز دهید. Demo یا ادعای عمومی را با Artifact، Reference check یا Pilot کوچک راستیآزمایی کنید. اگر خرید خدمات و قرارداد مسئله اصلی است، راهنمای Build/Buy، Pilot و Exit را مبنای Procurement قرار دهید؛ همان لینک پیشتر در متن آمده و این اشاره بدون URL تکراری برای مرزبندی است.
هزینه ساخت را از ارزش تصمیم جدا نکنید
Estimate میگوید اجرای گزینه چه منابعی میخواهد؛ نمیگوید آن گزینه ارزش اجرا دارد. برای هر سناریو Outcome baseline، منفعت مورد انتظار، هزینه کل، زمان رسیدن به اثر و Counterfactual را کنار هم بگذارید. اندازهگیری Benefit باید از ابتدا طراحی شود، نه بعد از Launch. منبع: GOV.UK measuring service benefits.
برای ساخت Business case و سنجش اثر افزایشی، راهنمای ROI طراحی سایت را بهکار ببرید. ممکن است گزینه گرانتر با کاهش کار دستی، خطا یا زمان چرخه ارزش بیشتری بسازد؛ یا پروژهای با Estimate پایین چون Outcome مشخصی ندارد اصلاً قابل دفاع نباشد. «سایت سرمایهگذاری است» فقط وقتی معنا دارد که منفعت و هزینه با شواهد سنجیده شوند.
برنامه ۳۰روزه برای رسیدن به Estimate قابل اتکا
| بازه | کار | خروجی | Gate |
|---|---|---|---|
| روز ۱ تا ۳ | Outcome، تصمیم، ذینفع، constraint و Cost boundary | Estimate charter یکصفحهای | توافق بر پرسشی که عدد باید جواب دهد |
| روز ۴ تا ۸ | User need، Journey، Content/Data inventory و سامانههای درگیر | Scope map و unknown list | مرز In/Out روشن |
| روز ۹ تا ۱۲ | Spike برای unknownهای گران و بررسی دارایی reusable | Option evidence و Risk register | حذف فرضهای پراثر بدون شاهد |
| روز ۱۳ تا ۱۷ | ساخت WBS، NFR، Acceptance و Dependency | Basis of estimate | هر کار Owner و خروجی دارد |
| روز ۱۸ تا ۲۰ | Analogous/parametric check و Bottom-up range | Estimate v1 و sensitivity | بازسازیپذیری عدد |
| روز ۲۱ تا ۲۳ | Scenario، contingency و Cash timing | Base/upside/downside | تصمیمگیر ریسک را میبیند |
| روز ۲۴ تا ۲۷ | ارسال Quote pack و جلسه پرسش مشترک | پیشنهادهای قابل Normalize | پاسخ همه به Scope version واحد |
| روز ۲۸ تا ۳۰ | Normalize، Reference/Pilot evidence و تصمیم | Recommendation + assumptions + next review | قیمت، کیفیت، ریسک و Exit همزمان دیده شدهاند |
چکلیست نهایی برآورد هزینه طراحی سایت
- Outcome، کاربران، Task و مرز خدمت پیش از راهحل ثبت شدهاند.
- Cost boundary میگوید Build، Launch، عملیات و نیروی داخلی کجا حساب میشوند.
- Scope version و فهرست In/Out برای همه پیشنهاددهندگان یکسان است.
- تعداد Template، Component، State، Content type و Feature جای «تعداد صفحه» را گرفته است.
- هر Feature، Rule، Exception، Owner و Acceptance دارد.
- Content/Data inventory و مسئول تولید، پاکسازی و Migration مشخصاند.
- هر Integration از نظر API، Auth، Sandbox، Failure، Retry و Reconciliation بررسی شده است.
- Performance، Accessibility، Security، Reliability و Privacy معیار قابل آزمون دارند.
- RTL، فارسی، ریال/تومان، تاریخ، آدرس، پرداخت، پیامک و محدودیت Provider در Scope دیده شدهاند.
- WBS شامل Discovery، UX، Content، Build، QA، Release، Training و Handover است.
- Effort، Loaded rate، خرید شخص ثالث و دارایی reusable جدا ثبت شدهاند.
- Estimate تاریخ، روش، منبع داده، فرض، بازه و Confidence دارد.
- Risk register، تحلیل حساسیت و Contingency قابل توضیحاند؛ Padding پنهان ندارید.
- Quoteها با Included/Excluded، Acceptance، تیم، License، Support، Change و Exit Normalize شدهاند.
- Actual effort برای کالیبرهکردن Estimate بعدی ثبت خواهد شد.
سؤالات متداول
هزینه طراحی سایت به چه عواملی بستگی دارد؟
به Outcome و Scope، تعداد Template و Component، پیچیدگی Feature و Rule، محتوا و Migration، Integration، UX، سطح کیفیتهای غیرعملکردی، Platform، ظرفیت تیم، زمانبندی و ریسک. «نوع سایت» یا تعداد صفحه بهتنهایی برآورد قابل اتکایی نمیسازد.
قیمت سایت شرکتی یا فروشگاهی را چطور بدون تعرفه ثابت تخمین بزنیم؟
Scope را به WBS بشکنید، برای هر Work package Effort و Loaded rate بسازید، خرید شخص ثالث و ریسک را جدا کنید و نتیجه را بهصورت بازه همراه با فرضها بدهید. بعد از Discovery و داده واقعی، Estimate را بهروزرسانی کنید.
آیا تعداد صفحات معیار خوبی برای برآورد هزینه سایت است؟
فقط در کار تکراری و پس از تعریف نوع صفحه. واحد بهتر معمولاً Page template، Component، State، Content type، Rule و Acceptance است. صد URL روی یک Template ممکن است از چند Flow تعاملی ارزانتر باشد.
قالب آماده همیشه از طراحی اختصاصی ارزانتر است؟
خیر. قالب سازگار میتواند Effort شروع را کم کند، اما ناسازگاری با RTL، Content model، Performance، Accessibility یا Upgrade هزینه تغییر و نگهداری را بالا میبرد. گزینهها را با Scope و افق TCO یکسان بسنجید.
برای مقایسه دو پیشنهاد قیمت طراحی سایت چه چیزهایی را همسطح کنیم؟
Scope version، Deliverable/WBS، Included و Excluded، فرض و وابستگی، Acceptance، نقش و ظرفیت تیم، Timeline، QA، License و مالکیت، Support، Change route، مالیات/ارز/پرداخت و Risk allowance. سپس مبلغ و شواهد اجرا را کنار هم ارزیابی کنید.
جمعبندی
پرسش حرفهای این نیست که «هر صفحه چند است؟»؛ این است که برای رسیدن به Outcome مشخص، چه Scope و سطح کیفیتی با چه Effort، نرخ، خرید، وابستگی و ریسکی لازم است. یک برآورد خوب از WBS و شواهد ساخته میشود، بازه و فرضهایش را نشان میدهد، با Actual کالیبره میشود و Quoteها را روی مبنای واحد قرار میدهد. وقتی این Basis of estimate را دارید، مذاکره از چانهزنی روی عدد به تصمیم روشن درباره Scope، کیفیت، زمان و ریسک تبدیل میشود.
