...
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. Kymmenestä kysymyksestä Kano-malli nosti esiin neljä, jotka luokiteltiin odottamattomiksi eli joissa toiminnallisuus eniten nostaisi asiakkaiden tyytyväisyyttä:
- (2) Kommentointipyyntöjen otsikoiden ja tietojen näkyminen kaikille
- (3) Kommentit-työkalun kommenttien näkyminen ja niihin annettujen vastausten näkyminen muillekin kuin kommentoijille.
- (9) Piilotetaan korvatut ja käytöstä poistetut koodistot listausnäkymästä
- (10) Rajapinnan muutostietopalvelu
Loput vaihtoehdoista olivat neutraaleja, eli kaiken kaikkiaan neutraaleja ominaisuuksia oli kuusi kappaletta.
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 harmittaisisinänsä toki harmita, jos se tämä ominaisuus toteutetaan. Kyseessä on siis ominaisuus, joka sinänsä on hyödyllinen, mutta jolle ei vielä näytä olevan laajaa tarvetta. Koska työkalu jo tukee OpenAPI-formaattia, josta käyttäjä voi konvertoida YAML-muodon, YAML-tuen toteutus saa työlistalla alhaisen prioriteetin.
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.
Vaikka lisääntynyt työmäärä voi pienillä tietomäärillä olla kohtuullinen, on myös otettava huomioon, mitä muutos vaikuttaa, kun hallinnoitavia sisältöjä olisi paljon. 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. Toiminnallisuuden muutos vaikuttaisi monien käyttäjien prosesseihin.
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
Kommentointi-toimintojen kehittäminen (kysymykset 2 - 4) sai siis suosiota ja siten nousee näistä teemoista toteutuslistan kärkeen. Kaikkien toivottujen ominaisuuksien muuttamista valinnaisiksi ja kommentointikierroksen tekijän päätettäväksi ei kuitenkaan pysty tekemään yhdellä kertaa, joten tässäkin pitää suunnitella käyttäjien kanssa heitä parhaiten palveleva vaiheistus.
Suositeltujen (kysymys 5) ja suosittujen eli eniten viitattujen (kysymys 6) tietosisältöjen korostamisesta on ollut paljon keskustelua aiempina vuosina, mutta tällä vastaajajoukolla suurin osa suhtautui näihin ominaisuuksiin neutraalisti. Tulosten perusteella ihmisten tekemää suosittelua arvostetaan enemmän kuin sovelluksen tekemiä automaattisia nostoja.
Tosin hyvin moni vastaaja kysyi avoimessa palautteessaan, mikä tällainen asiantuntijaraati sitten olisi ja kuka sen valitsee. Tässä tapauksessa siis pitää ensin hahmotella hallintamalli ja asiantuntijaraadin rooli ja vaatimukset. Vasta kun näistä on yhteinen näkemys, voidaan rakentaa toiminnallisuus, joka tukee hallintamallia.
Korvattujen ja käytöstä poistettujen koodistojen piilottaminen listausnäkymästä (kysymys 9) sai paljon kannatusta. Koska vanhojakin koodistoja tarvitaan, niitä ei ole tarkoitus kokonaan poistaa, vaan ajatuksena on, että listaussivu jatkossa oletusarvoisesti näyttää vain aktiivisessa käytössä olevat koodistot. Ja jos käyttäjä haluaa nähdä kaikki koodistot, ne voi saada näkyvilleen muuttamalla listauksen asetuksia (esimerkiksi: aktiiviset -> kaikki). Tällä hetkellä käytöstä poistuneita koodistoja ei vielä ole kovin paljon, mutta ajan myötä niiden määrä kasvaa. Oletettavasti käyttäjiä turhauttaa pyöritellä pitkiä koodistolistauksia, jos suuri osa niistä on jo korvattu uudemmilla. Jos tämä suodatus pystytään toteuttamaan kohtuullisen pienellä vaivalla, se kannattaa tehdä.
Toteutuksessa on otettava huomioon, että vastaava suodatustoiminnallisuus on käytössä kaikissa työkaluissa, joten alasvetovalikon tekstien pitää olla sellaisia, että ne soveltuvat koodistojen lisäksi myös sanastoille, tietomalleille ja kommentointikierroksille. Ja käyttäjillä pitää olla helppo tapa vaihtaa suodatusta haluamakseen.
Rajapinnan muutostietopalvelu (kysymys 10) sai suurta suosiota, mutta vapaassa palautteessa todettiin, että jos tiedon tietosisällön muutoksesta saa vasta rajapinnassa, se tulee liian myöhään. Olennaisempaa olisi saada viesti muutoksista ennakkoon niin, että rajapinnan käyttäjä voi omalta osaltaan jo aiemmin varautua muutoksiin. Koska käyttäjät voivat jo nyt tilata sähköpostiinsa ilmoituksen, kun jokin alustalla jo oleva tietosisältö on muuttunut (katso seuranta- ja ilmoituspalvelu: https://wiki.dvv.fi/pages/viewpage.action?pageId=61252403), pitää teknisen rajapinnan tarpeet miettiä toisesta näkökulmasta: Kun sisällöntuottaja aikoo muuttaa tietosisältöjä, niin miten hän saa tiedon tietosisältönsä käyttäjistä, jotta voi ottaa näihin yhteyttä? Miten rajapinnassa kerrotaan sisällön päivitykset (esimerkiksi tietomallin version muutokset)? Miten ilmaistaan tekniset muutokset (esimerkiksi rajapinnan versiot)? Tässäkin tarvitaan lisäkeskusteluja käyttäjien kanssaLoput 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 Aiemmin esitettyjä 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., ja kyselymme vapaassa palautteessa saimme vielä tukun uusia. Kano-malli sopiikin ehkä parhaiten siihen, että sen avulla haarukoidaan monien vaihtoehtojen joukosta tärkeimmiksi katsotut kehitysideat, joita sitten määritellään tarkemmin asiakkaiden kanssa työpajoissa.. Näin käyttäjien kanssa pidettävissä työpajoissa voidaan keskittyä näihin helmiin, jotta kehitystyöstä saadaan suurin hyöty.
Avoimet palautteet
Avointen vastausten osuudessa saimme palautetta niin alustan teknisistä ominaisuuksista kuin yleisemmistä teemoista, kuten harmonisoinnista ja toimintamallin periaatteista.
Avoimissa vastauksissa oli esimerkiksi viety Kommentit-työkalun toiminnallisuuksiin liittyviä kysymyksiä eteenpäin mm. ehdottamalla, että kommentointipyynnön lähettäjällä pitäisi olla mahdollisuus määritellä kommentointipyyntöjen julkisuus vaihtoehdoilla: täysin julkinen, osittain julkinen tai täysin rajattu. Samaten kommenttien ja kommentoijien tietojen näkymisen pitäisi olla valittavissa oleva tieto. Tai asian voisi ratkaista niin, että kirjautuneille käyttäjille näkyy kommentoijan identiteetti, mutta anonyymeille käyttäjille ei. Myös kommentointikierroksen avaaminen ”kaikelle kansalle” voisi olla valinnainen ominaisuus.