Avainsanat: ‘loppukäyttäjä’

Näin tehdään pistiäisestä perhonen

perjantai, 23 heinäkuuta, 2010 | Kirjoittaja: Antti Niittyviita

Kesätervehdys arvon lukijat. Näin kuumottavimpien helteiden päätteeksi on hyvä palata hetkeksi ohjelmistotestauksen ja virheidenhallinnan ihmeelliseen maailmaan.

Kesän ajan olen seuraillut kuumana käyvää keskustelua älypuhelinrintamalla liittyen matkapuhelinten antenniongelmiin. Tarkemmin ottaen iPhone 4:n ongelmaan ja sen käsittelyyn. Uuden iPhonen rungon oikeaan alareunaan koskettaminen nimittäin pudottaa matkapuhelinverkon kuuluvuuden olemattomiin, kuten oheisesta videosta voi todeta.

Kyseessä on selvästi bugi, joka näyttää päässeen läpi useista laadunvarmistuksen tasoista aina hw-testauksesta loppukäyttäjätesteihin asti. Ammattimaisesti toteutetusta testausprosessista tämän tyyppisen virheen ei kuitenkaan pitäisi päästä läpi. Ei Applella eikä muuallakaan.

Minä väitänkin että tämä kyseinen virhe saatiin kiinni aivan oikeassa vaiheessa tuotekehityksen elinkaarta. Virhe pääsi kuitenkin markkinoille asti virheidenhallintaprosessin takia. Liian usein olen nähnyt kuinka täysin selkeitä virheitä arvioidaan ja todetaan “works as designed”.

Todetaan että bugi onkin feature. Näinhän sen pitääkin toimia!

Applella osataan kuitenkin markkinointi. Tuote-esittelyt suorastaan pullistelevat ylisanoja. Tuotteet ovat uskomattomia ja mahtavia. iPhone 4:n tapauksessa Apple on päättäny hoitaa ongelman jakamalla kaikille viasta raportoineille asiakkaille ilmaiset suojakuoret puhelimeen. Kun suojakuori on välissä, käsi ei pääse koskettamaan puhelimen pinnassa olevaa kriittistä aluetta. Näin toimimalla rivien välistä voidaan lukea että:

Olemme tiedostaneet virheen, mutta emme osaa sitä korjata. Vika on siis hardiksessa.

Kuitenkin markkinointiviesti on väkevämpi:

Me olemme inhimillisä ja myös me teemme virheitä. Rakastamme käyttäjiämme ja haluamme korvata virheemme antamalla lahjaksi puhelimeen suojakuoren.

Tämä toki herättää kätevästi loppuasiakkaan myötätunnon. Näin bugista tehtiin perhonen.

Oikeasti virheiden pukeminen featureiksi on vaarallista. Se on uhkapeliä sekä tuotteesi, että yrityksesi maineella.

Jos siis markkinointisi ei toimi kuten Applella, mieti tarkkaan ennen kuin edes yrität sitä.

Share

Vaatimukset täyttyvät, entäs sitten?

keskiviikko, 16 kesäkuuta, 2010 | Kirjoittaja: Antti Niittyviita

Teimme jokin tovi takaperin aasialaispohjaisella testaustiimillä kaksi testikierrosta ihan kokeilumielessä. Ensimmäiselle testikierrokselle laadittiin hyvin selkeäsanainen testispeksi testattavan tuotteen vaatimusten pohjalta.

Testaustyö tehtiin Intiassa ja tulokset olivat odotetunlaiset. 40 testitapauksen joukosta löytyi 18 virhettä. Yhtä paljon kuin testien suunnitteluvaiheessakin oli jo löydetty (*). Toisen testikierroksen tehtävänanto oli selvästi erilainen. Käytettävissä oli yhtä paljon aikaa testaustyöhön kuin edelliselläkin kerralla.

Toimeksiantoon lähetettiin ainoastaan testattava tuote ja ranskalaisin viivoin lista asioista jotka kannattaa tsekata testaustyön ohessa. Ei siis vaatimuksia, eikä testitapauksia:

Test this product to your best knowledge and report all issues in a way you find best suited

Lopputuloksena raportteja saatiin 25. Virheiden raportointiin testaustiimi käytti vielä kekseliäästi videonkaappausta, joten kenellekään ei jäänyt epäselväksi minkälaisista virheistä oli kysymys. Myös ohjelmistokehittäjät kiittivät!

Suorittavaan testaustyöhön käytetystä ajasta saatiin tarkalleen ottaen 38% parempi tulos kun testaajan käsiä ei sidottu vaatimusten tai testitapausten kyttäämisellä. Testaaja otti loppukäyttäjän hatun päähänsä ja raportoi virheistä parhaan kokemuksensa mukaan.

Kuilu vaatimusten mukaan toimivan ja oikeasti toimivan välillä meinasi tässä tapauksessa jäädä hurjan kokoiseksi. Probleema onkin juuri siinä että vaatimusmäärittelyt tehdään lähes poikkeuksetta ennen tuotteen rakentamista. Vaatimukset ovat etukäteen suunnittelijan pään sisällä muodostettu käsitys siitä miten lopputuotteen pitäisi pelata. Pidä se mielessä kun suunnittelet testausta.

Muista että vaatimusten mukaan toimiva tuote ei ehkä ole toimiva tuote. Vasta avoimin mielin tehty testaus voi kertoa miten oikeasti kävi!

(*) Testauksen suunnitteluvaiheessa jouduttiin tutustumaan sekä toiminnallisiin vaatimuksiin että tutkimaan itse tuotetta, eli tekemään tutkivaa testausta. Suunnitteluvaihe siis vei myös reilusti aikaa.

Share

Travel, ohjelmistojen aatelia

keskiviikko, 7 huhtikuuta, 2010 | Kirjoittaja: Jaakko Sakaranaho

Muutama kaveri työskentelee Oulun yliopistolla. Kuten monissa muissakin julkisen palvelun laitoksissa, on sielläkin käytössä Travel-matkalaskutusjärjestelmä. Käytettävyysongelmien takia softa on ollut päivityksessä kuukausia. Eräs kaveri päivitteli ircissä uutta päivitystä:

13:20 <@Anonyymi> info: ei valuuttakurssia
13:21 <@Anonyymi> tämä fyi kun valitset euron valuutaksi
13:30 <@Anonyymi> aah aa! asiaa tutkittuani intter.netistä, tämähän onkin varsin loogista ja taas vaan käyttäjän vika.
13:30 <@Anonyymi> “taksi, kotimaa” on nimittäin sen verta spesiaali kululaji muiden 300 eri kululajin joukossa että sen tapauksessa ei saa mennä valitsemaan valuutaksi euroa
13:30 <@Anonyymi> vaan se pitää jättää tyhjäksi

13:32 <@Anonyymi> mutta nyt kun tuon opin niin ehkä jopa onnistun ihan koko laskun tekemään omin kätösin nyt

13:42 <@Anonyymi> VIRHE: Pakollinen lisäseliteteksti puuttuu kulu/km -riviltä [-25]
13:42 <@Anonyymi> nuolasin ennenkuin tipahti
13:47 <@Anonyymi> jep. tähän tyssäs. mistään ei puutu mitään. en ainakaan löydä, eikä löytänyt xx:kään.
13:47 <@Anonyymi> tallennus ja kuitit sihteerille ja siitä jatkaa sitten se
13:54 <@Anonyymi> oih, löyty syy. kotimaan kulut vaatii “seliteteksti”-kentän lisäksi vielä “lisäselitteen” joka pitää käydä eri ikkunassa kokonaan syöttämässä :D
13:54 <@Anonyymi> sillä eihän se taksi nyt yhdellä selityksellä selity

Kuinka huono Travel onkaan ollut ennen kuukausia kestänyttä päivitystä?

Tästä purkauksesta kiinnostuneena googlettelin travelia hieman. Mielenkiintoisin keskustelu löytyi suomi24-palstalla, jossa keskustelunavauksessa siteerattiin Helsingin Sanomia 4.1.2009. Hesarin juttu löytyy digilehdestä, josta sen pääsee Hesarin verkkotunnuksilla lukemaan.

Jutussa haastatellaan TKK:n vuorovaikutteisen digitaalisen median professoria, joka on tutkinut valtionhallinnon ohjelmistohankintoja. Ei silitellä päätä ei. Hyvä herra professori oli ottanut yhteyttä Travelin tilaajaan, ja vähän kysellyt asioista.

Vastaanotto oli nihkeä. Takala sai muun muassa kuulla, että ohjelman testaamisessa haluttiin lakisyistä sulkea pois nykyiset Travelin käyttäjät.

Peruste, oli että koska olemme käyttäneet ohjelman aiempaa versiota, voi meillä olla sen toimittajaa kohtaan ennakkoasenne, minkä takia emme ole puolueettomia.

Vetää sanattomaksi.

Ennen kuin julkaiset ohjelmiston, pyydä nyt hyvänen aika kommentit edes peruskäyttäjältä.


Share

Ammattilaisuuden alasajo?

keskiviikko, 18 marraskuuta, 2009 | Kirjoittaja: Antti Niittyviita

Tuli kannattavammaksi myydä sutta halvalla kuin laatua kalliilla! Lepää rauhassa ammattimies!

…kirjoitti Markku Saksa Taloussanomien kolumnissaan näin ajettiin ammattimies alas. Nykytrendi tosiaankin tuntuu olevan nopea tuoton tavoittelu laadun kustannuksella. Onko testaaminen siis enää kannattavaa? Ylilaadun ja riittävän laadun rajat molemmat liikkuvat huonompaa kohti. Loppuasiakaskin on alkanut tyytymään siihen mitä tarjolla on.

Itse en koskaan osta kodintekniikan tuotteista ensimmäistä versiota. Mieluummin odotan että tuote on kunnolla testattu ja pahimmat viat on ehditty korjaamaan. Kaupassakin tsekkaan aina tarrat useampien pakettien kyljestä kuten parasta ennen päiväyksen maitopurkista. Tsekkaapa ensikerralla huvikseen tietoja usb-kovalevystäsi tai reitittimestäsi kaupan hyllyssä. Vertaile sarjanumerotarrojen tietoja. On jännää huomata kuinka monta eri versiota saman mallin tuotteesta voi hyllystä löytyä. Testausta on ulkoistettu loppukäyttäjälle. En tykkää!

Ammattilaisutta ei minusta silti ole ajettu täysin alas. Nykyammattilaisuutta on keskittyä oikeisiin asioihin.

Apple teki minusta ovelan tempun laadunvarmistuksen näkökulmasta puhelinbisneksellään. Koko tuotekehitys on silmin nähtävästi lähtenyt siitä että loppukäyttäjälle tarjotaan positiivisia käyttäjäkokemuksia. Todellisuudessa iPhonen taustalla oleva toiminnallisuus ei ole niin hyvää. Tyypihyväksyntätestit takkuavat ja operaattoria ahdistaa kun yksi iPhone saattaa kerralla varata kymmenien puhelinten verran verkon resursseja. Mutta ei se haittaa kun laadussa on panostettu juuri oikeaan paikkaan.

Laatukustannusten oikean ajoittamisen lisäksi laatukustannuksia pitää siis keskittää siihen missä se eniten merkitsee. Loppukäyttäjätuotteilla kannattaa keskittyä käyttäjäkokemuksiin. Se on myös bisnesriskien hallintaa.

Jos aiot markkinoille aikaisessa vaiheessa ja olet päättänyt tehdä sen laadun kustannuksella, varmista että olet testannut vähintäänkin ne oikeat asiat. Asiat, jotka vaikuttavat vastaanottoosi kohderyhmässä.

Share

Muutama sana asiakaslähtöisyydestä

perjantai, 11 syyskuuta, 2009 | Kirjoittaja: Jaakko Sakaranaho

Kurkkasin pikaisesti muutaman suomalaisen ohjelmistoyritysten verkkosivuja. Monet arvoistaan julkisesti puhuvat ilmoittivat olevansa erityisen Asiakaslähtöisiä. Se on hyvä. Ilman asiakkaita tuskin on tulojakaan.

Uskallan kuitenkin väittää, että liian moni yritys jättää käyttämättä loppukäyttäjien panoksen tuotekehityksensä apuna. Turhaa riesaa ja häiritsevät työtä, voi moni ajatella. Melko asiakaslähtöistä.

Yhdysvaltalainen Standish Group julkaisee säännöllisin väliajoin Chaos Reportin. Raportissa kerrotaan mm. miksi ohjelmistoprojektir onnistuvat tai epäonnistuvat. Vuoden 2009 raportin voi tilata 99USD:n hintaan, mutta koska vuoden 2004 Chaos Reportin dataa on luettavissa ilmaiseksi, katsotaan sitä. Keskustelun herättämiseksi tehdään suoraviivainen oletus, että onnistumisen syyt ovat pysyneet kutakuinkin samana. Vertailun vuoksi kerrotakoon vielä, että vuonna 2004 29% projekteista oli onnistuineita, kun vastavaa luku 2009 on 32%.

Chaos Reportin mukaan onnistuneen softaprojektin tärkeimpänä yksittäisenä tekijänä on käyttäjien kuunteleminen projektin aikana. Lisäksi jo vuoden 1995 Chaos Report totesi, että mikäli projektissa oli haasteita (toimitus oli myöhässä, budjetti ylittyi ja tai toiminnallisuuksia oli karsittu), yksittäisistä tekijöistä suurimpana syynä oli käyttäjäpalautteen puute. Yli joka kymmenes projektin epäonnistuminen johtui siitä, että käyttäjiä ei ole viitsitty/jaksettu/voitu kuunnella kehitysprojektin aikana. Esimerkkinä voidaan mainita sähköisen äänestyksen kokeilu viime syksyn kunnallisvaaleissa. Todellisten käyttäjien käyttäjäkokemukset ja palaute jätettin, ei pelkästään huomiotta, vaan kokonaan hankkimatta.

No, mitenkäs tämä nyt sitten liittyy testaukseen? Ottakaa asiakkaanne (ei pelkästään niitä päätöksentekijöitä vaan myös tuotteenne päivittäiset käyttäjät) mukaan tuotekehitykseen. Minä ainakin olisin riemuissani, jos yritykselleni räätälöitäisiin jokin työkalu ja minua pyydettäisiin mukaan varmistamaan sen toiminnallisuuksia jo kehityksen aikana! Tuotteen käyttäjäystävällisyys kasvaa. Se on mitä mainiointa markkinointia yrityksen muita tulevia projekteja ajatellen. Loppukäyttäjien palaute jo tuotekehitysvaiheessa antaa myös paljon lisää myytävää ja jatkokehitysajatuksia.

Loppukäyttäjien palaute on erinomaisen tärkeää varsinkin siinä tilanteessa, kun vaatimusmäärittely on parhaista yrityksistä huolimatta jäänyt puutteelliseksi. Kun loppukäyttäjiä kannustetaan testaamaan kehityksen alla olevaa toiminnallisuutta, saadaan mahdolliset vaatimusongelmat korjattua.

Pystytä julkinen testiserveri. Lahjo loppukäyttäjät kehitettävien ominaisuuksien testaajiksi. Kirjaa ylös kehityskohdat ja projektin ulkopuoliset toiminnallisuusehdotukset. ”Ihan kiva”-ominaisuuksien lisäksi saat ilmaisia vinkkejä asiakkaasi tuloksen parantamiseksi. Se on rahanarvoista matskua.

Share