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

📋 IT Project Management

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
2. Risk registri va ehtimollik/ta'sir matritsasi
3. RAID log: muammolar va bog'liqliklar jurnali
4. Stakeholder tahlili va quvvat/qiziqish matritsasi
5. RACI matritsasi: rollar va javobgarlik taqsimoti
6. Kommunikatsiya rejasi va RAG status hisoboti
7. Uchrashuvlar tizimi: vaqt va maqsad chegarasi
8. O'zgarishlarni boshqarish va Scope Creep
9. EVM (Earned Value Management): loyiha iqtisodi
10. Shartnomalar: Fixed Price, T&M va Dedicated Team
11. Muddat kechikishi va Brooks qonuni
12. Texnik qarz (Technical Debt) va uni himoya qilish
13. Xulosa
14. 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).

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:

# (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) 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:

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):

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):

• 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:

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).

Wellingtone (2026) hisobotiga ko'ra, PM'larning 72% i har oyda kamida yarim kunini status hisobotlari tuzishga sarflaydi (Wellingtone). Ushbu yukni kamaytirish uchun qisqa va standart shablon zarur:

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):

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). 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).

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):

• 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).
• 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).

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

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:

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).

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).

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:

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):

• 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
2. Stakeholder Analysis — Wikipedia
3. Responsibility Assignment Matrix (RACI) — Wikipedia
4. PRINCE2 Methodology — Wikipedia
5. State of Project Management 2026 — Wellingtone
6. ITIL 4 Practices — Wikipedia
7. Earned Value Management — Wikipedia
8. Earned Value Analysis — Wikipedia (DE)
9. Earned Schedule — Wikipedia
10. Time and Materials Contracts — Wikipedia
11. Brooks's Law — Wikipedia
12. Technical Debt Quadrant — Martin Fowler