سه شرکت برای «یک سایت شرکتی» سه قیمت با فاصله چندبرابری میفرستند. یکی فقط ۱۲ صفحه را شمرده، دیگری طراحی اختصاصی و ورود محتوا را دیده و سومی مهاجرت URL، اتصال CRM، تست، مانیتورینگ و پشتیبانی را هم داخل پیشنهاد آورده است. این سه عدد رقیب هم نیستند؛ سه محدوده متفاوتاند که فقط نام یکسان دارند.
هزینه طراحی سایت از قیمت یک قالب یا تعداد صفحه به دست نمیآید. برآورد قابل دفاع باید خروجی، مقدار، پیچیدگی، فرض، ریسک، زمان و هزینه پس از راهاندازی را کنار هم نشان دهد. این راهنما یک مدل عملی برای ساخت چنین برآوردی ارائه میکند؛ بدون فهرست قیمت تاریخمصرفدار و بدون وعده «عدد دقیق» پیش از شناخت.
چهار عدد متفاوت را با هم اشتباه نگیرید
- Estimate یا برآورد: پیشبینی هزینه بر اساس اطلاعات و عدمقطعیت فعلی؛ با تغییر شناخت باید بهروزرسانی شود.
- Price یا قیمت: مبلغی که ارائهدهنده با مدل قرارداد، حاشیه، ریسک و شرایط پرداخت پیشنهاد میکند.
- Budget یا بودجه: سقف یا ظرفیت سرمایهگذاری کارفرما؛ نه شاهد هزینه واقعی Scope.
- TCO یا هزینه کل مالکیت: هزینه ساخت، راهاندازی، بهرهبرداری، نگهداری، رشد و خروج در یک دوره مشخص.
ممکن است Estimate داخلی یک تیم با Price پیشنهادی برابر نباشد؛ زیرا قیمت، ریسک قرارداد، ظرفیت رزروشده، مالیات/هزینههای قراردادی، خدمات پس از تحویل و سود را نیز منعکس میکند. بودجه هم نباید با پنهانکردن Scope به Estimate تبدیل شود. اگر بودجه محدود است، خروجی و ترتیب فازها را تغییر دهید.
برآورد خوب چه ویژگی دارد؟
راهنمای رسمی Cost Estimating دفتر پاسخگویی دولت آمریکا (GAO) برای برآورد قابل اتکا بر تعریف هدف و Scope، Technical baseline، Work breakdown structure، فرضها، داده، روش تخمین، تحلیل حساسیت/ریسک، مستندسازی و بهروزرسانی با هزینه واقعی تأکید میکند. آن راهنما برای برنامههای بزرگ نوشته شده، اما منطق چهار ویژگی آن برای پروژه سایت نیز مفید است:
| ویژگی | در پروژه سایت یعنی چه؟ | نشانه ضعف |
|---|---|---|
| جامع | تمام کار و هزینه چرخه عمر دیده شده است | فقط Development قیمت دارد |
| مستند | عدد به Quantity، فرض، منبع و روش قابل ردیابی است | یک مبلغ بدون Breakdown |
| واقعبینانه | نه خوشبینانه پنهان و نه Contingency مبهم است | همه Integrationها «ساده» فرض شدهاند |
| معتبر | Cross-check، ریسک و سناریو بررسی شدهاند | فقط یک نفر و یک روش تخمین زده است |
ورودی برآورد: قبل از صفحه و Feature، Outcome را تعریف کنید
فهرست «خانه، درباره ما، خدمات، تماس» برای برآورد کافی نیست. ابتدا مشخص کنید سایت چه نتیجهای میسازد و شکست آن چه پیامدی دارد:
- جذب Lead واجدشرایط و ارسال به CRM؛
- فروش و عملیات سفارش؛
- رزرو، نوبت یا پرداخت؛
- Self-service و کاهش تماس پشتیبانی؛
- انتشار محتوای چندزبانه یا چندنویسنده؛
- پرتال مشتری، نقشها و داده حساس.
Outcome روی طراحی Journey، ابزار سنجش، سطح امنیت، Availability و عملیات پس از Launch اثر دارد. یک سایت معرفی کمریسک و سامانهای که سفارش و پول جابهجا میکند، حتی با تعداد صفحه برابر برآورد یکسان ندارند.
Technical baseline یکصفحهای
پیش از درخواست قیمت، این اطلاعات را در یک صفحه جمع کنید:
- هدف، مخاطب، زبان، جغرافیا و Device غالب؛
- Journeyهای حیاتی و نتیجه قابل سنجش؛
- نوع محتوا، تعداد تقریبی و وضعیت تولید؛
- نقشها، مجوزها، داده و سطح حساسیت؛
- سرویسهای ثالث، مالک API و محیط آزمایش؛
- دارایی موجود: Domain، Hosting، Analytics، CRM، محتوا و URLها؛
- الزام Performance، دسترسپذیری، امنیت، SEO و بازیابی؛
- تاریخ مطلوب و علت واقعی Deadline؛
- مالک تصمیم، بازخورد و تأیید در سمت کارفرما؛
- موارد ناشناخته و نیازمند Discovery.
WBS سایت: هزینه را به خروجی قابل پذیرش بشکنید
Work breakdown structure یا WBS باید کل کار را بدون همپوشانی مبهم به اجزای قابل تخمین تقسیم کند. برای سایت، این ساختار نقطه شروع است؛ هر پروژه برخی ردیفها را حذف یا عمیقتر میکند.
| بسته کار | خروجی نمونه | Quantity/Driver |
|---|---|---|
| Discovery | هدف، Scope، Risk، Journey و Technical spike | تعداد ذینفع/فرایند/ناشناخته |
| پژوهش و معماری اطلاعات | مصاحبه، Sitemap، Taxonomy، Search/filter | گروه کاربر و نوع محتوا |
| محتوا و SEO migration | Inventory، نگارش، Redirect map، Metadata | تعداد/نوع/کیفیت رکورد و URL |
| UX | User flow، Wireframe، Prototype و Usability test | Journey و State، نه فقط Page |
| UI و Design system | Component، Responsive state، RTL و Handoff | Component/Variant/Breakpoint |
| Frontend | Template، Component، Form، Interaction | رفتار، State و Browser matrix |
| Backend/CMS | Content model، Workflow، Role، API و Admin | Entity/Rule/Permission |
| Integration | پرداخت، پیامک، CRM، حمل و Analytics | Vendor/Operation/Failure mode |
| Data migration | Extract، Clean، Map، Import و Reconcile | حجم، تنوع، کیفیت و Downtime |
| QA و Verification | Functional، A11y، Security، Performance و UAT | Risk/Journey/Environment |
| Platform/Release | Environment، CI/CD، Backup، Monitor و Rollback | Environment/SLO/Recovery |
| Launch/Enablement | Training، Runbook، Content freeze و Hypercare | Role/Team/Launch risk |
| مدیریت و حاکمیت | Plan، Review، Decision log و Change control | Team/Stakeholder/Dependency |
| نگهداری و رشد | Update، Incident، Content، CRO و Feature | SLA/Change rate/Roadmap |
تعداد URL با تعداد قالب و Journey برابر نیست
پنجاه مقاله میتوانند یک Template داشته باشند؛ اما یک Checkout سهمرحلهای دهها State شامل Loading، Validation، Empty، Timeout، Duplicate، Permission و Recovery دارد. برای برآورد طراحی و توسعه این واحدها را جدا بشمارید:
- Page type یا Template؛
- Journey و Step؛
- Component و Variant؛
- Entity و Business rule؛
- Role و Permission؛
- Integration operation و Failure mode؛
- Content/data record و Migration rule؛
- زبان، Locale، Device و Browser مهم.
مدل محاسبه: Quantity × Effort × Complexity + Risk
برای هر بسته کار، یک واحد قابل شمارش و یک Range effort تعریف کنید. فرمول ساده مدیریتی:
Base Effort = Σ (Quantity × Unit Effort × Complexity Factor)
Estimate Range = Base Effort
+ Dependency/Integration Allowance
+ Risk & Uncertainty
+ Management/QA/Launch
Price = Estimate × Commercial Model + Explicit Pass-through Costsاین فرمول ماشین حقیقت نیست؛ ساختار توضیح است. Unit effort باید از داده پروژههای مشابه و Retrospective تیم بیاید. Complexity factor نیز باید دلیل داشته باشد: «Form چندمرحلهای با Save/resume و سه Role» نه صرفاً برچسب «پیچیده».
از Range و سهنقطهای استفاده کنید
وقتی شناخت کامل نیست، یک Point estimate دقت کاذب میسازد. برای هر ردیف حد خوشبینانه، محتمل و بدبینانه ثبت کنید. یک Summary سهنقطهای رایج:
Expected Effort ≈ (Optimistic + 4 × Most Likely + Pessimistic) ÷ 6این میانگین ریسک را حذف نمیکند و Probability قطعی نمیسازد. سناریوی بدبینانه باید از Driver واقعی مثل API بدون Sandbox، دیتای آلوده یا تصمیمگیر دیرهنگام بیاید. Range با Discovery کوچکتر میشود؛ با آرزو نه.
Confidence و تاریخ انقضا اضافه کنید
| سطح | شاهد | نحوه استفاده |
|---|---|---|
| کم | Brief مبهم، بدون دسترسی/نمونه/API | ROM برای Budget؛ قرارداد ساخت نه |
| متوسط | Journey و WBS روشن، چند Spike باز | فازبندی + Allowance صریح |
| زیاد | Prototype/Spike، داده نمونه و Acceptance معلوم | Baseline اجرا با Change control |
هر Estimate یک «As of» و شرایط اعتبار دارد. اگر Scope، نرخ سرویس، Deadline، داده یا Team عوض شود، برآورد هم باید تغییر کند.
Contingency را پنهان نکنید
ذخیره ریسک مشروع است، اما درصد ثابت ۱۰ یا ۲۰ برای همه پروژهها منطق ندارد. Risk register بسازید: احتمال، اثر، Owner، پاسخ و Cost exposure. هزینه شناختهشده را به Scope ببرید؛ فقط Unknown باقیمانده در Contingency بماند. Reserve مصرفنشده نیز نباید خودکار خرج Feature شود.
چه چیزهایی هزینه طراحی سایت را واقعاً تغییر میدهند؟
۱. Discovery و میزان عدمقطعیت
اگر هدف، جریان یا محدودیت روشن نیست، تیم یا برای Discovery هزینه میگیرد یا ریسک را داخل Price پنهان میکند. حذف Discovery هزینه را حذف نمیکند؛ آن را به Rework، Change request و تأخیر منتقل میکند. برای API ناشناخته یا مهاجرت دیتای قدیمی، Technical spike زماندار تعریف کنید.
۲. طراحی آماده، سفارشی یا Design system
قالب آماده میتواند Discovery و UI را کم کند، ولی هزینه ارزیابی License، Accessibility، Performance، Update و محدودیت سفارشیسازی را دارد. طراحی سفارشی برای هر صفحه نیز همیشه ارزشمند نیست. اغلب یک System کوچک از Token، Component و Pattern مشترک، هزینه تغییر و ناسازگاری را بهتر کنترل میکند.
تعداد Revision را با «تعداد دور بازخورد تجمیعشده» تعریف کنید. بازخورد متناقض پنج مدیر در پنج زمان، پنج دور نیست؛ یک مشکل Governance است که هزینه Schedule و Rework میسازد.
۳. محتوا، رسانه و SEO migration
«محتوا با کارفرما» اگر Owner، Format و تاریخ ندارد، ریسک Launch است. تحقیق، نگارش تخصصی، ویرایش، ترجمه، عکاسی، ویدئو، ورود CMS، Alt، Metadata و Approval را تفکیک کنید. در بازطراحی، فقط Copy کافی نیست: URL inventory، Redirect مستقیم، Canonical، Structured data، Internal link، تصویر و Analytics continuity باید برنامه داشته باشند.
۴. نقش، مجوز و منطق کسبوکار
ثبتنام ساده با سازمان چندکاربره، دعوت، تأیید، Role، Delegation و Audit trail یک Feature نیست. هر Permission باید در Server enforce و با سناریوی منفی Test شود. Business rule، وضعیت و Exceptionها را بشمارید؛ ظاهر یکسان میتواند Backend بسیار متفاوتی داشته باشد.
۵. Integration و Vendor ثالث
اتصال اولیه فقط Happy path است. برای پرداخت، پیامک، CRM، نقشه، حمل و سرویس احراز هویت این موارد هزینه میسازند:
- کیفیت Documentation و Sandbox؛
- Authentication، Secret و IP/Domain restriction؛
- Timeout، Retry، Idempotency و Rate limit؛
- Webhook، Signature و Duplicate/out-of-order event؛
- Versioning، Deprecation و Vendor outage؛
- هزینه مصرف، ارز، مالیات، سقف و دسترسی جغرافیایی؛
- Fallback، Reconciliation و Exit plan.
قرارداد و Failure mode هر اتصال را با راهنمای طراحی API وب دقیق کنید.
۶. مهاجرت داده
هزینه تابع تعداد رکورد تنها نیست. Schema ناسازگار، Encoding فارسی، داده تکراری، فایل گمشده، تاریخ جلالی/میلادی، واحد ریال/تومان، رابطهها و Downtime مهماند. چرخه کامل را قیمتگذاری کنید: Profile، Clean، Mapping، Dry run، Import، Reconcile، Cutover و Rollback.
۷. کیفیت قابل قبول: Performance، دسترسپذیری و امنیت
عبارت «سایت استاندارد باشد» قابل پذیرش نیست. Requirement نسخهدار و Testable بنویسید:
- دسترسپذیری: Scope صفحهها، سطح هدف و روش Test. WCAG 2.2 Success criteria قابل آزمون و سطوح A/AA/AAA دارد؛ ادعای Conformance باید Scope کامل و تاریخ داشته باشد.
- امنیت: Risk tier و Requirementهای منتخب. OWASP ASVS 5.0.0 میتواند برای Requirement و Verification در قرارداد Procurement استفاده شود؛ «امنیت رعایت شود» کافی نیست.
- Performance: Route/Device/Network و Field target. راهنمای Web Vitals LCP، INP و CLS را در صدک ۷۵ تفکیکشده Mobile/Desktop میسنجد؛ یک نمره Lighthouse روی لپتاپ Acceptance کامل نیست.
هزینه QA باید شامل Test design، Environment، Device/Browser، Fixture، رفع Issue و Retest باشد. برای ممیزی و اصلاح دسترسپذیری از راهنمای تست WCAG استفاده کنید.
۸. زیرساخت، انتشار و بازیابی
یک سرور ارزان با یک معماری عملیاتی قابل اتکا برابر نیست. Environmentها، Domain/DNS، TLS، CDN، Storage، Email، Secret، Backup، Restore test، Monitor، Log، Alert، Deployment، Rollback و Incident ownership را تفکیک کنید. Pipeline قابل بازیابی و Artifact آزمودهشده در راهنمای CI/CD تشریح شده است.
۹. زمانبندی و ظرفیت
Deadline فشرده ممکن است Parallel work، نیروی بیشتر، Overtime، ریسک Coordination و کاهش گزینههای معماری را تحمیل کند. افزودن نفر همیشه زمان را خطی کم نمیکند. دلیل تاریخ را روشن کنید: کمپین، نمایشگاه، قرارداد یا صرفاً ترجیح. MVP قابل بهرهبرداری را از Scope کامل جدا کنید.
۱۰. تیم، Governance و Hand-off
Senior بودن فقط نرخ بیشتر نیست؛ ممکن است Discovery، تصمیم و ریسک را سریعتر کند. از طرف دیگر، نام Senior روی Proposal تضمین نمیکند همان فرد کار کند. Composition، Allocation، Owner، Bus factor، Review و Handover را مکتوب کنید.
متغیرهای خاص پروژههای ایرانی
این موارد برای همه پروژهها یکسان نیستند، اما باید صریح بررسی شوند:
- RTL/BiDi، فونت فارسی، نیمفاصله، جستوجو و Sort فارسی؛
- ریال/تومان، جداکننده رقم، مالیات و Round-trip مبلغ؛
- تاریخ جلالی/میلادی و Timezone؛
- PSP، Callback، استعلام، مغایرت و بازگشت وجه؛
- پیامک فارسی، Template، Encoding، Delivery و Consent؛
- شبکه/دستگاه واقعی کاربران و دسترسی سرویس خارجی؛
- License، پرداخت ارزی، تحریم/حساب، Mirror و Plan خروج؛
- پشتیبانگیری در محل مستقل و سنجش Restore.
«پشتیبانی از فارسی» را با یک Screenshot Homepage نپذیرید. Fixture و Acceptance برای نام، آدرس، مبلغ، تاریخ، Mobile، RTL/BiDi و خطاهای Vendor بنویسید.
چگونه پیشنهادها را همسطح مقایسه کنیم؟
یک Comparison matrix بسازید و هر ارائهدهنده را مجبور کنید برای همان ردیف پاسخ بدهد:
| ردیف | پیشنهاد A | پیشنهاد B | پرسش اختلاف |
|---|---|---|---|
| Scope/Out of scope | … | … | کدام Journey/State حذف شده؟ |
| Deliverable/Acceptance | … | … | چه شاهدی تحویل را تأیید میکند؟ |
| Quantity و Complexity | … | … | Template، Role، Integration چند است؟ |
| Content/Migration | … | … | چه کسی مینویسد، وارد و تأیید میکند؟ |
| Quality/Verification | … | … | کدام معیار نسخهدار و چه Retestی؟ |
| Team/Allocation | … | … | چه کسی واقعاً کار و Review میکند؟ |
| Assumption/Dependency | … | … | اگر فرض غلط بود چه میشود؟ |
| Warranty/Support | … | … | Bug چیست، SLA چیست، Feature چیست؟ |
| Recurring/TCO | … | … | License، Hosting و Exit چه هزینهای دارند؟ |
Acceptance criteria را به هر خروجی وصل کنید
«صفحه محصول» Deliverable است، اما پذیرش ندارد. نمونه Acceptance بهتر:
- کاربر مهمان و عضو قیمت و موجودی درست را در سه Variant میبیند؛
- حالت Loading، Empty، Error و Retry طراحی و اجرا شدهاند؛
- Keyboard و Screen reader روی Flow انتخاب Variant آزموده شدهاند؛
- Structured data با داده نمایشی سازگار است؛
- Field performance در Scope و پنجره توافقشده سنجیده میشود؛
- Eventهای View/select/add-to-cart بدون PII ناخواسته ثبت میشوند.
Change control جلوی تغییر را نمیگیرد؛ اثرش را آشکار میکند
برای هر تغییر، Request، دلیل، Scope، اثر هزینه/زمان/کیفیت، تصمیمگیر و Baseline تازه ثبت کنید. «فقط یک دکمه» ممکن است Permission، API، State، Tracking و Test را تغییر دهد. تغییر کوچک واقعی نیز نباید با فرایند سنگین خفه شود؛ آستانه و Fast path تعریف کنید.
نشانههای خطر در Proposal
- یک مبلغ نهایی بدون Scope، فرض و Exclusion؛
- همه Featureها با عبارت «قابل انجام» اما بدون Acceptance؛
- امنیت، سرعت و SEO با واژه «کامل» و بدون معیار؛
- پشتیبانی «رایگان» بدون تعریف Bug، ساعت و SLA؛
- نامشخصبودن مالک Source code، Design file، Account و Domain؛
- License و سرویس ثالث بدون هزینه تمدید و Exit؛
- پرداخت سنگین پیش از Milestone قابل مشاهده؛
- Deadline قطعی با Dependencyهای ناشناخته؛
- قیمت بسیار پایین با انتقال کار محتوا/QA/مهاجرت به کارفرما بدون تصریح.
هزینه کل مالکیت را برای ۲۴ یا ۳۶ ماه ببینید
TCO = Discovery + Design + Build + Content + Migration
+ Verification + Launch
+ Hosting/CDN/Email/Storage/Monitoring
+ License/Vendor Usage
+ Maintenance/Security/Content Operations
+ Expected Incident & Recovery Cost
+ Growth/Change
+ Exit/Migration Costعدد TCO را با Scenario بسازید: Base، Growth و Stress. ترافیک، تعداد سفارش، حجم رسانه، مصرف پیامک، تیم محتوا و Change rate Driverهای دورهایاند. هرجا نرخ ارزی یا تعرفه Vendor مؤثر است، Currency، تاریخ، Tax و فرض رشد را ثبت کنید.
هزینه فرصت را جدا گزارش کنید
یک Launch دیرهنگام، Checkout کمتبدیل، Downtime یا پنل دشوار هزینه دارد؛ اما این اعداد را بدون داده داخل «قیمت ساخت» مخلوط نکنید. فرصت را با Range و سناریو گزارش کنید تا تصمیم MVP، Buy/Build یا فازبندی روشن شود.
کاهش هزینه با حذف ارزش فرق دارد
راههای سالم شامل کاهش Variant، استفاده از Component آماده معتبر، فازبندی Integration، پاکسازی محتوا پیش از مهاجرت، واگذاری تصمیم به Owner و Automation تست تکراری است. حذف Accessibility، Security، Backup یا QA فقط ریسک را به آینده منتقل میکند. گزینهها را در راهنمای کاهش هزینه طراحی سایت بدون افت کیفیت مقایسه کردهایم.
قالب Brief برای دریافت برآورد قابل مقایسه
1. Business outcome و KPI:
2. مخاطبان، زبان، جغرافیا، Device:
3. Journeyهای حیاتی و Failureهای مهم:
4. Sitemap / Content types / تعداد تقریبی:
5. Roleها، Permissionها و داده حساس:
6. Integrationها + مالک/Sandbox/Documentation:
7. محتوای موجود/جدید و مسئول هرکدام:
8. Migration: URL/Data/Media/Analytics:
9. Performance/A11y/Security/SEO acceptance:
10. Environment/Hosting/Backup/Recovery:
11. آموزش، Warranty، Support و SLA:
12. Deadline و دلیل آن:
13. Budget range و اولویت Must/Should/Could:
14. موارد Out of scope:
15. Assumptionها و Unknownها:
16. فرمت Breakdown مورد انتظار:
17. هزینههای یکباره/دورهای/مصرفی:
18. مالک Source/Design/Data/Account و Exit:خروجی مورد انتظار از ارائهدهنده
- WBS با Deliverable، Quantity و Acceptance؛
- Range هزینه/زمان و سطح Confidence؛
- Assumption، Dependency، Exclusion و Risk register؛
- Team composition و Allocation؛
- Milestone، Payment و Demo/Review point؛
- هزینه ثالث و تمدید؛
- Warranty، Support، SLA و نرخ Change؛
- IP/Source/Data/Account ownership و Exit plan؛
- تاریخ اعتبار Proposal و Trigger بازبرآورد.
چکلیست نهایی پیش از امضای قرارداد
- همه پیشنهادها بر Brief و Scope یکسان پاسخ دادهاند.
- قیمت به WBS، Quantity، Complexity و فرض وصل است.
- Unknownهای پرریسک Discovery/Spike دارند.
- Outcome، Deliverable و Acceptance از هم جدا و روشناند.
- محتوا، ورود داده، Redirect و Migration مالک دارند.
- Performance، Accessibility و Security نسخهدار و Testableاند.
- Failure mode اتصالها و هزینه مصرف Vendor دیده شده است.
- Change control و Baseline تازه تعریف شدهاند.
- Recurring cost، Support، Incident، Growth و Exit در TCO آمدهاند.
- Source، Design، Domain، Account و Data ownership روشن است.
برای مشاهده دامنه خدمات و چارچوب اولیه بودجه، صفحه قیمتگذاری و خدمات طراحی سایت مایندیو را ببینید. عدد نهایی فقط پس از همترازکردن Scope، ریسک و معیار پذیرش معنا دارد.
پرسشهای متداول
مهمترین عامل هزینه طراحی سایت چیست؟
یک عامل واحد وجود ندارد. تعداد و پیچیدگی Journey، Business rule، Role، Integration، محتوا/داده، سطح کیفیت و عدمقطعیت معمولاً از تعداد صفحه مهمترند. Estimate باید نشان دهد کدام Driver چه سهمی دارد.
چرا دو شرکت برای یک Brief قیمت متفاوت میدهند؟
ممکن است Scope، روش اجرا، سطح Seniority، کیفیت/تست، ریسک قرارداد، هزینه ثالث، Support و حاشیه متفاوت باشد. Proposalها را با Matrix Deliverable، Quantity، Acceptance، Assumption، Exclusion و TCO همسطح کنید؛ فقط مبلغ نهایی را مقایسه نکنید.
آیا میتوان پیش از جلسه شناخت قیمت دقیق گرفت؟
برای Scope کوچک و استاندارد شاید Range نسبتاً مطمئن ممکن باشد. برای پروژه دارای Integration، Role، Migration یا Requirement ویژه، عدد اولیه فقط Rough order of magnitude است. Discovery و Technical spike سطح Confidence را بالا میبرد.
چقدر بودجه ذخیره برای ریسک لازم است؟
درصد ثابت عمومی معتبر نیست. Risk register بسازید و احتمال/اثر Driverهای واقعی را بسنجید. هزینه شناختهشده وارد Scope شود و Contingency فقط Unknown باقیمانده را پوشش دهد. مصرف Reserve نیز باید تصمیم و گزارش داشته باشد.
هزینه نگهداری سایت شامل چه چیزهایی است؟
Hosting/CDN/Storage/Email، License و مصرف Vendor، مانیتورینگ، Backup/Restore، Update امنیتی، رفع Incident، Support کاربر/محتوا، بهبود Performance و تغییرات محصول. Warranty رفع Bug با نگهداری و Feature جدید یکسان نیست و باید جدا تعریف شود.
جمعبندی
برآورد واقعی طراحی سایت یک عدد سریع نیست؛ مدل قابل ممیزی از Scope، WBS، Quantity، Complexity، فرض، ریسک و چرخه عمر است. ابتدا Outcome و Journey را روشن کنید، سپس کار را به خروجی قابل پذیرش بشکنید، Range و Confidence بدهید و پیشنهادها را روی یک Matrix مقایسه کنید.
اگر فقط یک اقدام انجام میدهید، از هر ارائهدهنده بخواهید کنار هر مبلغ سه چیز بنویسد: چه چیزی تحویل میشود، بر چه فرضی و با چه شاهدی پذیرفته میشود. اختلاف قیمت پس از این سه پاسخ، قابل تحلیل میشود.
