Miten kehitetään tietojärjestelmiä järkevästi -
kokemuksia Jyväskylän yliopistosta

Rikupekka Oksanen 19.5.2016

Tai: miten ei kehitetä tietojärjestelmiä järkevästi

Rikupekka Oksanen

• Jyväskylän yliopisto, IT-palvelut
• 15+ vuotta www-pohjaisten tietojärjestelmien kehittämistä
• Virtuaaliyliopistohanke
• Tietohallintokeskus
• IT-palvelut
• Kehittäjä, tiiminvetäjä

Jyväskylän yliopisto

• 15 000 opiskelijaa
• +13 000 opiskelijaa Avoin yliopisto
• 2 700 henkilökuntaa
• Heterogeeninen ympäristö

Tietojärjestelmät JY:ssä

Yliopistolla useita tapoja hankkia/kehittää tietojärjestelmiä:

• Hankitaan ulkoa (esim. hallinnolliset järjestelmät, levyjärjestelmät)
• Kehitetään itse (esim. opintohallinnon ja opetuksen tietojärjestelmät, oppimisympäristöt, videojulkaisu)
• Näiden kombinaatio (esim. verkkomaksamisen palvelun integrointi kassajärjestelmään ja SAPiin, rajapinnat kansallisiin järjestelmiin)

Kehittämispalvelut

• n. 30 henkeä, joista n. 15 kehittäjiä, loput asiakastukea tai suunnittelijoita
• Palveluiden ylläpitoa, tukea ja jatkokehitystä mm. Korppi-opintotietojärjestelmä, www-palvelut, oppimisympäristöt (Optima, Moodle, Koppa), opintohallinnon järjestelmät, tutkimustietojärjestelmät, tilastojärjestelmät, verkkomaksaminen, videopalvelut, jne.

Kehittämistapa

• Oma palveluinfra - mikropalveluarkkitehtuuri
• Docker, virtualisointi, automatisointi
• Ketteryys
• Testaus (yksikkö, integraatio, funktionaalinen)
• Jatkuva toimittaminen
• Paljon Open Source -tuotteita ja työkaluja - ei lisenssimaksuja, ei vendor-lock-in, sen kun valitsee hyllystä

Open Source

Ydinteesit

1. Tilaaja-tuottaja: Asiakas ei usein tiedä mitä haluaa, mutta tietää mitä ei halua
    
2. Kehitetään prosessia, ei vain mallinneta sitä
    
3. Ensimmäinen vaihe tietojärjestelmäprojektissa on käyttöönotto
    
4. Projektit ja hankkeet loppuvat, mutta tietojärjestelmän käyttö jatkuu

Loppukäyttäjä mukaan

• Jos ollaan tekemässä esim. uutta opintosuoritusten rekisterijärjestelmää opintosihteerien käyttöön, niin tarvitaan ainakin yksi aktiivinen opintosihteeri, jota uudistus kiinnostaa ja joka tietää miten suoritusten merkkaaminen tapahtuu. Joku, jonka kädet ovat syvällä savessa, joka oikeasti käyttää tulevaa järjestelmää ja tietää nykyisen menettelytavan.
• Lisäksi tarvitaan mandaatti eli pomon lupa/rahoitus

Kuuntele asiakasta, ajatuksella

• Yliopiston kehityksen erityispiirre(?): sisäinen asiakas
   
• Ts. Raha menee taskusta toiseen, mutta samasta pussista.
   
• Kehittäjänä ei kannata sanoa kaikkeen, että ok, tehdään, vaikka se maksaakin teille rahaa. Pitää ajatella kokonaishyötyä.

Esimerkki - kehitystarve

• Aikanaan erään järjestelmän kohdalla tilaaja halusi jatkokehittää järjestelmään jonkun sähköpostia vastaavan toiminnon, jolla opiskelijat voisivat ottaa yhtettä opettajaan kysyäkseen, menikö tehtävänpalautus perille.

?

?

?

?

Esimerkki - kehitystarve

• Kun asiaa kuitenkin hetki pohdittiin, selvisi varsinainen ongelma: opiskelija oli epävarma oliko tehtävänpalautus mennyt perille.

• Asiakkaan pyytämä ominaisuus olisi ollut vain apu vaivaan, mutta ei ratkaisu ongelmaan.
   
• Joten mietittiin hetki

Ratkaisu

• Ratkaisu oli yksinkertainen: massiivinen teksti "PALAUTUS ONNISTUI" ja vielä massiivisempi, vihreä peukku ylös.
• Ratkaisu oli sekä yksinkertaisempi, halvempi ja parempi kuin tilaajan ehdottama sähköpostitoiminnallisuus

Prosesseja pyritään mallintamaan ja kehittämään, jotta prosessin vaikutusalueen laatua, tehokkuutta ja tuottavuutta voitaisiin ohjata ja parantaa.

Prosessin määritelmä

Prosesseja pyritään mallintamaan ja kehittämään, jotta laatua ja tehokkuutta...

Mallinnetaan kyllä, mutta ei kehitetä!

Prosessin määritelmä

Vanha viidakon sanonta:
Älkää toteuttako vanhaa prosessia orjallisesti!

Prosessin kehittäminen

• Tietojärjestelmäuudistus on hyvä (joskus ainoa!) vipuvarsi ongelmallisen ja kivikautisen prosessin uudistamiseksi.

Prosessi!

Monimutkainen prosessi johtaa monimutkaiseen tietojärjestelmään

Prosessi ja järjestelmä

• Ennenkaikkea uusi tietojärjestelmä pitää kehittää joustavasti niin, että
  • Herättää pohtimaan nykyisen prosessin järkevyyttä
  • Se tehostaa olemassa olevan usein toistuvan toiminnan tekemistä
  • Järjestelmä sallii helposti jatkuvan kehityksen samalla kun prosessiakin hiotaan paremmaksi

Fakta: on täysin mahdotonta suunnitella monimutkaista (tai edes yksinkertaista) tietojärjestelmää täydellisesti etukäteen. 

Tietojärjestelmäprojekti 1986

• Ennen vanhaan, (ja huolestuttavalla tavalla vielä nykyäänkin?), tietojärjestelmäprojektit etenevät massiivisen määrittelyn ja ennakkosuunnittelun kautta kehitysvaiheeseen ja testaukseen ja lopulta hyvässä lykyssä muutamaan otteeseen siirrettyyn käyttöönottoon, jossa huomataan että a.) järjestelmä ei toimi kunnolla ja b.) siitä puuttuu ominaisuuksia.

Järjestlmä on epätäydellinen

Pitää hyväksyä, että kun järjestelmä tulee käyttöön, se on epätäydellinen.

1. vaihe: käyttöönotto

• Järjestelmä on valmis käyttöönotettavaksi, kun se tekee yhdenkin (1) asian niin, että siitä on hyötyä tilaajalle.
• Esimerkki: Avoimen Koppa (oppimisympäristö) otettiin käyttöön kun sinne pystyi syöttää opetussisältöä, vaikka sieltä puuttui vielä opiskelijakirjautuminen ja tehtävien palautus.

Hyödyt ohjaamaan kehitystä

• Älä kerää asiakkaalta ominaisuuslistaa (feature) vaan miettikää yhdessä niitä liiketoimintahyötyjä tai arvoja mitä järjestelmällä ja mahdollisella prosessin uudistamisella voidaan saada.
   
• Hyödyt ohjaavat kehitystä paremmin kuin ominaisuudet

"Vain testissä"

• Eräs pidempään kestänyt tietojärjestelmäkehitys, jossa saatiin lopulta masinoitua laaja testaus 30 henkilölle
• Koska järjestelmä oli vain testissä, koehenkilöiden sitoutuminen oli vaillinaista, ja testauksen tulokset eivät olleet niin hyödyllisiä kuin asiakas olisi toivonut.
• Työnantajaltaltalkaan ei välttämättä heru aikaa testaukseen osallistumiseen

Todellisuus näyttää tien

• Vastaavasti on tehty onnistuneita kehityshankkeita, joissa järjestelmä on otettu käyttöön varhaisessa vaiheessa, pienellä määrällä ominaisuuksia.
   
• Tuotantokäyttö on näyttänyt, että jotkut ennakkoon tärkeäksi kuvitellut ominaisuudet ovat olleet aivan turhia ja toisaalta aito käyttäjäpalaute on ohjannut kehitystä oikeaan suuntaan.

1. vaihe: käyttöönotto

• Koko kehitys pitäsi ajatella näin:
  • 0. visio järjestelmästä: mikä on ydintoiminto
  • 1. käyttöönotto yhdellä hyödyllisellä ominaisuudella
  • 2. seuraavaksi tärkeimmän ominaisuuden kehitys ja käyttöönotto
  • 3. seuraavaksi tärkeimmän ominaisuuden kehitys
  • 4. seuraavaksi tärkeimmän ominaisuuden kehitys jne.

Open Source jeejee

• Avoimen lähdekoodin hyödyt: voit ottaa suoraan tuotantoon valmiita ohjelmistoja, komponentteja, työkaluja
• Esimerkki: Ulkoasun räätälöinnin voi tehdä myöhemmin, jos käyttäjä pääsevät jo syöttämään sisältöä ja kokeilemaan toimintoja oikeasti.

Jatkuva toimittaminen

• Käyttäjiltä saatu palaute tuotannossa olevasta järjestelmästä on ihan toista luokkaa kuin pelkkien rautalankamallien näyttäminen saatika suunnitelmien loputon pyörittäminen työryhmissä.
• Nykyaikana voidaan rakentaa järjestelmät niin, että niiden päivittämiseksi ei tarvita neljän päivän huoltokatkoa.
• Päivitys on nopeaa ja parhaassa tapauksessa tehty niin, etteivät käyttäjät edes huomaa järjestelmän käyneen alhaalla.  

Projektit

• "Kehitysprojekti kestää vuoden". No sehän on hienoa. Mitäs sitten seuraavana vuonna? Tai sitä seuraavana?
   
• Projekti on tyhmä asia. Sillä on alku ja loppu ja tiedossa olevat rajat (jotka todellisuudessa eivät ole tiedossa).
   
• Hyvä tietojärjestelmä on käytössä lukuisia vuosia, ja alkaa tuottaa hyötyä varhaisessa vaiheessa. Mihin tarvitaan projektin rajoituksia?

Epäonnistunut projekti?

• Jos ajatellaan kehitysprojektia,
  • joka suunniteltiin kestävän vuoden,
  • mutta kestikin kaksi,
  • ja siitä vihdoin tuotantoon mennyt sovellus vaatii vielä jatkokehitystä kymmenen vuotta, niin onko kyse epäonnistumisesta?

Onnistunut projekti

• Ei. Kyseessä oli onnistuminen. Kymmenen vuotta hyötyjä käytössä olevasta tietojärjestelmästä on hieno juttu!

Projektit ja estimointi

• Toinen projekteihin liittyvä ongelma on työmääräarviot. Kuinka usein ne pitävät paikkansa?
   
• Taloja on rakennettu tuhansia vuosia, niiden rakentamista voi arvioda
• Tietojärjestelmiä on kehitetty noin 50 vuotta. Näitä ei voi verrata.
   
• Jokainen tietojärjestelmä on erilainen, jokainen tekijä on erilainen, jokainen ominaisuus on erilainen.

Estimointi

• Arvio epäonnistuu jos työhön meneekin enemmän aikaa kuin arvioitiin. Arvio epäonnistuu, jos työhän menee vähemmän aikaa kuin arvioitiin.
   
• Ei pitäisi kysyä: "Milloin se on valmis?"
  Vaan pitäisi kysyä "Milloin se alkaa tuottaa hyötyjä?"
   - Alan Kelly

Priorisointi

• Estimointia tärkeämpää onkin priorisointi - mikä ominaisuus toteutetaan seuraavaksi?

Elinkaari

• Kannattaa miettiä projektien sijaan järjestelmän elinkaarta
• Kuka ylläpitää/tukee/jatkokehittää järjestelmää sen jälkeen kun projekti loppuu?
• Ongelma yliopistolla: rahaa saadaan kehitysprojekteihin ja uudistushankkeisiin, ei niinkään palveluiden ylläpitoon, tukeen ja kehitykseen

Elinkaari - esimerkkejä

• Korppi-opintotietojärjesytelmä - alunperin IT-tiedekunnassa opiskelijaprojektina kehitetty (n. 2000) - sittemmin ylläpitoon ja jatkokehitykseen Tietohallintokeskukseen ja IT-palveluihin
• Moniviestin videojulkaisu: 2003 (paljon ennen YouTubea) ja edelleen käytössä (tiettyjä etuja, esim. videoiden piilotus, automaattinen tilatallennus ja kuvauspalveluprosessi)
• Avoimen yliopiston Koppa - alkuperäiseen (2010) lisätty mm. ilmoittautumismaksujärjestelmä ja etätenttimahdollisuus

Yhteenveto

• Tarve, selkeä asiakas ja tuottaja
• Kuuntele asiakasta aivoilla (ei lompsalla tai sydämellä)
• Muokkaa prosessia, älä vain mallinna
• Käyttöönotto - ei Big Bang -mallisesti
• Projektien sijaan elinkaari
• Priorisointi > estimointi

PS

• Olemme kiinnittäneet erityistä huomiota kyberturvallisuuteen
• Vältämme kriisejä, mutta viestimme paljon
• Katsomme avoimin mielin digitaaliseen tulevaisuuteen.

Kiitos!

rioksane@jyu.fi

@rikupekka

tech.blog.jyu.fi

plone-support.blog.jyu.fi

staff.jyu.fi/Members/rioksane