Vähänkin laajemman verkkopalvelun uudelleenrakentamiseen liittyy usein monenlaista ahdistusta. Palvelut ovat usein rakentuneet vuosien evoluution tuloksena ja vuosien saatossa niihin on myös kehitetty kasapäin erilaisia, toinen toistaan tärkeämpiä toiminnallisuuksia. Myös integraatioita taustajärjestelmiin on rakennettu pitkään ja hartaudella. Ja kun palvelu on kerran vaivalla pystyyn urakoitu, samaan työhön ei haluaisi kovin kevein perustein lähteä uudestaan. Mutta jossakin vaiheessa aika vain ajaa ohi ja uudistus on pakko tehdä. Mutta miten? Pitäisikö uudistaa koko palvelu kerralla, vai riittäisikö vain osittainen uudistus? Miten projekti pitäisi vaiheistaa? Mistä nurkasta pitäisi edes lähteä liikkeelle?
North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
4.5.2015
1. Priorisoi, priorisoi, priorisoi
Työ kannattaa aloittaa listaamalla eniten käytetyt sisällöt, ominaisuudet ja toiminnallisuudet. Web-sivustojen statistiikat antavat yleensä hyvät lähtökohdat tähän selvitystyöhön. Statistiikan avulla myös näet, mitä osioita ei juuri käytetä ja mitä voi näin jättää pois ainakin ensimmäisestä julkaisuversiosta. Ylläpitäjiä haastattelemalla saat varmasti selville mikä heidän työkaluissaan hiertää eniten ja mikä näin pitäisi olla uudessa versiossa paremmin. Loppukäyttäjien, asiakkaiden ja yhteistyökumppanien haastatteluista saatat myös saada hyvinkin arvokasta lisätietoa palvelusi uudistusta varten.
Tärkeää on saada selville paitsi se, mitä nykyisestä palvelusta puuttuu ja mitä pitää karsia, myös mikä nykyisessä versiossa toimii hyvin. Usein olemassa olevia ominaisuuksia pidetään itsestäänselvyyksinä, eikä niistä välttämättä hoksata puhua, ennen kuin niiden huomataan puuttuvan uusista kilkkeistä.
Priorisoi sisällöt ja toiminnallisuudet esim. kolmeen kategoriaan. Ensimmäiseen luokkaan kuuluvat ne, joita ilman palvelua ei oikeastaan kannata edes rakentaa. Ne hyödyttävät liiketoimintaasi eniten ja suurin osa käyttäjistäkin saadaan niillä tyytyväisiksi. Kakkosluokkaan kuuluvat ne, joita voidaan tarvittaessa vaiheistaa vähän myöhemmäksi. Nice-to-have-asiat kuuluvat kolmosluokkaan.
Luokittelu on aina enemmän tai vähemmän tasapainoilua eri vaihtoehtojen välillä. Tässä vaiheessa on kuitenkin hyvä olla melko kriittinen. Jos kaikkein tärkeimpään kategoriaan kasautuu liikaa asioita, projekti paisuu liikaa ja siitä tulee vaikeasti hallittava. Toiminnallisuuksien karsiminen ensimmäisestä vaiheesta saattaa tilapäisesti heikentää käyttäjien kokemaa palvelutasoa, mutta voi nopeuttaa merkittävästi uuden palvelun julkistusaikataulua. Eivätkä käyttäjät välttämättä aina edes kaipaa kaikkia toiminnallisuuksia niin paljon, kuin ehkä itse arvelet.
Ja sitten taas toisaalta, liian paljonkaan ei saa karsia. Uuden palvelun ensimmäisen version lanseeraus on aina kriittinen hetki. Toista yhtä hyvää tilaisuutta uuden palvelun myymiselle ei välttämättä tule. Varmimmin lanseeraus onnistuu, jos mukana on muutama koukku, joilla käyttäjien leuat saadaan loksahtamaan. Ripaus kunnianhimoakin pitää projektissa aina olla, että lopputuloksista on oikeasti iloa ja hyötyä.
2. Tee projektille tiekartta
Seuraavaksi tarkoituksena olisi selvittää, miten suuria muutoksia nykyjärjestelmiin tarvitaan. Jos uusittava palvelu on jo alun alkaen toteutettu modulaariseksi ja tekniikka on edelleen toimivaa, palvelun uusimiseksi saattaa riittää vain käyttöliittymäkerroksen uusiminen. Jos taas toimintojen taustalla oleva liiketoimintalogiikkakin on muuttunut tai tekninen alusta on tullut tiensä päähän, voi olla parempi rakentaa koko palvelu alusta loppuun uusiksi. Valitse kuitenkin aina tapauskohtaisesti mitkä palikat pitää oikeasti uusia ja milloin kannattaa hyödyntää jo olemassa olevia osia. Selvitystyössä saatat tarvita apuja esim. toteutuskumppaniltasi.
Tiekartan ajatuksena on asettaa jokainen yksittäistä työvaihetta kuvaava palikka aikajanalle ja ryhmitellä toisiinsa liittyvät asiat lähelle toisiaan. PowerPoint on hyvä työkalu tähän. Perinteinen fläppitaulu ja tarralaput toimii myös hyvin. Mitä vaativammasta työvaiheesta on kyse, sitä leveämmän palikan se aikajanalla tarvitsee. Ole tässäkin realistinen äläkä yritä tiivistää aikajanaa liikaa. Pidä mielessä, että sinulla on joka tapauksessa vain rajallinen määrä resursseja käytettävissä kuhunkin yhtäaikaiseen työvaiheeseen.
Ensimmäisen vaiheen tulisi sisältää pääasiallisesti vain ensimmäisen prioriteetin asioita, mutta voit toki sisällyttää siihen myös joitakin ”pikavoittoja”. Jos jokin toisen tai kolmannen prioriteetin toiminnallisuus on helppo toteuttaa eikä vaadi liikaa resurssejasi, voi olla hyvä ajatus ottaa se mukaan jo ensimmäiseen vaiheeseen, vaikkei se olisikaan niin liiketoimintakriittinen.
3. Tiekartasta toteutukseen
Kaikki liikkuvat palikat ovat nyt siististi järjestyksessä aikajanalla. Mitä pitäisi tapahtua seuraavaksi? Pitäisikö kirjoittaa massiivinen vaatimusmäärittely ja yrittää valita yksi toteutuskumppani, joka pystyy tekemään kaikki määritellyt toiminnallisuudet jollakin maagisella teknologialla? Ei välttämättä. Jokainen aikajanalla oleva palikka tarvitsee kyllä jonkinlaisen vaatimusmäärittelyn, varsinkin jos olet kilpailuttamassa toteutusta. Mutta voit myös ajatella vähän pienimuotoisemmin ja haukata pienempiä palasia kerrallaan. Keskity aluksi määrittelemään tarkemmin vain ensimmäisessä vaiheessa toteutettavia elementtejä. Myöhemmissä vaiheissa tehtävien osien määrittelyn tarkkuusaste voi tässä vaiheessa olla paljon alhaisempi.
Älä kuitenkaan unohda, että sinulla on koko ajan oltava selkeä kokonaiskäsitys siitä, minkälaista palvelua olet rakentamassa. Tarvitset konseptisuunnitelman, jossa on kuvattu mm. palvelun tavoitteet ja visiot, kohderyhmät, minkälainen palvelun käyttökokemuksen pitäisi olla, mitä yleisiä käytettävyysperiaatteita palvelun pitäisi noudattaa jne. Pidä konseptisuunnitelma takaraivossasi koko projektin ajan ja säilytä yhtenäinen linja koko uudistusprojektin ajan.
Entä tekniset ratkaisut?
Asiakkaamme pohtivat myös usein sitä, kannattaisiko heidän valita ensin jokin teknologia-alusta ja vasta sitten yrittää määritellä ja toteuttaa vaaditut toiminnallisuudet valitun teknologian päälle. Joskus tämä onkin ihan hyvä tapa edetä, varsinkin jos jo alustavat vaatimukset suosivat selkeästi jotakin tiettyä teknologista ratkaisua tai jos asiakkaalla on jokin tarkoitukseen soveltuva teknologia käytössä jo entuudestaan. Teknologian pitäisi kuitenkin aina tukea liiketoimintaa eikä päinvastoin. Siksi tärkeimmät vaatimukset olisikin yleensä hyvä määritellä ensin ja vasta sitten valita tarkoitukseen parhaiten sopiva teknologia.
Usein suosittelemme, että pohjalle otetaan jokin valmistuote tai -kehys, jossa perustoiminnallisuudet ovat jo valmiina. Tuotepohjaisissakaan ratkaisuissa räätälöinneiltä ei toki voida kokonaan välttyä, mutta päivitykset, tietoturva-asiat ym. perusasiat ovat niissä yleensä jo valmiiksi kunnossa. Usein toteutus tulee näin halvemmaksi, lopputuloksen laatu on parempi ja riskitkin ovat pienemmät. Esimerkiksi julkaisujärjestelmiä ei enää ole pitkään aikaan ollut järkevää tehdä kokonaan räätälöiden. Joskus tietenkin asiakkaiden tarpeet ovat niin valtavirrasta poikkeavat, että valmista tuotetta ei markkinoilla ole. Silloin kokonaan räätälöitykin järjestelmä voi olla oikea valinta.
Kaikki teknologiat eivät kuitenkaan sovellu kaikkiin käyttötarkoituksiin. Esimerkiksi verkkokauppa-alustat eivät yleensä sisällä kovin hyviä työkaluja monipuolisen viestinnällisen sisällön hallintaan. Ja myös toisinpäin, kaikki julkaisujärjestelmät eivät laajene ongelmitta laajamittaiseksi verkkokaupaksi. Voi olla, että ei edes ole olemassa yhtä tuotetta, joka toteuttaisi kunnolla edes kaikki tärkeimmät vaatimuksesi. Lopputulos voikin olla hybridi, usean teknisen alustan yhdistelmä.
Yleensä nyrkkisääntö on, että yhden järjestelmän ratkaisulla saavutetaan yhtenäisempi käyttökokemus, ainakin ylläpitäjille. Mutta hybridijärjestelmiäkään ei pidä pelätä liikaa. Kustakin alustasta voidaan ottaa irti sen parhaat kyvykkyydet, eikä alla olevien teknisten ratkaisujen tarvitse välttämättä näkyä loppukäyttäjälle mitenkään. Monimutkaisempia järjestelmäkokonaisuuksia rakennettaessa saatat joutua hankkimaan myös esim. identiteetinhallintajärjestelmän, joka huolehtii eri järjestelmien saumattomasta yhteispelistä. Tämä tietysti lisää kokonaisuuden kompleksisuutta, mutta jos vaaditun kaltaista järjestelmää ei muuten ole mahdollista kustannustehokkaasti toteuttaa, hybridi voi hyvinkin olla paras mahdollinen ratkaisu.
Soveltuvimman ratkaisun valinta on aina tapauskohtaista ja riippuu monesta muuttujasta. Isompikin uudistus on kuitenkin mahdollista saada haltuun, kunhan sen vain palastelee helposti nieltäviksi kokonaisuuksiksi. Jos kuitenkin jokin vaihe tuntuu liian haastavalta tai tarvitset muuten apua projektissasi, autamme toki mielellämme.
PS. Sinua voisi kiinnostaa tulossa oleva ilmainen webinaarimme: Digitaaliset asiointipalvelut – Erilaiset konseptit ja toteutuksen eri vaihtoehdot (11.12.2024 klo 10:00). Ilmoittaudu webinaariin
