JHS 129 (Julkisten verkkopalvelujen suunnittelu ja kehittäminen): miksi vastustan kyseisin luonnoksen hyväksymistä

Annoin vastustavan lausunnon syksyllä 2013 julkaistusta JHS 129 -luonnoksesta, koska se ei mielestäni anna riittäviä ja oikeita ohjeita verkkopalvelujen suunnitteluun.

(Olen juuri pitämässä TalentumEventsin järjestämää käytettävyyskurssia, yhdessä Aapo Puskalan kanssa. Kurssilla tuli esiin JHS 129, ja kun siihen ei kurssin puitteissa ollut mahdollista syventyä, niin päätin tehdä tämän postauksen). 

Nykyisin julkisten verkkopalvelujen "käyttäjäkeskeisetkin" kehittämismallit voivat johtaa vaikkapa sellaiseen käytäntöön, että hankkijalle voi jäädä ainoaksi vaihtoehdoksi laittaa toimittaja (=suunnittelija) ja ulkopuolinen käytettävyystoimisto saman pöydän ääreen tinkaamaan suunnitteluratkaisuista keskenään. Ja kumpikin taho istuvat täydellä konsulttipalkkiolla. Ja tilaaja maksaa. Ä-L-Y-T-Ö-N-T-Ä.

Havaintoni on, että JHS -suosituksilla voi olla kovinkin merkittävä rooli julkisissa järjestelmähankinnoissa. JHS 129 on suositus verkkopalvelujen kehittämiselle, eli aika merkittävästä suosituksesta on kyse. Ja mielestäni on kriittistä, että JHS-suositukset ovat itsessään laadullisesti korkeatasoiset ja johtaisivat toimiviin käytäntöihin (eikä yllämainitun tapaisiin).

JHS 129 uusi luonnos julkaistiin syksyllä lausuntoja varten. Ja minä olen toinen kahdesta, jotka antoivat vastustavan kannanoton. (Ilman muutoksia tai muutoksin hyväksyviä oli yli 20 kpl). Tarkastelin luonnosta erityisesti käytettävyyden ja käyttäjäkeskeisyyden näkökulmasta ja hankintatilanteessa.

Syksyllä 2013 julkaistiin JHS 129 (Julkisten verkkopalvelujen suunnittelu ja kehittäminen) luonnos. Luonnokseen pyydettiin lausuntoa, niin sen yksittäisiin kappaleisiin kuin yleistä hyväksymispalautetta.

Kaikkiaan palautteita näyttää tulleen 24 kpl. Näistä luonnoksen hyväksymisen kannalla (joko sellaisenaan tai muutoksin) on 21. Yksi ei ottanut kantaa, ja kaksi (2) vastusti hyväksymistä.

Annoin oman näkemykseni mukaan palautteen. Oma lausuntoni on, että "vastustan" luonnoksen hyväksymistä. Eli olen toinen noista vastustajista.

Taustasta vielä sen verran, että annoin kommentteja myös alustavaan versioon kesällä 2013, mutta niiden vaikutus ei ollut sellainen kuin toivoin ja odotin. Ko. kommentit löytyvät täältä: http://kaytettavyysnavigoija.blogspot.fi/2013/06/kommentteja-jhs-129-luonnokseen.html

Omasta mielestäni luonnoksessa on vakavia puutteita, eikä se ole ratkaisu nykyisiin ongelmiin. Kirjoitin seuraavan vastustusperustelun ("miksi vastustan"; lisäksi kirjoitin useita yksityiskohtiin meneviä kommentteja):

"Aluksikin, osa muutoksista on niin isoja, että muutosehdotuksiin ei voi kirjoittaa niin isoja korjauksia kuin mitä tarvitaan. Osaan muutosehdotuksista olen suoraan esittänyt mikä on korvaava teksti, mutta osa on niin isoja, että tarkoittaisi mittavaa uuden materiaalin tuottamista (mihin ainakaan minulla vapaaehtoisena ole resursseja).

Yleisellä tasolla, suositusluonnos ei vastaa yleisiin verkkopalvelujen kehittämisongelmiin:

• suositusluonnos jättää helposti harhaanjohtavan kuvan tuloksellisen käyttäjäkeskeisen suunnittelun luonteesta ja haasteista (erityisesti hankinta- ja kilpailutustilanteessa)
• verkkopalvelujen tason laaja vaihtelu (joskus onnistuu paremmin, joskus heikommin)
• suositus ei käytännössä sisällä mitään konkretiaa sille, miten suunnittelutaho saataisiin ottamaan vastuuta suunniteluratkaisujen laadusta, ts suunnittelun laatuvastuu jää käytännössä tilaajalle. Tämä tarkoittaa käytännössä rahavirtaa suunnittelu- (ja käytettävyys) toimijoille muutostentöiden kautta

Tarkemmin

• Palvelukaaren kehittämisen elinkaaressa ei näy ollenkaan keskeistä kehittämisen osa-aluetta: suunnittelu. Suunnitteluasioita on laitettu vaatimusmäärittelyn alle, mikä ei (tietenkään) missään tapauksessa ole loogista. Tämä on ISO ongelma
• Verkkopalvelun suunnittelu ”käyttäjänäkökulmatasolla” nähdään osana vaatimusmäärittelyä (kpl 7), vaikka se on erityisesti suunnittelutehtävä, ja keskeisesti vaativa ja ratkaiseva verkkopalvelun onnistumisen näkökulmasta. Suunnittelu nähdään puolestaan lähinnä teknisen toteutuksen suunnitteluna (kpl 9)
• Suositusluonnoksessa on monia epätarkkoja, vääriin tulkinnallisuuksiin mahdollisesti johtavia yksityiskohtia (mm. termien käyttö ja määritelmät)
• Hankinta- ja kilpailutusnäkökulma on otettu esiin todella suppeasti ja epämääräisesti; kuitenkin se on erittäin keskeinen asia, johon erityisesti tämän tyyppisen ohjeiston pitäisi antaa vahvaa ohjeistusta
• ongelmat tuloksellisen ja aidon käyttäjälähtöisyyden varmistamisessa
• hankintaohjeistojen puutteet"

---------------
JHS -suositusten laadintaohjeen (JHS 136) mukaan ".... vastustamisperusteet on tutkittava huolellisesti ja niihin on vastattava".  Tällä hetkellä tilanne on se, että (mielenkiinnolla) odotan noita vastauksia. 

Kirjoittelen, kun prosessi etenee.

Linkkejä:  

• Kaikki luonnokseen annetut palautteet, johon olen korostanut omat kommenttini 
• Linkki JHS 129-sivuille 

Tuomioistuinjärjestelmän epäonnistuminen - taustalla toimimattomat käytettävyyden suunnitteluperiaatteet? (taas)

Ritu -tuomioistuinjärjestelmän epäonnistumisen syyksi selitetään liian suppeita käytettävyystestejä. Oletettavaa kuitenkin on, että taustalla oli lähtökohtaisestikin toimimaton lähestymistapa käytettävyyden suunnitteluun ja varmistamiseen. 

Osui silmiini artikkeli Tekniikka ja Talous -lehdestä käytettävyydeltään epäonnistuneesta järjestelmästä: tuomioistuinten käyttöön hankitusta Ritu-järjestelemästä. Siitä sanotaan mm. että "järjestelmä hidastaa toimintaa tuomioistuimissa, vaikka sen piti nopeuttaa oikeusjuttujen käsittelyä. Tuomion antamiseen voi kulua jopa kolme kuukautta, kun se ennen annettiin vanhalla järjestelmällä kuukaudessa." 

Jutun mukaan käytettävyyteen oli panostettu: 

• "sovelluksen käytettävyyttä testattiin useammassa käräjäoikeudessa. Testikäyttäjinä oli sekä tuomareita että käräjäsihteereitä... ilmeni joitain teknisiä ongelmia, mutta käyttöliittymään ei juurikaan puututtu"

Toisaalta todetaan, että käytettävyystestaus oli puutteellista

• "Käytettävyyteen olisi pitänyt kiinnittää enemmän huomiota...  Testaukseen oli kuitenkin valittu hyvin yksinkertaisia juttuja, joissa oli yksi syytetty ja yksi syytekohta. Kun tositilanteessa eteen on tullut laajoja rikosjuttuja, joissa on paljon vastaajia ja paljon syytekohtia, on sovelluksen käyttö koettu kohtuuttoman hankalaksi"
• Vielä todetaan, että "kentän ääntä voitu kuunnella vieläkin tarkemmin".

Tuleviksi korjaustoimenpiteiksi suunnitellaan: 

• "Järjestelmää tullaan kuluvan vuoden aikana jatkokehittämään erityisessä jatkokehitysprojektissa, jota varten on valikoitu kenttää edustava joukko. Ryhmä koostuu päällikkötuomareista, käräjäsihteereistä ja it-alan ammattilaisista".

---------------

Johtopäätös 1: projektissa tehty perinteistä toimimatonta käytettävyyssuunnittelua

Kun tätä juttua tarkastelee, niin pidän oletettavana siltä, että käytettävyystoimenpiteet ovat olleet juuri niitä, jotka eivät ole olleet tuloksellisia aiemminkaan (ensisijainen ongelma ei siis ei ole se, että ainoastaan käytettävyystestaukset olisivat olleet puutteellisia):

• Vaikka en ole nähnyt alkuperäistä tarjouspyyntöä, olen varma, että siinä ei aidosti edellytetty käytettävyyttä toimitettavalta järjestelmältä
• Käytettävyystestauksen rooli näyttää olleen keskeinen käytettävyystoimenpide. Kuitenkin käytettävyystestaus potentiaalisesti on käytettävyyden vihollinen #1 (esim. aiempi juttuni http://kaytettavyysnavigoija.blogspot.fi/2013/12/kaytettavyyden-arviointi-kaytettavyyden.html). 
• Oletan myöskin - vaikka jutusta ei käy ilmi - että loppukäyttäjiä (tuomareita, käräjäsihteereitä tms.) oli vastuutettu käytettävyydessä toimimattomin tavoin 

Johtopäätös 2: projektin korjaustoimenpiteet jatkavat samaa toimimatonta rataa

Jutusta ei myöskään käy tarkemmin ilmi, miten jatkokehitys tarkalleen tullaan tekemään. Mutta artikkelista saa viitteitä siltä, että samaan tyyliin kuin aiemminkin: ajatellaan, että jos on edustava joukko käyttäjiä kentältä mukana, niin sillä asiat ratkeavat. 

Näin ei kuitenkaan välttämättä lainkaan ole: käyttäjien mukanaolo ei itsessään ratkaise mitään. Vaan se, miten käyttäjien ja suunnittelutiimin roolitus ja vastuu menevät. 

--------------

Miten pitäisi toimia

Olen kirjoitellut aiheeseen liittyen moneen kertaan, niin tässä blogissa kuin artikkeleissa:

• käytettävyystestauksen väärästä roolista: ks. yllä mainittu linkki
• miten käyttäjien pitäisi/ ei pitäisi olla mukana järjestelmäkehityksessä esim. http://kaytettavyysnavigoija.blogspot.fi/2011/10/ala-laita-kayttajia-jasentamaan-tyotaan.html (tästä minulla on tulossa myös "oikea" julkaisu tulevaan Etiikka-kirjaan
• yleensä siitä, miten käytettävyys pitäisi ottaa mukaan hankinnoissa; vaikkapa Sytyke-lehden artikkeli http://www.sytyke.org/wordpress/wp-content/uploads/2013/06/Sytyke_2_2013_low.pdf

Talentum Events järjestää käytettävyyskurssin 30.-31.1.2014

Pidän yhdessä Aapo Puskalan kanssa kurssin. Sisältää sekä käytettävyyden perustekniikat että myös syvällisempiä alueita (väitän, että tällaista tietoa ei saa muilta kursseilta).

Tarkemmat tiedot tästä.