Kuka on käyttäjä tietojärjestelmien hankinnoissa?

Käyttäjiä ovat kaikki käyttäjien edustajat

Olin pari päivää sitten NordiCHI -konferenssin yhteydessä pidetyssä työpajassa, aiheena "käyttäjien osallistuminen tietojärjestelmien hankinnoissa": ks.  http://proc.cs.hut.fi/nordichi/

Oma esitykseni koski käyttäjien osallistumisen eettisiä näkökulmia: mitkä tavat ottaa käyttäjiä mukaan hankinnoissa ovat eettisesti oikein, ja tavat mitkä eivät ole. Oma näkemykseni siis on, että monet nykyisin käytetyt tavat ottaa käyttäjät mukaan eivät ole eettisesti kestäviä (ja tuottavat laadullisesti huonoja tuloksia).

Positioesityksessäni esitin eettisen periaatteen käyttäjien mukaan ottamiselle. Kerroin myös, mitkä käytännön menetelmät ovat täyttävät tuo periaatteen ja mitkä eivät: tunnistin 12 erilaista yleisesti käytettyä tapaa osallistaa käyttäjiä, joista ainoastaan 4 on eettisesti kestävää.  (Tästä teemasta olen postannut tässä blogissa alustavasti joskus aikaisemmin, ja palaan asiaan myöhemmin.)

-----------------
Mutta sitten tämän kirjoituksen pointtiin. Minulle esitettiin erittäin hyvä kysymys:
Keitä ovat käyttäjät? (tietojärjestelmien hankinnoissa)

No, vastasin: Käyttäjiä ovat ne, jotka eivät kuulu hanketiimiin. 

Sitten keskustelussa selvisi, että esimerkiksi Apotti -hankkeessa hanketiimiin kuuluu kaikkiaan ehkä 150 henkilöä. Siinä huomasin, että tuo vastaukseni ei olekaan pätevä. Mutta en siinä hetkessä oikein osannut jäsentää parempaa vastausta.

Itse en ole ollut mukana noin isoissa hankkeissa, mutta kuitenkin hankkeissa, joissa on mukana ehkä 20 - 30 henkilöä. Kuitenkin varsinainen hankkeen ydintiimi on ollut alle kymmenen, ehkä vain muutama henkilö. Ja olen nimenomaan nähnyt ongelmana ne roolit, mihin nuo laajempaan tiimiin kuuluvat käyttäjät tai heidän edustajansa laitetaan hankkeissa; käytännössä usein siis eettisesti ongelmallisiin rooleihin (ja tilanteisiin). Oikea vastaus kysymykseen "Ketkä ovat käyttäjiä?" siis ei ole "Ne, jotka eivät kuulu hanketiimiin".

Mikä olisi sitten parempi vastaus? Ketä ovat ne käyttäjät, joita erityisesti koskee omat eettisesti ohjeensa?

Vastaus "Ne, jotka eivät kuuluvat hankkeen ydintiimiin" on lähempänä totuutta, mutta "ydintiimi" on varmaan aika epämääräinen käsite. Eli tuskin tämäkään vastaus on oikein hyvä.

Mutta sitten keksi mielestäni yksinkertaisen ja ainakin tällä hetkellä pätevältä tuntuvan vastauksen:

Käyttäjiä ovat kaikki käyttäjien edustajat. 

Tämä pätee riippumatta siitä, ovatko käyttäjät/ käyttäjien edustajat hankkeessa mukana muodollisesti vai eivät. Menettelytavat, joilla käyttäjiä tai heidän edustajiaan otetaan mukaan, pitäisi olla kaikissa tapauksissa sellaiset, että ne eettisiä ja laadullisia ongelmia ei toteudu.

Varmuuden vuoksi: toki hanketiimissä voi olla mukana loppukäyttäjien ammattiryhmiä edustavia henkilöitä. Mutta oleellista on siis se, missä roolissa he ovat. On ihan ok, että he ovat projektipäällikköinä, asiantuntijoina tms. Mutta jos he ovat roolissa "edustaa käyttäjiä", niin silloin ollaan lähellä isoja ongelmia, jos ei toimita huolellisesti.

Hesariin kirjoittamani jutut kertovat tiiviisti käytettävyydestä/ julkisesta kilpailutuksesta

Aina joissakin yhteyksissä tulee esille Helsingin Sanomat tärkeänä mediana, jossa myös käytettävyysasioita voisi tuoda esiin.  

Itse olen Hesariin jonkin verran kirjoittanut ja myös saanut vieraskyniä ja mielipiteitä julkaistuksi. Saavutus, jonka asetan hyvinkin tieteellisten julkaisujeni rinnalle - pienempi prosentti Hesariin pääsee läpi kuin moniin arvostettuihinkin konferensseihin.

Nämä Hesarin kirjoitukseni ovat aika lyhyitä ja sellaisia, joita olen aika mietitysti kirjoittanut (ellei asiaa ytimekkäästi esitä, niin eipä ole toivoa julkaisemisestakaan). Ja ne aika hyvin tiivistävät sanomaani käytettävyydestä tietojärjestelmien hankinnoissa ja julkisesta kilpailutuksesta yleensä. Esimerkiksi Apottia käsittelen parissakin kirjoituksessa. 

Vaikeakäyttöisyys myös uusien järjestelmien riesa. 18.3.2014

Julkiset hankinnat eivät suosi halpaa. 17.4.2013

Tietojärjestelmän oltava helppokäyttöinen. 12.9.2012

Helppokäyttöisyyttä on osattava vaatia. 1.7.2012

Aho: Valtion IT-taidot heikkoja. 24.11.2011
(haastattelu)

Atk-hankinnoissa vastuu kuuluu tilaajalle. 9.11.2011

Myös minä olen tyhmä käyttäjä

Myös minä - Timo Jokela - olen "tyhmä" käyttäjä. 


Olen monessa esityksessä ym. tuonut esiin, että järjestelmä- (tuote-) kehityksessä ei pitäisi kysyä käyttäjien mielipiteitä, toivomuksia tms. Olen usein siteerannut Steve Jobsia: "Apple ei kysy käyttäjiltä".

Tämä viestini on ehkä käsitetty joskus väärin. Olen joskus esittänyt kalvon (alla), jonka viesti on se, että "lääkärien mielipidettä ei pitäisi kysyä". Tämä ei tarkoita, että erityisesti lääkäreiltä ei pitäisi kysyä mielipidettä, vaan että yleensäkään suunnittelu perustuen käyttäjien mielipiteille on väärä lähtökohta. Viesti paremminkin on se, että lääkäreiden - ja muiden käyttäjien - ei tarvitse sanoa mielipiteitään.

Ja että ei tulisi väärinkäsitystä, tämä koskee myös minua. Myös minä käyttäjänä olen sillä tavalla "tyhmä", että minulta ei pitäisi kysyä. Toki kysyä jotain, mutta ei niitä asioita, joita usein kysytään.

----------------
ESIMERKKI ITSESTÄNI

Voinee sanoa, että olen ammattimainen sähköpostin käyttäjä. Kuvitellaanpa, että olisi tilanne, jossa minun käyttööni kehitetään uusi sähköpostiohjelma.

MÄÄRITTELYVAIHE

Tällaista ei:
Näen, että roolini ja tehtäväni sähköpostin käyttäjänä ei ole kertoa kehittäjille, millaista sähköpostia haluan, mitä piirteitä siinä pitäisi olla, millainen sähköpostiohjelma on hyvä ja niin edelleen. Minä käytän työssäni "aivoresurssejani" paljon mieluummin muuhun, en halua eikä minua kiinnosta käyttää niitä tällaiseen määrittelytyöhön, joka ei ole varsinaista työtäni.

Jos tällaisia asioita kuitenkin kysyttäisiin minulta, en missään tapauksessa halua ottaa vastuuta sanomieni vaatimusten, toiveiden ym. oikeellisuudesta ja laadusta.

Mutta parempi siis, että ei tällaisia asioita ollenkaan kysyttäisi minulta. Jos kysytään, niin kysyjän pitäisi ymmärtää, että hän kysyy "tyhmältä käyttäjältä". Ja myös ymmärtää se, että hän aidosti väsyttää ja rasittaa minua kysymyksillään.

Tällaista kyllä:
Sen sijaan kyllä voin kertoa ja näyttää, millaista minun sähköpostin käyttö on. Ja kertoa yleensä, millaista tämä oma työn tekeminen on. Sellaiset asioiden - siis faktoja omasta elämästä - kertominen on paljon helpompaa ja luontevampaa kuin pinnistellä toivomuksia tai haluja. Ja erityisesti tämä on luotettavampaa tietoa: kerronhan faktoista.

Tosin tässäkin oletan, että haastattelija on sellainen, joka osaa esittää oikeita kysymyksiä. Että minun ei tarvitsisi miettiä, että mitä kertoisin. Vaan että haastattelija ottaa vastuun siitä, että ohjaa minua kertomaan oikeista, relevanteista asioista.

Jos jää jotain tahattomasti kertomatta, sekään ei ole minun vaan haastattelijan vastuulla.

SUUNNITTELUVAIHE

Tällaista ei:
Sitten kun kehittäjät ovat kehittäneet jotain, minä en halua, että minulle tullaan esittämään rautalankamalleja tai muita kuvia suunnitteluratkaisuista ja odotetaan, että antaisin niistä palautetta.

Voin ehkä antaakin, mutta kysyjän pitäisi tietää se, että palautteeni laatu voi olla mitä tahansa. Ja koska se voi olla mitä tahansa, niin parempi on, että ei ollenkaan kysyttäisi.

Kaikkein karmeinta olisi, jos minun pitäisi antaa käyttäjänä jokin hyväksymisleima, että ehdotettu ratkaisu on riittävän hyvä. Tai sen variaatio: että minun pitäisi kertoa, mitä pitäisi muuttaa niin, että muutosten jälkeen sitten hyväksyisin.

Ja vielä yksi karmea variaatio: että minun pitäisi jossain käyttäjäraadissa pisteyttää sähköpostiratkaisuvaihtoehtoja toimittajien esittämien demojen perusteella.

Ja vielä yksi karmeus: että minun pitäisi olla mukana suunnittelemassa sähköpostin käyttöliittymää. Absolut kiitos ei!

Tällaista kyllä:
Voin kyllä kokeilla jotain prototyyppiä. Tarkoittaa, että voin yrittää tehdä normaaleja tehtäviäni sillä. Siis keskittyä tehtävän tekemiseen, en millään tavoin prototyypin arvioimiseen.

Voin myös jälkikäteen kertoa käyttäjäkokemuksestani. Mutta en halua arvioida suunnitteluratkaisuja, puhumattakaan, että minun odotettaisiin ehdottavan parannusehdotuksia.

Siis että roolini on käyttää vain, olla käytettävyystestin testihenkilönä. Mutta ilman, että tarvitsee ajatella mitään muuta kuin että yrittää käyttää.

----
PS. Tämä tietenkin tarkoittaa, että käyttäjien ja asiakkaiden tarpeiden selvittäminen on haastava tehtävä kehitystiimille. Millä konsteilla saada nopeasti ja tuloksellisesti tietoa käyttäjiltä ja asiakkailta ja miten haastatella heitä - kerron uudesta lähestymistavasta ja muustakin enemmän tulevassa kirjassani:  http://asiakastarve.launchrock.com/

"Vaikeakäyttöisyys myös uusien järjestelmien riesa" -mielipide HS 18.3.2014

Pääkirjoitus 17.3. antoi sykäyksen tämän kommentin kirjoittamiseen.

Jos olet seurannut juttujani Hesarissa tai muualla, niin tuskin tässä sinulle mitään uutta on (laskelin, että taitaa olla viides kirjoitukseni Hesarissa tästä teemasta).

Jutussa joka tapauksessa perustelen lyhyesti, miksi en usko, että mitään ratkaisevasti parempaa tapahtuisi sen eteen, että järjestelmät muuttuisivat helppokäyttöisemmiksi tulevaisuudessakaan.

http://www.hs.fi/mielipide/Vaikeak%C3%A4ytt%C3%B6isyys+my%C3%B6s+uusien+j%C3%A4rjestelmien+riesa/a1395041459680

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ä.