Meille OIDO:ssa on erityisen tärkeää, että kaikki mitä hankkeessa suunnitellaan ja tehdään, tapahtuu tiukassa yhteistyössä loppukäyttäjien kanssa. Hankkeen alussa kehitystyö oli hyvin pitkälle sitä, että ohjauksen ammattilaiset kävivät läpi ohjauksen nykytilannetta ja siihen liittyviä prosesseja. Pohdintaan liittyi myös haasteiden kartoittamista ja niihin ratkaisujen miettimistä. Tilannekuvan lisäksi mietittiin myös sitä, kuinka tilannetta haluttaisiin parantaa nykyisestä.
Sitä kautta alkoi pikku hiljaa kehittyä ajatuksia erilaisista digitaalisista työkaluista, jotka erityisesti tukisivat opiskelijan itseohjautuvuutta itsenäisissä etäopinnoissa. Samalla niiden oli tarkoitus tarjota ohjaajille lisää työkaluja, jotta he voisivat kohdentaa ohjaustoimet mahdollisimman varhaisessa vaiheessa sitä tarvitseville.
Matka toiveesta valmiiksi työkaluksi on kuitenkin hyvin pitkä ja sisältää lukuisan määrän iteraatioita, joiden aikana toive pikku hiljaa jalostuu digitaaliseksi työkaluksi tai näkymäksi. On harhaluulo ajatella, että sovelluskehitys on vain sitä, että koodari naputtelee koodia määritysten mukaisesti. On se tietysti sitäkin, mutta se vaatii myös yhteisen näkemyksen hakemista, erilaisten mahdollisuuksien pallottelua, yrityksiä, erehdyksiä ja myös onnistumisia.
Iteratiivisessa sovelluskehityksessä kehitys etenee vaiheissa, joihin voi palata missä tahansa vaiheessa tarpeen mukaan. Iteraation myötä luonnokset kehittyvät käyttöönotettaviksi piirteiksi. Kuvat: Adobe Stock
Suunnittelussa kaiken lähtökohtana ovat käyttäjien tarpeet ja toiveet. Lähtökohtana oli, että ohjaajat saivat unelmoida isosti siitä, kuinka etäopintojen ohjaus voisi tapahtua. Tässä vaiheessa ei ollut rajoitteita, kaikkea sai toivoa. Syntyi muun muassa unelmaohjaamo, johon ohjaajat olivat sijoittaneet kaiken, mitä erityisen toimiva etäohjaus voisi tarvita tuekseen.
Asiakasymmärrys on välttämätöntä
Palvelumuotoilu on ollut paljon esillä viime vuosien aikana. Puhutaan esimerkiksi muotoiluajattelusta (engl. design thinking), joka on ihan justiinsa sitä, mitä ketterissä sovelluskehitysprojekteissa harrastetaan. Kehitysprosessin alussa pyritään ymmärtämään, mitä asiakas eli tässä tapauksessa ohjaaja ja opiskelija tarvitsevat ja miksi. Asiakkaan ymmärtäminen on välttämätöntä, jotta projektissa päästään millään tavalla järkevästi eteenpäin. Ymmärrystä voidaan rakentaa monella eri tavalla, esimerkiksi keskustelemalla. Siihen voi liittyä myös kuvausta nykyisestä toiminnasta ja siihen liittyvistä ongelmakohdista. Meillä siihen on liittynyt lisäksi unelmointia siitä, miten asiat toimisivat täydellisessä maailmassa.
Ymmärryksestä määrittelyyn siirtyminen ei ole selkeä vaihe, jossa ymmärrys on saatu valmiiksi ja määritteleminen alkaa. Ennemmin kyse on siitä, että ymmärrysvaiheessa kerätään tietoa, josta määrittelyvaiheessa pyritään tekemään johtopäätöksiä. Johtopäätökset voivat esimerkiksi ratkaistavia ongelmia tai täytettäviä tarpeita. Meillä sovelluskehityksessä kerätystä aineistosta on tehty analyysiä, jossa erilaisia toiveita ja tarpeita jaoteltiin kokonaisuuksiksi, mahdollisiksi komponenteiksi ja näkymiksi. Lopulta määriteltyjä komponentteja oli huomattavan paljon enemmän kuin mitä hankkeen aikana mitenkään ehdittäisiin toteuttamaan. Näiden osalta on tehty priorisointia ohjaajien kanssa.
Toteutettava piirre kehittyy iteroiden
Meillä ideointivaiheeseen osallistuvat sekä ohjaajat että sovelluskehittäjät. Tavallaan ideoinnissa on kyse myös määrittelystä, koska tässä kohden pallotellaan ideoita siitä, miten asiat voisivat toimia ja toisaalta myös, kuinka niiden tulisi toimia. Monesti on niin, että käyttäjillä ei ole täyttä ymmärrystä siitä, mikä kaikki on on teknisesti mahdollista. Toisaalta voi olla myös niin, että omaan korvaan viattomalta kuulostava toive onkin teknisesti todella monimutkainen eikä ehkä sen kaiken työn ja ajan arvoinen. Ideoidessa asiakasymmärryksen merkitys vahvistuu: kun ymmärtää asiakasta, voi ehdotella hänelle sellaisiakin asioita, joita hän tarvitsee, mutta ei osaa toivoa.
Näiden vaiheiden jälkeen sovelluskehityksessä vetäydytään luonnostelemaan toivottuja piirteitä. Aluksi luonnokset voivat olla rautalankamalleja käyttöliittymästä tai hätäisesti kyhättyjä prototyyppejä. Olennaisinta niissä on se, että kaikki aiemmin suunniteltu saadaan visualisoitua jotenkin tavalla, johon asiakas eli meillä ohjaajat pystyvät ottamaan kantaa. Visualisoinnit ovat siksikin tärkeitä, että niitä nähdessä mieleen alkaa pulpahdella uusia ideoita ja toisaalta myös mielipiteitä siitä, miten asiat eivät ainakaan voi toimia. Palaute on siis usein myös uudelleen määrittelyä ja ideointia, jonka perusteella sovelluskehityksessä syvennetään ymmärrystä ja palataan luonnostelemaan.
Useiden iteraatioiden kautta digitaaliset työkalut kehittyvät luonnoksista käyttöönotettaviksi piirteiksi. Jopa vielä demolla testattava versio käy läpi useita iteraatioita, kun siitä karsitaan pois isompia ja pienempiä toimimattomuuksia. Esimerkiksi pelkästään käyttöliittymätekstien hifistely vie aikaa: niiden pitää ohjata käyttäjää riittävästi ja olla yksiselitteisiä, mutta määrän pitää olla maltillinen. Ohjeitakin voi olla liikaa.
Sovelluskehitysprojektissa käytetään siis hyvin samankaltaisia toimintatapoja kuin palvelumuotoilussa. Vasta palvelumuotoilun yleistyttyä niitä tosin on alettu käyttää myös vaikka minkä muotoilussa. On kuitenkin huomioitavaa, että suuri osa työstä on jotain muuta kuin koodaamista, jota toki sitäkin on, mutta se on vain osa kokonaisprojektia. Toinen huomioitava asia on, että iteraatiot vievät aikaa. Sovelluskehitys on siis melko hidasta. Tämä kannattaa huomioida jo ennen projektiin ryhtymistä, koska usein voi olla niin, että asiakaspää ei ole varannut riittävästi aikaa olla mukana projektissa. Se näkyy väistämättä lopputuloksessa, jos sovelluskehityksen päässä pitää arvailla, miten asioiden pitäisi olla.
Teksti: Nina Kurki
Kuvat: Adobe Stock
