Virpi Blom // June 02 2014

KAKSI ERILAISTA OSTOMALLIA VERKKOPALVELUPROJEKTILLE

Verkkopalveluprojektien ostamiselle on selvästi muotoutumassa kaksi erityyppistä mallia, joita käytetään hankittavan verkkopalvelun luonteen mukaan. Tunnistamalla tarvitsemansa projektimallin tilaaja voi löytää helpommin oikeanlaiset tekijät verkkopalveluhankkeelleen.

 

1. Ensimmäisen mallin voisi nimetä lennokkaasti vaikkapa ”pintapainotteiseksi”, koska sitä käytetään tyypillisesti rakennettaessa sellaista verkkopalvelua, jossa korostuu esityskerros ja ulkoasu. Tässä mallissa verkkopalvelun suunnittelu ja rakentaminen tapahtuu kahdessa vaiheessa: ensin innovoidaan, ideoidaan, suunnitellaan ja mallinnetaan uuden verkkopalvelun käyttökokemus, ja toisessa vaiheessa kilpailutetaan, suunnitellaan ja rakennetaan verkkopalvelun tekninen toteutus.

Tässä kaksivaiheisessa mallissa tyypillisesti käyttökokemuksen suunnittelee palvelumuotoiluun erikoistunut suunnittelutoimisto, ja teknisestä toteutuksesta vastaa sovellussuunnitteluun erikoistunut teknisempi toteuttajakumppani.

2. Toinen malli voidaan nimetä vaikkapa ”pohjapainotteiseksi”, koska siinä verkkopalvelun rakentaminen pohjautuu vakaaseen tekniseen sovellusalustaan, jonka parhaiten tukemien ominaisuuksien valossa tehdään esitystapojen, käyttöliittymien ja toiminnallisuuksien suunnittelu. Suunnittelu ja toteutus tehdään vaiheittain saman yhteistyökumppanin kanssa.

1. PINTAPAINOTTEINEN VERKKOPALVELUPROJEKTI

Kun verkkopalvelu-uudistuksessa haetaan aivan uudenlaista konsepti-ideaa, innovatiivisia käyttöliittymäratkaisuja ja WOW-efektiä, päädytään useimmiten kaksivaiheiseen ”pintapainotteiseen” projektimalliin.

Jos verkkopalvelulle halutaan löytää täysin entisestä poikkeava sisältörakenne, uudenlaiset navigointimallit ja päräyttävät esitystavat, aloitetaan suunnittelu puhtaalta pöydältä. Käyttäjätarpeet sekä liiketoiminnan tavoitteet analysoidaan, ja näiden pohjalta suunnitellaan uudenlaiset palvelumallit sekä niitä tukeva käyttökokemus.

Innovatiiviseen palvelukonseptin luomiseen kilpailutetaan palvelumuotoiluun, konseptisuunnitteluun tai vuorovaikutussuunnitteluun erikoistunut kumppani. Suunnitteluprojekti saadaan tavallisesti nopeasti käyntiin, sillä tarjouspyynnön laatiminen ja kilpailutuksen läpivienti on melko kevyt prosessi. Investoimalla konseptisuunnitteluun vaikkapa 20 000 – 30 000 euroa onnistuu saamaan useimmilta suunnittelutoimistoilta mallikkaan ja paneutuneen suunnitteluprojektin.

Konseptisuunnittelun vaiheessa voidaan keskittyä palvelun käyttökokemuksen ja ulkomuodon kysymyksiin, mikä on asiakasorganisaatiolle palkitsevaa ja havainnollista. Asiakas saa nopeasti käsiteltäväkseen konkreettisia malleja uuden verkkopalvelun sisältö- tai käyttöliittymäratkaisuista, ja uusia ideoita voidaan arvioida, katselmoida ja testata niin sisäisillä kuin ulkoisillakin sidosryhmillä.

Lopputuloksena HTML-protomalli

Konseptisuunnitelmaa ei oikeastaan kannata jättää rautalankojen tai layout-mallien tasolle. Konseptin toimivuus, toteutuskelpoisuus, käyttökokemuksen muodostuminen ja käyttöliittymien responsiivinen mukautuminen on vaikeaa todentaa muutoin kuin kunnollisella HTML-mallilla. Protomallin rakentamisen kustannukset tulevat helposti takaisin toteutusvaiheen säästöinä, ja proton avulla on erinomaisen selkeää osoittaa toteutustyöstä vastaavalle kumppanille, mitä verkkopalvelun esityskerrokselta odotetaan.
Uusia konsepti-ideoita hakiessa ei pitäisi jumiutua teknisten ratkaisujen rajoituksiin, mutta konseptisuunnitelman edetessä käyttöliittymäratkaisuihin on toteutuskelpoisuuden ja ylläpidettävyyden kannalta hyvinkin merkityksellistä se, millä julkaisujärjestelmällä palvelu toteutetaan. Suunnittelutyö voidaan tehdä tuoteriippumattomasti, mutta ihanteellisessa tapauksessa julkaisujärjestelmävalinta tehdään suunnitteluprosessin edetessä, ja lopulliset suunnitteluratkaisut tehdään julkaisujärjestelmän parhaita ominaisuuksia hyödyntämällä.

Toteutusprojektiin siirryttäessä kilpailutetaan toteutustyöhön sellainen kumppani, jolla on kompetenssia valitun julkaisujärjestelmän hyödyntämiseen. HTML-proto on hyvä liitemateriaali tarjouspyyntöön, ja kumppaniehdokkaiden vertailussa voidaan kiinnittää erityistä huomiota proton osoittamien ongelmakohtien ratkaisuehdotuksiin.

Kun pintapainotteinen verkkopalveluprojekti siirtyy toteutusvaiheeseen, saadaan tekninen suunnittelu ja toteutus ripeästi käyntiin, sillä valmis HTML-proto kuvaa (toivottavasti) tavoitellun lopputuloksen niin yksiselitteisesti, että määrittelyjen tarkentamisesta tarvitsee neuvotella vain taustasovellusten teknisten ratkaisujen osalta. Tässä mielessä proton rakentamisen kustannukset ovat suurelta osin suoraan pois toteutustyön työmääristä.

2. POHJAPAINOTTEINEN VERKKOPALVELUPROJEKTI

Pohjapainotteinen verkkopalveluprojekti edellyttää tyypillisesti sitä, että tilaajaorganisaatiolla on suhteellisen tarkka käsitys siitä, mitä ovat tavoittelemassa. Käsitys julkaistavista sisältötyypeistä on kirkastunut, käyttökokemukseen haetaan käytännön standardien mukaisia ratkaisuja ja verkkopalvelun keskeiset toiminnallisuudet tiedetään edeltä käsin. Julkaisujärjestelmäkin voi olla jo valittuna.

Tällaisissa tapauksissa suunnittelu- ja toteutustyö hankitaan samalta kumppanilta yhden kilpailutuskierroksen kautta. Suunnitteluvaiheesta voidaan sopia kiinteähintaisena ja toteutusvaiheelle voidaan arvioida tavoitehinta, vaikka toteutettavat käyttöliittymämallit, sivupohjat, sovellusratkaisut tai tekniset yksityiskohdat eivät aluksi olisikaan täysin määriteltyinä.

Pohjapainotteisen verkkopalveluprojektin kilpailutuksessa haetaan kokonaisvastuullinen kumppanitaho, jolla on sovellusalustana käytössään tarkoitukseen soveltuva julkaisujärjestelmä sekä osaamista suunnitella palvelut, käyttöliittymäratkaisut, sovellusten toimintatapa ja sisältöjen ylläpito järjestelmän ihanteellisesti tukemalla tavalla. Mikään ei estä ideoimasta uudenlaisia, kekseliäitä ratkaisuja verkkopalvelun käyttökokemukselle matkan varrella. Muutoshallinnan keinoin toteutettavan kokonaisuuden ominaisuuksia voidaan kehitellä suunnitteluvaiheessa löydettyjen ideoiden pohjalta.

Yhden kumppanin mallissa kantavana ideana on tuoda teknisen toteuttajakumppanin kokemus ja osaaminen mukaan suunnittelutyöhön. Järjestelmäalustan kyvykkyydet voivat tarjota yllättäviä uusia mahdollisuuksia palvelukonseptin yksityiskohtiin, ja toteuttajakumppanin projektiryhmän monialaiset osaajat voivat yhdessä hioa palvelulle yhtenäiseen optimaaliseen lopputulokseen tähtäävän esityskerroksen, ulkoasun, toimintalogiikan ja sovelluslogiikan. Asiakas saa toteuttajakumppanista pitkäaikaisen yhteistyökumppanin, jonka kanssa voidaan kehittää verkkopalvelun kaikkia osa-alueita.

Miten tarkka määrittely tarvitaan kilpailutukseen?

Jotta suunnittelusta ja toteutuksesta vastaava toteuttajakumppani voisi tuoda pohjapainotteiseen projektiin kokonaisvaltaisen osaamisensa, ei verkkopalvelua kannata määritellä kilpailutusvaiheessa liian tarkkaan. Tarjouspyyntöön liitettävät määrittelyt vaatimuksista ja konseptista voivat olla suhteellisen karkealla ylätasolla ja keskittyä kuvaamaan tavoitteita rakennettavan kokonaisuuden käyttökokemukselle, toimintojen käytölle ja ylläpidolle.

Tämä asettaa omat laadulliset haasteensa tarjouspyyntödokumentaatiolle, sillä määrittelyjen tulisi olla riittävän tarkalla tasolla toteuttajakumppanikandidaattien työmääräarviointia varten, mutta samalla niissä tulisi olla paljon väljyyttä kandidaattien omille ehdotuksille toteutustavoista.
Pohjapainotteisen verkkopalveluprojektin vaatimusmäärittelyyn ei oikeastaan kannattaisi sisällyttää näyttöjen käyttöliittymämalleja lainkaan. Konseptin avainasiat kuvataan toki, ja yleiset käyttöliittymäperiaatteet tai käytettävyystavoitteet kannattaa esittää, mutta varsinainen käyttöliittymäsuunnittelu on hyödyllistä jättää kokonaisvaltaiselle kumppanille. Näin kumppanin suunnitteluryhmä pääsee paremmin sisäistämään palvelukonseptin ja sitoutumaan konseptin ilmentymistapoihin, kun he ovat omalla työllään hakeneet konseptia tukevat esitystavat ja mallit.

Kun suunnittelu ja toteutus hankitaan yhdeltä kokonaisvastuulliselta kumppanilta, voi kumppani myös valita projektin vaiheiden läpivientiin mallin, jonka eniten kokee omakseen, ketterän tai inkrementaalisen tai minkä vain.

Kumman projektimallin valitsemme?

2014-06-02 05.12.47 am