Weighted Project Progress و Control Tower

داشبورد شلوغ می‌تواند درصد درست‌نما ولی تصمیم غلط بسازد

یک capstone بیست task دارد. دوازده task کوچک مستندسازی بسته شده‌اند؛ بنابراین داشبورد task-count عدد ۶۰٪ را نشان می‌دهد. اما Deployment Rehearsal، Rollback Evidence، Accessibility QA، Integration و Final Review هنوز بازند. وقتی هر task را مساوی بگیریم، پروژه دقیقاً در جایی سبزتر دیده می‌شود که کارهای پرریسک هنوز انجام نشده‌اند.

در این درس Weighted Learning-Project Progress & Control Tower Contract v1 را می‌سازیم: baseline مشخص، weight basis ازپیش‌اعلام‌شده، planned weight، completion evidence، earned weight، varianceهای جدا، critical milestone، risk/forecast state و change-control revision. وزن‌ها بعد از دیدن نتیجه نباید دستکاری شوند و revision جدید نباید تاریخ revision قبلی را بازنویسی کند.

سقف state موفق CONTROL_TOWER_REVIEW_REQUIRED است. Control Tower evidence را برای تصمیم انسانی مرتب می‌کند؛ baseline واقعی را تغییر نمی‌دهد و تاریخ تحویل بیرونی commit نمی‌کند.

مخاطب: مهندس پلتفرم یادگیری، مالک project control، delivery lead، analytics engineer و reviewer. خارج از دامنه: vanity metric بر اساس task count، reweight پنهان، completion evidence ساختگی، تشخیص سلامت/فرسودگی یا تعهد قراردادی تاریخ تحویل.

Route و مرز مالکیت درس

MKN-015 مالک evidence مربوط به weighted project progress و Control Tower است. MKN-013 پیش‌نیاز hard و MKN-014 پیش‌نیاز soft است. MKN-014 مالک Learning Fatigue/Anti-overlearning و MKN-016 مالک Probabilistic ETA است. این درس می‌تواند evidence محدود آن‌ها را مصرف کند، اما حق ندارد از telemetry تشخیص سلامت بسازد یا درصد progress را به promise زمانی تبدیل کند.

در مسیر Foundation یک baseline فریز‌شده را از planned weight تا earned weight دنبال کن. در مسیر Repair روی اولین evidence خراب توقف کن. در مسیر Experienced از weight basis، variance interpretation، critical milestone، change-control revision و history reconciliation دفاع کن.

Checkpointها: F1 توضیح بده چرا ۱۲/۲۰ authority پیشرفت نیست؛ F2 reweight بعد از دیدن progress بد را رد کن؛ F3 scope change را approve کن، baseline revision جدید بساز و درصد قبلی را به‌عنوان history نگه دار.

مدل ذهنی: Baseline → Earned Evidence → Variance → Control Tower → Rebaseline

جریان را این‌طور نگه دار:

approved scope → declared weight basis → frozen planned weights → completion evidence → earned weight → weighted progress + schedule/effort variance → milestone/risk/forecast state → human review → governed change request → new baseline revision with old history retained

planned_weight قبل از معلوم شدن outcome تعیین می‌شود. earned_weight فقط وقتی شناخته می‌شود که completion rule و evidence قابل مشاهده وجود داشته باشد. Raw task count فقط یک آمار کمکی است، نه authority progress.

Schedule variance و effort/cost variance سؤال‌های متفاوتی از weighted progress جواب می‌دهند. ممکن است earned progress خوب باشد اما critical milestone عقب باشد؛ یا schedule جلو باشد ولی effort بسیار بیشتر مصرف شده باشد. Control Tower این signalها را جدا نگه می‌دارد.

با scope change، baseline قبلی immutable history می‌ماند. change request تأییدشده baseline revision جدید می‌سازد؛ reportهای قبلی دوباره محاسبه نمی‌شوند انگار scope جدید از روز اول وجود داشته است.

Foundation Contract؛ هفده بُعد فریز‌شده

ابعاد فریز‌شده عبارت‌اند از project_id، baseline_id، work_package_id، scope_ref، weight_basis، planned_weight، planned_date، actual_completion_evidence، earned_weight، actual_effort_or_cost، schedule_variance، critical_milestone، risk_state، forecast_state، change_request_ref، baseline_revision و control_owner.

Invariantهای اصلی:

1. هویت Project/Baseline/Work Package روشن است.
2. weight basis قبل از مشاهدهٔ earned progress اعلام می‌شود.
3. planned weightها به total baseline reconcile می‌شوند و بعداً بی‌صدا تغییر نمی‌کنند.
4. earned weight از planned weight بیشتر نمی‌شود.
5. earned weight مثبت بدون completion evidence مجاز نیست.
6. task-count جای weighted progress را نمی‌گیرد.
7. schedule variance و effort/cost evidence از progress جدا می‌مانند.
8. critical milestone حتی با taskهای کوچک کامل‌شده دیده می‌شود.
9. risk و forecast state صریح‌اند؛ missing evidence سبز نمی‌شود.
10. scope change approval و baseline revision جدید می‌خواهد.
11. revision جدید history baseline قبلی را نگه می‌دارد.
12. control owner و provenance تصمیم را بازسازی‌پذیر می‌کنند.

توضیح عمیق؛ discipline اندازه‌گیری را بگیر، ادعای compliance نساز

Integrated performance measurement — FACT. DOE، EVM را رویکردی برای یکپارچه‌سازی scope، schedule و cost/technical accomplishment معرفی می‌کند تا performance جاری عینی‌تر سنجیده و trend برای performance آینده استفاده شود. همچنین approved baseline و milestoneهای مهم در تحلیل دیده می‌شوند. MAKNOW از این discipline برای learning project محدود استفاده می‌کند.

Planned / Earned / Actual — FACT. در guidanceهای DOE، ارزش کار برنامه‌ریزی‌شده، ارزش کار انجام‌شده و actual cost از هم جدا می‌شوند و مقایسهٔ آن‌ها variance می‌سازد. در MAKNOW unit می‌تواند weight point غیرپولی باشد؛ بنابراین ادعای formal EVMS compliance نداریم.

Weighted progress — INFERENCE. در capstone، وزن می‌تواند contribution یا risk-bearing importance را نسبت به task-count بهتر منعکس کند. نکتهٔ کلیدی خود عدد نیست؛ declared، reviewable و stable بودن basis در طول یک baseline revision است.

Control Tower Gateها — DESIGN. MAKNOW می‌خواهد هر درصد به work-package evidence، baseline revision و stateهای variance/risk/forecast وصل باشد. threshold و labelهای خاص authority داخلی‌اند.

Worked Example؛ ۶۰٪ بر اساس Count می‌تواند فقط ۲۴٪ بر اساس Weight باشد

مثال A — Baseline. دوازده task مستندسازی کامل‌اند و هرکدام ۲ point وزن دارند؛ پس task count = ۱۲/۲۰ = ۶۰٪ ولی earned weight = ۲۴/۱۰۰ = ۲۴٪. Deployment Rehearsal با وزن ۱۵، Rollback Evidence با ۱۲، Accessibility QA با ۱۲، Integration با ۱۰ و Security QA با ۹ هنوز بازند. Control Tower عدد weighted را progress authority می‌گیرد و task count را فقط context نگه می‌دارد.

مثال B — Shortcut نامعتبر. بعد از دیدن ۲۴٪، تیم وزن کارهای باز critical را کم و وزن documentationهای بسته را زیاد می‌کند، بدون scope change مصوب. arithmetic شاید عدد قشنگ‌تری بسازد اما baseline بعد از مشاهدهٔ outcome بازنویسی شده است. State: HOLD_BASELINE_INTEGRITY.

مثال C — Change کنترل‌شده. یک feature حذف و security review اجباری اضافه می‌شود. CR-017 تأیید می‌شود، baseline revision 2 ساخته و weightها برای scope جدید بازتعریف می‌شوند. Revision 1 با historical weighted progress = 24% دست‌نخورده می‌ماند.

Failure Modeها و State امن

• Task-count inflation: taskهای کم‌وزن بسته‌اند ولی critical work باز است؛ CONTROL_TOWER_REVIEW_REQUIRED با alert TASK_COUNT_OVERSTATES_PROGRESS.
• Reweight بعد از دیدن performance: HOLD_BASELINE_INTEGRITY.
• Earned weight بدون evidence: HOLD_COMPLETION_EVIDENCE.
• Earned weight بیشتر از planned: HOLD_EARNED_WEIGHT.
• Variance evidence ناقص: HOLD_VARIANCE_EVIDENCE.
• Scope change بدون approval: HOLD_CHANGE_CONTROL.
• Change تأیید شده بدون revision جدید/history: REBASELINE_REQUIRED.
• Risk/forecast state ناقص: HOLD_FORECAST_STATE.
• Critical milestone identity ناقص: HOLD_MILESTONE_EVIDENCE.
• Control owner مفقود: HOLD_CONTROL_OWNER.
• Provenance مفقود: HOLD_AUDIT_PROVENANCE.

درصد ظاهراً معقول evidence chain خراب را درست نمی‌کند.

Alternativeها و Trade-offها

Equal task count: ارزان و ساده است ولی فقط وقتی work unitها واقعاً comparable باشند قابل‌دفاع است.

Fixed weighted milestones: برای کارهای ناهمگن بهتر است، اما weight basis باید قبل از outcome مشخص و change-controlled باشد.

Binary 0/100 earning: جلوی subjective 90% complete را خوب می‌گیرد، ولی برای work package طولانی coarse است. اگر partial earning داریم، rule باید از قبل objective باشد.

Effort-weighted progress: گاهی proxy مفیدی است، اما effort spent خودبه‌خود value earned نیست. کار دشوار می‌تواند effort بسوزاند و هنوز completion evidence نداشته باشد.

Composite Control-Tower score: برای executive جذاب است ولی scope/schedule/effort/risk را در یک عدد پنهان می‌کند. decomposed evidence + bounded review state شفاف‌تر است.

پل Experienced؛ از چهار چیز دفاع کن

اول baseline semantics را حفظ کن؛ denominator باید در تمام یک revision یک معنا داشته باشد.

دوم earning rule را حفظ کن؛ value با completion evidence earn می‌شود، نه با تایپ دستی ۹۰٪.

سوم variance decomposition را حفظ کن؛ progress واحد نمی‌تواند late بودن، effort overrun و unresolved risk را هم‌زمان توضیح دهد.

چهارم history under change را نگه دار؛ revision 2 حق دارد درصد جدیدی داشته باشد، اما revision 1 باید قابل بازسازی باشد. این مرز governed rebaseline با retroactive storytelling است.

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

Guided: lab://MKN-015/MKN-015-LAB1 را اجرا کن. توضیح بده چرا raw count برابر ۶۰٪ است ولی weighted progress برابر ۲۴٪ و کدام critical work هنوز باز است.

Repair: هر بار یک dimension را خراب کن: completion evidence را بردار، earned را بیش از planned کن، variance را حذف کن، change را unapproved کن، بعد از approval revision را جلو نبر، risk/forecast را حذف کن، owner یا provenance را پاک کن. اولین state امن و کوچک‌ترین repair را نام ببر.

Independent: Transfer fixture را اجرا کن. یک feature حذف و security review اجباری اضافه شده است. Revision 2 را بساز، revision 1 history را نگه دار و weighted view جدید را از evidence جدید recompute کن؛ baseline answer oracle نیست.

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

Reviewer باید project/baseline identity، work packageها، scope ref، weight basis، planned weights، completion evidence، earned weights، actual effort/cost، schedule variance، critical milestone، risk/forecast state، change request، baseline revision، owner و provenance را بازسازی کند.

همچنین raw task-count و weighted progress را مستقل محاسبه کند. اگر داشبورد count عدد ۶۰٪ و evidence weighted عدد ۲۴٪ بدهد، هر دو arithmetic درست‌اند ولی فقط weighted progress در این baseline authority است.

در revision جدید، baseline قبل و historical progress آن هم باید قابل بازیابی باشد. اگر revision 1 ناپدید شده یا report قدیمی با denominator جدید بازنویسی شده باشد، change-control chain معتبر نیست.

Assessment و Transfer

S1: توضیح بده چرا completed-task ratio وقتی work packageها value متفاوت دارند authority پیشرفت نیست. S2: برای baseline، Weighted Learning-Project Progress & Control Tower Contract v1 را بساز و count/weighted progress/variance/critical state را reconcile کن. S3: بعد از دیدن progress بد، وزن workهای باز را تغییر بده؛ evidence boundary نقض‌شده و state امن را مشخص کن. S4: یک feature را حذف، security review اجباری را اضافه، change را approve و revision 2 را بساز، درحالی‌که revision 1 history حفظ می‌شود.

Misconception مسدودکننده: «اگر بیش از نصف taskها بسته‌اند، پروژه هم بیش از نصف کامل است.»

AI می‌تواند evidence synthetic را مرتب و calculation deterministic را اجرا کند؛ حق ساخت completion evidence، تغییر وزن پس از outcome، approve change request، mutation baseline واقعی یا تعهد بیرونی ندارد.

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

• DOE Earned Value Management — FACT: EVM scope، schedule و cost/technical accomplishment را یکپارچه می‌کند، current performance را objectiveتر می‌سنجد و برای future performance از trend استفاده می‌کند.
• DOE EVMS Implementation Guidance — FACT: approved baseline، variance/trend analysis و baseline stability در project-performance analysis دیده می‌شوند.
• MAKNOW inference/design: planned-weight point غیرپولی، typed hold stateها، alertها و workflow baseline revision authority داخلی‌اند.

Freshness در 2026-09-13 روی صفحات جاری DOE دوباره بررسی شد. بازبینی بعدی حداکثر تا 2027-01-15 یا زودتر در صورت تغییر material guidance انجام شود. این درس ادعای compliance رسمی EIA-748/DOE EVMS ندارد.