Verkkopalvelun kehityshankkeet ovat kriittisiä projekteja, joiden onnistumisella on valtava merkitys bisnekselle ja sen kasvulle. Digitaaliseen tuotekehitykseen, myyviin verkkopalveluihin ja verkkokauppoihin erikoistuneen Sofokuksen Tomi Pyrhönen nostaa esiin viisi asiaa, jotka yrityksen tulisi huomioida verkkopalvelun määrittelyvaiheessa.


1 Liiketoiminnan tilanne

“Anna tietohallinnolle verkkopalvelun kehitystehtävä, niin saat palvelin- ja tekkinäkökulmasta toimivan kokonaisuuden. Ota mukaan liikkeenjohdon henkilöitä, niin teet bisnestä.”

Aivan aluksi on tärkeää käsitellä liikkeenjohdon ajatuksia siitä, mitä ollaan tekemässä ja miksi. Kannattaa aloittaa kartoittamalla lähtötilanne ja ydinliiketoiminnan malli sekä listata suunnitellut muutokset.  Numerot antavat pohjan työlle, mutta eivät kerro, onko yrityksellä “piilossa” tuotteita tai palveluita, joilla on potentiaalia kasvattaa liiketoimintaa tulevaisuudessa. Miettikää siis haluatteko kiihdyttää nykyistä liiketoimintaa vai tunkeutua kokonaan uusille markkinoille? Kaikella tällä on vaikutusta muun muassa budjettiin, palvelun lanseeraukseen, tuleviin kehityspolkuihin ja pidemmän aikavälin tavoitteisiin.

Kehityshankkeissa punnitaan myös organisaation kyvykkyys resurssien näkökulmasta. Onko organisaatiossa valmiiksi vastuullisia tuoteomistajia vai rakennetaanko vastuut oman työn oheen? Kysykää myös itseltänne, oletteko valmiita tarvittaviin muutoksiin –  löytyykö talosta riittävästi osaamista ja kuinka paljon resursseja on mahdollista sitoa?

Myös kehityksen mittaaminen ja testaus ovat tärkeitä vaiheita. Onko mahdollisuutta testata laajemmassa mittakaavassa vai edetäänkö worst case scenario -mallilla?

 

Tomi Pyrhönen

Tomi Pyrhönen


2 Asiakaskohtainen ymmärrys verkkopalvelun suunnittelun näkökulmasta

Voit tehdä palvelun itsellesi tai asiakkaallesi. Kummalla on enemmän merkitystä lopputuloksen kannalta?  

Verkkopalvelun määrittelyn tulee siis lähteä loppukäyttäjästä. Toteutusta suunniteltaessa voidaan pohtia muun muassa seuraavia kysymyksiä:

  • Missä vaiheessa verkkopalvelun loppukäyttäjä otetaan mukaan osaksi kehityskaarta?
  • Törmäytetäänkö ajatuksia verkkopalvelun tilaajan tai loppukäyttäjän kanssa jo alkuvaiheessa, onko pilottiryhmää, lanseerataanko MVP (minimum viable product) suljetulle käyttäjäryhmälle ja kuinka ajatukset validoidaan?

Asiakaskohtainen ymmärrys on olennaista priorisoinnin näkökulmasta, sillä sen avulla palvelusta kuoritaan pois turhat asiat ja voidaan keskittyä liiketoiminnan kannalta tärkeimpiin osa-alueisiin.

 

Sofokuksen jokaisella työntekijällä on oma slogan, joka kehystetään toimiston seinälle. Sofokuksen Tomi ja Kalle esittelemässä iskulauseitaan.


3 Tekninen arkkitehtuuri

Olisiko jo aika päästää jo irti 20 vuotta vanhasta toiminnantuhoamisjärjestelmästä? Tee se harkiten.

Tekninen arkkitehtuuri asettaa omat rajansa, mutta avaa toisaalta mahdollisuuden kehitykselle.

Siksi seuraavat kysymykset ovat tärkeitä tätä osa-aluetta käsiteltäessä:

  • Mitä järjestelmiä on olemassa ja onko ajatuksena uusia näitä? Mitä on tiedettävä järjestelmien yhteensopivuuden varmistamiseksi?
  • Kuinka taustajärjestelmät vaikuttavat lopputulokseen, mitkä ovat pullonkaulat?
  • Missä kohtaa voidaan oikoa säästäen aikaa ja rahaa. Voidaanko käyttää avoimen lähdekoodin valmisratkaisuja osana kokonaisuutta? Tehdäänkö nollasta vai käytetäänkö valmiita ratkaisuja ja moduuleita, kuten pilvi-ohjelmistoja?
  • Mitä tulee ottaa huomioon tietoturvan ja päivitettävyyden osalta?

 

4 Roadmap ja kehitysskenaariot

Historia auttaa alkupisteen määrittämisessä, mutta harva pystyy ennustamaan tulevaa. Arvauksia voidaan kuitenkin tehdä ja antaa niiden viedä tutkimusmatkalle.

Etenemisestä voidaan sopia roadmapin ja kehitysskenaarioiden avulla. Ketterässä kehityksessä ei tiedetä tarkkaa lopputulosta, jolloin useamman skenaarion rakentaminen ja niiden seuraaminen on hyvä tapa lähestyä esimerkiksi budjetointia, aikataulutusta tai priorisointia.

 

Miryan huoneentaulu linjaa, ”Get shit done”.

 

Suunnittelussa olennaista on tunnistaa ylätasolla, mitkä asiat ovat muuttuvia tekijöitä ja millä tavalla ne vaikuttavat tehtyihin skenaarioihin. Eri skenaariot perustuvat eri tavoitteisiin.

Tärkeää on myös hahmottaa kuinka valmis organisaatio on tekemään nopeita suunnanmuutoksia. Millaista päätösvaltaa tai byrokratiaa se vaatii?

 

5 Aikataulutus

Kuten projekteissa aina, on aikataululla oma paikkansa osana kokonaisuutta. Verkkopalvelun lanseerausaikataulun tulisi perustua liiketoiminnan tarpeisiin, eikä siihen, että “olisi kiva saada palvelu ennen joulua”.

Aikataulussa on otettava huomioon eri kehitysskenaariot: rakennetaanko MVP vai suoraan täysin valmis paketti. Ovatko taustajärjestelmät, resurssit, kolmas osapuoli ynnä muut valmiina?

 

Määrittelystä kohti toteutusta frameworkiä hyödyntämällä

Tomi Pyrhönen on tyytyväinen viiteen otsikkoomme, vaikka sisältöä jokaiseen riittäisi novelliksi saakka. “Kun lähdetään verkkopalvelun kehityshankkeeseen, yllä esiteltyjä asioita ei saisi sivuuttaa”, Pyrhönen sanoo.

“On löydettävä hyvä tradeoff määrittelyn ja ketteryyden välillä.”

Pyrhösen edustama Sofokus hyödyntää verkkopalveluiden määrittelyssä kehittämäänsä frameworkia, jolla verkkopalvelun ja sen kehityshankkeen kannalta olennaiset asiat käydään läpi hallitusti asiakkaan kanssa. Asiakaslähtöisyyttä Pyrhönen ei voisikaan liikaa korostaa:

“Kaikkea ei voi suunnitella etupeltoon, vaan tärkeintä on saada aluksi pääasiat ruotuun. On löydettävä hyvä tradeoff määrittelyn ja ketteryyden välillä. On selvää, että jokaisen asiakkaan liiketoiminta on erilainen. Näin ollen ei voida myöskään tehdä geneeristä määrittelyä, joka toimisi kaikille.”

 

Sofokuksen ite wiki -profiili

Sofokuksen kotisivut