Neprecīzas aplēses ir viena no populārākajām projektu vadības problēmām. Uzsākot jaunu IT projektu, jūs vēlaties zināt divas lietas: cik ilgi tas prasīs un cik tas izmaksās. Lai atbildētu uz šiem jautājumiem, jums ir jāsagatavo topošo projektu aplēses. Nav maģiska noteikuma, kas nosaka, ka projekts X ilgst 12 nedēļas un izmaksā $150 000. Vai arī Y līdzīgas tīmekļa vietnes izstrāde aizņem 10 nedēļas un izmaksā $100000.
Ko uzzināsiet no šī raksta:
- Kā projektu vadītājiem sagatavoties izmaksu aplēsēm projektu vadībā?
- Kādas aplēšu metodes ir noderīgas projektu aplēsēm?
- Kā plānošana notiek, lai sagatavotos izmaksu novērtēšanai ar formulām?
Jūs nevarat novērtēt projekta laika grafiku vai izmaksas bez rūpīgas aplēses, pat ja projekta apjoms ir ļoti līdzīgs iepriekš veiktajiem darbiem. Tomēr viss kļūst vēl sliktāk: aplēses nekad nesniegs jums 100% precīzu atbildi arī uz šiem jautājumiem. Tātad, kāpēc mēs veicam aplēses? Tāpēc, ka tas ir vienīgais veids, kā izdarīt pieņēmumus par projekta laika grafiku un budžetu, darba apjomu un projekta īstenošanai nepieciešamajiem resursiem.
Veicot projekta aplēses, jūs varat arī plānot darbiniekus ar atbilstošu pieredzi un prasmēm. Tas, ko jūs varat darīt, ir izmantot metodoloģijas un paņēmienus, kas ļaus jums veikt maksimāli precīzu aplēsi. Lūk, kā izmantot Agile metodoloģiju un plānošanas pokera tehniku, lai izveidotu jēgpilnas projekta aplēses.
Džeimss Grenings (James Grenning) 2002. gadā izstrādāja plānošanas pokera sesiju, kas pazīstama ar savu stratēģiju Scrum poker. Pagājušā gadsimta 50. gadu sākumā viņa izstrādātā novērtēšanas metode Wide band Delphi bija pārāk laikietilpīga un ar citiem ierobežojumiem. Grenninga gadījumā pokera plāns sākotnēji bija saistīts ar problēmas risināšanu, kurā spēlētāji bija pārāk aizrautīgi un pārāk koncentrēti, lai uzvarētu. Mike Cohn, Agile alianses un Scrum alianses dibinātājs, vēlāk izmantoja šo tehniku rakstā Agile Estimation and Planning.
Veiksmīga projekta uzsākšana galvenokārt ir atkarīga no tā, cik labi jūs saprotat, par ko tas īsti ir. Tas ietver:
- Izpratne par klienta vēlmēm
- Izpratne par projekta mērķiem un tā galveno mērķi.
- Vajadzīgo funkciju saraksta izveide
Kad esat iepazinies ar klienta instrukciju un jums ir pēc iespējas vairāk informācijas par projekta prasībām, varat uzskaitīt visas funkcijas un nodot tās savai komandai.
Lai to izdarītu, izveidojiet produkta neizpildīto darbu sarakstu, kas sastāv no visām veicamajām funkcijām. Pēc tam varat noteikt to prioritātes, novērtēt to sarežģītību un aplēst, cik ilgs laiks būs nepieciešams, lai tās pabeigtu. Pareizs produkta neizpildīto darbu saraksts sastāv no:
- Lietotāju stāsti - apraksta darbības, ko lietotāji var veikt katrā produkta lietošanas posmā.
- Pieņemšanas kritēriji - uzskaitiet elementus, kas nepieciešami, lai stāsts tiktu pabeigts.
- Stāsta punkti - novērtējiet darba apjomu, riskus un sarežģītību relatīvā punktu vērtībā.
- Lietotāja stāsta uzdevumi - uzskaitiet uzdevumus, kas jāveic, lai nodrošinātu lietotāja stāsta izpildi.
Lai nodrošinātu precīzu un reālistisku novērtējumu, ir ļoti svarīgi iesaistīt izstrādes komandu produkta neizpildīto uzdevumu saraksta veidošanā un prioritāšu noteikšanā.
Kad ir sagatavots funkciju saraksts, piešķiriet prioritāti katrai no tām. Varat izmantot MoSCoW analīzes metodi, lai tās sakārtotu šādi:
- Jābūt
- Vajadzēja
- Varēja būt
- Nebūs
Izstrādājot projektu, koncentrējieties uz lietām, kas jums vispirms ir jānodrošina. MVP izveide dod iespēju pārbaudīt hipotēzes par savu ideju pirms visa projekta pabeigšanas, parādīt to ieinteresētajām personām vai beta lietotājiem un apkopot atsauksmes, kas ir svarīgas pārējo funkciju turpmākai izstrādei.
Prioritātes piešķiršana var arī palīdzēt jums aprēķināt projekta aplēses. Koncentrējoties uz galvenajām funkcijām un funkcijām, kas jāizpilda vispirms, jūs varat izdarīt precīzākus pieņēmumus par to paredzamo pabeigšanu. Attiecībā uz funkcijām, kas "varētu būt", varat sākt ar aptuvenu aplēsi, jo tās ir tālāk izstrādes procesā un līdz brīdim, kad jūsu komanda nonāks līdz tām, var daudz kas mainīties (un ja jūsu komanda nonāk līdz tām, jo pēc atsauksmju apkopošanas par jūsu MVP jūs varat mainīt un neiekļaut visas sākotnēji plānotās funkcijas).
Tomēr ir svarīgi novērtēt visas funkcijas neatkarīgi no to prioritātes (protams, izņemot "nebūs" funkcijas), jo vēlaties iegūt pārskatu par visu projektu uzreiz. Un, pārejot uz nākamajiem projekta posmiem, jūs varat atkārtoti izvērtēt darba apjomu, lai pārliecinātos, ka jūsu aplēses joprojām ir precīzas.
Tagad, kad esat pabeidzis produkta neizpildīto darbu, ir pienācis laiks novērtēt katru no tā elementiem. Šim nolūkam mēs izmantojam stāstu punktus. Tās ir vienības, ko Agile komandas izmanto, lai novērtētu darbu, kas nepieciešams, lai pabeigtu katru no neizpildīto darbu saraksta elementiem. Stāstu punkti palīdz piešķirt relatīvu vērtību produktu atpakaļsaraksta elementiem. Tie nav saistīti ar laiku, un dažādām komandām tie var būt ar atšķirīgu vērtību, tāpēc tiem nav emocionālas vērtības. Tādējādi pastāv iespēja, ka komandas locekļi neuzbāzīs aplēses tikai drošības labad. Plānošanas pokers palīdz programmatūras komandām plānot darba plūsmas un uzlabot projekta izpildes ātrumu.
Izmantojot stāsta punktus, komanda var novērtēt:
Plānošanas sesija ir viena no bruto līmeņa aplēšu metodēm, kurā tiek izmantota modificēta Fibonači secības versija: 1, 2, 3, 5, 8, 13, 20, 40, 100. Lai novērtētu produkta neizpildīto produktu saraksta posteņus, komandas locekļi saņem vienādus plānošanas pokera kāršu komplektus ar cipariem uz tiem. Pēc tam, kad produkta īpašnieks (kurš nebalso) ir īsi iepazīstinājis ar produkta nesamaksāto produktu saraksta elementu un ir notikusi diskusija, viņi privāti izvēlas karti ar to stāsta punktu skaitu, kas, viņuprāt, atbilst šim elementam nepieciešamajam darba apjomam, un atklāj tos vienlaicīgi.
Ja skaitļi atšķiras, komandas locekļi apspriež, kāpēc viņi ir izvēlējušies šādu stāsta punktu skaitu, un tad balso vēlreiz. Tā ir daļa no plānošanas pokera procesa, kas ir konsensā balstīta aplēšu metode, ko Agile izmanto, lai novērtētu lietotāju stāstu darbietilpību. Viņi to dara, līdz panāk vienprātību, un tad pāriet pie nākamā produkta darbu saraksta elementa. Un, ja saskaņotais skaits ir liels, teiksim, 20, 40 vai lielāks, tas nozīmē, ka stāsts var prasīt pārāk daudz darba vienam sprintam un to var būt nepieciešams sadalīt mazākos uzdevumos. Ideālā gadījumā posteņa prezentācijai, diskusijai un balsošanai vajadzētu aizņemt aptuveni divas minūtes, kas ļauj īsā laikā novērtēt visu neizpildīto darbu sarakstu. Taču, tā kā šeit runa ir par visa neizpildīto darbu kopuma novērtēšanu uzreiz, nesteidzieties un neuztraucieties, ja dažu stāstu novērtēšana aizņems nedaudz vairāk laika.
Komandas ātrums parāda, kāds ir projekta attīstības temps. Tas palīdz saprast divas lietas:
- Kādu darba apjomu jūsu komanda spēj paveikt vienā sprintā.
- Kāds ir paredzamais datums, kad tiks pabeigta visa darbības joma, pieņemot, ka tā ir fiksēta.
Katrai komandai ātrums ir atšķirīgs. To var novērtēt pēc pirmajām iterācijām, kad komanda jau ir strādājusi pie dažām funkcijām. Piemēram, ja pirmajā iterācijā esat iekļāvis četrus produkta darbu saraksta elementus, kuru kopējais skaits ir 20 stāsta punkti, un komanda ir pabeigusi trīs no tiem, kas atbilst 15 stāsta punktiem, tas ir jūsu komandas pašreizējais ātrums. Atcerieties, ka skaitās tikai pabeigtie elementi. Pat ja viņi būtu paspējuši sākt ceturto elementu, bet nav to pabeiguši, tas netiek ieskaitīts.
Scrum meistaram ir izšķiroša loma, lai atvieglotu aplēšu procesu un nodrošinātu precīzus novērtējumus šo sesiju laikā.
Pēc tam, kad ir apspriesti stāsta punkti un novērtēts komandas ātrums, jūs varat noteikt projekta grafiku. Lai to izdarītu, saskaitiet komandas ātrumu no pēdējām trim iterācijām un daliet to ar trīs. Piemēram, ja ātrums šajās iterācijās bija 20, 23 un 17, vidējais ātrums būtu aptuveni 20 punkti. Ja kopējais darba apjoms tika lēsts 100 stāsta punktu apmērā, tad, ja vidējais ātrums ir 20 punkti, projekta pabeigšanai būtu nepieciešamas 5 iterācijas. Pieņemot, ka viena iterācija ilgst divas nedēļas, jums projekts būtu jāīsteno 10 nedēļās.
Lai noteiktu projekta budžetu, varat izmantot šo pamatformulu: (kopējais stāsta punktu skaits / ātrums * komandas stundas sprintā) + ar darbu nesaistītās izmaksas = paredzamais budžets. Ja kopējais stāstu punktu skaits ir dalīts ar vidējo ātrumu, reiziniet sprintu skaitu ar 40 stundām nedēļā vienam komandas loceklim, lai iegūtu darbaspēka izmaksas. Tad pieskaitiet ar darbu nesaistītās izmaksas, piemēram, kapitāla izmaksas, aprīkojuma izmaksas, uzturēšanas izmaksas, apmācības izmaksas utt. Piemēram, mums ir projekts, kura aptuvenais apjoms ir 100 stāsta punkti, un mūsu komandas vidējais ātrums ir 20. Piešķirot projektam 5 cilvēku komandu ar stundu likmēm $50, komandas stundas vienā sprintā ir vērtas $20 000 un $100 000 par 5 sprintiem. Ar hipotētiskām ar darbu nesaistītām izmaksām $50,000, mūsu projekta paredzamais budžets būtu $150,000. Ņemot vērā ticamības intervālus parauglīmeņiem 80-120%, mūsu budžeta ziņotais diapazons tagad ir no $120 000 līdz $180 000.
Atcerieties, ka neviens aprēķins nav 100% precīzs. Vislabāk ir atkārtoti novērtēt projektu ik pēc dažām iterācijām, jo laika gaitā var mainīties tādas lietas kā resursu pieejamība, komandas ātrums vai projekta apjoms. Veicot atkārtotu novērtēšanu, jūs pārliecināties, ka jūsu tāme ir aktuāla. Izmantojot laika uzskaites un resursu plānošanas programmatūru, varat arī pārvaldīt komandas pieejamību un vajadzības gadījumā pārdalīt darbiniekus. Izmantojot pareizos paņēmienus un rīkus, jūs varat padarīt savas aplēses uzticamākas un labāk plānot nākamo projektu.
Precīzs projekta novērtējums ir ļoti svarīgs veiksmīgai projekta vadībai. Izprotot gaidas un mērķus, izveidojot detalizētu produktu sarakstu, nosakot prioritātes un izmantojot tādas metodes kā stāsta punkti un plānošanas pokers, jūs varat uzlabot savu aplēšu precizitāti. Regulāra atkārtota aplēšu veikšana un laika uzskaites un resursu pārvaldības rīku izmantošana vēl vairāk palielina jūsu projekta laika grafiku un budžetu ticamību. Ievērojot šos paņēmienus, jūs varat pārvarēt neprecīzu aplēšu problēmas un nodrošināt labākus projekta rezultātus.
Viegli izmantojiet plānošanas pokera novērtēšanas metodi
Noskaidrojiet, kāpēc mūsu resursu pārvaldības programmatūru izvēlas Hill-Knowlton vai Stormind Games projektu vadītāji.
Resursu kalendārs (vai projektu vadības kalendārs, vai projektu plānošanas kalendārs, resursu plānošanas programmatūra) ļauj efektīvāk un lietderīgāk plānot, pārvaldīt un sadalīt resursus - īpaši, ja Microsoft Excel ir bijusi vadošā loma jūsu...
Kāds ir projektu vadītāju galīgais mērķis? Veiksmīgi īstenot savus projektus. Paši projektu vadītāji atzīst, ka tas nenotiek pārāk bieži: saskaņā ar jaunāko "Pulse of the Profession" aptauju mazāk nekā 60% projektu tiek pabeigti vai nu...
Jaudas pārvaldība ir stratēģija, ko uzņēmumi izmanto, lai pēc iespējas labāk izmantotu ražošanas efektivitāti, ņemot vērā pieprasījumu pēc pakalpojuma vai produkta. Jaudas pārvaldības galīgais mērķis ir: identificēt un...