5.2 Priorisointi, sitoutuminen ja kehitysjonot

Nykypäivän markkinatilanteessa liiketoimintapalvelujen ja -ratkaisujen kehittäminen on kilpailun kannalta merkittävä tekijä. Organisaatiot vastaanottavat jatkuvasti pyyntöjä päivittää ja parantaa bisnesteknologiaomaisuuttaan tai käyttöönottaa uusia kyvykkyyksiä tai teknologioita, joita tarvitaan yrityksen vision ja strategian onnistuneeseen toteuttamiseen.

Tämän osalta bisnesteknologiatoiminnon yleinen haaste on löytää oikea tapa hallita ja priorisoida jatkuvaa kehityspyyntöjen virtaa kevyimmällä mahdollisella hallintamallilla. Tavoitteena on lyhentää tarpeesta palveluksi -kehitysaikaa ja huolehtia samalla alhaisemman prioriteetin kehityspyynnöistä.

Kehityspyyntöjen arviointi

Priorisointi- ja sitoutumisprosessi luo päätöksentekomallin kehitysputkessa oleville kehitysaloitteille. Kehityspyynnöt, joista ei voida päättää kehitysputkessa, viedään salkunhallinnan ohjausprosessiin ja tarpeellisten sirodsryhmien käsittelyyn.

Kuva 5.2.1 Priorisointi- ja sitoutumisprosessi

Kuten kappaleessa 2.6 Kehityssalkku on kerrottu, tarve- ja kehityssalkunhallinta tarjoaa säännöt ja ohjeet, jotka auttavat tunnistamaan, voidaanko kehityspyyntö käsitellä kehitysputkessa vai pitääkö se viedä ylemmän tason tarkasteluun ja hyväksymismenettelyyn.

Seuraavat arviointikriteerit määrittävät, voidaanko kehittämisputken sisäistä hyväksymismenettelyä käyttää:

1. Sponsorointi: Onko kehityspyynnölle liiketoiminnan tai arvovirran omistajan hyväksyntä?
2. Rahoitus: Onko omistajalla rahoitus/budjetti kehittämiselle?
3. Resurssit: Onko omistajalla käytössä resurssitiimi pyynnön toteuttamiseen?
4. Arkkitehtuuri: Onko pyyntö linjassa kokonaisarkkitehtuurin kanssa?
5. Tietoturva: Noudattaako pyyntö tietoturvasääntöjä ja -ohjeistuksia?
6. Toimittajat: Käytetäänkö sopimustoimittajia ja -kumppaneita?
7. Prosessit: Noudattaako projekti vakioituja ja olemassa olevia kehitysprosesseja?

Jos vastaus on myöntävä kaikkien näiden seitsemän kriteerin kohdalla, pyyntö voidaan käsitellä kehitysputken hyväksymismenettelyssä. Siinä tapauksessa kehitystiimi lisää pyynnön kehitysjonoon ja huolehtii pyynnön jatkokäsittelystä.

Hyväksymisarviointi voi myös edellyttää muiden tahojen hyväksyntää. Esimerkiksi jos hyväksyntää ei voida tehdä ensimmäisellä käsittelytasolla, arviointi voidaan viedä seuraavalle hierarkiatasolle, kunnes se saa hyväksynnän tai kunnes se nousee salkkutasolle asti. Alimman tason itsearvioinnin tekee tyypillisesti palvelupäällikkö tai tuoteomistaja. Seuraavan tason arvioinnin tekee palveluomistaja tai arvovirran omistaja ennen kuin se mahdollisesti viedään salkkutasolle.

Kehityspyyntöjen hallinta salkkutasolla

Kun kehityspyyntöä ei voida hyväksyä kehitysputken päätöksellä, tulee se viedä salkunhallinnan päätöksentekoon, jossa tehdään seuraavat toimenpiteet:

• arvioidaan pyynnön tarkoituksenmukaisuus ja toteutuskelpoisuus sekä riskit
• määritellään pyynnön prioriteetti
• arvioidaan pyynnön prioriteetti suhteessa muihin
• autetaan löytämään rahoitus ja tarvittavat resurssit.

Kun salkunhallinnan ohjausryhmä hyväksyy kehityspyynnön ja on tyytyväinen sitä koskeviin seikkoihin, voi se edetä kehitysvaiheeseen, missä kehityspyyntö toteutetaan joko projektoidun tai jatkuvan kehityskulun menetelmiä käyttämällä:

• Projektoitu kehittäminen olettaa, että käytössä on projektisuunnitelma ja eri vaiheiden roolit ja vastuut on määritelty ja nimetty.
• Jatkuva kehittäminen tarvitsee kehitysaihiot (epics), ominaisuudet ja tarinat lisättäväksi kehitysjonoon.

Kehityspyyntöjen priorisointi

Kehityspyynnöt priorisoidaan ja käsitellään kehitysputken käyttämän menetelmän ja menettelyn mukaisesti.

Priorisointi projektoidussa kehityskulussa

Projektoidun kehityskulun menetelmää käytettäessä jaetut resurssit varataan kehittämiseen tietylle ajanjaksolle. Priorisointi on moniulotteinen päätös, joka vaatii huolellisesti mietityn tasapainon seuraavien kolmen näkökulman osalta:

• Liiketoimintahyöty ja -vaikutus: Mietitään projektin vaikutusta strategisiin tavoitteisiin, mahdollisuuksia uusien tulojen hankintaan, kilpailuetua jne. Yleisesti käytössä oleva menetelmä liiketoimintahyödyn laskemiseen on määritellä nykyarvo (eng. Net Present Value, NPV), jonka laskenta perustuu tuleviin kassavirtoihin (sisään ja ulos) ja niihin liittyviin riskeihin.
• Viiveestä johtuvat kustannukset: Tapa jakaa ja ymmärtää ajan merkitys suhteessa ennustettuihin tuloihin. Se tarjoaa keinot laskea ja verrata kustannuksia tilanteessa, jossa kehityspyynnön toteutusta lykätään. Yleisesti käytetty tapa maksimoida tuotettu hyöty tietyn aikarajan sisällä on määritellä viiveen kustannus jaettuna kestolla (eng. CD3 score).
• Nykytilaan liittyvät riskit ja määräystenmukaisuus: Otetaan huomioon organisaatiolle koituva riski, jos nykytilaa jatketaan. Tähän liittyy olemassa olevien ratkaisujen ja niiden tuen nykyinen elinikä sekä määräystenmukaisuus. Yleisesti käytetty tapa riskien arviointiin on käyttää 5×5 riskimatriisia, jossa todennäköisyys ja vaikutus muodostavat 2 ulottuvuutta asteikolla pieni – erittäin suuri.

Kehitystoimisto (eng. Development Management Office, DMO) johtaa yllä olevien näkökulmien tarkastelua, ja projektin omistajat tarjoavat arviointiin tarvittavat tiedot. Salkunhallinnan ohjausryhmä tekee tarvittaessa myös oman arvionsa, jotta varmistetaan yhdenmukaiset priorisointikriteerit kaikille aloitteille.

Priorisointi jatkuvassa kehityskulussa

Jatkuvan kehityskulun menetelmää käytettäessä pyyntöjen kehitysjonoa hallinnoi tiettyyn kehitysvirtaan osoitettu tiimi. Tiimin täytyy hallita uusia tulevia pyyntöjä ja priorisoida kehitysjonoa samaan aikaan kun se julkaisee jatkuvasti uusien kehityssprinttien tuotoksia tuotantoon.

Ennalta määritetyissä työpajoissa (esim. SAFen mukaisissa PI-suunnittelusessioissa) tiimit, yhdessä sidosryhmien kanssa, jakavat jokaisen pyynnön osakokonaisuuksiin ja työstävät niistä pienempiä kehitysversioita (ominaisuudet, tarinat), joita voidaan viedä tuotantoon peräkkäin. Tiimit myös arvioivat eri kehitysosia ja priorisoivat niitä yhdessä sidosryhmien kanssa. Priorisointikriteereitä ovat muun muassa seuraavat:

• Tarkoituksenmukaisuus ja toteutuskelpoisuus sisältäen arvion jokaisen ominaisuuden kehittämisen kestosta teknisestä näkökulmasta. Tähän keskusteluun osallistuvat tiimin tekniset jäsenet ja teknologiakumppanit.
• Haluttavuus koostuu loppukäyttäjien tarpeiden analyysistä ja prioriteeteistä. Keskusteluun osallistuvat tuoteomistajat, käyttöliittymäsuunnittelijat ja strategiasta vastaavat henkilöt.
• Kannattavuus perustuen erilaisten projektia koskevien rajoitteiden, kuten rahoituksen, ajan, säädösten ja riippuvuuksien, analysointiin.

Tämän työn tuloksena on priorisoitu kehitysjono jokaiselle pyynnölle. Pyyntöjä verrataan toisiinsa ja niistä kannattavin valitaan ensimmäiseksi kehityskohteeksi. Valintakriteeri perustuu yleensä joko viivästymisen kustannuksiin jaettuna kestolla (CD3) tai SAFe:n ehdottamaan painotettuun nopeimpaan arvoon (eng. Weighted Shortest Job First, WJSF).

Muutokset

Jotkut palvelutiimien vastaanottamat kehityspyynnöt liittyvät olemassa oleviin tuotteisiin, ratkaisuihin tai palveluihin, ja niiden kehittämiseen tarvitaan siten vain muutaman tunnin tai päivän verran työtä. Kehitysputki voi yleensä päättää tällaisista muutoksista, ja ne noudattavat muutoskomitean (eng. Change Advisory Board, CAB) asettamia ohjaus- ja priorisointikäytäntöjä.

Palvelumuutosten hallintaprosessia käytetään muutosten käyttöönoton ja tuotantoon siirron hallinnoinnissa. Se käyttää vakioituja metodeja ja menetelmiä arvioidakseen tarvetta suhteessa muutoksen vaikutuksiin. Tavoite on välttää liiketoiminnan häiriöitä ja suunnittelemattomia palvelukatkoja.

Muutokset jaetaan tyypillisesti seuraaviin kategorioihin: normaali, vakio ja kiireellinen.

• Normaalit ja harvoin tapahtuvat muutokset palveluun tai infrastruktuuriin tarvitsevat muutoskomitean tekemän riskiarvioinnin.
• Vakioidut muutokset ovat rutiiniluontoisia tehtäviä, jotka palvelujohtamisen yksikkö on sallinut etukäteen. Muutosvaatimuksen määrittely tehdään käyttämällä hyväksyttyjä ja olemassa olevia prosesseja.
• Kiireelliset muutokset täytyy toteuttaa mahdollisimman nopeasti, koska yleensä ne koskevat virhettä jossain tietyssä ympäristössä. Näihin muutoksiin liittyy merkittävä riski, ja siksi ne täytyy hyväksyttää hätämuutoskomiteassa (eng. Emergency Change Advisory Board, ECAB).