Effort Estimation و Probabilistic ETA

یک تاریخ بدون نمایش عدم‌قطعیت، Forecast Contract نیست

یک تیم سامانهٔ یادگیری baseline فعلی، بخشی از effort واقعی و چند task باقی‌مانده دارد. دو task به هم وابسته‌اند، یک external review ممکن است تأخیر ایجاد کند و مدیر فقط یک «تاریخ تحویل» می‌خواهد. اگر فقط یک تاریخ بدهیم، دقیقاً همان شواهدی را پنهان کرده‌ایم که نشان می‌دهند این تاریخ قطعی نیست.

در این درس Probabilistic Effort & ETA Forecast Contract v1 ساخته می‌شود. actualهای مشاهده‌شده از فرض‌های remaining work جدا می‌شوند؛ duration distribution و basis آن، dependency، discrete risk، model/run evidence، completion distribution، P50/P80، sensitivity، margin و forecast revision همگی صریح می‌مانند.

قوی‌ترین خروجی موفق FORECAST_REVIEW_REQUIRED است. percentile ابزار تصمیم‌گیری محدود است، نه تضمین. Lab کاملاً synthetic و offline است و هیچ baseline واقعی یا تعهد بیرونی را تغییر نمی‌دهد.

برای: مهندسان پلتفرم/محصول، project-control ownerها، delivery leadها، analytics engineerها و reviewerها. نه برای: تعهد قراردادی، تشخیص فشار کاری/سلامت، ساختن probability بدون evidence، estimate پنهان AI یا جابه‌جایی بی‌ردپای baseline.

جهت مسیر و مرز مالکیت

MKN-016 مالک evidence مربوط به effort estimation و probabilistic ETA است. prerequisite سخت آن MKN-013 و prerequisite نرم آن MKN-015 است. MKN-015 weighted progress/control tower را مالک است و MKN-017 OAuth/OIDC و social publishing را. این درس می‌تواند progress evidence را مصرف کند، اما outcome درس مجاور را جذب نمی‌کند.

برای learner پایه، یک schedule سه-task را از assumption تا P50/P80 دنبال کنید. در مسیر repair، روی اولین evidence ناقص یا stale توقف کنید. learner باتجربه باید از distribution basis، dependency/risk model، percentile communication، sensitivity و revision trigger دفاع کند.

Checkpointها: F1 actual effort را از remaining-work assumption جدا کن؛ F2 single-point duration را به‌جای uncertainty نپذیر؛ F3 وقتی دو task زودتر تمام شدند اما risk review قطعی شد، forecast را دوباره محاسبه کن و P80 قبلی را برای حفظ ظاهر ثبات نگه ندار.

مدل ذهنی: evidence → uncertainty model → distribution → percentile decision → revision

مسیر اصلی:

baseline + actuals + remaining work → duration distributions + dependencies + discrete risks → deterministic simulation contract → completion distribution → P50/P80 + margin + sensitivity → human forecast review → revision on change

actual_effort_to_date evidence مشاهده‌شده است؛ remaining_work_estimate فرض فعلی دربارهٔ کار باقی‌مانده است. duration distribution عدم‌قطعیت elapsed duration را بیان می‌کند و با effort یکی نیست. discrete risk نیز probability و impact مستقل دارد و نباید بدون provenance داخل task duration مخفی شود.

خروجی اصلی distribution است. P50 و P80 summaryهای همان distribution و assumptions هستند. هیچ‌کدام guarantee نیستند. اگر actual، scope یا risk تغییر کرد، forecast قبلی historical evidence می‌ماند و یک forecast_revision جدید ساخته می‌شود.

قرارداد پایه: بیست بُعد Evidence فریز‌شده

ابعاد فریز‌شده عبارت‌اند از forecast_id، baseline_ref، work_package_ref، actual_effort_to_date، remaining_work_estimate، duration_distribution، distribution_basis، dependency_ref، discrete_risk_ref، risk_probability، risk_impact، simulation_model_ref، completion_date_distribution، p50_date، p80_date، confidence_level، schedule_margin، sensitivity_driver، forecast_revision و review_owner.

Invariantهای حداقلی:

1. forecast/baseline/work package هویت و نسخهٔ روشن دارند.
2. actual effort از assumption کار باقی‌مانده جداست.
3. durationهای باقی‌مانده distribution غیرتک‌نقطه‌ای و basis مستند دارند.
4. dependencyها صریح‌اند؛ ترتیب ردیف جای graph را نمی‌گیرد.
5. discrete risk probability و impact دارد؛ missing probability برابر صفر فرض نمی‌شود.
6. simulation model و run count نسخه‌دار و reproducible هستند.
7. completion distribution خروجی اصلی و P50/P80 summary آن است.
8. P80 در همان distribution نمی‌تواند زودتر از P50 باشد.
9. margin باید به uncertainty/risk متصل باشد، نه buffer پنهان برای ثابت نگه‌داشتن تاریخ.
10. sensitivity نشان می‌دهد کدام assumption بیشترین اثر را دارد.
11. تغییر actual/scope/risk نیازمند revision جدید است.
12. owner و provenance امکان audit تصمیم را می‌دهند.

توضیح عمیق: Uncertainty، Margin و زبان Percentile

Schedule Risk Analysis — FACT. NASA در PP&C Glossary جاری، SRA را تحلیل احتمالاتی schedule با Monte Carlo، duration uncertainty distribution و discrete risk تعریف می‌کند که confidence level برای completion/milestone تولید می‌کند. این منبع شکل distribution، تعداد run یا threshold داخلی MAKNOW را تعیین نمی‌کند.

Schedule Margin — FACT. راهنمای NASA margin را allowance برای uncertainty و risk می‌داند و probabilistic schedule assessment را مبنایی برای سنجش کفایت margin معرفی می‌کند. همچنین margin نباید صرفاً برای ثابت نگه‌داشتن یک forecast date استفاده شود.

Forecast Communication — INFERENCE. در MAKNOW به‌جای یک تاریخ قطعی، چند percentile همراه assumption و sensitivity گزارش می‌شود. با تغییر actual یا risk، forecast قبلی حفظ و revision جدید محاسبه می‌شود.

MAKNOW — DESIGN. distribution family، minimum run count، نمایش P50/P80، sensitivity method، typed stateها و سقف FORECAST_REVIEW_REQUIRED authority داخلی هستند.

مثال‌های کارشده

مثال A — baseline با عدم‌قطعیت آشکار

سه task باقی‌ماندهٔ serial distribution مثلثی با min/mode/max دارند. external review با probability برابر 25% می‌تواند delay مثلثی اضافه کند. Lab با seed و run count ثابت completion distribution را تولید می‌کند. P50 و P80 از همان distribution به‌دست می‌آیند؛ فاصلهٔ آن‌ها به‌عنوان margin توضیح داده می‌شود و نتیجه FORECAST_REVIEW_REQUIRED است.

مثال B — shortcut تک‌نقطه‌ای

planner تمام distributionها را با یک «best estimate» جایگزین می‌کند. محاسبه هنوز ممکن به‌نظر می‌رسد، اما evidence عدم‌قطعیت حذف شده است. state درست HOLD_UNCERTAINTY_MODEL است؛ Monte Carlo روی constantها uncertainty واقعی نمی‌سازد.

مثال C — Risk قطعی می‌شود

external review از 25% به 100% تغییر می‌کند ولی forecast revision قدیمی می‌ماند. نتیجه REFORECAST_REQUIRED است. repair این نیست که P80 را دستی ویرایش کنیم؛ باید risk state به‌روز، revision جدید ساخته و model دوباره اجرا شود.

مثال D — Transfer بعد از یک هفته

دو task زودتر از برنامه تمام شده‌اند، اما external-review risk قطعی شده است. actual بهتر و risk بدتر شده. forecast باید از state جدید محاسبه شود. ممکن است P80 نزدیک یا حتی دیرتر از P80 قبلی بماند؛ نگه داشتن تاریخ قبلی فقط برای «ظاهر ثبات» provenance را خراب می‌کند.

Failure modeهایی که باید Fail-closed شوند

• جایگزینی distribution با single-point duration → HOLD_UNCERTAINTY_MODEL.
• وجود distribution بدون basis → HOLD_DISTRIBUTION_BASIS.
• dependency به task ناموجود یا graph ناسازگار → HOLD_DEPENDENCY.
• risk بدون probability یا impact → HOLD_RISK_MODEL.
• تغییر actual/risk بدون revision تازه → REFORECAST_REQUIRED.
• فقط یک due date بدون completion distribution → HOLD_OUTPUT_CONTRACT.
• simulation model/version یا run count ناقص → HOLD_MODEL_EVIDENCE.
• sensitivity evidence مفقود → HOLD_SENSITIVITY.
• هویت forecast/baseline/work package ناقص → HOLD_SCOPE_IDENTITY.
• owner/provenance ناقص → HOLD_AUDIT_PROVENANCE.
• Transfer نتیجهٔ baseline را copy کند → HOLD_BASELINE_ORACLE_REUSE.

Alternativeها و Trade-offها

Three-point/triangular duration. توضیح‌پذیر و مناسب تمرین bounded است، اما اگر min/mode/max basis واقعی نداشته باشند false precision می‌سازد.

Historical empirical distribution. با دادهٔ مشابه بهتر grounded می‌شود، ولی comparability و drift باید دفاع شوند.

Scenario band به‌جای Monte Carlo. برای پروژه کوچک ساده‌تر است، اما interaction چند risk و full distribution را از دست می‌دهد.

P50 به‌عنوان planning date. برای planning داخلی سبک‌تر است، اما احتمال exceed شدن بیشتری نسبت به percentile بالاتر دارد.

P80 به‌عنوان review point. محافظه‌کارانه‌تر است، ولی guarantee نیست و باید همراه assumption/revision نمایش داده شود.

Static buffer بزرگ. ساده است اما به‌راحتی با commitment اشتباه گرفته می‌شود. margin risk-informed و revision history قابل‌دفاع‌تر است.

پل باتجربه‌ها: چهار چیزی که ارزش دفاع دارند

اول provenance assumption را حفظ کن. probability یا spread بدون basis با داشتن رقم اعشاری معتبر نمی‌شود.

دوم هویت model را حفظ کن. reproducibility نیازمند model ref، seed/run contract و input evidence نسخه‌دار است.

سوم sensitivity را بر narrative ترجیح بده. اگر یک task یا risk driver اصلی است، همان را نشان بده؛ narrative نباید driver ضعیف را صرفاً به دلیل راحتی سیاسی برجسته کند.

چهارم revision history را نگه دار. forecast v1 با آمدن evidence جدید حذف نمی‌شود؛ historical می‌ماند و v2 با change reason ساخته می‌شود. این مرز auditability با cosmetic scheduling است.

تمرین هدایت‌شده و مستقل

Guided: lab://MKN-016/MKN-016-LAB1 را باز کن. baseline را اجرا و duration distribution، dependency، risk probability/impact، model ثابت و P50/P80 را مشاهده کن. توضیح بده چرا سقف outcome فقط review انسانی است.

Repair: هر بار یک dimension را mutate کن: distribution را constant کن، basis را حذف کن، dependency را بشکن، risk impact را حذف کن، sensitivity را پاک کن یا actual را بدون revision تغییر بده. اولین state نامعتبر و کوچک‌ترین repair را نام ببر.

Independent: Transfer fixture را اجرا کن. دو task زودتر تمام شده و external review قطعی شده است. actual، remaining work، risk state و revision را به‌روز کن و دوباره forecast بساز. percentile baseline oracle نیست.

Verification Evidence؛ Reviewer چه چیزی را باید بازسازی کند؟

Reviewer باید بتواند baseline/work package، actual effort، remaining work، duration distribution و basis، dependency graph، discrete risk probability/impact، model/run count، completion distribution، P50/P80، confidence، margin، sensitivity driver، revision و owner را از evidence آشکار بازسازی کند.

همچنین باید مرزهای منفی را ثابت کند: constant جای uncertainty را نگرفته؛ missing risk به صفر تبدیل نشده؛ margin برای فریز کردن تاریخ قدیمی مصرف نشده؛ تغییر actual/risk revision جدید ساخته؛ و Transfer از fixture جدید recompute شده است.

اگر evidence decisive ناقص، stale یا متناقض باشد، state باید hold/reforecast باقی بماند. تاریخ «معقول» evidence نیست.

Assessment و Transfer

S1: تفاوت actual effort، remaining-work estimate و duration uncertainty را توضیح بده. S2: برای baseline، Probabilistic Effort & ETA Forecast Contract v1 را بساز و P50/P80 و driver اصلی sensitivity را گزارش کن. S3: distributionها را single-point کن؛ evidence باطل‌شده و state امن را مشخص کن. S4: یک هفته بعد دو task زودتر تمام شده‌اند ولی external-review risk قطعی است. forecast را با revision جدید از صفر بساز و P80 را با baseline مقایسه کن.

Misconception مسدودکننده: «P80 یعنی 80 درصد تضمین و بعد از اعلام باید ثابت بماند.»

AI می‌تواند evidence synthetic را مرتب و simulation deterministic را اجرا کند؛ حق ندارد distribution، probability، confidence، state واقعی پروژه یا commitment را اختراع کند.

منابع، Freshness و مرز Authority

• NASA PP&C Glossary — FACT: SRA را probabilistic schedule analysis با duration uncertainty، discrete risk و Monte Carlo می‌داند و confidence level برای milestone/completion تولید می‌کند.
• NASA Schedule Management Handbook — FACT: schedule margin به uncertainty/risk متصل است و probabilistic schedule assessment می‌تواند برای کفایت margin استفاده شود؛ margin ابزار فریز کردن مصنوعی forecast نیست.
• MAKNOW inference/design: percentileهای انتخابی، minimum run count، sensitivity method، typed hold states و revision policy authority داخلی هستند.

Freshness در 2026-09-13 دوباره بررسی شد. بازبینی بعدی حداکثر تا 2027-01-15 یا زودتر در صورت تغییر معنادار guidance ناسا انجام شود.