Liiketoiminnan edustaja:” Me halutaan tulla sinne teidän testausympäristöön vähän tutkailemaan. Hoidatko mulle ja Tiina-Leenalle oikeudet?” 

Loppukäyttäjä hyväksymistestauksessa: “Mä näen tämän nyt ensimmäistä kertaa. Ei tämä näin voi toimia. Miksi meiltä ei ole kysytty, miten tämä käytännössä tehdään?” 

Kuulostaako tutulta? Hyvin usein liiketoiminnan edustajat tai loppukäyttäjät tulevat mukaan kovin myöhäisessä vaiheessa, huolimatta valitusta kehitysmallista. Liiketoiminnan edustaja voi olla sisäisissä kehityshankkeissa myös loppukäyttäjän roolissa. Haasteet voivat olla myös samoja niin sisäisissä kehityshankkeissa, kuin ulkoisille asiakkaille suunnatuissa palveluissa.

Miksi näin käy? Syitä voi olla monia. Projektin aikataulu voi olla lähtökohtaisesti liian kunnianhimoinen, jolloin loppukäyttäjien hyödyntämisen lisääminen tähän yhtälöön on haastavaa. Voi olla myös, ettei oikein tiedetä, miten asiantuntijoiden osallistaminen kannattaisi järkevimmin hoitaa.

Tai: “Ei loppukäyttäjiä ennenkään ole kuunneltu, miksi siis aloittaa nytkään?” Haasteita voi olla myös resursoinnissa, osaamisessa tai yhteistyömalleissa. Ketterissä malleissa tuoteomistajan tulisi huolehtia siitä, että liiketoiminnan edustajat ovat mukana kehitysprojektin koko matkan aikana ja että heillä on tähän myös ajankäytöllinen mahdollisuus.

Liiketoiminnan edustajien ja loppukäyttäjien mukaan ottaminen esimerkiksi testausvaiheisiin vaatii usein testauskäytäntöjen perehdyttämistä. Esteenä voivat olla myös puutteelliset tai siiloutuneet yhteistyömallit ja -rakenteet IT:n ja liiketoiminnan välillä.

Huonoja käyttäjäkokemuksia on vaikea muuttaa jälkeenpäin

Yllä mainitut syyt voivat kostautua myöhemmin. Loppukäyttäjien ottaminen mukaan vasta palvelun, tuotteen tai järjestelmän hyväksymistestauksessa – tai pahimmassa tapauksessa vasta tuotannossa – voi aiheuttaa suuren määrän käytettävyyteen tai liiketoimintaprosesseihin liittyviä havaintoja ja virheitä. Mitä myöhemmin nämä havainnot ja virheet tulevat esille, sitä kalliimpaa ja hankalampaa niiden korjaaminen on. Huonoja kokemuksia ja mielleyhtymiä on myös vaikea muuttaa jälkeenpäin. 

Loppukäyttäjillä, jotka voivat olla sisäisiä tai ulkoisia, on näkemyksiä ja tietoa tuotteesta, palvelusta ja liiketoimintaprosesseista, mitä tietojärjestelmän kehittäjillä ei useimmiten ole. He ovat myös niitä, jotka tulevat lopputuotosta oikeasti käyttämään. Miksi ei siis tehtäisi siitä sellaista, joka heidän työtään parhaiten palvelisi? Loppukäyttäjiltä on mahdollista saada arvokasta tietoa ja kommentteja, joita kannattaa hyödyntää mahdollisimman aikaisin.

Mitä keinoja on saada loppukäyttäjien näkemyksiä siitä, ollaanko tietojärjestelmän kehityksessä menossa oikeaan suuntaan?

Alla muutamia keinoja, joilla on mahdollista osallistaa liiketoiminnan edustajia ja loppukäyttäjiä kehitysprojektin aikana. Sisäisissä kehityshankkeissa näkökulma ja painopisteet voivat olla erilaisia kuin ulkoisille asiakkaille suunnatuissa palveluissa. Erilaisia keinoja tulee soveltaa tarkoitukseen ja tavoitteisiin parhaiten sopivalla tavalla.

• Otetaan liiketoiminnan edustajat ja loppukäyttäjät mukaan jo suunnittelu- ja määrittelyvaiheessa katselmointeihin, pöytätestauksiin ja asiakashaastatteluihin. Käyttöliittymistä voidaan tehdä suunnitteluvaiheessa protoversioita, joita demotaan liiketoiminnan edustajille ja/tai loppukäyttäjille.   
• Demotaan usein ja myös keskeneräistä kehitystä. Pidetään kiinni siitä, että vähintään sprinttien päättyessä on aina demottavaa. Tällöin saadaan varmistus kehityksen oikeasta suunnasta ja saadaan nopeaa palautetta. Kun demo on sprintin tavoitteena, se ohjaa myös kehityksen tekemistä eri tavalla.  
• Annetaan mahdollisuus osallistua testaukseen myös alemmissa testausympäristöissä, ei pelkästään hyväksymistestaukseen. Vaikka demot ja määrittelyjen katselmoinnit auttavat, on helpompi ottaa kantaa toiminnallisuuksiin, kun ne näkee ja kokee käytännössä. 
•  On huomioitava kuitenkin, että tämän tulee olla hallittua ja suunniteltua. Koordinoinnin puute voi lisätä muun testauksen riskejä, jotka voivat realisoitua esimerkiksi testiaineiston käytettävyydessä/rikkoutumisessa tai ohjausmallien puutteista johtuvissa kysymysten ja tukitarpeiden määrässä. Jotta testaajien määrä pysyy hallittuna, voidaan testaajiksi valita esim. key user -roolin omaavia loppukäyttäjiä. 
• Tehdään tarpeen mukaan myös erillinen käytettävyystestaus, tämäkin mahdollisimman aikaisessa vaiheessa. Loppukäyttäjät osallistetaan käytettävyystestaukseen. Tätäkin testauksen osa-aluetta voidaan tehdä myös vaiheittain ja pienissä paloissa.  
• Pilotoidaan tuotantoversiota pienemmällä joukolla loppukäyttäjiä. Tällöin saadaan aidot palautteet tuotantoympäristössä pieneltä osajoukolta ennen julkaisua kaikille loppukäyttäjille. Pilotointivaihe sekä sen palauteisiin reagointi tulee huomioida projektin kokonaisaikataulussa

Palaute projektin aikaisessa vaiheessa edellyttää keskeneräisyyden sietoa

Kaikissa näissä keinoissa tavoitteena on palautteen saaminen ja niihin reagointi. Mitä aikaisemmassa vaiheessa liiketoiminnan ja loppukäyttäjien palautteet saadaan, sen parempi. Tämä vaatii keskeneräisyyden sietoa, hyväksymistä ja ymmärtämistä sekä oikeiden odotusarvojen luomista ja näihin vastaamista. 

Palautteen antaminen ja siihen reagointi vaatii avointa, sujuvaa ja suunnitelmallista yhteistyötä kaikkien sidosryhmien välillä. Hyvä yhteistyö ja positiivinen ilmapiiri edesauttavat laadukkaan lopputuloksen saavuttamista. Ei kannata unohtaa myöskään ensivaikutelman merkitystä muutosjohtamisen näkökulmasta.

Tarja Kunnasvuo

Testauspäällikkö, Reflector Oy

www.reflector.fi

Tarja on ISTQB-sertifioitu testauksen ammattilainen, joka pitää testauksen langat käsissä yli kymmenen vuoden kokemuksella. Tarjalla on monipuolista osaamista testaukseen, testauksen koordinointiin sekä testauksen toimintatapojen kehittämiseen liittyen.