Kukaan ei halua käyttää softaasi

Kipeä totuus, jota joidenkin ohjelmistotaloissa työskentelevien tuntuu olevan vaikea ymmärtää, on että kukaan ei oikeasti halua käyttää sitä softaa jota teemme.

Jos mielesi tekee nyt väittää vastaan, mietipä hetki, miksi some- ja pelimaailmassa käytetään niin paljon keinoja, jotka luovat käyttäjille addiktioita. Ne tarjoavat käyttäjilleen mukavaa ajanvietettä, mutta joutuvat silti itse luomaan käyttäjille tarpeen palata.

Käyttäjän tarpeet ovatkin keskeinen syy siihen, miksi ohjelmistoja käytetään. Jos ohjelmiston avulla pystyy tekemään työnsä nopeammin, helpommin ja laadukkaammin kuin ilman, todennäköisesti ihmiset käyttävät tuota ohjelmistoa työssään, jos siihen vain on mahdollisuus.

Se ei kuitenkaan tarkoita, että he haluaisivat käyttää sitä ohjelmistoa. Ei, he haluavat saada työnsä vaivattomasti tehtyä.

Miksikö tämä on oleellista ymmärtää?

Siinä missä rakentamamme softa on meille itsellemme koko elämä, asiakkaillemme se on vain pieni osa heidän työtään, yksi työkalu muiden joukossa. Meidän täytyy ymmärtää sitä ympäristöä, jossa tuotetta käytetään, jotta voisimme ymmärtää, millainen tuote palvelisi asiakkaitamme parhaiten. Testaaja, joka ei ymmärrä todellisten käyttäjien toimintaympäristön haasteita, saattaa hyvinkin priorisoida aivan vääriä asioita tehdessään valintoja, mitä osa-alueita tarkastella kriittisesti ja mitä havaintoja raportoida.

Lahja, joka maksoi asiakkuuden

Yleinen vitsi on, että testaajan käsittelyssä kaikki vain hajoaa. Näin näyttää käyvän silloinkin, kun testaukseen käytettävä rajapinta on yrityksen asiakaspalvelu.


Minulla on täti, joka on jo vuosia kantanut huolta siitä, että meille ei kanneta aamuisin lehteä. Olen koittanut rauhoitella häntä kertomalla, että luemme kyllä uutiset netistä, mutta tämä on sen verran kaukana hänen kokemusmaailmastaan että viestiä on ollut vaikea saada perille.

Viime keväänä hän soitti minulle ja kertoi tilanneensa minulle ystävänpäivätarjouksena viikonlopun lehdet kotiin kannettuna. Innoissaan hän selitti, että siihen pakettiin kuuluvat myös tunnukset digilehteen, niin voin lukea arkilehdet sieltä netistä.

Muuten hyvä, mutta en oikeastaan halunnut lisää keräyspaperia ulos kannettavaksi, ja itse asiassa minulla oli jo tilaus ko. lehden digilehdestä. Jäin vain pohtimaan, voisiko mediatalolla olla riittävän fiksut tietojärjestelmät, että oman tilaukseni laskutuskautta muutettaisiin automaattisesti niin, että minun ei tarvitsisi maksaa digilehdestäni samaan aikaan kun tätini maksaa minulle sitä.

1) Sopimuksen sisältöä voi muuttaa kertomatta tilaajalle

Kun sitten sain lehdeltä kortin, jossa kerrottiin lahjatilauksestani, selvisi, että he aikoivat kantaa lehdet edelliseen osoitteeseeni. Tämä johtui siitä, että heillä oli entuudestaan olemassa osoitetietoni, koska vielä muutamia vuosia sitten meille tuli lehti kotiin kannettuna. Olin muuttanut hiljattain, ja koska luin vain digilehteä ja sain laskuni sähköisesti, olin unohtanut ilmoittaa osoitteenmuutoksesta. Tätini oli kyllä tilaukseen ilmoittanut uuden osoitteeni, mutta tällä ei ollut merkitystä, koska tätini ei voi muuttaa minun asiakastietojani.

Ymmärrän hyvin, että tätini ei voi muuttaa asiakasjärjestelmän tietoja, jotka koskevat omia tilauksiani. Olen kuitenkin aika hämmästynyt, jos lehti, jonka voi kesälomalla kääntää mökille, ei ole osannut rakentaa asiakastietojärjestelmäänsä tavalla, joka mahdollistaisi sen että lahjatilaukseni kannetaan eri osoitteeseen kuin minkä olen itse heille joskus muinoin ilmoittanut. Voihan myös lahjatilaus kohdistua vaikka loma-asuntoon tai putkiremonttievakon aikaiseen asuntoon.

Tai osoiteristiriidan huomatessaan he olisivat ehkä voineet soittaa minulle. Tekee lahjan saamisesta melko monimutkaista, että lahjan saajan on itse otettava yhteyttä asiakaspalveluun selvittääkseen osoiteasiansa.

Sitäpaitsi, mistä he tiesivät yhdistää tilauksen minun asiakastietoihini?

2) Voit laskuttaa tuotteesta "kahvi ja pulla" vaikka asiakas saisi vain pullan

Koska minulla ei ollut erityistä halua saada paperilehtiä, ja päivissäni on ihan riittävästi tekemistä ilmankin että joudun selvittelemään, mitä kautta ko. lehti suvaitsee ottaa vastaan asiakkaidensa yhteydenottoja, en heti tehnyt mitään asialle. Mutta kun sitten oman tilaukseni laskutuskausi päättyi kesken lahjatilauskauden, ja sain laskun seuraavasta laskutuskaudesta joka alkaisi kesken lahjatilauksen, ajattelin että en kyllä lähde maksamaan uutta laskua palvelusta jonka saan jo lahjana. Niinpä soitin asiakaspalveluun.

Asiakaspalvelussa minulle ystävällisesti kerrottiin, että todellakin, koska viikonloppulehdet+digilehti on eri tuote kuin digilehti, niistä voidaan tehdä päällekkäiset tilaukset. Uuden laskun hyvittäminen onnistui kuitenkin helposti, joten en viitsinyt ruveta kyselemään, mahtaisiko ko. lehtitalon kahviossa olla ok. toimintatapa myydä tarjouksella tuotetta "kahvi ja pulla", antaen pelkkä pulla niille joiden kahvimuki sattuu tarjoushetkellä olemaan täynnä. Veikkaan että tällaisessa tilanteessa moni kahvion pitäjä lupaisi ihan oma-aloitteisesti että santsikupin saa hakea ilmaiseksi, mutta lehtitilauksissa tällainen järjestely vaatii siis sitä että asiakas itse ottaa yhteyttä asiakaspalveluun. Entä miten olisi mahdettu menetellä tilanteessa, jossa oma tilaukseni olisi sisältänyt digilehden lisäksi kaikki paperilehdet? Tuote olisi silloinkin ollut eri kuin digi+viikonlopun lehdet, olisinko silloin hyötynyt lahjasta muuta kuin kortin, jolla minulle ilmoitettiin lahjan saamisesta?

Kerroin myös uuden osoitteeni, mutta sanoin että en oikeastaan halua sitä paperilehteä, vaan nauttisin ihan mielelläni vain siitä digilehti-osuudesta saamaani lahjaa. Ja esitin myös vienon toiveen, että oma jatkuva tilaukseni laitettaisiin jatkumaan automaattisesti lahjatilauksen päättymisen jälkeen, ettei minun itseni tarvitsisi ottaa heihin enää yhteyttä saadakseni digitilaukseni jatkumaan. Asiakaspalvelijan äänensävy saattoi tässä kohtaa muuttua hieman epävarmemmaksi, mutta mikään ei viitannut siihen että tämä ei onnistuisi.

3) Toisen henkilön puolesta voi tehdä sopimuksen puhelimitse

Muutama viikko sitten tätini soitti ja kysyi, mitä me oikein sovimme siitä minun lehtitilauksestani. Ilmeni, että noheva asakaspalvelija oli tehnyt digilehdestäni puolen vuoden jaksoissa laskutettavan jatkuvan tilauksen, joka laskutettiin tädiltäni. Tätini oli siis lahjatilaukseni jälkeen maksanut jo yhden laskun puolestani, mutta nyt toisen laskun saatuaan hän alkoi ihmetellä asiaa.

Tätini oli asiasta soittanut lehden asiakaspalveluun, jossa oli kerrottu että lasku tuli koska hänellä on tällainen tilaus. Alkava tilausjakso toki voitaisiin perua, mutta koska tädilläni oli käytössä suoramaksusopimus, lehti ei voisi estää laskun maksua, vaan tätini pitäisi pyytää pankkiaan poistamaan maksu.

Tätini oli ollut käsityksessä, että hänen laskutussopimuksensa toimisi niin, että laskun saatuaan hän voisi tarvittaessa ottaa yhteyttä lehden asiakaspalveluun laskun muuttamiseksi. Hän oli aika tuohtunut kun asiakaspalvelu ei suostunutkaan perumaan hänen laskuaan, ja pyysi minua hoitamaan asian siellä internetissä, kun puhelimitse ei näemmä enää palvelua saa. Hänellä itsellään ei ole tietokonetta tai kännykkää, joten pankkiasioiden hoitaminen kätevästi netissä ei ole hänelle kovin kätevää.

3) Toisen henkilön puolesta voi perua tilauksen, mutta ei sopia rahojen palauttamisesta

En heti ehtinyt tehdä mitään asialle, mutta muutamaa päivää myöhemmin otin yhteyttä asiakaspalveluun, kerroin mielipiteeni tästä palvelukokemuksesta, ja pyysin vaihtamaan tilaukseni taas minulta laskutettavaksi. Asiakaspalvelusta kerrattiin, mitä heidän näkökulmastaan oli tapahtunut, ja ilmoitettiin, että tätini lasku oli nyt mitätöity ja minulle oli luotu uusi tilaus 3kk laskutusjaksolla. Tätini olisi kuitenkin itse oltava heihin yhteydessä ylimääräisen maksun palauttamiseksi.

Soitin tädilleni, joka ei ilahtunut uutisista. Hän oli tahollaan tullut siihen tulokseen, että hänelle olisi helpointa vain maksaa saamansa lasku. Niinpä hän kuulemma oli ilmoittanut lehdelle, että hän lopettaa kyseisen tilauksen tämän laskun jälkeen, siis puolen vuoden päähän, ja siinä vaiheessa minun olisi itse tilattava lehti uudelleen itselleni. Hän ei enää halunnut olla asian tiimoilta yhteydessä sen kummemmin lehteen kuin pankkiinkaan.

Siispä otin uudestaan yhteyttä asiakaspalveluun. Pyysin, että he joko hyvittäisivät tätini maksaman laskun hänen oman lehtitilauksensa seuraavasta maksusta, tai vaihtoehtoisesti poistaisivat minun laskuni, jotta voisin lukea lehteä tätini laskuun seuraavat puoli vuotta sen sijaan että molemmat maksamme samasta palvelusta yhtä aikaa.

Ensimmäinen vaihtoehto ei kuulemma ollut mahdollinen. Minulla oli siis lehden käytäntöjen mukaan oikeus tehdä tätini puolesta sopimus oman lehteni tilauksesta hänen laskuunsa, sekä oikeus päättää hänen puolestaan tuo tilaus ja mitätöidä siihen liittyvä lasku, mutta "toisen henkilön laskutusta ei voida käsitellä", ja siksi minun pyynnöstäni ei ollut mahdollista hoitaa maksun hyvittämistä. Luonnollisesti asiakaspalvelusta ei myöskään ehdotettu vaihtoehtoa, että he itse olisivat tätiini yhteydessä asian tiimoilta, vaan minun tulisi houkutella hänet soittamaan heille.

Pian keskustelu asiakaspalvelun kanssa alkoi käydä hyvinkin mielenkiintoiseksi.

4) Jos laskuihin tehdään muutoksia, laskutustiedot voi sotkea ja siirtää vastuun asiakkaalle

Asiakaspalvelu ilmoitti, että tädiltäni veloitettua laskua ei itse asiassa ollut olemassa. Tilaus oli peruttu ja lasku mitätöity. Asiakkaalla ei ollut avoimia laskuja eikä hänen tiedoissaan näkynyt ylimääräisiä suorituksia.

Jotta asiassa päästäisiin eteenpäin, ilmoitin ko. laskun numeron ja viitenumeron siinä toivossa, että näiden tietojen perusteella maksu löytyisi, suoramaksu oli kuitenkin laskun tietojen mukaan lähtenyt tätini tililtä jo muutamia päiviä aikasemmin. Asiakaspalvelun mukaan kuitenkin kyse oli hyvityslaskusta, joka mitätöi aikaisemmin avoinna olleen laskun, eikä maksua asiakkuudelle ollut tullut. Maksutapahtuman tietoja vastaan raha voitaisiin kuitenkin etsiä ja palauttaa. Siispä otin valokuvan tätini saamasta suoramaksuilmoituksesta ja lähetin sen asiakaspalveluun, siinä kuitenkin näkyi maksusta kaikki se tieto, mitä laskusta oli saatavilla ottamatta yhteyttä tätini pankkiin tai odottelematta tiliotetta.

Tämä ei kuitenkaan asiakaspalvelulle kelvannut. Heidän mukaansa tätini pitäisi toimittaa heille kaikki maksun tiedot, siis asiakasnumero, tilinhaltijan nimi, maksupäivä, maksettu summa, arkistointitunnus, tilinumero jolle maksu on maksettu, käytetty viitenumero sekä maksukanava. Arkistointitunnusta lukuunottamatta kaikki tämä tieto toki olisi löytynyt heille toimittamastani kuvasta, mutta koska ilman pankin arkistointitunnusta se ei ollut "riittävä todiste" laskun maksamisesta, kaikki nuo tiedot pitäisi erikseen ilmoittaa heille, jotta he voisivat pyytää laskutuspuolta etsimään kadonneet rahat.

Tässä vaiheessa irtisanoin tilaukseni.

Tämän pyynnön asiakaspalvelu ystävällisesti toteuttikin. Sain ilmoituksen, että tilaukseni on irtisanottu päättymään maksetun tilausjakson loppuun 13.1.2018.

Jännittävää tässä on se, että en koskaan ehtinyt maksaa saamaani laskua, jonka tilausjakso loppuu 13.1.2018. Ainoa reitti, jota pitkin raha oli voinut tilaustietoihini tulla, on tätini mitätöity lasku, jolla hän maksoi tilaukseni 13.4.2018 asti.

5) Asiakasta saa hyppyyttää vapaasti

On kovin vaikeaa ymmärtää, miksi yritys haluaa markkinoida lahjatuotteita, joita se ei osaa toimittaa lahjan saajalle ilman että tämän on nähtävä näin paljon vaivaa asian eteen. On todella vaikeaa ymmärtää, miksi tieto laskutukseen liittyvästä ongelmasta ei riitä siihen, että asiakaspalvelusta oltaisiin suoraan yhteydessä siihen henkilöön, jolta he tarvitsevat tietoa ongelman selvittämiseen. Tuntuu täysin käsittämättömältä, että suoramaksuun liittyvien tietojen yksilöiminen ei riitä siihen että ko. maksusuoritusta voitaisiin yrittää etsiä. Miksi laskuissa on viitenumerot, ja laskun numerot, jos nämä yksilöintitiedot eivät riitä maksujen löytämiseen?

Eläissäni en ole saanut toista lahjaa, josta olisi koitunut minulle yhtä paljon vaivaa ja harmia. En muista törmänneeni toiseen yritykseen, jossa yhtä yksiselitteisesti olisi siirretty vastuu ongelmatilanteiden selvittämisestä asiakkaalle. Minun mielipahaani pahoiteltiin vasta, kun pyysin irtisanomaan tilaukseni.

6) Virheitä ei tarvitse myöntää

Teen töitä softan parissa ja osallistun myös asiakastuen pyörittämiseen. Ymmärrän, että inhimillisiä virheitä sattuu, että tietojärjestelmät voivat joskus toimia väärin, ja että välillä viesteihin vastaavat ihmiset eivät ole tarpeeksi perehtyneitä käsillä olevaan ongelmaan ostakseen olla asiakkaalle avuksi.

Se mitä en ymmärrä, on että kun asiakas esittää kysymyksen liittyen ongelmaan ko. firman prosesseissa, asia ohitetaan tai väitetään ettei mitään ongelmaa ole. En ymmärrä sitä että asiakkaalle lähdetään inttämään vastaan. Ainoa asia, jossa lehden puolelta myönnettiin heidän tehneen virheen, oli asiakaspalvelun tulkinta että laskuni olisi ollut maksettu.

Kaikenkaikkiaan tästä palvelukokemuksesta jäi kovin samanlainen maku kuin joskus 90-luvulla sukulaisten kertoessa lehtimyyjistä, jotka soittelivat eläkeläisille ja tekivät erilaisia lahjatilauksia lapsenlapsille ja serkun kummin kaimoille riippumatta siitä, halusiko asiakas ostaa lehden vai ei. Mutta ne lehdet kai sentään kannettiin perille ilman että lahjan saajan tarvitsi lähteä selvittelemään asiaa asiakaspalvelun kanssa.


Ehkä kontrasti vain on liian suuri verrattuna omaan työhöni, jossa keskeistä on miettiä, miten asiat saataisiin sujumaan asiakkaan näkökulmasta helposti ja sujuvasti? Asiakaskokemus on kuitenkin paljon muutakin kuin käytettävän softan toiminta, tätä meidän ohjelmistoinsinöörien on joskus vaikea muistaa.



----------
Edit: Tätini soitti ja kertoi, että hänen tiliotteensa mukaan laskua ei ollutkaan veloitettu. Lehden asiakaspalvelusta oli väitetty sekä hänelle että minulle, ettei maksua voinut lehden päässä perua, mutta ilmeisesti se sitten kuitenkin laskun mitätöinnillä peruuntui. Mukavaa, että asiakaspalvelussa ollaan näin hyvin kärryillä asioista, joissa heidän pitäisi asiakkaita palvella.

Kuka maksaa ja kenen kortilla?

Minulla on ikävä taipumus toivoa softilta ominaisuuksia joita niiden speksaajat eivät ole nähneet tarpeellisiksi toteuttaa. Yksi alue, jolla olen erityisen hämmästynyt valtavasta kuilusta omien toiveitteni ja vakiintuneiden toteutusten välillä liittyy verkkomaksamiseen.

Netissähän on äärimmäisen helppoa maksaa. Ei tarvitse kuin syöttää luottokorttitietonsa lomakkeelle voidakseen tehdä ostoksia mistä päin maailmaa tahansa. Monet palvelut käyttävät vakiintuneita maksamissovelluksia kuten PayPalia, mikä lisää luotettavuuden tunnetta ja helpottaa elämää kun niitä luottokorttitietoja ei tarvitse joka kerta syöttää erikseen. Myös älypuhelinten sovelluskauppoihin voi helposti tallentaa luottokorttitietonsa, minkä jälkeen ostosten tekeminen on äärimmäisen helppoa.

Mikä minua sitten riepoo?

Käyttötapaus 1: Mainosajan ostaminen yhdistykselle

Harrastan yhdistystoimintaa ja siihen liittyen osallistun yhdistyksemme Facebook-sivun ylläpitämiseen. Silloin tällöin meillä on tapahtumia, joita on tarpeen mainostaa, ja tällä hetkellä tähän järkevin kanava on Facebook. Se tarjoaakin helpon työkalun tapahtumien maksulliseen promoamiseen PayPalin avulla.

Se mikä itseäni toteutuksessa korpeaa on, että minun oletetaan yksinkertaisesti syöttävän maksutietoni ja jäävän tyytyväisenä odottelemaan kampanjan etenemistä.

Kun ensimmäisen kerran syötän Facebookiin PayPal-tunnuksiani, minulle ei millään tavalla kerrota, edellytetäänkö minulta myös seuraavalla kerralla kirjautumista PayPal-tunnuksilla (ei edellytetä). Minulle ei myöskään kerrota, liitetäänkö PayPal-tunnukseni henkilökohtaiseen tiliini vai promottavan yhdistyksen tietoihin. Jälkimmäinen vaihtoehto toki tuntuu epätodennäköiseltä, mutta kun kuitenkin suoritan maksua yhdistyksen profiilin kautta, ja tuohon samaan profiiliin on liitetty useita henkilökohtaisia facebook-tunnuksia, minun mieleni olisi aika paljon kevyempi jos minulle ihan eksplisiittisesti kerrottaisiin, että muilla tunnuksilla kirjautuneet eivät pääse tekemään yhdistyksemme nimissä ostoksia minun luottokortillani. Toki voi olla että Facebook ei tiedä vastausta tähän kysymykseen. Joskus vähemmän tärkeät asiat vain toimivat niin kuin ne sattuvat toimimaan kenenkään ottamatta kantaa siihen miten niiden pitäisi toimia.

Sinänsä koen hieman hermostuttavaksi myös sen, että omalta facebook-tililtäni voi koska vaan tehdä PayPal-maksuja kirjautumatta erikseen PayPaliin. Olisi naiivia ajatella, että kukaan muu ei voisi koskaan kirjautua facebookiin minun käyttäjätunnuksellani. Eikä salasanaani edes tarvitse saada selville, jos vie kännykkäni. Yksi suuria pettymyksiäni iPhonen kanssa oli se että puhelimen lukituskoodiin ei saanut kuin neljä merkkiä, mikä tekee sen luvattoman avaamisen ihan mahdolliseksi. Ja jos sen saa auki, pääsee kirjautumatta käsiksi niin sähköposteihini kuin sosiaalisen median tileihini. Toki jos näin käy, facebook-mainosten ostaminen luottokorttitiedoillani on todennäköisesti huolistani vähäisin. Silti, ihan periaatteen vuoksi, nukkuisin yöni paremmin jos jokainen maksutapahtuma luottokortiltani vaatisi erikseen kirjautumisen PayPaliin. Nyt saan tämän toteutumaan vain vaihtamalla PayPal-tilini salasanaa jokaisen facebook-maksun jälkeen. Kuinka käytännöllistä!

Käyttötapaus 2: Lapsen mobiilipelit

Meidänkin talouteemme on saatu erilaisia mobiililaitteita, joihin voi ladata jos jonkinlaista peliä. Monet pelit maksavat vähän rahaa, ja ilmaispeleissäkin pelaaminen usein muuttuu mielekkäämmäksi jos ostaa siihen vähän jotain ihan oikealla rahalla. Tämä on ihan fine, olen oikein tyytyväinen jos lasteni kulutustottumukset muuttuvat aineettomampaan suuntaan, sanotaanko vaikka että taloudessamme on jo ihan riittävä määrä Lego-palikoita.

Se mikä minua riepoo, on taas kerran se, että lasteni käyttämät mobiililaitteet ottavat auliisti vastaan luottokorttitunnukseni, mutta eivät kerro, miten helppo niillä on tehdä uusia ostoksia.

Surfacen sovelluskaupan sain aikanaan toimimaan niin, että lapset kirjautuivat laitteelle omilla tunnuksillaan mutta sovelluskauppa vaati minun tunnukseni, ja tällöin maksamisen yhteydessä vaadittiin aina kirjautumista erikseen. Kännyköihin en ole löytänyt tällaista vaihtoehtoa. Oletusarvoisesti luottokorttitiedot syötetään laitteeseen suoraan, minkä jälkeen lapsi saa omilla tunnuksillaan tehdä ostoksia vapaasti.

Esimerkiksi Momio kertoo rajoittavansa käyttäjien ostoksien euromäärää jättilaskujen ehkäisemiseksi, mutta itse koen että jättilaskut eivät ole se suurin ongelma. Ne huomataan, ja niistä voi saada rahansa takaisin. Sen sijaan pienemmät ostokset voivat jäädä luottokorttilaskulta huomaamatta, ja niistäkin voi ajan mittaan kertyä melkoiset summat. Haluaisin tietää ennen kuin ostan nyt alennuksessa olevan Momio Plussan lapselleni, onko minulla tuon ostoksen jälkeen muuta tapaa estää lastani tekemästä lisää ostoksia luottokortillani kuin pyytää pankkiani mitätöimään korttini ja lähettämään minulle uuden.

Tykkään siitä perinteisestä toimintatavasta, jossa lapsen viikkorahan suuruuden päättävät vanhemmat. Avoin piikki luottokortilleni on aivan tolkuton ajatus. Sitä paitsi eikö toisen henkilön luottokortilla maksaminen ole luvatontakin, saati sitten luottokortin antaminen alaikäiselle? Vai voinko yhtä hyvin antaa lapselleni sirukorttini PIN-koodin ja pyytää häntä käymään itse sen kanssa vaikkapa vaateostoksilla?

Olenko vanhanaikainen?

Maksamiseen liittyen on helppo keksiä muitakin potentiaalisia ongelmia. Itse kuitenkin näen keskeisimpänä sen, miten varmaankin käytettävyyttä kovasti ajatellen tällaiset workflowt tehdään mahdollisimman helpoiksi. Käyttäjää ei häiritä asioilla jotka voisivat saada hänet kyseenalaistamaan, kannattaako luottokorttitietojaan tuupata ihan joka paikkaan. Onko tämä alennus todella sen arvoinen, että jätän taas kerran luottokorttipiikkini jossakin auki?

Ennen aikaan kirjautumistietoihin suhtauduttiin vakavasti, nykyään monilla on niin valtava määrä kirjautumista vaativia järjestelmiä että sitä helposti huokaisee helpotuksesta kun uuteen järjestelmään voikin kirjautua suoraan Google-tilin tai Facebook-tilin avulla, tai tunnukset voi tallentaa selaimen muistiin.

Olisi kuitenkin hyvä, jos järjestelmät aina mahdollistaisivat myös vanhanaikaisen, varovaisen käyttötavan.

En näe kovin vaarallisena, jos joku saa selville tunnukseni vaikkapa verkko-Hesariin tai johonkin nettikauppaan, josta tilaaminen onnistuu vain maksamalla ostokset verkkopankissa. Koen hyvin huolestuttavana, että nuo tunnukseni ovat paremmin suojassa kuin luottokorttitietoni.

Ja tästä syystä olen se natsimutsi jonka lapset jäävät paitsi monesta sellaisesta, joka "kaikilla muilla" kuulemma on.

Mistä laatu tulee?

Testaajan työ on laadunvarmistusta. Joskus vastaan tulee käsitystä, että testaajan mukaan ottaminen takaisi lopputuloksen laadun.

Näin ei kuitenkaan ole. Testaajan tehtävä on laadun mittaaminen ja arviointi, sen parantaminen taas on pohjimmiltaan ihan muiden heiniä.

Laatu ei muutenkaan ole erillinen palikka, jonka voisi lisätä projektiin ihan vain jonkin dokumentin tai yksittäisen henkilön muodossa. Laatu on kaikkien yhteinen asia.

Laadun syntyminen vaatii tarkoituksenmukaista määritystä ja suunnittelua. Nykymaailmassa käytettävyys ja visuaalinen miellyttävyys ovat keskeisessä asemassa laadun kokemisessa, mutta tärkeää on tietenkin myös se että tuote vastaa toiminnallisuuksiltaan käyttäjien tarpeilta.

Laadun tuottamista helpottaa mahdollisuus seurata tarkoituksenmukaista prosessimallia, hyödyntäen sen tarjoamia työvälineitä.

Testausosaamisesta on apua laadun tuottamisessa niin järjestelmän määrittelijöille, suunnittelijoille kuin toteuttajille. Oma etunsa on kuitenkin myös siitä, että testaajalla ei ole vastuuta minkään näiden osa-alueiden tekemisestä. Näin siksi, että ihminen on sokea omille virheilleen, eikä testausosaaminen itsessään suojele ihmistä erehdyksiltä. Sen sijaan testausosaaminen antaa välineitä sen arviointiin, antaako määritys riittävät tiedot ohjelmiston toteuttamiseen tai vastaako toteutus määritystä.

Keskeisimpään kysymykseen, eli vastaako järjestelmä asiakkaan tarpeita, testaus voi vastata vain silloin kun asiakas itse testaa. Toimittajan testaajalla harvoin on mahdollisuutta verrata määritystä asiakkaan tarpeisiin, koska hän ei osallistu määrityksen tekemiseen eikä siksi pääse käsiksi tietoon joka voisi osoittaa määrityksen puutteet tarpeisiin nähden.

Erityisesti isojen asiakasorganisaatioiden kanssa työskennellessä ongelma on myös se, ettei asiakkaankaan projektiryhmällä välttämättä ole riittävää tietoa kaikkien tulevien käyttäjien tarpeista.

Lisäksi järjestelmän määrittäminen on helposti liian abstraktia henkilölle, joka ei ole määritysammattilainen. Todelliset tarpeet saattavat tulla tästä syystä esiin vasta testausvaiheessa.

Tämä nostaa haasteeksi sellaisten työvälineiden ja työskentelytapojen löytämisen, jotka konkretisoivat, mistä projektissa on kysymys.

Erilaiset demoympäristöt tai vaikka paperille hahmoteltu käyttöliittymä jota saa ihan itse "klikata" voivat auttaa konkretian luomisessa. Ketterät menetelmät taas antavat mahdollisuuden tarkentaa määrittelyä sitä mukaa kuin asiat konkretisoituvat.

Joskus voi olla myös tarpeen opettaa asiakasta testaamaan, tai esimerkiksi kysyä, pääsevätkö kaikkien tulevien käyttäjäryhmien edustajat arvioimaan määrityksen onnistumista.

Miten testaus voi auttaa asiakastyytyväisyyden parantamisessa

Asiakastyytyväisyys on hankala suure. Sen mittaaminen on usein hieman epämääräistä, ja siihen vaikuttavien asioiden perusteellinen analysointi kenties vieläkin haasteellisempaa.

Asiakkaalle ihanteellista olisi saada hyvää halvalla nopeasti, vieläpä hyvällä palvelulla ryyditettynä. Mutta asiakkaan etu on myös se, että yhteistyökumppanien toiminta on kannattavaa, koska nappiin mennyt toteutusprojekti ei kauheasti lämmitä, jos ylläpidosta huolehtiva organisaatio katoaa.

Laadun tekeminen halvalla kannattavasti on haasteellista. Tämä pätee niin huonekaluostoksilla, ravintolassa kuin ohjelmistokehityksessäkin. Näiden tekijöiden optimointi asiakkaan parhaaksi - laatu, hinta, aikataulu, palvelutaso ja kannattavuus - ei ole ihan yksinkertaista. 

Testaus (hyvin hoidettuna) on yksi tapa vaikuttaa positiivisesti näihin kaikkiin.

Laatu

Testauksen vaikutus laatuun on kenties helpointa nähdä, puhutaanhan testaamisesta usein laadunvarmistuksena. Testaus ei kuitenkaan itse tuota laatua, vaan ennemminkin mittaa sitä, antaen laadun tekijöille eli järjestelmän määrittelijöille, suunnittelijoille ja toteuttajille informaatiota, jonka avulla lopputuloksesta voi tulla laadukas.

Järjestelmän käyttöönoton kannalta ohjelmiston laatu on usein keskeisempi asia kuin toteutusprojektiin liittyvät kommellukset, ja siksi laadunvarmistus on keskeinen tekijä asiakastyytyväisyydessä.

Muissa asioissa arkiajattelussa testauksen rooli ei ehkä ole yhtä ilmeinen.

Hinta

Testaus nähdään usein asiana, joka kasvattaa hintalappua. Näin asia onkin, jos testausta ei tehdä oikein, sillä kaikkien bugien kaivaminen esiin monimutkaisesta ohjelmistosta on ikuisuusprojekti. Päämäärätön ohjelmiston läpikliksuttelu ei myöskään välttämättä löydä oleellisimpia virheitä, vaikka aikaa siihen saa kulumaan ihan niin paljon kuin aikaa käytettävissä on.

Ammattitaitoisesti suunniteltu testaus ei kuitenkaan välttämättä kasvata kokonaishintaa verrattuna tilanteeseen jossa vain ollaan testaavinaan, vaan voi toimia jopa päinvastoin.

Testaajan osallistuminen jo määritysvaiheeseen dokumenttien katselmoinneilla sekä alustavien testitapauksien luominen ennen ohjelmiston toteutusta voi tehostaa muiden projektiin osallistuvien työskentelyä ja ehkäistä virheitä, vähentäen kokonaistyömäärää. Testaajan ammattitaitoa on myös mm. testitapauksien priorisointi, eli sen arviointi miten perusteellisesti mitäkin kannattaa tehdä, ja tätä kautta pystytään yhtä aikaa minimoimaan testaukseen kuluvaa aikaa ja maksimoimaan testauksen kykyä löytää merkittävät virheet.

Aikataulu

Toinen testauksen perusongelma on se, että siihen ei jää aikaa kun toteutus venyy.

Todellisuudessa asiantunteva testaaminen ei kuitenkaan viivästä projektia, koska järjestelmän käyttökelpoisuus ei riipu siitä, miten paljon testaajat ovat löytäneet bugeja, vaan siitä, miten paljon niitä oikeasti on. Testauksesta nipistäminen aikataulun nimissä johtaa helposti tilanteeseen, jossa stabilointivaihe venyy ja kuormittaa niin projektipäällikköä kuin kehittäjiä kohtuuttomasti, koska aikaa kuluu paljon asiakkaan löytämien bugien perkaamiseen, selittelemiseen ja hyvittelemiseen. Sen sijaan asiantuntevan sisäisen testauksen avulla on mahdollista siirtää projektin aikataulua hallitusti, kun ammattitestaaja pystyy auttamaan järjestelmän valmiusasteen ja stabilointivaiheen vaatiman aikataulun arvioinnissa.

Palvelu

Testauksen tuki aikataulun arvioimiseen, sekä tarvittaessa käyttöohjeiden luomiseen ja asiakkaan hyväksymistestauksen ja käyttönoton tukemiseen paitsi helpottaa projektipäällikön työtä, voi myös parantaa asiakkaan kokemusta saamansa palvelun laadusta. Näin jo siksikin, että testaajan avulla projektipäällikön on helpompaa keskittyä olennaiseen. Lisäksi testaajan tuominen asiakasrajapintaan voi parantaa asiakkaan kokemusta siitä, että hänen kokemansa haasteet ohjelmiston käyttöönotossa otetaan vakavasti.

Kannattavuus

Mitä toiminnan kannattavuuteen tulee, yksi näkökulma on tuotantokäytössä löytyvien bugien määrä ja laatu. Asiakkaan tai hänen asiakkaansa löytämän bugin korjaaminen on paljon kalliimpaa kuin bugin korjaaminen toimittajan itse tekemän stabiloinnin aikana. Ongelman selvittelyyn osallistuu silloin vähemmän osapuolia, kehittäjät ovat orientoituneet kyseiseen projektiin kun tekevät sitä muutenkin, ja lisäksi bugiraportti tarjoaa tyypillisesti paljon paremmat eväät ongelman syyn löytymiseen.

Tuotantokäytössä löytyviä virheitä ei välttämättä tarkastella yrityksen kustannuslaskennassa projektien kannattavuuden näkökulmasta, koska itse toteutusprojekti on ehtinyt jo päättyä. Yrityksen kannattavuuteen ja mahdollisuuksiin jakaa työ tekijöilleen tehokkaasti ne kuitenkin vaikuttavat. Merkittävien tuotantokäytössä löytyvien bugien pr-arvo on myös korkea, ja osa asiakkaista osaa myös vaatia ylläpitosopimuksia, joissa ongelmatilanteisiin liittyy sanktioita.

Muutoshallintaa v-käyrällä

Projektipäällikkö raahusti hiuksiaan haroen ja raskaasti huokaillen testaajan työpisteelle.

"Istuhan alas", testaaja kehotti. "Mitäs meidän projektille kuuluu? Stabilointivaiheen piti muistaakseni alkaa pari viikkoa sitten, joko nyt vihdoin alkaisi olla jotain testattavaa?"

Projektipäällikkö huokaisi taas syvään.

"Ei ole vielä tarpeeksi valmista," hän vastasi. "Ja itse asiassa nyt on sellainen tilanne, että pitäisi keskustella testauksen määrästä."

"Niin, arvioin silloin projektin alkaessa, että riittävä testaus voisi onnistua kolmen viikon työllä. Se todettiin jo silloin hieman optimistiseksi arvioksi, mutta haluttiin minimoida kustanuksia. Projektin ongelmat tietysti indikoivat, että se ei välttämättä riitä."

Projektipäällikön ilme muuttui entistä tuskaisemmaksi.

"Mutta kun projektin aikataulu ei jousta! Etkö voisi testata vähän nopeammin?"

"No tietysti voidaan vielä priorisoida testitapauksia ja karsia pikkuisen eri päätelaitteilla ja selaimilla tehtävää testausta, mutta se tietysti kasvattaa riskejä. Varmaan kahdessa ja puolessa viikossa saisi jo kohtuullisen käsityksen riskitasosta, vaikka laadun takaaminen voikin olla mahdotonta. Ja aikatauluhan riippuu pitkälti myös siitä, miten nopeasti korjaukset etenevät."

"Minä ajattelin ennemminkin, että jos kuitenkin vaan ottaisit pari päivää ja kliksuttelisit sen läpi? Ei mentäisi niin virallisesti."

"Oletko tosissasi? Meillä on testattavana kymmenkunta prosessikulkua variaatioineen viidellä eri selaimella, tabletilla ja älypuhelimella. Jo siihen kolmen viikon työmäärään liittyy tietyn riskitason hyväksyminen. Ja miten se aikataulu nyt voi olla noin tiukka, kun testaussuunnitelmaa tehtäessä sen kolmen viikon työn jakaminen kuuden viikon jaksolle ei ollut mikään ongelma? Nyt ollaan vasta kaksi viikkoa myöhässä, tai kohta siis kolme viikkoa. Eikö sitä testausaikaa pitäisi olla vielä kolme viikkoa jäljellä?"

"Unohdin kertoa sinulle, että koulutuksia piti aikaistaa kahdella viikolla. Eräillä avainhenkilöillä osui lomat siihen hankalasti, ja sitten oli seminaarimatkoja. Pitäisi saada valmista sitä ennen."

Testaaja veti syvään henkeä ja nojautui tuolissaan taaksepäin.

"Yritätkö siis sanoa, että softa ei ole vielä tarpeeksi valmis testattavaksi, mutta ensimmäiset koulutukset ovat jo kahden viikon kuluttua?"

"Niin."

Hetken aikaa kuului vain ilmastoinnin vaimea humina.

"No, periaatteessa tilanne saattaa olla pelastettavissa, jos voin valjastaa koko testaustiimin työhön, ja pääsemme aloittamaan vielä tällä viikolla. Täytyyhän siellä joku kokonaisuus kohta olla testattavissa, ette kai te kaikkea ole tehneet yhtä aikaa."

Projektipäällikkö vinkaisi hiljaa, muttei sanonut mitään.

"Mutta korjausten pitäisi sitten edetä tosi nopeasti, tai muuten me vain dokumentoimme syyt, joihin koulutus tulee kaatumaan. Ja tietysti sen pitää olla hyvin koodattu, että se saadaan käytännössä yhdellä korjauskierroksella kuntoon. Aika ei mitenkään riitä nyt bugi-pingikseen."

"Ei onnistu, budjetti ei anna myöten."

"Miten niin ei anna myöten? Piti olla mahdollisuus käyttää testaamiseen kolme viikkoa työaikaa."

"Mutta tässä on nyt ollut vähän kaikenlaista, on tullut yllättäviä kustannuksia. Muista projekteista aiheutuvien resursointiongelmien vuoksi tätä on nyt tehty aika takapainotteisesti, ja siksi projektiin piti ottaa mukaan odotettua suurempi joukko kehittäjiä. Osa on ollut vähän kokemattomia, työ on edennyt hitaasti ja ovat tarvinneet suunniteltua enemmän ohjausta. Hommia on myös jouduttu vaihtamaan tekijältä toiselle, kun on pitänyt priorisoida työskentelyä eri projektien välillä. Yksi päivä meni hukkaan, kun integraatioympäristö asennettiin ensin väärin. Pari päivää meni kun piti kaivaa yhden sairaslomalle jääneen kehittäjän koneelta, mitä hän oli ehtinyt tehdä. Ja sitten yksi kone hajosi, eikä ollut varmuuskopiota. Ja..."

"Eli kun koodarit säätävät, testaus maksaa?"

"Maksaa ja maksaa, asiakashan se tästä maksaa. Tai meidän firma, asiakas ei suostu maksamaan enää yhtään enempää."

"Tiedätkö, miten kalliiksi tuotantokäytössä löytyvät bugit tulevat? Tai miten paljon työläämpää on tulkita ja hallita keskivertoasiakkaan bugiraportteja kuin meidän omien ammattitestaajien bugiraportteja? Mitä tulee koulutuksesta, kun softa ei toimi? Tai miten vaikuttaa asiakastyytyväisyyteen tai käyttäjien muutosvastarintaan, jos aloitetaan keskeneräisellä järjestelmällä?"

"No en minä voi kehittäjiltäkään sitä työaikaa nipistää, kun ei siitä järjestelmästä tule valmista ilman heidän työtään."

"Ja mikä saa sinut kuvittelemaan, että he saavat sen käyttökuntoon ilman että sitä testataan? Kuule maailmassa on aika paljon hyvää tuotekehitystä mennyt hukkaan, kun puutteellisen testauksen takia softaa ei ole saatu riittävään kuntoon, että sitä oikeasti voisi käyttää."

"Noh, tuskin tästä nyt sen luokan katastrofi on tulossa."

"Minusta kuulostaa, että sinulla on tässä projektissa toteutunut aika merkittävä määrä riskeistä. Sillä on väistämättä aikataulu- tai kustannusvaikutuksia, usein molempia."

"Mutta kun asiakas ei tule hyväksymään korkeampaa hintaa eikä viivästettyä aikataulua!"

"Ei se järjestelmä tunne projektin aikataulua, se valmistuu tekemällä ja testaamalla. Jos hintaa ja aikataulua ei voi venyttää, niin ominaisuuslistaa tulee pienentää."

"Sinä et tunne tätä asiakasta, eivät ne tule suostumaan... Eikä se tällä aikataululla onnistuisikaan. Sitä paitsi kaikki on melkein valmista, joten olisi tyhmää jättää mitään kesken."

Laskeutui hiljaisuus. Ilmastoinnin humina tuntui painostavana. Projektipäällikkö painoi päänsä käsiinsä ja huokaisi syvään.

"Mitä tässä sitten sinun mielestäsi tulisi tehdä?"

Testaaja katsoi ulos ikkunasta. Aurinko paistoi.

"Lähdetään kaljalle."

"Mitä, nyt on keskiviikkoiltapäivä?"

"Joo joo. Sulla on varmasti jo viikon tunnit täynnä, etkä pysty nyt edistämään mitään. Mennään kaljalle."

"Mutta eihän se käy!"

"No tietysti se käy. Otetaan mukaan kynää ja paperia ja suunnitellaan yhdessä kriisiviestintä. Kun sitten aamukrapulassa soitat asiakkaalle, kuulostat niin autenttisen katuvalta ja uupuneelta, että ne kyllä leppyvät."

Hetken hiljaisuus.

"Absurdia, mutta tuossa saattaa olla järkeä..."

"Joo joo. Enemmän kuin monessa asiassa, mitä tänään on tullut vastaan."