Netikslios sąmatos yra viena populiariausių projektų valdymo problemų. Pradėdami naują IT projektą norite žinoti du dalykus: kiek laiko jis užtruks ir kiek kainuos. Norėdami atsakyti į šiuos klausimus, turite įvertinti ketinamus vykdyti projektus. Nėra stebuklingos taisyklės, kuri sakytų, kad projektas X trunka 12 savaičių ir kainuoja $150 000. Arba į Y panašią svetainę reikia sukurti per 10 savaičių ir ji kainuoja $100 000.
Ką sužinosite iš šio straipsnio:
- Kaip projektų vadovai pasiruošia sąnaudų vertinimui projektų valdyme?
- Kokie vertinimo metodai yra naudingi projekto vertinimui?
- Kaip planuojant reikia pasiruošti įvertinti išlaidas pagal formules?
Negalite įvertinti projekto terminų ar sąnaudų be išsamaus įvertinimo, net jei projekto apimtis yra labai panaši į anksčiau atliktų darbų. Tačiau viskas dar blogiau: įvertinimas niekada nepateiks 100% tikslaus atsakymo ir į šiuos klausimus. Taigi, kodėl mes vertiname? Nes tai vienintelis būdas daryti prielaidas apie projekto terminus ir biudžetą, darbo krūvį ir jam įgyvendinti reikalingus išteklius.
Įvertinę projekto sąmatą, taip pat galėsite suplanuoti reikiamos patirties ir įgūdžių turinčius darbuotojus. Tai, ką galite padaryti, tai naudoti metodikas ir būdus, kurie leis jums įvertinti maksimaliai tiksliai. Štai kaip naudoti "Agile" metodologiją ir planavimo pokerio techniką, kad sukurtumėte prasmingus projekto įverčius.
2002 m. Jamesas Grenningas sukūrė planavimo pokerio sesiją, žinomą dėl savo strategijos, pavadintos "Scrum poker". Šeštojo dešimtmečio pradžioje jo taikytas vertinimo metodas "Wide band Delphi" užėmė per daug laiko ir turėjo kitų apribojimų. Grenningo atveju pokerio planas iš pradžių buvo skirtas problemai spręsti, kai žaidėjai buvo pernelyg entuziastingi ir pernelyg susitelkę, kad laimėtų. Mike'as Cohnas, "Agile alliances" ir "Scrum alliances" įkūrėjas, vėliau panaudojo šį metodą straipsnyje "Agile Estimation and Planning".
Sėkmingo projekto pradžia labiausiai priklauso nuo to, kaip gerai suprantate, apie ką iš tikrųjų kalbama. Tai apima:
- Kliento lūkesčių supratimas
- Projekto tikslų ir pagrindinio tikslo supratimas
- Reikalingų funkcijų sąrašo sudarymas
Išnagrinėję kliento santrauką ir turėdami kuo daugiau informacijos apie projekto reikalavimus, galite išvardyti visas funkcijas ir perduoti jas savo komandai.
Norėdami tai padaryti, sukurkite produkto atsilikimo sąrašą, kurį sudaro visos privalomos atlikti funkcijos. Tada galėsite nustatyti jų prioritetus, įvertinti jų sudėtingumą ir apskaičiuoti, kiek laiko prireiks joms atlikti. Tinkamą produkto atsilikimo sąrašą turėtų sudaryti:
- Vartotojo istorijos - aprašykite veiksmus, kuriuos vartotojai gali atlikti kiekviename produkto naudojimo etape.
- Priėmimo kriterijai - išvardykite elementus, kurių reikia, kad istorija būtų užbaigta.
- Istorijos taškai - įvertinkite darbo kiekį, riziką ir sudėtingumą santykine taškų verte.
- Vartotojo istorijų užduotys - išvardykite užduotis, kurias reikia atlikti, kad naudotojo istorija būtų įgyvendinta.
Labai svarbu, kad kuriant ir nustatant prioritetus būtų įtraukta kūrimo komanda, kad būtų užtikrintas tikslus ir realus įvertinimas.
Parengę funkcijų sąrašą, kiekvienai iš jų suteikite prioritetą. Galite naudoti MoSCoW analizės metodą, kad jas surūšiuotumėte taip:
- Turi būti
- Turėtų būti
- Galėjo
- Neturės
Kurdami projektą, daugiausia dėmesio skirkite dalykams, kuriuos pirmiausia turite pristatyti. Kurdami MVP galite patikrinti savo idėjos hipotezes prieš užbaigdami visą projektą, parodyti ją suinteresuotosioms šalims arba beta naudotojams ir surinkti grįžtamąjį ryšį, svarbų tolesniam likusių funkcijų kūrimui.
Prioritetų priskyrimas taip pat gali padėti įvertinti projektą. Sutelkę dėmesį į pagrindines funkcijas ir tas, kurias reikia atlikti pirmiausia, galėsite tiksliau numatyti numatomą jų užbaigimą. "Galėtų būti" funkcijų atveju galite pradėti nuo apytikslio įverčio, nes jos yra tolimesnėje kūrimo proceso stadijoje ir daug kas gali pasikeisti, kol jūsų komanda jas pradės kurti (ir jei komanda jas pradės kurti, nes, surinkę atsiliepimus apie jūsų MVP, galite pakeisti ir neįtraukti visų iš pradžių planuotų funkcijų).
Tačiau svarbu įvertinti visas funkcijas, nepriklausomai nuo jų prioriteto (žinoma, išskyrus tas, kurių "nebus"), nes norite iš karto apžvelgti visą projektą. Pereidami į kitus projekto etapus, galite iš naujo įvertinti darbų apimtį, kad įsitikintumėte, jog jūsų įverčiai išlieka tikslūs.
Dabar, kai jau turite užbaigtą produkto atsilikimo sąrašą, laikas įvertinti kiekvieną jo elementą. Tam naudojame istorijos taškus. Tai vienetai, kuriuos "Agile" komandos naudoja, kad įvertintų darbą, kurio reikia kiekvienam "backlog" elementui užbaigti. Istorijos taškai padeda priskirti santykinę vertę produkto atgalinio sąrašo elementams. Jie nesusiję su laiku ir skirtingoms komandoms gali turėti skirtingą vertę, todėl jie neturi emocinės vertės. Taigi yra tikimybė, kad komandos nariai nepadidins sąmatų vien dėl saugumo. Planavimo pokeris padeda programinės įrangos komandoms planuoti darbo eigą ir pagerinti projekto įgyvendinimo spartą.
Naudodama istorijos taškus komanda gali įvertinti:
Planavimo sesija - tai vienas iš bendrojo lygio vertinimo metodų, kuriame naudojama modifikuota Fibonačio sekos versija: 1, 2, 3, 5, 8, 13, 20, 40, 100. Kad įvertintų gaminio sąrašo elementus, komandos nariai gauna tuos pačius planavimo pokerio kortelių su skaičiais rinkinius. Tada, produkto savininkui (kuris nebalsuoja) trumpai pristačius produkto atsilikimo sąrašo elementą ir pradėjus diskusiją, jie privačiai išsirenka kortelę su tokiu istorijos taškų skaičiumi, kuris, jų nuomone, yra susijęs su šiam elementui užbaigti reikalingų darbų kiekiu, ir tuo pačiu metu jas atskleidžia.
Jei skaičiai skiriasi, komandos nariai aptaria, kodėl jie pasirinko tokį istorijos taškų skaičių, ir vėl balsuoja. Tai yra planavimo pokerio proceso dalis - bendru sutarimu grindžiamo vertinimo metodo, naudojamo "Agile" metodikoje siekiant įvertinti naudotojo istorijų pastangas. Taip jie daro tol, kol pasiekia bendrą sutarimą, ir tada pereina prie kito produkto darbų sąrašo elemento. Ir jei sutartas skaičius yra didelis, tarkime, 20, 40 ar daugiau, tai reiškia, kad istorijai gali prireikti per daug darbo vienam sprintui ir ją gali tekti išskaidyti į mažesnes užduotis. Idealiu atveju elemento pristatymas, diskusija ir balsavimas turėtų užtrukti apie dvi minutes, todėl per trumpą laiką galima įvertinti visą atsilikimą. Tačiau kadangi čia siekiama įvertinti visą atsilikimą iš karto, neskubėkite ir nesijaudinkite, jei kai kurioms istorijoms įvertinti prireiks šiek tiek daugiau laiko.
Komandos greitis rodo, koks yra projekto vystymo tempas. Jis padeda suprasti du dalykus:
- Kiek darbo jūsų komanda gali atlikti per vieną sprintą
- Kokia numatoma visos apimties užbaigimo data, darant prielaidą, kad ji yra fiksuota
Kiekvienos komandos greitis yra skirtingas. Jį galite įvertinti po pirmųjų iteracijų, kai jūsų komanda jau dirba su kai kuriomis funkcijomis. Pavyzdžiui, jei į pirmąją iteraciją įtraukėte keturis produkto atgalinio sąrašo elementus, kurių bendras skaičius yra 20 istorijos punktų, o komanda baigė tris iš jų, kas sudaro 15 istorijos punktų, tai yra dabartinis jūsų komandos greitis. Atminkite, kad skaičiuojami tik užbaigti elementai. Net jei pavyko pradėti ketvirtąjį elementą, bet jo nebaigti, jis neskaičiuojamas.
"Scrum" meistras atlieka svarbų vaidmenį palengvinant vertinimo procesą ir užtikrinant tikslius vertinimus per šias sesijas.
Suderinus istorijos taškus ir įvertinus komandos greitį, galima nustatyti projekto tvarkaraštį. Norėdami tai padaryti, susumuokite trijų paskutinių iteracijų komandos greitį ir padalykite jį iš trijų. Pavyzdžiui, jei šių iteracijų greitis buvo 20, 23 ir 17, vidutinis greitis būtų lygus maždaug 20 taškų. Jei buvo apskaičiuota, kad bendra darbų apimtis yra 100 istorijos taškų, tai, esant vidutiniam greičiui 20 taškų, projektui užbaigti prireiktų 5 iteracijų. Darant prielaidą, kad viena iteracija trunka dvi savaites, projektą turėtumėte įgyvendinti per 10 savaičių.
Projekto biudžetui nustatyti galite naudoti šią pagrindinę formulę: (bendras istorijos taškų skaičius / greitis * komandos valandos per sprintą) + su darbu nesusijusios išlaidos = numatomas biudžetas. Turėdami bendrą istorijos taškų skaičių, padalytą iš vidutinio greičio, padauginkite sprintų skaičių iš 40 valandų per savaitę vienam komandos nariui, kad gautumėte darbo sąnaudas. Tada pridėkite su darbu nesusijusias išlaidas, pavyzdžiui, kapitalo, įrangos, techninės priežiūros, mokymo išlaidas ir t. t. Pavyzdžiui, turime projektą, kurio vertė yra 100 istorijos taškų, o vidutinis komandos greitis yra 20. Projektui priskyrus 5 žmonių komandą su $50 valandiniais įkainiais, komandos valandos per sprintą kainuoja $20 000, o per 5 sprintus - $100 000. Su hipotetinėmis $50 000 ne darbo sąnaudomis numatomas mūsų projekto biudžetas būtų $150 000. Atsižvelgiant į 80-120% pavyzdinių lygių pasikliautinuosius intervalus, nurodytas mūsų biudžeto intervalas dabar yra nuo $120 000 iki $180 000.
Atminkite, kad joks įvertinimas nėra 100% tikslus. Geriausia kas kelias iteracijas iš naujo įvertinti projektą, nes laikui bėgant gali pasikeisti tokie dalykai kaip išteklių prieinamumas, komandos greitis ar projekto apimtis. Pakartotinai vertindami įsitikinate, kad jūsų sąmata yra aktuali. Naudodami laiko stebėjimo ir išteklių planavimo programinę įrangą taip pat galėsite valdyti savo komandos užimtumą ir prireikus juos perskirstyti. Naudodami tinkamus metodus ir priemones, galite padidinti savo sąmatų patikimumą ir geriau suplanuoti kitą projektą.
Sėkmingam projekto valdymui labai svarbus tikslus projekto įvertinimas. Suprasdami lūkesčius ir tikslus, sukurdami išsamų produkto darbų sąrašą, nustatydami funkcijų prioritetus ir naudodami tokius metodus kaip istorijos taškai ir planavimo pokeris, galite padidinti savo sąmatų tikslumą. Reguliarus pakartotinis vertinimas ir laiko stebėjimo bei išteklių valdymo priemonių naudojimas dar labiau padidina projekto terminų ir biudžetų patikimumą. Laikydamiesi šios praktikos, galite įveikti netikslių sąmatų keliamas problemas ir užtikrinti geresnius projekto rezultatus.
Lengvai naudokite planavimo pokerio vertinimo metodą
Sužinokite, kodėl mūsų išteklių valdymo programinę įrangą renkasi "Hill-Knowlton" ar "Stormind Games" projektų vadovai.
Veiksmingas išteklių planavimas yra labai svarbus tikslas bet kokio dydžio įmonėms, nesvarbu, ar jos veikia internete, ar tradicinėse pramonės šakose. Atsižvelgiant į didelę įmonių, kurioms reikia planuoti išteklius, įvairovę, sudėtinga pateikti universalią rekomendaciją...
Įmonės paprastai deda daug pastangų išteklių paskirstymui. Norite, kad visi būtų užimti ir kartu užtikrintumėte, kad jų užduotys būtų vertingos (o tai dažnai reiškia, kad už jas galima atsiskaityti) įmonei. Tai tampa labai sudėtinga, nes jūsų komanda...
Komandos visame pasaulyje susiduria su panašiais iššūkiais planuodamos savo komandos tvarkaraštį. Sukurti projekto planą yra sudėtinga savaime, o jį atnaujinti ir reaguoti į pokyčius - dar sunkiau...