Table of contents
Open Table of contents
Intro
I wrote a guest article to Aleksi Kopponen’s blog about agility and ecosystems to replace monolithic projects and systems (in Finnish).
Ketterä ekosysteemi
Tietojärjestelmiä voidaan kehittää monella tavalla. Julkisuuteen tietojärjestelmähankkeet päätyvät usein siinä vaiheessa, kun jotain on mennyt jo pieleen. Pääviesti tässä vaiheessa julistaa, kuinka on jälleen kerran tuhlattu veronmaksajien rahoja monta miljoonaa euroa ilman, että mitään valmista on saatu aikaan. Hankkeet on myös usein mammuttimaisen suuria ja puhutaan useiden vuosien kehityshankkeista, ennen kuin tuloksia päästään hyödyntämään. Hankkeiden hyödyt katoavat byrokratian rattaisiin vaikka rahaa palaa koko ajan. Kuulostaako tutulta?
Edellä kuvattu sopii valitettavan usein niin julkisiin kuin yksityisenkin sektorin tietojärjestelmähankkeisiin jotka toteutetaan perinteisin menetelmin. Ensin tehdään mittava määrittely- ja suunnittelutyö, jossa parhaimmillaan järjestelmän tulevat käyttäjätkin pääsevät kertomaan toiveensa. Sitten alkaa kehitystyö toteuttajien kammioissa, joista tullaan aikanaan ulos lopputuloksen kanssa, jos tullaan. Lopussa ei useinkaan kiitosta kuulla, vaan alkaa syyllisten etsintä, koska aikoja sitten tehty vaatimusmäärittely ja sen perusteella tehty toteutus ei enää vastaa ympäröivää maailmaa ja liiketoiminnan tai viranomaisen tarpeita.
Onneksi asioita voidaan tehdä myös toisin, hyödyntäen ketteryyttä projektivaiheessa ja toisenlaista tavoiteasetantaa.
Tavoitteeksi ekosysteemi
Mammuttihankkeissa usein on tavoitteena ottaa käyttöön massiivinen maailman pelastava tietojärjestelmä, joka kattaa kaikki mahdolliset tarpeet. Tämä johtaa väistämättä massiivisiin vaatimusmäärittelyihin ja muihin määrittelydokumentteihin, joiden ajantasalla pitäminen on käytännössä mahdoton tehtävä. Hanke siis epäonnistuu jo määrittelyvaiheessa, loppu hankkeesta on vain väistämättömän lopputuloksen siirtämistä ja rahan tuhlausta.
Vaihtoehtona yhdelle massiiviselle järjestelmällä voisi olla ekosysteemi, joka koostuu pienemmistä komponenteista tai palasista, joista jokainen toteuttaa yhden tarpeen. Kun alussa luodaan niin kutsuttu iso kuva, jossa kuvataan kokonaisuus korkealta katsottuna menemättä yksityiskohtiin, voidaan näitä komponentteja alkaa toteuttamaan suhteellisen itsenäisesti. Yhteisesti on tarpeen määritellä ja sopia komponenttien keskinäisistä rooleista ja kommunikaatiotavoista, joilla komponentit voivat keskustella ja vaihtaa tietoa keskenään. Hallintaa siis tarvitaan edelleen, että esimerkiksi samaa toiminnallisuutta ei aleta toteuttaa kahdessa eri komponentissa.
Vaihtoehtona yhdelle massiiviselle järjestelmällä voisi olla ekosysteemi, joka koostuu pienemmistä komponenteista tai palasista, joista jokainen toteuttaa yhden tarpeen.
Koska jokainen komponentti voidaan periaatteessa toteuttaa itsenäisesti sovittuja reunaehtoja noudattaen, on työn hajauttaminen huomattavasti helpompaa ja etenkin tulokset tulevat näkyville nopeammin. Ekosysteemiajattelu vähentää myös huomattavasti toimittajariskiä, koska tekemistä voidaan hajauttaa useille toimittajille, se mahdollistaa kilpailuttamisen pienemmissä osissa ja toisaalta antaa pienemmille toimijoille realistisia mahdollisuuksia osallistua tarjouskilpailuihin.
Keskiössä käyttäjät
Edellä hahmoteltu ekosysteemimalli siis mahdollistaa pienempien, jo sinällään käyttökelpoisten osatoteutusten tekemisen. Tällainen osatoteutus voisi olla esimerkiksi terveydenhuollon tarvitsema ajanvaraustoiminnallisuus.
Lopputulosta määriteltäessä ja suunniteltaessa keskiössä pitäisi aina, siis aina, olla palvelun loppukäyttäjät. Loppukäyttäjät ymmärtävät parhaiten, mitä he tarvitsevat työssään ja mikä heitä eniten siinä auttaisi. Muitakin vaatimuksia toteutukselle varmasti tulee esimerkiksi lainsäädännön muodossa, mutta tärkeintä pitäisi olla miellyttävä ja sujuva käyttäjäkokemus. Kun loppukäyttäjät otetaan mukaan projektiin ja ylläpidetään jatkuvaa vuoropuhelua, vältytään suurilta yllätyksiltä lopussa.
Lopputulosta määriteltäessä ja suunniteltaessa keskiössä pitäisi aina, siis aina, olla palvelun loppukäyttäjät.
Ajanvarausesimerkissä loppukäyttäjiä ovat esimerkiksi potilas, lääkäri sekä muu hoitohenkilökunta.
Ketteryydellä nopeampia hyötyjä ja läpinäkyvyyttä
Menemättä syvälle ketterään ohjelmistokehitykseen ja sen vaihtoehtoisiin filosofioihin ja toteutusmalleihin yleistäen voidaan sanoa, että ketteryydellä päästään usein nopeammin lopputulokseen. Jatkuva vuoropuhelu ja läpinäkyvyys tekemisessä antavat sidosryhmille hyvän näkyvyyden projektin etenemiseen, jolloin tarvittaessa suunnan korjaaminen onnistuu pienemmin liikkein.
Aina ketteräkään kehitys ei siis kulje haluttuun suuntaan ja esimerkiksi tekeillä oleva komponentti muuttuu pahimmillaan tarpeettomaksi. Ketterän työskentelymallin ja yksittäisen projektin rajatun laajuuden ansiosta hukkaan ei kuitenkaan mene valtavaa työmäärää.
Ketterien menetelmien käyttö vaatii perehtyneitä ja kokeneita asiantuntijoita siinä missä muutkin projektinhallintamenetelmät. Kun projektiin saadaan mukaan muutamia kokeneita henkilöitä, vaivat he jalkauttaa työskentelymallia eteenpäin muulle projektiryhmälle.
Ketterien menetelmien käyttö vaatii perehtyneitä ja kokeneita asiantuntijoita siinä missä muutkin projektinhallintamenetelmät.
Niin, ketterä kehitys ei siis tarkoita sitä, että syöksytään suoraan tekemään ilman määrittelyä ja suunnittelua, eikä lopputuloksesta ole syntynyt projektin aikana mitään dokumentaatiota ylläpitovaiheen tarpeisiin. Kaikkea tätä tehdään, mutta osin limittäin toteutuksen ja testauksen kanssa, vain merkittävästi joustavammin ja läpinäkyvämmin.