Sissejuhatus

IT-maailmas on numbreid palju, kuid vähesed näitavad, kas loome päriselt äriväärtust. Müügitulu ja teisi finantsnumbreid on suhteliselt lihtne mõõta, aga märksa keerulisem on välja valida 3-5 mõõdikut, mis aitavad tegelikult IT meeskonna arengut juhtida.

Hästi valitud mõõdikukomplekt annab juhile tervikliku ülevaate meeskondade edenemisest ning võimaldab teha paremaid juhtimisotsuseid. Kui mõõdikud toetavad ärieesmärkide saavutamist ning aitavad jälgida meeskonna tõhusust, saab neid edukalt lisada ka OKR-idesse.

Selles artiklisarjas on välja toodud viis mõõdikut, mis on IT-maailmas populaarsed ja mis aitavad hinnata väärtuse loomise kiirust, protsessi tõhusust, kvaliteeti, lubaduste püsivust ja kliendirahulolu:

1. Läbivusaeg (Lead Time) – fookus kiirusel
2. Tsükliaeg (Cycle Time) – fookus kiirusel ja protsessi tõhususel
3. Veamäär toodangus (Production Bug Rate) – fookus kvaliteedil
4. Lubaduste täitmise määr (Planned vs Done Rate, Velocity, Throughput) – fookus planeerimisel ja läbilaskevõimel
5. Huvirühmade rahuloluindeks (Stakeholder NPS) – fookus rahulolul

Iga mõõdiku juures selgitan selle olemust, kasutegurit juhile, toon kasutamise näited, annan juhised kuidas alustada ja loetlen levinud juurutamise vead.

Lühidalt märgin ära ka teised tuntumad mõõdikud nagu WIP, DORA ja teenindusmõõdikud.

Eraldi peatükis on ülevaade negatiivse mõjuga mõõdikutest, mis näivad esmapilgul head, kuid tegelikult hakkavad soodustama mängurlust ja negatiivseid antimustreid.

Meeskonnad, kellel on oma töö hindamiseks lihtsad ja täpsed mõõdikud, on eelisseisus ning saavad oma arenguteekonda selgelt ja numbripõhiselt jälgida. Juhtide õige suhtumine määrab siinkohal palju – meeskonna mõõdikud on vestluse käivitajad ja arengumootori loomulik osa, mitte argument “piitsa” kasutamiseks.

Kohe tuleb mainida, et ühtset “kõigile sobivat” mõõdikukomplekti ei ole olemas. Erineva iseloomuga meeskonnad (tootearendus, infra/ops, kasutajatugi, platvorm, jm) vajavad erinevaid rõhuasetusi. Soovitatud mõõdikute loetelust tuleks välja valida need, mis päriselt sobivad sinu meeskonna töövooga. Teadlik valik on oluline, aga alati on ka hea eksperimenteerida ning juhul kui valitud mõõdik ei aita häid otsuseid teha, siis saab proovida järgmist.

Märkus: Kuna IT-valdkonnas on väga laialt kasutatav projektihaldustarkvara Jira (hinnanguline kasutusosakaal ca 60%), siis tuginevad selles artiklis toodud pildid ja juhendid peamiselt Jirale. Levinud projektihalduse tööriistad on ka Azure DevOps, Asana, Monday, Trello, Redmine, jpt.

5 mõõdikut, mida on kasulik kord kuus analüüsida

1. Läbivusaeg (Lead Time)

Alustame kõige populaarsemast IT mõõdikust – Lead Time’ist (nim. ka Time-to-Value, Idea-to-Production). Eesti keeles öeldakse kõnekeeles ka “aeg ideest tarneni” kuid enamasti kasutatakse inglisekeelset terminit.

Lead Time – mis see on?

See on aeg ideest või päringust kuni hetkeni, mil tulemus on kasutajale või kliendile kättesaadav. Oma olemuselt näitab see, kui kiiresti jõuab väärtus kliendini.

Meeskonna Lead Time on kõigi meeskonnas tehtud tööde Lead Time’i mediaan.

Miks see on juhile oluline?

• Peegeldab lubaduste pidamist ja turukiirust
• Annab nö ühise kella äri ja IT vahel (time-to-value)
• On otseses seoses töövooga: mida lühem on Lead Time, seda sagedamini näeme tulemusi

Näited

Kasutajatugi

Kliendi päring tehakse 1. märtsil, vastus/lahendus on olemas 20. märtsil.
Lead Time = 20 päeva.

Tootearendus

Arendussoov lisatakse Product Backlogi 1. märtsil, tarnitakse toodangusse 20. aprillil.
Lead Time = 51 päeva.

Tihti küsitakse, kuidas erinevad Time-to-Value ja teine väga populaarne mõiste Time-to-Market?  Üldiselt kasutatakse Time-to-Market mõistet pikemas ajaskaalas, hõlmates toote või suurema tooteosa turulejõudmise kiirust. Eesti keeles on levinud vaste “turuletoomise kiirus”.

Kuidas alustada ja mõõta?

Oluline on täpselt kokku leppida ja fikseerida Lead Time algus- ja lõppaja reegel. Kindlasti tuleb arvestada meeskonna töö iseloomu. Kui kasutajatoe korral eeldame, et kõik kliendilt saadetud küsimused saavad vastuse, siis tootearenduses on normaalne, kui kõik tootekuhja (Product Backlogi) lisatud tööd ei liigu edasi arendusse – osad jäävad teadlikult tegemata ja nende ooteaega me mõõta ei soovi.

Lead Time mõõdiku kasutuselevõtu sammud:

1. Fikseeri algus- ja lõppaja reegel: tootearenduses on algusaeg tavaliselt töö „Created“ staatus ja lõppaeg „Released“ staatus
2. Mõõda aega kalendripäevades
3. Segmenteeri ja erista omavahel tööliigid (viga, arendussoov, jm)
4. Leia moodus kuidas visuaalselt mõõdiku väärtuseid (sh mediaanväärtuseid) kuvada, filtreerides ajavahemikku
5. Vaata trendi kuude lõikes, nt viimase 3-6 kuu vaadet
6. Lisa mõõdik tiimi töölauale

Jiras sobib mõõdiku monitoorimiseks “Control Chart”.

Vaata ka Lisa: Juhendid Jiras

Levinud vead

🚨 Üks levinud apse selle mõõdiku kasutamisel on lõppaja vale märkimine – kas liiga vara või liiga hilja. Näiteks arendaja liigutab töö “Tehtud” staatusesse, aga tegelikult pole töö veel tarnitud ega kasutajani jõudnud. Sellisel juhul on Lead Time tegelikkusest lühem.

🚨 Või teistpidi – töö on küll täielikult valmis, aga ootab reliisi kokkupanemist. Sellisel juhul on Lead Time  tegelikkusest pikem.

🚨 Üks risk on ka võrrelda õunu ja apelsine, mis juhtub kui jätta ära segmenteerimine ja segada kõik tööliigid ühte hunnikusse. On kasulik ära otsustada, millise töö liigi Lead Time on oluline ja käsitleda mõõdikuna ainult seda. Tootearenduses on sageli mõõdetavaks tööliigiks uus arendussoov ehk funktsionaalsus/featuur.

2. Tsükliaeg (Cycle Time)

Kui me räägime Lead Time mõõdikust, siis ei saa kuidagi jätta rääkimata tema paarilisest – mõõdikust nimega Cycle Time. Eesti keeles on vasted “tsükliaeg” või “töötlemise aeg”.

Cycle Time – mis see on?

See on aeg hetkest, mil töö võetakse päriselt ette, kuni see on tiimi vaates valmis. Tsükliaeg mõõdab töö tegelikku töötlemisaega tiimi tööprotsessis.

Cycle Time on alamosa Lead Time mõõdikust ja ei sisalda ooteaegu enne ja pärast töö tegemist:

Lead Time = ooteajad enne + Cycle Time + ooteajad pärast.

Miks see on juhile oluline?

• Näitab ära töövoo reaalsed kitsaskohad
• Muudab prognoosimise realistlikumaks

Kumba kasutada – Lead Time vs Cycle Time?

• Vali Lead Time kui fookuses on kliendi ooteaeg, SLA-d, äri lubadused, time-to-value.
• Vali Cycle Time kui fookuses on tiimi sisene töövoog ja efektiivsus: kitsaskohad, valmimise prognoosimine, jmt.

Lihtne rusikareegel:

• Paranda Lead Time’i, kui tööd “ootavad” liiga pikalt enne Product Backlogis või pärast valmimist.
• Paranda Cycle Time’i, kui tööde tegemine venib ja nad on liiga pikalt  “On töös (In Progress)” staatuses.

Näited

Kasutajatugi

Kliendi päring 1. märtsil, lahendus on olemas 20. märtsil.
Lead Time = 20 päeva.
Töötaja alustab päringuga tööd 5. märtsil ja lõpetab 20. märtsil.
Cycle Time = 15  päeva.

Tootearendus

Arendussoov lisatakse Product Backlogi 1. märtsil, tarnitakse toodangusse 20. aprillil.
Lead Time = 51 päeva.
Tiim alustab tööga 25. märtsil, lõpetab töö ja viib “Done” staatusesse 10. Aprillil.
Cycle Time = 16 päeva.

Kuidas alustada ja mõõta?

Cycle Time mõõdiku kasutuselevõtmise protsess on peaaegu samasugune nagu Lead Time mõõdiku korral, ainult algus- ja lõppaeg defineeritakse erinevalt.

Cycle Time mõõdiku kasutuselevõtu sammud:

1. Fikseeri algus- ja lõppaja reegel: tootearenduses on algusaeg tavaliselt töö “In Progress“ staatus ja lõppaeg „Done“ staatus
2. Mõõda aega kalendripäevades
3. Segmenteeri ja erista omavahel tööliigid (viga, arendussoov, jm)
4. Leia moodus kuidas visuaalselt mõõdiku väärtuseid (sh mediaanväärtuseid) kuvada, filtreerides ajavahemikku
5. Vaata trendi kuude lõikes, nt viimase 3-6 kuu vaadet
6. Lisa mõõdik tiimi töölauale

Mis on “Done” ? “Done” staatuse sisuline tähendus sõltub siin tiimi kokkuleppest, see võib olla:

• täielikult valmis, mis ootab tarnimist toodangusse või
• on tarnitud toodangusse, aga pole veel kasutajatele nähtav (peidus feature flag-ide taga) või
• on tarnitud toodangusse  ja on kasutajatele nähtav (sama mis “Released”).

Jiras sobib mõõdiku monitoorimiseks “Control Chart”.

Vaata ka Lisa: Juhendid Jiras

Levinud vead

🚨 Levinud vead kattuvad suuresti Lead Time peatükis kirjeldatud vigadega. Suurim segadus tekib siis, kui Lead ja Cycle Time’i algus- ning lõppmomendid pole üheselt kokkulepitud. Leppige selgelt kokku, millal töö „algab“ (nt kui töö lisatakse sprinti) ja millal see on „Done“, ning hoia eraldi „Done“ ja „Released“ staatused. 

🚨 Tiimideülesed võrdlused ilma kontekstita on eksitavad: erinevate töövoogude ja staatuse definitsioonidega tiime ei ole mõistlik kõrvutada – usaldusväärsem on pigem jälgida trende tiimi sees. Kui staatuse definitsioonid on ühtsed ja töö iseloom sarnane, on mõõdikud ka tiimide vahel hästi võrreldavad.

Flow Efficiency (FE)

Praktikas on hea koos Lead ja Cycle Time mõõdikuga jälgida ka Flow Efficiency (FE) ehk voo tõhususe trendi. Nii näed, kas aeg kaob tegemise (Doing) faasis või eelkõige ootamiste tõttu.

Mis on Flow Efficiency?

Flow efficiency (FE) on aktiivse töö aja suhe koguaega, mis kulus selle töö valmimiseks. See on protsent, kui suur osa koguajast oli päriselt töö (mitte ootamine/blokeeritud olek).

Valem Flow Efficiency arvutamiseks on:

Flow Efficiency (%) = (Active Time / Lead Time) × 100

Või lihtsamalt: Töövoo efektiivsus (%) = (Aktiivne aeg / Koguaeg) x 100

Näiteks kui mingi töö FE on 10%, siis see tähendab, et 90% ajast oli see töö kas blokeeritud või ootel.

Üldistades võib öelda, et kui sinu tiimi keskmine FE on alla 40%, siis tuleks keskenduda  süsteemis ootamisaja vähendamisele. Seejuures tasub uurida ka üksikuid töid, mille FE % on väga madal (nt alla 20%) ja analüüsida ooteaja/blokeeringute põhjuseid.

Lead Time, Cycle Time ja Flow Efficiency moodustavad koos hea mõõdikute trio, mida ühiselt jälgida. 

Lisa: Juhendid Jiras

• Configure columns
• View and understand the control chart
• Methods of calculating rolling average on the control chart
• Track cycle time with the Control Chart
• View and understand the cumulative flow diagram 
• Create a custom report for your service project
• Configure custom dashboards
• Dashboard gadgets
• An effective dashboard for Service Desk and Customer Support teams in Jira Service Management

Lisa: Jira pluginad

• Performance Objectives> Kõik mõõdikute raportid koos õpetustega
• eazyBI
• ActionableAgile
• Timepiece
• Custom Charts for Jira
• Agile Reports and Gadgets
• Great Gadgets for Jira Cloud
• Customer Satisfaction Survey for Jira
• Smart Forms for Jira

Järgmine osa

Järgmine osa mõõdikute sarjas on “Kvaliteet ja võimekus: Production Bug Rate + Planned vs Done/Velocity/Throughput (2/3)”

Samal teemal