This is the Trace Id: 2efb12564785741e9bbc35882358de85
Pāriet uz galveno saturu Uzņēmuma izaugsme Uzņēmuma pārvaldība Produktivitāte Biznesa tehnoloģijas Biznesa padomi

Projektu pārvaldība: tradicionāla, iteratīva vai hibrīda?

Tāpat kā lielākajai daļai projektu vadītāju un organizāciju, jums, iespējams, ir grūti izvēlēties optimālo piegādes pieeju. Lielākā daļa no mums atzīst, ka tradicionālās pieejas negarantē sekmīgu piegādi, un mēs vienmēr meklējam labāku veidu.

 

Spējās jeb iteratīvās izstrādes metodes pēdējos gados ir saņēmušas daudz ļoti pozitīvu atsauksmju kā būtisks uzlabojums, kas nodrošina veiksmīgāku projektu piegādi. Tāpēc, tāpat kā lielākā daļa organizāciju mūsdienās, arī jūs, visticamāk, domājat, kur un kā šīs spējās jeb iteratīvās izstrādes metodes vislabāk izmantot, lai uzlabotu gan projektu piegādes savlaicīgumu, gan sekmīgumu.  

 

Īsumā, iteratīvās izstrādes metodes plāno, izstrādā un ievieš projekta funkcionalitāti nelielās daļās (jeb iterācijās). Sekmīgas iteratīvās piegādes pamatā ir tas, ka katra mazā daļa faktiski darbojas kā mazāks mini projekts kopējā projekta ietvarā. Rezultātā katru mini projekta iterāciju var plānot precīzāk, aprēķinot nepieciešamo piepūli divu nedēļu iterācijai, nevis divu gadu plānam. Turklāt, tā kā plānojam divu nedēļu periodos, varam viegli pielāgot nākamo divu nedēļu plānu, lai iekļautu visas konstatētās izmaiņas. 

Spējā un tradicionālā gadījuma izpēte

Vēlos uz brīdi apstāties, lai aprakstītu netehnisku situāciju, kurā, izmantojot spējās izstrādes pieeju, tika gūti lielāki panākumi nekā ar tradicionālu plānu. 

 

Izmantosim piemēru ar pilnas dienas aktivitāšu plānošanu — tas ir projekts. Tāpat kā liela projekta gadījumā, arī šeit ir daudz nenoteiktības un riska: mēs nezinām, kas notiks pēc pusdienām un varētu ietekmēt mūsu plānu, taču tradīcija paredz, ka izstrādājam visaptverošu plānu tam, ko darīsim katru dienu no pamošanās plkst. 6:00 līdz došanās gulēt brīdim plkst. 23:00.

 

Līdz plkst. 9:00 mēs atpaliekam no grafika, jo satiksme aizkavēja nokļūšanu darbā; plkst. 10:00 mūs aicina uz ārkārtas sapulci; un līdz pusdienlaikam vienīgais ikdienas uzdevums, kas pabeigts, ir nokļūšana birojā, un pat tas notika ar kavēšanos. 

 

Tagad aplūkosim to kā spējās izstrādes projektu, kurā plānojam tikai nākamo iterāciju: sagatavoties iziešanai no mājas (tātad uzdevumi ir duša, brokastis un bērnu nogādāšana skolā). Tas viss tika sekmīgi piegādāts laikā un budžeta ietvaros.

 

Tāpēc ar pārliecību plānojam nākamo iterāciju, proti, nokļūšanu birojā (brauciens uz autobusu depo, piepilsētas vilciens līdz stacijai un pēc tam pilsētas autobuss līdz birojam).

 

Tas neizdodas īpaši labi: pirmajam uzdevumam (brauciens uz autobusu depo) ir satiksmes radītas problēmas, tāpēc mainām uzdevumu uz braucienu uz biroju un vienojamies, ka pārējie divi uzdevumi var tikt izņemti no iterācijas plāna. Ierodoties mēs plānojam nākamo iterāciju. Taču plānošanas cikla vidū tiek pievienots jauns uzdevums (ārkārtas sapulce), un tas aizņems visu nākamo iterāciju.

 

Visbeidzot, pēc pusdienām viss norimst un varam pārskatīt nepabeigto darbu žurnālu un sākt darbu pie augstākās prioritātes uzdevumiem; pēcpusdienā mēs sekmīgi pabeidzam divas iterācijas, kas saistītas ar augstākās prioritātes vienumiem. 

 

Ja mēs būtu turējušies pie tradicionālā plāna, šos augstākās prioritātes vienumus mēs nekad nebūtu pabeiguši, jo tie tika pārcelti uz nākamo dienu plāna nobīdes dēļ, ko izraisīja brauciens uz biroju. 

Kāda ir vislabākā pieeja — elastīgā, tradicionālā vai hibrīda?

Tieši šī elastība pielāgoties mainīgajām biznesa vajadzībām ir tas, kas spējām jeb iteratīvajām metodēm padodas vislabāk, un tāpēc daudzas organizācijas tās ievieš. BET vai jūsu organizācija patiešām ir gatava pilnībā pāriet uz spējo pieeju? Manā pieredzē bieži ir daudz šķēršļu pilna apjoma spējās izstrādes ieviešanai, jo īpaši stingri nostiprinātas organizācijas politikas, kas bieži vien ir tikai daļēji saderīgas ar spējās izstrādes pieejām. 

Tādas politikas kā prasība, lai pirms projekta apstiprināšanas būtu noteikts budžets, ieguvumu realizācijas paziņojums un mērķa datums, ir svarīgas, bet īsti nav spējā izstrāde. Tāpat organizācijas ieviešanas politikām, kas jāievēro, lai nodrošinātu, ka netiek ietekmēta esošā darbība, ir būtiska nozīme, bet tās noteikti nav spējā izstrāde. 

Rezultātā daudzām organizācijām ir grūti saglabāt dažus galvenos tradicionālos procesus, vienlaikus pielāgojoties iteratīvajām metodēm. Atbilde ir hibrīdas piegādes modelis. Daļu projekta var piegādāt, izmantojot tradicionālās pārvaldības metodes, bet citas daļas var būt iteratīvas. 

Hibrīdās piegādes modelis

Visizplatītākais hibrīdmodelis, ar kuru esmu saskāries, atbalsta tradicionālu projekta uzsākšanu un plānošanu, kam seko vairākas iterācijas ar pārtraukumiem tradicionālām ieviešanas darbībām laidieniem, pēc tam vēl viena iterāciju sērija un tradicionāla ieviešana. 

 

Šajā modelī es izstrādāju tradicionālu, uz rezultātiem balstītu darba sadalījuma struktūru (WBS), kurā tiek identificēti galvenie rezultāti, kas organizācijā nepieciešami projekta apstiprināšanai, piemēram, projekta statūti, projektu pārvaldības plāns un projekta budžets.

Šos sākotnējos piegādājamos rezultātus var izstrādāt un pārvaldīt, izmantojot tradicionālās metodes, lai parādītu vadībai, ka šis projekts ir atbilstošs un ir laba vieta, kur ieguldīt resursus. 

 

Kad projekts ir apstiprināts, darbu var turpināt, izmantojot iteratīvu pieeju: tiek uzturēts nepabeigto uzdevumu žurnāls, un nākamajā iterācijā tiek atlasīti un pilnībā izstrādāti augstākās prioritātes uzdevumi. Projekta skats mainās no tradicionālas Ganta diagrammas uz interaktīvu vilkšanas un nomešanas paneli, kas ļauj dinamiski piešķirt uzdevumus iterācijām. 

 

Jebkurā laikā, bieži vien ikdienā, produkta īpašnieks var pievienot, dzēst un mainīt nepabeigto uzdevumu žurnālu, lai atspoguļotu mainīgās biznesa vajadzības.

Katras iterācijas beigās mēs apstājamies, veicam retrospektīvu veikumu un neveiksmju izvērtējumu, kā arī veicam izmaiņas, lai ieviestu nepieciešamos uzlabojumus. Pēc tam, un pats svarīgākais, mēs pārskatām produkta nepabeigto darbu žurnālu un atlasām svarīgākos uzdevumus kā kandidātus nākamajai iterācijai. Šī pieeja nodrošina, ka projekts vienmēr strādā pie vispiemērotākā un visvērtīgākā darba. 

 

Katras iterācijas ietvaros komanda var izmantot spējās izstrādes principus, piemēram, ikdienas sapulci, un pārrunāt pašreizējai iterācijai ieplānoto uzdevumu statusu. Tādā veidā komandai ir pilnīga kontrole pār darbiem, kas paveikti iterācijas laikā, vienlaikus nodrošinot, ka kopējais projekts joprojām ir aktuāls un pieejams uzņēmuma pārskatiem par resursu kapacitāti, kā arī portfeļa un programmas statusu.

Viens no spējās izstrādes principu pamatelementiem ir spēja ieviest galīgo risinājumu nelielos laidienos. Tas sniedz ieguvumu, jo ļauj izmantot sākotnējo funkcionalitāti, lai pēc iespējas ātrāk sasniegtu daļu no paredzētajiem biznesa ieguvumiem.

 

Turklāt tas ļauj agrīni validēt risinājumu, lai visas korekcijas varētu viegli iekļaut atlikušajos uzdevumos produkta nepabeigto uzdevumu žurnālā. Tāpēc, tiklīdz iterācijās ir pabeigts pietiekams skaits augstākās prioritātes uzdevumu, projekts pāriet atpakaļ tradicionālā ciklā un veic organizācijai nepieciešamos standarta ieviešanas uzdevumus. 

Izmēģiniet Microsoft Project bez maksas

Izmēģiniet Microsoft Project vienu mēnesi bez maksas

Šīs laidiena un ieviešanas darbības tiks plānotas un kontrolētas, izmantojot tradicionālas pieejas, un nodrošinās, ka tiek ievēroti noteiktie procesi, lai mazinātu jebkādu ietekmi uz esošo darbību, kad tiek ieviesti jauni projekti.

 

Kad pirmais laidiens ir pabeigts, projekts atgriežas pie spējās izstrādes pieejām un sāk strādāt cauri citai iterāciju secībai, lai turpinātu atlikušo uzdevumu izstrādi.

 

Lai gan šāda “fāžu” pieeja spējās izstrādes un tradicionālo pieeju apvienošanai ir visizplatītākā, varat kombinēt pieejas, lai atbalstītu konkrētas projekta piegādes prasības. Piemēram, es vadīju projektu, kuram bija nepieciešams ārkārtīgi augsts atbilstības un validācijas līmenis, ieviešot jaunu produktu ļoti stingri regulētā nozarē. Tāpēc lielākā daļa mana projekta tika plānota un kontrolēta, izmantojot tradicionālas metodes.

 

Tomēr projektā bija arī biznesa analīzes daļa, kurā mans uzņēmums analizēja milzīgo veiktspējas datu apjomu, ko ģenerēja sistēma; šo daļu vislabāk atbalstīja spējās izstrādes pieeja. BI komponentam projektā (kas norisinās paralēli tradicionālajam darbam) mēs atlasītu prioritārākos lietotājus uzdevumus, kurus varētu pabeigt trīs nedēļu sprintā, un pabeigtu vienu iterāciju.

 

Tā kā daudzi no šiem stāstiem bija izpētes rakstura, bieži vien mēs izveidotu jaunus stāstus vai nu tālākai izpētei, vai konkrētu veiktspējas pārskatu izveidei. Tie vienkārši tika pievienoti uzdevumu sarakstam, lai tos izvērtētu nākamajā sprintā.

 

Izmantojot šo pieeju, man bija viens projekta grafiks, kas nodrošināja visu nepieciešamo atskaišu un normatīvo darbību izpildi, vienlaikus ļaujot ļoti elastīgi izstrādāt neregulētās uzņēmējdarbības atskaišu komponentu projektā.

 

Visu darbu apvienošana vienā grafikā nodrošināja vienotu skatu uz visu, kas notika šajā projektā:

 

  • Informācija, kas man bija nepieciešama, lai pārvaldītu resursu piešķīrumus vispiemērotākajiem uzdevumiem (tradicionālajiem vai elastīgajiem), bija uzreiz pieejama
  • Bija pieejama iespēja izveidot jaudīgus iknedēļas un ikmēneša statusa pārskatus

 

Spējā izstrāde ir ārkārtīgi jaudīga projektu piegādes pieeja, kurai vajadzētu sniegt būtiskus ieguvumus jūsu organizācijas kopējā projektu piegādes rīkkopā. To var izmantot kā patstāvīgu risinājumu, kā daļu no pakāpeniskas piegādes pieejas vai integrēt hibrīdā piegādes struktūrā.

 

Galvenais ir ieviest spējās izstrādes principus, kas palīdzēs jūsu organizācijai nodrošināt veiksmīgu piegādi, vienlaikus ievērojot tradicionālos procesus, kas līdz šim ir palīdzējuši jūsu organizācijai būt veiksmīgai.

Stīvam Keislijam (Steve Caseley) ir vairāk nekā 35 gadu pieredze darbā ar Microsoft Project, un viņš ir aktīvs programmas Microsoft Project lietotājs kopš tās pirmās versijas. Viņš ir vairāku ar Microsoft Project un projektu pārvaldības labāko praksi saistītu grāmatu redaktors. Viņš ir galvenais konsultants uzņēmumā Sensei Project Solutions, kur viņš palīdz lielām organizācijām sasniegt izcilību projektu piegādē, izmantojot Microsoft Project Portfolio Management (PPM) rīkkopu.

Darba sākšana ar Microsoft 365

Tā ir pazīstamā sistēma Office un vēl dažādi rīki, kas palīdz labāk strādāt kopā, lai varat izdarīt vairāk jebkurā laikā un vietā.

Saistītais saturs

Mana uzņēmuma pārvaldība

Kāpēc vadībai nepatīk projektu vadītāji?

Uzņēmējdarbības ieskati un idejas nesniedz profesionālu konsultāciju nodokļu vai finanšu jomā. Jums jāsazinās ar savu nodokļu vai finanšu speciālistu, lai apspriestu savu situāciju.

Sekot produktam Microsoft 365

Latviešu (Latvija) Patērētāju veselības konfidencialitāte Sazināties ar Microsoft Konfidencialitāte Pārvaldīt sīkfailus Izmantošanas noteikumi Prečzīmes Par mūsu reklāmām EU Compliance DoCs