Verkkopalveluprojektien top-10 haasteet vuonna 2009

Tässä artikkelissa on listattu käytännön kokemuksen kautta syntyneitä havaintoja verkkopalveluprojekteista. Haasteet on listattu niiden arvioidun yleisyyden ja merkittävyyden mukaiseen järjestykseen. Listalla on yleisiä haasteita, palvelutoimittajiin liittyviä haasteita sekä asiakasnäkökulmaan liittyviä.

Haaste 1: Asiakkaiden ja käyttäjien odotukset kasvavat nopeammin kuin mihin teknologia kykenee vastaamaan

Yhä useammin oman firman intranettiä verrataan Facebookiin ja valitetaan miksei homma toimi kuten Facebookissa. Pahimmillaan vielä argumentoidaan Facebookin olevan ilmainen ja oman intran sentään maksaneen satoja tuhansia euroja. Tavallisella web-käyttäjällä onkin nykyisin käytettävissään miljoonien eurojen ohjelmistot täysin ilmaiseksi. Googlen, Microsoftin ja kumppaneiden hyperkilpailu on luonut varsin mielenkiintoisen asetelman. Harva tavallinen käyttäjä hahmottaa, että suosituimpien ilmaispalveluiden takana saattaa olla satoja ihmisiä kehittämässä palvelua ja työtä on saatettu tehdä jo vuosia. Esimerkiksi moni verkkopalvelun omistaja haluaisi videopalvelunsa sisältävän samat ominaisuudet kuin YouTube. Yllätys voi olla suuri kun ratkaisutoimittaja kertoo hintalapun olevan karsitullekin YouTube-kopiolle helposti puoli miljoonaa euroa.

Haaste edellyttää vahvempaa liiketoimintasuunnittelua ja projektien perusteiden rakentamista. Käyttäjien tarpeita on kuunneltava, mutta vain liiketoiminnallisesti tärkeisiin vaatimuksiin kannattaa vastata.

On myös suositeltavaa harjoittaa avointa viestintää käyttäjille päin, jotta useammat avainhenkilöt ymmärtävät, että isojen verkkopalveluiden kehittäminen ja käyttöönotto ei ole menossa halvempaan ja yksinkertaisempaan suuntaan.

Haaste 2: Julkaisujärjestelmät eivät ole lähteneet kovin ketterästi mukaan Web 2.0 -maailmaan

Monia järeitä web-sisällönhallintajärjestelmiä kehitetään jopa satojen ihmisten voimin, mutta on eri asia kehittää monikäyttöistä alustaa kuin yksittäistä palvelua. Tästä syystä Googlenkin askeleet kohti yrityksiä ovat olleet pieniä ja varovaisia. Täten on myös epätodennäköistä, että julkaisujärjestelmien ja esim. Facebookin välinen ominaisuuskuilu katoaisi lähitulevaisuudessa. Monet järjestelmätoimittajat ovat toki ryhtyneet vannomaan sosiaalisen median, semanttisen webin ja sähköisten työpöytien nimiin viime aikoina, mutta kuilu Googlen ja kumppaneiden ominaisuuksiin tulee varmasti pysymään.

Haaste edellyttää julkaisujärjestelmiä kehittäviä tahoja keskittymään vain tiettyihin käyttötapauksiin. Asiakkailta haaste vaatii kirkasta verkkostrategiaa eikä päätöntä ominaisuuskilpailua jossa omaan verkkopalveluun halutaan milloin mitäkin ominaisuuksia. “Paraskaan” järjestelmä ei taivu kaikkeen.

Haaste 3: Iso kasa ominaisuuksia ei korvaa strategisen näkemyksen puutetta

Kaiken Web 2.0 -huuman keskellä on vaikea säilyttää malttinsa kun uusia ja upeita juttuja keksitään koko ajan. Ymmärrettävää. Valitettavasti se ei ole strategia, että “haluaa kaiken”.

Uusista jutuista vain murto-osa päätyy pitkäkestoiseen käyttöön organisaatioiden verkkopalveluissa. Moni yritys on vasta nyt löytänyt sähköpostisuoran, verkkokaupan ja Google Adwordsin. Blogit, hakukoneoptimointi ja moni muu ovat vasta nousemassa tavallisten verkkopalveluiden valtavirtaan.

Hyviä verkkopalveluita ei tehdä ominaisuuksien määrällä – vaikka mediatalojen sivustoja katsomalla sellaisen illuusion saattaa itselleen pystyä rakentamaan.

Tämä haaste koskettaa erityisesti asiakkaita, mutta välillisesti myös projekteja toteuttavia osapuolia. Mitä enemmän hankkeen strategia on hukassa ja hajallaan, niin sitä todennäköisemmin projektissa tulee ongelmia tai erimielisyyksiä. Selkein merkki strategian puutteesta on, että vaatimusmäärittely kattaa kaiken mahdollisen sosiaalisesta nettiTV:stä aina mobiilisti toimiviin ryhmätyötiloihin ja googlemaisesti toimiviin personoituviin hakutoimintoihin.

Haaste 4: Projektin alkuvaiheessa lukittavat aikataulut

Edelleen on kummallisen yleistä, että asiakastaho näkee omaksi roolikseen vain vaatimusmäärittelyn ja laadun valvonnan. Massiivisen määrittelydokumentin valmistuttua projekti kilpailutetaan ja toteutukselle annetaan neljä kuukautta aikaa. Sitten kun homma on runnottu kasaan niin asiakas aloittaa kirjoittamaan virhelistaa ja valittamaan laatuongelmista. Esimerkki on hyvin kärjistetty, mutta ei täysin irrallaan todellisuudesta.

Verkkopalveluiden kehittäminen ja uudistuksien käyttöönotto tapahtuu parhaimmillaan vaiheistetusti ja yhteistyössä käyttäjien kanssa. Tiukat projektiaikataulut ja perinteiset vesiputousmallit ovat usein ristiriidassa käyttäjien arkitodellisuuden kanssa. Uudistuksien ajaminen sisään kertarysäyksillä on hyvin harvoin käyttäjien toivoma tapa. Lisäksi verkkopalveluille ja sisällönhallintajärjestelmille on tyypillistä käydä läpi julkaisun jälkeen pitkähkö sopeutusvaihe jossa ominaisuudet hiotaan ja viimeistellään käyttäjien haluamiksi.

Kaikkeen uuteen teknologiaan liittyy myös tarve kyseenalaistaa alkuperäisiä suunnitelmia toteutusvaiheessa. Projektitiimi voi oppia uusia asioita järjestelmästä projektin aikana tai asiakas voi nähdä tuotteen tarjoamat mahdollisuudet uudella tavalla. Tämän oppimisen vieminen käytäntöön vaatii neuvotteluvaraa aikatauluihin ja ketteriä projektimenetelmiä.

Tiivistetysti: Tiukat ja joustamattomat aikataulut tuottavat tyytymättömiä käyttäjiä ja huonoa teknistä laatua. Jos aikataulut on pakko lukita etukäteen, niin näihin seurauksiin on varauduttava. Piste.

Haaste 5: Resursointiongelmat ja arkkitehtuuriosaamisen niukkuus

Viides haaste koskettaa lähes ainoastaan projektien toteutusvaiheita ja liittyy toimittajien toimintatapoihin. Verkkopalveluiden toteutus edellyttää poikkeuksellisen laajan teknologiapaletin hallintaa. Tällaisia todella osaavia suunnittelijoita ja arkkitehtejä on Suomessa hyvin rajallinen määrä. Erityisesti laajojen sisällönhallinta- ja portaalituotteiden kohdalla vaaditaan laajaa ymmärrystä koko paletin mahdollisuuksista.

Junioritekijät päätyvät yleensä koodaamaan enemmän ja nostavat näin projektien hintaa ja tuovat haasteita ylläpidolle. Kokeneilla tekijöillä taas on niin paljon kysyntää koko ajan, että heitä on vaikea saada mukaan projekteihin. Tämä haaste lienee varsin pysyvä alalla joka ottaa käyttöön jatkuvasti uutta teknologiaa ja jossa kilpailu on armotonta.

Fiksut asiakkaat näkevät tämän jo sopimusvaiheessa ja vaativat mustaa valkoiselle tiimin kokoonpanosta ja käytettävyydestä. Ei ole ollenkaan harvinaista että tarjouksissa tarjotaan tiimiin tekijöitä jotka on jo kiinnitetty lähes kokonaan muihin projekteihin.

Projektiliiketoiminnan yksi suurimpia haasteita on resurssien optimointi ja tämä optimointi on usein ristiriidassa projektien laadun kanssa. Asiakkaan kannalta parhaita keinoja helpottaa tilannetta on panostaa konsepti- ja arkkitehtuurisuunnitteluun sekä sallia neuvottelu tavoiteaikatauluista projektin aikana. Usein juuri tiukat aikataulut johtavat tilanteisiin joissa homma runnotaan kasaan niillä tekijöillä jotka sattuvat olemaan saatavilla. Seurauksena on lähes aina laatuongelmia myöhemmässä vaiheessa. Osaavia tekijöitä ei vain ole rajattomasti.

Haaste 6: Valitseminen kokonaisuudistuksen ja vaiheittaisen kehittämisen välillä

Kuudes haaste liittyy erityisesti asiakkaiden näkökulmaan verkkopalveluiden kehittämiseen.

Nykyisin verkkopalveluita kehitetään jatkuvana prosessina. On hyvin tyypillistä, että kerran rakennettuun palvelukokonaisuuteen tehdään muutaman vuoden aikana useita kymmeniä pienempiä parannuksia ja laajennuksia. Pienet kehitysprojektit saavat helpommin vihreätä valoa ja tuottavat nopeita tuloksia. Tarve isommalle uudistukselle tiedostetaan, mutta vuosia rakennettu järjestelmäkokonaisuus ei ole helppo uudistettava. Joskus täysremontti on kuitenkin paikallaan. Sopivan hetken tunnistaminen ei vain ole helppoa.

Nykyisin on tarjolla paljon vaihtoehtoja kokonaisuudistukselle. Ominaisuuksia voidaan lisätä käyttämällä kolmansien osapuolien palveluita ja laajennuksia. Järjestelmiä voidaan myös räätälöidä nykyisin aiempaa kevyemmin kun kaikkea ei tarvitse aina koodata alusta asti.

On kuitenkin monia toiminnallisuuksia joita ei ole mahdollista rakentaa vanhan alustan päälle kovinkaan ketterästi. Tällaisia ovat yleensä mm. kehittyneet hakutoiminnot, käyttäjäprofiilit, sisältöjen automaattinen suosittelu ja käyttöoikeuksien tarkempi hallinta.

Asiakkaiden kannalta kehityksen suunta on haastava, koska arkkitehtuurinäkemystä tarvitaan yhä enemmän myös ostajan puolella. Enää ei kannata vain lähettää kasaa tarjouspyyntöjä maailmalle ja odottaa toimittajien esittävän parhaat ratkaisut. Tulevaisuuden mahdollisuudet riippuvat paljolti tehdystä alustaratkaisusta ja erilaisten alustojen tulevaisuutta on vaikea ennustaa.

Kaikki tämä edellyttää, että joko asiakkaalla on itsellään vahvaa näkemystä alan kehityksestä tai saatavilla on kumppaneita joiden liiketoiminta ei ole riippuvainen jatkuvista koodausprojekteista, lisäräätälöinnistä tai järjestelmäpäivityksistä. Huomattavaa on myös se, että mainostoimistoista ei tähän rooliin ole. Harva ns. “digitaalinen mainostoimistokaan” hahmottaa kovin suuria kokonaisuuksia ja pystyy katsomaan kokonaisuutta asiakkaan näkökulmasta.

Haaste 7: Jatkuvan kehityksen palveluntarjoajien vähäisyys

Verkkopalveluiden tietojärjestelmiä toimittavat palveluntarjoajat elävät vielä vahvasti isojen uudistusprojektien maailmassa. It-talot haluavat isoja projekteja ja puskevat asiakkaille näitä kankeita mammuttijärjestelmiä riippumatta asiakkaiden tarpeista. Mainostoimistot eivät ole sen parempia. Useimmat haluaisivat koodailla kokonaisuudesta irrallaan olevia Flash-saitteja ja katsovat asioita erittäin kampanjalähtöisesti. Mainostoimistot myös kunnostautuvat usein julkaisujärjestelmien haukkumisessa, koska järjestelmien olemassaolo tehokkaasti heikentää mainostoimistojen tuottoisaa Flash-saittibisnestä.

Markkinoilla on krooninen pula osaajista ja yrityksistä jotka olisivat keskittyneet jatkuvan kehityksen palvelutarjontaan. Suomalaiset verkkopalvelut elävät edelleen aivan liikaa massiivisten uudistusprojektien kautta. Uudistusten välissä verkkopalvelut uinuvat ruususen unta ja ylläpidosta maksetaan vaikka mitään ei tehtäisikään.

Tämän haasteen ratkaisu edellyttää asiakkailta ajattelutavan muutosta. Markkinointi- ja viestintävetoisesta projektitoiminnasta tulee siirtyä yhä enemmän pitkäjännitteiseen palvelu- ja sisältötuotantoon jossa pääpaino on jatkuvassa inkrementaalisessa kehittämisessä.

Esimerkiksi Aki Björklundin artikkeli “A website is never done” antaa kehittäjän näkökulman siihen miten parhaat web-innovaatiot syntyvät nykyisin. Lyhyesti: Ne eivät synny tiukassa tilaaja-tuottajamallissa jossa kiinteät projektit ovat ainut sopimusmuoto.

Haaste 8: Lanseerauksen merkityksen aliarviointi

Verkkopalveluprojekteja tehdään helposti liian pienessä piirissä ja oma henkilökunta saattaa lukea uudistuksesta jopa lehdistötiedotteesta. Tämä on omiaan herättämään negatiivisen arvostelun ja tähän ei millään yrityksellä pitäisi olla varaa. Jopa uusi intranet saattaa vain ilmestyä henkilökunnan käyttöön ilman sen kummempia ennakkotiedotteita, koulutuksia tai esittelytilaisuuksia.

Etenkin jos sisällöntuotantoon halutaan sitouttaa laajempi joukko ihmisiä niin uuden palvelun lanseerauksessa tulisi soveltaa samoja oppeja kuin minkä tahansa uuden tuotteen kohdalla. Avainvaikuttajat tulee sitouttaa ajoissa, viestintä tulee suunnitella etukäteen, koulutukset tulee järjestää ja lanseerauksen pitää tapahtua rytinällä. Sisältöpalveluiden kohdalla hiljainen beta-vaihe ja pilottistrategia ovat myös suosittuja, mutta yhtä lailla nämäkin tulee suunnitella osana kokonaisuutta.

Verkkopalvelut ovat yhä merkittävämpiä tietojärjestelmäprojekteja. Useampien alan toimijoiden kannattaisi tutustua esimerkiksi toiminnanohjausjärjestelmien käyttöönotoista opittuihin asioihin. SAP-tietojärjestelmiä ei viedä organisaatioihin matalalla profiililla. Tästä pitäisi ottaa oppia.

Haaste 9: Sisältöjen siirron työllistävyyden aliarviointi

Sisältöjen siirron haasteiden osalta tilanne on vuosien varrella parantunut, koska useammilla alan ihmisistä on jo takana useita projekteja. Esimerkiksi viestintä saattaa nykyisin jo projektoida erillisen projektin pelkästään sisältöjen siirrolle, kehittämiselle ja sisällöntuottajien koulutukselle.

Siirtojen kanssa kohdataan yleensä ongelmia kaikissa projekteissa. Automaattinen siirto on yleensä mahdollista vain hyvin rajalliselle määrälle sisältöjä ja vaadittava henkilötyömäärä usein yllättää. Ongelmat sisältöprojektissa onkin tyypillisin julkaisuaikataulun viivästyttäjä.

Sisällöntuotantoon ja lanseeraukseen tulisi aina perustaa oma projektinsa joka johdetaan samalla tarkkuudella kuin varsinainen teknologinen uudistusprojektikin.

Haaste 10: Yhteensopivuusongelmat kirjavien päätelaitteiden kanssa

Web-standardeista ja moderneista selaimista huolimatta verkkopalveluiden kehittäminen päätelaiteriippumattomasti on käytännössä mahdotonta. Asiakkailla on houkutus luetella vaatimusmäärittelyssä kaikki selaimet IE6:sesta Operaan, Chromeen ja Windows Mobileen. Toteuttajat sitten joutuvat selittelemään kun viikkojen testaamisen ja korjaamisen jälkeenkään palvelu ei toimi virheettömästi edes IE:n ja FF:n uudemmilla versioilla. Pelkästään järkevän selainyhteensopivuuden saavuttaminen on verkkopalveluprojektien megahaaste johon tarvitaan tehtävään erikoistuneita osaajia.

Minikannettavien ja mobiililaitteiden kehittyessä haasteet vain kasvavat. Eri päätelaitteiden tukemisesta tulisi neuvotella jokaisen palvelun kohdalla erikseen ja etukäteen. Palveluntarjoajat lupailevat herkästi liikoja joten tämä haaste vaatii asiakkailtakin ymmärrystä, koska tilanne ei näytä olevan menossa pelkästään parempaan suuntaan.

Yhteenveto: Asiakkailta ja toimittajilta tarvitaan monimutkaistuvassa verkkomaailmassa entistäkin parempaa yhteistyötä. Toisaalta asiakkaan rooli edellyttää yhä enemmän näkemystä – tai kykyä haalia näkemystä ympärilleen. Myös projektien käytännön tekemisestä alkaa nykyisin olla jo paljon kokemusta alalla. Kokemuksen tuomia oppeja ei kuitenkaan sovelleta projekteissa automaattisesti – ei asiakkaan puolelta eikä toimittajan toimesta. Verkkopalveluprojektien menestyksekäs läpivienti on edelleen erityistaito johon kannattaa panostaa.

Tämä artikkeli on kirjoitettu, koska haasteista on tärkeätä keskustella ennen kuin ne muuttuvat ongelmiksi ja vievät projektit kriisitilaan.