Ebatäpsed hinnangud on üks populaarsemaid projektijuhtimise probleeme. Uue IT-projekti alustamisel soovite teada kahte asja: kui kaua see kestab ja kui palju see maksab. Nendele küsimustele vastamiseks tuleb teil hinnata projekte, mida te kavatsete käivitada. Ei ole olemas maagilist reeglit, mis ütleb, et projekt X võtab aega 12 nädalat ja maksab $150 000. Või Y-taolise veebisaidi arendamiseks kulub 10 nädalat ja see maksab $100 000.
Mida te sellest artiklist saate teada:
- Kuidas valmistuvad projektijuhid projektijuhtimise kulude hindamiseks?
- Millised hindamismeetodid on kasulikud projekti hindamiseks?
- Kuidas võtab planeerimine aega, et valmistada end ette kulude hindamiseks valemitega?
Te ei saa hinnata projekti ajakava või kulusid ilma põhjaliku hinnanguta, isegi kui projekti ulatus on väga sarnane sellega, mida olete varem teinud. Kuid asi läheb veel hullemaks: hindamine ei anna teile kunagi 100% täpset vastust ka nendele küsimustele. Miks me siis hindame? Sest see on ainus võimalus teha eeldusi projekti ajakava ja eelarve, töökoormuse ja projekti elluviimiseks vajalike ressursside kohta.
Projekti hinnates saate ka õige kogemuse ja oskustega töötajad planeerida. Mida saate teha, on kasutada metoodikaid ja tehnikaid, mis võimaldavad teil hinnata võimalikult täpselt. Siin on, kuidas kasutada agiilset metoodikat ja planeerimispokkeri tehnikat, et koostada oma projekti kohta sisukaid hinnanguid.
James Grenning töötas 2002. aastal välja oma strateegia poolest tuntud planeerimispokkeri, mida nimetatakse Scrum pokkeriks. 1950ndate alguses oli tema hindamismeetod, Wide band Delphi, liiga aeganõudev ja tal olid muud piirangud. Grenningi puhul käsitles pokker algselt probleemi lahendamist, kus mängijad olid liiga entusiastlikud ja liiga keskendunud, et võita. Mike Cohn, agiilsete liitude ja Scrumi liitude asutaja, kasutas seda tehnikat hiljem artiklis Agile Estimation and Planning.
Eduka projekti käivitamine sõltub peamiselt sellest, kui hästi te mõistate, millega see tegelikult seotud on. See hõlmab järgmist:
- Kliendi ootuste mõistmine
- Projekti eesmärkide ja peamise eesmärgi mõistmine
- Nõutavate funktsioonide loetelu koostamine
Kui olete saanud kliendi lühikirjelduse läbi ja teil on võimalikult palju teavet projekti nõuete kohta, saate loetleda kõik funktsioonid ja edastada need oma meeskonnale.
Selleks looge toote tagavaraplaan, mis koosneb kõigist tegemata funktsioonidest. Seejärel saate need tähtsuse järjekorda seada, hinnata nende keerukust ja hinnata, kui kaua nende lõpuleviimiseks kulub aega. Korralik toote backlog peaks koosnema järgmistest elementidest:
- Kasutaja lood - kirjeldavad tegevusi, mida kasutajad saavad teha toote kasutamise igal etapil.
- Vastuvõtukriteeriumid - loe üles, mida on vaja loo lõpetamiseks.
- Loo punktid - hinnata töömahtu, riske ja keerukust suhtelises punktiväärtuses
- Kasutaja lugude ülesanded - loendage ülesanded, mida on vaja teha kasutaja loo elluviimiseks.
Täpse ja realistliku hinnangu tagamiseks on väga oluline kaasata arendusmeeskond tooteprojekti koostamisse ja prioriteetide seadmisse.
Kui funktsioonide nimekiri on valmis, määrake igaühele neist prioriteet. Võite kasutada MoSCoW analüüsimeetodit, et neid sorteerida järgmiselt:
- Peab olema
- Peaks olema
- Oleks võinud
- Ei ole
Projekti arendamisel keskenduge asjadele, mida peate esmajärjekorras täitma. MVP ehitamine annab teile võimaluse testida hüpoteese oma idee kohta enne kogu projekti lõpuleviimist, näidata seda sidusrühmadele või beetakasutajatele ning koguda tagasisidet, mis on oluline ülejäänud funktsioonide edasiseks arendamiseks.
Prioriteedi määramine aitab teil ka projekti hindamisel. Kui keskendute peamistele funktsioonidele ja nendele, mida on vaja teha esimesena, saate teha täpsemaid oletusi nende eeldatava valmimise kohta. "Võiks olla" funktsioonide puhul võite alustada ligikaudse hinnanguga, kuna need on arendusprotsessis kaugemal ja palju võib muutuda selleks ajaks, kui teie meeskond nende juurde jõuab (ja kui teie meeskond jõuab nende juurde, sest pärast tagasiside kogumist oma MVP kohta võite muuta ja mitte lisada kõiki algselt kavandatud funktsioone).
Oluline on siiski hinnata kõiki funktsioone, sõltumata nende prioriteetsusest (välja arvatud muidugi need, mida "ei ole"), sest te soovite saada korraga ülevaate kogu projektist. Ja kui jõuate projekti järgmistesse etappidesse, saate tööde mahtu uuesti hinnata, et teie hinnangud jääksid täpseks.
Nüüd, kui teil on oma tooteprojektide nimekiri valmis, on aeg hinnata iga üksikut selle punkti. Selleks kasutame jutupunkte. Need on üksused, mida agiilsed meeskonnad kasutavad iga backlogi elemendi lõpetamiseks vajaliku töö hindamiseks. Story points aitavad määrata toote backlogi objektidele suhtelist väärtust. Need ei ole seotud ajaga ja võivad erinevatele meeskondadele kanda erinevat väärtust, seega ei kanna nad emotsionaalset väärtust. Seega on tõenäoline, et meeskonnaliikmed ei paisuta hinnanguid vaid kindluse mõttes. Planeerimispokker aitab tarkvarameeskondadel kavandada töövooge ja parandada projekti valmiduskiirust.
Kasutades jutupunkte, saab meeskond hinnata:
Planeerimise sessioon on üks brutotasandi hindamismeetoditest, mille puhul kasutatakse Fibonacci jada modifitseeritud versiooni: 1, 2, 3, 5, 8, 13, 20, 40, 100. Toote tagavaraportfelli elementide hindamiseks saavad meeskonnaliikmed samad planeerimispokkeri kaardid, millel on numbrid. Seejärel valivad nad pärast toote omaniku (kes ei hääleta) poolt toote tagavaralogi punkti lühitutvustust ja arutelu eraviisiliselt välja kaardi, millel on nende arvates selle punkti täitmiseks vajaliku töömahu suhtes asjakohane loo punktide arv, ja paljastavad need korraga.
Kui arvud erinevad, arutavad meeskonnaliikmed, miks nad sellise arvu loosipunkte valisid, ja hääletavad seejärel uuesti. See on osa planeerimispokkeri protsessist, mis on konsensuspõhine hindamismeetod, mida kasutatakse Agile'is kasutajate lugude töömahu hindamiseks. Nad teevad seda seni, kuni jõuavad konsensusele, ja seejärel liiguvad edasi järgmise toote tagavaraprogrammi punkti juurde. Ja kui kokkulepitud arv on suur, ütleme 20, 40 või suurem, tähendab see, et lugu võib nõuda ühe sprindi jaoks liiga palju tööd ja seda võib olla vaja jagada väiksemateks ülesanneteks. Ideaalis peaks kirje tutvustamine, arutelu ja hääletamine kestma umbes kaks minutit, mis võimaldab kogu backlogi lühikese ajaga hinnata. Kuid kuna eesmärk on hinnata kogu backlogi korraga, võtke aega ja ärge muretsege, kui mõne loo hindamine võtab veidi kauem aega.
Meeskonna kiirus näitab, milline on projekti arengu tempo. See aitab mõista kahte asja:
- Millise töömahu suudab teie meeskond ühe sprindi jooksul ära teha.
- Milline on prognoositav kuupäev, millal kogu rakendusala lõpetatakse, eeldades, et see on fikseeritud.
Kiirus on iga meeskonna puhul erinev. Seda saab hinnata pärast esimesi iteratsioone, kui teie meeskond on juba töötanud mõne funktsiooni kallal. Näiteks kui te olete esimesse iteratsiooni lisanud neli tooteprotokolli punkti, mis teeb kokku 20 loo punkti, ja meeskond on neist kolm lõpetanud, mis teeb 15 loo punkti, siis on see teie meeskonna praegune kiirus (velocity). Pidage meeles, et arvesse lähevad ainult lõpetatud elemendid. Isegi kui nad oleksid suutnud alustada neljandat punkti, kuid ei ole seda lõpetanud, ei loe see.
Scrum master mängib olulist rolli hindamisprotsessi hõlbustamisel ja täpsete hinnangute tagamisel nende seansside ajal.
Pärast läbirääkimiste pidamist loo punktide üle ja meeskonna kiiruse hindamist saate määrata projekti ajakava. Selleks liita kokku meeskonna kiirus viimasest kolmest iteratsioonist ja jaga see kolmega. Näiteks kui nende iteratsioonide kiirus oli 20, 23 ja 17, siis keskmine kiirus oleks ligikaudu 20 punkti. Kui kogu töö maht oli hinnanguliselt 100 jutupunkti, siis keskmise kiiruse 20 punkti puhul kuluks projekti lõpuleviimiseks 5 iteratsiooni. Eeldades, et üks iteratsioon võtab aega kaks nädalat, peaksite projekti valmis saama 10 nädalaga.
Oma projekti eelarve määramiseks võite kasutada järgmist põhivalemit: (Story Points kokku / Velocity * meeskonnatunnid sprindi kohta) + mittetööjõukulud = hinnanguline eelarve. Kui teil on loo punktide koguarv jagatuna keskmise kiirusega, korrutage sprintide arv 40 tunniga nädalas meeskonnaliikme kohta, et saada tööjõukulud. Seejärel lisage mittetööjõukulud, nagu kapitalikulud, seadmete kulud, hoolduskulud, koolituskulud jne. Näiteks on meil projekti hinnanguline maht 100 jutupunkti ja meie meeskonna keskmine kiirus on 20. Määrates projektile 5-liikmelise meeskonna $50 tunnitasuga, on meeskonna tundide väärtus ühe sprindi kohta $20 000 ja 5 sprindi puhul $100 000. Kui hüpoteetiline mittetööjõukulu on $50,000, oleks meie projekti hinnanguline eelarve $150,000. Võttes arvesse usaldusvahemikke 80-120%, on meie eelarve teatatud vahemik nüüd $120,000 kuni $180,000.
Pidage meeles, et ükski hinnang ei ole 100% täpne. Parem on oma projekti iga paari iteratsiooni järel uuesti hinnata, sest asjad, nagu ressursside kättesaadavus, meeskonna kiirus või projekti ulatus, võivad aja jooksul muutuda. Uuesti hinnates veendute, et teie hinnang on ajakohane. Aja jälgimise ja ressursside planeerimise tarkvara kasutamine aitab teil ka juhtida oma meeskonna kättesaadavust ja vajadusel neid ümber paigutada. Õigete tehnikate ja tööriistade abil saate muuta oma hinnangud usaldusväärsemaks ja paremini planeerida oma järgmist projekti.
Täpne projektihindamine on eduka projektijuhtimise jaoks ülioluline. Kui mõistate ootusi ja eesmärke, koostate üksikasjaliku tooteprojekti, seate funktsioonid tähtsuse järjekorda ning kasutate selliseid tehnikaid nagu story points ja Planning Poker, saate parandada oma hinnangute täpsust. Regulaarne ümberhindamine ning aja jälgimise ja ressursside haldamise vahendite kasutamine suurendavad veelgi teie projekti ajakava ja eelarve usaldusväärsust. Neid tavasid järgides saate ületada ebatäpsetest hinnangutest tulenevad probleemid ja tagada paremad projektitulemused.
Kasutage hõlpsasti planeerimispokkeri hindamistehnikat
Vaata, miks meie ressursihaldustarkvara valivad projektijuhid Hill-Knowltonist või Stormind Gamesist
Tõhus ressursside planeerimine on oluline eesmärk igas suuruses ettevõtete jaoks, olenemata sellest, kas nad tegutsevad internetis või traditsioonilistes tööstusharudes. Arvestades, et ressursside planeerimist vajavad ettevõtted on väga erinevad, on keeruline anda kõigile sobivat soovitust...
Ettevõtted teevad tavaliselt palju jõupingutusi ressursside eraldamiseks. Te soovite, et kõik oleksid hõivatud, tagades samal ajal, et nende ülesanded on ettevõtte jaoks väärtuslikud (mis sageli tähendab, et need on tasulised). See muutub tõeliselt keeruliseks, kui teie meeskond...
Meeskonnad kogu maailmas seisavad oma meeskonna ajakava planeerimisel silmitsi sarnaste väljakutsetega. Projektiplaani koostamine on iseenesest keeruline ning selle ajakohasena hoidmine ja muudatustele reageerimine on veelgi...