طراحی سایت چقدر طول می‌کشد؟ روش برآورد

دو پروژه هر دو «سایت شرکتی ۲۰صفحه‌ای» هستند. اولی متن و تصویر تأییدشده، یک تصمیم‌گیر و فرم ساده دارد؛ دومی ۱۲۰۰ URL قدیمی، بازطراحی برند، سه زبان، اتصال CRM بدون Sandbox و پنج مدیر با تقویم تأیید متفاوت. اگر برای هر دو «شش هفته» اعلام شود، عدد بیشتر شبیه ابزار فروش است تا Forecast.

طراحی سایت چقدر طول می‌کشد؟ پیش از Discovery پاسخ معتبر یک بازه مشروط با سطح اطمینان است، نه تاریخ قطعی. پس از شکستن Scope، شناخت وابستگی‌ها، آزمون ریسک و مشاهده Throughput تیم می‌توان Forecast را باریک‌تر کرد. مدت پروژه از جمع ساعت‌های برنامه‌نویسی به دست نمی‌آید؛ Content، تصمیم، صف، Calendar، Integration، Migration، Verification و Launch نیز روی زمان سپری‌شده اثر دارند.

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

1. Scope baseline: چه Outcome/Journey/Content/Data/Quality در نسخه است؛
2. Schedule network: کارها، Owner، Dependency، Calendar و Milestone؛
3. Range: سناریوی زود/محتمل/دیر با Assumption؛
4. Confidence: مثلاً P50 برای برنامه داخلی و P80 برای تعهد حساس؛
5. Forecast cadence: تاریخ به‌روزرسانی، Evidence و Trigger بازبرآورد.

برای ترتیب فعالیت‌ها به مراحل طراحی سایت از Discovery تا Live و برای ورودی‌های پیش از قیمت‌گیری به نقشه آمادگی شروع سایت مراجعه کنید. این صفحه مالک روش برآورد و کنترل زمان است.

اول چهار مفهوم را جدا کنید

کاری با دو نفرـروز Effort ممکن است به‌دلیل انتظار دسترسی API و پاسخ حقوقی، ۱۲ روز Elapsed time داشته باشد. افزودن Developer لزوماً صف تصمیم یا وابستگی خارجی را کوتاه نمی‌کند.

چرا جدول «نوع سایت = چند هفته» گمراه‌کننده است؟

نوع سایت فقط یک برچسب بازاری است. Duration از ساختار واقعی کار می‌آید:

• تعداد Journey و State، نه فقط صفحه؛
• Content آماده یا نیازمند Research/Claim/ترجمه؛
• Template یکتا و Componentهای جدید؛
• Role، Rule، Data و حجم/کیفیت آن؛
• API، درگاه، CRM، پیامک و سرویس ثالث؛
• تعداد URL و پیچیدگی Migration؛
• Accessibility/Security/Privacy/Performance/SEO target؛
• تعداد تصمیم‌گیر، مهلت Review و نرخ تغییر؛
• تجربه/ظرفیت واقعی تیم و کارهای هم‌زمان؛
• Launch window، Hypercare و ریسک عملیات.

Landing متصل به پرداخت/CRM با Claim حقوقی ممکن است از سایت محتوایی چندTemplate‌ای پرریسک‌تر باشد.

سطح برآورد را با بلوغ اطلاعات اعلام کنید

دقت ظاهری «تحویل در ۴۳ روز» وقتی Scope و ریسک هنوز نامعلوم‌اند، کیفیت برآورد نیست.

گام ۱: واحد قابل‌برآورد تعریف کنید

صفحه واحد خوبی نیست؛ یک صفحه ممکن است Static باشد و دیگری Role/Data/Payment/Recovery داشته باشد. Work breakdown را تا خروجی قابل‌مالکیت بشکنید:

outcome → journey → vertical slice → activity/work package
→ owner → predecessor/successor → calendar
→ acceptance/evidence → uncertainty/risk

ریزشدن افراطی نیز هزینه نگهداری Schedule را بالا می‌برد. واحد باید به‌اندازه‌ای باشد که Dependency، Owner، Done و Range آن قابل‌فهم شود.

گام ۲: Inventory کمّی و کیفی بسازید

«۲۰ صفحه» بدون مشخص‌کردن پنج Template یا بیست Template، زبان، State و Content readiness داده برآورد نیست.

گام ۳: Dependency network را رسم کنید

GAO Schedule Assessment Guide برنامه قابل‌اعتماد را مدل یکپارچه‌ای از کار و روابط منطقی می‌داند که Critical path، تغییر و ریسک زمان را آشکار کند. Dependencyها را با تاریخ دستی پنهان نکنید.

content model → CMS schema → migration mapping → dry run
brand decision → tokens → components → templates
API access → contract spike → integration → failure test → UAT
URL inventory → destination mapping → redirects → crawl verification
release build → restore rehearsal → go/no-go → cutover → hypercare

Start-to-finish یا Lagهای مبهم را فقط با دلیل استفاده کنید. Dependency واقعی را از Preference سازمانی جدا کنید.

Critical path چیست؟

Critical path بلندترین زنجیره منطقیِ محرک Milestone پایان است؛ تأخیر آن بدون Float کافی، پایان را جابه‌جا می‌کند. «مهم‌ترین کار مدیر» یا «بزرگ‌ترین Epic» لزوماً Critical نیست.

Schedule را پس از هر Status update دوباره محاسبه کنید. GAO همچنین بر Near-critical path تأکید دارد؛ با تغییر Duration یا وقوع Risk، مسیر دیگری می‌تواند محرک پایان شود. فقط یک خط قرمز را پایش نکنید.

تقویم و ظرفیت واقعی را وارد کنید

• روز/ساعت کاری هر Role و منطقه زمانی؛
• تعطیلات رسمی، نوروز، پنجشنبه/جمعه و مرخصی؛
• ظرفیت جزئی افراد در چند پروژه؛
• جلسه، Support و کار عملیاتی؛
• مهلت واقعی Review مدیر/حقوقی/مالی؛
• پنجره درگاه، Vendor، دیتاسنتر یا تغییر DNS؛
• دسترسی Participant تحقیق و UAT؛
• Content freeze و Campaign blackout.

«یک Senior تمام‌وقت» را اگر فقط دو روز در هفته آزاد است، یک FTE فرض نکنید.

گام ۴: از داده تاریخی تیم استفاده کنید

Analogous estimate زمانی مفید است که Scope، Team، Quality و Context قابل‌مقایسه باشند. برای تیم پایدار:

• Cycle time distribution برای Itemهای هم‌کلاس؛
• Throughput در بازه زمانی؛
• Blocked time و علت؛
• Defect/rework/review latency؛
• نسبت Planned/Unplanned work؛
• Migration/launch incident history.

Velocity تیم دیگر یا Story point بین تیم‌ها قابل‌انتقال نیست. Point واحد زمان و معیار بهره‌وری افراد نیست.

گام ۵: برای کار نامطمئن Range بدهید

برای Activityهای مهم سه سناریو ثبت کنید:

O = optimistic when named favorable assumptions hold
M = most likely under current evidence
P = pessimistic under plausible risks, not apocalypse
range source = history / pilot / expert / vendor / unknown
confidence + review trigger

اگر از Three-point estimate یا فرمول PERT استفاده می‌کنید، فرض مدل را ثبت کنید. یک میانگینِ محاسبه‌شده عدم قطعیت شبکه و هم‌بستگی Riskها را حذف نمی‌کند.

P50 و P80 را به زبان ساده بفهمید

در تحلیل احتمالاتی، P50 یعنی حدود نیمی از خروجی‌های مدل در آن تاریخ یا زودتر پایان می‌یابند؛ P80 یعنی حدود ۸۰٪. این اعداد احتمال واقعی جهان نیستند مگر Input، Dependency، Calendar و Risk model قابل‌دفاع باشند.

P50 می‌تواند Forecast داخلی برای تصمیم‌های برگشت‌پذیر باشد؛ تعهد کمپین پرهزینه ممکن است Confidence بالاتر و Contingency روشن بخواهد. درصد را بدون روش، تاریخ داده و Scope نمایش ندهید.

Schedule risk analysis چه چیزی اضافه می‌کند؟

در برنامه دارای مسیرهای موازی، جمع Best guess معمولاً خوش‌بینانه است. تحلیل ریسک، Durationها و Risk eventها را بارها نمونه‌گیری می‌کند تا Distribution پایان و Risk criticality نشان دهد. GAO تأکید می‌کند تحلیل معتبر به شبکه کامل و منطق درست نیاز دارد؛ Monte Carlo روی Schedule بد فقط دقت ظاهری می‌سازد.

Buffer با Padding مخفی فرق دارد

اگر هر نفر Task را پنهانی دوبرابر کند و مدیر نیز ۳۰٪ روی کل اضافه کند، Schedule نه شفاف است نه قابل‌یادگیری. Uncertainty و Risk را آشکار ثبت کنید:

• Activity range برای ابهام ذاتی؛
• Risk event با احتمال/اثر/مالک/mitigation؛
• Project/Release contingency برای نوسان تجمعی؛
• Management reserve برای Unknownهای تعریف‌شده در Governance؛
• زمان Hypercare جدا از Build.

مصرف Buffer باید گزارش و Forecast بازتنظیم شود؛ آن را «زمان رایگان Scope جدید» ندانید.

Content اغلب Critical path پنهان است

برای هر Content item فقط Deadline متن ننویسید:

brief → source/research → draft → expert/legal/brand review
→ media/license/alt → CMS entry → responsive/A11y/SEO QA
→ approval → migration/publish → freshness owner

در سایت چندزبانه، Translation پس از Copy نهایی، Terminology QA و Layout/BiDi به Dependency تبدیل می‌شوند. نمونه‌کار بدون Consent یا Price بدون Owner نیز Done نیست.

Integration را با «API داریم» برآورد نکنید

یک Spike کوچک قبل از Commitment، Uncertainty را کم می‌کند. زمان این موارد را ببینید:

• دریافت دسترسی، NDA، IP allowlist و Sandbox؛
• خواندن/ابهام مستندات و Version؛
• Auth/refresh/secret rotation؛
• Rate/volume/latency؛
• Timeout/retry/idempotency/order؛
• Error/reconciliation/manual fallback؛
• Vendor support و Production approval؛
• UAT data و End-to-end evidence.

External dependency بدون پاسخ‌گوی نام‌دار و تاریخ Escalation، «سبز» نیست.

Migration دو ساعت Cutover نیست

Inventory، Mapping، Cleaning، Script، Dry run، Diff، Delta، Redirect و Reconciliation پیش از شب انتشار کار می‌خواهند. راهنمای مهاجرت سایت و Cutover این چرخه را عمیق توضیح می‌دهد.

Google Search Central زمان پردازش Migration را ثابت نمی‌داند؛ تعداد URL و سرعت Server اثر دارند، نوسان موقت Search ممکن است و پایش ادامه دارد. بنابراین «Go-live date» با «پایان مهاجرت Search/Outcome stabilization» یکی نیست.

Verification و رفع Defect را جداگانه زمان‌بندی کنید

تست فقط اجرای Checklist نیست؛ Environment، Data، Investigation، Fix، Retest و Regression زمان می‌خواهند. Severity profile و Defect arrival rate را از Pilot/Iterationهای اول به Forecast برگردانید.

راهنمای استراتژی تست وب Portfolio و Release gate را پوشش می‌دهد. Quality را برای رسیدن به تاریخ حذف نکنید؛ Scope/Sequence را تغییر دهید و Risk acceptance را صریح کنید.

Deadline ثابت را از Target جدا کنید

برای تاریخ ثابت، از عقب برنامه‌ریزی کنید

campaign/event date
← stabilization/measurement
← hypercare
← go-live window
← go/no-go + restore/rollback rehearsal
← UAT + critical defect closure
← migration dry run
← production-ready slices/content
← pilot/discovery/readiness

اگر شبکه در تاریخ جا نمی‌شود، فقط Taskها را روی هم نیندازید. گزینه‌های Scope کوچک‌تر، Phased release، Feature flag، Manual fallback، تغییر تاریخ یا توقف را مقایسه کنید.

چه چیزهایی را می‌توان موازی کرد؟

موازی‌سازی وقتی مفید است که Interface و Dependency روشن باشند:

Coordination cost، Merge، Review و Rework را صفر فرض نکنید. افزایش Work in progress معمولاً Lead time را بدتر می‌کند.

افزودن نفر همیشه پروژه را سریع نمی‌کند

افراد جدید Onboarding، Communication و Review می‌خواهند. اگر Bottleneck تصمیم محتوا، یک API خارجی یا UAT است، Developer بیشتر Critical path را کوتاه نمی‌کند. قبل از Staffing بپرسید:

• محرک واقعی Milestone چیست؟
• کار قابل‌تقسیم و Interface ثابت است؟
• Reviewer/Test environment ظرفیت دارد؟
• نیروی جدید مهارت Domain لازم را دارد؟
• افزایش Parallel work چه Integration risk می‌سازد؟

روش Forecast برای تیم جریان‌محور

اگر Backlog هم‌کلاس و Workflow پایدار است، Historical throughput/cycle time می‌تواند برای Simulation باقی‌مانده به کار رود. شروط:

• Definition of Done و item slicing نسبتاً ثابت؛
• Scope remaining شمارش‌پذیر و Changes ثبت‌شده؛
• Blocked/expedite/unplanned work در داده؛
• تقویم و ظرفیت آینده قابل‌مقایسه؛
• Forecast به‌صورت Distribution و تاریخ داده.

میانگین Velocity × Sprintها بدون Variation، Scope change و Dependency خارجی Confidence واقعی نمی‌دهد.

پیشرفت را با Done و Remaining uncertainty گزارش کنید

GOV.UK Measuring and reporting progress برنامه‌ریزی مستمر، Backlog شفاف و Show-and-tell را بخشی از گزارش طبیعی تیم می‌داند. داشبورد هفتگی مفید:

as-of date + baseline/version
done outcomes/slices with evidence
remaining scope + change
blocked age/owner
critical & near-critical path
top schedule risks
forecast P50/P80 or low/likely/high
next decision/milestone + confidence
budget/buffer consumption

«۷۵٪ تمام» وقتی چهار Journey نیمه‌کاره‌اند، اطلاعات کمی می‌دهد. Burnup Scope و Done را جدا نشان می‌دهد.

چه زمانی باید بازبرآورد کرد؟

• Scope/Acceptance/Quality target تغییر کرد؛
• Pilot فرض مهمی را رد کرد؛
• Content/Data/Integration readiness متفاوت درآمد؛
• Critical یا near-critical path عوض شد؛
• Throughput/cycle time از Range خارج شد؛
• Defect/incident/rework بالا رفت؛
• Vendor/مجوز/دسترسی تأخیر کرد؛
• تیم/Calendar/Launch constraint تغییر کرد؛
• Contingency سریع‌تر از انتظار مصرف شد.

Reforecast شکست برنامه‌ریزی نیست؛ پنهان‌کردن Evidence تازه شکست Governance است.

نمونه سناریو، نه وعده عمومی

فرض کنید یک سایت B2B دارای ۶ Template، ۴۰ URL قابل‌مهاجرت، یک Form→CRM، محتوای فارسی آماده ۶۰٪، یک Decision owner و Design system موجود است. پس از Discovery و Spike CRM، تیم سه سناریو می‌سازد:

خود عددها باید از شبکه، تاریخچه و ظرفیت همان تیم تولید شوند. اگر CRM یا محتوا هنوز آزموده نشده، Range گسترده می‌ماند.

ریسک‌های زمانی ویژه پروژه‌های ایران

• تعطیلات نوروز/تقویم شمسی و اختلاف Calendar ابزار؛
• پنجشنبه/جمعه و تیم/فروشنده با Weekend متفاوت؛
• فرایند PSP، اینماد، پیامک و دسترسی Production؛
• نوسان ارز/تمدید SaaS و Procurement؛
• دسترسی ناپایدار سرویس خارجی یا شبکه؛
• فونت/مجوز/محتوای فارسی و اصلاح RTL/BiDi؛
• ریال/تومان و تست Finance/Reconciliation؛
• دسترسی تصمیم‌گیران در نمایشگاه، رمضان یا پایان سال مالی؛
• محدودیت دیتاسنتر/دامنه/DNS و پنجره تغییر؛
• نبود Sandbox یا پاسخ‌گویی Vendor.

ریسک محلی را به Buffer مبهم تبدیل نکنید؛ Trigger، Owner، پاسخ و اثر Range بدهید.

زمان و هزینه یک سیستم‌اند

تأخیر می‌تواند هزینه Team/Vendor/Hosting و Opportunity را بالا ببرد؛ فشرده‌سازی نیز Overtime، Defect، Rework و Support می‌سازد. راهنمای هزینه‌های پنهان و TCO سایت سبد هزینه را توضیح می‌دهد و تصمیم زمان و بودجه بازطراحی Trade-offهای Root cause و Option را پوشش می‌دهد.

Duration پروژه با زمان مشاهده نتیجه یکی نیست

برای Time to stabilize، SLO و Incident readiness از راهنمای Observability سایت استفاده کنید.

چک‌لیست پذیرش Forecast

• As-of date، Scope version و Definition of Done دارد؛
• Effort/Duration/Elapsed و Calendar جدا هستند؛
• همه Trackها و کار کارفرما/Vendor دیده شده‌اند؛
• Dependency network و Critical/near-critical path معتبر است؛
• تاریخ دستی و Lag مبهم کم و موجه‌اند؛
• Range source و Assumptionها ثبت شده‌اند؛
• Risk event و Mitigation/Trigger/Owner دارند؛
• Confidence به روش/داده متصل است؛
• Content/Integration/Migration/Test/Launch/Hypercare داخل Scope زمانی‌اند؛
• Contingency از Padding پنهان جداست؛
• Deadline/Target/Forecast/Commitment جدا هستند؛
• Cadence و Trigger بازبرآورد روشن است.

خطاهای رایج برآورد زمان طراحی سایت

• قول هفته بر اساس برچسب «شرکتی/فروشگاهی»؛
• جمع ساعت Coding به‌عنوان پایان پروژه؛
• صفحه به‌عنوان واحد Complexity؛
• نادیده‌گرفتن Review و کار کارفرما؛
• یک تاریخ بدون Scope/Assumption/Confidence؛
• تقویم افراد با ظرفیت ۱۰۰٪؛
• وابستگی با Date constraint دستی؛
• تمرکز فقط بر Critical path فعلی؛
• انتقال Velocity/Point تیم دیگر؛
• Monte Carlo روی Schedule ناقص؛
• Padding پنهان و Buffer دوبرابر؛
• Content/API/Migration به‌عنوان کار جانبی؛
• QA بدون زمان Fix/Retest؛
• افزودن نفر بدون تحلیل Bottleneck؛
• یکی‌گرفتن Launch، Stabilization و Outcome.

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

این راهنما در ۱۲ اوت ۲۰۲۶ بازبینی شده است. هیچ Range عمومی جای Discovery، Pilot، داده تاریخی تیم و تحلیل ریسک همان پروژه را نمی‌گیرد.

• U.S. GAO: Schedule Assessment Guide
• GOV.UK: Measuring and reporting progress
• GOV.UK: Developing a roadmap
• Google Search Central: Site moves and migrations

سؤالات متداول زمان طراحی سایت

طراحی سایت معمولاً چقدر طول می‌کشد؟

بدون Scope و Evidence پاسخ قابل‌اعتماد وجود ندارد. نوع سایت، Content/Data/Integration/Migration، Quality، تیم و Review را به شبکه کار تبدیل کنید و Range مشروط بدهید. پس از Discovery/Pilot و مشاهده Throughput، Forecast دقیق‌تر می‌شود.

آیا سایت شرکتی در یک هفته ساخته می‌شود؟

یک Template آماده با محتوای حاضر شاید Deploy شود، اما این ادعا چیزی درباره Discovery، محتوای معتبر، طراحی، Accessibility/Security/SEO، Integration، QA، مالکیت و عملیات نمی‌گوید. Scope و Definition of Done را کنار تاریخ بخواهید.

چطور زمان طراحی سایت را کوتاه کنیم؟

پرریسک‌ترین فرض را زود Pilot کنید، Content/Decision/API access را آماده کنید، WIP را محدود و Vertical slice کامل بسازید، Scope نسخه نخست را کم و Release را مرحله‌ای کنید. Quality gate بحرانی را حذف نکنید.

تأخیر کارفرما چگونه در برنامه حساب می‌شود؟

Content، دسترسی و Review کارفرما Activity واقعی با Owner، Calendar، SLA و Dependency هستند. تأخیر را بر Critical path و Forecast محاسبه و Change record کنید؛ همه تأخیرها را خودکار به یک طرف نسبت ندهید.

P50 و P80 در زمان‌بندی پروژه چیست؟

P50/P80 Percentile خروجی مدل‌اند: حدود ۵۰٪/۸۰٪ سناریوهای شبیه‌سازی‌شده تا آن تاریخ تمام می‌شوند. اعتبار آن‌ها به شبکه، Range، Risk، Calendar و داده Input وابسته است؛ تضمین یا احتمال ذاتی پروژه نیستند.

جمع‌بندی: تاریخ را نتیجه مدل کنید، نه ورودی دلخواه

برآورد خوب «حدس دقیق‌تر» نیست؛ ساخت مدلی شفاف از Scope، کار، Dependency، Calendar، Uncertainty و Risk است که با Evidence تازه به‌روزرسانی می‌شود. یک Range همراه Confidence و Assumption، از تاریخ قطعیِ بی‌پشتوانه مفیدتر است.

همین امروز جدول سه‌ستونه بسازید: «Milestone، محرک/Dependency، Range و دلیل». سپس Critical path، سه Risk زمان و تاریخ Reforecast را اضافه کنید. اگر تاریخ نهایی بدون این‌ها تغییرناپذیر است، آن عدد Forecast نیست؛ Constraintی است که باید Scope و ریسک آن آگاهانه طراحی شود.