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.

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.

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.

Älä turhaan suunnittele testausta

Testauksen voi suunnitella monella tavalla. Testitapauksia voi kirjoittaa hyvin yksityiskohtaisesti, tai ne voi rakentaa vain otsikkotasolla, muistilistanomaisesti. Itse testauksen organisointia voi suunnitella enemmän tai vähemmän perusteellisesti. Testaussuunnitelma voi kertoa mm. kuinka paljon työaikaa ja kalenteriaikaa käytetään mihinkin testikierrokseen, miten paljon aikaa varataan niihin liittyviin korjauksiin verifiointeineen, kuinka usein testikierroksia toistetaan, ja mitkä ovat kriteerit testauksen lopettamiseen.

Joskus on hyvä pysähtyä hetkeksi miettimään, millä tarkkuustasolla nämä asiat kannattaa tehdä projektin suunnnitteluvaiheen aikana.

Perusteellinen testaussuunnittelu liittyy usein siihen, että asiakkaalle on luvattu tiettyjä dokumentteja tietyssä vaiheessa projektia. Jos asiakkaan kanssa sovitaan, että he saavat toimittajan testitapaukset sisältöineen kaikkineen käytettäväksi omassa hyväksymistestauksessaan, ne on rakennettava paljon huolellisemmin ja paljon enemmän aikaa käyttäen kuin jos luodaan vain alustava testitapausluettelo, jota muokataan ja täydennetään tarpeen mukaan testausvaiheessa. Jos asiakas haluaa lukea testaussuunnitelman, siinä ei oikein voi lukea että testataan sitä mukaa kun jotain on likipitäen testattavissa, testaajana se joka sattuu silloin parhaiten ehtimään. Joskus tämä kuitenkin olisi tarkoituksenmukaisempi suunnitteludokumentti kuin sellainen, joka ottaa kantaa kaikkeen mahdolliseen testaamisen aloitus- ja keskeytyskriteereistä testikierrosten organisointiin. Kenties keskeisin hyvän testaussuunnitteludokumentin piirre voisi olla se, että se on riittävän lyhyt jotta projektin kulkua ohjaavat henkilöt lukevat ja sisäistävät sen.

Jos oikeastaan mikään ei todellisuudessa tapahdu suunnitteludokumentaation mukaisesti, eikä sitä tosiasiallisesti edes yritetä noudattaa (olipa syy tähän sitten piittaamattomuus tai projektielämän realiteetit), kuinka paljon aikaa tällaisen dokumentin kirjoittamiseen kannattaa käyttää?

Jos projektia edistetään vähän miten nyt kukakin sattuu ehtimään, on testauksessakaan turha pyrkiä tämän suurempaan kurinalaisuuteen. Klassinen testaus perusteellisine testitapausluetteloineen ja huolella ennalta suunniteltuine testikierroksineen on mielekästä vain, jos myös projektin edeltävät vaiheet viedään läpi vastaavaa kurinalaisuutta noudattaen. Eli määritysvaiheessa todella määritetään ja kiinnitetään määritykset, suunnitteluvaiheessa ihan oikeasti suunnitellaan määrityksen pohjalta, ja toteutusvaiheessa nämä suunnitelmat viedään läpi aikataulussa.

Kaikissa projekteissa tämä ei kuitenkaan ole mahdollista. Eikä kyse ole vain toteuttavan projektihenkilöstön osaamisesta ja viitseliäisyydestä. Tilanteeseen vaikuttaa myös esimerkiksi asiakkaan määritysosaaminen, eli pystyvätkö he kertomaan, mitä haluavat, ja kuinka paljon projektin aikatauluun sisällytettäviä muutoksia he keksivät suunnittelu- ja toteutusvaiheiden aikana, Ja tähän taas vaikuttaa paitsi asiakkaan projektiryhmän IT- ja substanssiosaamisen riittävyys, myös asiakkaan tarpeiden selkeys.

Lisäksi, ihmiset ovat erehtyväisiä. Paraskin projektipäällikkö voi unohtaa jotakin, ja paraskin tekninen vastuuhenkilö ymmärtää jotain väärin. On vain hyvä asia, jos nämä unohdukset ja väärinymmärrykset jäävät kiinni ennen stabilointivaihetta, koska silloin niiden vaikutukset aikatauluihin ja työmääriin ovat vähäisemmät. 

Jokainen projektiin tuleva muutos kuitenkin syö etukäteen tehdyn perusteellisen testaussuunnittelun arvoa. Mitä enemmän asioita on kirjoitettu auki testitapauksiin, sitä enemmän niitä on pakko muokata muutosten mukaisesti, ja sitä suurempi riski on sille että testaus raportoi vääriä asioita bugeina. Mitä enemmän projektin käytännöt ja järjestelyt poikkeavat testaussuunnitelmasta ehdotetuista, sitä vähemmän arvoa on sen kirjoittamiseksi tehdyllä työllä. Kun tämän päälle tulee vielä testaussuunnittelun itsensä epätäydellisyys, on selvää että määritysvaiheen perusteella tehdyt testitapaukset on vähintään katsottava läpi kriittisellä silmällä testauksen alkaessa.

Testaussuunnittelu on mahdollista tehdä myös toisin. Määritys- ja suunnitteluvaiheessa testauksen rooli voi keskittyä enemmänkin katselmointiin ja konsultointiin. Testaussuunnitteludokumentaation keskeisin rooli voi olla tiedon kerääminen siitä, mihin dokumentteihin nojaten testaus on tehtävä, sekä millaisia riskejä projektiin liittyy testaamisen näkökulmasta ja miten niihin varaudutaan. Riskitarkastelussa käsitellään niin testaukseen ulkopuolelta vaikuttavat riskit kuin riskit joihin testaaja voi itse vaikuttaa, muistaen erityisesti asiakkaan toiminnan kannalta keskeisimmät toimitettavaan järjestelmään liittyvät riskit, joiden tulisi vaikuttaa testauksen sisällölliseen painotukseen. Varsinaiset testitapaukset voidaan luoda tutkivan testauksen ohessa, tosin tällöin on muistettava että testaukseen tarvittavaan aikaan on lisättävä myös dokumentaation vaatima aika.

Mikä siis on päivän opetus? 

Klassisella, kurinalaisella testauksella on oma arvonsa ja paikkansa, mutta kaikkialle se ei sovi. Jos tiedät, ettet aikuisten oikeasti pysty viemään projektia läpi tiukasti vesiputousmallin mukaisesti, älä tee myöskään testaussuunnittelua niin kuin mentäisiin vesiputousmallilla. Älä silloin myöskään lupaa asiakkaalle testitapauksia (paitsi korkeintaan otsikkotasolla) suunnitteluvaiheessa. Tosiasiat voi tunnustaa jo etukäteen, ja ammattimainen testaaja pystyy kyllä luovimaan tiensä myös vähän epämääräisemmässä projektiympäristössä. Säästytään puolin jos toisin paljolta pahalta mieleltä ja turhalta työltä, jos projektin toimintatavoista sovitaan avoimesti etsien ne tavat, joilla tieto parhaiten löytää tarvitsijansa, ja testaus voidaan suunnitella tavalla jolla se todennäköisesti voidaan myös toteuttaa.