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.
- Pitää olla visio
- Puitesopimuksella ja esiselvityksellä mielenrauha
- 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
- Pitää olla visio
- Puitesopimuksella ja esiselvityksellä mielenrauha
- Käyttäjän näkökulmasta tarinoiden
- Ketterästi rakentaen
- Hektisen kehittämisvaiheen jälkeinen elämä
