Kuntien Tiera Oy:n oppimisympäristön hankintailmoituksessa käytettävyys on korostetusti esillä mutta siten, että valituksi voi tulla käytettävyydeltään huonoin vaihtoehto.
Kuntien Tiera Oy on julkaissut hankintailmoituksen sähköisestä oppimisympäristöstä: http://www.hankintailmoitukset.fi/fi/notice/view/2012-061560/. Kuntien Tiera kilpailuttaa oppimisympäristöä "edelläkävijäasiakkaille", jotka hankintailmoituksen mukaan ovat ns. kuumakuntia: Järvenpää, Mäntsälä jne.
Hankintailmoitus on osallistumispyyntö rajoitettuun neuvottelumenettelyyn, eli siinä haetaan rajoitettu määrä toimittajia, joiden kassa neuvotellaan. Neuvottelujen perusteella sitten Kuntien Tiera laatii tarjouspyynnön, joka ei ole julkinen eikä sitä siten pääse näkemään.
Hankintailmoituksen käytettävyyssisältö
Hankintailmoitus ei siis sisällä tarjouspyyntöä. Kuitenkin hankintailmoituksessa kerrotaan, miten käytettävyys aiotaan huomioida tarjouspyynnössä. Hankintailmoituksessa lukee:
-------------------
"7. Käytettävyyden testaus osana tarjousten vertailua
Tarjottujen tuotteiden käytettävyys tullaan testaamaan osana tarjousten arviointia tarjousten vastaanottamisen jälkeen. Niille toimijoille, joille tarjouspyyntö lähetetään, tulee tarjota demo- tai vastaava ympäristö ja tarvittava määrä käyttäjätunnuksia käytettävyyden testaamista varten viikolle 6. Testausta tullaan tekemään alakoulu- yläkoulu- ja lukiotasolla. Käytettävyystestaukselle vaadittavat järjestelyt kuvataan tarkemmin tarjouspyynnössä.
Käytettävyys on vain osa tarjousten kokonaistaloudellisuuden arviointia. Vertailuperusteet kuvataan täsmällisesti tarjouspyynnössä."
--------------------
Vaikka kuvaus on aika suppea, siitä selviää keskeiset periaatteet: käytettävyys on osa vertailuperusteita, ja vertailu tehdään demojen käytettävyystestauksilla.
Ensi silmäyksellä voi saada kuvan, että kilpailutuksessa pärjää sellainen oppimisympäristö, jonka käytettävyys on hyvä tai paras. Näin kuitenkaan ei ole. Itse asiassa kuvatulla menettelyllä on aika sattumanvaraista, millainen valitun oppimisympäristön käytettävyys on, niin absoluuttisesti kuin suhteissa kilpaileviin vaihtoehtoihin. Alla tarkempi analyysi.
Ensi silmäyksellä voi saada kuvan, että kilpailutuksessa pärjää sellainen oppimisympäristö, jonka käytettävyys on hyvä tai paras. Näin kuitenkaan ei ole. Itse asiassa kuvatulla menettelyllä on aika sattumanvaraista, millainen valitun oppimisympäristön käytettävyys on, niin absoluuttisesti kuin suhteissa kilpaileviin vaihtoehtoihin. Alla tarkempi analyysi.
Hyvää
Aloitetaan hyvästä puolesta. Hyvää on se, että lähestymistapa perustuu käyttäjien suoriutumisen arviointiin. Ja tämä on oikea tapa. Käyttäjien suoriutuminen on viime kädessä ainoa validi käytettävyyden kriteeri.
Ongelmia
Hankintailmoituksen käytettävyysosion ongelmat ovat sen kummatkin keskeiset periaatteet: (1) käytettävyys on osana vertailuperusteita, ja (2) määrällinen käytettävyystesti tehdään demoilla. Kumpikin näistä piirteistä yksistään riittäisi siihen, että valituksi voi tulla käytettävyydeltään huonoin vaihtoehto.
(1) Käytettävyys osana vertailuperusteita
Ongelma hankintailmoituksen lähestymistavassa on se, että käytettävyys (laatu) on vertailuperusteissa eikä pakollisissa vaatimuksissa. Jos aidosti halutaan käytettävyyttä (tai muuta laatua), käytettävyyden (laadun) paikka on pakolliset vaatimukset eikä vertailuperusteet.
Kun käytettävyys on vertailuperusteissa, periaatteessa valituksi aina voi tulla oppimisympäristö, jonka käytettävyys on "nolla" (jos kyseinen vaihtoehto on vahva muissa valintaperusteissa). Tästä olen kirjoittanut useasti aikaisemmin esim. http://hankikaytettavyytta.blogspot.fi/2012/01/laatu-pakollisiin-vaatimuksiin-eika.html.
Kun käytettävyys on vertailuperusteissa, periaatteessa valituksi aina voi tulla oppimisympäristö, jonka käytettävyys on "nolla" (jos kyseinen vaihtoehto on vahva muissa valintaperusteissa). Tästä olen kirjoittanut useasti aikaisemmin esim. http://hankikaytettavyytta.blogspot.fi/2012/01/laatu-pakollisiin-vaatimuksiin-eika.html.
(2) Määrällinen käytettävyystesti demoilla
Aluksikin, kun käytettävyyttä verrataan, niin kyse on määrällisestä käytettävyystestauksesta, koska tuloksena tarvitaan arvosanoja. Yleisin käytettävyystestauksen muoto on laadullinen testaus, jonka tavoitteena on löytää suunnitteluongelmia (ja -vahvuuksia) järjestelmästä. Mutta tästähän ei vertailutyyppisessä testauksessa voi olla kyse, vaan siis määrällisestä testauksesta.
Määrällisessä käytettävyystestauksessa mitataan käyttäjien suoriutumista annetuista tehtävistä. Ja vertailutilanteessa tasapuolisen kohtelun vuoksi käyttäjiä ei saa auttaa tms., vaan käyttäjien on suoriuduttava tehtävistä täysin itsenäisesti.
Määrällisessä käytettävyystestauksessa on tyypillistä, että käyttäjien suoriutumiseen voi vaikuttaa merkittävästi pieni yksityiskohtaisen tason suunnitteluratkaisu. Käyttäjän suoritus saattaa pysähtyä esimerkiksi siihen, että käyttöliittymässä on termi, jota käyttäjä ei ymmärrä.
Kun demot eivät ole yksityiskohdiltaan lopullisia järjestelmiä, niin niissä tällaisia "viilaamattomia" suunnitteluratkaisuja voi olla useitakin. Sen vuoksi demo saattaa saada määrällisessä käytettävyystestissä huonot pisteet, vaikka käyttäjälle ongelmia aiheuttavia piirteitä ei olisikaan lopullisessa toteutuksessa ja perustaltaan järjestelmä olisi muutenkin käytettävyydeltään hyvä.
Tämän vuoksi demojen määrällinen käytettävyystestaus ei ole validi menetelmä. Siinä mitataan demon käytettävyyttä, ja testitulos voi olla ihan eri kuin jos olisi testattu lopullista järjestelmää. Huonot pisteet voi saada järjestelmä, jonka lopullinen toteutus olisi käytettävyydeltään korkealuokkainen.
Olen kirjoittanut asiasta aiemminkin, esim. http://hankikaytettavyytta.blogspot.fi/2011/05/vertaileva-kaytettavyystestaus-demoilla.html.
- Ja vielä yksi käytännön näkökulma. Hankintailmoituksen mukaan rajoitettuun menettelyyn valitaan viisi ehdokasta. Totean vain, että on aikamoinen haaste suunnitella ja toteuttaa vertaileva käytettävyystesti viiden järjestelmän välillä niin, että se tehdään syrjimättömästi ja että tulokset ovat valideja (= että paljastavat aidosti parhaan järjestelmän). No, jos testit tehdään demoilla, niin tulosten validius on siis joka tapauksessa ongelma kuten edellä olen todennut.
- Ja vielä yksi käytännön näkökulma. Hankintailmoituksen mukaan rajoitettuun menettelyyn valitaan viisi ehdokasta. Totean vain, että on aikamoinen haaste suunnitella ja toteuttaa vertaileva käytettävyystesti viiden järjestelmän välillä niin, että se tehdään syrjimättömästi ja että tulokset ovat valideja (= että paljastavat aidosti parhaan järjestelmän). No, jos testit tehdään demoilla, niin tulosten validius on siis joka tapauksessa ongelma kuten edellä olen todennut.
Yhteenveto
Valituksi voi tulla oppimisympäristö, joka on käytettävyydeltään "mitä tahansa", niin absoluuttisesti kuin suhteissa kilpaileviin vaihtoehtoihin:
- Valituksi voi tulla oppimisympäristö, joka saa parhaat pisteet käytettävyydestä. Mutta valituksi voi myös tulla järjestelmä, joka se saa huonoimmat pisteet käytettävyydestä.
- Parhaat pisteet käytettävyydestä voi saada järjestelmä, joka on käytettävyydeltään paras. Mutta myös käytettävyydeltään huonoin järjestelmä voi saada parhaat pisteet.
Hyvässä tapauksessa asiakaskunnat voivat saada helppokäyttöisen oppimisympäristön. Mutta mahdollista on, että valituksi tulee ympäristö, jonka seurauksena on pähkäileviä käyttäjiä, vastahankaista käyttöönottoa, korkeita koulutuskustannuksia, jatkuvaa tuen tarvetta, käyttövirheitä ja kaiken maailman sekaannuksia.
Mikä olisi oikea tapa huomioida käytettävyys tarjouspyynnössä?
Perusaskel on määrittää käytettävyys pakollisiin vaatimuksiin. Siis määrittää se, mikä on riittävän hyvä taso järjestelmän käytettävyydelle. Tämän itse asiassa voinee vieläkin tehdä oppimisympäristön kilpailutuksessa, koska toki käytettävyys voi olla pakollisissakin vaatimuksissa sen lisäksi, että se on vertailuperusteissa.
Ja toinen perusaskel on perustaa vaatimukset käyttäjien suoriutumiseen. Niinhän tässäkin hankinnassa tehdään, mutta siis ei-toimivalla tavalla.
(On muuten hankintailmoituksia - myös Kuntien Tieran julkaisemia - jossa tehdään päinvastoin: käytettävyys on pakollisina mutta ei-valideina vaatimuksina. Yhtä toimimaton ratkaisu.)
Ja toinen perusaskel on perustaa vaatimukset käyttäjien suoriutumiseen. Niinhän tässäkin hankinnassa tehdään, mutta siis ei-toimivalla tavalla.
(On muuten hankintailmoituksia - myös Kuntien Tieran julkaisemia - jossa tehdään päinvastoin: käytettävyys on pakollisina mutta ei-valideina vaatimuksina. Yhtä toimimaton ratkaisu.)
Mutta se, miten tämä asia tehdään validisti ja miten vaatimusten saavuttaminen todennetaan, onkin sitten se haaste. Asian vaikeuden osoittaa, että niin tässä kuin käytännössä missään muissakaan Hilmassa julkaistuissa hankintailmoituksissa käytettävyyttä ei ole osattu aidosti edellyttää. Tässä suhteessa tämä hankintailmoitus ei ole muita huonompi mutta ei kyllä parempikaan. - Olen analysoinut hankintailmoituksia aiemminkin niin tässä blogissa kuin useissa julkaisuissani ja esityksissäni. Ja varmaan teen jatkossakin.
Asiaan ei siis ole helppoja ratkaisuja. Joitakin ratkaisumalleja mielestäni on, mutta niiden raportoinnin aika on, kun ratkaisuista on enemmän empiriaa (esimerkkejä). Itse teen tätä työtä, ja sen lisäksi tätä työtä tehdään jossain määrin Tekesin FlowIT-projektissa, jossa olen myös mukana. En tiedä, onko asian kimpussa muita tahoja; en ole tätä ainakaan huomannut (en juuri myöskään kansainvälisesti).
Paljon helpompi on kertoa, millä tavoin käytettävyyttä ei tule laittaa tarjouspyyntöihin. Tämä hankintailmoitus on yksi esimerkki; ja muista ei-toimivista tavoista olen kirjoittanut ja pitänyt esityksiä, niin kuin edellä totean.
Mikä olisi sitten suositus?
Yksinkertaisesti ja vähän provokatiivisestikin: älä laita käytettävyyttä ollenkaan tarjouspyyntöön, ellet tiedä oleellisesti parempaa lähestymistapaa kuin se, miten tähän asti käytettävyys on huomioitu tarjouspyynnöissä! Ei pakollisiin vaatimuksiin eikä vertailuperusteisiin.
Niiden miettiminen vie vain turhia resursseja eikä niistä ole viime kädessä mitään hyötyä. Ja itse asiassa ne voivat olla vahingollisia siinä mielessä, että niistä voi tulla väärää mielenrauhaa: ajatellaan, että kun jotakin laittaa, niin sillä olisi jotain positiivista merkitystä. Ja kun ajatellaan kilpailutuksen yleistä logiikkaa, tällaiset toiveet on syytä hylätä alkuunsa.
Yksinkertaisesti ja vähän provokatiivisestikin: älä laita käytettävyyttä ollenkaan tarjouspyyntöön, ellet tiedä oleellisesti parempaa lähestymistapaa kuin se, miten tähän asti käytettävyys on huomioitu tarjouspyynnöissä! Ei pakollisiin vaatimuksiin eikä vertailuperusteisiin.
Niiden miettiminen vie vain turhia resursseja eikä niistä ole viime kädessä mitään hyötyä. Ja itse asiassa ne voivat olla vahingollisia siinä mielessä, että niistä voi tulla väärää mielenrauhaa: ajatellaan, että kun jotakin laittaa, niin sillä olisi jotain positiivista merkitystä. Ja kun ajatellaan kilpailutuksen yleistä logiikkaa, tällaiset toiveet on syytä hylätä alkuunsa.
Ei kommentteja:
Lähetä kommentti