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.

Kuinka rakennetaan muutosvastarinta

Sujuvatko IT-projektisi turhan helposti? Ovatko asiakkaat liiankin tyytyväisiä? Ei hätää, tässä muutama vinkki, joilla saat työhösi uutta haastetta.

Älä ole kiinnostunut asiakkaan prosesseista, vaan minimoi tuotettavan tiedon määrää

Jo määritysvaiheessa kannattaa unohtaa asiakkaan käyttäjäroolit sekä niihin liittyvät tehtävät ja tavoitteet. Älä osoita kiinnostusta sen selvittämiseen, mitä asiakkaan todelliset käyttäjäryhmät ovat, mitä he tarvitsevat tai saavatko he äänensä kuuluviin. Määritystyöpajojen ensisijainen tehtävä on juoda kahvia ja jutella mukavia samalla kun selataan läpi irrallisia vaatimuksia ja tuotetaan sisällötöntä dokumentaatiota erilaisten johtajien luettavaksi.

Parasta on, jos saat määritystyöhön nakitettua henkilön, joka ei ymmärrä mitään asiakkaan toimialasta eikä myymästään teknologiasta, mutta osaa poliittisen jargonin jolla voidaan antaa kaikille käsitys että tässä nyt määritetään jotain vaikkei oikeasti määritetäkään. Jos myyt valmissoftaa, älä ainakaan esittele tuotteen demoympäristöä asiakkaalle - hehän saattaisivat vaikka ymmärtää, mistä määritystä tehtäessä puhutaan.

Suunnittelu- ja toteutusvaiheessa panosta vain siihen, että koodaaja pääsee mahdollisimman helpolla. Pyydetty toiminnallisuus on olemassa, jos sen yksinkertaisin käyttötapaus on mahdollista viedä läpi. Ei väliä, onko normaalin ihmisen mahdollista muistaa prosessin läpiviemisen vaatima akrobatia, tai löytyykö käyttöliittymästä kaikki tarvittava sen tekemiseen. Tärkeintä on, että ratkaisu on olemassa.

Panosta käyttöliittymän sekavuuteen

Pidä huolta, että käyttöliittymässä näkyy käyttäjälle moninkertainen määrä toiminnallisuuksia siihen nähden mitä hän tarvitsee. Parasta on, jos joukossa on viattoman näköisiä toiminnallisuuksia, joiden käyttäminen aiheuttaa katastrofin. Ja lupaavan ja tarpeellisen näköisiä toiminnallisuuksia, jotka eivät tee mitään. Ja toiminnallisuuksia, joista kukaan ei tiedä, mitä ne ovat ja miksi ne ovat siellä, saati seuraisiko niiden piilottamisesta katastrofi.

Jos käyttöliittymässä on personointeja kuten asiakkaan nimi, kirjoita se väärin. Tai kopioi toiminnallisuus toiselta asiakkaalta ja jätä vaihtamatta nimi, jotta käyttäjät varmasti ymmärtäisivät, ettei tätä järjestelmää heitä varten rakenneta.

Pyydä asiakkaalta vastauksia samoihin kysymyksiin useampaan kertaan

Älä lue projektissa tuotettua määritysdokumentaatiota. Älä pidä sitä ajantasalla. Pyydä asiakkaalta tietoa listoina, joiden merkityksiä he eivät ymmärrä, ja pyydä tätä tietoa kuukauden päästä uudelleen hukattuasi ensimmäisen version tai todettuasi ettei sen sisältö kuitenkaan vastaa asiakkaan tarpeita.

Älä näytä asiakasta ja teknisiä asiantuntijoita toisilleen, vaan pidä välissä suodattimena henkilöä joka ei ymmärrä heistä kumpaakaan, ja jolla ei riitä aika tehtäviensä hoitamiseen.

Kouluta keskeneräisellä järjestelmällä

Mikään ei ole parempi tapa pelotella ja hämmentää tulevia käyttäjiä kuin koulutusten järjestäminen heti kun jotain likipitäen pystyssä pysyvää on saatu asennettua. Oppi uppoaa parhaiten, kun koulutuksessa toistuvat fraasit "tämä olisi järkevämpää tehdä vähän toisella tavalla, mutta koska siinä on nyt bugi niin tehdään vähän vaikeammalla ja epäintuitiivisemmalla tavalla" sekä "sitten kun tämä valmistuu, niin tänne tulee näkyviin sellainen toiminto jonka kautta voitte tehdä sitä-ja-tätä". Parasta on, että järjestelmän ollessa koulutuksessa riittävän keskeneräinen, asiakas pääsee käyttämään sitä itse vasta kuukausia myöhemmin, mihin mennessä kaikki opitut tiedonmuruset ovat ehtineet unohtua.

Kikkaile raportoinnin kanssa, jotta asiakas aloittaisi hyväksymistestauksen vaikka toteutus on kesken

Tekee aina hyvää asiakassuhteelle väittää kirkkain silmin että kaikki toimii, kun seuraavana päivänä asiakas kokeilee itse ja saa todeta että mikään ei toimi. Ja kuinka mielenkiintoista onkaan selvittää, miten monta kertaa asiakas suostuu aloittamaan hyväksymistestauksen.

Tee toiminnallisia muutoksia kun järjestelmä on jo asiakastestauksessa tai pilotoinnissa

Jos tuntuu, että joku juttu olisi sitten kuitenkin järkevämpi jollain toisella tavalla, muuta se toimimaan järkevämmin. Ja jää sitten odottamaan, huomaako kukaan eroa, ja jos huomaa, keksiikö millaiseksi toiminnallisuus on muuttunut. Älä ainakaan päivitä käyttöohjetta muutoksen mukaiseksi, älä kerro kouluttajille, testaajille äläkä asiakkaille. Suunnittele valmiiksi ylimielinen vastaus, kun joku onneton kuolevainen uskaltautuu kysymään asiasta tai raportoi muutoksen bugina.

Älä ota asiakkaan ongelmia vakavasti

Kun asiakas on tyytymätön, totea että he eivät vain osaa käyttää järjestelmää, ja siksi heidän pitäisi ostaa lisää koulutusta. Toista tätä viestiä, vaikka asiakas olisi jo maksanut useammasta ekstrakoulutuspäivästä kuin mitä olit sisällyttänyt alkuperäiseen tarjoukseesi riittävänä koulutuspakettina järjestelmän käyttöönottamiseksi.

Miten saada paras hyöty irti testaajasta?

Työpanoksen mittaaminen on vaikeaa. Jollain tavalla työntekijöiden suoriutumista pitäisi seurata, mutta mittareilla on paha tapa vaikuttaa ihmisten suoriutumiseen paitsi hyvässä myös pahassa.

Testaajan työn arviointia hankaloittaa se, että se on niin riippuvaista muiden työskentelystä. Samoin helpoiten muodostettavat testaajan työssä onnistumisen mittarit ovat kaikki omalla tavallaan ongelmallisia.

Löytyvät bugit riippuvat paitsi testaajasta myös kehittäjästä, joten tietyssä aikavälissä löytyvien bugien määrä tai laatu ei välttämättä kerro kovin paljoa siitä, miten hyvin testaaja on aikansa käyttänyt. Jos testaajan työtä arvioidaan mittaamalla löytyvien bugien määrää, se kannustaa testaajaa tehokkaaksi löytämään virheitä, mutta ei suuntaamaan tekemistään oleellisimpiin asioihin - näin bugikanta saadaan helposti täyttymään pienen prioriteetin virheistä. Bugien merkittävyyden arvioiminen statistiikkaa varten taas on työlästä, ellei luoteta testaajan tai hänen kanssaan työkentelevän kehittäjän omaan arvioon bugien prioriteeteistä. Toisaalta tarkkakaan tieto bugien vakavuudesta ei anna tietoa testauksen tehokkuudesta, jos testaaja käyttää paljon aikaa sellaisten asioiden manuaaliseen läpikäymiseen, joiden testaaminen kannattaisi automatisoida.

Testauksen tehokkuutta voidaan mitata myös esimerkiksi sillä, miten suuri osa raportoiduista bugeista saadaan ratkaistua kerralla, kysymättä lisätietoja bugin toistamiseksi. Tämä vaatii kuitenkin suhteellisen huolellista bugiraportointijärjestelmän käyttöä, jotta statistiikkaa saadaan helposti kerättyä, ja siten mahdollistaa myös huijaamisen. Asiakkaan löytämien bugien määrä ja laatu kertoo paljon sisäisesti tehdyn testauksen onnistumisesta, mutta tämän mittarin käyttäminen on monella tavalla hankalaa: miten tieto asiakkaan löydöistä raportoidaan ja luokitellaan, ja miten hallitaan tieto järjestelmään tehtävien päivitysten vaikutuksesta sekä niihin liittyvien testikierrosten vastuista.

Testaajan mahdollisuudet käyttää aikansa hyödyllisesti riippuvat myös siitä, mihin tahtiin testattavaa valmistuu. Hänellä ei ole valtaa vaikuttaa siihen, tuleeko asiakasprojekteista hommia tasaiseen tahtiin, vai joudutaanko vuoroin käyttämään aikaa toissijaisiin tehtäviin ja vuoroin priorisoimaan projekteja. Jos siis mitataan sitä, miten suuri osa ajasta kuluu laskutettavien projektien parissa, kannustaa se toki priorisoimaan ajankäytössä asiakasprojekteja, mutta myös käyttämään näihin projekteihin tarpeettoman paljon aikaa silloin kun asiakasprojekteja ei ole tarjolla täysipäiväisesti. Jos taas mitataan sitä, miten hyvä tuntihinta saadaan tehtävästä työstä, kipeimmin testausta kaipaavat katastrofiprojektit päätyvät testaajan ajankäytön priorisoinnissa viimeiseksi. Entä miten pitäisi huomioida tuotekehityksen tukeminen, tämä työ kun hyödyttää useita asiakasprojekteja?

Asiakastyytyväisyyttäkään ei saavuteta pelkällä testauksella, vaan siihen vaikuttavat mm. projektipäällikön kommunikointitaidot ja määrityksen tekemiseen osallistuvien kyky ymmärtää asiakkaan tarpeet ja muotoilla ne ymmärrettävästi. Jos järjestelmää ei ole onnistuttu määrittämään ja suunnittelemaan täyttämään asiakkaan tarvetta, timanttinenkaan testaus ei tilannetta pelasta. Asiakkaan löytämillä bugeilla kun on merkitystä vain, jos ne ovat syy joka estää järjestelmää täyttämästä sitä tarvetta, jota varten se hankittiin. Jos tärkeimmät valituksen aiheet ovat luonteeltaan muutospyyntöjä, liikutaan alueella jolla testaajien rooli on usein tarkoituksenmukaisinta pitää melko pienenä - ellei häntä sitten tuoda jo määritysvaiheesta alkaen asiakasrajapintaan niin, että hänellä on aidosti mahdollisuus arvioida toteutuksen soveltumista asiakkaan liiketoimintatarpeisiin.

Voidaan myös yksinkertaisesti kysyä projektihenkilöstöltä rivikoodarista projektipäällikköön, onko yhteistyö testaajan kanssa koettu hyödylliseksi, ja millaisia puutteita siinä nähdään. Tällaisten kartoitusten kompastuskiveksi vain koituu helposti se, että kenelläkään ei ole aikaa paneutua ylimääräisiksi koettuihin asioihin, kun seuraavat projektit painavat jo päälle. Lisäksi subjektiivisiin arviointeihin liittyy myös persoonallisuuksiin liittyviä piirteitä, jotka tekevät arvioinnista ylipäätään epämääräistä.


Toisaalta, onko testaajan työn mittaamisella edes merkitystä, jos organisaatio ei osaa täysin hyödyntää testaajan työpanosta?

Pystytäänkö tekeminen projekteissa aikatauluttamaan niin, että testaajan työaika saataisiin mahdollisimman tehokkaasti hyödynnettyä, eli testattavaa saataisiin eri projekteista valmistumaan mahdollisimman tasaiseen tahtiin? Mahdollistavatko projektien aikataulut sellaisen testaamisen, että ammattitestaajista on oikeasti hyötyä?

Onko organisaation sisäiset laskutuskäytännöt muodostettu niin, että projektien kannattaa hyödyntää ammattitestaajia?

Miten testaajan työaikaa hyödynnetään parhaiten silloin, kun testattavaa ei ole? Onko sisäisiä kehitysprojekteja, jotka tuovat hyötyä asiakasprojekteille, tai muita aikataulultaan väljiä tehtäviä, joihin voi käydä käsiksi, jos ei testaamalla pysty olemaan oikeasti avuksi? Tuetaanko testaajien mahdollisuuksia kouluttautua suoriutumaan paremmin työssään? Onko kehittäjien mahdollista itsenäisesti pyytää tukea testaajalta, jos he kokevat sen hyödylliseksi jotakin toiminnallisuutta rakentaessaan?

Entä mitä testaukselta ylipäätään halutaan? Onko tarkoituksena vain etsiä bugeja niin pitkään kuin projektin aikataulu ja budjetti antavat myöten, vai onko tavoitteena esimerkiksi antaa projektipäällikölle mahdollisuus keskittyä työssään olennaiseen, helpottaa kehittäjien työtä, tai saada tieto ohjelmiston laadusta tietyllä ajanhetkellä?

Kun näihin kysymyksiin löytyy vastauksia, on myös relevanttien mittareiden rakentaminen varmasti helpompaa.

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.