Roadmap toimii tuotekehityksen tukena silloinkin, kun puntaroidaan, miksi jokin ominaisuus tehdään ohjelmaan ja miksi jokin jätetään tekemättä, sekä jos jokin ominaisuus tehdään, miten ja millaisella aikataululla se toteutetaan? Lue blogista, mitä roadmap-kartta pitää sisällään ja miten se muodostuu!
Mitä roadmap käytännössä pitää sisällään?
Lyhyesti tiivistettynä roadmap tarkoittaa sitä, että oikeita asioita tehdään oikeaan aikaan. Se toimii yhteisenä tiekarttana ja tukena kehitysjonon priorisoinnissa. Se on aina ylätason suunnitelma siitä, mitä ja millä aikataululla pyritään tekemään.
Vaikka roadmap onkin visuaalinen tapa esittää tuotestrategia kokonaisuutena, se on myös paras tämänhetkinen käsitys tulevaisuuden suunnitelmista.
Tämän vuoksi roadmapia käytetään pitkän aikavälin tavoitteita varten. Lisäksi se tuo suunnitelmallisuutta kaikkeen tekemiseen antamalla esimerkiksi raamit lakimuutoksiin perustuviin toimintoihin, joilla on tietty deadline.
Maailma kuitenkin muuttuu, ja aina toisinaan tilanteisiin pitää pystyä reagoimaan vikkelästi. Tästä syystä roadmapin ei tule olla täysin kiveen hakattu, vaan sen pitää sallia uudenlaiset valinnat tilanteiden muuttuessa.
Tätä kaikkea voisikin verrata suunnistamiseen: Suunnistaja tekee reittivalinnan maastossa seuraavalle rastille. Maastossa edetessään hän kuitenkin huomaa, että oja tulvii tai maasto on niin vaikeakulkuista, että on järkevämpää valita reitti uudelleen esimerkiksi valmista polkua pitkin.
Vaikka reitti aukean kautta saattaakin olla lyhyempi ja polku puolestaan pidempi, polkua pitkin on helpompi kulkea ja siksi se myös on lopulta järkevämpi tapa edetä.
Tällaisia valintoja on tehtävä myös tuotekehitystyössä. Aina voi tulla vastaan jotain yllättävää, joka vaatii reagointia, ja silloin tarvitaan ketteriä käännöksiä kartalla. Myös itse tavoitekin voi muuttua matkan varrella: tavoite voi olla lopulta jokin toinen, yleensä myös paljon parempi.
Joskus roadmapin täytyy joustaa – case Wilma & koronakevät
Kevät 2020 jää jokaiselle mieleen, myös Visman oppilashuoltojärjestelmä Wilman tuotekehitystiimille, kun etäopiskelu nosti Wilman käyttöasteen pilviin.
Roadmapilla oli jo valmiiksi tiettyjä asioita odottamassa, mutta kaikki paukut olikin yhdessä hetkessä käytettävä aivan toiseen. Onneksi meillä oli pelivaraa.
Korona nosti esiin aivan uudenlaisia tarpeita, minkä lisäksi meidän tuli puntaroida, mistä saadaan suurin hyöty mahdollisimman monelle käyttäjälle, vieläpä niin että käytössä olevat resurssit riittävät myös niiden toteuttamiseen.
Poikkeuksellinen tilanne vaati suunnanmuutoksia: joitan asioita oli siirrettävä eteenpäin, ja kouluarjen toimivuus Wilman osalta oli varmistettava myös etänä. Koronakevään tärkeimmäksi prioriteetiksi nousikin Wilman toimivuuden varmistaminen sekä Wilman optimointi siten, että tuikitärkeä viestitoiminto nopeutui.
Wilma onkin tuotteistamme se, joka saa ylivoimaisesti eniten kehitystoiveita, onhan sillä todella laaja käyttäjäkunta. Arvostamme saatua palautetta ja kehitysehdotuksia, joita tälläkin hetkellä on satoja. Tästä syystä muistuttelemme myös aina siitä, että kaikki kehitysehdotukset kannattaa kertoa ensin omalle koululle, mistä viesti ohjelman pääkäyttäjän kautta etenee Vismalle.
Ja koska Wilma on koulujen itsensä hallinnoima ohjelma, saattaa toivottu asia olla olemassa, mutta sitä ei ole vain vielä otettu käyttöön kunnassa tai oppilaitoksessa.
Ideasta roadmapille
Roadmap on suunnittelun tulos ja tekemisen lähtökohta. Mutta miten jokin asia päätyy roadmapille?
Roadmapilla ei ole yksittäisiä pieniä muutoksia, vaan sille nostetaan aina isompia kokonaisuuksia, jotka myös ovat yrityksen tuotestrategian kannalta merkittäviä. Vaikka jokin toiminnallisuus voi olla pienikin, se voi olla asiakkaiden kannalta iso ja siten strategisesti merkittävä.
Esimerkiksi Wilmassa roadmapia ohjaavat vahvasti lait ja viranomaisvaatimukset, joita on paljon. Nämä vaatimukset ovat kuitenkin myös hyödyksi kaikille asiakkaillemme. Strategian ja viranomaisvaatimusten lisäksi Wilman suunnittelussa huomioidaan myös esimerkiksi rajapintamuutokset ja tekninen uudistus.
Roadmapin suunnittelussa on aina mukana koko organisaatio
Koko organisaation osallistamisella varmistetaan se, että kaikki organisaatiossa olevat taustatiedot saadaan yhteen, minkä ansiosta löydetään myös paras mahdollinen toteutustapa toivotun tarpeen saavuttamiseksi.
Eli sen sijaan, että ohjelmaan toteutettaisiin suoraan jokin toive, mietitään ensin, voisiko toivotun ominaisuuden sijaan jokin muu tapa olla vieläkin parempi ja hyödyllisempi?
Kevyessä esimerkissä, jossa käyttäjän tavoitteena on yltää ylimmälle tasolle, on ensimmäinen ajatus tarvittavasta työkalusta yleensä tikapuut. Mutta ennen kuin aletaan automaattisesti rakentaa tikapuita, joihin kuluu aikaa, kannattaa miettiä, olisiko olemassa jokin muu tapa päästä helpommin ylimmälle tasolle? Tikapuiden sijaan lopputuloksena voi olla vaikka pieni raketti. Ja mitä mahdollisuuksia jatkokäytön osalta raketti voisikaan antaa asiakkaalle, niiden tikapuiden sijaan?
Tasaisin väliajoin edustajat jokaisesta tiimistä (kuten tuki, koulutus, myynti) kootaan yhteen keskustelemaan tällaisista “tikapuista” ja “raketeista” sekä arvioimaan käyttäjien tarpeita.
Kun jotain kokonaisuutta lähdetään edistämään, tutkitaan ensiksi, miksi kokonaisuutta tarvitaan, miten ja mihin sitä käytetääna, sekä miltä se näyttäisi. Lisäksi muun muassa selvitetään, kenelle tai mille käyttäjäryhmälle kokonaisuudesta on hyötyä, onnistuuko sen tekeminen teknisesti, miten kalliiksi se tulee ja riittävätkö resurssit. On myös aina syytä pohtia, onko sen tekeminen ylipäätään kannattavaa.
Kehitysjaksoa ei koskaan tuupata täyteen valmiiksi suunnitelluilla toiminnallisuuksilla, vaan yllättävien muutosten varalle tulee aina jättää jonkin verran pelivaraa. Roadmap elää ja kehittyy, ja siten jotain asioita voidaan päätyä siirtämään eteenpäin, kun taas jotkut asiat kiilaavat takavasemmalta jonon ensimmäiseksi.
Kuten sanottu, roadmap on pyrkimys tehdä oikeita asioita oikeaan aikaan, aina parhaalla mahdollisella tavalla. Se ei ole kiveen hakattu taulu, vaan elävä ja muuttuva, tilanteisiin reagoiva suunnistuskartta.