Mitä Yhteentoimivuusalustan käyttäjät vastasivat uudenlaiseen kyselyyn?

Kyselyn taustaa

Kysyimme marraskuussa 2020 Yhteentoimivuusalustan käyttäjien mielipidettä kymmeneen ehdotettuun ominaisuuteen tai toiminnallisuuteen. Vuoden 2020 aikana alustalle ei tehty juurikaan kehitystyötä, mutta vuoden 2021 tiekarttaa varten halusimme saada palautetta kehitysehdotuksista. Koska rahaa ja tekijöitä ei ole rajattomasti, haluamme tunnistaa ne ideat, joiden toteuttamisesta koituu hyötyä mahdollisimman monille. Kysymyksenasettelu oli tällä kertaa erilainen kuin aiemmin, sillä hyödynsimme kyselyssä niin sanottua Kano-mallia.

Saamme alustan työkaluihin kehitysehdotuksia ja palautetta useiden eri kanavien kautta, kuten sähköpostiviesteinä, kommentteina alustan työkalujen esittelytilaisuuksissa ja Slack-kanavien kautta. Ne kuitenkin kertovat vain yhden käyttäjän tai käyttäjäryhmän toiveista. Yksittäisten toiveiden kautta ei saa näkymää siihen, kuinka moni muu käyttäjä toivoo samaa ominaisuutta, mikä on toiveen prioriteetti tai onko toive kenties ristiriidassa jonkun toisen käyttäjän tarpeen kanssa. Kano-mallin avulla pyritään saamaan näitä ulottuvuuksia paremmin esiin. Kaikki asiakkaiden esittämät kehittämistoiveet eivät ole samanarvoisia.

Yhteentoimivuus on sinänsä muutakin kuin tekninen alusta, jonne tietosisältöjen kuvauksia määritellään. Monet vastaajat huomauttivatkin, että yhteentoimivuus on myös prosesseja ja ihmisiä ja näiden kyvykkyyksiä, eikä pitäisi rajautua vain yksittäisiin ominaisuuksiin. Rajaus pelkkiin alustan ominaisuuksiin oli kuitenkin tarkoituksellista – halusimme tällä kertaa keskittyä konkreettisiin muutostoiveisiin, jotka voidaan sanoittaa niin, että vaihtoehtoihin on helppoa ottaa kantaa ruksaamalla haluttu vaihtoehto.

Täysin uusien kehitysideoiden tai syväluotaavien toimintamalli- ja prosessikysymyksien esittäminen ja työstäminen Kano-mallilla ei välttämättä ole paras ratkaisu, vaan siihen tarkoitukseen esimerkiksi työpajakeskustelu toimii paremmin. Valikoimme kyselyn vaihtoehdot myös siitä näkökulmasta, että saamme kokemusta myös itse Kano-mallista ja sen käyttökelpoisuudesta. Marraskuun kyselyssä esitettiin kysymyksiä kaikista työkaluista, mutta tulevaisuudessa lienee järkevämpää tehdä kullekin työkalulle omia Kano-kyselyitä.

Kyselyssämme oli mahdollisuus antaa myös avointa palautetta. Yli puolet vastaajista hyödynsikin tätä mahdollisuutta, ja saimme arvokasta palautetta niin kysymyksistämme kuin muistakin teemoista.

Kano-kyselyn toteutustapa

Vuosien aikana Yhteentoimivuusalustan kehittäjille on esitetty kymmeniä, ellei satoja toiveita, jotka on kirjattu Jira-projektinhallintatyökaluumme kehitysideoiksi. Osa toiveista on selkeitä, teknisiä ja suoraviivaisia toteuttaa – on selvää, että Sanastot-työkalussa pitäisi olla valittavissa latinan kieli yhdeksi termien kielivalinnaksi, joten turha kysellä muidenkin mielipidettä, jos tästä puutteesta meille huomautetaan. (Asia on tätä nykyä korjattu.)

Monet esitetyistä toiveista kuitenkin vaikuttavat sisällöntuottajien tai tietoa hyödyntävien toimintatapoihin: jos esimerkiksi lisäämme uuden tilakoodin, niin sen lisääminen alasvetovalikkoon on teknisesti suoraviivaista, mutta mitä muutoksesta seuraa käyttäjille: ovatko tilatietojen erot riittävän selkeitä sisällöntuottajalle, tai pystyykö tietojen käyttäjä kohdistamaan haun aiempaa tarkemmin? Vai tuleeko tilakoodeja jo niin paljon, että niiden välillä on vaikea valita ja siten käytettävyys huononee?

Valitsimme siis kyselyyn nyt ensisijaisesti ehdotuksia, joiden toteuttaminen (ainakin ehdotuksen esittäjän mielestä) olisi tarpeen, mutta jotka eivät itsestäänselvästi hyödytä kaikkia käyttäjiä, vaan jonkin toisen käyttäjäryhmän näkökulmasta saattavat lisätä työmäärää tai huonontaa käytettävyyttä. Onko esimerkiksi tarpeen näyttää myös korvatut koodistot aina kaikille, vai näytetäänkö aluksi vain voimassa olevat koodistot, ja lisäksi annetaan mahdollisuus hakea listaukseen mukaan myös korvatut koodistot. Kumpi vaihtoehto palvelee enemmistöä paremmin?

Yksinkertaisin tapa kysyä asiaa on listata halutut toiminnot ja pyytää käyttäjiä äänestämään niistä. Kano-mallissa tähän on kuitenkin lisätty kierrettä: vastaajia pyydetään ottamaan kantaa kahdella tavalla:

• Miten suhtautuisit, jos kuvattu ratkaisu toteutetaan?
• Miten suhtautuisit, jos kuvattua ratkaisua ei toteuteta?

Kumpaankin kysymykseen on tarjolla seuraava vastausasteikko:

• Pidän siitä
• Odotan asian olevan niin
• Suhtaudun neutraalisti
• En pidä siitä, mutta voin hyväksyä sen
• En pidä sitä

Vastaaja ei siis voi vain tykätä kaikesta mukavasta ja kivasta, vaan voi antaa myös vastaääniä, jos siltä tuntuu. Ja vaikka vastaaja samaan aikaan voisikin ilmoittaa ristiriitaisesti sekä pitävänsä ratkaisun toteuttamisesta että siitä, että sitä ei toteuteta, Kano-malli kyseenalaistaa tällaisen tuloksen.

Kano-mallissa kullekin ominaisuudelle muodostetaan näiden kahden eri vastauksen yhteispisteytys seuraavanlaisen luokittelun avulla:

• Odottamattomat: Luo tyytyväisyyttä, mutta ei aiheuta negatiivisia reaktioita, mikäli ominaisuutta ei toteuteta – asiakas ei suoranaisesti odota näitä ominaisuuksia. Jos tällaisia ominaisuuksia tuodaan sovellukseen, asiakastyytyväisyys kasvaa.
• Vaaditut: Asiakas ei välttämättä erikseen kuvaile näitä tarpeiksi, sillä niiden pakollisuutta pidetään usein niin ilmeisenä. Niiden puuttuminen tuottaa tyytymättömyyttä.
• Neutraalit: Nimensä mukaisesti ovat ominaisuuksina yhdentekeviä, näiden toteutuminen tai toteutumatta jääminen ei tuota sen enempää tyytyväisyyttä kuin tyytymättömyyttäkään.
• Odotetut: Odotetut ominaisuudet ovat ideologialtaan selkeästi ”mitä enemmän, sitä parempi” -tyyppisiä ominaisuuksia. Asiakas osaa odottaa näitä ominaisuuksia.
• Käänteiset: Ominaisuus, jonka olemassaolo laskee asiakastyytyväisyyttä. Ovat harvinaisia, mutta niitäkin saattaa löytyä palvelusta.
• Kyseenalaiset: Vastausvirheistä johtuvat tulokset, esim. asiakas pitää siitä, että ominaisuus on olemassa ja samalla myös siitä, ettei ominaisuutta sovelluksesta löydy.

Mitä kysyimme ja mitä vastattiin

Kymmenistä mahdollisista kehitysideoista valittiin kyselyyn seuraavat kymmenen:

• Käyttöoikeudet annetaan kohdennetusti sisältöön, ei koko organisaation tasolla
• Kommentointipyyntöjen otsikoiden ja tietojen näkyminen kaikille
• Kommentit-työkalun kommenttien näkyminen ja niihin annettujen vastausten näkyminen muillekin kuin kommentoijille
• Avataan kommentointikierrokset avoimiksi kaikille
• Suositellut tietosisällöt listauksiin ylimmäksi ja kuvauksiin jokin merkki siitä, että kyseessä on "suositus"
• Suosituimmat tietosisällöt nostetaan listauksissa ylimmäksi
• Lisätään Tietomallit-työkaluun YAML-tuki
• Tilatietoihin (status-tieto) lisää vaihtoehtoja
• Piilotetaan korvatut ja käytöstä poistetut koodistot listausnäkymästä
• Rajapinnan muutostietopalvelu

Linkki kyselyyn lähetettiin 88 Yhteentoimivuusalustan pääkäyttäjälle tai muuten alustan kanssa tekemisissä olevalle henkilölle. Lisäksi kyselyä mainostettiin LinkedInissä ja Slackissä. Vastauksia saatiin yhteensä 40 kappaletta ja vastauksien jakautuminen näkyy kuvassa 1. Kolmisenkymmentä vastausta riittää antamaan Kano-kyselyssä tilastollisesti merkitsevän tuloksen, joten saimme vastauksia siis riittävästi.

Kaikki vastaajat eivät vastanneet kaikkiin kysymyksiin, minkä vuoksi niiden palkit ovat kuvaajassa eri pituisia. Kyseenalaisia (eli virheellisiä) vastauksia ei tullut lainkaan, joten se vaihtoehto jätettiin kuvaajasta pois.

Kuva 1. Kano-kyselyn vastausten jakautuminen eri luokkiin.

Kysymykset olivat laajuudeltaan erilaisia: esimerkiksi ensimmäinen kysymys oli yksittäinen muokkausoikeuksia koskeva kysymys, jolle ei esitetty muita vaihtoehtoja. Sen sijaan kysymyksissä 2-4 oli kyse samasta työkalusta ja samasta asiasta: kuinka laajasti Kommentit-työkalun tietoja voidaan avata myös ulkopuolisten tahojen nähtäville.

Kuvasta 1 näkyy, että useimmille käyttäjille ehdotetut ominaisuudet tai toiminnot olivat enimmäkseen neutraaleja. Esimerkiksi kysymys 7, Tietomallit-työkaluun YAML-tuki, oli useimpien kannalta neutraali – ei herätä intohimoja sen enempää puolesta kuin vastaan, jos se toteutetaan tai jätetään toteuttamatta. Vain yksi käyttäjä piti sen toteuttamista välttämättömänä. Eikä ketään tämän mukaan harmittaisi, jos se toteutetaan. Kyseessä on siis ominaisuus, joka sinänsä on hyödyllinen, mutta jolle ei vielä näytä olevan laajaa tarvetta.

Myös kysymyksessä 1, Käyttöoikeudet annetaan kohdennetusti sisältöön, ei koko organisaation tasolla ja kysymyksessä 8, Tilatietoihin (status-tieto) lisää vaihtoehtoja, suurin osa vastaajista suhtautui vaihtoehtoihin neutraalisti. Näissä kuitenkin löytyi myös useita käyttäjiä, joiden mielestä ehdotetun ominaisuuden toteuttaminen olisi huono asia. Käytännössä siis tällaisen toiminnallisuuden kanssa pitää palata suunnittelupöydälle ja miettiä tarkemmin, millaisella ratkaisulla eri käyttäjäryhmien ristiriitaiset tarpeet voidaan parhaiten ratkaista.

Kano-malli nosti esiin neljä kysymystä, jotka luokiteltiin odottamattomiksi eli joissa toiminnallisuus eniten nostaisi asiakkaiden tyytyväisyyttä:

• Kommentointipyyntöjen otsikoiden ja tietojen näkyminen kaikille
• Kommentit-työkalun kommenttien näkyminen ja niihin annettujen vastausten näkyminen muillekin kuin kommentoijille.
• Piilotetaan korvatut ja käytöstä poistetut koodistot listausnäkymästä
• Rajapinnan muutostietopalvelu

Loput vaihtoehdoista olivat neutraaleja, eli kaiken kaikkiaan neutraaleja ominaisuuksia oli kuusi kappaletta.

Tehty kysely ei tietenkään ole niin sanotusti lopullinen totuus, koska se kertoo vain niistä toiminnallisuuksista, joista kysyimme. Toivomuksia on paljon enemmän kuin tähän kyselyyn otettiin. Vastauksista kuitenkin näemme, että esimerkiksi kommentointipyyntöjen otsikoiden näkyminen kaikille olisi monien mielestä tarpeellinen ominaisuus. Siksi sille kannattaisi työlistalla antaa korkea prioriteetti. Sen sijaan muiden tietojen avaamisessa pitää vielä määritellä toteutusvaihtoehdot tarkemmin käyttäjien kanssa.

Kano-malli sopiikin ehkä parhaiten siihen, että sen avulla haarukoidaan tärkeimmiksi katsotut kehitysideat, joita sitten määritellään tarkemmin asiakkaiden kanssa työpajoissa.