Üksus 2 / 11

Tööjaotuse struktuur (WBS) ja ulatuse planeerimine

Kasu:

  • Mõistke ulatuse avalduse ja tööjaotuse struktuuri (WBS) mõisteid ning kasutage tehisintellekti tööpakettideks jagatud WBS-i mustandi loomiseks
  • Tehisintellekti toega tehisintellekti toega tehisintellekti toega tehisintellekti toega tehisintellekti reguleerimisalast väljas olevaid esemeid, tarneid ja vastuvõtukriteeriume selgitage
  • Oskus mõista, et projektijuhi kohustus on kinnitada tehisintellekti poolt toodetud WBS-i terviklikkust, realistlikkust ja sobivust organisatsiooni kontekstiga meeskonna ja sidusrühmade kontrollimise kaudu.

Kui alustate projekti küsimusega "mida me teeme?" Sellest alustamine on nagu pimedas kõndimine. Projektid ebaõnnestuvad sageli mitte sellepärast, et neid juhitakse halvasti, vaid seetõttu, et need olid algusest peale valesti määratletud. Selle üksuse teemaks on kaks põhitööriista, mis visandavad projekti piirid ja jagavad töö juhitavateks osadeks: ulatuse avaldus ja töö jaotuse struktuur. Kui need kaks dokumenti on õigesti üles seatud, on ajakava, prognoos, risk ja eelarve kindlalt nende peal; Kui seade on valesti seadistatud, väriseb kõik kogu projekti vältel. Tehisintellekt on mõlemas dokumendis võimas koostamispartner: see pakub välja ulatuse skeleti ja jaotuse tööpakettideks minutitega. Kuid pidage meeles: AI loob üldise mustri; Ainult teie ja teie meeskond teate teie organisatsiooni tegelikke tulemusi, piiranguid ja aktsepteerimiskriteeriume.

Mis on ulatuse avaldus?

Ulatus on see, mida projekt sisaldab ja mida mitte. Ulatuse avaldus on dokument, mis vormistab selle kirjalikult ja sisaldab tavaliselt järgmist: projekti eesmärk, peamised tulemused, aktsepteerimiskriteeriumid, reguleerimisalast väljas olevad üksused, eeldused ja piirangud. Kõige kriitilisem ja enim tähelepanuta jäetud osa siin on rakendusalast väljas olev nimekiri: "Me ei tee selles projektis X-i" takistab hiljem argumenti "aga ma arvasin, et see oli kaasatud".

Kui ulatus väljub kontrolli alt, nimetatakse seda ulatuse hiilimiseks: projekti lisatud väikesed heakskiitmata tööd ajavad selle aja jooksul üles. "Lihtsalt veel üks väike lisa", kui seda korrata, lööb eelarve ja ajakava õhku. Hea ulatuse avaldus ja selged aktsepteerimiskriteeriumid on esimene kaitseliin ulatuse hiilimise vastu. Vastuvõtukriteeriumid on mõõdetavad tingimused, millele tarne peab vastama, et seda loetaks "täielikuks" (nt "laadimine vähem kui 2 sekundiga").

Näpunäide. Kui kirjutate ulatuse avaldust, pange sama palju vaeva loendisse "mida me ei tee" kui "mida me teeme". Välja arvatud esemed on projekti odavaim kindlustus.

Mis on tööjaotuse struktuur (WBS)?

Tööjaotuse struktuur (WBS) on hierarhiline puu, mis jagab projekti kogutöö loogilisteks osadeks, mis järk-järgult ülevalt alla vähenevad. Üleval on projekt, selle all peamised tulemused/faasid ja nende all tööpaketid. Tööpakett on madalaima taseme töö, mida saab inimesele/meeskonnale määrata ja mis on piisavalt väike, et hinnata selle kestust ja maksumust. Hea WBS järgib kahte reeglit: 100% reegel (alumiste osade summa sisaldab kogu ülemist osa, ei rohkem ega vähem) ja vastastikune eksklusiivsus (kaks paketti ei sisalda sama tööd, ei kattu).

Miks on WBS nii oluline? Sest prognoosimine, ajakava, eelarve ja risk tehakse alati tööpaketi tasemel. “Teeme veebilehe” on ettearvamatu; kuid sellised paketid nagu "sisselogimislehe kujundus", "kasutaja registreerimisvorm", "maksete integreerimise testimine" on etteaimatavad. WBS on ka vastutuse määramise (RACI), edenemise jälgimise ja suhtlemise raamistik.

Samm-sammult: WBS-i mustandi loomine tehisintellektiga

  1. Täpsustage ulatust. Andke tehisintellektile anonüümselt projekti eesmärk, peamised tulemused ja teadaolevad piirangud. Hea WBS ei tulene ebaselgest eesmärgist.
  2. Küsi jaotuse mustandit. Küsige tehisintellekti faasideks ja tööpakettideks jagatud hierarhiat; Küsige iga paki üherealist ulatuse kirjeldust ja tarnimissoovitust.
  3. Testige 100% reeglit. Kontrollige, kas toodetud pakendite kogusumma vastab täielikult kohaldamisalale; Märkige puuduvad ja mittevajalikud esemed.
  4. Lisa vastuvõtmise kriteeriumid. Nõua iga peamise väljundi jaoks mõõdetavate aktsepteerimiskriteeriumide kavandit, seejärel viimistlege neid tegelikkusega võrreldes.
  5. Täpsustage reguleerimisalast väljas. Küsige AI-lt loendit "esemetest, mis peaksid tõenäoliselt selle projekti jaoks sobimatud olema" ja arutage seda meeskonnaga.
  6. Meeskonna ja sidusrühmade valideerimine. Vaadake mustand koos tööpaketi omanikega üle. WBS pole kunagi "plaan" ilma meeskonna nõusolekuta.
Ettevaatust: tehisintellekti loodud WBS võib sageli puududa kriitilisest paketist (nt „juriidiline kinnitus”, „andmete migratsioon”, „kasutajakoolitus”), mis tundub loogiline, kuid on teie organisatsioonile omane. Puuduv pakett muudab teie ennustuse algusest peale valeks. Rakendage kindlasti 100% reeglit inimese vaatenurgast.

kolm minikarpi

Juhtum 1 – aega säästev plaan. Selle asemel, et luua WBS-i uue sisevõrgu projekti jaoks nullist, andis PMO ekspert YZ-le anonüümse ulatuse kokkuvõtte ja palus mustandit. YZ pakkus välja 6 etappi ja 34 tööpaketti. Ekspert eemaldas 5 paketti ja lisas 3 puuduvat paketti (SSO integreerimine, juurdepääsetavuse testimine, sisu migreerimine) 45-minutilises töötoas koos meeskonnaga. Töö, mis nullist ühe päeva oleks võtnud, sai poole päevaga valmis ja sai terviklikumaks.

Juhtum 2 – skoobi libisemise püüdmine. Projektijuht esitab kliendilt tehisintellekti 12 väikest päringut ja küsib: "Kas need on kehtiva ulatuse avalduse kohaselt kohaldamisalas või väljaspool seda?" Ta lasi selle klassifitseerida järgmiselt: YZ 7 märkis taotluse kui "võimalik, et see ei kuulu rakendusalasse". Peaminister muutis need ametlikeks muutmistaotlusteks; vastasel juhul imbub 3 nädalat täiendavat tööd vaikselt projekti.

Juhtum 3 – puuduv paketilõks. Meeskond kiitis ilma kontrollita heaks 28 YZ toodetud WBS-i pakki. Projekti keskel märgati, et puuduvad paketid "andmete migratsioon" ja "käivitage proov"; need kaks vahelejäämist lisasid graafikusse 4 nädalat. Õppetund: AI kavandeid ei tohiks ilma inimkatseta 100% reegliga heaks kiita.

Nõrk viip / Tugev viip

Nõrk viip:

Kirjutage mobiilirakenduse projekti jaoks WBS.

See viip on väga üldine: AI loob tavaliselt malli, kuid sellel on vähe tähtsust teie projekti tegelike tulemuste, piirangute ja aktsepteerimiskriteeriumide jaoks.

Võimas viip:

Sinu roll: vanemprojektiplaneerimise spetsialist.Kontekst: Varude jälgimise mobiilirakendus jaekliendile (nimi maskeeritud).Piirangud: 4 kuud, integreerimine olemasoleva ERP-ga kohustuslik, iOS+Android, andmete migratsioon on olemas.Ülesanne: koostada WBS-i mustand, mis on jagatud etappideks ja tööpakettideks.Reeglid:- Järgige 100% reeglit; iga etapi paketid peaksid katma faasi täielikult.- Iga tööpaketi puhul: üherealine ulatus + peamine tulemus + mõõdetavad aktsepteerimiskriteeriumid.- Lisage lõppu eraldi loend "võimalik, et väljaspool ulatust".- Märkige asutusepõhised paketid, milles te pole kindel, "[kinnita meeskonnaga]", sobitamisega. Väljund: allahindluste tabel (faas | Pakend | Ulatus | Tarne | Vastuvõtmise kriteeriumid).

See taotlus on tugev, kuna kontekst, piirang, 100% reegel, aktsepteerimiskriteeriumid ja kohaldamisalast välja jääv taotlus on selged; samuti jõustab määramatuse "[kinnitus meeskonnaga]".

Täiendavad mallid:

# Väljaspool ulatuse leidjaLugege allolevat ulatuse avaldust. Loetlege "mitte reguleerimisalasse kuuluvate kandidaatidena" ülesanded, mis on tavalised, kuid mida siin SELGELSELT ei mainita (nt koolitus, dokumentatsioon, tugi, migratsioon, turvatestimine). Küsige igaühe puhul, miks see tuleks kaasata/välistada.

# Vastuvõtukriteeriumide tootja Soovitage 3–5 mõõdetavat vastuvõtmiskriteeriumi järgmise tarne jaoks (SMART-vormingus): [tarne]. Ärge kirjutage kriteeriume, mida ei saa mõõta (näiteks "see peaks hästi toimima").

# 100% reeglikontrollUurige allolevat WBS-i. Millisel ulatuslause väljundil EI ole üheski tööpaketis vastet? Millised paketid ÜLETAVAD ulatuse avalduse? Loetlege lüngad.

Levinud vead

  • Mitte kirjutamine väljaspool ulatust: kui "mida me ei tee" on ebaselge, on ulatuse hiilimine vältimatu.
  • Liiga suured või õhukesed pakid: hiiglaslik pakk, mis kestab kuu aega, on ettearvamatu; Pisike ühetunnine pakett ajab juhtkonnale üle jõu. Pakid peavad olema etteaimatavad ja jälgitavad.
  • AI kavandi kinnitamine ilma seda kinnitamata: mittetäielik ettevõttespetsiifiline pakett (andmete migratsioon, regulatiivne heakskiit, koolitus) võltsib plaani algusest peale.
  • Vastuvõtmise kriteeriumide vahelejätmine: kui kriteeriume pole, on "tehtud" arutelu lõputu.
  • WBS-i seadmine ei keskendu pigem väljunditele kui tegevustele: hea WBS näitab tulemusi (nimesid), mitte selliseid tegevusi nagu "koosoleku pidamine".
Näpunäide: ärge kirjutage WBS-i üks kord ja jätke see sinnapaika. Kui saabub kinnitatud muudatus, värskendage WBS-i, seejärel ajakava ja eelarvet. WBS on elav dokument.

Kokkuvõttes

Ulatuse avaldus määratleb projekti piirid, samas kui WBS määratleb töö hallatavad osad. Hea ulatusega avaldus sisaldab selgeid aktsepteerimiskriteeriume ja tugevat „ulatusest väljas” loendit; Hea WBS järgib 100% reeglit ja vastastikust eksklusiivsust. Tehisintellekt toodab mõlema jaoks kiireid ja täielikke plaane, kuid võib jätta vahele asutusepõhised paketid. Projektijuhi ülesanne on rakendada 100% reeglit inimlikust vaatenurgast, selgitada väljapoole ulatust ja hankida meeskonna kinnitus.

Rakenduse ülesanne

Oma praeguse projekti jaoks koostage tehisintellektist WBS-i mustand, mis on jagatud etappideks ja tööpakettideks (anonüümseks muutke andmed). Seejärel rakendage koos mõne oma meeskonnaliikmega 100% reeglit: millised pakid on puudu, millised mittevajalikud, millisel tarnimisel pole vastuvõtmise kriteeriume? Parandage vähemalt 3 puuduvat/vale punkti ja salvestage parandatud WBS.

kontrollnimekiri

  • [ ] Minu ulatuse avaldusel on eesmärk, tulemus, aktsepteerimiskriteeriumid, reguleerimisalast väljas, eeldus ja piirang.
  • [ ] Täitsin meelega "väljaspool" nimekirja.
  • [ ] WBS järgib 100% reeglit (puuduvaid/liigseid pakette pole).
  • [ ] Iga tööpakett on etteaimatav ja jälgitav.
  • [ ] Igal olulisel väljundil on mõõdetavad aktsepteerimiskriteeriumid.
  • [ ] Kontrollisin koos meeskonnaga tehisintellekti mustandit; Lisasin asutusepõhised paketid.