Aina viisaus ei ole organisaation sisällä – siksi apu on tervetullut

Saavutettavuuslain tultua vihdoin voimaan huhtikuussa pyrkimys palvella kaikkia digitaalisissa kanavissa ei enää riitä, vaan tavoitteen on toteuduttava. EU-direktiivin ja lain myötä Turun kaupungille kilpailutettiin ensimmäistä kertaa yhteistyökumppanit saavutettavuuteen.

Kun organisaatiolla on takanaan historiaa ja siten myös byrokratiaa lähes 800 vuotta, ei muutos alamaisista palveltaviksi ja osallistuviksi asiakkaiksi ole aina ollut helppo. Vaikka verkkoviestinnällisissä palveluissa asukas monenlaisine tarpeineen on ollut keskiössä jo vuosia, kaupungin muita digipalveluja on saatettu tehdä hyvinkin järjestelmälähtöisesti niin käyttöliittymän, toiminnallisuuksien kuin terminologian osalta.

Insinöörimäinen lähtökohta on johtanut siihen, että käyttäjä on saanut arvuutella, mistä kohtaa ruutua lomakkeen Lähetä-painike löytyy ja millä vierailla termeillä toiminnallisuutta on kuvattu. Nykytilanne on kuitenkin perua tietämättömyydestä, ei välinpitämättömyydestä.

Kiitos saavutettavuuslain tilanne voi muuttua vain parempaan suuntaan. Tämän varmistamiseksi kilpailutimme Aurajoen rantamilla tukea saavutettavuuden kolmeen osa-alueeseen:

• Verkko, mobiili- ja digitaalisten palvelujen saavutettavuuden auditointiin sekä kehittämistukeen suunnittelusta toteutukseen
• Työntekijöiden osaamisen kasvattamiseen niin ymmärryksen kuin tekemisen osalta
• Digi, mobiili- ja verkkopalvelujen reaaliaikaiseen saavutettavuusmonitorointiin ja tulosten analysointitukeen.

Uskon, että Turun digipalvelut ovat jatkossa kaikkien käytettävissä itsenäisesti, kun saavutettavuusasiantuntijat ovat tukenamme koko hankinta- ja toteutusprosessin ajan. Saamme luotua alusta lähtien parempia digipalveluja, joiden tekniset toiminnallisuudet tai sisällöt eivät vaadi asukkaalta lehmän hermoja tai koko kylää avuksi asiointiprosessiin.

Ryhdymme saavutettavuustyöhön kesäloman jälkeen aikataulutetusti aloittaen uusimmista ja käytetyimmistä digipalveluistamme, jotta mahdollisimman monelle tie palveluihin ja palveluissa helpottuu. Kehitystyön rinnalla panostamme työntekijöiden osaamiseen, jotta saavutettavasti tekeminen tulee osaksi arkirutiineja, oli kyse sitten mobiilipalvelun suunnittelusta tai verkkosivuston liitteistä.

Tavoitteena on, että saavutettavuudesta tulee itsestäänselvyys – sitä sen pitäisi jo nyt olla meille julkishallinnon bittibyrokraateille.

Kirjoitus on julkaistu alkujaan Kuntaliiton Yhdenvertaisuuden puolesta -blogisarjassa saavutettavuudesta.

Mainokset

Palvelukartalla päämäärä on matkaa tärkeämpi

Helsinki rakentaa maailman saavutettavinta palvelukarttaa esimerkillisellä otteella palvelun omistajien, koodareiden, designerien ja suuren yleisön saumattomalla yhteistyöllä. Uuden rakentumista voi seurata ilolla ja oppien edellisten ja tulevien blogipostausten välityksellä.

Palvelukartan rakentamisessa asiakas tarpeineen on aina kehittämisen fokuksessa, jolloin palautteiden hyvät arviot ilahduttavat, mutta syvä analysointi keskittyy kriittisempiin huomioihin. Palvelukartta on tarkoitettu kaikille vaivattomaksi avuksi.

Miten pääkaupunkiseudun palvelutietojen wikipediasta suodatetaan ruudulle juuri sinun tarvitsemasi tieto helposti havaittavaksi kirkkaassakin auringonpaisteessa erilaisilla päätelaitteilla tai apuvälineillä? Miten kartalle tupsahtanut untuvikkokäyttäjä saatetaan onnellisesti kaipaamaansa maaliin? Digitaalisissa palveluissa toivottu päämäärä ja lopputulos ovat aina kuljettua matkaa tärkeämpiä.

Kevään kääntyessä kohti kesää useat käyttöliittymänäkymät ja -viilaukset ovat jalostuneet pienin askelin kohti toivottua selkeyttä käyttäjien arvioivien silmien ja sormien alla. Silti julkaisuversioon on vielä matkaa.

Tätä kaikkea Turun kaupungin digikehittäjät ovat saaneet olla seuraamassa ja tukemassa keskustellen, oppien ja tietoa jakaen. Kesän aikana sokea korkeakouluharjoittelijamme testaa syntyviä toiminnallisuuksia omasta näkökulmastaan auttaen meitä kaikkia näkemään asiat toisin.

Oppien ja yhteistyön lisäksi jo käytössä ja nyt rakenteilla olevat toteutukset ovat avoimella lähdekoodilla tehtyinä kenen tahansa hyödynnettävissä. Kaupunkien yhteistyö on syvää mahdollistaen järkevämmän verorahojen käytön, kun haasteet ovat meille kaikille kuitenkin samat. Näin myös Turun kaupunki on matkalla kohti omaa versiotaan maailman saavutettavimmasta palvelukartasta.

Palvelukartan kehittämisen viikoittaiset tiimipalaverit alkavat aina fiilisarviolla: auringon paistaessa ylpeänä Helsingin tekemästä työstä ja iloisena mahdollisuudesta tuoda panoksensa mukaan olo on paras mahdollinen eli 5.

Bloggaus on alkujaan julkaistu Helsingin palvelukartan blogissa.

Lisää aiheesta

• Pääkaupunkiseudun palvelukartta
• Rakenteilla oleva palvelukartta
• Helsingin palvelukartan blogi

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)

 

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ä