Erään tarjouspyynnön käytettävyysanatomia, osa 1: Vähimmäisvaatimukset

Tämän tarkasteltun kohteena olevassa tarjouspyynnössä on määritetty käytettävyyteen liittyviä vähimmäisvaatimuksia (1) asiantuntijoille, (2) palvelulle ja (3) kehitysprosessille. Positiivista on, että käytettävyyteen on kiinnitetty monipuolisesti huomiota. Kuitenkin vähimmäisvaatimuksissa on merkittäviä puutteita sekä todennettavuuden että validiuden näkökulmasta.  Yhteenvetona on vaikea nähdä, miten näillä vaatimuksilla on merkittävyyttä käytettävyyden saavuttamisen näkökulmasta.

Toisaalta, kuten blogia seuranneet tietävät, käytettävyyden vaatiminen on aidosti haastavaa, eikä hyviä esimerkkejä juuri löydy.

(Osassa 2 tarkastellaan tarjouspyynnön vertailuperusteita)

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

Tarkastelun kohteena on Oikeushallinnon tietotekniikkakeskuksen tarjouspyyntö aloitepalvelun kehittämisestä. Ja siinä erityisesti se, miten käytettävyys on huomioitu.

Tämän analyysin tausta on se, että Teemu Ropponen tietotekniikkakeskuksesta "haastoi" minua arvioimaan tätä tarjouspyyntöä. Mikä on hieno asia, ja tekee toivottavasti lukijallekin asiasta mielenkiintoisemman ja konkreettisen; tarjouspyyntöhän on vielä julkisesti saatavilla. Aiemmin blogissani olen ottanut esimerkkejä anonyymisti (vaikka lukijoilla tietenkin on periaatteessa ollut mahdollisuus jäljittää alkuperäinen lähde). 

Tarjouspyynnössä on tavanomaiseen tapaan määritetty:

• vähimmäisvaatimukset: vaatimukset, jotka tarjoajan on täytettävä, jotta olisi mukana kilpailussa
• vertailuperusteet: näin perusteella valitaan voittava tarjous niiden joukosta, jotka täyttävät pakolliset vaatimuksen

Tässä kirjoituksessa ("osa 1") tarkastellaan sitä, miten käytettävyys näkyy vähimmäisvaatimuksissa. Omasta mielestäni vähimmäisvaatimukset on se "tärkeämpi" osa, koska valituksi voi periaatteessa tulla sellainen toimittaja, joka pelkästään täyttää nämä vähimmäisvaatimukset (ks. myös: http://hankikaytettavyytta.blogspot.com/2012/01/laatu-pakollisiin-vaatimuksiin-eika.html)

Mitä tarjouspyynnön vähimmäisvaatimuksiin on kirjoitettu käytettävyydestä 

Löysin tarjouspyynnöstä seuraavia vähimmäisvaatimuksia: 

1. Asiantuntijoihin liittyvät vähimmäisvaatimukset

Edellytetään käytettävyysasiantuntijaa/ käyttöliittymäsuunnittelijaa, jolla "tulee olla vastaavasta tehtävästä vähintään kolmen vuoden kokemus… vuorovaikutteisen verkkopalvelun rakentamisesta". Kyseisellä palvelulla on oltava "vähintään 500 keskimääräistä käyttäjää päivässä ja vähintään 2 käyttökieltä". 

2. Palveluun liittyvät vähimmäisvaatimukset:
Toimittajan tulee sitoutua noudattamaan "liitteen 7 mukaisen palvelun". Ja liitteestä 7 löysin seuraavat palvelun käytettävyyteen liittyvät vaatimukset:

• Näistä seikoista johtuen järjestelmän käyttöliittymän on täytettävä vähintään julkisille sähköisille palveluille asetetut yleiset käytettävyys- ja saavutettavuusvaatimukset.
• Koska kyseessä on verkkopalvelu, jota käyttää lukuisa määrä satunnaisia käyttäjiä (aloitteen tekijät), on se suunniteltava helppokäyttöiseksi. Järjestelmän tulee olla mahdollisimman käyttäjäystävällinen, jotta se kannustaisi käyttäjiä sähköisten palveluiden käyttämiseen ja positiivisen kokemuksen saamiseen.
• Helppokäyttöisyys (huom. PETOn käytettävyysvaatimukset) sekä kansalaiselle että viranomaiselle
• Järjestelmä on rakennettava siten, että kannatusilmoitusten keräämisen käsittelysääntöjä on helppo muuttaa tarvittaessa (esim. on mahdollista että jossain vaiheessa kannatusilmoitusten keräämisen käynnistys muuttuu siten, että aloitteelle kerätään ensin OM:n verkkopalvelussa 50 kannatusilmoitusta, ja aloite tulee vasta sen jälkeen tarkistettavaksi OM:ään)
• Järjestelmän on tuettava aloitteen vireillepanijaa eri tyyppisten aloitteiden tekemisessä (ohjeet, pakolliset tiedot)
• Järjestelmän käyttäjän pitää aina tietää, missä hän on ja mitä hän voi siinä tehdä.

3. Kehitysprosessiin liittyvät vähimmäisvaatimukset:
Liitteestä 7 löysin seuraavat kehitysprosessiin liittyvät vaatimukset: 

• Toimittaja on tehnyt järjestelmälle käytettävyys- ja suorituskykytestit vaatimusmäärittelyjen mukaisesti.
• Järjestelmälle on voitava tehdä käytettävyystestaus kolmannen osapuolen toimesta ennen tuotantoonottoa.

Vaatimusten arviointia

Tarkastelen vaatimuksia kahdesta näkökulmasta:

• todennettavuus: onko vaatimus määritetty siten, että sen täyttyminen voidaan tarkistaa niin, että ei tule erimielisyyksiä siitä, toteutuuko vaatimus vai ei (itse asiassa, josa vaatimus ei ole todennetava, niin se ei käytännössä ole vaatimus ensinkään)
• validius: onko vaatimus on sisällöllisesti oikea (= sen täyttyminen tarkoittaa, että sillä on aidosti vaikuttavuutta järjestelmän parempaan käytettävyyteen)

1. Henkilöihin liittyvät vähimmäisvaatimukset

• Vaatimus ("... vähintään kolmen vuoden kokemus...) on kohtuullisesti todennettavissa
• Mutta vaatimuksen validius on ongelmallinen: käyttöliittymä-/ käytettävyyskokemus kun sinällään ei takaa viime kädessä aitoa käyttöliittymäsuunnittelun tai käytettävyyden ammattitaitoa.  Käyttöliittymiä ja myös käytettävyysaktiviteetteja kun on voinut suorittaa ilman mitään alan koulutusta. Minun on myöskään vaikea nähdä, miten vaatimus "vähintään 500 käyttäjää" on relevantti käytettävyysasiantuntijan näkökulmasta?

Eli käytännössä tämä vähimmäisvaatimus ei edellytä ammattitaitoista käytettävyys-/ käyttöliittymäsuunnittelijaa.

2.  Palveluun liittyvät vähimmäisvaatimukset

•  "... täytettävä vähintään julkisille sähköisille palveluille asetetut yleiset käytettävyys-.... vaatimukset". Tässä ei suoraan määritetä, mitä nuo vaatimukset ovat; ehkä JHS-suosituksiin?
  Joka tapauksessa, tämän tyyppisessä vaatimuksessa on kaksi ongelmaa. (1) Useimmat JHS-suositusten yksittäisistä vaatimuksista ovat luonteeltaan ei-todennettavia. (2) Tällaiset yleiset vaatimukset  - vakka olisivatkin todennettavia - yleensäkään eivät kata käytettävyydestä kuin ehkä 10 - 20%.
•  "... on se suunniteltava helppokäyttöiseksi. Järjestelmän tulee olla mahdollisimman käyttäjäystävällinen", "helppokäyttöisyys.... sekä kansalaiselle että viranomaiselle", "käsittelysääntöjä on helppo muuttaa", "järjestelmän on tuettava aloitteen vireillepanijaa", "käyttäjän pitää aina tietää, missä hän on ja mitä hän voi siinä tehdä". Tällä tavalla muotoillut "pyöreät" vaatimukset eivät ole todennettavia eivätkä siten varsinaisia vaatimuksia. 

3. Kehitysprosessiin

 liittyvät vähimmäisvaatimukset

• "Toimittaja on tehnyt järjestelmälle käytettävyys- ja suorituskykytestit vaatimusmäärittelyjen mukaisesti." Aluksikaan, en löytänyt noita käytettävyystestimäärittelyjä tarjouspyynnöstä. Mutta vaikka siellä sellaiset vaatimukset olisikin, niin niin käytettävyystestit sinällään eivät takaa mitään käytettävyydestä, toisin sanoen, niiden edellyttäminen ei ole validi vaatimus (tähän on montakin syytä, yksi esimerkiksi CUE-tutkimusten tulokset, ks.  http://hankikaytettavyytta.blogspot.com/2011/04/lahtokohta-kaytettavyyden-varmistus-ei.html). 

• "Järjestelmälle on voitava tehdä käytettävyystestaus kolmannen osapuolen toimesta ennen tuotantoonottoa". No, tätä ei oikein tulkitse vaatimukseksi ollenkaan, koska sen voi jokainen toteuttaa. Käytettävyystestaustahan on mahdollista tehdä hyvinkin keskeneräisellä järjestelmällä, jopa paperitasolla. 

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

Yhteenveto: ks. tiivistelmä ylhäällä. 

"Usability in Government Systems" jo myynnissä

Tuleva kirja Usability in Government Systems jo Amazonin etukäteismyynnissä. Sisältää mm. Elizabeth Buien ja Timon kirjoittaman kappaleen "Getting UX into the contract". 

http://www.amazon.com/gp/product/0123910633

Ylivoimainen menestys, yksi käyttöliittymä

Näin iPhone jyrää: katteet 75% koko matkapuhelinsektorista: http://www.macrumors.com/2012/02/03/apples-share-of-profits-among-top-mobile-phone-vendors-hits-75/

Tällainen menestys, vaikka Applen puhelimilla on vain yksi käyttöliittymä. 

Muistuupa vain mieleen Nokia joskus aikoinaan. Käyttöliittymiä kehitettiin useita, kun käyttöliittymää käytettiin segmentointitekijänä. Käytettävyysmielessähän tällainen on ihan "hullu" lähestymistapa: käyttöliittymistä tuli itseisarvo käytettävyyden (ja käyttäjäkokemuksen) kustannuksella. Käytännössä tarkoitti muun muassa sitä, että toiset nokialaiset olivat helppokäyttöisempiä kuin toiset.

Tämä filosofia sai siis vallan Nokiassa. Joskus aikoinaan se riitti, mutta kun tuli kilpailua, niin tässä ollaan. 

Itse pidän mahdollisena*, että vaikka näistä puhelimista on aikaa vuosia, niin tämä erikoinen paradigma jäi elämään Nokialla viime vuosiin asti - ainakin joidenkin ihmisten mieleen. Ja on osasyynä siihen, että Nokia jäi ratkaisevasti käytettävyydessä jälkeen.

* Tämä on siis tulkintani, ei tutkittua faktaa. Sitä tukee jotkut hajanaiset nokialaisten suusta kuulemat lausumat. 

Laatu vähimmäisvaatimuksiin eikä arviointiperusteisiin tarjouspyynnöissä

Laatu olisi sisällytettävä tarjouspyynnöissä ensi sijaisesti vähimmäisvaatimuksiin. Arviointiperusteissa voi olla mukana "ylimääräinen" laatu, mutta sen painoarvon ei tulisi olla kovin korkea.
 
-------------------
Aluksikin: tämä juttu on tietojärjestelmien (julkisesta) kilpailutuksesta yleensä, ei mitenkään erityisesti käytettävyydestä. Mutta pätee tietenkin käytettävyyteenkin - kun käytettävyys on yksi laatutekijä.

Miten kilpailuttaa ja tehdä tarjouspyyntö, että saataisiin tulokseksi laatua? 

Laatu (esimerkiksi käytettävyys) voi näkyä kahdella tavalla tarjouspyynnössä: (1) vähimmäisvaatimus, jonka täyttämiseen jokaisessa tarjouksesssa on sitouduttava ja (2) arviointiperuste, jolloin toimittaja saa sitä enemmän pisteitä, mitä parempaa laatua pystyy tarjoamaan (eniten pisteitä saanut tarjous on valittava).

On esitetty, että laadulla pitäisi olla painoarvoa arviointiperusteissa. Eräskin ohjelmistotalo on ottanut lähtökohdaksi, että he eivät lähde mukaan kilpailutuksiin, jossa hinnan osuus on yli 40% arviointiperusteista.

Miten tämä nyt oikein menee? Miten laatu pitäisi laittaa vähimmäisvaatimuksiksi ja arviointiperusteiksi?

VÄHIMMÄISVAATIMUKSET

Loogista on määrittää laatu vähimmäisvaatimuksiin niin, että niiden täyttäminen riittää "riittävän" hyvään järjestelmään. Toisin sanoen, vaikka toimittaja ei saisi yhtään laatupisteitä arviointiperusteissa, niin sen tuottama laatu pitäisi olla riittävää.

Otetaanpa esimerkki. Ajatellaan, että tarjouspyynnön arviointiperusteissa laadun painoarvo on 50% ja hinnan 50%. Ajatellaan edelleen, että saadaan kolme tarjousta, joista yksikään ei saa yhtään laatupistettä. Tällöin tulee kuitenkin valita yksi näistä (joka siis on halvin).

Mutta tässäkin tapauksessa tietenkin tuon valitun järjestelmän olisi oltava "riittävän" hyvä asiakkaan tarpeisiin.

Mielestäni ei ole muuta loogista johtopäätöstä kuin tuo edellä mainittu: vähimmäisvaatimukset tulee määrittää siten, että niiden täyttyminen takaa riittävän hyvän järjestelmän.

ARVIOINTIPERUSTEET

Mikä on sitten laadun osuus arviointiperusteissa? Jos kerran vähimmäisvaatimuksilla saavutetaan riittävän hyvää, niin tästähän seuraa loogisesti, että arviontiperustelaatu on ylimääräistä laatua. Eli asiakas saa jotain parempaa kuin mitä välttämättä tarvitsee.

Tästä loogisesti seuraa se, että järkevä laadun osuus arviointiperusteissa ei voi olla kovin korkea. Otetaan esimerkiksi lähtökohta, että arviointiperusteissa laadun osuus on 50% ja hinnan osuus 50%. Mitä tämä merkitsee käytännössä? Ääri tapauksessahan tämä tarkoittaa, että jos kilpailijat eivät pärjää laatupisteytyksessä, niin "laatutoimittaja" tulee valita, oli sen tarjouksen hinta vaikka kuinka korkea. (Vaikka se ei saisi juuri yhtään hintapistettä, niin laadusta saadut 50% takaisivat valinnan, koska muut eivät saaneet laatupisteitä)."Maksaa mitä tahansa" on kova hinta, kun kyse on kuitenkin vain "ylimääräisestä" laadusta. 
   
JOHTOPÄÄTÖKSET
Looginen johtopäätös on, että hankinnoissa laatu pitäisi erityisesti määrittää vähimmäisvaatimuksiin. Tämä tarkoittaa sen ymmärtämistä ja määrittämistä, mikä on "riittävän hyvä": mitä ovat sitä kuvaavat mittarit ja tavoitetasot. Ei varmasti monesti ole helppoa, mutta siihen nähdäkseni tulisi pyrkiä ja on siis erittäin keskeinen hankkijan tehtävä.

Jos näin toimittaisiin, tämä tarkoittaa myös kulttuurillista muutosta toimittajapuolella. Nykyään toimittajat "ruksivat" täyttävänsä vähimmäisvaatimukset (koska muuten pullahtaisivat pois kilpailutuksesta). Jos vähimmäisvaatimuksissa aidosti edellytetään laatua, niin ruksiminen kyllä edellyttäisi toimittajilta aitoa pohtimista, mihin he oikeasti sitoutuvat.

Miten paljon laatua sitten arviointiperusteisiin? Mielestäni ylimääräiseen laatuun tulisi laittaa (veronmaksajien) rahoja vain hyvin perustellusti.

MUTTA...
Tämä kirjoitus on luonteeltaan  "järkeilyä" ja voi olla idealistinen.  Käytännön realiteetit voivat asettaa omat haasteensa. Varmaan yksi sellainen on, että jos kukaan tarjoajista pysty vähimmäisvaatimuksiin.

Ja voi tuossa järkeilyssäkin olla jokin pielessäkin. Palautetta otan mielelläni vastaan (mielellään nimi näkyviin!)

Laatu pakollisiin vaatimuksiin eikä valintakriteereihin tarjouspyynnöissä

Hupsista! Kirjoitin aluksi tämän jutun tuli vahingossa tähän toiseen blogiini.

Katso kirjoitus Hanki käytettävyyttä! -blogista: 
http://hankikaytettavyytta.blogspot.com/2012/01/laatu-pakollisiin-vaatimuksiin-eika.html


(Pahoillani ylimääräisestä klikkauksesta. Ehdin kuitenkin levittää tätä linkkiosoitetta, ja tänne joku lukija saattaa tulla).

Koulutus "Käytettävyys tietojärjestelmien hankinnoissa" 12.3.2012

Koulutuksen tiivistetty kuvaus: 


Yksi suurimmista ja yleisimmistä tietojärjestelmien riskeistä on järjestelmien vaikeakäyttöisyys ja kaikkiaan epäonnistunut käyttäjäkokemus. Vaikeakäyttöisistä järjestelmistä kärsitään laajasti eri aloilla terveydenhuollosta VR:n verkkopalveluihin. Tämä on tilanne tänään, vaikka päättäjien keskuudessa tehtyjen tutkimusten mukaan helppokäyttöisyyttä kuitenkin pidetään yhtenä tärkeimpänä tietojärjestelmien laatukriteerinä.

Käytettävyys tietojärjestelmien hankinnoissa -koulutuksessa käydään läpi käytettävyyden varmistamiseen liittyviä haasteita, nykyisten käytäntöjen ongelmakohtia ja esitetään vaihtoehtoisia toimintamalleja, joilla käytettävyys aidosti saataisiin mukaan projekteihin. Uudet toimintamallit tarkoittavat aika merkittäviä muutoksia nykyisiin hankintakäytäntöihin. Päivän koulutuksen tarkoituksena ei ole antaa keittokirjamaista ratkaisua, vaan lähtökohdat ja valmiudet oman toiminnan kehittämiseen sekä oikeiden valintojen tekemiseen.

Koulutuksessa keskitytään erityisesti käytettävyyteen asiakaskohtaisten järjestelmien hankinnassa, mutta sivutaan myös valmisohjelmistojen hankintaa. Koulutus on tarkoitettu tietojärjestelmäprojekteissa oleville henkilöille niin hankkijapuolella kuin toimittajapuolellakin. Koulutuksen aluksi käydään läpi käytettävyyden keskeiset perusteet, jolloin koulutus soveltuu myös henkilöille, joille käytettävyys ei ole kovin tuttua.

Koulutuksen järjestää Tietotekniikan liitto. Ks. koulutuksen tarkempi ohjelma

Uusi kirja käytettävyydestä (käyttäjäkokemuksesta) julkishallinnon järjestelmissä

Kohta ilmestyy kirja "Usability in Government Systems" (Morgan Kaufmann).

Kirjasta on alustavaa tietoa kirjan alustavilla sivuilla. Sivuilla ei vielä ole edes sisällysluetteloa, mutta kirjoittajat koostuvat alan kansainvälisistä asiantuntijoista. 

Kirjoitin siihen yhden kappaleen amerikkalaisen kollegani Elizabeth Buien kanssa: "Getting UX into the contract". Tiivistelmä:  

Poor usability persists in government systems mainly because government agencies fail to specify usability in a way that ensures the production of adequately usable systems, or are not prepared to ensure usability by themselves. This chapter looks at how governments initiate system development projects, prepare RFPs and proposes some approaches to solving the problem. It uses examples from Finland and the United States to illustrate the concepts it presents. 

Kerron sitten tarkemmin, kun kirjasta sisällöstä ja julkaisuajankohdasta tulee tarkempaa tietoa.