Azimjon Abdurasulov

PM 3: Baholash va rejalashtirish — PERT, Monte Carlo, WBS, critical path, prioritet

📋 IT Project Management

PM 3: Baholash va rejalashtirish — PERT, Monte Carlo, WBS, critical path, prioritet

Holat: 2026-yil sentabr. Dasturiy ta'minotda "qachon tayyor bo'ladi?" degan savol eng ko'p beriladigan va eng ko'p xato javob olinadigan savoldir. Ushbu darsda dasturchi va PM baholashdagi noaniqlikni qanday hisobga olishi, bitta qat'iy raqam o'rniga ehtimolliklar bilan ishlash (PERT, Monte Carlo), vazifalarni qismlarga ajratish (WBS) va bog'liqliklar zanjirida eng muhim yo'lni topish (CPM) amaliy hisob-kitoblar bilan ko'rsatiladi.

Mundarija

  1. Noaniqlik konusi (Cone of Uncertainty)
  2. Story Points va Planning Poker
  3. PERT: Uch nuqtali baholash va dispersiya
  4. Velocity va Goodhart qonuni
  5. Monte Carlo simulyatsiyasi: ehtimollik bilan rejalashtirish
  6. #NoEstimates harakati: qachon baholash kerak emas
  7. WBS (Work Breakdown Structure): 100% qoidasi
  8. Bog'liqliklar va Critical Path Method (CPM)
  9. Gantt, Milestone va Now/Next/Later Roadmap
  10. Prioritizatsiya: RICE, WSJF, MoSCoW va Kano
  11. Xulosa
  12. Manbalar

1. Noaniqlik konusi (Cone of Uncertainty) {#noaniqlik}

Loyiha boshida qilingan baholash hech qachon aniq bo'lmaydi. Bu hodisa muhandislikda Cone of Uncertainty (Noaniqlik konusi) deb ataladi.

Barry Boehm 1981-yilda dasturiy ta'minot xarajatlarini tahlil qilib, loyihaning dastlabki bosqichidagi xatolik ko'lami 4 baravargacha (0.25x dan 4.0x gacha) farq qilishi mumkinligini ko'rsatgan ("funnel curve"). Keyinchalik Steve McConnell bu tushunchani "Cone of Uncertainty" nomi bilan ommalashtirdi (Wikipedia).

Dastlabki g'oya (Concept)       : 0.25x <------------ [ 4x farq ] ------------> 4.0x
Talablar tasdiqlangach (BRD/TZ) : 0.5x  <------- [ 2x farq ] -------> 2.0x
Dizayn va arxitekturadan so'ng  : 0.67x <--- [ 1.5x ] ---> 1.5x
Tizim integratsiyasi paytida    : 0.8x  <- [ 1.25x ] -> 1.25x
Reliz oldidan                   : 1.0x (Aniq)

Muhim saboq: loyiha boshida buyurtmachi yoki rahbariyat "aniq muddat va soatni ayt" desa, bitta qat'iy raqam berish yolg'on hisoblanadi. Noaniqlik faqat vaqt o'tishi va ish bajarilib bilim to'planishi orqali torayadi.

2. Story Points va Planning Poker {#story-points}

Agile jamoalarda soatlar o'rniga nisbiy kattalik — Story Points ishlatiladi. Nega?

  • Inson miyasi mutlaq vaqtni (soat, kun) chamalashda ojiz, lekin nisbiy taqqoslashda (A vazifa B vazifadan 2 baravar qiyinroq) ancha kuchli.
  • Turli tajribadagi dasturchilar (Junior va Senior) bir xil vazifani turlicha soatda bajaradi, lekin vazifaning murakkabligi va xatari ikkalasi uchun ham bir xil.

Planning Poker

Mike Cohn va Mountain Goat Software tomonidan ommalashtirilgan ushbu usulda Fibonachchi qatori (yoki o'zgartirilgan varianti: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100) kartalaridan foydalaniladi (Mountain Goat Software):

  1. Product Owner talabni (User Story) tushuntiradi.
  2. Dasturchilar savol berib, noaniqliklarni aniqlashtiradi.
  3. Hamma bir vaqtda o'z kartasini ochadi (bu "anchoring" effekti — birinchi odamning fikriga qolganlar ergashib ketishini oldini oladi).
  4. Eng kichik va eng katta baho bergan dasturchilar o'z sabablarini aytib beradi.
  5. Qayta ovoz beriladi va konsensusga kelinadi.

Scrum Guide (2020) qoidasi: Ish hajmini faqat uni bajaruvchi insonlar — Developers baholaydi. PM yoki PO ularga o'z bahosini majburlay olmaydi. T-shirt sizing (XS, S, M, L, XL) esa dastlabki xomaki saralashda norasmiy vosita sifatida qo'llaniladi.

3. PERT: Uch nuqtali baholash va dispersiya {#pert}

Agar vazifani soat yoki kunda hisoblash shart bo'lsa (masalan, fixed-price shartnomada yoki muhim sanaga bog'liq bo'lsa), bitta raqam o'rniga PERT (Program Evaluation and Review Technique) uch nuqtali baholashidan foydalaniladi (Wikipedia):

  • $a$ — optimistik baho (hamma narsa ideal ketsa);
  • $m$ — eng ehtimolli baho (most likely — odatdagi holat);
  • $b$ — pessimistik baho (kutilmagan to'siqlar, muammolar chiqsa).

Kutilgan qiymat ($E$) va standart og'ish ($SD$): $$E = \frac{a + 4m + b}{6}, \quad SD = \frac{b - a}{6}$$

Quyidagi Python skripti orqali 5 ta vazifadan iborat modulni hisoblaymiz:

import math

# (vazifa, a = optimistic, m = most likely, b = pessimistic) — ish kunlarida
tasks = [
    ("Auth API", 3, 5, 10),
    ("Login ekrani (iOS)", 2, 3, 6),
    ("To'lov integratsiyasi", 5, 8, 15),
    ("Push notification", 1, 2, 4),
    ("QA va bug fix", 4, 6, 12),
]

total_e = total_var = 0.0
for name, a, m, b in tasks:
    e = (a + 4 * m + b) / 6          # PERT kutilgan qiymat
    sd = (b - a) / 6                 # standart og'ish
    total_e += e
    total_var += sd ** 2             # mustaqil vazifalarda dispersiyalar qo'shiladi
    print(f"{name:<23} E = {e:5.2f} kun   SD = {sd:4.2f}")

total_sd = math.sqrt(total_var)
most_likely_sum = sum(m for _, _, m, _ in tasks)
print(f"\n'Most likely' yig'indisi: {most_likely_sum} kun")
print(f"PERT bo'yicha jami E:     {total_e:.1f} kun (SD = {total_sd:.2f})")
print(f"~68% oraliq: {total_e - total_sd:.1f} - {total_e + total_sd:.1f} kun")
print(f"~95% oraliq: {total_e - 2 * total_sd:.1f} - {total_e + 2 * total_sd:.1f} kun")

Skript natijasi va saboqlari:

  1. Dasturchilarning "odatiy" taxminlari yig'indisi (most_likely_sum) 24 kun chiqdi.
  2. PERT bo'yicha kutilgan o'rtacha muddat esa 26.3 kun (SD = 2.57). Chunki xatarlar ehtimoli muddatni o'ng tomonga (kechikish tomonga) tortadi.
  3. ~68% ehtimollik bilan loyiha 23.8 - 28.9 kun ichida tugaydi.
  4. ~95% ishonch bilan muddat 21.2 - 31.5 kun oraliqda bo'ladi. Buyurtmachiga "24 kunda bitiramiz" deyish — o'z-o'zini aldashdir.

4. Velocity va Goodhart qonuni {#velocity}

Velocity — jamoaning bitta sprintda tugatgan (Definition of Done shartiga to'liq javob bergan) Story Point'lar yig'indisi ([Wikipedia](https://en.wikipedia.org/wiki/Velocity_(software_development))).

Keng tarqalgan xatolar:

  • Jamoalarni Velocity bo'yicha solishtirish: A jamoaning 40 point'i B jamoaning 20 point'idan ko'proq ish bajarganini bildirmaydi. Har bir jamoaning o'lchov shkalasi xususiy.
  • Velocity'ni KPI qilish: Merilin Stretton va Charlz Gudxart ifodalagan qonun: "O'lchov ko'rsatkichi nishonga aylansa, u yaxshi o'lchov bo'lishdan to'xtaydi" (Goodhart's Law). Agar rahbariyat "keyingi chorakda velocity 20% oshishi kerak" desa, dasturchilar shunchaki oldin 3 point bergan vazifasiga 5 point bera boshlaydi (Point Inflation). Haqiqiy ish esa o'zgarmaydi.

5. Monte Carlo simulyatsiyasi: ehtimollik bilan rejalashtirish {#monte-carlo}

Troy Magennis (Focused Objective) dasturiy ta'minotda Monte Carlo simulyatsiyasini ommalashtirdi (Focused Objective).

O'tmishdagi haqiqiy ma'lumotlar (har haftada nechta vazifa bitgani — throughput) asosida minglab ehtimoliy kelajak ssenariylari kompyuterda hisoblanadi:

import math
import random
import statistics

random.seed(42)  # natija har safar bir xil chiqishi uchun

history = [3, 7, 5, 9, 2, 6, 8, 4, 5, 6]  # oxirgi 10 haftada tugagan item'lar
backlog = 50                              # qolgan item'lar
trials = 10_000


def weeks_to_finish() -> int:
    done = weeks = 0
    while done < backlog:
        done += random.choice(history)  # o'tmishdan tasodifiy bitta hafta
        weeks += 1
    return weeks


finish = sorted(weeks_to_finish() for _ in range(trials))
avg = statistics.fmean(history)
naive = math.ceil(backlog / avg)
print(f"O'rtacha throughput {avg:.1f} item/hafta -> 'o'rtacha' reja: {naive} hafta")
chance = sum(w <= naive for w in finish) / trials
print(f"{naive} haftada tugash ehtimoli: {chance:.0%}")
for p in (50, 85, 95):
    print(f"{p}% ehtimol bilan: {finish[p * trials // 100 - 1]} hafta yoki tezroq")

Natija:

  • O'rtacha throughput haftasiga 5.5 item bo'lgani uchun oddiy hisob-kitob 50 / 5.5 = 10 hafta ko'rsatadi.
  • Lekin Monte Carlo 10,000 ta simulyatsiya natijasida ko'rsatadiki, loyihaning 10 haftada tugash ehtimoli bor-yo'g'i 80%!
  • 50% ehtimol bilan: 9 hafta yoki tezroq;
  • 85% ehtimol bilan: 11 hafta yoki tezroq;
  • 95% ehtimol bilan: 12 hafta yoki tezroq.

Bu ma'lumot biznes bilan gaplashishda kuchli qurol: "Biz 85% ishonch bilan 11 haftada, 95% kafolat bilan 12 haftada yetkazib beramiz".

6. #NoEstimates harakati: qachon baholash kerak emas {#noestimates}

Ron Jeffries, Chet Hendrickson, Woody Zuill va Neil Killick tomonidan ilgari surilgan #NoEstimates harakati baholash uchun sarflanadigan soatlab vaqt ko'pincha bekorga ketishini ta'kidlaydi (Ron Jeffries):

  • Baholashlar ko'pincha menejment tomonidan dasturchilarni jazolash quroliga aylanadi ("soat 18:00 gacha bitiraman deganding-ku").
  • Agar vazifalar kichik, taxminan teng bo'laklarga (masalan 1–2 kunda bitadigan) bo'linsa, ularni ballarda baholash shart emas — shunchaki sonini sanash (Throughput) orqali Monte Carlo bilan reja qilsa bo'ladi.
  • Biroq Ron Jeffries tan oladi: investitsiya jalb qilish yoki qat'iy byudjet ajratish bosqichida baholashdan butunlay qochib bo'lmaydi.

7. WBS (Work Breakdown Structure): 100% qoidasi {#wbs}

WBS — loyiha doirasidagi barcha ishlarni ierarxik daraxt shaklida bo'laklash (Wikipedia).

Tarixi: AQSh Mudofaa vazirligi MIL-STD-881 standarti (1968-yil, F reviziyasi 2022-yil 13-may).

Ikkita asosiy qoida:

  1. 100% qoidasi (PMI Practice Standard for WBS, 2-nashr, 2006): Bolalar elementlarining yig'indisi ota elementning 100% ishini va byudjetini tashkil qilishi shart. Undan na kam, na ko'p bo'lmasligi kerak.
  2. 8/80 qoidasi (norasmiy evristika): Eng quyi darajadagi ish paketi (Work Package) 8 soatdan kam bo'lmasligi (mikromenejment bo'lmasligi uchun) va 80 soatdan (2 haftadan) oshmasligi kerak (boshqaruv yo'qolmasligi uchun).

WBS tekshiruvchi skript:

# WBS: kod -> (nomi, baholangan soat). Ota elementning soati = rejadagi umumiy baho.
wbs = {
    "1": ("Mobil ilova v1.0", 560),
    "1.1": ("Loyiha boshqaruvi", 48),
    "1.2": ("Discovery va TZ", 40),
    "1.2.1": ("Stakeholder intervyulari", 16),
    "1.2.2": ("TZ yozish", 16),
    "1.2.3": ("TZ review va imzo", 8),
    "1.3": ("UX/UI dizayn (Figma)", 60),
    "1.3.1": ("Wireframe'lar", 20),
    "1.3.2": ("UI kit va ekranlar", 40),
    "1.4": ("iOS ilova", 180),
    "1.4.1": ("Auth moduli", 40),
    "1.4.2": ("Katalog va savat", 96),
    "1.4.3": ("Push notification", 24),
    "1.4.4": ("Offline kesh", 20),
    "1.5": ("Backend API", 120),
    "1.5.1": ("Auth API", 32),
    "1.5.2": ("Katalog API", 48),
    "1.5.3": ("Buyurtma API", 32),
    "1.6": ("QA va reliz", 112),
    "1.6.1": ("Test va bug fix", 92),
    "1.6.2": ("App Store'ga yuborish", 16),
    "1.6.3": ("Release notes", 4),
}


def children(code: str) -> list[str]:
    depth = code.count(".") + 1
    return [c for c in wbs if c.startswith(code + ".") and c.count(".") == depth]


problems = 0
for code, (name, hours) in wbs.items():
    kids = children(code)
    if kids:
        total = sum(wbs[k][1] for k in kids)
        if total != hours:
            problems += 1
            print(f"100% qoida: {code} {name} - reja {hours} soat, bo'laklar {total} soat")
    elif not 8 <= hours <= 80:
        problems += 1
        advice = "yana bo'ling" if hours > 80 else "qo'shni paket bilan birlashtiring"
        print(f"8/80: {code} {name} - {hours} soat, {advice}")
print(f"Jami {problems} ta muammo")

Skript WBS'dagi 4 ta muammoni aniqladi:

  1. 1.4.2 Katalog va savat — 96 soat (80 soatdan ko'p, kichikroq vazifalarga bo'linishi kerak).
  2. 1.5 Backend API — umumiy reja 120 soat, lekin bolalari yig'indisi 112 soat (100% qoidasi buzilgan).
  3. 1.6.1 Test va bug fix — 92 soat (yana bo'linishi kerak).
  4. 1.6.3 Release notes — 4 soat (8 soatdan kam, qo'shni paket bilan birlashtirilishi tavsiya etiladi).

8. Bog'liqliklar va Critical Path Method (CPM) {#critical-path}

Vazifalar orasidagi bog'liqlik turlari:

  • FS (Finish-to-Start): B vazifa boshlanishi uchun A tugashi kerak (eng keng tarqalgani).
  • SS (Start-to-Start): A boshlanishi bilan B ham boshlanishi mumkin.
  • FF (Finish-to-Finish): A tugaganda B ham tugashi kerak.
  • SF (Start-to-Finish): Kamdan-kam uchraydi (A boshlanganda B tugaydi).

CPM usuli 1957-yilda Morgan Walker (DuPont) va James Kelley (Remington Rand) tomonidan kashf qilingan (Wikipedia).

Kritik yo'l (Critical Path) — loyihaning boshidan oxirigacha bo'lgan eng uzun zanjir. Bu zanjirdagi har qanday kechikish butun loyihaning relizini kechiktiradi (uning zaxirasi — float nolga teng).

# kod: (nomi, davomiylik (ish kuni), oldingi ishlar) — tartib topologik
tasks = {
    "A": ("Talablar va TZ yangilash", 3, []),
    "B": ("UI dizayn (Figma)", 4, ["A"]),
    "C": ("Backend: obuna API", 6, ["A"]),
    "D": ("iOS: StoreKit ekranlari", 5, ["B"]),
    "E": ("iOS + backend integratsiya", 3, ["C", "D"]),
    "F": ("Admin: obuna hisobotlari", 2, ["C"]),
    "G": ("QA va regression", 4, ["E", "F"]),
    "H": ("App Store'ga yuborish", 2, ["G"]),
}

# Forward pass: eng erta boshlanish (ES) va tugash (EF)
es, ef = {}, {}
for code, (_, dur, preds) in tasks.items():
    es[code] = max((ef[p] for p in preds), default=0)
    ef[code] = es[code] + dur
end = max(ef.values())

# Backward pass: eng kech boshlanish (LS) va tugash (LF)
succ = {c: [s for s, (_, _, ps) in tasks.items() if c in ps] for c in tasks}
ls, lf = {}, {}
for code in reversed(list(tasks)):
    lf[code] = min((ls[s] for s in succ[code]), default=end)
    ls[code] = lf[code] - tasks[code][1]

print(f"{'Ish':<30}{'ES':>3}{'EF':>4}{'LS':>4}{'LF':>4}{'Float':>6}")
for code, (name, dur, _) in tasks.items():
    print(f"{code} {name:<28}{es[code]:>3}{ef[code]:>4}{ls[code]:>4}{lf[code]:>4}"
          f"{ls[code] - es[code]:>6}")

critical = [c for c in tasks if ls[c] == es[c]]
print(f"\nCritical path: {' -> '.join(critical)} = {end} ish kuni\n")
for code, (_, dur, _) in tasks.items():  # oddiy matnli Gantt
    bar = " " * es[code] + "#" * dur
    print(f"{code} |{bar:<{end}}|")

Natijadan ko'rinadiki:

  • Kritik yo'l: A -> B -> D -> E -> G -> H = 21 ish kuni.
  • Vazifa C (Backend) ning zaxirasi (float) 3 kun bor: u 3 kunga kechiksa ham umumiy reliz kechikmaydi.
  • Vazifa F (Admin hisobotlari) ning zaxirasi 4 kun.
  • Eslatma: App Store tekshiruvi (H qadami) rejalashtirish taxmini hisoblanadi; Apple tekshiruv vaqti kafolatlanmagan.
  • Eliyahu Goldratt (1997) ishlab chiqqan CCPM (Critical Chain Project Management) usulida har bir vazifa ichiga yashiringan zaxiralar olib tashlanib, umumiy loyiha oxiriga Project Buffer va kritik bo'lmagan shoxlar tugashiga Feeding Buffer qo'yiladi.

9. Gantt, Milestone va Now/Next/Later Roadmap {#roadmap}

  • Gantt diagrammasi: Karol Adamiecki (1896) va Henry Gantt (1910–1915) tomonidan ishlab chiqilgan vaqt bo'yicha chiziqli grafik (Wikipedia).
  • Milestone (Bosqich belgisi): Davomiyligi 0 bo'lgan muhim voqea (masalan, "Beta build TestFlight'ga chiqdi", "Shartnoma imzolandi").
  • Burndown vs Burnup chart: Burndown qolgan ishni ko'rsatadi, lekin scope kengaysa chalg'itishi mumkin. Burnup qilingan ish va umumiy scope chiziqlarini alohida ko'rsatib, scope kengayishini (scope creep) fosh qiladi (Wikipedia).

Now / Next / Later Roadmap

Janna Bastow va Simon Cast (ProdPad, 2012) tomonidan ishlab chiqilgan ushbu zamonaviy roadmap qat'iy sanalarga emas, balki aniqlik darajasiga tayanadi (ProdPad):

+-----------------------+-----------------------+-----------------------+
|         NOW           |         NEXT          |        LATER          |
| (Aniq, jamoa ishlaydi)| (Tadqiqot, dizayn)    | (G'oyalar, istiqbol)  |
+-----------------------+-----------------------+-----------------------+
| • Apple Pay checkout  | • Dark mode interfeys | • Siri Shortcuts      |
| • Crash reporting tuz.| • Obuna analitikasi   | • iPad moslashuvi     |
| • Push notification   | • Push AB-testing     | • WatchOS companion   |
+-----------------------+-----------------------+-----------------------+

10. Prioritizatsiya: RICE, WSJF, MoSCoW va Kano {#prioritet}

Mahsulotdagi 100 ta g'oyadan qaysi birini birinchi qilish kerak?

  1. RICE (Intercom): $$\text{RICE} = \frac{\text{Reach} \times \text{Impact} \times \text{Confidence}}{\text{Effort}}$$
  2. Reach: chorakda qancha foydalanuvchiga tegadi;
  3. Impact: ta'siri (3 = ulkan, 2 = yuqori, 1 = o'rta, 0.5 = past, 0.25 = minimal);
  4. Confidence: ishonch (100% = yuqori ma'lumotlar bor, 80% = o'rta, 50% = taxmin);
  5. Effort: sarflanadigan odam-oy (Intercom).
  6. WSJF (Weighted Shortest Job First — SAFe): $$\text{WSJF} = \frac{\text{Cost of Delay (CoD)}}{\text{Job Size}}, \quad \text{CoD} = \text{User Value} + \text{Time Criticality} + \text{Risk Reduction}$$ (Izoh: SAFe rasmiy sahifasi login talab qiladi, formula ikkilamchi manbalardan tasdiqlangan).
  7. MoSCoW (Dai Clegg 1994, DSDM 2002):
  8. Must have: Bu bo'lmasa reliz bo'lmaydi (rejaning ko'pi bilan 60% qismini tashkil qilishi shart);
  9. Should have: Juda muhim, lekin vaqtincha aylanib o'tish yo'li bor;
  10. Could have: Qulaylik, vaqt qolsagina qilinadi (~20% zaxira bufer);
  11. Won't have (this time): Bu relizga kirmaydi (Agile Business Consortium).
  12. Kano modeli (Noriaki Kano, 1980-yillar): Must-be (asosiy gigiyena), One-dimensional (unumdorlik), Attractive (jozibador kutilmagan qulaylik), Indifferent (befarq), Reverse (teskari) (Wikipedia).

Quyidagi skript RICE, WSJF va MoSCoW mezonlarini solishtiradi:

# nomi: (reach/chorak, impact, confidence, effort (odam-oy), BV, TC, RR, job size, MoSCoW)
features = {
    "Onboarding qayta dizayni": (5000, 1, 0.8, 1.5, 8, 8, 2, 3, "Must"),
    "Tezkor checkout": (2000, 2, 0.8, 2.0, 8, 5, 3, 5, "Must"),
    "Dark mode": (3000, 0.5, 1.0, 1.0, 3, 1, 1, 2, "Could"),
    "Referal dasturi": (1200, 2, 0.5, 2.0, 5, 3, 5, 5, "Should"),
    "Offline rejim": (800, 1, 0.5, 3.0, 5, 2, 8, 8, "Won't"),
}

rice = {n: r * i * c / e for n, (r, i, c, e, *_) in features.items()}
wsjf = {n: (bv + tc + rr) / size for n, (*_, bv, tc, rr, size, _) in features.items()}

print("RICE reytingi:")
for name in sorted(rice, key=rice.get, reverse=True):
    print(f"  {name:<25} {rice[name]:7.0f}")
print("WSJF reytingi:")
for name in sorted(wsjf, key=wsjf.get, reverse=True):
    print(f"  {name:<25} {wsjf[name]:7.2f}")

# MoSCoW: shu relizga kiradigan ishning (Won't'dan tashqari) effort ulushlari
effort = {}
for _, (_, _, _, e, *_, group) in features.items():
    effort[group] = effort.get(group, 0) + e
planned = sum(v for g, v in effort.items() if g != "Won't")
print(f"Must ulushi: {effort['Must'] / planned:.0%} (tavsiya: 60% dan oshmasin)")
print(f"Could ulushi: {effort['Could'] / planned:.0%} (tavsiya: ~20% zaxira)")

Natijalar:

  • RICE reytingi: Onboarding qayta dizayni (2667), Tezkor checkout (1600), Dark mode (1500), Referal dasturi (600), Offline rejim (133).
  • WSJF reytingi: Onboarding (6.00), Tezkor checkout (3.20), Referal (2.60), Dark mode (2.50), Offline (1.88).
  • E'tibor bering: RICE Dark mode'ni 3-o'ringa qo'ydi (chunki ko'p kishiga tegadi va arzon), WSJF esa Referal dasturini 3-o'ringa qo'ydi (chunki vaqt kritikligi va xatar kamaytirish yuqori). Ramkalar bir-birini to'ldiradi.
  • MoSCoW taqsimotida Must ulushi 54% (tavsiya etilgan 60% dan past, xavfsiz), Could ulushi esa 15% buferni tashkil etmoqda.

11. Xulosa {#xulosa}

  • Noaniqlik konusi sababli loyiha boshida bitta qat'iy muddat berish muhandislik xatosidir.
  • PERT kutilmagan xatarlar sababli "most likely" yig'indisidan ko'ra realroq ehtimollik oraliqlarini beradi.
  • Monte Carlo simulyatsiyasi o'tmishdagi throughput asosida muddatlarni aniq ehtimollik foizlari (85%, 95%) bilan rejalashtirish imkonini beradi.
  • WBS'da 100% qoidasiga rioya qiling: bolalar yig'indisi ota elementga teng bo'lishi shart.
  • CPM tahlilida kritik yo'ldagi vazifalarga asosiy e'tibor qaratiladi; zaxirali (float) vazifalar kechikishi umumiy relizni to'xtatmaydi.

Manbalar {#manbalar}

  1. Cone of Uncertainty — Wikipedia
  2. Planning Poker — Mountain Goat Software
  3. Three-point estimation / PERT — Wikipedia
  4. [Velocity in Software Development — Wikipedia](https://en.wikipedia.org/wiki/Velocity_(software_development))
  5. Focused Objective — Troy Magennis
  6. The #NoEstimates Movement — Ron Jeffries
  7. Work Breakdown Structure — Wikipedia
  8. Critical Path Method — Wikipedia
  9. Now-Next-Later Roadmap — ProdPad
  10. RICE Simple Prioritization for Product Managers — Intercom
  11. MoSCoW Method — Agile Business Consortium
  12. Kano Model — Wikipedia

Markdown manba

iOS Lessons