Katsaus tuotevertailuun teknisestä näkökulmasta

Kesän helteet ovat takana ja Apotti-hankkeen pyörät ovat pyörineet jo joitain viikkoja täydellä vauhdilla. Niin hanketoimiston kuin hankintaan osallistuvien käyttäjäorganisaatioidenkin asiantuntijat työskentelevät hankinnan seuraavan vaiheen kimpussa. Käynnissä on hankittavan kokonaisuuden määrittelevien vaatimuslistojen tarkentamista ja toisen vaiheen tuotevertailujen toteutussuunnitelmien viimeistelyä. Näin syksyn kynnyksellä on hyvä hetki luoda katsaus kuluneen vuoden tapahtumiin myös hieman IT-teknisemmästä näkökulmasta.

IT-ammattilaisen silmin katsottuna hankkeen kulunut vuosi antaa paljon aihetta tyytyväisyyteen. Erityisesti tuotteen toiminnallisuuden ja kyvykkyyden arviointi käyttäjätarinoiden avulla on osoittautunut tehokkaaksi ja paljon käyttökelpoista informaatiota tuottavaksi tavaksi arvioida sitä, kuinka hyvin tarjottavat ohjelmistokokonaisuudet toimivat omassa kotimaisessa käyttöympäristössämme.

Hankkeessa käytetty käyttäjätarina-menetelmä (User Stories) on 1990-luvun lopulla kehitetty tekniikka, joka on ainakin kaikille ketterillä menetelmillä ohjelmistoja rakentaneille IT-ammattilaisille tuttu käsite. Pohjimmiltaan kyse on siitä, että ohjelmiston haluttuja toimintoja kuvataan aluksi normaalilla ihmiskielellä ja käyttäjän näkökulmasta. Käyttäjätarina-menetelmän vahvuutena ketterissä ohjelmistoprojekteissa onkin juuri iteratiivisuuden ja paloittain kehittämisen tukeminen. Perinteinen malli olisi laatia yksityiskohtainen toiminnallinen määritys, joka sitten raskaalla ns. vesiputousmallilla kuljetetaan sitkeästi kohti kerran määriteltyä tavoitetta.

Tarinoiden ilmaisuvoima ja merkitys korostuvat

Kun puhtaan ohjelmistokehitysprojektin sijaan tehdään valmisohjelmistoista muodostuvan kokonaisuuden valintaa, poikkeaa käyttäjätarinoiden käyttötapa ja merkitys totutusta perusmuodostaan hieman. Tuotevalintaa tehtäessä käyttäjätarinat kuvataan edelleen ihmiskielellä ja käyttäjän näkökulmasta, mutta ne ovat usein merkittävästi alkuperäistä ohjelmistokehitys-serkkuaan yksityiskohtaisempia ja kuvaavampia. Lisäksi näiden käyttäjätarinoiden ilmaisuvoima ja merkitys korostuvat tässä käytössä sitä enemmän, mitä monimutkaisempi ja monisävyisempi toimintaympäristö on kyseessä.

Siinä missä 1980-luvun perinteinen viisaus kuului: ”Aluksi kun vaan kunnolla määritellään ja sitten sen mukaan rakennetaan, niin hyvä tulee.”, on nykykäsitys tehokkaista menetelmistä toimivan IT-ratkaisun kokoamiseksi muuttunut radikaalisti.

Monilla toimialoilla, niin teollisessa tuotannossa, vakuutus- ja rahoitusalalla kuin julkishallinnossakin on jouduttu liian monesti toteamaan, että nykymaailmassa jo melko yksinkertaisissakin toimintaympäristöissä todellisuus ja toiminnan tarpeet tiedon käsittelylle ovat niin monimutkaisia, että ohjelmistojen toiminnan yksityiskohtainen kirjaaminen kertaheitolla kaikenkattavaksi vaatimusmäärittelyksi on kasvanut lähes mahdottomaksi tehtäväksi. Tämä pitää erityisesti paikkansa terveydenhuollon ja sosiaalihuollon alueilla, joissa tiukasti määriteltyjen selkeiden ydinprosessien lisäksi mukana kokonaisuudessa on aina suuri määrä dynaamisesti muuttuvia erittäin monimutkaisia ja toisiinsa monitasoisesti kytkeytyviä täysin välttämättömiä prosesseja.

Moottoripyöräonnettomuudesta toimeentulotukipäätökseen

Apotin arviointimenetelmä on tähän mennessä tarkastellut tuotteita ensisijaisesti ammattilaiskäyttäjän näkökulmasta, vaikka kansalaiselle tarjottavia sähköisen asioinnin rajapintojakaan ei ole unohdettu. Vertailutilaisuuksiin huolellisesti ennakkoon valmistautuneet toimittajaehdokkaat tekivät kevään aikana tinkimätöntä ja hyvää työtä esittäessään käytännön tasolla, miten heidän ratkaisunsa mahdollistavat toimimisen monissa eri käyttötilanteissa.

Käsiteltävät aihepiirit ja demonstraation rytmi vaihtelivat laidasta laitaan. Välillä käytiin läpi tyypillisiä sosiaalihuollon ja terveydenhuollon käyttötapauksia näiden alojen ammattilaisten voimin; välillä taas perehdyttiin yksityiskohtaisesti ohjelmiston muokattavuuden ja hallittavuuden ominaisuuksiin IT-asiantuntijoiden ja hankintaorganisaation ulkopuolisten akateemisten asiantuntijoiden voimin.

Käyttäjätarinoiden skenaarioissa sukellettiin niin moottoripyörällä kaatuneen monivammapotilaan hoitopolkuun päivystyksestä teho-osastolle kuin tutkittiin aikuissosiaalityön toimeentulotukipäätöksen käytön joustavuutta. Tilanteita kuvailtiin kymmenien sivujen mittaisissa yksityiskohtaisissa skenaariokuvauksissa, joiden vaatimusten täyttymistä arvioitiin demonstraatiotilaisuuksissa esitetyn toiminnan perusteella. Lisäksi mukautettavuusarvioinnissa tarkasteltiin sitä, miten eri ohjelmistot sallivat ulkoasunsa ja toimintalogiikkansa muuttamisen ja hienosäätämisen niin konfiguraatiotyökaluilla kuin erilaisilla makrokielilläkin.

Perinteinen vaatimusmäärittelykuvaus kulkee rinnalla

Käyttäjätarinoiden lisäksi ja niiden rinnalla hankkeessa on määritelty luonnollisesi myös perinteisempi vaatimusmäärittelykokonaisuus, jonka määräämissä puitteissa hankittavan kokonaisuuden pitää pystyä toimimaan. Monet osa-alueet, erityisesti lukuisat tuotteen teknisiin ominaisuuksiin ja teknologiaan liittyvät yksityiskohdat, on edelleen mielekästä määritellä yksityiskohtaisesti perinteisten vaatimusmäärittelykuvausten avulla. Tällä alueella tärkeiden yksityiskohtien lista on pitkä, tietoturvavaatimuksista erilaisiin teknisiin minimivasteaikavaatimuksiin. Yhdessä muiden tuotevalintaan liittyvien vaatimusten kanssa ne muodostavat tehokkaan menetelmän oikeiden tuotevalintojen tekemiseksi.

Kaiken kaikkiaan kevään tuotevertailuvaihe on vakuuttanut ainakin allekirjoittaneen siitä, että se on erittäin tehokas tapa päästä näkemään eri tuotteiden vahvuudet ja heikkoudet. Ja näkemään ne niin lähellä arkikäyttöä olevassa tilanteessa kuin mahdollista ilman itse järjestelmän hankkimista.

Lisäksi tuotevertailu on ollut hyvin opettavaista: Nyt tämäkin vanha yliopistosairaalan tietohallintojohtaja ymmärtää ensimmäistä kertaa, miksi vaikkapa pleuradreenin kirjausten ”selkeä näkyminen” ei olekaan traumakirurgin näkökulmasta lainkaan sama asia kuin IT-ammattilainen saattaisi luulla. Ja joitain satoja muita vastaavia pikkuseikkoja…

Jari Renko
tekninen kehitysjohtaja