Asiakas on tärkein, eikö niin?

Viikolla twitterissä levisi kirjoitus viestinnän tärkeydestä suhteutettuna panostuksiin. Tärkeinä pidetyt asiat ja niihin resursointi osoittaen arvostuksen on arkisen ahertamisen suurimmista ristiriidoista ja turhautumisen aiheista.

Olen saanut mahdollisuuden seurata ulkokehällä uusien maakuntien verkkopalvelujen kehittämistä. Viime viikolla oli ensimmäinen yhteisseminaari, joten vaikka työtä on tehty jo jonkin aikaa, ollaan vielä alkumetreillä sitouttamassa yhä suurempaa joukkoa mukaan.

Alla oleva perustuu täysin omaan kokemukseen esitetyistä luonnoksista ja vajavaiseen tietämykseen kaikesta taustalla jo pohditusta ja suunnitellusta.

Unelmatilanne kehittäjille

Kun ajatellaan maakunnan verkkopalvelua riippumatta siitä, kuinka järkevänä uuden hallintohimmelin rakentamista pitää, verkkoviestijälle ja digikehittäjälle optimaalisempaa tilannetta ei voisi olla: palvelun rakentaminen voidaan aloittaa tyhjältä pöydältä ilman menneen painolastia.

Kuinka usein tällainen mahdollisuus on olemassa. Käyttäjiä ei tarvitse opettaa pois vanhoista toimintatavoista, eikä nykyisen verkkopalvelun sisältöjaottelut tai sisällöntuotannon toiminnallisuudet kummittele taustalla ohjaamassa uutta tekemistä.

Julkishallinnon selkeä suuntaus kohti asiakas- ja elämäntapahtuma-keskeistä digimaailmaa on hyvä konsepti ja helpompi toteuttaa ilman taustalla olevia siiloja ja vanhoja taustajärjestelmiä.

Täysin uuden, innovatiivisen ja tulevaisuuteen katsovan verkkopalvelun rakentaminen vaatii kuitenkin digitaalista ja verkkoviestinnällistä ymmärrystä, näkemystä ja jopa intohimoa. Sekä aikaa pohtia.

Tukea kehittäjille tarvitaan

Ja tässä nousee esiin alussa mainittu viestinnän yhteydessä mainittu panostus ja arvostus. Suurin osa yhteisseminaarin skype-keskustelijoista vaikutti olevan erikokoisten kuntien ja organisaatioiden viestintä- ja IT-asiantuntijoita. Verkkoviestinnällinen osaaminen ja tulevaisuuden ratkaisut eivät tuntuneet olevan monillakaan arkisessa ahertamisessa keskeisessä roolissa.

Tämä tuntemus on vain henkilökohtainen oletus, ei millään lailla faktaan perustuvaa.

Uusimaa 2019 -hankkeen verkkoviestintäasiantuntijan Anja Asuntan esityksestä hahmoteltu maku.fi:n päänavigaatio ja kohderyhmät.

Työpajassa keskustelua käytiin pääasiassa verkkosivujen päänavigaation otsikoista ja kohderyhmistä.

Diplomaattisesti todeten skype-keskusteluun tuodut ehdotukset jatkavat hyvin julkishallinnon 90-luvulta lähtöisin olevia perinteitä organisaatiolähtöisyydellään. Keskustelussa useilla oli olennaista, mistä löytyvät jatkossa oman organisaation sisällöt, ja pääpaino oli termien viilauksessa.

Samaten laajan kohderyhmälistauksen osalta huoli oli enemmän kohderyhmien lisäämisestä kuin karsimisesta käyttäjälle hahmotettavaksi kokonaisuudeksi, ja banneri oli ratkaisu asioiden korostamiseen.

Onneksi työryhmien tuloksia purettaessa nykypalvelujen statistiikka nostettiin olennaiseksi niin terminologian kuin kohderyhmien tarkentamisen osalta.

Asiakas, elämäntilanteet tai uudet tekemisen tavat eivät tässä skype-keskustelussa vilahdelleet, saati sitten että ne olisivat päässeet parrasvaloihin. Toiminnallisuuksista innovatiivisinta osuutta olivat hyvä haun kaipuu sekä paikkatiedon hyödyntäminen. Teknisen toteutuksen roadmapilla sivupohjat toteutetaan ennen kuin sisältöjen tekemisessä päästään vauhtiin, jolloin niiden jatkokehitykseen tarvitaan resursseja rinnan.

Miten eteenpäin?

Tämä postaus on ilman muuta huolen ja turhautumisen purkamista. Mutta samalla se on pieni hätähuuto maakunnan asukkaana.

Kaikki osallistujat tekevät varmasti kehittämistyötä intohimolla kaivaen aikaa kansalliseen pohdintaan ja rakentamiseen. Ja #makufi-tägillä twitterissä keskustellen osallistujat tuntuvat olevan erittäin tyytyväisiä työpajan antiin.

Erinomaista on myös pyrkimys tehdä yhdessä uutta sen sijaan, että jokainen miettisi ikiomia ratkaisujaan, jolloin työsarka olisi moninkertainen. Haaste kuitenkin on, että osaaminen ja näkemykset eivät ole kovin innovatiivisia, eikä oman toimen ohessa uurastettaessa voi sitä vaatiakaan.

Sen sijaan meille kaikille ihan uutta luovat tarvitsevat ja ansaitsevat tukea ja resurssointia. Että joku auttaa heitä hahmottamaan, miten 2020-luvulla käyttäjä tarpeineen on verkkopalvelussakin keskiössä, miten oman organisaation sisällöt  jatkossa löytyvät luontevasti muiden seassa elämäntapahtuman palvelujen osana ilman vilkkuvia bannereita.

Graaffit ovar Varsinais-Suomen Kimpassa-Allihopa-viestintäpäällikkö Jessica Ålgars-Åkerholmin esityksestä alueen käyttäjäkyselyn tuloksista

Varsinais-Suomessa tehty käyttäjäkysely osoittaa, että halua käyttää ennen kaikkea digipalveluja modernisti on.

Jos/kun uusi hallinnon taso halutaan, sen toteuttaminen meille kansalaisille parhaaksi mahdollliseksi digipalveluksi, pitäisi olla työlistan kärjessä.

Nyt nähtävästi useampi hanke miettii vähän samaa tiiviin yhteistyön sijaan. Lisäksi avainroolissa on luonnollisesti myös muu julkishallinnon digikehittäminen VRK-johtoisesti. Mutta jos yhteistyö tapahtuu ensin omia digipalveluja tuputtamalla, asiakas tarpeineen jää jälleen panttivangiksi takapenkille eri organisaatioiden taistellessa ohjauksesta.

Kuka voisi tarjota organisaatioiden näkökulman unohtaen visionäärisyyttä niin konseptointiin että sisältöjen suunnitteluun sekä resursseja toteutukseen, jotta me kansalaiset saamme helppokäyttöisen ja tulevaisuutta peilaavan verkkopalvelun, joka räätälöityy tarpeidemme mukaisesti?

Me kaikki ansaitsemme sen.

Ensimmäisen työpajan materiaalit löytyvät verkosta, joten jokainen voi muodostaa oman näkemyksensä ja kenties auttaa ja tukea rakennustyötä.

Lue lisää

• vimana.fi: Ensimmäisessä Makufi-seminaarissa luotiin yhteistä näkymää maakuntien tuleviin verkkopalveluihin (10.08.2018)
  • Makufi-hankkeessa rakennetaan maakuntien verkkosivustoja yhteistyöllä (16.04.2018)
• kuntalehti.fi: Tempaus vaati lisää ytyä kuntien viestintään – kaupunginjohtaja myöntää ongelman (09.08.2018)

 

Mainokset

Hektisen kehittämisvaiheen jälkeinen elämä – pari sanaa verkkopalvelun rakentamisesta, 5

Kirjoitan verkkopalvelun kehittämisestä viisi postausta omien kokemusten pohjalta täysin subjektiivisesta näkökulmasta. Tämä on sarjan viimeinen kirjoitus.

1. Pitää olla visio
2. Puitesopimuksella ja esiselvityksellä mielenrauha
3. Käyttäjän näkökulmasta tarinoiden
4. Ketterästi rakentaen

5. Hektisen kehittämisvaiheen jälkeinen elämä

Kenties 1990-luvulla verkkosivu-uudistuksen jälkeen hanskat saattoi lyödä tiskiin pitkäksi aikaa ja ihailla kättensä jälkiä, mutta nykyään massiivisemmankin projektivaiheen jälkeen jatkokehityslista on pitkä. Sprinttien priorisointilistalla nice to have -ominaisuuksia jää paljon toteuttamatta, ja toiminnallisuuksien karvalakkiversiot kaipaavat ehostusta. Lisäksi nopeasti kyhään kasatut sisällöt vaatisivat huomiota, kun työkalut ja uusien toiminnallisuuksien mahdollisuudet tulevat tutuiksi.

Meillä projektin loppumetreillä hengähtäminen jäi haaveeksi. Jostain syystä verkkopalvelun julkaisun jälkeen viimeiset toteutukset rikkoivat paljon palvelun perusvakaudessa, ja jo saavutetun toimivuuden palauttaminen kesti pitkään. Samalla virhelistan korjaaminen vei resursseja muulta viilaukselta.

Todennäköisesti syntyneeseen tilanteeseen vaikutti paljon toteutusajan puolittuminen, jolloin laadukkaan koodin vertaisauditoinnista huolimatta ratkaisut eivät olleet optimaalisimpia vaan nopeimpia.

Pienkehittäen ja yhteistyöhön pyrkien

Varsinaisen projektin päätyttyä puitesopimustoimittajien kesken kilpailutettiin palvelun ylläpito ja pienkehitystyö. Suuremmat toteutukset on edelleen minikilpailutettu toimittajien kesken.

Virheemme on ollut, ettemme liittäneet ylläpitosopimukseen kokonaisarkkitehdin roolia, jolloin eri toimittajien uusien toiminnallisuuksien kehittäminen ei ole välttämättä aina perustunut yhteneväisiin ratkaisuihin. Samalla kun toimittajien projektivaiheen tiivis yhteishenki purkautui, kommunikointi ja vastuiden jako on ollut toisinaan haasteellista.

Tulevaisuuden visio on myös paljolti kiinni siitä, miten intohimoisesti verkkopalveluun suhtaudutaan.

Verkkopalvelun uudistuksen jälkeen vision päivittäminen on äärettömän tärkeää. Mikä on uuden verkkopalvelun rooli, mihin suuntaan niin sisällöllisesti kuin teknisesti kokonaisuutta kehitetään? Minkälainen on se Tesla, johon pyritään?

Verkkopalvelun omistajan rooli ja näkemys on tärkein jatkon kannalta.

Meillä tämä on jäänyt utuiseksi ja hahmottumattomaksi. Verkkopalvelu on pääasiallinen viestintäkanavamme -mantraa ei ole mietitty toiminnallisesti tai sisällöllisesti.

Kehityslistan työlistalla on paljon ominaisuuksia, jotka modernisoisivat entisestään verkkopalvelua. Samaan aikaan resurssit on käytetty ennen kaikkea olemassa olevien, ja erityisesti sisällöntuotannon, ominaisuuksien kehittämiseen, kun selkeää visiota tulevaisuuden verkkopalvelusta ei ole. Kuitenkin kehitystyö jatkuu koko ajan.

Tulevaisuuden visio on siis myös paljolti kiinni siitä, miten intohimoisesti verkkopalveluun suhtaudutaan.

Vaikka verkkoviestinnällinen näkökulmamme on vielä sumea, selkeä tahtotila on ollut virheistä viilatun kokonaisuuden jakaminen muille avoimesti hyödynnettäväksi.

Verkkopalvelun koodi on jaettu vapaasti hyödynnettäväksi.

Kunta.fi-koodi avattiin vuosi verkkopalvelun viimeistelyn jälkeen kokonaispakettina. Kuka tahansa voi ottaa lähdekoodin käyttöönsä ja tehdä sillä, mitä haluaa. Yhteistyöhön onkin ryhtynyt useampi taho Kuntaliiton koordinoimana.

Digitaalinen on ensisijainen palvelukanava

Verkkopalvelun rooli on siirtymässä verkkoviestinnästä yhä enemmän digitaalisiin palveluihin ja käyttöliittymä-ajatteluun. Jo lakitasolla on määritelty, että digitaalinen vaihtoehto on ensisijainen palvelukanava.

Kaupungin siirtyessä kohti modulaarista arkkitehtuuria verkkopalvelu esittää ja hyödyntää samoja komponentteja ja tietoja kuin useat muut kaupungin digipalvelut ja taustajärjestelmät. Yhä enemmän tieto tehdään vain kerran ja hyödynnetään rajapintojen kautta ja tekoälyn avulla monipuolisesti.

Tieto siis liikkuu palvelusta ja palveluun, esimerkiksi tapahtumakalenterin tiedot ovat kenen tahansa käytettävissä, ja parhaillaan rakentuu digitaalisen kaavoituksen näkymä, johon kaikki tieto ja toiminnallisuudet tulevat taustajärjestelmistä.

Samalla kun kansalliselta tasolta lähtien yhteiskunta on muuttumassa ennakointikykyiseen ja ihmiskeskeiseen ajatteluun, niin verkkoviestinnän rooli ja verkkosisältöjen esittämistapa kokee myllerryksen.

Uusi uurastus on meillä kaikilla taas pian edessä.

Lyhyt muistilista Kehittämisvaiheen jälkeen uudistettu visio ohjaa kaikkea kehittämistä Painopiste siirtyy yhä enemmän verkkopalvelussa käyttöliittymä-ajatteluun, jolloin tieto tehdään muualla ja näytetään eri tavoin verkkopalvelussa Digitaalinen kanava on ensisijainen palvelukanava

Kokonaisuuden postaukset

1. Pitää olla visio
2. Puitesopimuksella ja esiselvityksellä mielenrauha
3. Käyttäjän näkökulmasta tarinoiden
4. Ketterästi rakentaen
5. Hektisen kehittämisvaiheen jälkeinen elämä

Ketterästi rakentaen – pari sanaa verkkopalvelun rakentamisesta, 4

Kirjoitan verkkopalvelun kehittämisestä viisi postausta omien kokemusten pohjalta täysin subjektiivisesta näkökulmasta. Tämä on sarjan 4. kirjoitus. Pahoittelut, että postaus on ennätyksellisen pitkä vuodatus.

1. Pitää olla visio
2. Puitesopimuksella ja esiselvityksellä mielenrauha
3. Käyttäjän näkökulmasta tarinoiden

4. Ketterästi rakentaen

Varsinaisen verkkopalvelun rakentamisvaiheen osalta työmäärä ja alla olevan tekstin osuvuus riippuu hyvin paljon siitä, lähdetäänkö liikkeelle tyhjältä pöydältä, kuten me teimme. Tai onko käyttöön tulossa jokin valmistuote tai esimerkiksi kunta.fi-toteutuksen kaltainen avoimen lähdekoodin toteutus, joita vain tuunataan omaan käyttöön sopivaksi.

Riippumatta työmäärästä kehittäminen vaatii paljon mielikuvitusta, mielikuvaharjoittelua, sillä kuten kollegani joskus totesi, verkkoviestintä vaatii spatiaalista ajattelua. Verkkopalvelussa liikkuminen ja toimiminen tapahtuu monella tasolla, myös syvyyssuunnassa. Kirkas visio niin kokonaisuuden kuin toiminnallisuuksien yksityiskohtien osalta on siis tarpeen.

Visuaalisuus mukaan

Kun puitesopimustoimittajien kanssa viilailtiin sopimuksia valmiiksi, mainostoimiston kanssa pohdittiin verkkopalvelun visuaalisuutta. Kaupungin verkkopalvelu oli ensimmäinen uuden brändi-ilmeen ilmentymä. Mainostoimisto sai työhönsä suhteettoman vähän aikaa sisäisten aikataulujemme takia, joten heidän työsarkaansa ei käy kateeksi.

Jotta tilanne oli heille visuaalisesti vielä kiittämättömämpi, muokkasimme itse alkuperäisiä leiskoja enemmän tavoitteitamme vastaaviksi. Kaiken kruunuksi annoimme ne Drupal-toimittajillemme saatesanoilla ”tällaista fiilistä tavoittelemme”.

Yksi verkkopalvelun suurimmista kustannuksista voi syntyä siinä vaiheessa, kun mainostoimiston visio pakotetaan käytettävään tekniikkaan. Aiemmin visuaalinen ilme oli myös hyvin rajoittunut tiettyyn ruutukokoon, joten kaikki poikkeukset olivat haaste. Lähtökohtanamme oli mobiili ensin -ajattelu, mutta visuaalisen ilmeen osalta se mietittiin vasta toisessa aallossa.

Ketterän kehittämisen alkeet

Verkkopalvelun rakentaminen päätettiin tehdä ketterästi, mikä tarkoittaa valitulla Scrum-menetelmällä sitä, että

• työ eli käyttäjätarinoiden toteutus
• jaettiin 1-2 viikon jaksoihin eli sprintteihin,
• joiden päättyessä saimme aina uusia toiminnallisuuksia rakentuvaan verkkopalveluun.

Tekemistä seurattiin päivittäisissä dailyissä eli noin 15 minuutin skype-palavereissa, joissa käytiin aina läpi, mitä kulloinkin on tekeillä ja mikä mahdollisesti estää tekemistä.

Kanban-taulu työtehtävien seurantaan kertoo vasemmalta oikealle: – toiveiden tynnyrin – kehitykseen valitut käyttäjätarinat = toiminnallisuudet – parhaillaan työn alla olevat ominaisuudet – vertaisauditoinnissa oleva toteutus – tilaajan testaukseen tulleet ominaisuudet – valmiit toimivat ratkaisut

Työn etenemistä seurattiin yhteisillä työkaluilla ja ns. Kanban-taululla, jolloin kaikille oli kokonaiskuva näkyvillä:

• mikä on seuraavana tulossa kenellekin työlistalle
• missä vaiheessa jokin toteutus on
• mitä on jo valmiina.

Sprintit alkavat suunnittelulla, johon osallistuu koko koodaritiimi sekä ainakin tuoteomistaja. Suunnittelupalaverissa käydään läpi

• paljonko seuraavan sprinttijakson aikana resursseja on käytettävissä,
• mitä seuraavaksi on tavoitteena saada valmiiksi ja
• miten paljon työtä se vaatii.

Tuoteomistaja priorisoi resurssien ja työmääräarvioiden perusteella, mitkä käyttäjätarinat otetaan sprintissä työlistalle.

Olin jo ennen rakennustyön alkua ihastunut käyttäjätarinoihin ja ketterään tekemiseen, ja onnistunut toteutus on vain vahvistanut uskoani asian suhteen. Rakentaminen on hyvin läpinäkyvää ja kommunikointi on jatkuvaa. Enää ei tarvitse odottaa henkeä pidätellen ja peläten, mitä puolen vuoden kuluttua eteensä saa.

Ketterässä tekemisessä sitoudutaan joko

• kustannuksiin,
• aikaan tai
• toiminnallisuuksiin.

Kaikki kolme ovat liikkuvia osia ja riippuen tilanteesta jokin näistä on määräävin.

Vanhan ajan kehittämisessä sovitaan hyvin aikaisessa vaiheessa tarkka määrittely sekä siitä koituvat kustannukset ja toteutusaikataulu. Projektin lopussa saatiin hyvin usein myöhässä toimittajan tulkinta määrittelyistä, ja asiakkaiden oikeiden tarpeiden täyttäminen oli lisäkustannus.

Ketterässä kehittämisessä käytännössä ostimme työtä, jonka sisältö tarkentui tekemisen edetessä näkemyksen ja osaamisen syventyessä.

Pala kerrallaan edeten

Ennen töiden aloittamista mietimme ulkopuolisen toimijan kanssa, minkälaisissa kokonaisuuksissa ja missä järjestyksessä verkkopalvelu kannattaa rakentaa. Rakentamisen määrä voi tuntua mahdottomalta, mutta pilkkominen tuo rytmiä tekemiseen ja havainnollistaa, mitä kannattaa sisällöllisesti tehdä missäkin vaiheessa.

Varsinaisen ketterän kehitystyön aikaan kaikki kolme puitesopimustoimittajaamme tarjosivat resurssit käyttöömme ja kehitimme kokonaisuuksia tasaveroisesti yhdessä. Sovimme kuukausittain tehtävät toiminnallisuudet ja viikoittain, mitä kukin koodari kulloinkin rakentaa.

Yhteen toimittajaan verrattuna työaikaa kului enemmän alun valmisteluihin ja firmojen erilaisten käytäntöjen yhtenäistämiseen projektin ajaksi, mutta samaan aikaan saimme kaikilta toimittajilta koko firman osaamisen käyttöömme. Sen sijaan, että yhden toimittajan pitäisi opetella ja selvittää erilaisia ongelmanratkaisuja, aina jostain löytyi kokenut asiantuntija, joten työ eteni tämän osalta sujuvasti.

Toimintatapa oli ainutlaatuinen ja pääsimme ratkaisullamme finaaliin ensimmäisessä Blue Arrow Awards -kilpailussa. Olimme myös käsittämättömän onnekkaita, että eri toimittajien koodarien kemiat toimivat yhteen ja kaikki tulivat toimeen loistavasti.

Ketterästi kehittäen toiminnallisuuksia rakennetaan MVP (minimal viable product -ajattelulla) eli ensimmäisenä ei tavoitella täydellistä ratkaisua, vaan Teslan sijaan kokeillaan ensin potkulauta-versiolla toimiiko ajatus lainkaan ja voiko kevyempi ratkaisu ollakin jo riittävä.

Vaikka ketterä kehittäminen nopeuttaa tai ainakin tekee näkyväksi etenemisen, niin se ei auta, jos kesken projektin aikataulusta poistetaan puolet.

Priorisointitarve korostui ja epäilemättä kaikki tekniset tai sisällölliset ratkaisut eivät olleet optimaalisimpia tai kestävämpiä kiirehdittäessä, kun aiempi verkkopalvelu oli katoamassa bittiavaruuteen puoli vuotta alkuperäistä määräaikaa aiemmin.

Ketterän kehittämisen roolit

Avainpelaajia ketterässä kehittämisessä olivat meidän tapauksessamme

• tuoteomistajat kaupungin puolelta,
• heidän vastinparinsa Scrum masterit toimittajilta sekä
• koodaritiimi eri toimittajilta toteuksessa ja
• sidosryhmänä sisällöntuotannon vastuuhenkilöt kirjoittamassa uusia käyttäjätarinoita ja testaamassa syntyvien toteutusten toimivuutta tarpeisiimme.
• Ohjausryhmä koordinoi toimintaa ylätasolla kuukausittain toteutettavaksi sovittujen kokonaisuuksien osalta.

Varsinaisen sprinttivaiheen aikana tuoteomistaja ainoana tekee ratkaisut ja kantaa vastuun.

Tuoteomistajan rooli on kriittinen onnistuneen ja asiakasta palvelevan verkkototeutuksen syntymiselle. Tuoteomistajan tehtävänä on ohjata koodareiden työtä, priorisoida tarvittavia toiminnallisuuksia tilaajan näkökulmasta ja ennen kaikkea olla koodarien tavoitettavissa, kun koodaamisen aikana pitää päättää, mikä olisi toimivin ratkaisu.

Tästä johtuen tuoteomistajalla pitää olla luottamusta organisaation sisällä ja vapaus tehdä itsenäisesti ratkaisut. Toisaalta hänellä pitää myös olla visio, miten toiminnallisuuden pitää toimia, jotta hän voi ohjata koodaria oikeaan ratkaisuun. Tuoteomistaja on yksi henkilö, ei ryhmä, jossa kukaan ei kanna vastuuta.

Tässä onnistuimme vaihtelevasti.

Vaikka sprinttivaiheessa eli aktiivisen toteutuksen jaksolla ainoastaan tuoteomistaja ohjaa koodareita, niin ennen sprinttiä ja sen jälkeen käyttäjätarinoita kirjoittamassa on hyvä olla useampi henkilö. Joukossa on voimaa, kun mietimme toimivimpia toiminnallisuuksia, esimerkiksi miten haluamme saman sisällön näkyvän eri puolilla verkkopalvelua ja minkälainen työkalu olisi helpoin tämän toteutumiseen. Samaten sprintin lopulla tai jälkeen samat sidosryhmän jäsenet ovat parhaita arvioimaan, toimiiko uusi toteutus toivotulla tavalla.

Mutta varsinaisen sprinttivaiheen aikana tuoteomistaja ainoana tekee ratkaisut ja kantaa vastuun.

Tuoteomistajan haasteita

Matkan varrella eri toiminnallisuuksien ja siten eri tuoteomistajien kohdalla haasteena oli saada muita mukaan miettimään ratkaisuja. Usein näyttäisi olevan enemmän halukkuutta odottaa muiden miettivän ratkaisuja kuin omaehtoisesti ottaa selvää ja pohtia asioita.

Toisissa sprinteissä tuoteomistaja jätti koodarin oman onnensa nojaan uskaltamatta ottaa vastuuta tai hän halusi koota sidosryhmän uudelleen koolle saadakseen vastauksen koodarille, joka joutui odottelemaan ratkaisuja. Tästä johtuen ajanjaksolle suunnitellut työmäärät ja siten valmiit toteutukset jäivät vajaiksi.

Lisäksi vastuun kantaminen osoittautui toisinaan haasteelliseksi ja syyttävä sormi osoitti kaikkialle muualle kuin peiliin.

Toimin itse verkkopalvelu-kokonaisuuden tuoteomistajana ja koko kokonaisuutta koordinoivana. On tunnustettava, että sprintin aikana kiireessä, riittämättömällä osaamisella tehdyt ratkaisut olivat toisinaan vääriä, ja niiden korjaaminen myöhemmin oli kallista niin kustannusten kuin maineen kannalta. Tämä konkretisoitui erityisesti verkkopalvelun toiminnallisuuksien saavutettavuudessa. Aina ei voi voittaa ja tällöinkin vastuu on kannettava.

Edelle kirjattu osoittaa, miten sitovaa ketterä kehittäminen tilaajalle on. Riippuen tekeillä olevan toteutuksen laajuudesta tuoteomistajat pitäisi irrottaa muusta työstä keskittymään kehittämiseen.

Tämä ei onnistunut meillä kertaakaan, vaikka kokonaisuudet olivat toisinaan massiivisia. Lisäksi inhimillisten tilanteiden myötä, esimerkiksi koodarin lapsen sairastuttua, töitä kirittiin ja tarvittavia kehitysmuutoksia ratkottiin yhdessä lauantai-iltapäivänä.

Tuoteomistajan vastinpari on Scrum master, joka vastaa kehittämisen teknisestä puolesta. Hän  huolehtii koodarien yhteispelistä ja ratkoo mahdollisia ongelmia, esimerkiksi palomuuriavauksia tai selvittää puuttuvia tietoja. Scrum master voi olla niin tilaajan kuin toimittajan palkkalistoilla, mutta meillä ei tällaiseen tekemiseen ollut riittävää osaamista.

Yleensä ennen seuraavan sprinttijakson alkua tuoteomistaja ja Scrum master käyvät läpi minkälaisia toiminnallisuuksia ja missä järjestyksessä kannattaa seuraavaksi rakentaa.

Ja sprinttijakson päättyessä koko aktiivinen tekijätiimi eli tuoteomistaja, Scrum master ja koodarit käyvät läpi, mikä jakson aikana toimi ja missä voitaisiin parantaa.

Pienin askelin myös käyttäjille näytettävää

Ketterässä kehittämisessä jokaisen sprintin jälkeen tilaaja saa uusia toimivia ominaisuuksia rakentuvaan verkkopalveluunsa. Eteneminen on näkyvää ja sisältöjen tekeminen voi edetä lähes samaan tahtiin teknisen kehittämisen kanssa.

Samalla verkkopalvelun alpha- tai beta-version julkaiseminen loppukäyttäjien kokeiltavaksi on enemmän kuin suositeltavaa. Viimeistään tällöin pohditut ratkaisut tulevat testiin, ja sisältöjä ja toiminnallisuuksia voi kehittää järkevästi toteutustyön osana eikä jälkeenpäin päälle liimaten.

Erityisesti julkishallinnolle on aiemmin ollut haaste esitellä keskeneräistä ja osallistaa käyttäjiä kehitystyöhön. Tämä oli meilläkin sisäisesti suuri kynnys, kun vanhakantaiset näkökulmat velloivat projektiryhmän ulkopuolella, joten keräsimme alpha- ja beta-vaiheen palautteita rajoitetuilta sidosryhmiltä pitkin matkaa suljetussa ympäristössä. Vasta viime metreillä saimme avattua uuden verkkopalvelun beta-version yleiseen kommentointiin.

Käyttäjiä kannattaa haastatella ja haastaa toiminnallisuuksista, sillä mekin saimme pääasiassa kehuvaa palautetta beta-versiosta, kunnes se yhtäkkiä olikin ainoa käytössä oleva verkkopalvelu. Kritiikki oli armotonta, kun vanhat rutiinit enää auttaneetkaan tietojen löytymiseen uudessa verkkopalvelussa.

Huomioi verkkomaailman lainalaisuudet

Olennaista on myös kehittämisen ohessa miettiä verkkopalvelun ulkopuolista verkkomaailmaa. Esimerkiksi kaikkien olennaisten verkko-osoitteiden ohjaaminen uusiin sisältöihin on äärimmäisen tärkeää.

Tässäkin epäonnistuimme uuden verkkopalvelun alkumetreillä. Olimme keränneet ja uudelleen ohjanneet esitteissä ja vakiintuneessa käytössä olleita lyhytosoitteita, mutta vanhan julkaisujärjestelmän metrin pituiset osoitteet olimme jättäneet huomiotta.

Luonnollisesti hakukoneet olivat indeksoineet vanhat osoitteet ja uuden verkkopalvelun myötä kaikki vanhat osoitteet siirsivät käyttäjän etusivulle, jossa sisältölogiikka oli uusi ja hakumoottori vielä viilauksessa. Kaaos oli valmis, ja media mukana setvimässä asiaa.

Onneksi nykyaikana ja varsinkin suurten verkkopalvelujen osalta uusien sisältöjen indeksointi tapahtui parissa päivässä. Muutkin verkkopalvelun ontuvat ominaisuudet olivat toimintakunnossa kolmessa päivässä.

Media jäi tällä kertaa ketterän kehityksen jalkoihin, kun keskiviikkona ongelmista tehty haastattelu julkaistiin vasta viikonloppuna, jolloin jutun aiheena olleet virheet oli jo korjattu ja käyttäjiä neuvottiin jo väärin.

Vähillä resursseilla ja epävarmuudessa eläminen

Tekninen toteutus on kuitenkin aina vain pieni osa verkkopalvelua. Kyse on ennen kaikkea sisällöistä. Ketterän kehittämisen suurimpia haasteita on pienin askelin toiminnallisuuksien rakentuminen. Tämä tarkoittaa usein, ja ainakin meidän tapauksessamme, että sisällöntuotannon toiminnallisuudet kehittyivät ja muuttuivat koko ajan.

Kun edes avainhenkilöillä ei ole mahdollisuutta tai osaamista syventyä uusiin toiminnallisuuksiin, miten he olisivat kyenneet tukemaan sisällöntuottajia verkkosisältöjen rakentamisessa.

Keskeistä on, miten motivoituneita ja verkkoviestinnällisesti osaavia avainhenkilöt ovat. Otetaanko uudet työkalut käyttöön oma-aloitteisesti mielenkiintoisena haasteena ja tavoitteena kehittää ne mahdollisimman hyviksi nykyaikaisen verkkoviestinnän tarpeisiin? Tai odotetaanko passiivisena, että joku toinen antaa vastaukset ja opettaa kädestä pitäen? Julkishallinnossa ainakin painopiste tuntuu olevan jälkimmäisessä, eikä epävarmuudessa eläminen ole muutosvastarintaisille helppoa.

Ohjeistuksen jatkuva päivittäminen kannattaa vastuuttaa jollekulle muulle kuin tuoteomistajalle, sillä omasta kokemuksesta sekä teknisen rakentamisen ohjaaminen, jatkuva ohjeiden päivittäminen että sisältövaihtoehtojen ratkominen ovat liikaa yhdelle tekijälle.

Verkkouudistukset nähdään yleensä tarpeellisina, ja johto sitoutuukin syntyviin teknisiin kustannuksiin. Mutta sisältöjen osalta on ainakin omalla työuralla tilanne on ollut toinen. Verkkopalvelu mielletään monesti ”pääviestintäkanavana” ja termiä viljellään auliisti ulospäin, mutta sisältöjen tarvitsemaa työaikaa ei resurssoida, eikä verkkoviestinnälliseen osaamiseen ahkerasti panosteta, varsinkaan aktiivisimman kehitysvaiheen jälkeen.

On kuitenkin myönnettävä, kun projektimme ulkopuolella syvässä viisaudessa toteutusaikaa leikattiin, saimme aktiivisen lobbauksen jälkeen runsaasti lisäkäsiä sisältöjen siirtoon vanhasta verkkopalvelusta uuteen. Lisätyövoima ei kuitenkaan auta asiantuntevan sisällön tekemisessä, ainoastaan sen muotoilussa verkkoon.

Helposti myös verkkoprojektin ponnistelujen jälkeen avainhenkilöiden jaksaminen on kortilla, ja verkkosisällöt jäävät pitkäksi aikaa oman onnensa nojaan. Kannattaa siis panostaa ennen kaikkea sisältöihin uudistuksen aikana, sillä ne ohjaavat hakukoneiden kautta ihmiset tiedon äärelle ja vähentävät kuormaa muista kanavista.

Lyhyt muistilista Kehitysvaiheessakin sisällöt ja sisällöntuottajien tukeminen on tärkeintä Vastuutaulukko myös sisäisesti auttaa jakamaan ja hahmottamaan työtehtäviä Kannattaa huomioida miten nykyiset sisällöt löytyvät esimerkiksi hakukoneista tai muista palveluista Ketterä kehittäminen tuo läpinäkyvyyttä ja nopeutta mutta sitoo paljon resursseja Sisältöjen tekemiseen osaamista ja resursseja ei voi olla liikaa

Kokonaisuuden postaukset

1. Pitää olla visio
2. Puitesopimuksella ja esiselvityksellä mielenrauha
3. Käyttäjän näkökulmasta tarinoiden
4. Ketterästi rakentaen
5. Hektisen kehittämisvaiheen jälkeinen elämä

Käyttäjän näkökulmasta tarinoiden – pari sanaa verkkopalvelun rakentamisesta, 3

Kirjoitan verkkopalvelun kehittämisestä viisi postausta omien kokemusten pohjalta täysin subjektiivisesta näkökulmasta. Tämä on sarjan 3. kirjoitus.

1. Pitää olla visio
2. Puitesopimuksella ja esiselvityksellä mielenrauha

3. Käyttäjän näkökulmasta tarinoiden

Käyttäjätarina kuvaa nimensä mukaisesti käyttäjän näkökulman.

Ketterän kehittämisen mukaisesti kirjasimme verkkopalvelun konseptista syntyneet asiakasnäkökulmaan pohjautuvat toiminnalliset toiveet käyttäjätarinoiksi. Tarinat ovat yksittäisiä virkkeitä, joissa kerrotaan

• missä rooissa, esimerkiksi sisällöntuottajana, yksinhuoltajalapsen äitinä tai luottamushenkilönä käyttäjä on
• mitä hän haluaa tehdä
• miksi, mikä on käyttäjän toivoma lopputulos

Toivotun yhden toiminnallisuuden tiivistäminen yhteen virkkeeseen on taitolaji. Liian laajoja tarinoita on kuitenkin helppo matkan varrella purkaa useammaksi, kunhan sisällössä on järkeä. Käyttäjätarinoiden kirjoittaminen vaatii myös mielikuvitusta, kun edessä on tyhjä ruutu ja puuttuva toiminnallisuus, mitä ja miten käyttäjän tulisi ruudulla voida toimia.

Esimerkiksi

Asiakas haluaa varata tilan häihin.

on aivan liian yleinen, eikä kerro mitään, miten tila halutaan valita ja varata.

Vastaavasti

Kuntalainen tai yrityksen edustaja haluaa ostaa verkkokaupasta lahjakortin haluamalleen summalle ja saada kortin postitettuna joko itselleen tai suoraan lahjan saajalle mahdollisimman lyhyellä toimitusajalla antaakseen kortin lahjana henkilölle, joka voi seuraavan vuoden aikana käyttää yhtä ja samaa lahjakorttia käydäkseen esim. opastetulla kummituskierroksella, katsomassa näytelmiä , uimassa ja kuuntelemassa konsertteja. Jos lahjakortti postitetaan suoraan lahjan saajalle, pitäisi tarjota mahdollisuus tilaajalle kirjoittaa korttiin oma tervehdyksensä.

taas pitää sisällään lukemattomia toiminnallisuuksia antamatta kuitenkaan paljoakaan eväitä, mitä toteutukselta toivotaan. Esimerkiksi missä vaiheessa ostoprosessia ja miten syötetään postitukseen tarvittavat yhteystiedot.

Entisaikaisen tekniikkaan keskittyvän vaatimusmäärittelyn sijaan kuitenkin käyttäjä on keskiössä. Meidän humanistien, asiakaspalvelijoiden tai muiden alojen asiantuntijoiden ei tarvitse tietää mitään tekniikasta. Koodarien taikaa on, miten asiakkaan näkökulma rakentuu toimivaksi ominaisuudeksi.

Alkumetreillä teknisempien asiantuntijoidemme kanssa terminologia oli haaste: käyttäjätarina (user story) – lyhyt virke asiakkaan näkökulmasta vs. use case – teknisestä näkökulmasta käyttäjän ja tekniikan yhteiselo.

Käyttäjien tarpeet ja toiveet selvitetään asiakkaita haastatellen, yhdessä asioita työpajoissa työstäen, tai keveimmillään asiakaspalvelussa työskentelevien asiantuntijuuteen nojautuen. Meillä vuonna 2014 jälkimmäinen oli vallitseva tapa. Nyt jo konseptivaiheessa palvelumuotoilun keinot asiakkaiden kanssa ovat normikäytäntö.

Asiakkaat kulkevat mukana käyttäjäpersoonina

Asiakkaista luotiin myös stereotyyppejä, esimerkkejä käyttäjäpersoona-kuvauksiksi. Minkälaisia palveluja maahanmuuttaja-teini käyttää? Entä mitkä asiat kiinnostavat eniten perheenäitiä?

Käyttäjäpersoonien pitäisi kulkea rinnan koko kehittämisen ajan ja muistuttaa, kenelle, miten ja miksi palvelua ollaan rakentamassa. Persoonien pitäisi myös syventyä ymmärryksen lisääntyessä ja tekemisen edetessä. Optimaalista olisi, että kaikessa digikehittämisessä persoonat olisivat samat, jolloin ne monipuolistuisivat.

Verkkopalvelun rakentamisen osalta oppikirjamainen tavoite jäi vain haaveeksi. Käyttäjäpersoonat oli luotu jo aiemmin pienessä piirissä sen sijaan, että sisällöistä vastaavat ja asiakkaat olisivat työstäneet asioita yhdessä, ja tämän jälkeen avainhenkilöt olisivat rakentaneet käyttäjäpersoonat.

Ehkä tästä ja omien myyntitaitojen rajallisuudesta johtuen persoonat jäivät lähes hyödyntämättä, ja asiakasnäkökulma oli enemmän kaupungin työntekijöiden oletuksiin pohjautuvaa.

Käyttäjätarinat ohjaavat koko tekemistä

Tarjouspyyntövaiheessa lyhyitä ja pitempiä käyttäjätarinoita oli satoja, joiden määrä kymmenkertaistui kehitysvaiheessa, kun ylätason tarinat purettiin pienempiin toteutettaviin osiin.

Tarjouspyynnön oheen käyttäjätarinoista tehtiin excel-listaus, joten välttämättä vaatimusmäärittely-exceliin ei näennäisesti ole niin suurta eroa.

Ketterä eteneminen tarkoittaa myös sitä, että usein tarpeet muuttuvat ja ymmärrys kasvaa kehitystyön edetessä.

Vaikka käyttäjätarinan pohjalta tehty toteutus vastaa täysin tarinassa esitettyihin vaateisiin, se ei välttämättä silti palvele käyttäjää alkuperäisten oletusten mukaisesti, joten tarvitaan uusi tarina täydentämään toteutusta. Tai kuukausien kehitystyön aikana alkuperäinen tarve kehittyy, jolloin tarinakin edellyttää päivittämistä. Vanhan ajan vaatimusmäärittelyssä tällaiseen nopeaan reagointiin ja uudelleen arviointiin ei ole yleensä mahdollisuutta.

Toteutukset myös testataan käyttäjätarinoita vasten eli jokaiseen tarinaan kannattaa kirjata myös, minkä pitää olla mahdollista toteutuksen jälkeen. Näin testaaminen on helpompaa.

Samaten on hyvä kirjata, mikä esimerkiksi ensimmäisessä vaiheessa jätetään suosiolla toteutuksen ulkopuolelle: ensin potkulauta, myöhemmin Tesla.

Käyttäjätarinat koskevat kaikkea tehtävää työtä, jotta tekeminen saadaan kohdistettua tarinoihin ja voidaan seurata työmäärien kulumista.

Meillä erityisesti teknisen puolen käyttäjätarinat jäivät puolitiehen, kun tämänkaltaista osaamista ei meillä ollut eivätkä omat IT-asiantuntijamme olleet vielä valmiita tarinoiden maailmaan. Lisäksi meiltä puuttuivat alkumetreillä kaikki visuaalisuuteen liittyvät käyttäjätarinat, kun luotimme leiskojen voimaan.

Onneksi toimittajiemme Scrum masterit olivat kärsivällisiä opettajia, jotta pääsimme vauhtiin. Kirjojen lukemisesta ja kurssituksesta huolimatta tekemällä oppii parhaiten.

Lyhyt muistilista Käyttäjätarinan käyttäjä voi olla niin asukas, sisällöntuottaja, yrittäjä kuin kuka tahansa Käyttäjätarina ei ota kantaa tekniikkaan Voidakseen kirjoittaa käyttäjän toiminnan, se on pystyttävä kuvittelemaan Käyttäjätarinoita ei yleensä voi olla liikaa Käyttäjätarina tai toteutus ei ole epäonnistunut, vaikka lopputulos ei heti tyydytä, kyse on vain jatkokehittämisestä

Kokonaisuuden postaukset

1. Pitää olla visio
2. Puitesopimuksella ja esiselvityksellä mielenrauha
3. Käyttäjän näkökulmasta tarinoiden
4. Ketterästi rakentaen
5. Hektisen kehittämisvaiheen jälkeinen elämä

Puitesopimuksella ja esiselvityksellä mielenrauha – pari sanaa verkkopalvelun rakentamisesta, 2

Kirjoitan verkkopalvelun kehittämisestä viisi postausta omien kokemusten pohjalta täysin subjektiivisesta näkökulmasta. Tämä on sarjan 2. kirjoitus.

1. Pitää olla visio

2. Puitesopimuksella ja esiselvityksellä mielenrauhaa

Verkkopalvelu-uudistuksemme yhtenä tavoitteena oli päästä irti toimittajaloukoista. IT-palvelut oli teettänyt ulkopuolisen selvityksen tarjolla olevista avoimen lähdekoodin ratkaisuista, jotta voisimme jatkossa karsia kustannuksia. Toteutustekniikaksi valikoitui Drupal.

Tiettyyn julkaisualustaan sitoutuminen helpottaa suuresti tarjouspyyntöjen arviointia, kun erilaisten tekniikoiden hyviä ja huonoja ominaisuuksia ei tarvitse arvottaa ristiin.

Avoimen lähdekoodin tai lukuisten toimittajien tarjoama alusta ei rajoita toimittajien osallistumista kilpailutukseen, niin markkinaoikeuskaan ei ole uhkana.

Olen oppinut arvostamaan puitesopimusten liikkumavaraa.

Lisäksi IT-palvelumme pyrkii monivuotisiin puitesopimuksiin useamman toimittajan kanssa. Tämä tuo tilaajan näkökulmasta enemmän resursseja ja vaihtoehtoja niin toteutusvaiheeseen kuin yleensäkin yhteistyöhön.

Yleisen puitesopimuksen myötä kilpailutusvaiheessa verkkopalvelun kaikkien toivottujen toiminnallisuuksien tai edes kokonaisuuden ei tarvitse olla niin tarkkaan mietittyjä kuin yksittäisen projektin osalta. Samalla myös tunnustetaan se tosi asia, ettei verkkopalvelu tule kerralla valmiiksi, vaan hektisessä maailmassa, kansallisten vaateidenkin myötä tekninen kehitystyö on jatkuvaa.

Drupal-toimittajien kanssa eteenpäin

Meillä ei ollut tietämystä tai osaamista Drupalin mahdollisuuksista ja rajoitteista, joten lähdimme liikkeelle keskustellen kiinnostuksen ilmoittaneiden toimittajien kanssa. Näiden keskustelujen pohjalta tarkensimme tarjouspyyntömateriaalejamme julkaistavaksi julkishallinnon hankintapalveluun, Hilmaan.

Tarjouspyynnössä keskityimme visiomme, konseptimme avaamiseen liittäen mukaan käyttäjätarinat ja toiminnallisuuksien kuvaamisen. Lisäksi kerroimme tiukan aikataulumme.

Pyrimme myös kuvaamaan mahdollisimman tarkkaan integrointitarpeemme eri taustajärjestelmiin, mutta tämä osuus oli minimaalinen verrattuna nykyaikaan. Nyt verkkopalvelu muotoutuu käyttöliittymäksi ja asiakaskokemukseksi rajapintojen kautta tulevien tietojen ja palvelujen esittämiseen.

Toisaalta, jos tarjouspyyntö kohdistuu johonkin valmistuotteeseen, tai vaikka avoimen lähdekoodin ”valmis”ratkaisuun, kuten esimerkiksi kunta.fi, niin tarvittava määrittely, työmäärä ja siten kustannus tulevat olemaan pienempiä.

Paljon pohdimme myös, miten tarjoukset arvioidaan ja mitä asioita halutaan painottaa. Yleensä meillä tarjousten arvioinnissa laatu-hinta-suhde on 60-40.

Ja sitten hyppäsimme uima-altaan syvään päähän toivoen parasta.

Neljän vuoden puitesopimuksella haimme kolmea yhteistyökumppania toteuttamaan tarpeemme ja toiveemme. Me päätimme kohdella kaikkia puitesopimustoimittajia tasaveroisina sen sijaan, että olisimme minikilpailuttaneet päätoteuttajan. Ainoastaan ylläpitovaiheessa sitouduimme yhteen, kun jaettu vastuu on aina haasteellista.

Tällä hetkellä uusi puitesopimuskausi on tarjousten odotusvaiheessa. Nyt kuitenkin kierros on toivottavasti helpompi, kun kokemusta on enemmän ja tehty toteutus on koko maailman nähtävillä sekä jaettuna  lähdekoodina kansallisen yhteistyön pohjana.

Tänä vuonna lakimuutosten myötä teknisen osaamisen rinnalle on nostettu tietosuoja- ja saavutettavuustietämys.

Verkkopalvelu on ennen kaikkea viestintää

Hankintavaiheessakin kannattaa pitää mielessä, että verkkopalvelu on ennen kaikkea tietoa ja palvelua asiakkaalle. Verkkoviestinnästä verkkouutisointi on useimmissa palveluissa ehkä noin 10 %, loput 90% koostuu palvelupolkujen rakentamisesta ja staattisemmista sisällöistä, käyttöliittymissä ohjaamisesta jne.

Tekniset ratkaisut eivät siis yksin riitä, vaan toisinaan laadukkaaseen ja nykyaikaiseen verkkoviestintään tarvitaan tukea. Loistavien sisältöjen tekeminen voi olla mahdollista sisäisen osaamisen tai itsenäisen kouluttautumisen kautta, mutta ainakin Aurajoen rantamilla usein ulkopuolinen asiantuntija on messias.

Kannattaa siis miettiä ovatko resurssit verkkopalvelun rakentamiseen ja sisältötukeen jo olemassa tai pitäisikö nekin kilpailuttaa. Tai onko tarve niin pieni, että suorahankinta on mahdollinen.

Me lähdimme liikkeelle suorahankinnoin. Jo tarjouspyynnön tekovaiheessa saimme koulutusta käyttäjätarinoihin ja ketterään kehittämiseen.

Kun olimme päättäneet lähteä liikkeelle pienen ruudun tarpeista, avainhenkilöt saivat koulutusta mobiilikirjoittamiseen, jotta tekstit saataisiin lyhyemmiksi ja sisällöt tiiviimmiksi. Verkkopalvelun sisältövastuussa olevien tehtäväksi jäi viedä ohjeistusta eteenpäin sisällöntuottajille ja auttaa sisältöjen tekemisessä.

Edeltävän verkkohankkeen aikana teimme massiivisen verkkoviestinnän koulutusrumban ja oppeja kerrattiin pitkin matkaa. Mutta asiat unohtuvat, väki vaihtuu, ja mobiiliin kirjoittaminen vaatii kirkasta ajatusta ja ytimekästä toteutusta, mikä on aina haaste.

Samaten visuaalinen verkkopalvelu edellyttää paljon laadukkaita valokuvia, infograafeja. Onko valokuvia ja valokuvaajia riittävästi organisaatiossa tai onko helpompaa hankkia apua ulkopuolelta? Saavutettavuuslain myötä viimeistään WCAG-vaateiden noudattaminen on keskeistä. Löytyykö osaaminen omasta takaa tai miten huolehditaan lain noudattamisesta?

Myös kieliversioiden tarpeet pitää punnita. Miten uudet sisällöt saadaan palvelemaan kaikkia kohderyhmiä.

Hankintavaihe vaatii siis hyviä istumalihaksia, kokonaisnäkemystä ja pitkää pinnaa. Usein se tuntuu ultramaratonilta, kun paljon tehdään ja työstetään, mutta määränpää ei lähene.

Lyhyt muistilista Mikä on teille toimivin kilpailutustapa niin oman osaamisen kuin työmäärien kannalta Kilpailutustapa määrittää myös, miten paljon ja miten tarkkaan tulevia tarpeita pitää kuvata teknisin termein tai käyttäjätarinoin Mitä kaikkea muuta kuin tekniikkaa tarvitaan ja miten se on järkevintä hankkia

Kokonaisuuden postaukset

1. Pitää olla visio
2. Puitesopimuksella ja esiselvityksellä mielenrauha
3. Käyttäjän näkökulmasta tarinoiden
4. Ketterästi rakentaen
5. Hektisen kehittämisvaiheen jälkeinen elämä

Pitää olla visio – pari sanaa verkkopalvelun rakentamisesta, 1

Viime aikoina olen saanut tukea kollegoja eri tahoilla verkkopalvelun suunnittelussa, vaikka viimeisestä suuremmasta toteutusvaiheesta on kulunut jo kolme vuotta. Niinpä ajattelin koota muutamia ajatuksia yhteen, jos vaikka niistä olisi muillekin apua.

Teksti on osin muistojen sävyttämää ja ehkä vanhentunutta, mutta yritän parhaani mukaan tuoda ”Älä tee, kuten me teimme, vaan tee ennemmin näin”-ajatuksia mukaan. Teksti on siis hyvin subjektiivinen. Kirjailut jakautuvat viiteen osaan etenemisen mukaan konseptoinnista hankinnan ja aktiivisen rakentamisvaiheen kautta ylläpitoon ja jatkokehittämiseen.

Kirjoitan läpi tekstien verkkopalvelusta, sillä mielestäni jokaisen virallisen toimijan verkkopresenssin/verkkosivuston pitäisi 2020-lukua lähestyttäessä olla palvelutasoa keskittyen käyttäjän omatoimisen tekemisen tukemiseen pelkän tekstin sijaan. Verkkosivut ja kotisivut taas ovat muutaman sivun kokoelmia, ja ne jo terminä antavat vähättelevän kuvan verkkosisältöjen monipuolisuudesta.

1. Pitää olla visio

Yleensä verkkopalvelun rakentamista edeltää uudesta ja tulevasta unelmointi, kun kaikki on mahdollista ja olemassa olevan verkkopalvelun rajoitteet tai sisällöllinen sekavuus jää taa ja edessä on puhdas pöytä.

Tulevan palvelun lähtökohdaksi nousi nopeasti mobiili ensin -ajattelu

Niin asiakkaiden tarpeista ja toiveista, sisällöntuottajien haaveista, lain vaateista ja muualta löydetyistä hyvistä käytännöistä sekä resurssien tuomista rajoitteista on verkkopalvelu rakennettu. Lähdetään liikkeelle isosta kuvasta kohti yksityiskohtia.

Ehdimme oman verkkopalvelumme osalta haaveilla pitkään ja kerätä ideoita toiveiden tynnyriin projektin sisäisen käynnistyksen edetessä hitaasti. Kansallisten esimerkkien ja suurten kaupunkien kollegojen työn jäljen lisäksi esimerkiksi Lontoon ja New Yorkin ratkaisut tutkittiin tarkkaan. Always dream big.

Vuonna 2013 emme keränneet laajasti ideoita suoraan käyttäjiltä, mikä nyt olisi itsestäänselvyys, vaan eri alojen asiakaspalvelijat olivat paras tietolähteemme kävijätilastojen ohella. Silloisen verkkopalvelun rakentamisessa olimme siirtyneet organisaation esittelystä palvelulähtöisiin sisältöihin, jolloin olimme esimerkiksi keränneet puhelinvaihteesta parin viikon ajalta tietoa eniten kysytyistä asioista.

Verkkopalvelun visioksi muotoutui:

Verkkopalvelu haluaa olla innovaatioita ja toimintoja tarjoava elämyksellinen ja benchmarkattava verkkopalvelu, joka yhdistää saumattomasti erilaiset digitaalisen asioinnin monikanavaiset palvelut. Drupal-alustalla Turun sisällöt on suunniteltu ja rakennettu yhtenäisiksi, tekniseltä ja visuaaliselta toteutukseltaan yhdenmukaiseksi sekä mittavaa avoimen lähdekoodin alustaa hyödyntäviksi.

Sivusto hyödyntää sosiaalista mediaa tehokkaasti ja vuorovaikutteisesti asiakaspalvelun ja viestinnän osana, digitaalisten palvelujen rinnalla. Rakenteelliset ja sisällölliset ratkaisut tehdään asiakkaan näkökulmasta. Sivusto palvelee asiakkaita lisäksi päätelaiteriippumattomasti ja esteettömästi. Lähtökohtana on ”mobiili ensin” eli teknisten ratkaisujen tulee toimia ensisijaisesti pienellä ruudulla, josta laajennetaan suurempaan.

Mielestäni onnistuimme ainakin kohtuullisesti vision toteutuksessa.

Pienellä ruudulla asiakas ensin

Kuitenkin asiakkaan näkökulma ja käyttäytyminen olivat tärkein lähtökohta uusien toimintojen miettimiseen.

Olimme joutuneet hankkimaan mobiilisovelluksen aiemman verkkopalvelun rinnalle, jotta kännykän käytön tarpeisiin voitiin vastata edes jotenkin. Joten tulevan palvelun lähtökohdaksi korostui nopeasti mobiili ensin -ajattelu. Tällä tarkoitan sitä, että toiminnallisuuksien, sisältöjen asettelu mietitään ensin pienelle ruudulle ja laajennetaan sitten suurempaan sen sijaan, että vanhaan malliin yritetään työpöytä-näkymää mahduttaa kännykän ruudulle, jolloin esimerkiksi info-pallurat ovat onnettoman kokoisia sormella tökättäväksi.

Linjaus ohjasi myös miettimään, mitä muuta mobiili mahdollistaa esimerkiksi paikkatiedon hyödyntämisen suhteen. Samalla pieni ruutu tarkoittaa rankkaa karsintaa sisällöissä, jotta palvelu on käytettävää eri kokoisissa laitteissa.

Toistelimme turtumiseen saakka päätelaiteriippumattomuutta kännykän ruudulta taulutelevisioihin. Tarjouspyynnön hankinnan kohteeseen taidettiin kirjailla myös Google-lasien käyttö, koska vuonna 2013 ne olivat ”juuri yleistymässä”. Aina tekniikka ei etene niin optimaalisesti.

Samaten koko tämän vuosikymmenen visuaalisuuden merkitys on kasvanut yleisenä trendinä koko yhteiskunnassa, joten oli luonnollista huomioida tämä myös verkkopalvelussa.

Erilaiset asiakasryhmät huomioon

Pyrkimyksenämme oli myös tarjota osuvampaa sisältöä eri kohderyhmille huomioiden niin lapsiperheet ja seniorit tai matkailijat. Lisäksi WCAG-vaateiden kirjausten myötä saavutettavuusvaateita haluttiin noudattaa mahdollisimman tarkasti. Jälkimmäisessä tahtotila oli suurempi kuin onnistumisprosentti, mutta siitä myöhemmin lisää.

Mobiilikäyttö on tätä päivää.

Käyttäjätarinat havainnollistavat tarpeet

Verkkopalvelun toteutukseen saamamme aikajana oli lyhyt ottaen huomioon palvelun koon. Aiemmassa verkkopalvelussa sisältöjä oli yhteensä lähes 100 000 sivua useammalla kieliversiolla.

Lyhyestä toteutustajasta ja itsekseen opiskelluista materiaaleista nousi idea käyttäjätarinoihin ja ketterään kehittämiseen, joilla pyrimme taklaamaan toteutusvaiheen haasteita.

Niin me verkkopalvelusta vastaavat kuin asiakaspalvelijat ja sisällöntuottajat kirjailimme tarjouspyynnön liitteeksi satoja käyttäjätarinoita, joilla kuvailimme asiakkaan tai sisällöntuottajan näkökulmasta, miten haluaisimme käyttäjän voivan toimia verkkopalvelussa.

Tarinoiden rinnalle tarjouspyynnön liitteeksi teimme kaupungin suosiman Prince 2 -projektihallintamallin mukaisesti product breakdown structure -kuvan kertomaan minkälaisista kokonaisuuksista ajattelimme verkkopalvelun muodostuvan. Kuvaan kirjattiin esimerkiksi uutisosio, tapahtumakalenteri, palvelukartta ja edelleen toteutustaan odottava asiointitili sekä mistä esimerkiksi työntekijätiedot tulevat verkkopalveluun.

Verkkopalvelun osasia product breakdown structurena – tummemman siniset laatikot kuuluivat beta-versioon.

Tavoitteena ketteryys ja teknologiariippumattomuus

Humanistina olen aina vierastanut tuhansien rivien teknistä vaatimusmäärittelyä. Se ei vain sovi logiikkaani.

Lisäksi IT-toteutusten painajaisissa ja liian usein myös realismissa toteutuksen alkaessa sekä erityisesti sen jälkeen tilaaja ja toimittaja ovat päätyneet kiistelemään. Vaatimusmäärittelyjen tulkinta ja sen pohjalta tehty toteutus valitulla teknisellä ratkaisulla maksoikin maltaita annetun kustannusarvion sijaan, eikä lopputulos välttämättä vastaa lainkaan alkuperäistä tarvetta.

Jos tekee aina samoin, ei voi odottaa toisenlaista lopputulosta.

Käyttäjätarinoiden avulla pyrimme keskittymään käyttäjänäkökulmaan unohtaen teknologian, johon meillä kaupungissa ei edes ollut osaamista. Käyttäjätarinat ovat myös ketterän kehittämisen lähtökohta.

Ketterä kehittäminen tarkoittaa, että toteutus tehdään pienissä osissa, jolloin mahdollisiin muutostarpeisiin voidaan reagoida heti. Samalla tilaaja saa koko ajan toimivia toiminnallisuuksia käyttöönsä eikä vasta puolen vuoden kuluttua.

Vuonna 2013 palvelumuotoilun hyvät käytännöt eivät vielä olleet mukana kokonaisidean ja konseptin rakentamisessa, vaan tämä asiantuntemus rajoittui tekemisessämme tiedettyjen haasteiden ratkomiseen. Nyt luonnollisesti tilanteen pitää olla toinen.

Näillä eväillä ja hyvin vapaamuotoisella konseptikuvauksella halusimme pyrkiä ketterästi kohti responsiivista ja adaptiivista, visuaalista verkkopalvelua mobiili ensin -periaattein.

Kuten kenties jo huomasit, visuaaliset leiskat eli miltä verkkopalvelu näyttää ei ole tässä vaiheessa vielä olennainen.

Lyhyt muistilista Ketä ja miten verkkopalvelun tulee palvella Minkälainen tunnelma ja funktio verkkopalvelulla on Mistä toiminnallisuuksista verkkopalvelu koostuu Mistä tiedot tulevat

Kokonaisuuden postaukset

1. Pitää olla visio
2. Puitesopimuksella ja esiselvityksellä mielenrauha
3. Käyttäjän näkökulmasta tarinoiden
4. Ketterästi rakentaen
5. Hektisen kehittämisvaiheen jälkeinen elämä

Saavutettavuus on ihmisoikeuskysymys

Markus Rahkola kuvaa mistä saavutettavuus digipalveluissa koostuu.

Digitalisaation edistyessä yhdenvertaisuuden toteutuminen verkossa ja mobiilisovelluksissa nousee uudelle tasolle. Erityisesti julkishallinnon palvelujen pitää olla kaikkien käytettävissä. Suurin haaste saavutettavuuden osalta saattaa kuitenkin olla tekniikan sijaan ymmärrettävä sisältö.

Marraskuinen #saavuta2017-seminaari antoi eväitä ja suuntaviivoja kaikille suunnattujen palvelujen rakentamiseen. Saavutettavuus onkin huomioitava verkko- ja mobiilipalvelujen osalta tarjouspyynnöstä lähtien. Teknistä toteutusta ohjaa erinomaisesti WCAG 2.1 –standardi, mutta käyttäjälle selkeän ja selkeästi esitetyn sisällön osalta työ voi olla haasteellisempi.

Nopeimmin lisääntyvä käyttöliittymä on puhekäyttöliittymä – Markus Rahkola, Valtiovarainministeriö

Uusi saavutettavuuslaki on tarkoitus saada voimaan 1.9.2018 ja sen soveltaminen alkaa

• 23.9.2018 jälkeen julkaistujen verkkopalvelujen osalta 23.9.2019
• vanhempien verkkopalvelujen osalta vuotta myöhemmin ja
• mobiilisovellukset tulevat lain piiriin 23.09.2021
• ennen 23.9.2019 julkaistujen ekstra- ja intranetien osalta laki sitoo vasta, kun palvelut uudistetaan täysin

– Palvelujen digitalisoituessa vauhdilla on syytä pitää mielessä, että koko palveluketjun pitää olla saavutettava, muistutti Valtiovarainministeriön Markus Rahkola. Verkkosivulta digilomakkeeseen tai palvelukonfiguraattoriin siirtyminen voi muodostua yllättäväksi haasteeksi.

Saavutettavuusselosteessa palvelun ja sovelluksen ongelmat esille

Tulevaisuudessa saavutettavuuden toteutumista valvoo viranomainen, ja me kaikki olemme velvollisia kirjaamaan saavutettavuusselosteessa erityisesti osuudet, joissa on parannettavaa.

Väestörekisterikeskuksen Jani Ruuskanen edustaa Suomea eurooppalaisessa WADEX-ryhmässä, jossa pohditaan EU:n laajuisia toimintatapoja saavutettavuuden toteutumiseen ja valvontaan.

Ryhmän hahmotelmien mukaan saavutettavuusseloste esitetään verkkopalvelussa ja vastaavasti mobiilisovelluksen osalta esimerkiksi mobiilikaupassa.

Saavutettavuusselosteen tulee sisältää vähintään

• kuvaus palvelun osista, jotka eivät ole saavutettavia ja miksi, ja miten tiedot/palvelut saa muita kanavia pitkin
• viranomaisen yhteystiedot ja palautekanava
• linkki valvontaviranomaisen sivuille, jossa ainakin on mahdollisuus tehdä saavutettavuusselvityspyyntö
• milloin seloste on päivitetty – todennäköisesti tieto on päivitettävä vuosittain

Puoli miljoonaa henkilöä Suomessa tarvitsee selkokieltä

Palvelun tekninen moitteettomuus ei vielä riitä, vaan vasta ymmärrettävä sisältö mahdollistaa itsenäisen toimimisen.

Kehitysvammaliiton Sami Älli muistutti, että saavutettavuus ei ole vain tuotteen tai palvelun ominaisuus, vaan se riippuu palvelun käyttäjästä. Tekninen toteutus on helposti arvioitavissa, mutta helppo käytettävyys välttämättä ei. Ideaalitapauksessa palvelut voitaisiin räätälöidä yksilöllisesti käyttäjän mukaan.

Selkokieli on yksinkertaisempaa kuin useimmiten käyttämämme tai ainakin sellaiseen pyrkimämme yleiskieli. Selkokielikeskuksen Leealaura Leskelä osoitti, miten tavalliset arjen sanat, yksinkertaiset kielen rakenteet sekä selkeä ja johdonmukainen sisältö auttavat ymmärrettävien palvelujen tekemistä. Selkokieli on erityisen tärkeää digitaalisten palvelujen osana.

LeeaLaura Leskelä esitteli kielen eri rooleja.

Selkokieliset sivut tarvitaan, kun

• palvelu on tarkoitettu kaikille Suomessa asuville
• palvelu on suunnattu ihmisille, joilla on erityistarpeita, esim. vammaisille tai vanhuksille suunnatut sisällöt, ja
• kun palvelu on tarjolla vain digitaalisena ja se korvaa kasvokkain kanssakäymisen

Erinomainen esimerkki selkokielitoteutuksesta on Satakunnan sairaanhoitopiirin verkkopalvelu, jossa sisältöihin panostamalla on vähennetty painetta muissa kanavissa. Ja kaikki käyttäjät ovat olleet tyytyväisiä saamiinsa tietoihin. Tosin samalla korostui nykyisten lomakkeiden haasteellinen kieli, joka ei välttämättä ole yhtä helposti selkeytettävissä kuin verkkosisällöt.

Vincitin sokea koodari Tuukka Ojala muistutti, että loppupeleissä kyse on tasavertaisesta tekemisestä. Hän hyödyntää apuvälineitä, jotka mahdollistavat, eivät vain helpota, työnteon. Kaikki ohjelmistotalot hyötyvät, kun työyhteisö on monimuotoinen.

Saavutettavat digitaaliset palvelut mahdollistavat itsenäisyyden, ja me kaikki hyödymme niistä.

Lue lisää

• #saavuta2017-seminaarin materiaalit
• #saavuta2017 twitter-keskustelu
• Satakunnan sairaanhoitopiirin verkkopalvelu
• Tuukka Ojala Vincitin blogissa: Software development 450 words per minute (28.8.2017)