Voimauttaako vai kyynistääkö tuotteesi käyttäjiä?

Olin yhteydessä tulevan hankkeen yhteistyökumppaniin asiasta, jonka olisi periaatteessa pitänyt voida tehdä käytössämme olevan tietojärjestelmän kautta. Erinäisten sähköpostikeskustelujen ja konsortioviestien jälkeen asia ratkesi, ja pääsimme asiassa askeleen eteenpäin. Selvittelyn lopussa pohdin vielä mainintaa yhteistyötaholle heidän käyttämänsä järjestelmän ongelmallisuudesta, ja miten sen voisi ratkaista, mutta päätin lopulta olla laittamatta viestiä asiasta. Päätös ei johtunut mistään hienotunteisuuden puuskasta, tai ’kaikki toimii hienosti’ -kulissin ylläpitämisestä: tiedän hyvin, että heillä itsellään on ollut suurta tuskaa kyseisen järjestelmän kanssa, ja asiasta on julkisuudessakin puhuttu jonkin verran.

Oikeastaan juuri tuo asian tunnettuus johti päätökseni jättää nostamasta asia pöydälle. Oletin, että kaikki osapuolet tietävät jo, sillä tästä on ollut puhetta, ja on itsestään selvää, että jos järjestelmän hoidettavana olevia asioita joudutaan selvittelemään puolin ja toisin sähköpostitse, niin jotain on pielessä. Oletin myös että, jos järjestelmätoimittaja ei ole saanut järjestelmää tähän päivään mennessä toimimaan, niin ehkei se jatkossakaan paremmaksi muutu.

Tiivistäen voisi sanoa, että oletin että joko 1) kaikki ongelmat on varmasti havaittu ja raportoitu moneen kertaan, tai 2) järjestelmä on jo tuhoon tuomittu toivoton tapaus. Kummassakin tapauksessa ongelman raportointi ja korjausehdotuksen pohtiminen olisi vain ajanhukkaa.

Sitten pysähdyin hetkeksi miettimään. Entä jos kaikki muutkin ajattelevat samoin? Entä jos järjestelmätoimittaja on tehnyt hyvin puutteellista testausta, ja on tunnistanut vain osan virheistä, tai esimerkiksi ei ymmärrä käyttötapauksia kaikkien käyttäjien näkökulmasta (vrt. agenttiteoria Eisenhardt 1989), eikä edes tunnista kaikkia virheellisyyksiä ja puutteellisuuksia? Entä jos tuotteen kehitysjono elää täysin irrallaan todellisesta maailmasta: kehittäjät pohtivat kehittämiskohteita omista kuplistaan, ja todelliset käyttäjät eivät jaksa raportoida ongelmista, olettaen että joko ongelmat jo tiedetään, tai että niille ei kuitenkaan tehdä mitään? Jäin pohtimaan, miten pitkällä aikavälillä tuollainen todellisuudesta irtaantuminen ja kuplautuminen voi olla hyvinkin mahdollista.

Tämänkaltainen kehityskulku ei varmastikaan ole tarkoituksellista, saati tietoista. Järjestelmän kehittämisen aikana ja vielä käyttöönoton alussakin varmasti kerätään käyttökokemuksia laajasti ja pyritään parantamaan kehitettävän järjestelmän toimivuutta. Mutta jos korjattavaa on paljon ja kehittäminen hidastuu, esimerkiksi käyttäjille näkymättömien teknisten haasteiden vuoksi, niin ajan mittaan se saattaa näyttää loppukäyttäjille siltä, että kehittäjiä ei kiinnosta korjata käyttäjille keskeisiä toiminnallisuuksia, joten niitä ei jonkin ajan jälkeen enää pyydetäkään.

Syynä tilanteeseen voi olla se, että ollaan lähdetty tuotantoon liian keskeneräisellä tuotteella, ja lisäksi ylläpitovaiheessa on osoitettu liian vähän resursseja korjaamiseen ja jatkokehittämiseen. Toinen skenaario on se, että keskeneräinen tuote on todettu valmiiksi (esim. aikataulu tai taloudellisista syistä) ja kapula on vaihtunut kehitystiimiltä ylläpitotiimille, jolla ei riitä aika eikä osaaminen kaikkien haasteiden ratkaisemiseen. Lisäksi, jos järjestelmä on huonosti toteutettu (esim. arkkitehtuurivirheet, tekninen velka), ja jatkokehittäjien osaaminen ei aivan yllä tarvittavalle tasolle, on riski, että jokaisesta muutoksesta seuraa useita uusia teknisiä ongelmia, joiden ratkomiseen menee paljon aikaa (ja tekninen velka kasvaa koko ajan).

Loppukäyttäjät helposti muuttuvat kyynisiksi: muutoksia lakataan pyytämästä, mutta epävirallinen valitus ja harmitus nousee aivan uusiin sfääreihin. Lopputuloksena virheitä ei enää pyritäkään korjaamaan, vaan niille aletaan löytää kiertoteitä: käyttäjille voi olla esimerkiksi paljon mielekkäämpää uhrata muutamia tunteja ylimääräiseen sähköpostikeskusteluun, kuin ottaa riski järjestelmän päivityksen ja siitä seuraavien uusien ongelmien suhteen.

Miten tällainen tilanne voidaan välttää? Seuraavassa muutama yleisohje, joiden pitäisi olla tuttuja kaikille järjestelmiä kehittäville.

Kuva: Shutterstock