Pelnas:
- Gebėjimas suprasti pakeitimo užklausos, problemų žurnalo, pakeitimų valdymo plokštės (CCB) ir kokybės kriterijų sąvokas bei parengti poveikio analizės projektą su dirbtinio intelekto palaikymu.
- Gebėjimas naudoti dirbtinį intelektą, kad būtų galima vizualizuoti pakeitimo apimtį, laiką, sąnaudas ir kokybę (geležinį trikampį) ir pagrindinės priežasties analizės projektą.
- Gebėjimas suprasti, kad pakeitimų patvirtinimas ir kokybės priėmimas priklauso kompetentingam sprendimų priėmėjui ir kad dirbtinio intelekto poveikio analizė turi būti patikrinta.
Joks projektas nevyksta taip, kaip planuota. Klientas pateikia naują užklausą, pasirodo netikėta klaida, pasikeičia reikalavimas. Šio skyriaus tikslas – valdyti šiuos neišvengiamus pokyčius, kol jie nevirsta chaosu. Sužinosime apie tris mechanizmus: pokyčių valdymą, užtikrinantį, kad joks darbas nepasikeis be patvirtinimo, problemų valdymą, kuris fiksuoja ir išsprendžia kylančias problemas ir kokybės valdymą, kuris užtikrina, kad rezultatai atitiktų „pakankamai gerai“. AI yra galingas analizės partneris visose trijose srityse: jis parodo pakeitimo užklausos apimties, laiko, sąnaudų ir kokybės poveikį, tiria pagrindines problemų priežastis, rengia kokybės kriterijus. Tačiau pritarimas pokyčiams ir kokybės pripažinimas visada priklauso kompetentingam sprendimus priimančiam asmeniui; DI poveikio analizė neturėtų būti paversta sprendimu be patikrinimo.
Pokyčių valdymas ir geležinis trikampis
Pakeitimo užklausa yra oficialus prašymas, kuriame siūloma pakeisti apimtį, tvarkaraštį, biudžetą ar išteklius. Nekontroliuojami pokyčiai yra pagrindinis taikymo srities šliaužimo šaltinis, kurį matėme ankstesniuose įrenginiuose. Sprendimas – kiekvieną pakeitimą perstumti pro vartus: pakeitimų valdymo plokštė (CCB) yra autoritetinga grupė, kuri vertina ir patvirtina/atmeta pakeitimų užklausas.
Norint suprasti kiekvieno pakeitimo poveikį, geležinio trikampio koncepcija yra labai svarbi: apimtis, laikas ir kaina yra tarpusavyje susiję (kokybe yra viduryje). Vieno pakeitimas turi įtakos kitiems: jei padidinsite apimtį, arba laikas, arba kaina padidės, arba kokybė sumažės; „Daugiau darbo per tą patį laiką, už tą patį biudžetą“ dažnai kainuoja kokybė. Gera poveikio analizė aiškiai parodo pakeitimo poveikį šioms trims (keturioms) dimensijoms.
Pakeitimų procesas paprastai yra toks: prašymas registruotis → poveikio analizė (apimtis/laikas/kaina/kokybė/rizika) → CCB sprendimas → planas, tvarkaraštis ir biudžeto atnaujinimas, jei jis patvirtintas → suinteresuotųjų šalių instruktažas. Bet kokie nepatvirtinti pakeitimai nebus įgyvendinti.
Problemų ir kokybės valdymas
Problema, skirtingai nei rizika, yra problema, kuri jau įvyko (rizika yra neapibrėžtumas ateityje, problema yra realybė šiandien). Problemų žurnalas yra tiesioginis sąrašas, kuriame stebimos neišspręstos problemos, jų prioritetas, savininkas ir sprendimo būsena. Pagrindiniai problemų priežastims nustatyti naudojami du būdai: 5 Kodėl – „kodėl? pereiti prie pagrindinės priežasties nuo paviršiaus simptomo, užduodant klausimą iš eilės; ir žuvies kaulų diagrama – priežasčių suskirstymas į kategorijas (žmogus, procesas, medžiaga, mašina, aplinka).
Kokybės vadyba susideda iš dviejų dalių: kokybės užtikrinimas (QA) užtikrina, kad procesai veiktų tinkamai (prevencinis), kokybės kontrolė (QC) tikrina, ar rezultatai atitinka kriterijus (detektorius). Priėmimo kriterijai ir atlikto apibrėžimas yra kriterijai, pagal kuriuos nustatoma, kada darbas tikrai baigtas.
koncepcija
ką
pavyzdys
prašymą pakeisti
Oficialus prašymas pakeisti planą
„Pridėti filtrą prie ataskaitos ekrano“
Poveikio analizė
Taikymo sritis / laikas / kaina / kokybė
"+5 dienos, +3% biudžetas, vidutinė rizika"
CCB
patvirtinimo institucija
Rėmėjas + PM + techninis vadovas
problema
Suvokta problema
„Bandomoji aplinka sudužo“
pagrindinė priežastis
Tikroji priežastis (5 priežastys)
„Atsarginės kopijos konfigūracija neteisinga“
Kokybės kriterijus
Priėmimo kriterijai
"Klaidų lygis < 1%"
Žingsnis po žingsnio: keitimas ir kokybė naudojant AI
- Patikslinkite prašymą. Pakeitimo prašymą parašykite kaip „kas, kodėl, kas to nori“; Neįmanoma analizuoti dviprasmiškos paklausos.
- Poveikio analizės projektas. Paprašykite dirbtinio intelekto poveikio, atsižvelgiant į apimtį, laiką, sąnaudas, kokybę ir riziką; patikrinti numerius su komandos duomenimis.
- Generuokite parinktis. Tegul AI išvardija parinktis „patvirtinti / atmesti / atidėti / taikyti iš dalies“ ir kiekvieno iš jų rezultatus.
- Pateikti CCB. Pateikite analizę sprendimų priėmėjui; Neteikite paraiškos be patvirtinimo.
- Pagrindinės priežasties analizė. Leiskite dirbtiniam intelektui sugeneruoti 5 „Kodėl grandinės ir žuvies kaulų“ kategorijas problemai spręsti; Išbandykite su tikrais duomenimis.
- Kokybės kriterijų kontrolė. Pateikite rezultatus AI ir pasirūpinkite, kad trūkumai / neatitikimai būtų parengti pagal priėmimo kriterijus; Galutinį sutikimą duoda ekspertas.
Atsargiai: AI gali atrodyti, kad pakeitimo poveikis yra nedidelis, pvz., „tik 2 dienos“, nes jis nežino paslėptų priklausomybių ir netiesioginių padarinių. Poveikio analizė neturėtų būti pateikta CCB kaip „galutinė“, nepatikrinus su komanda, kuri atliks darbą.
trys mini dėklai
1 atvejis – tikroji pakeitimo kaina. Klientas norėjo „nežymaus ekrano pakeitimo“. PM pateikė prašymą AI ir gavo poveikio analizės projektą: pakeitimas paveikė tris modulius, +6 dienas ir +4% biudžetą. Komanda tai patvirtino. CCB parodė tikrąsias išlaidas klientui; klientas atidėjo pakeitimą kitam etapui. Paklausa, kuri buvo laikoma „maža“, buvo suvaldyta, kol ji nevirto chaosu.
2 atvejis – rasta pagrindinė priežastis. Vienoje komandoje testavimo aplinka nuolat strigdavo. Koordinatorius perdavė problemos ataskaitą AI ir paprašė 5 Kodėl grandinės. Grandinė baigėsi „nepakankamai diskų → neapibrėžta valymo užduotis → nėra proceso savininko“. Komanda išsprendė pagrindinę priežastį (neišvalytas valymo procesas), o ne paviršiaus simptomą (griuvimas); Problema nepasikartojo.
3 atvejis – neįvertintas poveikis. Viena komanda patvirtino AI projektą „šis pakeitimas turi minimalų poveikį“ jo nepatikrinusi. Pakeitimas nutraukė priklausomybę nuo kritinio kelio ir projektas buvo atidėtas 9 dienomis. Pamoka: poveikio analizė negali būti naudojama kaip pagrindas priimant sprendimus be komandos patvirtinimo.
Silpnas raginimas / Stiprus raginimas
Silpnas raginimas:
Apsvarstykite šį pakeitimo prašymą.
Nėra dydžio, duomenų ir sprendimų sistemos; AI pateikia paviršutinišką ir galbūt pernelyg optimistišką atsakymą.
Galingas raginimas:
Jūsų vaidmuo: pokyčių valdymo analitikas.Pakeitimų užklausa: [aprašas]. Prašė: [role]. Pagrindimas: [kodėl].Kontekstas: esama apimtis, tvarkaraštis (pridedamas kritinis kelias), biudžeto būsena (santykiu).Užduotis: Poveikio analizė per geležinį trikampį Pagaminti JUODRAŠTĮ:- Įtaka apimčiai, Įtaka laikui (ar tai turės įtakos kritiniam keliui?), Įtaka sąnaudoms, Kokybės įtaka, Naujos rizikos- Galimybės: patvirtinti / atmesti / atidėti / iš dalies; kiekvienos taisyklės rezultatas: SURAŠykite skaitmeninių efektų JURAŽĄ ir pažymėkite juos "[reikalingas komandos patikrinimas]". Tarkime, kad nežinote paslėptų priklausomybių; tiksli kalba. Galutinį sprendimą priima CCB.
Šis raginimas yra galingas: apima geležinį trikampį, parinkčių generavimą, įspėjimą apie juodraštį ir sprendimų priėmėjo akcentą.
Papildomi šablonai:
#5 Kodėl variklisKlausimas "kodėl?" Išsiaiškinkite pagrindinę priežastį 5 kartus iš eilės užduodami klausimą: [problema]. Kiekviename veiksme taip pat parašykite, kaip kita priežastis bus patikrinta naudojant duomenis. Pridedama sugalvota priežastis.
# Fishbone gamintojas Išvardykite galimas šios problemos priežastis pagal kategorijas (žmogus, procesas, įrankis/mašina, medžiaga, aplinka, metodas). Pažymėkite 3 labiausiai tikėtinas priežastis ir pasiūlykite patvirtinimo būdą.
# Kokybės priėmimo inspektoriusPatikrinkite pristatomą prekę pagal šiuos priėmimo kriterijus; Atskirkite sutiktą, nepatenkintą ir neapibrėžtą. Nurodykite, kad galutinį sprendimą dėl priėmimo turi priimti ekspertas.
Dažnos klaidos
- Pakeitimo įgyvendinimas be patvirtinimo: pakeitimas be patvirtinimo yra pats aprėptis.
- Poveikio neįvertinimas: tai, ką dirbtinis intelektas vadina „mažu“ pokyčiu, gali būti didelis su paslėptomis priklausomybėmis.
- Simptomo pašalinimas ir pagrindinės priežasties palikimas: jei neatliksite 5 priežasčių, problema grįš.
- Problemos painiojimas su rizika: rizika ateityje, problema dabartyje; Jie valdomi skirtingai.
- Kokybės kriterijų paliekant subjektyvų: „Gerumas“ negali būti matuojamas; Priėmimo kriterijus turi būti skaitinis.
- Poveikio analizės pateikimas CCB be patikrinimo: neteisinga analizė skatina klaidingą sprendimą.
Patarimas: pasakyti „ne“ kiekvienai pakeitimo užklausai taip pat yra vadovybės sprendimas. Geras premjeras žino, kad pakeitimo atmetimas taip pat apsaugo projektą; PM priima kiekvieną užklausą ir valdo klientą, o ne projektą.
Apibendrinant
Pokyčiai, problemos ir kokybės valdymas išlaiko projektą neišvengiamų pokyčių metu. Pokyčiai praeina per CCB ir analizuojami per geležinį trikampį (apimtis-laikas-kaina-kokybė); Problemos užfiksuojamos ir pagrindinė priežastis sprendžiama naudojant 5 Kodėl ir žuvies kaulus; Kokybė užtikrinama išmatuojamais priėmimo kriterijais. AI pagreitina poveikio analizę, pagrindinių priežasčių tyrimą ir kokybės auditą. Tačiau komandų poveikio skaičių, pakeitimų patvirtinimo ir kokybės patvirtinimo patikrą atlieka kompetentinga žmogiškoji institucija.
Taikymo užduotis
Gaukite pakeitimų prašymą (faktinį ar potencialų) iš savo projekto. Sukurkite poveikio analizės metmenis ir sprendimų variantus iš AI per geležinį trikampį; patikrinkite numerius su kuo nors iš savo komandos. Be to, imkitės esamos problemos, suraskite pagrindinę priežastį naudodami „5 Kodėl variklį“ ir nukreipkite sprendimą į pagrindinę priežastį. Apibendrinkite poveikio analizę CCB sprendimo formatu.
kontrolinis sąrašas
- [ ] Pokytį analizavau per geležinį trikampį (apimtis/laikas/kaina/kokybė).
- [ ] Patikrinau poveikio skaičius su komandos duomenimis, pažymėtais kaip juodraštis.
- [ ] Nusiunčiau pakeitimą patvirtinti kompetentingai institucijai (CCB).
- [ ] Radau pagrindinę problemos priežastį: 5 priežastys / žuvies kaulas.
- [ ] Kokybės priėmimą susiejau su išmatuojamais kriterijais.
- [ ] Neįgyvendinau jokių pakeitimų be patvirtinimo.