Kävin edellisessä blogissani sekä webinaarissa läpi mikä on dashboard (ja mitä se ei ole), sekä mitä seikkoja on hyvä pitää mielessä dashboardia suunnitellessa. Tässä blogissa kuvaan dashboardin suunnitteluun liittyvää prosessia, erityisesti miten ketterillä kehitysmenetelmillä päästään perinteistä vesiputousmallia parempaan lopputulokseen.
Perinteiset liikkeellelähdön oletukset eivät palvele aina lopputulosta
Perinteisessä IT-projektissa dashboardin suunnittelu aloitetaan yleensä kokoamalla yhteen mahdollisimman paljon dataa ja määrittelemällä myös dashboard-näkymät. Muutama avainhenkilö organisaatiosta esittää yleensä näkemyksensä siitä, mitä tietoa ja millä tavoin esitettynä ne halutaan dashboardilla nähdä. Usein ajatus ja näkemys pohjaa olemassa oleviin raportteihin. Helposti saattaa jäädä huomioimatta oleellisia asioista, kuten mihin tätä tietoa oikeastaan tarvitaan, mikä on todellinen käyttötilanne ja mitä toimenpiteitä tiedon pohjalta tehdään. Tästä johtuen dashboardia suunnittelevalla henkilöllä ei vielä projektin alkuvaiheessa ole olemassa kovin syvällistä ymmärrystä todellisen loppukäyttäjän varsinaisesta tarpeesta, eikä käyttäjiä edustava yhteyshenkilö välttämättä osaa sitä itsekään täydellisesti määritellä.
Tästä ristiriidasta johtuen saattaa käydä niin, että dashboard-suunnittelun pohjalla olleet oletuksen käyttäjän tarpeista eivät vastaakaan todellisuutta. Todelliset käyttäjät voivat kokea dashboardin liian hankalaksi käyttää, dashboardin käyttäjämäärä jää vähäiseksi ja projekti ei tarjoakaan organisaatiolle tavoiteltuja hyötyjä.
Ketterät kehitysmenetelmät onnistuneen dashboardin salaisuutena
Jos tämän tyyppisiltä ongelmilta haluaa välttyä, kannattaa dashboardien kehitystyössäkin kokeilla ketteriä kehitysmenetelmiä. Ketterässä kehittämisessä ei pyritä tekemään kerralla valmista täydellistä ratkaisua, vaan pyritään nopeasti tuottamaan yksinkertainen ensimmäinen versio ratkaisusta, jonka pohjalta voidaan testata oletuksia käyttäjän tarpeista ja saada käyttäjiltä suoraa palautetta.
Saadun tiedon perusteella varmistutaan siitä, että oletukset käyttäjien tarpeista ovat oikein tai tarpeen vaatiessa suunnitelmiin tehdään muutoksia.
Ketterä kehittäminen tarjoaa myös mahdollisuuden julkaista materiaalia tuotantoon jatkuvasti. Tällöin projekti alkaa nopeasti tuottaa todellista arvoa käyttäjille.
Ketterä kehittäminen edellyttää yleensä uudenlaista tapaa ajatella ja lähestyä ongelmia
Kehitystapa on iteratiivinen ja kuva lopputuloksesta tarkentuu vähitellen prosessin aikana. On tärkeää, että prosessissa ihmiset ja kommunikaatio ovat keskeisessä asemassa. Data ja ratkaisut eivät saa varastaa huomiota siitä, kenelle ja mihin tarpeeseen dashboardia tehdään. Loppukäyttäjän äänen tulee kuulua kehityksessä jatkuvasti ja sen perusteella on tehtävä muutoksia läpi projektin. Dashboard-ratkaisunhan tulee ennen kaikkea palvella käyttäjää, ei tietovarastoa.
Oikein tehtynä ketterässä projektikehittämisessä käyttäjä ja hänen tarpeensa ovat keskiössä dashboard-projektissa alusta loppuun saakka, sillä käyttäjiltä saatu palaute ja käyttäjien määrän kehitys ohjaavat dashboardin suunnittelua jatkuvasti.
Palautetta voidaan kerätä käyttäjien haastattelemisen lisäksi esimerkiksi dashboardiin sijoitettavan palautelinkin avulla. Käyttäjiä haastatellessa kannattaa kysyä avoimia kysymyksiä, jolloin saadaan paremmin tietoa käyttäjän tarpeesta, kuin tiukemmin rajatuilla kysymyksillä.
Seuraavassa blogikirjoituksessani tulen kertomaan käytännön vinkkejä siihen, miten design ajattelutavoista on hyötyä ketterin menetelmin tehdyssä dashboard-projektissa.
