Epätarkat arviot ovat yksi suosituimmista projektinhallinnan haasteista. Kun aloitat uuden IT-projektin, haluat tietää kaksi asiaa: kuinka kauan se kestää ja kuinka paljon se maksaa. Jotta voit vastata näihin kysymyksiin, sinun on arvioitava tulevat projektit. Ei ole olemassa mitään maagista sääntöä, jonka mukaan projekti X kestää 12 viikkoa ja maksaa $150 000. Tai Y:n kaltaisen verkkosivuston kehittäminen vie 10 viikkoa ja maksaa $100 000.
Mitä opit tästä artikkelista:
- Miten projektipäälliköt valmistautuvat kustannusarviointiin projektinhallinnassa?
- Mitkä arviointitekniikat ovat hyödyllisiä projektin arvioinnissa?
- Miten suunnittelu vie aikaa valmistautua kustannusten arviointiin kaavojen avulla?
Et voi arvioida projektin aikataulua tai kustannuksia ilman perusteellista arviointia, vaikka projektin laajuus olisikin hyvin samankaltainen kuin aiemmin tekemäsi. Tilanne on kuitenkin vielä pahempi: arvioinnilla ei koskaan saada 100%-tarkkaa vastausta myöskään näihin kysymyksiin. Miksi siis teemme arvion? Koska se on ainoa tapa tehdä oletuksia projektin aikataulusta ja budjetista, työmäärästä ja sen toteuttamiseen tarvittavista resursseista.
Kun arvioit projektin, voit myös ajoittaa työntekijät, joilla on oikea kokemus ja taidot. Mitä voit tehdä asialle, on käyttää menetelmiä ja tekniikoita, joiden avulla voit arvioida mahdollisimman tarkasti. Tässä kerrotaan, miten voit käyttää ketterää menetelmää ja Planning Poker -tekniikkaa mielekkäiden arvioiden luomiseen projektistasi.
James Grenning kehitti vuonna 2002 strategiastaan tunnetun suunnittelupokeri-istunnon nimeltä Scrum-pokeri. 1950-luvun alussa hänen arviointimenetelmänsä, Wide band Delphi, oli liian aikaa vievä ja sillä oli muitakin rajoituksia. Grenningin tapauksessa suunnittelupokerissa oli alun perin kyse ongelman ratkaisemisesta, jossa pelaajat olivat liian innostuneita ja liian keskittyneitä voittaakseen. Mike Cohn, ketterien allianssien ja Scrum-allianssien perustaja, käytti myöhemmin tätä tekniikkaa artikkelissa Agile Estimation and Planning.
Onnistuneen projektin käynnistäminen riippuu pääasiassa siitä, miten hyvin ymmärrät, mistä on kyse. Tähän sisältyy:
- Asiakkaan odotusten ymmärtäminen
- Hankkeen tavoitteiden ja päätavoitteen ymmärtäminen.
- Luettelon laatiminen vaadituista ominaisuuksista
Kun olet käynyt läpi asiakkaan tehtävänkuvauksen ja saanut mahdollisimman paljon tietoa projektin vaatimuksista, voit luetella kaikki ominaisuudet ja välittää ne tiimillesi.
Luo tätä varten tuotteen backlog, joka koostuu kaikista tehtävistä ominaisuuksista. Sen jälkeen voit asettaa ne tärkeysjärjestykseen, arvioida niiden monimutkaisuutta ja arvioida, kuinka kauan niiden valmistuminen kestää. Kunnollisen tuotetakaiskatalogin tulisi koostua seuraavista osista:
- Käyttäjätarinat - kuvaavat toimet, joita käyttäjät voivat tehdä tuotteen käytön jokaisessa vaiheessa.
- Hyväksymiskriteerit - luettelo asioista, joita tarvitaan, jotta tarina voidaan saattaa loppuun.
- Tarinapisteet - arvioi työn, riskien ja monimutkaisuuden määrä suhteellisella pistearvolla.
- Käyttäjätarinoiden tehtävät - luetellaan tehtävät, jotka on tehtävä käyttäjätarinan toteuttamiseksi.
Kehitystiimi on ehdottomasti otettava mukaan tuotekehitystyöryhmän luomiseen ja priorisointiin, jotta voidaan varmistaa tarkat ja realistiset arviot.
Kun luettelo ominaisuuksista on valmis, aseta ne tärkeysjärjestykseen. Voit käyttää MoSCoW-analyysimenetelmää lajitellaksesi ne seuraavasti:
- Täytyy olla
- Pitäisi olla
- Olisi voinut
- Ei ole
Keskity projektin kehittämisessä asioihin, jotka sinun on ensisijaisesti toimitettava. MVP:n rakentaminen antaa sinulle mahdollisuuden testata hypoteeseja ideastasi ennen koko projektin loppuunsaattamista, esitellä sitä sidosryhmille tai beta-käyttäjille ja kerätä palautetta, joka on tärkeää muiden ominaisuuksien jatkokehitystä varten.
Tärkeysjärjestyksen määrittäminen voi auttaa myös projektin arvioinnissa. Kun keskityt tärkeimpiin ominaisuuksiin ja niihin, jotka on tehtävä ensin, voit tehdä tarkempia oletuksia niiden arvioidusta valmistumisesta. "Mahdollisten" ominaisuuksien osalta voit aloittaa arvioinnin suuntaa-antavalla arviolla, sillä ne ovat pidemmällä kehitysprosessissa, ja monet asiat voivat muuttua siihen mennessä, kun tiimisi pääsee niihin käsiksi (ja jos tiimisi pääsee niihin käsiksi, sillä kerättyään palautetta MVP:stäsi voit kääntyä ja olla sisällyttämättä kaikkia alun perin suunniteltuja toimintoja).
On kuitenkin tärkeää arvioida kaikki ominaisuudet niiden tärkeysjärjestyksestä riippumatta (lukuun ottamatta tietysti niitä, joita ei ole), koska haluat saada kerralla yleiskuvan koko hankkeesta. Kun siirryt projektin seuraaviin vaiheisiin, voit arvioida työn laajuutta uudelleen varmistaaksesi, että arviosi pysyvät oikeina.
Nyt kun olet saanut tuotetietokantasi valmiiksi, on aika arvioida jokainen sen kohde. Tätä varten käytämme tarinapisteitä. Ne ovat yksiköitä, joita ketterät tiimit käyttävät arvioidessaan kunkin backlogin kohteen valmistumiseen tarvittavaa työtä. Tarinapisteiden avulla voidaan määrittää suhteellinen arvo tuotteen backlog-kohteille. Ne eivät liity aikaan, ja niillä voi olla eri tiimeille eri arvo, joten niillä ei ole tunnearvoa. Näin ollen on todennäköistä, että tiimin jäsenet eivät varmuuden vuoksi pehmennä arvioita. Planning Poker auttaa ohjelmistotiimejä suunnittelemaan työnkulkuja ja parantamaan projektin toimitusnopeutta.
Tarinapisteiden avulla tiimi voi arvioida:
Suunnitteluistunto on yksi bruttotason estimointitekniikoista, jossa käytetään muunnettua versiota Fibonaccin sekvenssistä: 1, 2, 3, 5, 8, 13, 20, 40, 100. Arvioidakseen tuotteen backlogin kohteita tiimin jäsenet saavat samat suunnittelupokerikorttisarjat, joissa on numeroita. Sitten kun tuoteomistaja (joka ei äänestä) on esitellyt lyhyesti tuotteen backlog-kohdan ja keskustelun jälkeen he valitsevat yksityisesti kortin, jossa on niiden mielestä kyseisen kohdan loppuunsaattamiseen vaadittavan työmäärän kannalta merkityksellinen määrä tarinapisteitä, ja paljastavat ne samanaikaisesti.
Jos luvut eroavat toisistaan, ryhmän jäsenet keskustelevat siitä, miksi he ovat valinneet juuri tietyn määrän tarinapisteitä, ja äänestävät sitten uudelleen. Tämä on osa suunnittelupokeri-prosessia, joka on konsensukseen perustuva arviointimenetelmä, jota käytetään ketterässä ohjelmassa käyttäjätarinoiden työmäärän arvioimiseksi. He tekevät näin, kunnes pääsevät yhteisymmärrykseen, ja siirtyvät sitten seuraavaan kohtaan tuotesuorituslistalta. Ja jos sovittu luku on korkea, vaikkapa 20, 40 tai suurempi, se tarkoittaa, että tarina saattaa vaatia liikaa työtä yhdelle sprintille ja se on ehkä pilkottava pienempiin tehtäviin. Ihannetapauksessa kohteen esittelyn, keskustelun ja äänestyksen pitäisi kestää noin kaksi minuuttia, jolloin koko backlog voidaan arvioida lyhyessä ajassa. Koska tarkoituksena on kuitenkin arvioida koko backlog kerralla, ota aikaa, äläkä ole huolissasi siitä, että joidenkin tarinoiden arvioiminen kestää hieman kauemmin.
Tiimin nopeus kertoo, mikä on projektin kehitysvauhti. Se auttaa ymmärtämään kaksi asiaa:
- Kuinka paljon työtä tiimisi pystyy tekemään yhdessä sprintissä.
- Mikä on koko soveltamisalan valmistumisen arvioitu päivämäärä, olettaen, että se on korjattu?
Nopeus on erilainen jokaisessa joukkueessa. Voit arvioida sitä ensimmäisten iteraatioiden jälkeen, kun tiimisi on jo työstänyt joitakin ominaisuuksia. Jos olet esimerkiksi sisällyttänyt ensimmäiseen iteraatioon neljä Product Backlog -kohtaa, joiden kokonaismäärä on 20 tarinapistettä, ja tiimi on saanut valmiiksi kolme niistä, mikä vastaa 15 tarinapistettä, tämä on tiimisi nykyinen nopeus. Muista, että vain valmiit kohteet lasketaan. Vaikka tiimi olisi onnistunut aloittamaan neljännen kohdan, mutta ei ole saanut sitä valmiiksi, sitä ei lasketa.
Scrum masterilla on ratkaiseva rooli arviointiprosessin helpottamisessa ja tarkkojen arvioiden varmistamisessa näiden istuntojen aikana.
Kun olet neuvotellut tarinapisteistä ja arvioinut tiimin nopeuden, voit määrittää projektin aikataulun. Laske yhteen tiimin nopeus kolmelta viimeiseltä iteraatiokierrokselta ja jaa se kolmella. Jos esimerkiksi näiden iteraatioiden nopeus oli 20, 23 ja 17, keskimääräinen nopeus on noin 20 pistettä. Jos työn kokonaismääräksi on arvioitu 100 tarinapistettä, projektin loppuunsaattaminen kestäisi 20 pisteen keskimääräisellä nopeudella viisi iteraatiota. Jos oletetaan, että yksi iteraatio kestää kaksi viikkoa, projektin pitäisi valmistua 10 viikossa.
Voit määrittää hankkeesi budjetin tämän peruskaavan avulla: (tarinapisteiden kokonaismäärä / nopeus * tiimin työtunnit sprinttiä kohti) + muut kuin työkustannukset = arvioitu budjetti. Kun olet saanut tarinapisteiden kokonaismäärän jaettuna keskimääräisellä nopeudella, kerro sprinttien määrä 40 viikkotunnilla tiimin jäsentä kohti, niin saat työvoimakustannukset. Lisää sitten muut kuin työvoimakustannukset, kuten pääomakustannukset, laitekustannukset, ylläpitokustannukset, koulutuskustannukset jne. Esimerkki: projektin kestoksi on arvioitu 100 tarinapistettä, ja tiimimme keskimääräinen nopeus on 20. Jos projektiin nimetään 5 hengen tiimi, jonka tuntihinta on $50, tiimin työtunnit sprinttiä kohti ovat $20 000 ja $100 000 viiden sprintin osalta. Kun hypoteettiset muut kuin työvoimakustannukset ovat $50 000, projektin arvioitu budjetti on $150 000. Kun otetaan huomioon esimerkkitasojen luottamusvälit 80-120%, budjettimme ilmoitettu vaihteluväli on nyt $120 000-$180 000.
Muista, että mikään arvio ei ole 100% tarkka. On parasta arvioida projekti uudelleen muutaman iteraation välein, sillä resurssien saatavuus, tiimin nopeus tai projektin laajuus voivat muuttua ajan myötä. Arvioimalla uudelleen varmistat, että arviosi on ajan tasalla. Ajanseuranta- ja resurssien aikataulutusohjelmiston käyttö auttaa sinua myös hallitsemaan tiimisi saatavuutta ja jakamaan heidät tarvittaessa uudelleen. Oikeiden tekniikoiden ja työkalujen avulla voit tehdä arvioistasi luotettavampia ja suunnitella seuraavaa projektiasi paremmin.
Tarkka hankearviointi on ratkaisevan tärkeää onnistuneen projektinhallinnan kannalta. Ymmärtämällä odotukset ja tavoitteet, luomalla yksityiskohtaisen tuotetiedoston, priorisoimalla ominaisuudet ja käyttämällä tekniikoita, kuten tarinapisteitä ja Planning Pokeria, voit parantaa arvioiden tarkkuutta. Säännöllinen uudelleenarviointi sekä ajanseuranta- ja resurssienhallintatyökalujen käyttö lisäävät entisestään projektin aikataulujen ja budjettien luotettavuutta. Näitä käytäntöjä noudattamalla voit voittaa epätarkkojen arvioiden haasteet ja varmistaa paremmat projektitulokset.
Käytä suunnittelupokerin arviointitekniikkaa helposti
Tarkista, miksi Hill-Knowltonin tai Stormind Gamesin projektipäälliköt valitsevat resurssienhallintaohjelmistomme.
Resurssikalenterin (tai projektinhallintakalenterin, projektisuunnittelukalenterin, resurssisuunnitteluohjelmiston) avulla voit suunnitella, hallita ja jakaa resursseja tehokkaammin ja tuloksellisemmin - varsinkin jos Microsoft Excelillä oli johtava rooli...
Mikä on projektipäälliköiden perimmäinen tavoite? Toimittaa projektinsa menestyksekkäästi. PM:t itse myöntävät, että näin ei tapahdu kovin usein: viimeisimmän Pulse of the Profession -tutkimuksen mukaan alle 60% projekteista saadaan päätökseen joko...
Kapasiteetinhallinta on strategia, jolla yritykset pyrkivät hyödyntämään tuotannon tehokkuutta parhaalla mahdollisella tavalla suhteessa palvelun tai tuotteen kysyntään. Kapasiteetinhallinnan lopullisena tavoitteena on: Tunnistaa ja...