POTILASTIETOJÄRJESTELMÄN KETTERÄN KÄYTETTÄVYYSTESTAUSMENETELMÄN KEHITTÄMINEN

Transkriptio

1 POTILASTIETOJÄRJESTELMÄN KETTERÄN KÄYTETTÄVYYSTESTAUSMENETELMÄN KEHITTÄMINEN Anne Lehtimäki Opinnäytetyö Marraskuu 2018 Hyvinvointiteknologia Ylempi ammattikorkeakoulututkinto

2 TIIVISTELMÄ Tampereen ammattikorkeakoulu Ylempi ammattikorkeakoulututkinto Hyvinvointiteknologian koulutus LEHTIMÄKI ANNE Potilastietojärjestelmän ketterän käytettävyystestausmenetelmän kehittäminen Opinnäytetyö 57 sivua, joista liitteitä 3 sivua Marraskuu 2018 Potilastietojärjestelmien käytettävyys on aiheuttanut paljon uutisia viime aikoina. Uutiset eivät ole olleet positiivisia: huono käytettävyys on saanut aikaan muun muassa stressiä hoitohenkilökunnalle. Mikä sitten on aiheuttanut moisen uutistulvan potilastietojärjestelmän huonosta käytettävyydestä juuri nyt? Tähän kysymykseen löytyy vastaus uudesta järjestelmästä, joka on otettu käyttöön useissa sairaanhoitopiireissä. Asiakkaat ovat tottuneet käyttämään aiempaa potilastietojärjestelmää, ja uusi järjestelmä tuo uusia käyttötapoja ja vaatii loppukäyttäjien kouluttamista. Uusi tuote ja uudet käyttötavat huolettavat loppukäyttäjiä, joilla ei ole aikaa opetella uusia asioita kiireisen hoitotyön vuoksi. Tämän opinnäytetyön tarkoituksena on tutkia, mikä on käytettävyystestauksen tila Tieto Healthcare ja Welfare -yrityksessä, ja kehittää yrityksen ketterän tuotekehityksen käytettävyystestausta. Yrityksessä panostetaan käytettävyyssuunnitteluun ottaen huomioon loppukäyttäjien käyttötapoja. Lisäksi yrityksessä panostetaan testaukseen, varsinkin työnkulkutestaukseen. Työnkulkutestauksilla jäljitetään loppukäyttäjien tekemiä työnkulkuja järjestelmässä. Nämä työnkulut on haettu hoitohenkilökunnalta heidän kanssaan keskustellen. Myös loppukäyttäjät ovat tarkistaneet työnkulkutestauksen. Ketterä tuotekehitys tuo haasteensa käytettävyystestauksen järjestämiselle loppukäyttäjien kanssa. Tähän työhön on etsitty ketterän tuotekehityksen käytettävyystestausmenetelmiä, ja ylipäänsä erilaisia käytettävyystestausmenetelmiä. Tutkimuksessa selviää, miten käytettävyystestausta tehdään nykyisin ja mitä kehittämisen kohteita siitä löytyy. Lopputuloksena saadaan mallinnus käytettävyystestausmenetelmästä potilastietojärjestelmän ketterässä tuotekehityksessä. Loppukäyttäjien saaminen mukaan käytettävyystestaukseen voisi tuoda ratkaisuja potilastietojärjestelmän käytettävyysongelmiin ja vähentäisi heidän stressiään. Asiasanat: potilastietojärjestelmä, käytettävyystestaus, ketterä tuotekehitys

3 ABSTRACT Tampereen ammattikorkeakoulu Tampere University of Applied Sciences Master s Degree in Wellbeing Technology LEHTIMÄKI ANNE Development of a patient information system s agility testing Bachelor's thesis 57 pages, appendices 3 pages October 2018 The usability of patient information systems has caused a lot of critical news lately. Poor usability has caused, among other things, stress to nursing staff. What may have caused all the recent critical news about the usability of patient information systems? The reason might be a new patient information system, which has recently been introduced in several hospital districts. The system s customers are used to using the previous patient information system, and the new system introduces new ways of use and requires additional end user training. The new product and new ways of use are of concern for the end users, who do not seem to have enough time to learn the use of the new system due to the busy nature of healthcare work. The purpose of this thesis is to investigate how Usability Testing is performed by Tieto Healthcare & Welfare and to develop the usability testing of the company's agile product development. The company invests in usability planning, considering end user usage. In addition, the company invests in testing, especially in workflow testing. Workflow testing tracks end user workflows in the system. These workflows have been collected from the nursing staff while discussing the workflows with them, and end users have also verified the workflow testing. Agile product development places a challenge for organizing usability testing with end users. For this work, agile product development usability testing methods and various usability testing methods in general have been sought. This study shows how Usability Testing is done today and how could it possibly be developed in the future. This thesis results in a modelling of a usability testing method in the agile product development of the patient information system. Involving end users in the usability testing could create solutions to the patient information system s usability challenges, and possibly reduce the stress experienced by the end users. Key words: patient information system, usability testing, agile product development

4 4 SISÄLLYS 1 JOHDANTO TUTKIMUSASETELMA Tutkimus- ja kehittämismenetelmät Tutkimuksen tavoite ja tarkoitus Tutkimuskysymykset TERVEYDENHUOLLON TIETOJÄRJESTELMÄ JA POTILASTIETOJÄRJESTELMÄ POTILASTURVALLISUUS KETTERÄ MENETELMÄ ELI AGILE DEVELOPMENT Vesiputousmalli Ketterät menetelmät Scrum DevOps TIEDON POTILASTIETOJÄRJESTELMÄN KÄYTETTÄVYYSTESTAUS Tieto terveydenhuollon tietojärjestelmien tuottajana Käytettävyyssuunnittelu tuotekehitys prosessissa Käytettävyyssuunnittelun sijoittaminen scrum malliin Tiedon käytettävyystestauksen prosessi KÄYTETTÄVYYS KÄYTETTÄVYYSTESTAUS Käytettävyystestauksen eri testausmenetelmiä Käyttäjäherätteinen käytettävyystestaus aidossa käyttöympäristössä Käytettävyystestauksen analysointi ja esittäminen KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ RITE + Krug-menetelmä Autodesk extreme Scenario-Based Design ANALYSOINTI KEHITYSEHDOTUKSENA: UUSI TOIMINTAMALLI POHDINTA LÄHTEET... 53

5 5 LYHENTEET JA TERMIT Agile APO AVI Backlog Bug DevOps Increment MDD OPO Scrum Sprint Sprint planning Scrum Master THL User Story Workflow ketterä menetelmä Area Product Owner, aluetuotteen omistaja Aluehallintovirasto tuotteen kehitysjono virhe ohjelmoinnissa toimintamalli sähköisten palvelujen tuotantoon inkrementti, tuoteversio Medical Devices Directive, Lääkintälaitedirektiivi Operative Product Owner, tuotteen omistaja scrum sprintti sprintin suunnittelu scrummaster Terveyden ja hyvinvoinnin laitos käyttäjätarina työnkulku

6 6 1 JOHDANTO Opinnäytetyön aihe saatiin Tieto Healthcare & Welfare -yritykseltä. Tieto Healthcare & Welfare tuottaa potilastietojärjestelmää sekä julkisen puolen että yksityisen sektorin terveydenhuollolle. Työn tavoitteena on kehittää käytettävyystestauksen toimintamallia potilastietojärjestelmän ketterässä tuotekehityksessä. Tarkoituksena on analysoida yrityksen nykyinen käytettävyystestausmenetelmä ja löytää uusia menetelmiä sekä tuoda ehdolle uusia toimintatapoja potilastietojärjestelmän ketterän tuotekehityksen käytettävyystestaukselle. Terveydenhuollon ammattilaiset pitävät potilastietojärjestelmiä hankalasti käytettävinä. Usein he kokevat, että potilastietojärjestelmän käyttö hankaloittaa heidän varsinaista työtään (Martikainen, 2015). Potilaan hoitamiseen jää heidän kokemuksensa mukaan vähemmän aikaa, koska potilastietojärjestelmän käyttö vie niin suuren osan heidän työajastaan (Martikainen, 2015). Martikainen on tutkimustyössään selvittänyt, mitkä tekijät vaikuttavat terveydenhuollon tietojärjestelmien huonoon käytettävyyteen ja miten tärkeää on saada loppukäyttäjät mukaan käytettävyyden kehittämiseen terveydenhuollon järjestelmien kehityksessä. Terveydenhuollon tietojärjestelmien käytettävyyttä on tutkittu, ja yleinen vaikutelma on se, että käytettävyyden kehittämiseen pitäisi käyttää enemmän resursseja (Martikainen, 2015). Potilastietojärjestelmän käytettävyys on ollut viime aikoina terveydenhuollon kuuma puheenaihe. Terveyden ja hyvinvoinnin laitoksen (THL) artikkelin mukaan Terveydenhuollon tietojärjestelmien heikko käytettävyys stressaa työntekijöitä (THL, artikkeli, 2018). Adusson toimitusjohtaja Janne Pitkänen kertoo haastattelussa, että nyt olisi korkea aika käydä rakentavaa keskustelua potilastietojärjestelmien käytettävyydestä. Adusso on keskittynyt käytettävyystestaukseen ja käytettävyyden parantamisen ratkaisuihin. (Itewikin artikkeli, 2018.) Potilastietojärjestelmän käytettävyystestaus on erittäin tärkeää myös potilasturvallisuuden kannalta. Järjestelmän käytettävyyden tulee tukea loppukäyttäjää tekemään työnsä niin, ettei tulisi inhimillisiä virheitä, jotka voivat vaarantaa potilasturvallisuuden. Käytettävyys voi joskus tarkoittaa elämän ja kuoleman välistä eroa (Tullis & William, 2013). Heikko käytettävyys voi johtaa erittäin kriittisiin tilanteisiin,

7 7 joissa tarpeellinen tieto ei ole saatavissa silloin kuin sitä tarvitaan. Mikäli tarpeellinen tieto on saavuttamattomana hoitotilanteessa, tilanne voi olla potilaalle hengenvaarallinen (Martikainen, 2015). Ketterä tuotekehitysmenetelmä asettaa omat haasteensa käytettävyyden testaukselle (Koskela, 2014). Terveydenhuollon ammattilaiset tulisi saada mukaan tähän ketterään tuotekehityssykliin. He ovat kiireisiä oman työnsä vuoksi, joten yhteisen ajan löytäminen käytettävyystestaukselle on haasteellista. Tarvitaan ketterä tapa saada myös työssä olevat ammattilaiset mukaan käytettävyyden testaukseen. Tärkeintä on saada oikeat alan ammattilaiset mukaan oikeaan aikaan.

8 8 2 TUTKIMUSASETELMA 2.1 Tutkimus- ja kehittämismenetelmät Opinnäytetyön tutkimusote on ensisijaisesti konstruktiivinen. Päämääränä on ymmärtää potilastietojärjestelmän käytettävyystestauksen nykytilanne ja sen kohtaamat haasteet ketterässä tuotekehityksessä. Opinnäytetyön on tarkoitus löytää nykyisten menetelmien haasteet sekä innovatiivisia ratkaisuja tosielämän ongelmiin, kuten konstruktiivinen tutkimusote edellyttää. Aineiston kerääminen konstruktiivisessa otteessa sisältää tutkijan ja käytännön edustajien tiivistä yhteistyötä. Tämän opinnäytetyön aineiston keruu sisältää Tiedon käytettävyysasiantuntijoiden haastatteluja sekä tuotekehitystiimin kanssa käytyjä keskusteluja. Nykytilanteen kartoittamiseksi aineistoa on kerätty olemassa olevista Tiedon sisäisistä dokumenteista. Lisäksi tutkijan pitkä kokemus tuotekehityksen testauksesta tuo näkemystä käytettävyystestauksen kehittämistarpeista potilastietojärjestelmän ketterässä tuotekehityksessä. Opinnäytetyön toissijainen tutkimusote on laadullinen, sillä tutkimuksessa kartoitetaan myös ymmärrystä käytettävyydestä, käytettävyystestauksesta ja ketterästä tuotekehityksestä. Laadullista tutkimusotetta varten on aineistoa kerätty kirjallisuudesta ja aikaisemmista tutkimuksista. Varsin teoreettinen tutkimusote vaatii teoreettista aineistoa, jota käytetään apuna nykyisen tilanteen analysoinnissa. 2.2 Tutkimuksen tavoite ja tarkoitus Opinnäytetyön tavoite on kehittää yrityksen käytettävyystestauksen toimintamallia. Tarkastelun lähtökohtana on selvittää nykyinen toimintamalli potilastietojärjestelmän käytettävyystestauksessa Tiedolla. Tutkimuksen aikana etsitään muita mahdollisia menetelmiä, jotka voisivat sopia potilastietojärjestelmän käytettävyystestaukseen.

9 9 Terveydenhuollon järjestelmien kanssa mennään asiakkaan ehdoilla: käytettävyystestauksen aikana pyritään tutustumaan asiakkaan työhön ja toiminnan logiikkaan, jotta järjestelmä tuntuisi asiakkaasta luontevalta. Ketterä tuotekehitys on nopeasyklistä, ja loppukäyttäjien saaminen mukaan käytettävyystestauksiin on haasteellista. Loppukäyttäjillä on omat kiireensä hoitotyön saralla, eikä heillä ole aikaa irtaantua hoitotyöstä käytettävyystestaukseen. Myös potilastietojärjestelmän tuottajalla on haasteena mahduttaa käytettävyystestaus mukaan ketterään tuotekehitykseen. (Skypepalaveri käytettävyysasiantuntijoiden kanssa, 10/2017.) Opinnäytetyön tarkoituksena on keskittyä ketterän tuotekehityksen käytettävyystestaukseen. Työssä selvitetään yleisesti, mitä menetelmiä tällä hetkellä on käytössä käytettävyyden testauksessa. Näin löydettyjä menetelmiä vertaillaan keskenään sekä peilataan niiden käyttökelpoisuuteen ison järjestelmän käytettävyystestauksessa ottaen huomioon potilasturvallisuuden, hoitohenkilökunnan kiireen ja ketterän tuotekehityksen. Potilastietojärjestelmän käytettävyystestauksesta ei löydy aiempaa tutkimusmateriaalia. Aiempia tutkimuksia löytyy siitä, miten potilastietojärjestelmän käytettävyyttä tutkitaan ja miten käytettäviä potilastietojärjestelmät ylipäänsä ovat. Aikaisempia tutkimuksia käytettävyystestauksen sopivuudesta ketterään tuotekehitykseen löytyy web-pohjaisten sovellusten käytettävyystestauksesta. Kevyiden web-pohjaisten sovellusten käytettävyystestausmenetelmät eivät välttämättä tue potilastietojärjestelmän käytettävyystestausta, joka on haastavuudeltaan aivan eri tasoa. 2.3 Tutkimuskysymykset Opinnäytetyön tutkimuskysymykset ovat apuna nykyisen käytettävyystestausmenetelmän ongelmakohtien löytämiseksi potilastietojärjestelmän ketterässä tuotekehityksessä. Ensin kartoitetaan, mitä käytettävyystestauksen menetelmiä käytetään tällä hetkellä potilastietojärjestelmän tuotekehityksen parissa. Etsitään ketterän tuotekehityksen käytettävyystestausmenetelmiä pyrkimällä vastaamaan kysymykseen mitä muita menetelmiä on olemassa. Lisäksi tutkimusmateriaalia läpikäytäessä pohditaan, miten asiakas saadaan ajoissa ketterässä tuotekehityksessä olevan sovelluksen käytettävyyden testaamiseen ja miten käytettävyystestaus hoidettaisiin, niin ettei se kuormittaisi asiakasta ja miten se antaisi lisäarvoa tuotekehitykseen.

10 3 TERVEYDENHUOLLON TIETOJÄRJESTELMÄ JA POTILASTIETOJÄRJESTELMÄ 10 Valvira määrittelee terveydenhuollon tietojärjestelmän seuraavasti: Tietojärjestelmällä tarkoitetaan sosiaali- tai terveydenhuollon asiakastietojen sähköistä käsittelyä varten toteutettua ohjelmistoa tai järjestelmää, jonka avulla tallennetaan ja ylläpidetään asiakastai potilasasiakirjoja ja niissä olevia tietoja. Tietojärjestelmän tulee täyttää yhteentoimivuutta, tietoturvaa ja tietosuojaa sekä toiminnallisuutta koskevat olennaiset vaatimukset, ennen kuin sen saa ottaa käyttöön. Tietojärjestelmän valmistaja on vastuussa vaatimustenmukaisuuden osoittamisesta. (Valvira 2018.) Potilastietojärjestelmä on osa terveydenhuollon tietojärjestelmää. Se sisältää useita sovelluksia, joita käytetään potilaan hoitamisen apuna. Potilastietojärjestelmän tuotekehityksen eri tiimeillä on vastuunsa eri sovelluksien kehittämisestä. Esimerkiksi yksi tiimi huolehtii seuraavista sovelluksista: hoitoisuusluokitus, kotihoito, määräys, päivystysmonitori ja hoitokertomus, kun taas toinen tiimi huolehtii mm. kertomuksesta ja ajanvarauksesta. Sovelluksia käyttävät eri ammattilaiset, esimerkiksi sairaanhoitajat käyttävät pääsääntöisesti hoitokertomusta, lääkärit puolestaan käyttävät paljon määräystä ja kertomusta. Nykyään potilastietojärjestelmän kirjaukset arkistoituvat Kanta-palveluun, josta kansalainen voi itse lukea kirjatut asiat sekä uusia reseptejä ja tarkistaa, mitä lääkettä olikaan saanut tiettyyn vaivaan. Näin ollen potilastietojärjestelmää käyttävät sekä hoitoalan ammattilaiset että terveys- ja sosiaalialan potilaat ja asiakkaat. Ja yhä enemmän myös potilaat ja asiakkaat itse käyttävät potilastietojärjestelmää, sillä terveydenhuolto on tuonut mm. etäkuntoutuksia, etävastaanottoja ja Omakanta-palvelun kansalaisille parantaakseen palveluitaan. (Kansaneläkelaitos, Omakanta, viite.)

11 11 4 POTILASTURVALLISUUS Terveyden ja hyvinvoinnin laitos (THL, viite) määrittelee potilasturvallisuuden seuraavasti: Potilas saa tarvitsemansa ja oikean hoidon oikeaan aikaan. Tähän kuuluu hoidon turvallisuus, lääkehoidon turvallisuus ja lääkinnällisten laitteiden turvallisuus. Terveydenhuollon tietojärjestelmän toimittajat ottavat potilasturvallisuuden huomioon potilastietojärjestelmän kehittämisessä. Terveydenhuollon tietojärjestelmän toimittajat kouluttavat työntekijänsä säännöllisesti potilasturvallisuuden tiimoilta. Terveydenhuollon laki tuli voimaan vuonna 2011 (8 Laatu ja potilasturvallisuus). Siinä todetaan seuraavaa: Terveydenhuollon toiminnan on perustuttava näyttöön ja hyviin hoito- ja toimintakäytäntöihin. Terveydenhuollon toiminnan on oltava laadukasta, turvallista ja asianmukaisesti toteutettua. Kunnan perusterveydenhuollon on vastattava potilaan hoidon kokonaisuuden yhteensovittamisesta, jollei siitä muutoin erikseen sovita. Terveydenhuollon toimintayksikön on laadittava suunnitelma laadunhallinnasta ja potilasturvallisuuden täytäntöönpanosta. Suunnitelmassa on otettava huomioon potilasturvallisuuden edistäminen yhteistyössä sosiaalihuollon palvelujen kanssa. Sosiaali- ja terveysministeriön asetuksella säädetään asioista, joista on suunnitelmassa sovittava. Aluahallintovirasto (AVI, viite) valvoo lain noudattamista seuraavien kriteerien avulla: - Potilaskeskeisyys (asiantuntijuus, osallisuus, vuorovaikutus) - Potilasturvallisuus, riskien arviointi, ennakointi ja niiden hallinta - Hoidon oikea-aikaisuus - Osaaminen - Sujuvuus - Vaikuttavuus (terveyshyöty) - Henkilöstön määrän mitoitus Terveydenhuollon tietojärjestelmien tuottajien tulee myös noudattaa tuota lakia ja ottaa se huomioon järjestelmän toiminnallisuuden ja käytettävyyden suunnittelussa ja toteutuksessa.

12 12 Terveydenhuollon tietojärjestelmien tuottajien tulee noudattaa myös lääkinnällisten laitteiden direktiiviä (Medical Devices Directive, MDD). Tämä tarkoittaa sitä, että markkinoille tuotetut lääkinnälliset laitteet ovat määräysten mukaisia eivätkä vaaranna potilaiden, käyttäjien ja muiden henkilöiden turvallisuutta ja terveyttä, kun ne on asianmukaisesti asennettu ja niitä käytetään asianmukaisesti. (Tiedon sisäinen materiaali, 2018.) Tämä otetaan huomioon tuotekehityksen käytettävyys suunnitteluissa sekä tuotekehityksen testauksissa. Käytettävyystestauksellakin saataisiin lisävarmuutta siihen, että tuote on direktiivin mukainen.

13 13 5 KETTERÄ MENETELMÄ ELI AGILE DEVELOPMENT Tässä luvussa käsitellään ohjelmistotuotannon menetelmiä, vesiputous, ketterä (agile) menetelmä sekä DevOps. Vesiputousmenetelmä on näistä kolmesta menetelmästä vanhin, ja se on pohjana muille menetelmille. 5.1 Vesiputousmalli Vesiputousmalli on useiden nykyaikaisempien menetelmien taustalla. Vesiputousmallin ideana on tehdä tuotekehitystä eri vaiheissa niin, että ensin tehdään aina yksi vaihe loppuun, ennen kuin seuraava vaihe voi alkaa. (Juvonen, 20118, 15.) Kuva 5 kuvaa vesiputousmallin yksinkertaisimmillaan. Kuva 5. Vesiputousmalli (Juvonen, 2018, 16) Vesiputousmallin hyviä puolia ovat selkeys ja suunnitelmallisuus: tässä menetelmässä voidaan olla varmoja, että kaikki vaiheet on suunniteltu ja dokumentoitu. Huonona puolena koetaan vesiputousmallin kankeus: siinä ei ole mahdollista palata taaksepäin, vaan vaiheet mennään läpi eteenpäin. Vesiputousmallin projektitkin ovat todella pitkiä, ja kehityksen varrella määrittelyt saattavat muuttua, jolloin tulisi voida palata myös takaisin päin määrittelykohtaan.

14 Ketterät menetelmät Vesiputousmallin myötä on kehitetty uusia menetelmiä ohjelmistokehitystyöhön, kuten ketterät menetelmät. Ketterien menetelmien kehittäjinä pidetään ohjelmistokehittäjien joukkoa, joka parin päivän tapaamisellaan Utahissa keskusteli käyttämistään menetelmistä vuonna Tämä joukko nimesi parhaat menetelmänsä ketteriksi ja perusti Agile Alliance -järjestön (Agile Alliance, 2018). Agile Alliance -järjestö on määritellyt sittemmin ketterille menetelmille arvot ja periaatteet, jotka on määritelty Agile Manifestossa. Alla luetellut arvot ovat suora lainaus ketterän menetelmän julistuksesta (Agile Manifesto, 2018): Arvostamme: yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota asiakasyhteistyötä enemmän kuin sopimusneuvotteluja vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa. Muutama esimerkki myös Agile Manifeston määrittelemistä periaatteista ketterille menetelmille: Tärkein tavoite on tyydyttää asiakas toimittamalla tämän tarpeet täyttäviä versioita ohjelmistosta aikaisessa vaiheessa ja säännöllisesti. Otamme vastaan muuttuvat vaatimukset myös kehityksen myöhäisessä vaiheessa. Ketterät menetelmät hyödyntävät muutosta asiakkaan kilpailukyvyn edistämiseksi. Toimitamme versioita toimivasta ohjelmistosta säännöllisesti, parin viikon tai kuukauden välein, ja suosimme lyhyempää aikaväliä. Liiketoiminnan edustajien ja ohjelmistokehittäjien tulee työskennellä yhdessä koko projektin ajan. Rakennamme projektit motivoituneiden ihmisten ympärille. Annamme heille puitteet ja tuen, jonka he tarvitsevat, ja luotamme siihen, että he saavat työn tehtyä. Tehokkain ja toimivin tapa tiedon välittämiseksi kehitystiimille ja tiimin jäsenten kesken on kasvokkain käytävä keskustelu.

15 15 Toimiva ohjelmisto on edistymisen ensisijainen mittari. Ketterät menetelmät kannustavat kestävään toimintatapaan. Hankkeen omistajien, kehittäjien ja ohjelmiston käyttäjien tulisi pystyä ylläpitämään työtahtinsa hamaan tulevaisuuteen. Teknisen laadun ja ohjelmiston hyvän rakenteen jatkuva huomiointi edesauttaa ketteryyttä. Yksinkertaisuus tekemättä jätettävän työn maksimointi on oleellista. Parhaat arkkitehtuurit, vaatimukset ja suunnitelmat syntyvät itseorganisoituvissa tiimeissä. Tiimi tarkastelee säännöllisesti omaa tehokkuuttaan ja mukauttaa toimintaansa sen mukaisesti. (Agile Manifesto, 2018.) Liiketoiminnalle tärkeä asiakastyytyväisyys otetaan huomioon asiakaskeskeisessä ketterässä kehittämisessä. Menetelmässä saadaan mukaan kehitystyöhön ne asiakkaat, jotka käyttävät järjestelmää. Heiltä saatava palaute kehityksen varhaisessa vaiheessa on ketterässä tuotekehityksessä mahdollista. (Auer, Heinäsmäki, Hölttä, Kalliala, Laanti, Laine, Lekman, Miinalainen, Naski, Piiparinen, Puhakka, Pyhäjärvi, Pääkkönen, Räisänen, Sora, Taipale, Talvio, Tanninen, Toikkanen, Toivola, Toro, Valsta, Väyrynen, Weissenberg, 2013, 27.). 5.3 Scrum Ketteristä menetelmistä tunnetuin lienee Scrum. Scrum koostuu jaksoista, joita kutsutaan sprinteiksi. Sprintit ovat 1 4 viikon mittaisia työkokonaisuuksia. Sprintin aikana on tarkoitus saada aikaan jotain valmista toimitettavaksi asiakkaalle (Juvonen, 2018, 20). Potilastietojärjestelmän ketterässä tuotekehityksessä tavoitteena on saada toimitettavaksi tuote inkrementin aikana. Inkrementti sisältää 2 3 sprinttiä. Scrum-prosessissa on mahdollista reagoida nopeasti muutoksiin, kuten muuttuviin määrittelyihin. Sprintin aikana tehdään sovitut asiat ja silloin nautitaan työrauhasta. Mutta muuttuneisiin kohtiin pureudutaan ennen seuraavaa sprinttiä. Scrum pyörii nopealla syklillä, ja valmista saadaan aikaan tiheämmin kuin esimerkiksi vesiputousmallin

16 prosessissa. Kuva 6 kertoo scrum-prosessin jatkuvuuden, miten sprintit soljuvat eteenpäin. 16 Kuva 6. Scrum-prosessi (Scrum-prosessi, 2018) Jokainen sprintti suunnitellaan, priorisoidaan tehtävät, jotka sprintille otetaan. Varsinaisen sprintin aikana tehdään yhtäaikaisesti suunnittelu, kehitys, testaus ja katselmointi. Sprintin jälkeen pidetään jälkikatsaus, jossa esitellään mahdollisesti demo sprintin aikaansaannoista. Sprintin tekemistä seurataan tiimin tehtävälistan avulla. Sprintin suunnittelun aikana käydään läpi tuotekehityksen tuotekehitysjonoa muutostyöehdotuksien sekä uusien tuotteiden osalta. Scrum-tiimi ottaa tietyt työt omalle tehtävälistalleen. Tehtävälistalla hallinnoidaan käyttäjätarinoiden ja tehtäväjoukkojen etenemistä (Auer, Heinäsmäki, Hölttä, Kalliala, Laanti, Laine, Lekman, Miinalainen, Naski, Piiparinen, Puhakka, Pyhäjärvi, Pääkkönen, Räisänen, Sora, Taipale, Talvio, Tanninen, Toikkanen, Toivola, Toro, Valsta, Väyrynen, Weissenberg, 2013, ) 5.4 DevOps DevOps tulee sanoista Development ja Operations. DevOpsissa on kyse toimintamallista, jossa painotetaan ohjelmistokehittäjien ja IT-asiantuntijoiden kommunikaatiota ja yhteistyötä (Juvonen, 2018, 35). Toimintamallissa kehitys, testaus ja ylläpito tekevät tiivistä yhteistyötä. Kuva 7 havainnollistaa tämän kolmikon yhteistyötä.

17 17 Kuva 7. Keskiössä on kehityksen, testauksen ja ylläpidon yhteistyö (Juvonen, 2018, 35). DevOps-toimintamallin pääominaisuus on puolustaa automaatiota ja seurantaa kaikissa ohjelmistokehityksen vaiheissa integraatiosta, testauksesta ja vapauttamisesta käyttöönottoon ja infrastruktuurin hallintaan. DevOps-toimintamallilla pyritään lyhyempiin kehitysjaksoihin, lisääntyneeseen käyttöönottotaajuuteen ja luotettavampiin julkaisuihin, jotka ovat läheisessä yhteistyössä liiketoimintatavoitteiden kanssa. (Juvonen, 2018, 35.)

18 6 TIEDON POTILASTIETOJÄRJESTELMÄN KÄYTETTÄVYYSTESTAUS Tieto terveydenhuollon tietojärjestelmien tuottajana Vuonna 1968 Espoossa aloitti Tietotehdas Oy -niminen yhtiö toimintansa. Yhtiö kehitti ja ylläpiti tietojärjestelmiä Yhdyspankille ja muutamalle metsäyhtiölle luvulla yhtiö kasvoi useiden yritysostojen, fuusioiden ja strategisten kumppanuuksien ansiosta. Yhtiön nimikin muuttui matkan varrella TT Tiedoksi ja myöhemmin Tiedoksi. Vuonna 1999 suomalainen Tieto ja ruotsalainen Enator yhdistyivät, ja nimeksi muodostui TietoEnator. Sittemmin nimi on palannut juurilleen vuonna 2009, jolloin TietoEnatorista tuli Tieto. (Tiedon sisäinen materiaali, 2018.) Effica on modulaarinen terveydenhuollon tietojärjestelmä, jonka moduuleja ovat mm. terveyskertomus, ajanvaraus, laboratorio, kotihoito ja osastonhallinta. Effica on ollut useiden isojen sairaanhoitopiirien, kuten Etelä-Pohjanmaan, Keski-Suomen ja Itä-Savon potilastietojärjestelmänä. Effica-järjestelmän on valmistanut TietoEnator. Effican edeltäjänä toimi Sinuhe-niminen terveydenhuollon tietojärjestelmä. (Mäkelä, 2003.) Lifecare on uusi roolipohjainen terveydenhuollon tietojärjestelmä. Lifecare on sosiaalija terveydenhuollon kokonaisratkaisu, joka vastaa sosiaali- ja terveydenhuollon yhteisiin tieto- ja ohjaustarpeisiin hyvän hoidon tukena. Lifecare korvaa Effican. Ensimmäisen Lifecare-järjestelmän otti käyttöönsä Taivalkosken kunnan terveyskeskus vuonna Lifecare-järjestelmän tuotekehitys on jatkuvaa. Tuotekehitys sisältää ylläpidollisia töitä sekä uusien ominaisuuksien kehittämistä. ( Tiedon sisäinen materiaali, 2018.) 6.2 Käytettävyyssuunnittelu tuotekehitysprosessissa Käyttöliittymän suunnittelun pitäisi aina lähteä käyttäjän tarpeesta. Käyttäjiltä voi tulla toive käyttämänsä sovelluksen kehittämiseksi. Käyttäjä on saattanut havaita, että jokin käytettävyys ei sovelluksessa ole ihan kohdallaan tai että sovelluksessa voi olla jokin

19 19 puute, joka koetaan kehittämisen kohteeksi. Toisaalta tarve voi tulla havainnosta, että jokin tietty ominaisuus puuttuu sovelluksesta kokonaan. Tällöin voidaan tuottaa täysin uusi sovellus. Tekniset vaatimukset saattavat vaatia sovellukselle käytettävyyssuunnittelua, ja lain tuomat määräykset voivat puolestaan aiheuttaa sovellukselle uudistustarpeita. Muutoksia tai kehitystarpeita voi ilmetä myös liiketoiminnallisista syistä. (Martikainen, Tiedon sisäinen materiaali, 2018.) Tarpeen esiintyessä tehdään konseptisuunnittelu. Käytettävyyssuunnittelija määrittelee yhdessä käytettävyystutkijan, tuotteen omistajan (Operative Product Owner), aluetuoteomistajan (Area Product Owner) sekä käyttäjien kanssa mm. sen, minkälainen käyttöliittymän tarve on, kuka kehitettävää sovellusta käyttää ja miksi tarve on tullut. He tekevät näiden määrittelyjen mukaan käyttäjätarinat (User Story) sekä ominaisuudet (Features). Käyttäjätarina kuvaa yhden käyttäjän, kuten esimerkiksi lääkärin, käyttämää tapaa tehdä diagnoosi potilaalle. Tämä yksi käyttäjätarina liittyy isompaan kokonaisuuteen, kuten esimerkiksi diagnoosi sovelluksen käyttöliittymän uudistaminen. Kun konseptin suunnittelu on tehty ja määrittelyt luotu, alkaa varsinainen täytäntöönpano. Ensimmäisessä vaiheessa suunnitellaan käyttöliittymä ja vuorovaikutus. Käyttöliittymät ja vuorovaikutusmääritelmät katselmoidaan yhdessä käytettävyyssuunnittelijoiden, käytettävyystutkijoiden, tuoteomistajan, aluetuoteomistajan, käyttäjien, scrummastereiden ja tuotekehittäjien kanssa. Määrittelyiden tuloksena syntyneet ominaisuudet ja käyttäjätarinat viedään tuotekehityksen työjonolle (eng. backlog). Tuotekehitystiimi suunnittelee inkrementtisuunnittelussa, milloin voisivat ottaa uuden ominaisuuden työn alle. Tuotekehitystiimi arvioi työmäärän ominaisuudelle ja ottaa sen inkrementin jollekin kehitysjaksolle (eng. sprint). (Martikainen, Tiedon sisäinen materiaali, 2018.) Tämän tuotekehitysprosessin aikana tehdään lisää käyttöliittymän katselmointeja, käytettävyystestausta, itse tuotekehityksen koodaamista sekä testaamista. Tämä prosessi pyörii hyvässä yhteistyössä useiden eri tekijöiden kesken. (Martikainen, Tiedon sisäinen materiaali, 2018.) Kun tuotekehitys on valmis, käyttöliittymä katselmoidaan ja käydään läpi hyväksyntäkriteerit. Tässä ovat mukana scrummaster, tuotekehittäjät, tuotteen omistaja

20 sekä käytettävyyssuunnittelijat. Kuva 1 on hahmotus käytettävyyssuunnittelun tuotekehitys prosessista. (Martikainen, Tiedon sisäinen materiaali, 2018.) 20 Kuva 1. Käytettävyyssuunnittelun tuotekehitysprosessi (Martikainen, Tiedon sisäinen materiaali, 2018) Kuvassa 2 hahmotetaan käyttäjän tutkimus, vaatimusmäärittelyjen ja implementoinnin vaiheiden toiminnot, roolit sekä lopputulokset.

21 21 Kuva 2. Käytettävyyssuunnittelu, vaatimukset ja toteutus (Martikainen, Tiedon sisäinen materiaali, 2018) 6.3 Käytettävyyssuunnittelun sijoittaminen scrum-malliin Inkrementtisuunnittelun yhteydessä tuoteomistaja ja käytettävyyssuunnittelija luovat käyttäjätarinoita käytettävyyssuunnittelun ympärille. Kehitysjakson suunnittelun yhteydessä scrummaster, tuotekehitystiimi ja käytettävyyssuunnittelija suunnittelevat, mille jaksolle ottavat käyttäjätarinan (käyttäjätarinat) tuotekehitykseen (kuva 3). Kuva 3. Käytettävyyssuunnittelun sijoittaminen scrum-malliin (Martikainen, Tiedon sisäinen materiaali, 2018)

22 22 Potilastietojärjestelmän tuotekehitystä tehdään kahdella julkaisuhaaralla. Täysin uutta kehitystä tehdään haaralla 2 (uuden kehittämisen haara) ja ylläpidettäviä kehitys- ja korjaustöitä tehdään haaralla 1 (ylläpitohaara). Edellä kuvattu toimintamalli, jossa käytettävyyssuunnittelu sijoitetaan scrum-malliin, tehdään uuden kehittämisen haaralla. Ylläpitohaaran osalta tässä on toimintamallissa kehittämisen varaa. Uutta tuotekehitystä on mahdollista tehdä puhtaasti scrum-prosessilla. Kehitystiimi koostuu scrummasterista, kehittäjistä ja testaajista. Kehitystiimin työlista koostuu käyttäjätarinoista, virheraporteista ja pienistä tehtävistä. Työt tehdään sprinteissä, yksi sprintti kestää kaksi viikkoa. Jokainen sprint suunnitellaan ennen sen alkamista. Tuoteomistaja tuo kehitystiimin työlistalle työt käyttäjätarinat ja virheraportit (userstoryt ja bugit). Kehitystiimi valitsee sprintin suunnittelussa, mitä tuoteomistajan tarjoamista töistä ottaa seuraavalle työlistalle. Tuoteomistaja on yhdessä käytettävyyssuunnittelijan kanssa tehnyt inkrementtitasolla suunnitelman uudesta ominaisuudesta kokonaisuudessaan. Yhdessä tuoteomistaja ja käytettävyyssuunnittelija luovat käyttäjätarinat, jotka pohjautuvat ominaisuuteen. Tuoteomistaja tekee ominaisuudesta päätason inkrementtitason työlistalle. Myös käyttäjätarinat liittyvät ominaisuuteen, mutta ne ovat sprint-tason työlistalla. Uusien sovelluksien kehityshaarassa käytettävyyssuunnittelijat suunnittelevat käyttöliittymän ja esittelevät sen tuotekehityksen scrum-tiimille. Myös loppukäyttäjien kanssa käydään suunniteltu käyttöliittymä läpi. Käyttöliittymäsuunnitelmat myös katselmoidaan asiantuntijoiden kanssa, eli tuotteelle tehdään jatkuvaa sisäistä arviointia. Käytettävyyssuunnittelija pystyy näin ollen tekemään muutokset suunnitelmaan ennen kuin scrum-tiimi ottaa sen työlistalle. Jokaisen scrum-tiimin lähellä työskentelee myös tuoteasiantuntija sekä käytettävyysasiantuntija. Käytettävyyssuunnittelija suunnittelee yhdessä tuoteomistajan ja scrummasterin kanssa käytettävyystestauksen. Tuoteasiantuntija tietää tuotteen oikeat käyttäjät ja kommunikoi heidän kanssaan tarvittaessa tuotekehityksen aikana. Käytettävyyssuunnittelijoiden, tuoteasiantuntijoiden sekä tiimin yhteistyö on erittäin tärkeässä osassa ketterässä tuotekehityksessä. Heidän kommunikointinsa oikeiden asiakkaiden kanssa mahdollistaa sen, että tuotteesta tulee sellainen, jota oikea asiakas voi käyttää hoitotyötä tehdessään, ja että se on potilasturvallinen. Potilastietojärjestelmän kohdalla tämä tarkoittaa sitä, että saadaan

23 sellainen tuote, jonka käyttö ei vie liiaksi hoitohenkilöiden aikaa hoivatyöstä, eikä sen käyttö vaaranna potilasta eikä käyttäjäänsä. (THS, viite potilasturvallisuus.) 23 Tuotekehitykseen kuuluu myös tuotteen ylläpitotyö. Se koostuu pääasiassa virheiden korjauksista, joita on löytynyt tuotannossa olevasta järjestelmästä tai tuotekehityksen aikana tehdystä testauksesta. Ylläpitotöihin kuuluvat myös asiakkaan kautta tulleet kehitysehdotukset, joihin tulee reagoida. Kehitysehdotus voi olla jonkin toiminnallisuuden muuttaminen tai parantaminen. Myös ylläpitotyöt tehdään scrumprosessia noudattaen. Kehitysehdotus käydään läpi tuoteasiantuntijan (product specialist) kanssa. Tuoteasiantuntija esittää kehitysehdotuksen käytettävyyssuunnittelijalle, joka tekee muutossuunnitelman. Työnkulkutestaus: Tuotekehityksen ylläpitohaaralla tehdään workflow-testausta eli työnkulkutestausta, joka on summatiivista käytettävyystestausta. Summatiivisella tarkoitetaan arvioiden toteutettua testausta, jossa on otettu huomioon kaikki tekniset rajoitteet, ja sitä voidaan testata toteuttamiskelpoisilla työnkuluilla. Tämä sisältää useita eri työnkulkuja eri sovelluksille ja niiden yhteiskäyttöön liittyen. Tiedolla on kerätty valtavasti tietoa siitä, miten loppukäyttäjät käyttävät järjestelmää omassa työssään. Tiedämme mm. miten psykiatrisen osaston hoitaja tekee kirjauksiaan järjestelmään hoitotyön yhteydessä. Nämä tiedot on kerätty työnkulullisiin testitapauksiin. Testauksen aikana tarkastellaan laajasti ja tarkasti sitä, miten työnteko sujuu tietyllä julkaistavalla sovelluksella. Lisäksi Tiedon työnkulkuja testaavat henkilöt, jotka ovat olleet töissä hoitoalalla: hoitajat, lääkärit sekä hallinnon ihmiset, kuten pääkäyttäjät. Työnkulkutiimi koostuu teknisistä osaajista sekä hoitoalan koulutuksen saaneista henkilöistä. Tämä tiimi tekee työnkulullisia testauksia testiympäristössä sekä vierailee asiakkaiden luona käyden läpi työnkulullisia asioita järjestelmän kautta. Työnkulullinen testaus on järjestelmän läpileikkaavaa testausta, jossa suoritetaan tietty työnkuva, esimerkiksi päivystyksen sairaanhoitajan työnkulku siitä, miten hän hoitaa päivystykseen tulevan potilaan järjestelmän kautta.

24 Tiedon käytettävyystestauksen prosessi Tiedolla halutaan arvioida tuotteen käytettävyyttä yhdessä loppukäyttäjien kanssa. Näin saadaan tietoa käyttäjäkokemuksista. Käytettävyystestausta tehdään myös siksi, että voidaan mahdollisimman varhaisessa vaiheessa löytää käytettävyysongelmat. Mitä aiemmin käytettävyysongelmat saadaan selville, sen nopeammin saadaan ne myös korjattua, ennen tuotteen julkaisua. Loppukäyttäjiltä saadaan myös hyviä ja tuoreita näkökulmia tuotteen käytöstä. (Martikainen, Tiedon sisäinen materiaali 2018.) Mitä testataan ja milloin tehdään käytettävyystestausta? Tiedolla käytettävyystestausta tehdään tuotteille, jotka ovat sillä hetkellä tuotekehityksessä suunnittelu- ja kehitysvaiheessa. Käytettävyystestausta tehdään käyttämällä suunnitelmamalleja ja toimivaa sovellusta tuotekehityksen testiympäristössä. (Martikainen, Tiedon sisäinen materiaali 2018.) Miten käytettävyystestausta tehdään? Tiedolla potilastietojärjestelmälle tehdään formatiivista eli tutkivaa testausta. Tässä formatiivisessa testauksessa löydetään käytettävyysongelmat tuotekehityksen aikana. Formatiivinen käytettävyystestaus auttaa tekemään päätöksiä jo tuotteen suunnitteluvaiheessa. Myös summatiivista käytettävyystestausta tehdään tuotekehityksen myöhemmissä tuotekehityksen prosesseissa. Summatiivinen testaus Tiedolla on workflow-testausta eli työnkulullista testausta. (Martikainen, Tiedon sisäinen materiaali 2018.) Toimintatapaan kuuluvat myös sisäiset arvioinnit tuotteen käytettävyydestä. Arviointeja tehdään tuotteen suunnittelu- ja kehitysvaiheissa. Sisäisissä arvioinneissa käytetään apuna käytettävyyden heuristiikkaa ja työnkulkukuvauksia. (Martikainen, Tiedon sisäinen materiaali 2018.) Seuraavassa esittelen Jakob Nielsenin 10 heuristiikkaa (Nielsen Norman Group, 2018), joita käytetään tuotteen arvioinneissa: 1. Järjestelmän tilan näkyvyys - Järjestelmä pitää käyttäjät ajan tasalla siitä, mitä tapahtuu, antaen palautetta kohtuullisessa ajassa. - Toimiiko tuote? Mitä toimintoja tuotteella voi tehdä? Kertooko tuote, että tehty vaihe on nyt valmis?

25 2. Tuotteen ja tosielämän vastaavuus - Tuotteen ja sen ohjelmiston tulisi käyttää tavallisesta elämästä tuttuja termejä, sanontoja ja käsitteitä. - Onko käytetty kieli ja termi helppoa ymmärtää? Käyttäjien ohjaus ja vapaus - Järjestelmän tulee antaa mahdollisuus palata taaksepäin ja peruuttaa jokin toiminto. 4. Yhteneväisyys ja standardit - Järjestelmän tulisi olla johdonmukainen käytöltään eikä käyttää monia eri sanoja, tilanteita tai toimintoja, jotka tarkoittavat samaa asiaa. - Onko tuotteen käyttö helposti pääteltävissä muiden samankaltaisten tuotteiden osaamisella? 5. Virheiden estäminen - Erinomaiset virheen tunnistukset ja ilmoitukset estävät virheiden syntymistä ja toistumista. Opastus tulisi olla aina helposti saatavilla ja ymmärrettävissä. - Voiko tuotetta käyttää helposti virheellisesti vai estääkö tuote virheellisen käytön? 6. Muistettavuus - Järjestelmä auttaa käyttäjäänsä muistamaan, käyttäjän ei tarvitse muistaa tuotteen käyttöä tehdessään eri työvaiheita. - Onko tuotetta helppo alkaa käyttää opettelematta tai lukematta käyttöohjeita? 7. Joustavuus ja tehokkuus - Järjestelmä antaa kokeneille käyttäjille mahdollisuuden käyttää oikopolkuja nopeuttamaan toimintojaan. - Voiko tuotetta käyttää usealla eri tavalla onnistuneesti? 8. Selkeä ja minimalistinen suunnittelu - Järjestelmä sisältää yksinkertaisia, selkeitä ja luontevia käyttöliittymiä. - Onko muotoja käytetty miellyttävällä ja johdonmukaisella tavalla? 9. Virheiden diagnosointi ja niistä palautuminen - Järjestelmä auttaa käyttäjää diagnosoimaan virheitä ja pääsemään virhetilanteesta pois esimerkiksi virheviestien avulla. - Onko virheilmoitus ymmärrettävissä? 10. Apu ja dokumentaatio - Järjestelmä tarjoaa helposti apua ja käyttöohjeita dokumentaation avulla. - Ovatko ohjeet aina saatavilla? Annetaanko opastusta automaattisesti vaikeissa paikoissa?

26 26 Käytettävyystestauksen prosessi Käytettävyystestauksen prosessi on esitetty kuvassa 4. Kuva 4: Käytettävyystestauksen prosessi (Tiedon sisäinen materiaali, 2018) Prosessin vaiheet sanallisesti (Tiedon sisäinen materiaali, 2018): 1. Päätetään, mikä tuote ja työnkulku halutaan testata. 2. Määritellään testitapaukset, järjestetään käytännön asiat, kuten aikataulut ja paikka. Lisäksi valitaan moderaattori ja tarkkailijat. 3. Rekrytoidaan testihenkilöt. Testihenkilöinä on ollut mm. fysiatreja, sairaanhoitajia, sihteereitä, lääketieteen ja sairaanhoitajaopiskelijoita. Palveluiden testaamisessa on ollut myös kansalaisia. a. Ajanvaraus testaukselle tehdään viikkoja etukäteen, sillä hoitoalan loppukäyttäjät ovat todella kiireisiä, eikä sopivan ajan löytäminen ole helppoa. b. Lentäviä käytettävyystestauksia tehdään mm. sairaanhoitajien ja lääkinnän opiskelijoiden koulun hallissa. Tässä tapauksessa rakennetaan koulun halliin tai käytävälle testauslaboratorio ja rekrytoidaan satunnaisia opiskelijoita testaamaan prototyyppiä. 4. Ennen varsinaista käytettävyystestausta tehdään sisäistä pilottitestausta, jossa tarkistetaan testitapaukset ja tehdään lopulliset muutokset protoon tai tuotteeseen. 5. Testaustilanteessa on useita vaiheita: a. Käyttäjille annetaan lyhyt kuvaus testattavasta tuotteesta ja taustatarina: Moniajanvaraus: Olet ajanvaraaja Kiia Kotilainen Kotikaupungin keskussairaalassa, ja sinun pitäisi nyt varata aika polvileikkaukseen. Kuinka varaat ajan kaikille tähän liittyville resursseille? Näitä ovat aika hoitajalle, labra-aika (tulokset pitää olla saatu tietty aika ennen seuraavaa lääkäriaikaa) ja lääkäriaika ennen leikkausta, lääkäriaika leikkaukseen, leikkaussalin varaus, petipaikan varaus leikkauksen jälkeen. b. Nauhoitus: nauhoitetaan ääntä ja kuvaa. c. Loppukäyttäjää opastetaan ajattelemaan ääneen tuotteen testauksen aikana.

27 27 d. Moderaattori kertoo käyttäjille tehtävät. Moderaattori ei auta tuotteen käytössä ellei käyttäjä pyydä apua kohtaamaansa ongelmatilanteeseen. e. Käyttäjä suorittaa tehtävän ja tarkkailijat tekevät muistiinpanoja testauksen aikana. f. Loppukeskustelu: Keskustellaan lyhyesti tuotteen käyttökokemuksesta. Halutaan tietää, oliko käytettävyydessä jotain huonoa tai hyvää ja tuliko käyttäjille jotain ideoita tuotteeseen liittyen. g. Kyselylomake: käyttäjät täyttävät kyselylomakkeen, System Usability Scale (SUS) -lomake. 6. Testaajat tekevät raportin, jossa huomioidaan hyvät ja huonot puolet ja tehdään kehitysehdotukset. 7. Tulosten analysointi: Käydään läpi tarkkailijoiden muistiinpanot ja testaustilanteen nauhoitteet, analysoidaan löydökset sekä lasketaan kyselyn pisteet. 8. Analysoitujen tuloksien perusteella luodaan kehitysehdotukset tuotekehitykselle ja parannetaan käyttöliittymän suunnitelmaa. 9. Tulosten esittely ja uusien suunnitelmien esittely tuotekehittäjille. 10. Muutokset viedään tuotekehityksen toteutettavaksi.

28 28 7 KÄYTETTÄVYYS Käytettävyysstandardeja on monia. Standardi ISO määrittelee käytettävyyden seuraavasti: "Mitta, miten hyvin määrätyt käyttäjät voivat käyttää tuotetta määrätyssä käyttötilanteessa saavuttaakseen määritetyt tavoitteet tuloksellisesti, tehokkaasti ja miellyttävästi (Barnum, 2011, 11). Nielsen on luetellut käytettävyyden osatekijöiksi seuraavat käytettävyysmittarit (Nielsen Norman Group, 2018): 1. Opittavuus: miten helppo käyttäjien on suorittaa perustehtäviä sovelluksella ensimmäisellä käyttökerralla. 2. Tehokkuus: kun käyttäjät ovat oppineet sovelluksen käyttö, miten nopeasti he suoriutuvat tehtävistä. 3. Muistettavuus: miten nopeasti edellisen käyttökerran jälkeen käyttäjille palautuu muistiin tuotteen käyttö. 4. Virheettömyys: kuinka paljon virheitä käyttäjät tekevät, miten vakavia virheet ovat ja miten nopeasti käyttäjät selviytyvät virheistä. 5. Miellyttävyys: miten miellyttäväkäyttöinen sovellus on. Nielsen on määritellyt myös seuraavat termit eli käytettävyysmittarit (Nielsen Norman Group, 2018): käyttökelpoisuus = sovellus tarjoaa juuri tarvittavan toiminnallisuuden käytettävyys = miten helppo ja miellyttäväkäyttöinen sovellus on hyödyllisyys = käyttökelpoisuus + käytettävyys Käytettävyyden arvioinnin ja testauksen tavoitteina onkin selvittää seuraavat: Onko tuotteen käyttö helppoa ja helposti opittavissa, onko tuote miellyttävä käyttää, onko tuote käyttäjälleen hyödyllinen?

29 29 8 KÄYTETTÄVYYSTESTAUS Usability testing eli käytettävyystestaus tarkoittaa testausta, jonka avulla halutaan selvittää, miten loppukäyttäjä kokee tuotteen käytettävyyden. Käytettävyystestauksen aikana tarkkaillaan käyttäjää (testaaja, oikea käyttäjä) tämän käyttäessä tuotetta. Käytettävyystestauksessa halutaan löytää myös epäkohdat käyttöliittymästä ja toiminnallisuudesta. Näin saadaan muutostarpeet tuotteelle. Tarkoituksena ei kuitenkaan ole löytää kaikkia mahdollisia ongelmia, vaan parantaa tuotetta. Näin ollen ei ole tarkoitus järjestää raskaita käytettävyystestauksia, vaan keskittyä oleelliseen (Ovaska, Aula, Marjaranta, 2005, 188). Käytettävyystestaus on menetelmä, jota käytetään tuotekehityksen aikana, ja mieluiten ennen kuin tuote viedään tuotantoon. (Hyysalo, 2009, 164.) Käytettävyystestauksen aikana arvioidaan käytettävyyttä, jossa loppukäyttäjä suorittaa tuotteen aitoja käyttötilanteita muistuttavia tehtäviä. Käytettävyystestauksesta saatuja tuloksia ja aineistoja tulee analysoida huolellisesti, jotta diagnosoituja käytettävyysongelmia voidaan esittää tuotteen kehitysvastaaville. (Ovaska, Aula, Marjaranta, 2005, 187.) Tuotteen käytettävyydestä saadaan tietoa, kun tarkkaillaan oikeiden käyttäjien toimintaa ja käyttäytymistä tuotetta testatessa. Testaukseen olisi hyvä saada enemmän kuin yksi tai kaksi käyttäjää, jotta saataisiin tarpeeksi kattavia tuloksia. Käytettävyystestaustilanteessa on myös mukana 1 3 tarkkailijaa. Moderaattori eli testivalvoja valvoo ja johtaa testitilannetta. Muut tarkkailijat voivat toimia teknisinä tarkkailijoina tai taustahavainnoitsijoina. Testattavana on koko tuote, sen prototyyppi tai tuotteen jokin osa. (Ovaska, Aula, Marjaranta, 2005, 188.) Testauksen aikana tarkkailijat kirjoittavat muistiinpanoja, videoivat ja havainnoivat. Lopuksi pidetään loppuhaastattelu, jossa testikäyttäjä voi antaa vastauksia kysymyksiin, kuten miltä sovellus tuntui. Käytettävyystestissä on tarkoitus saada vastauksia mm. seuraaviin kysymyksiin: Mikä sovelluksen käytössä toimi hyvin tai odotetusti? Käytettiinkö sovellusta kuten sitä on suunniteltu käytettävän? Pystyttiinkö sovelluksella tekemään kaikki tehtävät? Minkälaisia virheitä ja ongelmia ilmeni testauksen aikana? (Hyysalo, 2009, 165.)

30 30 Käytettävyystestauksen vahvuutena on löytää varhaisessa vaiheessa mahdolliset puutteet ja ongelmat. Haasteina taas on löytää resurssit käytettävyystestauksen tekemiseen. Etenkin ajankäyttö on suurimpia haasteita varsinkin potilastietojärjestelmän käytettävyystestauksessa. Oikeiden käyttäjien saaminen testaustilaisuuteen on haaste. Olennaisen käytettävyystestauksesta tekee Jakob Nielsenin lause: Sinun paras arvauksesi ei ole tarpeeksi hyvä. (Barnum, 2011, 9.) Kuva 9 esittelee käytettävyystestausprosessin, joka on käytössä myös potilastietojärjestelmän käytettävyystestauksessa. Kuva 9. Käytettävyystestausprosessi (Martikainen, Tiedon sisäinen materiaali) 8.1 Käytettävyystestauksen eri testausmenetelmiä Ääneen ajattelu -testimenetelmässä käyttäjät tekevät testitehtäviään ja samalla kertovat ääneen, mitä ovat tekemässä ja miksi. Tätä menetelmää voidaan käyttää myös paperiprototyyppitestauksessa. Menetelmällä saadaan selville käyttäjien kokemukset ja heidän kohtaamansa ongelmat sovellusta käytettäessä. (Hyysalo, 2009, 175.) Paritestaus-menetelmässä käyttäjät keskustelevat keskenään sovellusta käyttäessään. Tämä voi olla hedelmällinen tapa, kun kaksi ammattilaista vuorovaikuttaa keskenään

31 testatessaan sovellusta, mutta se voi myös sotkea testausta, jos käyttäjät ovat tottuneet erilaisiin toimintatapoihin. (Hyysalo, 2009, 176.) 31 Hiljaa suoritettavissa käytettävyystestauksissa mitataan esimerkiksi, miten kauan tehtävien suorittamiseen kuluu aikaa. Tätä menetelmää käytettäessä testaus olisi hyvä videoida, jotta sitä voidaan jälkeenpäin analysoida. Näitä testauksia suoritetaan normaalisti erikoistilassa, jossa on analysointia helpottavia ohjelmia tai laitteita, esimerkiksi silmänliikekamera. (Hyysalo, 2009, 176.) Jälkikäteen haastattelu tulee aina kaikkien käytettävyystestauksien jälkeen. Tähän tarkoitukseen on tehty kyselyjä, joiden avulla selvitetään sovelluksen käyttökokemukset, helppokäyttöisyys sekä miellyttävyys. (Hyysalo, 2009, 176.) Heuristinen arviointi on asiantuntijan arviointimenetelmä. Tämä on käyty läpi kappaleessa 6.4. Asiantuntija katselmoi sovelluksen läpi käyttäen apunaan tarkistuslistoja, esimerkiksi Nielsenin heurestiikkaan liittyviä listauksia. (Hyysalo, 2009, 177.) Ryhmäläpikäynti-menetelmässä yhdistetään käyttäjien osallistuminen ja asiantuntijoiden arviointi. Testitehtävät käydään läpi yhdessä ja samalla pohditaan tuotteen toiminnallisuutta. (Sampsa Hyysalo, 2009, 177.) Formatiivinen testaus, toisin sanoen tutkiva tai muodostava testaus. Formatiivista testausta tehdään pääasiassa tuotekehityksen suunnittelu- ja kehitysvaiheissa, kuitenkin ennen tuotteen valmistumisvaihetta. Testauksen kohteena on esimerkiksi käyttöliittymän suunnittelukuvat tai tuotteen prototyyppi. Tutkivan testauksen osuus muodostuu tässä testauksen tavasta löytää mahdolliset ongelmatilanteet, ei niinkään tarkkaan suunnitelluilla testiskenaarioilla, vaan tarkkojen suunnitelmien ulkopuolelta. (Rubin, 2008, 34.) Muodostavan testauksen tapana on ääneen ajattelu testauksen tiimoilta (Nielsen, 1993, 170). Summaava testaaminen, toisin sanoen arvioiva testaaminen, toteutetaan normaalisti tuotekehityksen loppuvaiheessa. Tällöin tarkastelun kohteena ovat loppukäyttäjien oikeat käyttötavat, ja testauksessa käytetään tuotteen prototyyppiä. (Rubin, 2008, )

32 32 Barnum esittää teoksessaan Usability Testing Essentials, että käytettävyystestausta ei tarvitse tehdä laboratorio-olosuhteissa eikä arvioijan tarvitse olla läsnä, kun käyttäjä tekee käytettävyystestausta. Hän kertoo, että käytettävyystestausta voidaan tehdä myös (Barnum, 2011, 25 26) ihan missä tahansa tilassa, kuten kokoushuoneessa kentällä, joko asiakkaan tiloissa, kokoushuoneessa tai jopa asiakkaan kotona tai missä tahansa asiakkaat ovat etänä joko niin, että tarkkailija on toisessa paikassa ja käyttäjä toisessa, tai niin, että käyttäjä testaa itsekseen laitteilla, joilla voidaan kerätä heidän toiminnat talteen (videoiva sovellus taustalla ottaa jokaisen klikkauksen tms. talteen), tai sitten käyttäjä testaa automatisoidulla työkalulla, josta saadaan nopeasti palautetta käyttämällä pieniä esimerkkejä. Etätestaus-menetelmä mahdollistaa käyttäjien osallistumisen käytettävyystestaukseen vapaammin, heitä ei tarvitse sitoa tiettyyn paikkaan tai aikaan. Etätestauksesta on eri termejä, joista on esitetty kaksi yleisintä Barnumin kirjassa (Barnum, 2011, 41): 1. Moderated testing (ohjattu testaus) tarkoittaa sitä, että moderaattori (testauksen tarkkaileva johtaja) on etätestauksessa läsnä. 2. Unmoderated testing (ohjaamaton testaus) tarkoittaa web-pohjaisen sovelluksen kautta tehtävää etätestausta. Ohjattu etätestaus on kuin laboratoriotestausta etänä. Moderaattori (testauksen ohjaaja), testaukseen osallistuvat käyttäjät ja tarkkailijat eivät ole fyysisesti samassa tilassa. Joissakin tapauksissa tällaisen käytettävyystestauksen osallistujat voivat olla monessa eri paikassa. (Barnum, 2011, 42.) Ohjaamatonta etätestausta kutsutaan myös asynkroniseksi tai automatisoiduksi testaukseksi. Testauksen apuna käytetty web-pohjainen sovellus tallentaa kuvankaappaukset, näppäimistön painallukset, hiiren klikkaukset, navigointipolut ja erilaisia suoriutumisnopeuksia. Nämä tallenteet sovellus kerää raporttiin. Kaupallisia web-pohjaisia tuotteita tätä varten ovat Keynote, User Zoom ja Relevant View. (Barnum, 2011, 44.)

33 33 Lab in a bag on käytettävyystestausmenetelmä, joka tarkoittaa, että testaaja menee loppukäyttäjien luo tuotteen prototyypin, tietokoneen, kameran ja muiden testauksessa tarvittavien laitteiden kanssa. (Scott, 2009, 11.) 8.2 Käyttäjäherätteinen käytettävyystestaus aidossa käyttöympäristössä Tämä on suhteellisen uusi menetelmä, jonka tarkoituksena on tuoda helpotusta seuraaviin ongelmiin, jotka on tunnistettu terveydenhuollon tietojärjestelmien kehitystyössä: 1. loppukäyttäjien hankala saavuttaminen hoitohenkilökunnan kiireisestä työstä johtuen 2. epäkäytännöllinen työntutkimus, potilaiden tietosuojaukseen liittyen oikeassa käyttöympäristössä ei ole suotavaa olla ulkopuolisia tutkijoita 3. käytettävyyden arviointikeskeisyys tukee lähinnä järjestelmien valinnan helpottamista, eikä niinkään niiden kehittämistyötä 4. kustannustehokkuus, oikeassa ympäristössä tehtävä käytettävyystestaus yhdessä terveydenhuollon henkilöstön ja kehittäjien työaikana on kallista. (Pitkänen, Pitkäranta, Kaipio, Uusi menetelmä terveydenhuollon tietojärjestelmien kehittämisen avuksi, 2013, ) Tämä menetelmä eroaa perinteisestä käytettävyystestauksesta esimerkiksi siinä mielessä, että tätä ei suoriteta testauslaboratoriossa tai muussa kontrolloidussa tilanteessa tai ympäristössä. Käyttäjäherätteisessä käytettävyystestauksessa kerätään käyttäjäkokemuksia aidossa ympäristössä, ja tiedonkeruu koostuu käyttäjän kokemista ongelmallisista ja ilahduttavista käyttötilanteista hänen omassa käyttöympäristössään. Tällä menetelmällä halutaan päästä keskittymään kehitystyön olennaisempiin ongelmiin, joihin halutaan ratkaisu, sekä oikeiden käyttäjien ilahduttamiseen. (Pitkänen, Pitkäranta, Kaipio, Uusi menetelmä terveydenhuollon tietojärjestelmien kehittämisen avuksi, 2013, 69.) Käyttäjäherätteisessä käytettävyystestausmenetelmässä testaus tehdään aidossa ympäristössä, joka tarkoittaa käyttäjän päivittäin käyttämää työasemaa. Työasema koostuu normaalisti tietokoneesta, johon on kytketty näyttö, hiiri ja näppäimistö. Tähän työasemaan liitetään tietokoneen, näppäimistön sekä hiiren väliin erillinen tallennin,

34 34 muisti sekä painikekonsoli, jossa on vihreä ja punainen painike. Tallentimen tehtävänä on kerätä näytönkuvaa, hiiren painalluksia sekä näppäimistöllä tapahtumia toimintoja. Painikekonsolista lähetetään tallenteelle tietoa käyttäjän tyytyväisyydestä. Vihreä valo tarkoittaa positiivista kokemusta ja punainen negatiivista kokemusta, toisin sanoen ongelmatilanteesta. Lisäksi voidaan liittää laitteistoon mikrofoni, jolloin käyttäjä käyttää järjestelmää ääneen, ja kokemukset ääneen käytöstä jäävät tallenteelle. Tämä menetelmä ei vaadi erillisiä ohjelmistoasennuksia tietokoneelle eikä muutoksia paikalliseen verkkoon. Tallenteet voidaan siirtää suoraan paikalliseen muistiin. Kuvassa 10 on esitetty käyttäjäherätteisen käytettävyystestauksen laitteisto Kuva 10: Kuvankaappaus käyttäjäherätteisen käytettävyystestauksen laitteistosta (Pitkänen, Pitkäranta, Kaipio, Uusi menetelmä terveydenhuollon tietojärjestelmien kehittämisen avuksi,2013, 69) Seuraavassa kuvassa (11) on havainnoitu käytettävyystestauksessa syntyvän käyttötapahtumatallenteen rakenne.

35 35 Kuva 11: Kuvankaappaus käytettävyystestauksen käyttötapahtumatallenteen rakenteesta (Pitkänen, Pitkäranta, Kaipio, Uusi menetelmä terveydenhuollon tietojärjestelmien kehittämisen avuksi, 2013, 69) Käyttäjän tekemät toiminnot sovelluksessa, näppäimistön painallukset sekä hiiren klikkaukset tallentuvat videotallenteena. Tallenteet läpikäydessään käytettävyysasiantuntija analysoi niihin liittyvät käytettävyysasiat. Käytettävyysasiantuntija voi myös toistaa käyttäjän tekemiä toimintoja sekä mahdollisia ohjelmistovirheitä. Potilasturvallisuus ja potilastietosuoja turvataan siten, että tallenteiden säilyttämiseen käytettävät muistitikut on suojattu vahvalla salasanalla, sekä siten, että vain nimetyt henkilöt saavat käsitellä niitä. (Pitkänen, Pitkäranta, Kaipio, Uusi menetelmä terveydenhuollon tietojärjestelmien kehittämisen avuksi, 2013, 70.) Tämä menetelmä tuo aitoja käyttötilanteita aidosta ympäristöstä, ja tuloksena saadaan ymmärrys käyttäjien tavasta käyttää järjestelmää. Adusso on käytettävyystestausmenetelmä, joka perustuu edellä esitettyyn käyttäjäherätteiseen käytettävyystestaukseen, tehdään aidossa ympäristössä. Aitoon ympäristöön, esimerkiksi sairaalan psykiatrisen osaston sairaanhoitajan työasemaan, sijoitetaan musta laatikko. Tuo musta laatikko kerää kaiken datan sovelluksen käytöstä, jota sairaanhoitaja tekee. Mikäli toiminnan aikana tapahtuu jokin epäkohta sovelluksessa, käyttäjä merkkaa tapahtuman laitteen punaisella painikkeella. Hyvän käyttökokemuksen käyttäjä merkitsee vihreällä painikkeella. Mustan laatikon keräämä data tallennetaan muistitikulle. Kerätty data sisältää näytönkaappauksia, videoita, käyttäjän antamia palautteita, vihreän ja punaisen napin merkintöjä sekä hiiren painalluksia ja näppäinpainalluksia, jotka tallentuvat tekstitiedostona tallenteelle. Tallenteet käydään läpi kehittäjien kanssa. (Finland health, 2018.)

36 Käytettävyystestauksen analysointi ja esittäminen Käytettävyystestauksessa kerätyt havaintomateriaalit, muistiinpanot, videotallenteet ja tuotteen käytön lokitallenteet kannattaa koota yhteen paikkaan. Materiaaleista tehdään yhteenvetoraportteja esimerkiksi taulukoihin tai kuvioihin. (Ovaska, Aula, Marjaranta, 2005, 197.) Eräs tapa analysoida on käyttää analysointiasteikkoa: 4 = käytön estävä ongelma 3 = vakava käytettävyysongelma 2 = pienehkö ongelma 1 = kosmeettinen virhe 0 = ei ongelmaa Tämän analysoinnin pohjalta muodostuu listaus suunnittelutiimille, ja sitä käydään yhdessä läpi ja tehdään samalla korjausehdotuksia jokaiselle ongelmalle. (Hyysalo, 2009, 178.)

37 37 9 KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ Käytettävyystestauksen tuloksena saadaan suunnittelua ohjaavaa tietoa, joka on myös iteratiivista, kuten ketterä tuotekehityskin. Uusia käyttöliittymäversioita kehittyy koko ajan kokemusten ja palautteiden pohjalta. Ketterässä tuotekehityksessä kehitystiimien sekä käytettävyyssuunnittelijoiden olisi hyvä työskennellä yhdessä lähes päivittäin. Lähes päivittäinen kommunikointi pienentää kuilua käytettävyystiedon keräämisen ja muutosten välillä. Tästä tullaankin siihen, että käytettävyystestaus otetaan mukaan heti ketterän tuotekehityksen suunnitteluvaiheessa. (Eeva Kangas, 2015.) Kuvassa 12 on otettu käytettävyystestaus huomioon Scrum-sykliin. Kuva 12. Käytettävyystestaus osana scrum-sykliä. (Eeva Kangas, 2015) Sprintin aikana tehtävästä käytettävyystestauksesta on syytä tehdä nopeasti testattava (Eeva Kangas, 2015). Sprintin aikainen käytettävyystestaus on hyvä pitää mahdollisimman kevyenä. Yhden sprintin aikana ei saada aikaan kovin isoja tuotekehityksiä vaan pieniä kokonaisuuksia, joista lopuksi muodostuu isompi kokonaisuus. Näin ollen sprintin aikana suoritettavan käytettävyystestauksen aikana testattava osio on pienehkö palanen kokonaisuudesta. Inkrementin aikana on tarkoitus saada isompi kokonaisuus valmiiksi, jolloin tehdään myös laajempi käytettävyystestaus.

38 38 Käytettävyystestauksessa raportoinnilla on merkittävä osa. Mikäli tehdään kevyt käytettävyystestaus sprintin aikana, voi raportointikin olla nopeaa. Kangas esittää, että nopealla raportoinnilla haetaan lista ongelmista ja niihin muutospyynnöt. Ongelmista tuotetut muutospyynnöt tulee saada nopeasti tuoteomistajan tietoon, jotta ne saadaan tiimin työlistalle. Kangas tuo esiin myös sen, että joka sprintissä ei tarvitse tehdä käytettävyystestausta, mikäli sen aikana ei tuoteta selkeästi uutta toiminnallisuutta. Isompaa testausta ei kannata unohtaa, vaan se voitaisiin suorittaa, kun on isompi versiopäivitys on menossa tuotantoon. (Eeva Kangas, 2015.) Myös Northrop on esittänyt, että käytettävyystestauksesta olisi hyvä tehdä oma työlistansa tuotekehityksen muiden työlistojen kanssa. Hän esittää, että tehtäisiin käytettävyystestauksesta oma käyttäjätarina (User story), joka eroaa muista käyttäjätarinoista siinä, että se ei valmistu koskaan. Näin ollen tämä työlista tulee joka kerta inkrementin ja sprintin suunnittelussa mukaan, ja se otetaan tuotekehityksen jonolle osaksi muiden tehtävien kanssa. (Northrop, 2018.) Ketterän kehityksen aikana tehtävä käytettävyystestaus voidaan tehdä hankkeen alussa prototyyppivaiheessa tuotteen ollessa lähes valmis tuotteen ollessa markkinoilla. 9.1 RITE+Krug-menetelmä RITE (the Rapid Iterative Test and Evalutation method) -menetelmä yhdistettynä Steve Krugin käytettävyystestausmenetelmään on kevyt menetelmä käytettävyyden testaamiseksi (McGinn & Chang, 2013, 61). RITE-menetelmä suoritetaan siten, että yksi osallistuja suorittaa käytettävyystestauksen. Testauksen jälkeen ongelmakohdat tunnistetaan ja korjataan. Kun korjaukset on päivitetty järjestelmään, toinen osallistuja testaa samat tehtävät kuin edellinenkin osallistuja. Toisen testaussession jälkeen toistetaan jälleen kuvio, jossa ongelmakohdat tunnistetaan ja korjataan sekä päivitetään järjestelmään. Tätä toistetaan, kunnes käytettävyystestauksen suurimmat käytettävyysongelmat on tunnistettu ja korjattu sekä validoitu. (McGinn &

39 39 Chang, 2013, s. 62.) McGinn ja Chang havaitsivat tässä menetelmässä haasteena sen, että menetelmä vaatii useita osallistujia korjausten validointiin. Toisena haasteena koettiin tähän käytettävyystestausmenetelmään kuluva aika. Koska osallistujien määrä on suuri, muutoksien saaminen järjestelmään istuntojen aikana saattaa viedä kaksi viikkoa. Kolmas ongelmakohta on se, että RITE-menetelmässä testaus jatkuu, kunnes korjaukset on validoitu, joten testauksen loppuminen on näin ollen vaikea arvioida. (McGinn & Chang, 2013, 62.) Krug-menetelmän keskeisenä ajatuksena on, että yksi testaaja projektin aikaisessa vaiheessa on parempi kuin 50 testaajaa lähellä projektin loppua. Krug-menetelmä on saanut nimensä kehittäjänsä Steve Krugin myötä. Krug on vienyt käytettävyystestausmenetelmän erittäin nopeaksi testaukseksi. Menetelmä voidaan suorittaa päivässä käyttämällä ainoastaan kolmea tai neljää osallistujaa. Testauksen muodollinen raportti korvataan yhteisellä läpikäynnillä heti viimeisen testauksen valmistumisen jälkeen. Läpikäynnin aikana sidosryhmät kirjaavat muutokset, jotka päätetään tehdä. Tähän läpikäyntiin kuluu vähintään 30 minuuttia, ja se nopeuttaa korjauksien tekemistä. (McGinn & Chang, 2013, ) McGinn ja Chang yhdistivät nämä kaksi menetelmää. RITE+Krug-menetelmässä sitoutetaan sidosryhmät seuraamaan käytettävyystestaussessioiden kulkua. Menetelmässä käytetään 3 4 osallistujaa ja testisessiot jaetaan kahdelle päivälle. Ensimmäisenä päivänä kolme testaajaa suorittaa testauksen tehtävät ja toisena päivänä neljäs testaaja. Toisena päivänä tulokset käydään läpi sidosryhmien kanssa. McGinn ja Chang järjestävät tässä menetelmässä verkkokonferenssin, jolloin sidosryhmät pääsevät osallistumaan käytettävyystestaussessioon helposti. (McGinn & Chang, 2013, 64.) McGinn ja Chang huomasivat, että RITE+Krug-menetelmiä voidaan suorittaa useammin ja tiheämmin kuin perinteisiä menetelmiä. Menetelmässä pystytään testaamaan useita uusia ominaisuuksia aikaisessa vaiheessa ja tekemään muutoksia nopeammin. (McGinn & Chang, 2013, 65.) RITE+Krug-menetelmä mahdollistaa testauksen, tuloksien läpikäynnin ja muutoksien tekemisen muutamassa päivässä. Metodin katsotaan sopivan hyvin ketterään tuotekehitykseen. (McGinn & Chang, 2013, 66.)

40 Autodesk Autodesk on monikansallinen ohjelmistoyritys, joka tuottaa ohjelmistoja teollisuuteen, rakennussuunnitteluun, tekniseen suunnitteluun sekä media- ja viihdealalle. Autodesk toimii myös Suomessa. (Autodesk.fi, 2018.) Autodeskin ohjelmistokehitystiimin ottaessa käyttöön ketteriä menetelmiä haluttiin varmistaa, että tuotteita kehitetään edelleen asiakkaiden tarpeisiin. Heidän käytettävyyssuunnittelijansa kehittivät näin ollen oman toimintatavan ketterään ohjelmistokehitykseen. (Sy, 2007, 129.) Kuvassa 13 on Autodeskin käytettävyyssuunnittelijoiden kehittämä menetelmä. Kuva 13. Kuvankaappaus Desirée Syn artikkelista Adapting Usability Investigations for Agile User-centered Design, 2007 Tällä menetelmällä käytettävyyssuunnittelijat halusivat olla yhden syklin edellä tuotekehityksen sykliä. Nolla syklissä tutkitaan projektin alussa käytettävyyttä ja tehdään lyhyet vaatimusmäärittelyt. Ensimmäisessä syklissä määritellään arkkitehtuuriset vaatimukset tai ominaisuudet, jotka tarvitsevat vähän suunnittelua. Tämän ensimmäisen syklin toiminnot voivat sisältää mm. prototyypin suunnittelun toiselle syklille sekä nopeita käytettävyystestauksia suunnitelmille. Ensimmäiseen sykliin voivat kuulua myös nopeat haastattelut käytettävyydestä kolmatta sykliä varten. Toisessa syklissä esitetään suunnitelmat tuotekehittäjille, jotka tekevät sovelluksen koodauksen. Tässä vaiheessa suunnittelijat toimivat tiiviissä yhteistyössä tuotekehittäjien kanssa. Toinen sykli voi sisältää myös protypointia, käytettävyystestausta sekä haastatteluja kolmannen syklin

41 41 implementoinnille ja neljännen syklin suunnittelulle. Tämän menetelmän avulla käytettävyystestaus saadaan mukaan ensimmäisestä suunnittelusprintistä viimeiseen toteutussprinttiin. (Sy, 2007, ) Sy (2007, ) listaa havainnot tästä menetelmästä seuraavasti: 1. Ketterän kehityksen kommunikointitapa helpottaa käytettävyysdatan ja muutoksien tuomisen tuotekehitykseen. 2. Käyttäjäkeskeinen ketterä tuotekehitys mahdollistaa sen, että tuotekehitystiimi voi nojautua loppukäyttäjän mielipiteisiin. Käytettävyysasiantuntijoiden läsnäolo agile-tiimissä helpottaa tuotekehityksen kohtaamaa käyttäjäkokemuksien kautta kerättyä ja analysoitua dataa. 3. Tuttuja käytettävyystutkimusmenetelmiä voidaan käyttää ketterissä tuotekehitysprojekteissa, kuten mm. tutkiva testaus, käyttäjien ja tehtävien analysointi, haastattelut ja kentällä tapahtuva havainnointi. Tämä vaatii tutkimusmenetelmien ajoittamisen ja tulosten raportointien muuttamista. 4. Käytettävyys- ja suunnitteluprosessit voivat olla myös iteratiivisia ja koostua inkrementaalisista minijulkaisuista. Suunnittelu voi olla vähintään yhden sprintin edellä toteutusta. 5. Prototyyppinen demoaminen ja päivittäiset keskustelut korvaavat yksityiskohtaisemmat dokumentit, kuten käytettävyystestausraportit ja käyttöliittymämäärittelyt. 9.3 extreme Scenario-Based Design XSBD-malli (extreme Scenario-Based Design) kehitettiin Meridium-yritykselle ketterän tuotekehityksen ja käytettävyyssuunnittelun yhdistämiseksi. Menetelmällä haluttiin tuoda vastaus ketterän tuotekehityksen ja käytettävyystestauksen ongelmakohtiin. (Koskela, 2014, 53.) XSBD-mallissa käytettävyyssuunnittelijat työskentelevät yhdessä muiden tuotekehitystiimin jäsenten kanssa, kuten kehittäjien, laadunvarmistajien sekä asiakkaan edustajien. Käytettävyyssuunnittelijoiden ensisijainen vastuu on varmistaa, että tuotteen käyttöliittymä on loppukäyttäjien mieleen. (Lee, McCrickad, Stevens, 2009, 3.)

42 42 Käytettävyyssuunnittelu työskentelee yhden iteraation etukenossa tuotekehityksen tiimin työhön nähden. Tällä varmistetaan, että suunnitelmat voidaan toimittaa tuotekehittäjille. Näin he pääsevät heti tekemään implementointia. Keskeinen XSBD-prosessissa on suunnitteluesitys (CDR, Central Design Record). Tämä esitys tukee käytettävyyssuunnittelua sekä käytettävyyden arviointia. (Lee, McCrickad, Stevens, 2009, 3.) Kuva 14. Kuvankaappaus CDR-kaaviosta Leen ym. artikkelista, 2009, 4. Kuvassa 14 on kaavio CDR:stä. Eräs kriittisenä pidetty komponentti tässä CDRkehityskuviossa on suora kartoitus suunnittelun tavoitteiden, vaatimuksien ja käytettävyystestauksen tuloksien välillä. Tämä komponentti mahdollistaa käytettävyyssuunnittelijoiden keskittymisen ja tekee ainoastaan tärkeimmiksi nousseet käytettävyysominaisuudet. Tämä koetaan tärkeänä ketterässä tuotekehityksessä, jossa keskitytään toimittamaan tärkeimmät ohjelmiston osat asiakkaille mahdollisimman lyhyessä ajassa. (Lee, McCrickad, Stevens, 2009, 3.) XSBD-malli otettiin käyttöön Meridium-yrityksessä, jossa ketterät menetelmät olivat vielä melko uusi asia projektiryhmälle. Ja varsinkin käytettävyysasiantuntijan toimiminen tiimin mukana oli heille täysin uutta. Seuraavaksi on listattu tämän mallin käyttöönotosta muutamia huomioita (Lee, McCrickad, Stevens, 2009, 7): 1. Suunnittelutavoitteiden priorisoinnin avulla löydetään yhteisymmärrys käytettävyyssuunnittelijoiden ja ohjelmistokehittäjien välillä.

43 43 2. Vaatimukset ovat tehokkaita, ja niiden avulla voidaan ottaa huomioon suunnittelun perusteet ja säilyttää vaihtoehtoisia ehdotuksia tiettyjä ominaisuuksia varten. 3. Käytettävyyssuunnittelijoiden ja tiimin jäsenten on hyvä työskennellä yhdessä päivittäin. 4. Keskeisten suunnittelutavoitteiden avulla voidaan kehittää yhteneväisempiä käyttöliittymiä.

44 44 10 ANALYSOINTI Tämän tutkielman analysoinnissa käytettiin apuna tutkivan testauksen otetta. Raportointi on toteutettu teoriaa vasten taulukkoon Käytettävyystestauksen käytössä olevien menetelmien arviointi (liite 1), jonne listattiin teoriassa esitettyjä käytettävyystestausmenetelmiä ja peilattiin niitä uuden tuotekehityshaaran menetelmiin sekä ylläpitohaaran menetelmiin. Taulukossa tulee tulos passed, mikäli suurin osa toteutuu kunkin haaran menetelmissä. Failed-tulos tulee, mikäli suurin osa menetelmistä ei toteudu. Lisäksi analysoinnin apuna käytiin keskusteluja tuotekehitystiimin sekä käytettävyysasiantuntijoiden ja tuoteomistajan kanssa. Agile manifeston periaate asiakastyytyväisyydestä Agile manifeston periaatteista asiakastyytyväisyys, hyväksy muutos sekä toimiva sovellus Uuden tuotekehityksen haaralla: PASSED Ylläpitohaaralla: FAILED Huomioita: Agile manifeston periaatteista asiakastyytyväisyys ei toteudu ylläpitohaaralla olevan tuotekehityksen aikana. Asiakastyytyväisyys toteutuu uuden tuotekehityksen haaralla, sillä siellä otetaan huomioon asiakkaan toimintatavat sekä käydään käyttöliittymiä läpi asiakkaan kanssa testaten ja suunnitellen. Asiakas pääsee näin ollen tuotekehityksessä mukaan ja kuulemaan muutokset ja tietää tulleensa kuulluksi. Ylläpitohaaran muutossuunnitelmaa ei käydä asiakkaan kanssa läpi. Muutos monesti viedään seuraavassa julkaisussa suoraan käyttöön, ilman että se on käytettävyystestattu. Tosin työnkulullista testausta tehdään ylläpitohaaralla oleville tuotteille. Se on erittäin hyvä ja tärkeä osa tuotekehityksen etenemistä. Mutta se tehdään monesti tuotekehityksen loppuvaiheessa. Tutkimuksen esiin nostamia kehitysajatuksia: Muutossuunnitelma tulee käydä läpi asiakkaan kanssa. Näin varmistetaan, että muutos on heidän mielestään käytettävä. Asiakkaan hyväksyttyä muutossuunnitelman käytettävyyssuunnittelija esittää sen scrum-

45 45 tiimille. Tiimi suunnittelee yhdessä tuoteomistajan ja tuoteasiantuntijan kanssa muutostyön ottamisen tuotekehitysjonolle. Ketterän tuotekehityksen nopeat palautteet Ketterän kehityksen nopea palaute mahdollisimman aikaisessa vaiheessa Uuden tuotekehityksen haaralla: PASSED Ylläpitohaaralla: FAILED Käytettävyystestausmenetelmien käyttö Uuden tuotekehityksen haaralla: PASSED Ylläpitohaaralla: FAILED Huomioita: Uuden tuotekehityksen haaralla käytettävyystestaus on mukana jo suunnitteluvaiheessa. Näin ollen saadaan loppukäyttäjiltä nopeasti palautetta käytettävyydestä mahdollisimman aikaisessa tuotekehityksen vaiheessa. Käytettävyystestausta ei tehdä ylläpitohaaralla olevalle tuotteelle. Nykytilanne: Tuotannosta olevasta järjestelmästä (ylläpidossa oleva tuote) löydetyt tuotekehitykset/virheraporit tulevat asiakaspalveluun tiketteinä. Loppukäyttäjä kertoo huomaamastaan ongelmasta tuotteen käytössä pääkäyttäjälle. Pääkäyttäjä päättää, mitkä virheet raportoidaan eteenpäin palveluntuottajan asiakaspalveluun tikettinä. Asiakaspalvelu käy läpi tikettejä, joita on runsaasti. Asiakaspalveluhenkilö tiedustelee tikettiä tutkiessaan kehitystiimien tuoteomistajilta ja tuoteasiantuntijoilta, onko tiketissä esiintyvä kehitysehdotus/virheraportti sellainen, johon tulisi kiinnittää enemmänkin huomiota, vai voiko olla jokin muu syy, että se on raportoitu. Kun asiakaspalveluhenkilö, tuotteen omistaja ja tuoteasiantuntija kokevat, että tiketti on otettava työn alle, siitä tehdään tuottajalle joko käyttäjätarina työjonolle tai sitten virheraportti. Monesti tiketistä tehdään myös tutkittava aihe työjonolle, mikäli koetaan, että tuotekehittäjän olisi hyvä katsoa koodista ja analysoida, onko kyseessä todellakin virhe, tai minkälainen työ olisi tehdä kehitysehdotus. Käyttäjätarina tai virhe laitetaan työjonolle, ja inkrementtitason suunnitteluissa otetaan kantaa, mille sprintille sen

46 tekeminen voitaisiin ajoittaa ja arvioidaan, kuinka monta päivää sen toteuttaminen kestää. Sprint-suunnittelussa päätetään siitä, otetaanko se ehdotetulle sprintin työlistalle vai ei. 46 Tämän jälkeen kun käyttäjätarina tai virheraportti on päätetty ottaa sprintin työjonolle, sitä aletaan toteuttaa. Toteutuksen jälkeen se testataan kehitysympäristössä. Testausta tehdään paikallisesti, eli testataan vain se, mitä on toteutettu tai korjattu. Kun se on todettu toimivaksi, sille tehdään myös tutkivaa testausta, jolloin testataan sen ympärillä olevat asiat, että kaikki toimii edelleen moitteettomasti. Lopuksi tehdään työnkulkutestaus, jossa käydään kattavasti läpi työnkulku huomioiden muutos tai korjaus. Tämä nykyinen menetelmä palautteen saamisesta on melko hidasta, eikä se oikein sovi ketterään tuotekehitykseen. Haasteena tässä kohtaa nähdään loppukäyttäjien saaminen käytettävyystestauksen pariin ajoissa. Loppukäyttäjät ovat kiireisiä hoitotyössään, eikä heiltä liikene aikaa testata muutostyönkohteena olevan tuotteen käytettävyyttä. Seuraavassa esitän kehitysajatuksen kysymykseen, miten saada loppukäyttäjät ketterästi mukaan käytettävyystestaukseen: Etäkäytettävyystestaus voisi olla ratkaisu oikeiden käyttäjien saamiseksi mukaan käytettävyystestaukseen. Ylläpitovaiheessa ei ole useinkaan tarpeen tehdä mitään varsin isoa muutosta tai korjausta, vaan kyseessä ovat melko pienet muutostyöt, jotka olisi melko nopea testata käytettävyyden kannalta. Etätestauksen voisi järjestää tuoteasiantuntija, joka tuntee tuotteen käyttäjiä eri sairaanhoitopiireissä. Luodaan etätestausta varten ympäristö, johon viedään muutoksen saanut sovellus, ja sovitaan loppukäyttäjän kanssa, että käydään se heidän kanssaan nopeasti läpi. Tosin sairaanhoitaja ei voi hoivatyönsä ääreltä niin vain poistua tekemään käytettävyystestausta, mutta käytettävyystestaushetkestä tehdään nopeasti tehtävä se kestäisi enintään 15 minuuttia. Näin ollen käytettävyystestaus ei kuormittaisi hoitotyöntekijää. Etäyhteys on muodostettavissa Skypellä, jossa on myös nauhoitusmahdollisuus. Testaustilaisuus nauhoitetaan, ja tilaisuuden jälkeen tuoteasiantuntija analysoi tulokset yhdessä tuotteen omistajan kanssa. Tuo tilaisuus olisi hyvä yrittää järjestää kahden viiden hoitohenkilön kanssa, jotka käyttävät samaa sovellusta. Näin saataisiin heti laajempi käytettävyystestaus ja tulos on kattavampi. Jos ei saada sovittua yhteistä aikaa, käydään testaus läpi jokaisen kanssa erikseen. Palveluntuottajan puolesta etätestaustilaisuuteen olisi hyvä osallistua tuotteen omistajan lisäksi tuotekehitystiimin kehittäjä ja testaaja. Näin saadaan suoraan käyttökokemukset jaettua tuotekehitystiimille, joka aloittaa huomioiden käsittelyn heti käytettävyystestaustilaisuuden jälkeen.

47 47 Toisena kehitysajatuksena kysymykseen, miten saada loppukäyttäjät ketterästi mukaan käytettävyystestaukseen, nousee seuraava: Voitaisiinko ohjaamatonta etätestausta yhdistää käyttäjäherätteiseen käytettävyystestausmenetelmään? - Testiympäristöön olisi liitetty tallenninlaite, joka keräisi loppukäyttäjän sovelluksen käyttöä. Siihen olisi kytketty videointityökalu, joka napsahtaisi päälle joka kerta, kun joku käyttäjä kirjautuu työpöydälle (LC DESKTOP) - Tämä testiympäristö olisi virtuaalinen, ja siinä olisi aina uusimmat muutokset. - Loppukäyttäjällä olisi etäyhteysoikeudet testiympäristöön. Hän voisi käydä kokeilemassa tuotetta silloin, kun hänelle parhaiten sopii. - Testiympäristöön luodaan tietyt käyttäjät tietyillä rooleilla, jotka sopivat oikeisiin käyttäjiin. Konfiguraatiot olisivat yhteneväiset loppukäyttäjän konfiguraatioihin. - Tämä olisi potilastietosuojattua testausta, jolla käytettäisiin testipotilaita eikä oikeiden potilaiden dataa. Lab in a bag Uuden julkaisun haaralla olevien tuotteiden kanssa, jalkaudutaan lab in a bag - menetelmällä oppilaitoksiin, joissa opiskelee sairaanhoitajia, lääkäreitä ja muita hoitoalan ammattilaisia. Oppilaitoksen käytävälle rakennetaan testauspiste, jossa on läppäri, hiiri ja näppäimistö. Ohi kulkeville opiskelijoille annetaan jokin testitapaus, esimerkiksi potilastarina, jonka pohjalta opiskelija tekee kirjauksia järjestelmään. Järjestelmänä tässä tapauksessa toimii kehitysaikainen testausympäristö. Testitapaus on lyhyt ja nopeasti tehtävissä. Lopuksi opiskelija antaa palautteen, mikä oli hyvää ja mikä huonoa. Tämä on vallan mainio käytettävyystestausmenetelmä, jossa tavoitetaan useita loppukäyttäjiä. Tosin opiskelijat ovat monesti nuoria, uuden sukupolven tekijöitä, joille tietotekniikka on tuttua ja jotka omaksuvat nopeasti uusia käyttöliittymiä ja toimintoja eri järjestelmistä. Mutta miten on hoitohenkilökunnan vanhemman sukupolven tottumusten laita tietotekniikan kanssa? Kehitysajatus: Voisiko tämän tehdä myös sairaalassa, esimerkiksi henkilökunnan ruokalan läheisyydessä? Pystytetään testauslaboratorio hoitohenkilökunnan ruokalan läheisyyteen. Siinä loppukäyttäjät voivat vaikkapa ruokajonossa ollessaan suorittaa

48 48 nopean käytettävyystestauksen. Tai mikäli leikkaushoidon sovellukseen on tulossa muutos, muutosehdotuksen kanssa voitaisiin sijoittautua leikkausosaston käytävälle tai hoitohenkilökunnan sosiaalitiloihin. Ketterät käytettävyystestausmenetelmät Nykyinen käytettävyystestausprosessi kokonaisuudessaan voi olla turhan kankea ja hidas ylläpitohaaran muutos- ja korjaustöihin. Tuo prosessi sopii parhaiten uuden kehittämisen haaralle, jossa kehitetään täysin uusia käyttöliittymiä ja toimintoja. Tässä kehitysvaiheessa olevia tuotteita on syytä käytettävyystestata perusteellisesti. Sillä niiden halutaan kuitenkin tukevan loppukäyttäjän työntekoa ja tuoda uusia tuotteita, joilla saataisiin vielä enemmän hyötyä hoitotyön tekemiseen. Mutta onko nykyinen käytettävyystestausprosessi tarpeeksi ketterä? Tutkimusmateriaalin mukaan ketterässä tuotekehityksessä käytettävyystestaukset olisi hyvä pitää kevyinä. Näin ollen kevyet käytettävyystestaukset eivät vie hoitohenkilökunnalta aikaa hoitotyöltä. Lisäksi analysointiin tuodut ajatukset käytettävyystestauksesta omana käyttäjätarinana kehitystiimin työjonolle ovat erittäin varteenotettava vaihtoehto. Kehitysajatus: Yhdistämällä teoriassa esitettyjä menetelmiä, kuten Rite+Krug, Autodesk ja XSBD, voitaisiin saavuttaa myös potilastietojärjestelmän käytettävyystestauksessa uusia ulottuvuuksia. Näiden teorioiden pohjalla punaisena lankana ovat nopeat kevyet käytettävyystestaukset, joista tehdään kehitystiimien työjonolle oma käyttäjätarina. Näiden menetelmien myötä ehdottaisin tätä käytettävyystestauksen omaa käyttäjätarinaa sijoitettavaksi myös Tiedon tuotekehitystiimien työjonoille. Lisäksi näiden menetelmien ajatuksena on, että käytettävyyssuunnittelija työskentelisi tuotekehitystiimin kanssa. Kommunikointi helpottuu, kun voidaan tukeutua käytettävyyssuunnittelijan tietoon käytettävyyden tiimoilta sekä tuotekehityksen lujaan ammattitaitoon tehdä tuotteesta käytettävä. Nykyinen käytettävyystestausprosessi sijoittaa käytettävyyssuunnittelijan tuotekehityksen kanssa yhteistyöhön uuden tuotekehityksen haaralla, mutta ylläpitohaaralla tätä ei ole. Ylläpitohaaralla voidaan ottaa mukaan myös paikallinen käytettävyystestaustilaisuus. Inkrementin suunnittelun aikana tiimit miettivät keskenään, mitä asioita ottavat

49 49 ensisijaisesti inkrementin sisältämiin sprintteihin. Kun asiat on listattu, tiedetään mihin keskitytään. Sprintti suunnittelussa voidaan keskustella myös, missä kohdassa tehdään käytettävyystestaus. Voitaisiin ottaa käytettävyystestaus mukaan työn suunnitteluun ja ottaa jo loppukäyttäjiin yhteyttä ja sopia ajankohta sprintin puoliväliin, jolloin voitaisiin tehdä käytettävyystestausta. Tämän testaustilaisuuden voisi tuoteasiantuntija järjestää yhdessä tuotteen omistajan kanssa. Käytettävyystestaustilaisuudessa olisi hyvä olla 2 5 loppukäyttäjää sekä tuotteen omistaja, tuotekehittäjä ja tuotekehitystiimin testaaja. Näin testauksen tulos saadaan heti tiimin tietoon ja mahdolliset käytettävyyshuomiot työn alle. Lisäksi tästä tilaisuudesta saadaan valtavasti tietoa, miten tuotekehitystiimin testaaja voisi testata sovellusta. Esimerkkinä siitä, kuinka ylläpidossakin voisi hyödyntää käytettävyystestausta: Tiimin sovellukseen on tulossa muutos, joka vaikuttaa myös hoitotyötä tekevän käyttäjän tapaan käyttää sovellusta eli työnkulkuun. Inkrementin suunnittelun aikana otimme puheeksi tämän muutoksen ja siihen liittyvän käytettävyystestauksen. Kyseessä on ylläpitovaiheessa olevan sovelluksen muutos. Sprintin aikana tiimin tuotteen omistaja otti asiakseen järjestää käytettävyystestaustilaisuuden loppukäyttäjien kanssa. Hän otti yhteyttä asiakkaan edustajaan ja kysyi, olisikohan tällainen mahdollista. Asiakkaan edustaja innostui oitis ajatuksesta. Seuraavaksi tuotteen omistaja kysyi Tiedon päättäviltä tahoilta, olisiko tämä mahdollista. Tiimi sai ilman muuta luvan käytettävyystestaustilaisuudelle Tiedon taholta. Tuotteen omistaja ehdotti tiettyjä päiviä loppukäyttäjille tilaisuuden ajankohdaksi. Tämä onnistui todella nopeasti: jo viikon päähän saatiin sovittua käytettävyystestaustilaisuus asiakkaan luona. Tilaisuudessa käydään läpi ensin muutos, joka on tulossa sovellukseen. Tämän jälkeen loppukäyttäjät ohjataan kannettavan tietokoneen äärelle, josta on yhteys tuotekehityksen testausympäristöön. Loppukäyttäjille annetaan karkealla tasolla tehtävä, jonka he suorittavat sovellusta käyttämällä. Tehtävän suunnittelussa pyydetään apua käytettävyysasiantuntijoilta. Testauksessa käytettävälle kannettavalle tietokoneelle on asennettuna nauhoitusohjelma, joka nauhoittaa käyttäjän tekemät toiminnot, hiiren klikkaukset ja hiiren liikkumiset. Tämä käytettävyystestaustilaisuus on informatiivinen tilaisuus kaikille osapuolille. Loppukäyttäjät saavat ennakkoon tietoa tulevasta muutoksesta, tuotekehityksen tiimin jäsenet, kehittäjä ja testaaja saavat tärkeää tietoa loppukäyttäjien tavasta käyttää sovellusta sekä suorat palautteet tuotteen hyvistä ja huonoista puolista. Tämä tilaisuus, jossa tuotekehityksen tiimin jäseniä on mukana käytettävyystestauksessa, antaa myös

50 50 loppukäyttäjille positiivisen kuvan siitä, että heidän mielipiteillään on merkitystä. Kun tämä muutos jossain kohtaa tulee järjestelmään loppukäyttäjien lopulliseen käyttöön, sen käytön aloittaminen ei aiheuta vastustamista. Muutosvastarinta on melko yleistä uusien järjestelmien käyttöönotoissa, ja varsinkin, kun ne vain otetaan käyttöön ilman opastusta. Ylläpitohaaralla tulee ottaa huomioon työnkulkutestaus. Mikäli ylläpidossa olevaan tuotteeseen tehdään kehitysmuutos, joka vaikuttaa työnkulkuun, se on tuotava ilmi työnkulkutestaustiimille. Heille olisi hyvä kertoa muutoksesta ja pitää siihen liittyen esitelmä. Ylläpitotiimin vastuulla on huolehtia tämän esittelytilaisuuden järjestämisestä työnkulkutestaajille. Näin työnkulkutestitapaukset saadaan myös päivitettyä muutoksen myötä KEHITYSEHDOTUKSENA: UUSI TOIMINTAMALLI Potilastietojärjestelmän tuotekehityksen käytettävyystestausmenetelmien ketteröittäminen: Yhdistin ketteriä käytettävyystestausmenetelmiä, joita on esitetty kappaleessa 9, Tiedon ketterän tuotekehityksen malliin. Tein siitä mallinnuksen (liite 2). Tämä ehdotelma sopii molempien tuotekehityshaarojen linjoille, uuden kehittämisen haaralle ja ylläpitohaaralle. Käytettävyyssuunnittelija saa tuotekehityspyynnön scrum-tiimiltä, tuotteen omistajalta, tuoteasiantuntijalta tai loppukäyttäjien toiveesta. Käytettävyyssuunnittelijat ottavat kehityspyynnön omalle työjonolle. Suunnittelijoiden tiimi arvioi yhdessä tuotteen omistajan kanssa, milloin kehitystyö otetaan työn alle. Tästä tehdään oma käyttäjätarina käytettävyyssuunnittelijatiimin työjonolle. Käytettävyyssuunnittelija ottaa käyttäjätarinasta tehtävän kerrallaan työn alle, ja käyttöliittymän suunnittelu ja toimintojen suunnittelu voidaan aloittaa. Käyttöliittymän suunnittelun eräänä tehtävänä voisi olla suunnitelman läpikäynti yhdessä tuotteen omistajan ja loppukäyttäjän kanssa. Suunnittelutyön aikana tehdään myös uuden ominaisuuden käytettävyyden arviointia heurestiikan ja työnkulkukuvauksien avulla. Suunnittelutyöhön kuuluvat myös katselmoinnit, joita käydään läpi muiden käytettävyyssuunnittelijoiden, tuotteen omistajan ja toivottavasti tuotekehitystiimin kehittäjän ja testaajan kanssa.

51 51 Inkrementti on julkaisukelpoinen tuoteversio, joka sisältää normaalisti kolme sprinttiä, joiden aikana uuden ominaisuuden käyttäjätarinan/käyttäjätarinoiden tulisi valmistua. Viimeisen sprintin aikana käytettävyystestauskäyttäjätarina valmistuu, kun viimeinen käytettävyystestaus on käyty läpi. Tämän jälkeen tehdään työnkululliset testaukset, joissa uusi ominaisuus otetaan huomioon kokonaisuudessa potilastietojärjestelmän osana. Inkrementtisuunnittelun yhteydessä tuotteen omistaja esittää uuden ominaisuuden käyttäjätarinan/käyttäjätarinat scrum-tiimille. Suunnittelun aikana käyttäjätarinat käydään läpi, ja ne toimivat myös vaatimusmäärittelynä hyväksyntäkriteereidensä avulla. Tämä läpikäynti on vaatimusmäärittelyn testaamista. Inkrementtisuunnittelun aikana voidaan kysyä ja täsmentää uuden ominaisuuden käytettävyyttä ja toiminnallisuutta. Tuotteen omistajan on helppo esittää ominaisuuden käyttäjätarinat, sillä hän on ollut mukana suunnittelussa ja kuullut jo aikaisessa vaiheessa loppukäyttäjien mielipiteen niistä. Tuotteen omistaja tuntee ominaisuuden käyttötavat. Lisäksi vaatimusmäärittelyjen läpikäynnissä on ollut mukana kehittäjä ja testaaja, ja he ovat myös hyvässä valmiudessa kertomassa tulevasta työstä. Sprint-suunnittelun aikana suunnitellaan otettavaksi uuden ominaisuuden käyttäjätarina tai käyttäjätarinat. Näitä voi olla sprintillä työmäärän suuruudesta riippuen yks tai useampi. Mikäli on arvioitu, että yksi käyttäjätarina vie implementoinnilta ja testaukselta n. 8 työpäivää, ei voida ottaa mukaan kovin monta käyttäjätarinaa. Tuotteen omistajan tekemä käytettävyystestauskäyttäjätarina on myös otettava huomioon työjonoa suunniteltaessa. Käytettävyystestaus omana käyttäjätarinanaan tai sitten ominaisuuden käyttäjätarinan tehtävänä on hyvä, sillä silloin se tulee myös tehtyä. Tuotekehitystiimit voisivat ottaa sprinttien jatkuvaan tavoitteeseen uusien ominaisuuksien käytettävyystestauksen. Varsinkin ylläpitovaiheen tuotteissa tuotekehitystiimien ulottuvissa työskentelevä tuoteasiantuntija, joka tuntee loppukäyttäjiä, helpottaisi käytettävyystestauksen järjestämisessä. Se voitaisiin kevyimmin suorittaa etäyhteyksien avulla, esimerkiksi järjestämällä Skype-kokous. Näin on mahdollista saada mukaan useita loppukäyttäjiä, tuotteen omistaja, käytettävyyssuunnittelija ja tuotekehityksen tiimin jäseniä. Tuotekehityksen testausympäristöä voidaan hyödyntää tässä kohtaa. Kun käytettävyystestaus suunnitellaan hyvin, sen kestoa voidaan lyhentää sekä tehostaa.

52 52 11 POHDINTA Tiedon potilastietojärjestelmän nykyinen käytettävyystestaus ei saavuta loppukäyttäjiä halutulla tavalla. Loppukäyttäjät ovat kiireisiä omassa työssään, eikä heidän vapaaaikaansa haluta viedä tuotteiden käytettävyystestauksella. Käytettävyystestaus on kuitenkin erittäin tärkeä osa potilastietojärjestelmän tuotekehitystyötä. Käytettävyystestauksen avulla saadaan nopeasti palaute loppukäyttäjiltä tuotteen käytettävyydestä. Lisäksi puututtaessa ajoissa käytettävyydessä huomattuihin ongelmiin tai puutteisiin päädytään asiakasta miellyttävään toteutukseen. Kun loppukäyttäjä eli asiakas kokee tuotteen olevan käytettävyydeltään sujuva, hoitotyötä helpottava, hänen ei tarvitse kokea stressiä potilastietojärjestelmän käytöstä. Asiakkailla tulee olla varma ja turvallinen olo käyttäessään järjestelmää. Käytettävyystestauksella parannetaan tuotteen potilasturvallisuutta: huomioimalla sen toimivuus halutulla tavalla: lääkkeiden määräykset, diagnoosit ja kirjaukset menevät oikeille potilaille ja ne ovat myös potilasta hoitavan henkilön nähtävillä. Käytettävyystestausmenetelmiä on useita. Opinnäytetyössä on esitelty ne menetelmät, joiden katsotaan sopivan myös potilastietojärjestelmän käytettävyyden testaamiseen, varsinkin potilastietojärjestelmän ketterään tuotekehitykseen. Ketterä tuotekehitys - menetelmä on nopeasyklistä, loppukäyttäjät eivät tahdo pysyä ketterässä menetelmässä mukana. Mutta tuotekehityksen työn suunnittelussa huomioon otettuna käytettävyystestaus sopii ketterään tuotekehitykseen niin, että saadaan loppukäyttäjätkin mukaan. Hyvin suunnitellussa inkrementissä otetaan mukaan jo käytettävyystestaus yhtenä käyttäjätarinana. Näin ollen käyttäjätarina tulee tehdä loppuun asti. Mikäli tämä käyttäjätarina ei tahdo sulkeutua, on tuotekehitystiimin tuotava asia esiin ja sen eteen etsitään yhdessä ratkaisu. Käyttäjätarina on valmis, kun käytettävyystestaus loppukäyttäjän kanssa on tehty. Aikaisin suunniteltuna käytettävyystestauksen järjestäminen loppukäyttäjien kanssa helpottaa heidän mukaan saantiaan.

53 53 LÄHTEET Agile Alliance sivusto. Viitattu Agile Manifeston periaatteet -virallinen sivusto. Viitattu Auer, Heinesmäki, Hölttä, Kalliala, Laanti, Laine, Lekman, Miinalainen, Naski, Piiparinen, Puhakka, Pyhäjärvi, Pääkkönen, Räisänen, Sora, Taipale, Talvio, Tanninen, Toikkanen, Toivola, Toro, Valsta, Väyrynen, Weissenberg Ketterää kehitystä. Finn Lectura. Teoksen alkuperäinen nimi: 376 vuotta ketteriä kokemuksia. Autodesk yrityksen Suomen sivusto. Viitattu Barnum, Carol M Usability Testing Essentials: ready, set, --test!!. E-kirja. Vaatii kirjautumisen. TAMK-kirjasto. ewertype:khtml//root_slug:front-matter/url_slug:front-matter?b-toccid=kputerst06&b-toc-root-slug=&b-toc-url-slug=front-matter&b-toctitle=usability%20testing%20essentials%20- %20Ready,%20Set...Test!&page=last&view=collapsed&zoom=1 Finland Health sivusto. Adusso. Viitattu Hyysalo S Käyttäjätieto tuotekehityksessä: tieto, tutkimus, menetelmät. 2. painos. Jyväskylä: Gummerus Kirjapaino. IteWikin Ketterät menetelmät, agile, LEAN ja scrum Digitalisoinnin opas. Ladattava opas. Viitattu IteWikin sivusto. Haastattelu Potilastietojärjestelmän käyttöönotto vaatii lisäinvestointeja ja uudenlaisia ratkaisuja. Luettu QPQcX84 Juvonen R Ohjelmistoprojektin sudenkuopat ja miten ne vältetään. Helsinki: BoD-Books on Demand. Kangas E FixUi esitysmateriaali. Viitattu Kelan Kanta sivusto. Omakanta palvelu. Viitattu Koskela A Ketterän ohjelmistokehityksen ja kevyen käytettävyystestauksen yhteensovittaminen: Tapaustutkimus.

54 Lee J.C. McCrickard D.S. Stevens K.T Examining the Foundations of Agile Usability with extreme Scenario-based Design. Viitattu McGinn J. & Chang A Rite+Krug: A Combination of Usability Test Methods for Agile Design. Viitattu Martikainen S Väitöskirja. Towards Better Usability. Viitattu Mäkelä N. Terveydenhuollon tietojärjestelmät raportti, Viitattu Nielsen Norman Group heurestiikan sivusto. Viitattu Nielsen Norman Group artikkeli. Viitattu Usability 101: Introduction to Usability. Pitkänen J. Pitkäranta M. Ladattava tutkimus. Käyttäjäherätteinen käytettävyystestaus aidossa käyttöympäristössä. Luettu on_tietojarjestelmien_kehittamisen_avuksi_kayttajaheratteinen_kaytettavyystestaus_aid ossa_kayttoymparistossa Northrop B. Usability Testing on Agile Projects Viitattu Ovaska S. Aula A. Marjaranta P Käytettävyystutkimuksen menetelmät. Sarja: Raportti. Tampere: Tampereen yliopisto Sy D Adapting Usability Investigations for Agile User-centered Design. Viitattu : Terveyden ja hyvinvoinnin laitoksen sivusto. Potilasturvallisuus. Viitattu Terveyden ja hyvinvoinnin laitoksen sivusto. Artikkeli terveydenhuollon käytettävyydestä. Luettu Valviran sivusto. Tietojärjestelmät. Viitattu inen/tietojarjestelmat William A. and Tullis T Measuring the User Experience. Collecting, Analyzing, and Presenting Usability Metrics, edited by William Albert, Elsevier Science & Technology. ProQuest Ebook Central. Viitattu

55 55 LIITTEET Liite 1. Käytettävyystestauksen käytössä olevien menetelmien arviointi

56 56

57 Liite 2. Käytettävyystestauksen käyttö scrum-mallissa, ehdotus 57