# PM 6: Risk, stakeholder va nazorat — registr, RACI, status, EVM, shartnomalar

> **Holat:** 2026-yil sentabr. Dasturiy ta'minot loyihalarida eng qimmat xatolar texnik qiyinchiliklardan emas, balki aniqlanmagan risklar, noaniq mas'uliyat taqsimoti va yashirilgan kechikishlardan kelib chiqadi. Ushbu darsda risklarni boshqarish (ISO 31000, Risk Register, RAID log), jamoa rollarini muvofiqlashtirish (RACI va uning zamonaviy variantlari), stakeholder'lar bilan ishlash, loyiha iqtisodini baholash (EVM) va shartnoma modellari tahlil qilinadi.

## Mundarija

1. [Risk tushunchasi va ISO 31000 tamoyillari](#risk)
2. [Risk registri va ehtimollik/ta'sir matritsasi](#risk-register)
3. [RAID log: muammolar va bog'liqliklar jurnali](#raid)
4. [Stakeholder tahlili va quvvat/qiziqish matritsasi](#stakeholder)
5. [RACI matritsasi: rollar va javobgarlik taqsimoti](#raci)
6. [Kommunikatsiya rejasi va RAG status hisoboti](#status)
7. [Uchrashuvlar tizimi: vaqt va maqsad chegarasi](#meetings)
8. [O'zgarishlarni boshqarish va Scope Creep](#change-control)
9. [EVM (Earned Value Management): loyiha iqtisodi](#evm)
10. [Shartnomalar: Fixed Price, T&M va Dedicated Team](#shartnoma)
11. [Muddat kechikishi va Brooks qonuni](#deadline)
12. [Texnik qarz (Technical Debt) va uni himoya qilish](#tech-debt)
13. [Xulosa](#xulosa)
14. [Manbalar](#manbalar)

---

## 1. Risk tushunchasi va ISO 31000 tamoyillari {#risk}

Xalqaro **ISO 31000** standartiga ko'ra, risk — bu **"maqsadlarga noaniqlikning ta'siri"** (*effect of uncertainty on objectives*). Standart ilk bor 2009-yilda qabul qilingan va 2018-yilda qayta ko'rib chiqilgan (2023-yilda o'z kuchida tasdiqlangan) ([ISO 31000](https://en.wikipedia.org/wiki/ISO_31000)).

ISO 31000 risklarga javob berishning 7 ta yo'lini belgilaydi:
1. **Qochish (avoid):** Risk keltirib chiqaradigan faoliyatni boshlamaslik yoki to'xtatish.
2. **Qabul qilish yoki oshirish:** Yangi imkoniyatni qo'lga kiritish maqsadida riskni qabul qilish.
3. **Manbani yo'qotish (remove source):** Xavf manbasini ildizi bilan olib tashlash.
4. **Ehtimollikni o'zgartirish (change likelihood):** Xavf ro'y berish imkoniyatini pasaytirish.
5. **Oqibatlarni o'zgartirish (change consequences):** Xavf yuz berganda yetkaziladigan zararni minimallashtirish.
6. **Ulashish (share):** Riskni sug'urta yoki autsorsing shartnomasi orqali uchinchi tomonga taqsimlash.
7. **Ongli qaror bilan saqlab qolish (retain by informed decision):** Riskni bilgan holda qoldirish va monitoring qilish.

Amaliy dasturiy injiniringda ko'pincha soddalashtirilgan 4 strategiya ishlatiladi: **Avoid** (qochish), **Mitigate** (yumshatish), **Transfer** (o'tkazish) va **Accept** (qabul qilish).

---

## 2. Risk registri va ehtimollik/ta'sir matritsasi {#risk-register}

**Risk registri (Risk Register)** — loyiha davomida aniqlangan barcha potentsial xavflar, ularning bahosi, egasi va bartaraf etish rejasini jamlagan jonli hujjatdir.

Xavflar ehtimollik ($P \in [1..5]$) va ta'sir ($I \in [1..5]$) ko'paytmasi bo'yicha baholanadi:

$$\text{Score} = P \times I$$

Quyidagi Python skripti mobil ilova loyihasidagi risklarni baholash va jamoa kelishgan chegara asosida rangli (RAG) tasniflashni hisoblaydi:

```python
# (ID, tavsif, ehtimollik 1-5, ta'sir 1-5)
risks = [
    ("R1", "App Review rad etadi: demo akkaunt berilmagan", 3, 4),
    ("R2", "To'lov SDK hujjatlari eskirgan", 4, 3),
    ("R3", "Yagona iOS dasturchi loyihadan ketadi", 2, 5),
    ("R4", "Backend API bir sprint kechikadi", 4, 4),
    ("R5", "Yangi SDK privacy manifest'siz keladi", 2, 3),
]


def rag(score: int) -> str:
    # Chegaralar — jamoa bilan oldindan kelishilgan misol, xalqaro standart emas
    if score >= 15:
        return "RED   (darhol eskalatsiya)"
    if score >= 7:
        return "AMBER (javob rejasi + owner)"
    return "GREEN (kuzatish)"


for rid, desc, p, i in sorted(risks, key=lambda r: r[2] * r[3], reverse=True):
    print(f"{rid}  {p}x{i} = {p * i:>2}  {rag(p * i):<28}  {desc}")
```

Skript natijasi:
- **R4 (16 ball, RED):** Backend API bir sprint kechikishi — darhol loyiha homiysiga eskalatsiya qilinishi va mock API yaratilishi shart.
- **R1, R2 (12 ball, AMBER) va R3 (10 ball, AMBER):** Demo akkaunt tayyorlash, to'lov integratsiyasini oldindan tekshirish va bilim almashish (knowledge sharing) choralari ko'riladi.
- **R5 (6 ball, GREEN):** Yangi SDK privacy manifest'i ([/ios-lessons/devops-cicd#privacy-manifest](/ios-lessons/devops-cicd#privacy-manifest)) kuzatuvda saqlanadi.

---

## 3. RAID log: muammolar va bog'liqliklar jurnali {#raid}

Risk registrining kengaytmasi bo'lgan **RAID log** to'rtta muhim toifani yagona jadvalda ushlab turadi:

| Toifa | Inglizcha | Ta'rifi | Misol |
| :--- | :--- | :--- | :--- |
| **R** | Risks | Kelajakda yuz berishi mumkin bo'lgan noaniqlik | App Store Connect tekshiruv vaqti uzayishi |
| **A** | Assumptions | To'g'ri deb taxmin qilingan shartlar | Backend har sekundiga 2,000 RPS'ni ko'tara oladi |
| **I** | Issues | Hozir yuz bergan va yechim talab qilayotgan muammo | SMS shlyuz serveri 500 xatosini bermoqda |
| **D** | Dependencies | Boshqa guruh yoki tizimga bog'liqlik | Dizayn jamoasi UI Kit komponentlarini yakunlashi |

---

## 4. Stakeholder tahlili va quvvat/qiziqish matritsasi {#stakeholder}

**Stakeholder** — loyiha natijasidan manfaatdor yoki uning borishiga ta'sir o'tkaza oladigan har qanday tomon (mijoz, homiy, foydalanuvchi, ishlab chiquvchilar).

Klassik $2 \times 2$ Power/Interest matritsasi muloqot strategiyasini belgilaydi ([Stakeholder Analysis](https://en.wikipedia.org/wiki/Stakeholder_analysis)):

```text
Quvvat (Power)
  ^
  |  [Keep Satisfied]           |  [Manage Closely]
  |  Moliya bo'limi, Yuristlar  |  Mahsulot egasi (PO), Bosh homiy
  |  (Kam qiziqish, Katta kuch) |  (Katta qiziqish, Katta kuch)
  +-----------------------------+-----------------------------
  |  [Monitor]                  |  [Keep Informed]
  |  Qo'shni bo'limlar          |  Foydalanuvchilar, QA, Dasturchilar
  |  (Kam qiziqish, Kam kuch)   |  (Katta qiziqish, Kam kuch)
  +----------------------------------------------------------> Qiziqish (Interest)
```

---

## 5. RACI matritsasi: rollar va javobgarlik taqsimoti {#raci}

Vazifalar taqsimotida noaniqlikni yo'qotish uchun **RACI** matritsasidan foydalaniladi ([Responsibility Assignment Matrix](https://en.wikipedia.org/wiki/Responsibility_assignment_matrix)):
- **R (Responsible):** Ishni bevosita bajaruvchi mutaxassis.
- **A (Accountable):** Natija uchun yakuniy javobgar yagona shaxs (**qoida: har bir qatorda faqat bitta A bo'lishi shart!**).
- **C (Consulted):** Qaror qabul qilishda fikri olinadigan ekspert (ikki tomonlama muloqot).
- **I (Informed):** Ish natijasidan xabardor qilib turiladigan shaxs (bir tomonlama axborot).

Mobil loyiha uchun namunaviy RACI matritsasi:

| Loyiha faoliyati | Mahsulot egasi (PO) | PM | iOS dev | Android dev | Backend | QA | Dizayner | Mijoz |
| :--- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| Foydalanuvchi talablarini yozish (PRD) | **A** | C | I | I | C | C | C | I |
| UI/UX dizayn tizimi va maketlar | C | I | C | C | I | I | **A** | I |
| Backend API arxitekturasi va DB | I | I | C | C | **A** | I | I | I |
| iOS ilovani ishlab chiqish | I | I | **A** | I | C | C | C | I |
| Relizga chiqarish qarori (Go/No-Go) | C | **A** | C | C | C | C | I | I |
| App Store & Google Play relizi | I | **A** | R | R | I | I | I | I |

Sanoatda RACI'ning bir nechta variantlari mavjud: **DACI** (Driver, Approver, Contributor, Informed), **RASCI** (Support qo'shilgan), **CAIRO** (Omitted — jalb qilinmaydiganlar aniq belgilangan), hamda **RACI-VSL** (Verifier va Sign-off qo'shilgan).

---

## 6. Kommunikatsiya rejasi va RAG status hisoboti {#status}

Loyiha homiylari va boshqaruvchilarga status berishda **RAG (Red / Amber / Green)** tizimi qo'llaniladi. PRINCE2 metodologiyasidagi *"tolerances"* va *"management by exception"* tamoyiliga binoan, qaysi ko'rsatkich Amber yoki Red bo'lishi loyiha boshida kelishib olinadi ([PRINCE2](https://en.wikipedia.org/wiki/PRINCE2)).

Wellingtone (2026) hisobotiga ko'ra, PM'larning **72% i har oyda kamida yarim kunini** status hisobotlari tuzishga sarflaydi ([Wellingtone](https://wellingtone.co.uk/state-of-project-management/)). Ushbu yukni kamaytirish uchun qisqa va standart shablon zarur:

```text
LOYIHA STATUS HISOBOTI (Haftalik)
Loyiha: PayMobile iOS v2.4       Sana: 2026-09-29       Holat: AMBER
PM: Azimjon                      Sprint: 14/20

1. UMUMIY HOLAT:
- Scope: GREEN | Byudjet: GREEN | Muddat: AMBER | Sifat: GREEN

2. SPRINT NATIJALARI (Bajarildi):
- StoreKit 2 obuna ekranlari va kvitansiya tekshiruvi yakunlandi.
- TestFlight internal 2.4.0 (142) yig'masi sinovga uzatildi.

3. ASOSIY TO'SIQLAR VA RISKLAR (Bloklar):
- AMBER: To'lov provayderining Webhook sinov muhiti beqaror ishlamoqda.
  Chora: Backend jamoasi 30-sentabrgacha simulyator yaratadi.

4. KEYINGI HAFTA REJASI:
- Tashqi TestFlight sinovini boshlash va App Review uchun demo hisob sozlash.
```

---

## 7. Uchrashuvlar tizimi: vaqt va maqsad chegarasi {#meetings}

Haddan tashqari ko'p samarasiz uchrashuvlar dasturchilarning chuqur ishlash (deep work) vaqtini o'g'irlaydi. Scrum'da tasdiqlangan vaqt chegaralari (timebox):

| Uchrashuv | Maqsadi | Kimlar qatnashadi | Vaqt chegarasi (2 haftalik sprint) |
| :--- | :--- | :--- | :--- |
| **Sprint Planning** | Sprint maqsadini va vazifalarni tanlash | Jamoa, PO, PM | Maksimal 4 soat (odatda 2 soat) |
| **Daily Scrum** | Kunlik rejani sinxronlash va to'siqlarni topish | Ishlab chiquvchilar, Scrum Master / PM | Qat'iy 15 daqiqa (tik turib) |
| **Sprint Review** | Bajarilgan mahsulot inkrementini ko'rsatish | Jamoa, PO, Stakeholder'lar | Maksimal 2 soat |
| **Retrospective** | Jarayon va jamoaviy muhitni yaxshilash | Butun Scrum jamoasi | Maksimal 1.5 soat |
| **Backlog Refinement** | Kelgusi vazifalarni tahlil qilish va baholash | Jamoa, PO | Sprint davomida 1-2 soat |

---

## 8. O'zgarishlarni boshqarish va Scope Creep {#change-control}

**Scope Creep** — dastlabki kelishuvda bo'lmagan yangi mayda talablarning nazoratsiz qo'shilib borishi natijasida loyiha muddati va byudjeti izdan chiqishi. Eng xavfli tuzoq — *"bu 5 daqiqalik ish-ku"* degan og'zaki iltimoslardir.

ITIL 4 (2019) doirasida o'zgarishlarni boshqarish amaliyoti **Change Enablement** deb nomlanadi ([ITIL 4](https://en.wikipedia.org/wiki/ITIL)). O'zgarishlar uch toifaga bo'linadi:
1. **Standard:** Oldindan xavfsizligi tasdiqlangan, tezkor o'zgarishlar (masalan, patch reliz chiqarish).
2. **Normal:** Tahlil, rejalashtirish va vakolatli kengash (Change Advisory Board — CAB) tasdig'ini talab qiluvchi o'zgarishlar.
3. **Emergency:** Kritik ishlab chiqarish avariyasini tuzatish uchun darhol kiritiladigan o'zgarishlar.

Har qanday yangi funksiya rasmiy **Change Request (CR)** tartibi orqali ko'rib chiqilishi shart ([/ios-lessons/pm-requirements-tz#change-request](/ios-lessons/pm-requirements-tz#change-request)).

---

## 9. EVM (Earned Value Management): loyiha iqtisodi {#evm}

**EVM (Earned Value Management)** — loyihaning rejalashtirilgan hajmi, haqiqiy sarflangan xarajati va real bajarilgan ish qiymatini yagona raqamli ko'rsatkichlarga birlashtiruvchi standart metodologiyadir ([Earned Value Management](https://en.wikipedia.org/wiki/Earned_value_management)):
- **BAC (Budget at Completion):** Loyihaning umumiy byudjeti.
- **PV (Planned Value):** Hozirgi sanagacha reja bo'yicha bajarilishi kerak bo'lgan ish qiymati.
- **EV (Earned Value):** Haqiqatda bajarilgan ishning byudjetdagi qiymati ($EV = BAC \times \% \text{bajarildi}$).
- **AC (Actual Cost):** Shu paytgacha haqiqatda sarflangan jami mablag'.
- **CV (Cost Variance):** $CV = EV - AC$ ($CV < 0$ bo'lsa xarajat oshgan).
- **CPI (Cost Performance Index):** $CPI = EV / AC$ ($CPI < 1.0$ xarajat samarasizligini bildiradi).
- **SV (Schedule Variance):** $SV = EV - PV$ ($SV < 0$ grafikdan orqada).
- **SPI (Schedule Performance Index):** $SPI = EV / PV$ ($SPI < 1.0$ kechikishni bildiradi) ([Earned Value Analysis](https://de.wikipedia.org/wiki/Earned_Value_Analysis)).
- **EAC (Estimate at Completion):** Loyiha yakunida kutilayotgan umumiy xarajat ($EAC = BAC / CPI$).

> **Agile va EVM cheklovlari:** EVM ko'proq qat'iy rejalashtirilgan an'anaviy loyihalarda yaxshi ishlaydi. Dasturiy ta'minotda scope doimiy o'zgarib tursa, EVM ko'rsatkichlari buzilishi mumkin. Shuningdek, an'anaviy EVM'da loyiha kechikib bo'lsa ham oxiriga yetganda $SV = 0$ va $SPI = 1.0$ ga aylanadi, chunki barcha ish yakunlangan hisoblanadi ([Earned Schedule](https://en.wikipedia.org/wiki/Earned_schedule)).

Quyidagi skript 10 oylik, 100,000 dollarlik loyihaning 4-oydagi EVM holatini hisoblab beradi:

```python
BAC = 100_000          # umumiy byudjet ($), 10 oyga teng taqsimlangan
months_total, month_now = 10, 4
percent_complete = 0.35  # 4-oy oxirida haqiqatda bajarilgan ish ulushi
AC = 42_000              # 4-oy oxirigacha haqiqatda sarflangan ($)

PV = BAC * month_now / months_total   # reja bo'yicha shu paytgacha bajarilishi kerak edi
EV = BAC * percent_complete           # haqiqatda bajarilgan ishning byudjetdagi qiymati
CV, CPI = EV - AC, EV / AC
SV, SPI = EV - PV, EV / PV
EAC = BAC / CPI                       # hozirgi xarajat samaradorligi davom etsa
EAC_check = AC + (BAC - EV) / CPI     # ikkinchi formula — natija bir xil

print(f"PV = {PV:,.0f}   EV = {EV:,.0f}   AC = {AC:,.0f}")
print(f"CV = {CV:,.0f}   CPI = {CPI:.2f}")
print(f"SV = {SV:,.0f}   SPI = {SPI:.3f}")
print(f"EAC = {EAC:,.0f}   (tekshiruv: {EAC_check:,.0f})")
print(f"Byudjetdan kutilayotgan oshish: {EAC - BAC:,.0f}")
print(f"Qolgan ishga yana kerak: {EAC - AC:,.0f}")
```

Skript natijalari:
- **Reja va ijro:** $PV = 40,000$, ammo $EV = 35,000$ (rejadagidan kam ish qilingan).
- **Xarajat:** $AC = 42,000$, natijada $CV = -7,000$ dollar zarar va $CPI = 0.83$.
- **Muddat:** $SV = -5,000$ va $SPI = 0.875$ (loyihaning 12.5% kechikishi).
- **Kutilma (EAC):** Agar shu sur'at saqlansa, loyiha **120,000 dollarga** aylanadi (byudjetdan **20,000 dollar** oshish) va qolgan ishni bitirish uchun yana **78,000 dollar** talab etiladi.

---

## 10. Shartnomalar: Fixed Price, T&M va Dedicated Team {#shartnoma}

Buyurtmachi va ijrochi o'rtasidagi shartnoma modeli loyihadagi risk kimning zimmasiga tushishini hal qiladi:

| Model | Qachon tanlanadi | Risk egasi | Afzalligi | Kamchiligi |
| :--- | :--- | :--- | :--- | :--- |
| **Fixed Price** | Talablar 100% aniq va o'zgarmas bo'lganda (masalan, qat'iy davlat tenderi) | Ijrochi (Dasturchilar) | Mijoz xarajatni oldindan biladi | O'zgarish kiritish qiyin; ijrochi narxga 30-50% risk zaxirasini qo'shadi |
| **Time & Materials (T&M)** | Tadqiqot, MVP yoki dinamik o'zgaruvchan loyihalarda | Buyurtmachi (Mijoz) | Moslashuvchanlik yuqori; istalgan payt yo'nalishni o'zgartirish mumkin | Yakuniy byudjet oldindan noaniq (Not-to-exceed chegarasi qo'yiladi) |
| **Dedicated Team** | Uzoq muddatli mahsulotni rivojlantirishda | Taqsimlangan | Jamoa to'liq mijoz madaniyatiga integratsiya bo'ladi | Oylik doimiy xarajat; jamoani yuklama bilan ta'minlash mijoz gardanida |

T&M shartnomalarida byudjet nazoratini yo'qotmaslik uchun ko'pincha **"Not-to-Exceed (NTE)"** sharti kiritiladi — ya'ni belgilangan limitdan ortiq xarajatlar buyurtmachi bilan alohida kelishilmasdan amalga oshirilmaydi ([Time and Materials](https://en.wikipedia.org/wiki/Time_and_materials)).

---

## 11. Muddat kechikishi va Brooks qonuni {#deadline}

Loyiha muddati xavf ostida qolganda menejerlar ko'pincha jamoaga yangi odamlarni jalb qilishni o'ylaydi. Fred Brooks o'zining mashhur *"The Mythical Man-Month"* (1975) asarida shunday degan:

> **Brooks qonuni:** *"Kechikayotgan dasturiy loyihaga ishchi kuchi qo'shish uni yanada kechiktiradi"* ([Brooks's Law](https://en.wikipedia.org/wiki/Brooks%27s_law)).

Yangi dasturchi kelganda mavjud tajribali dasturchilar ularga kod arxitekturasi va jarayonlarni tushuntirish uchun o'z vaqtlarini sarflaydilar, kommunikatsiya kanallari esa eksponentsial ravishda ortadi ($n(n-1)/2$). Brooksning o'zi keyinchalik bu qoidani *"jiddiy ortiqcha soddalashtirish"* deb atagan bo'lsa-da, qisqa muddatli krizisda odam qo'shish kamdan-kam samara beradi.

Kechikishni to'g'rilashning uchta real usuli bor:
1. **Scope kamaytirish:** Eng kam prioritetli funksiyalarni keyingi relizga qoldirish.
2. **Muddatni surish:** Yangi sanani ochiq muhokama qilish.
3. **Fast-tracking va Crashing:** Bir-biriga bog'liq bo'lmagan ishlarni parallel qilish (Fast-tracking) yoki qo'shimcha resurslarni to'g'ri nuqtaga yo'naltirish (Crashing).

Quyidagi skript kechikish holatida imkoniyatlarni hisoblab beradi:

```python
import math

remaining = 120      # qolgan ish, story point
velocity = 20        # oxirgi 3 sprintning o'rtachasi
sprints_left = 4     # kelishilgan sanagacha qolgan sprintlar

capacity = velocity * sprints_left
gap = remaining - capacity
print(f"Sanagacha sig'im: {capacity} point, qolgan ish: {remaining} point, farq: {gap} point")
print(f"A) Scope: {gap} point'ni (eng past prioritetlisini) keyingi relizga o'tkazish")
print(f"B) Muddat: sanani {math.ceil(gap / velocity)} sprintga surish")
print(f"C) Aralash: {gap // 2} point keyingi relizga + {math.ceil(gap / 2 / velocity)} sprint qo'shimcha")
```

Skript hisob-kitobi:
- Qolgan 4 sprintda jamoaning sig'imi **80 point**, qolgan ish esa **120 point**. Farq — **40 point**.
- **Variant A:** 40 point'lik eng past prioritetli vazifalarni keyingi bosqichga o'tkazish.
- **Variant B:** Muddatni **2 sprintga** surish.
- **Variant C:** **20 point** ishni chiqarib tashlash va muddatni **1 sprintga** surish.

---

## 12. Texnik qarz (Technical Debt) va uni himoya qilish {#tech-debt}

Martin Fowler texnik qarzni to'rt kvadrantga ajratadi ([Martin Fowler — Technical Debt Quadrant](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html)):
- **Prudent & Deliberate:** *"Biz hozir reliz qilishimiz kerak va oqibatlarini keyin to'g'rilaymiz"* (ongli biznes qarori).
- **Reckless & Deliberate:** *"Bizda arxitektura qilishga vaqt yo'q"* (xavfli shoshqaloqlik).
- **Prudent & Inadvertent:** *"Endi biz buni qanday qilish kerakligini yaxshiroq tushundik"* (tajriba oshishi).
- **Reckless & Inadvertent:** *"Qatlamlar o'zi nima?"* (bilimsizlik).

Texnik qarzni boshqaruvchiga va mahsulot egasiga tushuntirishda texnik atamalar (masalan, "refaktoring kerak") o'rniga biznes tilidan foydalaning:
- *"Agar ushbu qarz to'lanmasa, har bir yangi funksiyani ishlab chiqish tezligi 30% ga sekinlashadi va tizim beqarorlashadi."*
- Texnik qarzni alohida **Tech Debt Register** jurnalida yuritish va har bir sprintda unga jamoa vaqtining ma'lum bir qismini ajratish tavsiya etiladi.

---

## 13. Xulosa {#xulosa}

- ISO 31000 bo'yicha risk — bu maqsadlarga noaniqlikning ta'siri bo'lib, unga nisbatan 7 xil davolash yondashuvi mavjud.
- Risk registridagi $P \times I$ reytingi jamoaga eng kritik xavflarga diqqat qaratish imkonini beradi.
- RACI matritsasida har bir qatorda yagona Accountable (A) shaxs bo'lishi loyiha intizomini kafolatlaydi.
- RAG hisobotlari orqali boshqaruvchilarga status berishda oldindan belgilangan toleranslarga tayanish lozim.
- EVM loyihaning pul va muddat samaradorligini (CPI, SPI) ob'ektiv ko'rsatadi, ammo Agile sharoitida ehtiyotkorlik bilan qo'llanadi.
- Kechikayotgan loyihaga odam qo'shish Brooks qonuniga ko'ra kechikishni kuchaytirishi mumkin; eng to'g'ri yo'l — scope'ni qisqartirish yoki sanani asosli surishdir.

---

## Manbalar {#manbalar}

1. [ISO 31000 Risk Management — Wikipedia](https://en.wikipedia.org/wiki/ISO_31000)
2. [Stakeholder Analysis — Wikipedia](https://en.wikipedia.org/wiki/Stakeholder_analysis)
3. [Responsibility Assignment Matrix (RACI) — Wikipedia](https://en.wikipedia.org/wiki/Responsibility_assignment_matrix)
4. [PRINCE2 Methodology — Wikipedia](https://en.wikipedia.org/wiki/PRINCE2)
5. [State of Project Management 2026 — Wellingtone](https://wellingtone.co.uk/state-of-project-management/)
6. [ITIL 4 Practices — Wikipedia](https://en.wikipedia.org/wiki/ITIL)
7. [Earned Value Management — Wikipedia](https://en.wikipedia.org/wiki/Earned_value_management)
8. [Earned Value Analysis — Wikipedia (DE)](https://de.wikipedia.org/wiki/Earned_Value_Analysis)
9. [Earned Schedule — Wikipedia](https://en.wikipedia.org/wiki/Earned_schedule)
10. [Time and Materials Contracts — Wikipedia](https://en.wikipedia.org/wiki/Time_and_materials)
11. [Brooks's Law — Wikipedia](https://en.wikipedia.org/wiki/Brooks%27s_law)
12. [Technical Debt Quadrant — Martin Fowler](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html)