SI loyiha boshqaruvi

“Nima uchun SI loyihalari har doim oxirda qulay keladi?”

Haqiqiy PM tomonidan duch kelgan SI loyihasining 5 ta xatar va real javob strategiyalari

SI loyihalari ko'pincha o'xshash tarzda boshlanadi.

Taklif bosqichida jadval ham mos keladi va ishchi kuchi ham yetarli ko'rinadi.Arxitektura ham ishonchli va mijoz ham “Yaxshi yordam bering” deb aytadi.

Lekin, rivojlanish 50% ga yetgach, muhit o'zgaradi.

• Talablar doimiy ravishda qo'shiladi va

• interfeys jadvali kechiktiriladi

• mijozlarning bo'limlari o'rtasidagi gaplar farq qiladi

• asosiy dasturchilar charchashga boshlaydi va

• test jadvali siqila boshlaydi.

Va ochilishidan bir oy oldin loyiha aslida urush maydoniga aylanadi.

Maydonda PM bo'lganlar biladi. SI loyihasi texnologiyadan ko'ra “xatarlarni boshqarish” kurashi ekanligini.

Haqiqiy loyihalar buzilishi odatda belgilangan naqshga ega. Ushbu maqolada maydonda eng ko'p yuzaga keladigan SI loyiha xatarlarining 5 tasi va PM nuqtai nazaridan haqiqatan ham samarali bo'lgan javob usullarini tartibga solamiz.

1. Talab (Scope) xatari

Loyihani eng ko'p buzadigan sabab

SI loyihasida eng xavfli narsa texnologiya emas. Ko'p hollarda talablar loyiha muvaffaqiyatini buzadi.

Dastlabki RFP odatda abstrakt bo'ladi. Muammo shundaki, loyiha har kim turlicha tushungan holda boshlanadi.

Mijozlar “albatta bo'ladi deb o'ylagan” bo'ladi, rivojlantirish jamoasi esa “texnik shartlarda yo'q edi” deydi.

Bu farq keyinchalik to'qnashadi.

① Kengayish — sekin-sekin qo'shiladi va loyiha to'kiladi.

Haqiqiy ish joylarida bunday so'zlar juda ko'p aytiladi.

“Bu shunchaki oddiy funksiyadir, uni birga qo'shib qo'ysa bo'lmaydimi?”

Muammo shundaki, ko'p hollarda oddiy emas.

Bitta ekran qo'shilganda:

• Ruxsatlar tuzilmasi o'zgaradi

• Tizim tuzish tartibi o'zgaradi

• API ta'siri yuzaga keladi

• Statistika mantiqini qayta moslashtirish zarur

• Sinov holatlari umuman o'zgartirilishi kerak bo'ladi.

Dastlab, PM munosabatlarni saqlab qolish uchun og'zaki qabul qila boshlasa, keyinchalik bu nazorat qilib bo'lmaydigan holga keladi.

Joyda buni "qor to'plari aylanadi" deb ifodalaydi.

② Tafsilotlar noaniq bo'lsa, oxirida barcha narsani qaytadan aytib o'tadi.

Matnga asoslangan talablar ta'rifi xavfli.

Mijoz allaqachon xayolida tayyor ekran tasavvur qiladi, dasturchi esa hujjatlar asosida minimal amalga oshiradi.

Nihoyat, UAT bosqichida albatta chiqqan so'zlar mavjud.

"Men xohlaganim bunday his-tuyg'u emas, shunday emasmi?"

Ushbu nuqtada UI/UX yo'nalishi o'zgarsa, loyiha deyarli qaytadan ishlab chiqish darajasiga o'tadi.

PM javob nuqtalari

Joyda talablar o'zgarishini to'xtatish amalda mumkin emas. Muhimi, "boshqarilmaydigan o'zgarishlar" ni oldini olishdir.

Amaliyotda quyidagi 3 ta narsani albatta nazorat qilish kerak.

• Barcha o'zgarish talablarini rasmiylashtirish

• Ta'sirni tahlil qilishdan so'ng tasdiqlash

• Jadval/xarajat trade-off ni rasmiylashtirish

Xususan, bu juda muhim.

"Qo'shimcha funksiyalarga ruxsat beriladi, lekin jadval yoki doira tuzatish talab etiladi."

Bu so'zni rasmiy ravishda qoldirmasangiz, keyinchalik hammasi bajarilish mas'uliyati sifatida qaytadi.

2. Texnologiya va infratuzilma xavf-xatarlar

Ekran chiqadi, lekin tizim ishlamaydi

Taklifnoma bosqichidagi arxitektura har doim mukammal ko'rinadi.

• MSA

• Bulutga mos keluvchi

• Real vaqtli bog'lanish

• Katta hajmli ishlov berish

• AI integratsiyasi

Ammo haqiqiy ish olib borish muhiti boshqacha.

Rivojlantirishning oxirida texnologik qarz bir vaqtning o'zida oqqachadi.

① Texnologik tasdiqlovsiz yangi texnologiya kiritilsa, albatta muammo yuzaga keladi

Oqimda tez-tez ko'riladigan shablon.

• Hech kim ishlatmagan frameworkni joriy qilish

• Iqtibos yoki misol bo'lmagan tuzilma qo'llanilishi

• Boshqaruv tajribasi bo'lmagan ochiq manba foydalanish

Boshida hamma narsa yaxshi ko'rinadi.

Muammo integratsion sinovdan boshlanadi.

• Ishlash samaradorligi yo'q

• Xotira portlayapti

• Transaktsiya o'zgarib ketmoqda

• Nosozliklarni tiklash ham bo'lmaydi.

Bu holatga kelganda loyiha “rivojlantirish” emas, “xatolarni tuzatish tashkiloti” ga aylanadi.

② Interfeys jadvali deyarli har doim kechikadi

SI loyihasi yakunida integratsion loyihadir.

ERP, guruh dasturi, tashqi tashkilotlar, PG, meros tizimlar bilan bog'lanmaslik kam uchraydi.

Muammo shundaki, integratsion tashkilotlar jadvali ko'p hollarda bizning nazoratimizga bo'ysunmaydi.

Maydonda haqiqatan ko'p uchraydigan vaziyat:

• API spetsifikatsiyalari doimiy ravishda o'zgaradi

• Sinov serveri ochilmaydi

• Mas'ul shaxs ta'tilda

• Xavfsizlik tasdiqlash kutilmoqda

• Fireval ochilmagan

Natijada, ishlab chiqarish jamoasi faqat Mask (Mock) ma'lumotlar bilan rivojlanadi.

Va oxirgi haqiqiy integratsiyada xatolar to'planadi.

PM javob berish nuqtalari

Amaliy PMlar interfeysni “alohida loyiha” sifatida boshqaradi.

Aslida muhim bo'lgan narsalar:

• Interfeys ta'rifini erta tasdiqlash

• Integratsiya mas'uli aloqa tarmog'ini ta'minlash

• Har hafta integratsiya yig'ilishini o'tkazish

• Sandbox jadvalini majburan belgilash

• Fireval jadvalini oldindan ko'rsatish

Bu.

Xususan, interfeysni kechikish bilan tuzganda, tiklash mumkin emas.

3. Jadval va inson riski

Nihoyat, loyiha odamlar tomonidan amalga oshirilib kelinadi

SI, nihoyat, odamlar biznesidir.

Qanday qilib jarayon yaxshi bo'lmasin, asosiy xodimlar tebranganda loyiha ham tebranishi mumkin.

① Key-Man chiqishining oqibatlari kutilgandan ko'ra halokatliroq

Loyihalarda albatta bo'ladi.

• Tuzilmani yaxshi biladigan PL

• Joylashuvni yolg'iz ishlab chiqqan dasturchi

• Interfeys asosiy mas'ul shaxs

Bu odam ketgan paytda loyiha to'xtaydi.

Muammo shundaki, alternative xodim kiritilganda darhol tiklanmaydi.

Odatda:

• Ishni tushunish

• Manba tahlili

• Domenni tushunish

Buni amalga oshirish uchun kamida bir necha hafta vaqt kerak.

Maydonda bu davrni «bo'sh vaqt» deb ataydilar.

② Jadvalning ko'p hollarda boshidan murakkabligi shundaki

Haqqoniyatni aytganda, SI jadvali ko'p jihatdan savdo jadvalidir.

Mijozlar ochilish jadvaliga asosan qarab aniqlanadi.

Shu sababli:

• Sinov siqish

• Loyihalashni o'tkazib yuborish

• Hujjatlar keyinroq taklif etish

• Tungi smenani doimiy qilish

va takrorlanadi.

Va agar jadval kechiksa, odatda shunday javob qaytariladi.

«Xodimlar ko'proq qo'shamiz»

Lekin aslida bu ishni sekinlashtiradi.

Mavjud xodimlar yangi xodimlarni o'qitishga vaqt ajratgani uchun ishlab chiqarish samaradorligi pasayadi.

Brooks qonuni maydonda takrorlanayotganining sababi.

PM javobgarlik nuqtalari

Amalda quyidagilarni albatta boshqarish kerak.

• Muayyan xodimlarga bog'liqlikni yo'qotish

• Kod tekshirishni majburiy qilish

• Hujjatlar uchun minimal talablarni saqlab qolish

• Muntazam loyihani bo'lishish

• Ish faoliyatini zaxira tizimini ta’minlash

Ayniqsa, “U odam bo'lmasa, bo'lmaydi” holati allaqachon xavf yuzaga kelgan holat deb hisoblanishi kerak.

4. Aloqa xavfi

Texnologiyadan qiyin bo'lgan narsa odamlarni muvofiqlashtirishdir

Loyiha texnik jihatdan muvaffaqiyat qozonib, mijozni qoniqtira olmasa, muvaffaqiyatsizlikdir.

Ayniqsa, yirik SIda manfaatdor tomonlar juda ko'p.

• Amaliy bo'lim

• IT bo'lim

• Xavfsizlik jamoasi

• Infra-jamoa

• Ishlatish jamoasi

• Boshqaruv

Har kimning xohishi boshqacha.

① Mijoz ichida fikrlar to'qnashuvi muqarrar yuzaga keladi

Bu haqiqiy joylarda keng tarqalgan.

Savdo jamoasining talab va boshqaruv jamoasining talablari farq qiladi, amaliyot va IT me'yorlari farq qiladi, boshqarma va filial talablarida farq bor.

Muammo mijoz ichidagi muammolardir, lekin oxir-oqibat vaqt bosimi ijrochi kompaniyaga tushadi.

② Subpudratchi tuzilmasida mas'uliyat chegaralari noaniq bo'ladi

Katta loyiha bo'lsa shuncha:

• Nashr

• Old tomon

• Orqa tomon

• Interfeys

• Infratuzilma

Tashkilotlar alohida harakat qiladi.

Ushbu holatda R&R aniq bo'lmasa, loyiha tezda mas'uliyat tangentiiga kiradi.

Maydonda eng xavfli so'z bor.

“Bu bizning doiramizda emasmi?”

Bu so'zlar paydo bo'lishi bilan jadval keskin orqaga qaramaydi.

③ Aslida eng qo'rqinchli narsa CEO riskidir

Maydonda PMlar eng qo'rqadigan narsa aslida texnik muammo emas.

Menejment o'zgaruvchisi.

Namuna:

6 oy davomida loyiha va ishlab chiqish qilindi, lekin boshqaruvda xuddi shunday:

“Hozirda AI kirishi kerak emasmi?”

Bir so'z aytilsa, yo'nalish o'zgaradi.

Ishchi guruhi allaqachon kechikkanini biladi.

Ammo loyiha yana siljiydi.

Aksincha, ijrochi rahbariyat riski ham mavjud.

• Noqonuniy talablar

• Haqiqiy bo'lmagan jadval

• Arzon shartnoma

• Bepul funksiyalarga va'da

Maydon dastlabdan zarar tuzilmasiga kiradi.

PM javob nuqtalari

Rahbariyat riskini “irqadagi ochilishdan” boshqa javob yo'q.

Shuning uchun muhim bo'lgan narsa:

• Ishchi qo'mita (Steering Committee)

• Muntazam direktorlar hisobotlari

• Prototipni erta oshkor qilish

• O'rta ko'rsatuv ko'rinishi

Bu.

Rahbariyat oxirida birinchi marta ko'rganda, deyarli doimo yo'nalishni o'zgartiradi.

5. Test va ma'lumotlarni o'tkazish risklari

Loyihalar ochilishidan oldin haqiqiy xavfga duch keladi

Orqa qism ekran chiqarilganda loyiha deyarli tugagandek ko'rinadi.

Lekin aslida eng xavfli nuqtalar shundan boshlanadi.

① Testlarni kamaytirish boshlanganda bu allaqachon xavf signali

Jadvalni kechiktirganingizda, eng birinchi kamayadigan narsa testlarni hisoblang.

Joylarda tez-tez yuz beradigan holatlar:

• Modul testlarini o'tkazib yuborish

• Integratsiya testlarini qisqartirish

• Faqat Happy Pathni tekshirish

• Nosozlik senariyasi tekshirilmagan

Bu holatda ochilish bo'lsa, faoliyatning birinchi kunida avariya bo'ladi.

Xususan:

• Kasb-hunar o'zaro bog'lanuvchilar

• Batch to'qnashuvi

• Ma'lumotlar mosligi

• Ruxsat xatosi

ko'pincha operatsiyada birinchi marta paydo bo'ladi.

② Ma'lumotlarni ko'chirish deyarli doimo kutilganidan qiyin.

Merosdagi ma'lumotlar asosan buzilgan.

• NULL ma'lumotlar

• Kod qiymatlari mos kelmaydi

• Takroriy ma'lumotlar

• Sana format xatosi

• Moslik qulash

Aslida ko'chirish kuni kutilmagan xatolar davom etadi.

Shuning uchun amaldagi PMlar ma'lumotlarni ko'chirish repititsiyalarini bir necha marta o'tkazadilar.

Asl Cut-Over “haqiqiy” emas, “repetitsiya natijasi” bo'lishi kerak.

Xulosa

SI loyihasi nihoyatida riskni boshqarish loyihasidir

Joyda uzoq qoldirgan PMlar umumiy ravishda shunday deydilar.

Loyihada muammo yo'q emas, muammo yuzaga kelganda ishonchni saqlash muhim.

SI loyihasida muhim narsa mukammallik emas.

• Risklarni tezda aniqlash va

• yashirmasdan ulashish

• muhitni vaqtida o'zgartirish

• qarorlarni qabul qilishni ta'minlash

bu loyiha omonatligi hisoblanadi.

Kiyosda haqiqatan ham xavfli loyiha muammosi bo'lmaydigan, muammoni hech kim aytmaydigan loyihadir.

Va ko'pchilik loyihalar bir kunda to'satdan buzilmaydi.

Boshidan boshlab doimiy ravishda signal berilayotgan edi.

Xulosa: Gʻalaba qozonuvchi SI loyihasi uchun 'PM risklarini boshqarishning 3 ta asosiy printsipi'

Yuqorida aytib o'tilgan 5 ta soha risklarini mutlaqo to'sib qo'yish imkoni yo'q. Risklarni boshqarishning mohiyati 'xavflarni oldini olish' emas, balki 'xavf yuzaga kelganda tizimning qulashini oldini olish uchun zarbalarni boshqarish' hisoblanadi. Buning uchun barcha loyiha rahbarlari yuraklariga o'rnatishi kerak bo'lgan 3 ta printsip mavjud.

[Risklarni boshqarishning asosiy tsikli]

정기적인 위험 식별(WBS 기반)

  ▼

  투명한 시각화(Red / Yellow / Green)

  ▼

  신속한 에스컬레이션(공식 채널 활용)

Birinchidan, vizualizatsiya qilinishi va oshkora tarzda ulashilishi kerak (ko'rsatish usuli Green hisobotining tugashi)

Ko'pgina loyihalarda haftalik hisobot paytida xavflarni yashirishadi va qo'lga olingandan keyin 'qizil' holatini ko'ndalang qo'yishadi. Xavf belgilari ko'rinsa darhol haftalik hisob va dashtbordga aks ettirilishi kerak. Muammolar erta baham ko'rilsa, markazdan texnik yordam olish yoki mijoz bilan doiralarni muhokama qilish imkoniyati bo'ladi.

Ikkinchidan, o'zgarishlarni boshqarish hissiyotlar asosida emas, balki 'jarayon' asosida amalga oshirilishi zarur.

Mijozlar bilan yaxshi munosabat faqat talablarni to'liq bajarish orqali saqlanmaydi. Aksincha, sifati past bo'lib ochilgan taqdirda munosabatlar to'liq qulashi mumkin. Barcha talablardagi o'zgarishlar yozma ravishda qayd etilishi va qo'shimcha xarajatlar hamda vaqt ta'sir ko'rsatkichlarini aniq hisoblab, tizim (CCB) orqali tasdiq olish madaniyatini shakllantirish zarur.

Uchinchidan, mukammal ochilishdan ko'ra 'xavfsiz bosqichma-bosqich ochilish(Phased Rollout)'ni ko'rib chiqing.

Big-Bang usulida har tomonlama bir vaqtda ochilish xavfi juda katta. Asosiy modullar yoki ma'lum nuqtalar, ma'lum foydalanuvchi guruhlariga mo'ljallangan holda birinchi bo'lib tizimni ochib (Pilot Open) barqarorligini tasdiqlab, keyin asta-sekin kengaytirish arxitekturasi va vaqt strategiyasini tayyorlash maqsadga muvofiqdir.

SI loyihasi to'polonli dengizda suzish bilan bir xil. Qachon bo'ron kelishini bilmaymiz, ammo ishonchli xarita (tekshirish ro'yxati) va kuchli chidamlilik (xavf boshqarish jarayoni) mavjud bo'lsa, har qanday loyihani belgilangan manzilga yetkazib berish mumkin. Hozirda amalga oshayotgan loyihangiz xavfsizmi?

Daniel(L)