Asiakas on oikeassa, vaikka hänellä ei ole hajuakaan

Olin aikaisemman työpaikan kautta erään yrityksen kehitysprojektin kakkosvaiheen avaustilaisuudessa. Hankkeessa oli mukana monia IT-toimittajia ja eräs osa tilaisuutta oli, että toimittajat esittelivät, missä tilanteessa heidän osansa projektia on.

Erään suomalaisen ohjelmistotalon projektipäällikkö valitti, että he eivät oikein ole päässeet etenemään, kun asiakkaalta ei ole saatu vaatimuksia.

Kiemurtelin myötähäpeästä tuolillani.

Kyllä, osa minunkin saamaa ohjelmistoalan koulutusta on ollut, että vaatimukset kerätään asiakkaalta, sitten ehkä täsmennetään asiakkaan kanssa ja toteutetaan tuotteeseen. Tämä on ohjelmistoalalta samanlainen megaluokan harhalaukaus kuin vesiputousmalli.

Ei pidä hetkeäkään kuvitella, että asiakas tietää, mitä hän haluaa.

Esimerkiksi, kun joskus muinoin olin ostamassa moduuleista koottavaa kirjahyllyä, kysyin myyjältä kaupassa, minkälaisen hyllyn näistä voi koota. Myyjä sanoi, että “ihan minkäläisen vaan”. Päädyin ostamaan tismalleen samanlaisen yhdistelmän, kuin kaupassa oli esillä. Ei minulla ollut osaamista huonekalusuunniteluun niin paljoa, että olisin osannut suunnitella hyllyn. Eikä asiakkaalta pidäkkään vaatia, että hän on huonekalusuunnittelun asiantuntija, saati sitten ohjelmistotekniikan.

Nyt syntyykin dilemma: tunnetun sanonnan mukaan asiakas on aina oikeassa ja asiakaslähtöisyys on menestyvän toiminnan A ja O.

Molemmat pitävät täysin paikkansa.

Ensialkuun kuulostaa tietysti hiukan pahalta ongelmalta, miten tehdään asiakasta miellyttäviä tuotteita, kun asiakkaalla itsellään ei ole hajua siitä, mitä hän haluaa. Solmun ratkaisu on yksinkertainen: pitää perehtyä asiakkaiden tarpeisiin, niin että ymmärtää, mitä he tarvitsevat ja suunnitella siltä pohjalta ratkaisu.

Tämä on periaatteessa samanlaista työtä kuin mitä vaikkapa sisustussuunnittelijat tekevät: he ottavat selville, minkälainen maku asiakkaalla on ja sen jälkeen tekevät yksityiskohtaiset valinnat ammattitaitonsa ja osaamisensa perusteella. Lisäksi lähes poikkeuksetta, vaikka asiakas ei etukäteen osaa sanoa, minkälaisen ratkaisun hän haluaa, niin luonnoksia hän jo osaa kommentoida sujuvasti.

Tuotekehitys tulee tehdä samalla tavalla:

1. Selvitä, mitä asiakas tarvitsee
2. Suunnittele ratkaisu
3. Esittele se asiakkaalle
4. Kerää palaute ja paranna tarvittaessa

Esimerkiksi itse olen Ennakkolippu.com:n toimintoja kehitellessä seurannut, miten lipuntarkistus tapahtuu ja mitä ongelmakohtia siinä on. Omista työtehtävistään asiakas kyllä osaa kertoa. Kertyneen ymmärryksen pohjalta voi sitten omaa ohjelmisto-osaamista ja ideointikykyä hyödyntäen suunnitella järjestelmän lipuntarkastukseen. Mutta jos olisin kysynyt avoimen kysymyksen, “mitkä ovat vaatimukset?”, niin takuuvarmasti ei oltaisi alkua pidemmällä.

Jos kaikki menee nappiin, niin sitten päästään jo siihen, että asiakaskin tietää tarkalleen mitä haluaa:

Tahtoo ton!

Linkki: http://en.wikipedia.org/wiki/Interaction_design

---