Unelma ketterästä Apotista

Apotti-hankkeen tavoite on tärkeä, mutta esitetyt hankintamallit ja teknologiat järjettömän kalliita ja vanhanaikaisia. Mitä jos Apotti toteutettaisiin ketterästi?

Kustannusarviosta

Koko Suomen kattavaa 1,8 miljardin kustannusarviota on verrattu Mars-luotaimeen. Vaikka itse Apotti maksaa ”vain” 350–450 miljoonaa euroa, se on monen mielestä liikaa. Hankkeessa ei tehdä rakettitiedettä vaan tallennetaan, näytetään ja siirretään potilastietoja.

Järkyttävän kokoista kustannusarviota on perusteltu IT-asiantuntijayhtiö Gartnerin tutkimuksella, jonka mukaan potilastietojärjestelmän modernisointi maksaisi jopa 1,4 miljardia kutakin erillisjärjestelmää kohti ja kestäisi 10–14 vuotta. Huh!

Gartnerin tutkimus perustuu tietysti projekteille, jotka on kehitetty perinteisillä projektimenetelmillä, määrittelemällä kaikki sisältö etukäteen ilman priorisointia ja kehittämällä kokonaisuutta ”kerralla valmiiksi” kuin Iisakinkirkkoa. Ei ole uutinen, että näin hankitut ja kehitetyt järjestelmät maksavat liikaa, valmistuvat myöhässä ja ovat surkeita.

On olemassa vaihtoehto. USA:n puolustusministeriö siirtyi vuonna 2010 uuteen tapaan hankkia IT-järjestelmiä. Ketterillä menetelmillä päästään edullisempaan ja parempaan lopputulokseen jopa kolme kertaa todennäköisemmin. Ilmeisesti uusista menetelmistä ei kuitenkaan olla Apotti-hankkeessa kiinnostuneita. Kysehän on vain miljardeista.

Tilannetta voisi verrata siihen, että ryhmä sytyttää nuotiota tuhannen euron seteleillä. Koska tapa on jatkunut vuosikymmeniä, Mr. Gartner -niminen asiantuntija arvioi, että nuotion sytyttäminen maksaa 1,4 miljardia euroa. Harmi vaan, ettei herra Gartner ole huomannut, että viereisellä nuotiopaikalla käytetään sytytysnestettä ja sanomalehteä. Niillä nuotio syttyy jopa kolme kertaa todennäköisemmin, edullisemmin ja mukavammin.

Supistaisin Apotin budjetin 50-100 miljoonaan euroon (koko maan laajuisena), minimoisin sen vaatimukset ja priorisoisin vaatimukset kunnolla. Apotilla ei lennetä Kuuhun vaan pyöritetään viiden miljoonan ihmisen potilastietoja. Vertailun vuoksi Facebookissa on 200 kertaa enemmän käyttäjiä. Sadalla miljoonalla eurolla pitäisi saada niin käsittämättömän hieno järjestelmä, ettei mitään rajaa. Tällainen asenne ja osaaminen hankkeessa pitäisi olla, eikä Gartnerin muiden tuhlailulla perustelema rahan polttaminen.

Hankintamallista

Apotin hankinnassa tuntuu kilpailevan kaksi ajatusta: Perinteinen vesiputoustoteutus ja valmiin lisenssin räätälöinti.  Koska perinteisestä hankintamallista on (onneksi) negatiivisia kokemuksia, on ainoaksi mahdollisuudeksi jäänyt koko systeemin ostaminen valmiina lisenssinä, joka räätälöidään. Räätälöinti onkin ihan fiksua, jos rahalle saa vastinetta. Harmi vaan, ettei rahalla tunnu olevan mitään arvoa (viitaten edelliseen esimerkkiin rahan polttamisesta), kun kymmenien miljoonien eurojen lisenssi, joka on teknologialtaan suljettu ja valmiiksi vanhentunut, on hankintalistan kärkipäässä. Samalla menetetään arvokas tilaisuus tukea kotimaista ohjelmistoteollisuutta.

Koko sisällön etukäteen määrittelemisen sijaan (joka on tämän kokoluokan projektille joko mahdotonta tai järjetöntä) hankkisin Apotin palvelukseen osaamiseltaan sopivia ammattilaisia, jotka toteuttaisivat järjestelmän. Siis ei sisältöä, vaan ihmisiä. Uutta mallia on käytetty suomalaisessa julkishallinnossa onnistuneesti useamman vuoden ajan. Tällöin järjestelmää voitaisiin kehittää jatkuvasti, alkaen käyttäjille kriittisistä toiminnoista ja laajentaa toimintoja käyttäjien ehdoilla. Näin turhia toimintoja ei pääsisi syntymään ja käytettävyys ja laatu säilyvät korkeammalla.

Korostaisin myös kulttuurin luomista. Tämän kokoluokan hanke vaikuttaa tuhansien ihmisten työhön, jolloin sen lisensointi voisi olla ongelmallista: Ihmisten tulisi nopeasti mukautua järjestelmään ja suuri osa toiminnoista jäisi helposti käyttämättä ja heikentäisi käytettävyyttä. Kehittämällä Apotti iteratiivisella mallilla ja ”omalla” henkilöstöllä saataisiin uuden työkulttuurin kehitys lähtökohtaisesti osaksi hanketta. Terveydenhallinnon uutta toimintakulttuuria ei voi ostaa, se tulee joka tapauksessa kehittää itse. Kehittämällä järjestelmää ja toimintakulttuuria käsi kädessä saataisiin paras lopputulos.

Arkkitehtuurista

Minulla ei ole riittävästi tietoa arkkitehtuurin suunnitteluun. Innostuin kuitenkin pohtimaan, kuinka toimisin juuri nyt, jos Apotti-startupillani olisi 100 miljoonan euron pikku budjetti.

Apotin vetäjänä lähtisin rekrytoimaan seuraavia tiimejä, jotka toimisivat yhteisissä tiloissa ja kommunikoisivat päivittäin keskenään. Varsinaisissa ohjelmistokehitystiimeissä olisi lisäksi ainakin yksi erikoisosaaja (ja siten yhteyshenkilö) kullekin alla kuvatulle erikoistiimille:

  • Tietokantatiimi sisältäisi tietokantasuunnittelun huippuammattilaisia. Tiimin tehtävänä on kerätä rakenteelliset tiedot kaikista tällä hetkellä olemassaolevista kotimaisen terveydenhuollon tietojärjestelmistä. Tietojen avulla mallinnetaan yksi keskitetty tietovarasto. Ensimmäisen tietomallin prototyypin aikataulu on  4 viikkoa. Tietokantatiimi tuottaa muiden tiimien ja hankejohdon kanssa jatkuvasti käytävän keskustelun perusteella päivitetyn tietomallin aluksi 2-4 viikon välein.
  • Käyttöpalvelutiimi sisältäisi Cloud Computing -palveluiden ja ylläpidon huippuammattilaisia. Tiimin tehtävänä on suunnitella, toteuttaa ja ylläpitää Apotin tuotekehitys-, staging- ja tuotantoympäristöjä pilvipalveluina (joko omana pilviklusterina tai kansallisen pilvipalvelun päälle). Lisäksi tiimi vastaa tuotannon virheilmoitusten valvonnasta ja vastaanotosta.
  • Lakitiimi sisältäisi juridiikan ammattilaisia, joiden tehtävänä on varmistaa, että Apotti voidaan toteuttaa kaikille turvallisesti ja iteratiivisesti. Tiimin asiantuntijat eivät listaa ohjelmistokehittäjille ongelmia, vaan potentiaalisia ratkaisuja. Lakitiimissä ymmärretään, että vaikka Suomen laki edellyttäisi tarjoamaan tietyn palvelun, kyseistä palvelua ei tarvitse välittömästi automatisoida täydellisesti, vaan ensin voidaan toteuttaa vain muutama tärkein osa (jotka kattavat usein jopa 80% käyttötapauksista) ja käsitellä poikkeukset käsityönä. Sitten laajennetaan.   
  • Integrointitiimi sisältäisi testausautomatiikan huippuammattilaisia, jotka vastaavat Apotin automaattisen koonti- ja testiympäristön kehittämisestä ja ylläpidosta yhteistyössä muiden tiimien kanssa. Mikäli ohjelmistovirheitä ilmenee toteutuksen tai stagingin aikana, tiimi raportoi asiasta kyseiselle kehitystiimille.
  • Kehitystiimit (useita) sisältäisivät ohjelmistokehityksen, laadunvarmistuksen, käyttöliittymäsuunnittelun, juridiikan, käyttöpalveluiden ja tietokantojen huippuammattilaisia. Jokaisessa tiimissä on vähintään yksi jokaisen alan osaaja, joka toimii yhdyshenkilönä mahdolliseen erilliseen tiimiin. Esim. kunkin kehitystiimin tietokantavastaava tapaa päivittäin muiden tiimien tietokantavastaavat varsinaisen tietokantatiimin luona (tai esim. skypessä). Lyhyessä 15 minuutin tapaamisessa tarkistetaan tilanne ja sovitaan tärkeimmistä riippuvuuksista.
  • Hanketoimisto tukisi hankkeen onnistumista tarjoamalla tiimeille mm. laadukkaat työnteon puitteet ja tuoteohjauksen.

Oma Apottini olisi täysin Internet-pohjainen, kuten Facebook, Youtube tai Twitter. Nykyaikana on älytöntä suunnitella Desktop-pohjaista järjestelmää, jossa käyttäjille tulisi asentaa paikallinen ohjelmisto (poislukien mobiilisovellukset, jotka jokainen osaa asentaa itse). Rahaa säästyy rutkasti, kun ylläpito ei juokse tuhansien käyttäjien koneilla.

nuutti-epic3

Nuutti Hyttisen kuva EPIC Systems Corporationin tarjoamasta potilastietojärjestelmästä, jonka ydin on kehitetty 60-luvun MUMPS-kielellä. Käyttöliittymänä on Visual Basic 6, jonka virallinen tuki lopetettiin 2008. Teknisen iän lisäksi käyttöliittymä vaikuttaa sekavalta, sisältänee turhia ominaisuuksia ja vaatinee räätälöintiä, asennuksia ja koulutusta.  

Rajaisin Apotin vaatimukset ensiversioissa kunkin osajärjestelmän muutamaan tärkeimpää toimintoon, joiden avulla osajärjestelmän käyttäjät voisivat siirtyä Apottiin. Esim. Mitkä olisivat ”Diagnoosi” -osajärjestelmän tärkeimmät kolme toimintoa lääkärille, joka on tekemässä potilasdiagnoosia? Lisäksi minimoisin integraatiot muihin järjestelmiin, koska ne ovat usein hitaita ja kalliita ja priorisoisin integroinnit alkaen arvokkaimmista, kuten KELA:n integrointi. Avoimet ja turvalliset HTTP-sovellusrajapinnat olisivat itsestäänselvyys.

Käyttäjille arvokkaiden vaatimusten (kehitysjonon) keräämiseksi perustaisin intressiryhmiä, jotka edustaisivat monipuolisesti Apotin käyttäjiä (esim. lääkäreitä, hoitajia, potilaita ja terveydenhoidon toimistotyöntekijöitä). Intressiryhmät antaisivat haastatteluja ja osallistuisivat Apotin suunnitteluun, testaamiseen ja parantamiseen koko projektin ajan.

Apotin teknologiaksi valitsisin nykyaikaisen, avoimen, maksuttoman ja hyvämaineisen kehyksen. Mieleen tulee jokin Internet-kieli, kuten PHP (sopivalla esim. MVC-kehyksellä), Ruby on Rails tai Java. Valittua teknologiaa laajennettaisiin tarkasti valituilla laadukkailla kirjastoilla. Toteutus tehtäisiin iteratiivisesti 2 viikon jaksoissa, joiden lopuksi toiminnot esiteltäisiin ja siirrettäisiin nk. staging-ympäristöön, jossa intressiryhmät saisivat testata sitä seuraavat 2 viikkoa. Tämän jälkeen toiminnallisuus julkaistaisiin tuotantoon.

Apotin raportit toteutettaisiin (ensimmäisten karujen versioiden jälkeen) erittäin käyttäjälähtöisesti, jolloin esimerkiksi verikokeen tulokset olisi helposti tulkittavissa:

ff_bloodwork3_large_f

Lähde: Wired Magazine, Blood Test Gets a Makeover.

Uskon, että iteratiivisella kehitysmallilla Apotti voitaisiin ottaa asteittain käyttöön 2 vuoden sisällä kehittämisen aloittamisesta ja se olisi ”valmis” 5 vuoden sisällä aloituksesta. Samalla terveydenhuollon kulttuuri olisi kehittynyt uudelle tasolle yhdessä järjestelmän kanssa, käyttäjät olisivat todennäköisesti erittäin tyytyväisiä ja Apotin ylläpito ja jatkokehitys olisi verrattain edullista. Ylläpitoon käytettäisiin DevOps-tyyppistä mallia, jossa ylläpidosta, jatkokehityksestä ja laadusta vastaisi yhteistyötä tekevä pieni organisaatio.

Toivotan Apotille ja sen parissa työskenteleville onnea ja energiaa! Lähden mielelläni lounaalle, jos haluatte keskustella ketterän kehityksen mahdollisuuksista.

15 Comments on “Unelma ketterästä Apotista

  1. Hyvää konkretiaa ja ratkaisukeskeisyyttä. Olen samaa mieltä, että Apotin kaltaiseen tekemiseen ketterä kehitys on erittäin hyvä vaihtoehto, ja nimenomaan tiimin palkkaamisesta lähtevällä mallilla. Apottia varten voisi hyvin perustaa oman itsenäisen yksikön tai jopa yrityksen. Valtiollahan on hyvää historiaa omien IT-yksiköiden perustamisesta, mutta tätä mallia ei nykyisin kaikkien IT-ulkoistuksien keskellä oikein ole trendikästä puolustella. Tätä hommaa varten voisi minusta hyvin perustaa jonkun ”Ketterän Tieran”.

    Tosin pakko kommentoida hieman tätä vesiputous ja lisenssit vs. ketterä kehitys -taistelua. Vesiputousmalli (tai sen modernimmat vaiheistetut variaatiot) kyllä edelleen puoltavat paikkaansa selkeämmissä it-projekteissa joissa ostetaan jotain joka todella osataan etukäteen määrittää ja kuvata riittävällä tarkkuudella. Samalla alueella toimivat myös tuotepohjaiset ratkaisut joiden käyttöönotot voidaan myös hoitaa muillakin tavoilla kuin ketterästi tehden. Ketteryys sinänsä voi olla minunkin mielestäni se ”filosofisesti” paras tapa tehdä softaa ja ottaa järjestelmiä käyttöön, mutta se on myös monella sektorilla kovin kallis tapa varmistaa laatua. On paljon ohjelmistoalan sektoreita joissa ollaan kypsyysasteikolla paljon pidemmällä kuin terveydenhoidon tietojärjestelmissä (sekä tuotekypsyydessä että integraattoreiden osaamisen kypsyydessä). Tämä nyt tällaisena pakollisena disclaimerina siihen, että tähän keskusteluun saataisiin jotain tasapainoa – kun ei se ketteryyskään nyt mikään maailman pelastava uusi uskonto sentään ole. (Ketteryys-evankelistat olisivat minusta tässä maassa paljon uskottavampia kun eivät leimaisi perinteisempiä malleja niin jyrkästi. Tulee liian usein mieleen nämä vanhan liiton taloarkkitehdit jotka vihaavat elementtirakentamista ja haluaisivat että kaikki talot tehtäisiin käsin edelleen.)

    Asiaan. Tähän hommaan siis ketterä kehitysmalli ja oma tiimi sopii minusta erittäin hyvin ja sitä kautta voidaan minunkin mielestäni saada aikaiseksi varmasti hyvää laatua ja varmasti paljon pienemmällä budjetilla. Eli ketteryys hyväksytään malliksi. Siirrytään seuraaviin vaikeisiin kysymyksiin.

    Sitten pitää nimittäin keskustella a) teknologiasta ja b) tiimin rekrytoinnista.

    Ketteryyden filosofiassa puhutaan paljon siitä, että tiimi saa valita teknologian, mutta tämän mittakaavan hommassa niin ei voi minusta asia täysin mennä. Valittava teknologia muodostaa kivijalan ohjelmiston kehitykselle pitkällä tähtäimellä. Siksi kieleksi ei saa valikoitua mikään liian eksoottinen tai suljettu vaihtoehto. Esittämistäsi vaihtoehdoista PHP ja Java ovat minusta Suomessa hyvin edustettuja osaamisjoukoltaan. Joskin Java-koodarit ovat keskittyneet finanssimaailmaan, ja uusien kykyjen keskuudessa Java ei ole enää mikään kovin suosittu kielivaihtoehto. Ruby on Rails (tai vaikkapa tällä hetkellä kovin trendikäs Python) on epäilemättä kyvykäs vaihtoehto tehtävään, mutta varsin pienen osaajajoukon teknologia Suomessa. Todennäköisesti paremmin tehtävään soveltuisi jopa Microsoftin .Net, koska .Net-osaajia on Suomessa arviolta jopa yli 10 000 henkeä. Tästä massasta löytyy myös maan kovimpia arkkitehtuuriosaajia ja ohjelmointiguruja. Näin arvioiden veikkaisin teknologiapohjaksi soveltuvan parhaiten joko PHP, Java tai .Net. Kaikilla näillähän on mahdollista tehdä lopputuloksesta avoimen lähdekoodin ohjelmisto.

    Lopullinen päätös teknologiasta voisi kyllä tapahtua sitten tiimin ja osaamispoolin kautta. Etenkin jos hankinnan ensimmäinen vaihe tehtäisiin jonkinlaisen avoimen kilpailutuksen kautta, niin voisi hyvin rajata teknologiat edellä mainittuihin ja katsoa mistä suunnasta löytyy parhaat tiimit ja laajin osaamispohja. Täten tiimin ja teknologiavalinnan voisi osittain yhdistää, kunhan rajaa pois eksoottisimmat teknologiavaihtoehdot. Ja vaikka EU:ssa ollaan, niin tämänkaltaisessa hankinnassa jonkinlainen huoltovarmuuskortti olisi jopa ihan asiallinen, eli teknologiat rajattaisiin niihin joihin löytyy osaamista parhaiten Suomesta ja myös tulevina vuosina.

    Ei tule äkkiseltään kyllä mieleen, että millaisella hankintamenettelyllä tällainen usean tiimin valintaprosessi vietäisiin läpi sujuvasti – vaikka hankintakonsultti olenkin – ehkä siinä onkin se yksi kipupiste tämän väittelyn takana. Mutta samaa mieltä olemme varmaankin siitä, että noin se pitäisi tehdä. :)

    Tuohon teknologiavalinta-aiheeseen kuulisin mielelläni myös lisää näkemyksiä. Pitäisikö Apotti koodata PHP:lla, .Netillä vai Javalla? Mistä näistä löytyy parhaiten tarjolla olevaa kykyä Suomesta? Miten tätä selvittäisi?

    • Kiitos kommenteista Perttu.

      Kiva että komppaat ketterää resurssipohjaista hankintaa.

      Sementtisäkkien tilaamiselle lienee edelleen paikkansa. Mieleen tulee yksinkertainen tilanne, jossa projekti on pieni ja sisältö täysin selvä (tiedätkö varmasti, että tiedät?). Pienenkin urakan voi tilata varmuuden vuoksi ketterältä toimittajalta ilman oman kehitystiimin palkkaamista ja säästyä jopa kolminkertaiselta hinnalta, jonka toimittaja usein lätkäisee joutuessaan antamaan ”varman” toimituspäivän kiinteälle projektille. Oman kokemukseni mukaan iteratiivinen ja tuntipohjainen hankinta- ja projektimalli on edullisempi tapa varmistaa laatua kuin vesiputous. En siis täysin ymmärrä, miten pidät sitä kalliimpana? Oletan, että viittaat hankintaosaamisen puutteeseen mainitsemillasi sektoreilla.

      Julkisen iteratiivisen ohjelmistoprojektin hankinta on lopulta aika yksinkertaista. Julkishallinnossa tästä on jo käytännön kokemuksia (katso artikkelini linkit esim. Paikkatietoikkuna-hankinnan tarjouspyyntöön). Apotin tapauksessa kilpailutettaisiin useampi toteutustiimi samalla perusmallilla, jossa määritellään tarvittavien henkilöiden määrä ja osaaminen. Yksinkertaista ja toimivaa. Pirauta vaikka minulle, niin käydään kahvilla juttelemassa tarkemmin.

      Teknologiavalinta on itselleni vähemmän merkittävä asia, kunhan sen minimivaatimukset täyttyvät. Minimivaatimuksina pitäisin, että valittu ohjelmointikieli ja verkkokehys soveltuvat nopeaan ja laadukkaaseen internet-kehitykseen ja ovat lähdekoodiltaan avoimia. Lisäksi kokeneita kehittäjiä tulisi löytää helposti, kuten sanoit.

      Ketteryyteen liitetään joskus outoja uskomuksia. Apotin teknologavalintaa tuskin alistettaisiin kehitystiimin huutoäänestykselle, vaikka tiimi olisi kuinka kokenut. Yleensä teknologian suuntaviivat päätetään selvitysten, ohjelmistoarkkitehtien ja prototyyppien avulla. Selvityksen voi toki tilata myös kehitystiimiltä.

  2. Missähän maailmassa ylläpito juoksee tuhansilla koneilla hoitamassa työpöytäsoftia? Ei sitä ole tehty vuosikausiin. Ja missähän maailmassa PHP on hyvämaineinen jatkuvine tietoturvaongelmineen ja sisäisine ristiriitoineen? Suosittu ei ole sama kuin hyvämaineinen.

    Miten ajattelit vaikkapa PHP:llä tehdä tällaisen oikean palvelinsovelluksen, siis sellaisen, joka pyörii isestäänkin taustalla hoitamassa asioita, eikä ole vain query/response-tyyppinen webbisovellus? Mitä lisäarvoa tuo ”avoin” kehys verrattuna siihen, että saataisi vakaa, hyvin ylläpidettävä ja kunnolla kehitetty järjestelmä, jolle ihan oikeasti taataan tuki ja mahdolliset korjaukset? Miten järjestetään tietojen tallennus, mahdollinen synkronointi, yhtäaikainen käsittely, verkkokatkojen haittojen minimointi jne tämän ”täysin Internet-pohjaisen” järjestelmän kanssa? Arkkitehtuuri on paljon muutakin kuin alustan ja protokollan valinta.

    Kuka maksaa kulut ja palkkaa lisäväkeä siinä vaiheessa kun on nämä ”kolme tärkeintä” asiaa diagnoosimodulissa ja lääkäreistä osa voi käyttää sitä osaan potilaista, mutta kukaan ei täysin ja tietoa vatkataan eri järjestelmien välillä eikä integraatiota ole? Kuka maksaa kahden viikon välein muuttuvan järjestelmän koulutusta ja helpottaa väkisinkin vastaan tulevaa muutosvastarintaa? Aikaa kuluu hukkaan ja potilaat odottavat ja lopulta pahimmassa tapauksessa kliinikot ilmoittavat käyttävänsä vanhaa järjestelmää jotta hommat hoituvat.

    Ketteryys on kiva asia eikä tällaista järjestelmää todellakaan pitäisi ainakaan tyhjästä tehtäessä rakentaa kerralla, mutta en nyt ihan heti näe tässä artikkelissa mitään erityistä Apotin ratkaisemiseksi. Eikä ainakaan mitään perusteluja heitetyille ajatuksille. Varsinkaan mikään iteraation pituus ole tässä vaiheessa oleellinen. Itse pidän enemmän ”kun se on valmis”-ajattelumallista, joka ei toki ole sama kuin ”väsätään vuosi ja katsotaan miten kävi.”

    Myöskin monet käyttöliittymät voivat vaikuttaa maallikosta sekavilta (en ota kantaa EPICiin kun en ole sitä käyttänyt, tuo yksi kuva näyttää itselleni ainakin aika selkeältä), mutta niille oikeille käyttäjille voivat olla hyvinkin toimivia. Kauniit värikkäät raportit asiakkaille ovat plussaa, mutta tärkeintä on saada se tieto tehokkaasti kliinisen työn tekijöille ja he sen kuitenkin lopulta asiakkaalle välittävät.

    • Hei Sami ja kiitos kommenteista. Onnitteluni myös yrityksesi upeasta nimestä Tokavuh. Se herätti suurta ihailua ollessani töissä Ekahau Oy:ssä.

      Olet ihan oikeassa. Minulla ei ole riittävästi tietoa Apotin tekniseen määrittelyyn, vain unelmointiin. Ehkä kuitenkin kommentoin muutamaa näkökulmaasi.

      Verkkosovelluksen ylläpitäjän ei tarvitse huolehtia sovelluksen asennuksesta satojen tai tuhansien käyttäjien erilaisille Windows-, Mac- ja Linux-koneille. Asennusten automaatio vaatii osaamista, aikaa, laitekohtaista hallintaa ja aktiivisen tukipalvelun, kun Apotti-sovellus kaatuu. Desktop-supportti ei (aina) juokse, mutta sen kustannukset juoksevat. Kyseessä olisi turha rahareikä, kun potilastietojen käsittely ei ole rakettitiedettä eikä vaadi lokaalia sovellusta.

      Ohjelmointikielen valinta ei ole itselleni kovin oleellista, kunhan se täyttää tietyt minimikriteerit. PHP:llä on mahdollista tehdä laadukasta ja ylläpidettävää koodia, kun käyttää sopivaa esim. MVC-kehystä. Eräajoihin ja muuhun backend-automaatioon valitaan tietysti tarkoituksenmukainen työkalu, kuten Python, C++, Scala, tms. PHP on esimerkki avoimesta ja yleisestä internet-kielestä suljetun ja vanhentuneen Visual Basic 6:n sijaan.

      Kirjoitukseni idea ei ole vastata Apotin IT-kysymyksiin vaan tarjota vaihtoehto Apotin julkisen hankinnan, projektoinnin ja budjetoinnin perinteisille haasteille, joista voi koitua satojen miljoonien ylimääräinen lasku veronmaksajille.

      Harva on käynyt kurssia Facebookin, Youtuben tai Twitterin käytössä. Nykyaikaisen käytettävyyden ei tule vaatia pitkää koulutusta. Kun hyvä peruskäytettävyys ja työnkulku on iteroitu kuntoon (esim. osajärjestelmän kolmella tärkeimmällä toiminnoilla) voidaan pienempiä toimintoja lisätä helpommin. Uusiin asioihin voidaan myös liittää videolinkki, joka neuvoo uuden ominaisuuden käytössä. Iteratiivisuus ei yleensä haittaa merkittävästi käyttäjiä, vaikka uusi versio vietäisiin tuotantoon kahden viikon välein (tai jopa päivittäin). Tämä on verkkokehityksen arkea ja mahdollistaa sen, että käyttäjillä on aina saatavilla uusin ja toimivin versio.

  3. Yritän välttää keskustelua näistä hankinta- ja toteutusmenetelmistä täysin abstraktilla ”tehdään jotain softaa” -tasolla. Ymmärrän, että ketteriä menetelmiä voi soveltaa ”joka paikkaan”, mutta silti ohjelmistoalalla on paljon hyvin erilaisia sektoreita. Olen itse esimerkiksi hyvin varovainen kommentoimaan terveydenhoidon sektoria, koska en väitä ymmärtäväni sen vaatimuksista, markkinoilla olevista tuotteista tai muista toimijoista kovinkaan paljoa (tai juuri mitään). Sitten taas jos puhutaan julkaisujärjestelmistä, isoista verkkosivustoprojekteista tai intraneteista, niin väitän ymmärtäväni niiden hankinnasta ja projektien läpiviennistä paljonkin. Ja sillä sektorilla esimerkiksi ketteryyteen liittyy vielä paljon haasteita enkä itse suosittele sitä malliksi kuin tilanteissa joissa selvästi on haasteellista kirkastaa tavoitetilaa ja hankinnan kohdetta etukäteen.

    Jos taas viestinnällinen intranet pitää uudistaa ja vaatimuksista on hyvä ymmärrys, ja asiakkaalla kokemusta vastaavista projekteista, ja jokin tuote vastaa hyvin vaatimuksiin (ja ollaan valmiit myös tinkimään omista vaatimuksista jotta osuttaisiin paremmin kehittyvän tuotteen ominaisuuksien piiriin), niin kyllä projekti kannattaa kilpailuttaa ja vetää läpi pariin palaseen vaiheistettuna hankkeena. Näin voidaan päästä ennustettavaan hintaan ja lopputulokseen, ja monesti halvemmalla kuin ketterässä projektissa – tosin tämä johtuu toki myös siitä että tiukempi projektimalli pitää kummankin puolen ”kurissa” projektin aikana.

    Olen siis omalla sektorillani nähnyt samankaltaisia projekteja tehtynä oikeasti ketterästi, vesiputouksella ja myös monenlaisilla tavoilla vaiheistettuna. Ja olen sitä mieltä, että mitä enemmän halutaan hyödyntää tuotteita (ja niitä on saatavilla), ja mitä enemmän tavoitellaan kustannustehokkuutta, niin sitä enemmän kannattaa soveltaa jonkinlaista boksittamista ja ennakkosuunnittelua/protoilua.

    Johonkin boksiin voi sitten soveltua myös ketterä tekeminen. Ja voihan tuotteenkin käyttöönoton tehdä ketterästi, mutta minusta se ei sitten enää ole mitään ketterää kehitystä oikeasti – se on vain hyvin iteratiivisesti tehtävää käyttöönottoa. Saa olla eri mieltä :)

    Nyrkkisääntönä pidän omalla sektorillani sitä, että jos budjettia on alle 200 000 euroa, niin ei kannata haaveilla mistään resurssipohjaisesta ”ostetaan tiimi tänne koodaamaan” -mallista. Tiimiyttämiseen ja ympäristön pystyttelyyn ja homman kiihdyttämiseen palaa rahaa kuitenkin aika lailla, ja lopputulos jää helposti aika ohueksi. Mitä enemmän taas ollaan puolen miljoonan euron lähellä tai yli, niin sitä enemmän ääriketterä ”hankitaan tiimi ja ryhdytään priorisoimaan vaatimuksia” -lähestyminen toimii.

    Suurin osa tämän maan ohjelmistoprojekteista osuu kuitenkin tuohon alle 200 000 euron malliin – väittäisin – niin siksi lähinnä pidän tätä ääriketterän mallin sovittamista kaikkeen ohjelmistokehitykseen/tekemiseen vähän harhaanjohtavana ajoittain.

    Joissain projekteissa ketterä malli on ihan ehdoton taas sitten esimerkiksi ympäristön haasteellisuuden vuoksi (esim. yksinkertainen saittiuudistus, mutta vanha saittikokonaisuus on hyvin laaja ja rikkonainen) jolloin iteratiivisesti etenevä raivausporukka hoitaa homman maaliin olennaisesti vähemmällä tuskalla – ja varmaan myös vähemmillä kustannuksilla kun toimittaja ei joudu arvailemaan mitä kaikkea onkaan edessä.

    Disclaimerina todettakoon, että en itse toimi täysin räätälöidyn softakehityksen parissa juuri ollenkaan, koska omalla sektorillani kyse on paljon enemmän esimerkiksi isojen verkkosivustojen toteutusprojekteista tai esimerkiksi asiointipalveluiden rakentamisesta jotka nojaavat useisiin taustajärjestelmiin ja kokonaisuuksien rakentamiseen on tarjolla paljon valmistuotteita/palikkakokoelmia (ja näihin erikoistuneita ohjelmistotaloja).

    Uskoisin, että olemme suurimmasta osasta asioista ihan samaa mieltä, mutta katsomme asioita vain erilaisten markkinoiden näkökulmista. Ymmärrän myös, että et suostu allekirjoittamaan sitä, että ketterä kehitys olisi jotenkin kalliimpaa. Eihän se ”oikein tehtynä” varmasti koskaan olekaan, mutta kun todellisuus on toinen. Minun väitteet perustuvat täysin siihen mitä olen nähnyt käytännössä – ja omalla sektorillani on paljon kokemuksia siitä, että rahaa palaa tasaisesti, ja tuloksiakin tulee tasaisesti, mutta kun kaikki asiat tehdään viimeisen päälle ja jokainen nurkka hioen, niin tavoitellun lopputuloksen hintalappu on lopulta todella korkea. Pahimmillaan matkan varrella on koodattu tuotepohjainen ratkaisu siinä sivussa ihan uuteen asentoon, ja jopa sen tuotteen sisältämiä perustoimintoja on koodattu uusiksi.

    Näissä esimerkeissä on tietysti ollut paljon enemmän kyse siitä, että hankkeistus ja tavoiteasetanta on mennyt jollain tapaa pieleen – eikä sitten ole osattu reagoida tilanteeseen matkan varrella – mutta ehkä isona pointtina onkin se, että ketterä kehitysmalli vaatii valtavasti niiltä ihmisiltä jotka siihen osallistuvat – ja fakta on minusta se, että sellaista osaamista löytyy vielä aika niukasti niin tekijöistä kuin hankejohdosta. Siksi hyvä malli huonosti toteutettuna voi johtaa heikompaan tulokseen kuin keskinkertainen malli hyvin toteutettuna.

    • Kiitos kommentistasi Perttu. Jos kaipasit substanssia, toimin sairaalapaikannusta kehittävän firman teknologiajohtajana 6 vuotta. Sinä aikana ehti kehittyä jonkinlainen tuntuma terveydenhuollon järjestelmistä.

      Jaksan aina ihmetellä sitkeää utopiaa siitä, että vaatimusten lukitseminen varmistaisi hyvän lopputuloksen tai edullisemman hinnan. Ikäänkuin ohjelmistokehittäjien osaaminen itsekseen paranisi, kun sisällöltään lukittu toimitussopimus on allekirjoitettu. Tai että kovasti yrittämällä näkisimme tulevaisuuteen.

      Otetaan simppeli esimerkki. Tilaat vaatimusmäärittelysi mukaisen verkko-ohjelmiston, jossa on viisi ominaisuutta A, B, C, D ja E. Hinnaksi sovitaan tasan 500 euroa (alv0%) ja toimitusajaksi 5 kuukautta. Kun nimesi on paperissa, olet juuri poistanut loogisen tarpeen priorisoida vaatimukset (koska kaikki on luvattu). Peffa edellä rakennetun ohjelmistosi saat juuri niin nopeasti (lue hitaasti) ja edullisesti (lue kalliisti) kuin olet sopinut. Tämän vuoksi vesiputousta kutsutaankin “latest date, maximum cost”. Kun sitten huomaat projektin aikana jonkin tärkeän asian puuttuvan määrittelystäsi, niin voit joko unohtaa sen tai vaatia ominaisuuden toimittajalta (viivyttäen toimitusta kuukaudella) ja maksaa muutoksesta 100 euroa lisää. Koska et ole nähnyt väliversioita, voi tosin olla, ettei lopputulos miellytä käyttäjiäsi. Olet juuri maksanut 600 euroa kuukauden myöhästyneestä systeemistä, jossa on turhia ominaisuuksia ja joka ei tyydytä käyttäjiä. Ikävä kyllä näin voi hyvinkin käydä Apotille, tosin miljarditasolla, ellei jotain tapahdu.

      Sama iteratiivisella mallilla. Varaat saman kehitystiimin työaikaa 5 kuukautta. Koska sinulle näytetään väliversioita, huomaat ettet tarvitse ominaisuuksia D ja E, joiden kehitykseen olisi mennyt 2 kuukautta ja 200 euroa. Lisäätte myös mukaan tärkeän ominaisuuden F, joka puuttui alkuperäisestä määrittelystä. Sait juuri paremman ja selkeämmän järjestelmän 2 kuukautta vesiputousta nopeammin ja 200 euroa edullisemmin (josta tosin maksat kehitystiimille n. 20% bonuksen jos käytät tavoitehintamallia). Säännöllisen priorisoinnin ja katselmointien johdosta ohjelmisto on lisäksi laadukkaampi ja tyydyttää käyttäjiäsi.

      Mistä tahansa projektimallista päätyy maksamaan liikaa, jos ei tunne hintatasoa. Ketterässä hankinnassa on oleellista varmistaa tekijöiden osaaminen (jonka voi myös kilpailuttaa) ja siihen suhteutettu kilpailukykyinen päivä- tai tuntihinta sekä realistinen arvio projektin kestolle, jos käyttää tavoitehintamallia.

      Kokemukseni perusteella iteratiivinen kehitysmalli sopii erityisen loistavasti verkkosovelluksiin (intra- ja internetiin), joissa pienillä muutoksilla voi olla suuri vaikutus lopputulokseen. En siis ymmärrä mikä ketterissä verkkosivuprojekteissa on “vielä haasteellista”. Tutustu esim. Reaktorin, Houston Inc:n, Kisko Labsin, Eficoden, Solitan, Wunderkrautin, Futuricen ja muiden ketterien toimittajien tarjoomaan. He kertovat mielellään lisää, ja projektisi voit teettää myös heidän tiloissa. Tällöin sinun ei tarvitse rekrytoida omaa ketterää tiimiä, ja projektisi budjetti voi olla hyvinkin pieni, esim. €15-30k. Kuten sanoit, oman tiimin rekrytointi on perustellumpaa, kun projekti on suurempi.

      Aurinkoa ja tsemppiä kevään projekteihin!

  4. Lare, hieno kirjoitus ja hyvä aloite. Mutta jotta nämä kauniit ajatukset, joista itse allekirjoittaisin monet, eivät jäisi vain blogin asteelle vaan syntyisi jotain konkreettista niin mitä voisimme tehdä? En usko, että kukaan haluaa ”sytyttää nuotiota tuhannen euron seteleillä” vaan aidosti päättäjillä ei ole tietoa paremmista toimintatavoista ja meillä voisi olla mahdollisuus tuoda se tieto heille? Voisimmeko tehdä yhteisvoimin asian eteen jotain?

    • Kiitos Jukka! Olen juuri lähdössä lomalle, joten en ole vähään aikaan edistämässä Apotti-asiaa. Mukavaa liikehdintää on kuitenkin havaittavissa. Esim. Houston-Inc:n Vesa Teikari on järjestämässä jonkinlaista toimintaa aiheen tiimoilla. Kehotan olemaan toistaiseksi häneen yhteydessä.

  5. Olen ehdottomasti sitä mieltä, että iteratiivinen malli on hyvä. Tosin tämän kokoisessa projektissa, jossa on vieläpä kyse terveydenhuollon järjestelmästä, on oleellista, että arkkitehtuuri saadaan toimivaksi. Muun muassa laatuvaatimukset pitää miettiä ja selvittää tarkkaan, jotta ei tehdä sellaisia päätöksiä arkkitehtuurin suhteen, joita on myöhemmin vaikea muuttaa. Kuten aikaisempi kommentoijakin sanoi, arkkitehtuuri on muutakin kuin alustan ja protokollan valinta. Arkkitehtuurin muuttaminen jälkikäteen voi tulla hyvinkin kalliiksi, joten se, että suin päin lähdettäisiin ketterästi toteuttamaan järjestelmää voi kostautua jälkikäteen. Puhdas ketteryys toimii joissain projekteissa, mutta pitää myös ymmärtää milloin se ei välttämättä sellaisenaan toimi. Pitää pystyä ajattelemaan objektiivisesti ja valitsemaan käytettävät prosessit ja teknologiat projektin kontekstin mukaan. Sellaiset prosessit ja teknologiat, jotka toimivat hyvin verkkopalveluiden toteuttamisessa eivät välttämättä sovellu kaikkiin projekteihin.

    Vaatimukset on siis tämän kokoisessa projektissa hyvä selvittää mahdollisimman hyvin etukäteen. Nyt en tarkoita, että kaikki vaatimukset pitäisi määritellä etukäteen. Toki pitää hyväksyä, että muutoksia väistämättä tulee ja silloin on pystyttävä reagoimaan näihin muutoksiin. Se, että vaatimukset ja suunnittelu on tehty huolellisesti etukäteen, ei tarkoita, että koko projekti pitäisi lukita näihin vaatimuksiin. Keskustelu ketteristä menetelmistä ja vesiputousmallista on liian usein ”joko tai”-tyyppinen keskustelu. Pitäisi enemmän yrittää miettiä sitä, miten nämä voisivat tukea toisiaan. Itse asiassa Winston Roycen alkuperäinen artikkeli vesiputousmalliin liittyen on monesti ymmärretty väärin. Hän itse asiassa kirjoittaa, että puhdas vesiputousmalli sisältää riskejä ja voi johtaa epäonnistumiseen (tosin hän ei mainitse sanaa vesiputousmalli kertaakaan). Tämän takia hän ehdottaa viisi toimenpidettä, joilla riskejä epäonnistumiseen voi välttää. Hän muun muassa ehdottaa pienimuotoista iteratiivisuutta ja asiakasyhteistyötä.

    Isona taakkana Apotti-hankkeessa ovat vanhat potilastietojärjestelmät, joiden integroiminen tulee olemaan haastavaa. Ilman tätä taakkaa Apotti-hanke olisi huomattavasti helpompi toteuttaa. Sen takia Apotti-hanketta ei voi suoraan verrata esimerkiksi Virossa toteutettuun potilastietojärjestelmään. Virossa käsitykseni mukaan hanke oli mahdollista toteuttaa puhtaalta pöydältä, koska siellä terveystiedot eivät olleet niin levällään kuin ne Suomessa ovat.

    Potilastietojärjestelmää ei myöskään voi verrata Facebookiin tai muuhun sosiaaliseen verkkopalveluun. Potilastietojärjestelmä on kriittinen siitä syystä, että virheet järjestelmässä voivat pahimmillaan vaikuttaa ihmisten terveyteen tai jopa johtaa kuolemiin. Kirjoittajakin sen mainitsee: ”Apotilla ei lennetä Kuuhun vaan pyöritetään viiden miljoonan ihmisen potilastietoja”. Juuri näin, viiden miljoonan ihmisen potilastietoja. Haluaisitko sinä, että potilastiedoissasi on virheitä tai että potilastietojärjestelmän tietoturva on kyseenalainen?

    Se, että Apotti olisi täysin Internet-pohjainen olisi kiva ajatus, mutta epäilen, että se käytännössä toimisi. Potilastietojärjestelmässä palvelun saatavuus on erittäin tärkeää ja tietojen lukemisen ja tallennuksen pitäisi toimia myös kun verkkoyhteydet eivät toimi. Tämän takia Desktop-pohjaista järjestelmää ei kannata kokonaan torpata. Mitä ohjelmointikieliin tulee, niin olen itse toteuttanut verkkopalveluja PHP:llä, mutta en kyllä aivan heti suosittelisi sen käyttämistä potilastietojärjestelmän toteutuksessa. Vaikka PHP:hen on viime aikoina tullut parannuksia, valitsisin mieluummin jonkun paremmin suunnitellun kielen projektin tarpeet huomioon ottaen. Tämän kokoisessa projektissa voi jopa olla tarpeen käyttää useampia ohjelmointikieliä, jos sille löytyy hyvät perustelut.

    Kirjoitus on mielenkiintoinen ajatusten herättäjänä, mutta ketteryys ei yksinomaan ole mikään kaikenkattava ratkaisu Apotti-hankkeeseen. Ohjelmistoprojekteissa kyse ei ole pelkästään prosesseista tai teknologioista, vaan lopulta ihmisistä, jotka näitä prosesseja ja teknologioita käyttävät. Siinä olen kirjoittajan kanssa samaa mieltä, että olisi hyvä, jos saataisiin Apotti-hankkeeseen rekrytoitua mahdollisimman osaavia ammattilaisia. Perusteluja saisi tosin kirjoitukseen lisätä yhden jos toisenkin, jolloin keskustelu voisi keskittyä mielipiteiden sijaan asioista väittelemiseen.

    • Hei Jari ja kiitos kommenteistasi! Alla muutamia perusteluja.

      Ketterään kehitykseen liitetään välillä uskomus, ettei vaatimuksia kerättäisi, analysoitaisi tai arkkitehtuuria suunniteltaisi etukäteen. Useimmiten tällaisen huolen esittää henkilö, jolla ei ole menetelmistä käytännön kokemusta.

      Ketterissä projekteissa vaatimusten, arkkitehtuurin, käytettävyyden, tietoturvan ja laadun varmistukseen käytetään jopa enemmän aikaa kuin perinteisessä projektissa. Aika vaan jakautuu tasaisemmin koko projektille.

      Ketterän projektin alussa tehdään tietysti tarkoituksenmukaiset teknologiavalinnat. Koska työn tuloksia katselmoidaan ja testataan säännöllisesti, mahdolliset pullonkaulat havaitaan ja voidaan kokeilla vaihtoehtoista teknologiaa sen sijaan, että roikkuisimme määritellyssä teknologiassa, kunnes on liian myöhäistä. Yksikään ammattilainen ei tee teknologiavalintoja juosten pissien.

      Tuskin kukaan syyttää Winston Roycea vesiputousmallin ongelmista. Juurisyynä on Roycen mallin pohjalta syntynyt projektiliiketoiminnan kulttuuri, joka suorastaan pakottaa kompleksit projektit epäonnistumaan (esim. poistamalla loogisen tarpeen priorisoida vaatimukset keskenään, koska kaikki vaatimukset on luvattu, ja kilpailuttamalla määrittely-, suunnittelu- ja kehitysvaiheet jopa eri firmoille hukaten tolkuttomasti tietoa).

      Perinteinen hankintamalli on keskeinen syy sille, miksi Apotin kustannusarvio on niin suuri ja miksi projektilla on pienet mahdollisuudet onnistua. Siksi artikkelini keskittyy tarjoamaan Apotin hankinta- ja projektimallille vaihtoehdon, joka voi johtaa jopa kolminkertaiseen onnistumistodennäköisyyteen (kts. artikkelin linkit).

      En missään nimessä lähtisi integroimaan satoja ikivanhoja hajallaan olevia terveydenhuollon purkkeja yhteen. Koko ajatus on mielestäni absurdi, koska uuden keskitetyn verkkopohjaisen Apotin rakentaminen ja ylläpito maksaisi todennäköisesti vähemmän kuin pelkkien integrointien kustannukset. Mainitsemiasi virheitä siinä vasta syntyykin, kun alamme kolvata yhteen satoja erilaisia tietokantoja ja protokollia, joista jokainen vaatii erikoisosaamista. Siinä ei olisi järjen häivääkään, se maksaisi tolkuttomasti ja virheiden selvittely ja jatkokehitys vielä enemmän.

      Desktop-Apotti olisi ollut vielä 1990-luvulla OK. Maailma on sittemmin muuttunut ja vuodesta 2010 lähtien laajakaistayhteys on kuulunut Suomessa nk. välttämättömiin yleispalveluihin. Se tarkoittaa sitä, että jokainen suomalainen kuluttaja tai yritysasiakas saa tarkoituksenmukaisen internet-laajakaistan vakituiseen asuin- tai sijaintipaikkaansa. Tämä riittää Apotillekin loistavasti.

      Sen sijaan, että poltamme puoli miljardia euroa 1960-luvun desktop-teknologiaan internet-yhteyden pelossa, voisimme vaikkapa varmentaa sairaaloiden verkkoyhteydet muutamalla prosentilla Apotin kustannuksista. Desktop-sovelluksen perusteleminen vuoden 2013 Suomessa sillä, että verkkoyhteys voi katketa, on mielestäni sama kuin auton akkujen teippaaminen Apotti-käyttäjien selkään siltä varalta, että sähköt katkeavat. Internetin pomminkestävästä rakenteesta johtuen palvelinbunkkereissa varmennettu laadukas verkkosovellus todennäköisesti palvelisi suomalaisia paremmin myös kriisitilanteissa kuin nippuun kolvattu tilkkutäkki, jonka korjaaminen olisi hidasta ja kallista.

      Käytin Facebookia vertauksena verkkopalvelusta, joka palvelee lähes miljardia käyttäjää. FB:n ensiversio koodattiin muutamalla tonnilla, joten ehkäpä Apotin budjetissa olisi varaa vähän satsata laadunvarmistukseen. Ketterässä projektimallissa laadunvarmistusta tehdään jatkuvasti koko projektin ajan, jolloin potilastietomme pysyvät kunnossa jopa aiempaa paremmin.

      Ketterän mallin avulla voi jopa kolminkertaistaa projektin todennäköisyyden onnistua (kts. artikkelin linkit tutkimustuloksiin). Jos se ei riitä, niin mielelläni kuulisin, mikä on tehokkaampi keino tukea Apotin onnistumista.

  6. Kiitos vastauksesta Lare. Eiköhän me olla ihan samoilla linjoilla käytännössä monessa asiassa edelleen. Ja diggaan siitä, että uskot asiaasi ketterien menetelmien evankelistana.

    Olen vain itse eri linjoilla sen näkemyksen kanssa, että alalla oltaisiin siinä tilanteessa, että voisi antaa suosituksen: ”Menkää ja tehkää ketterästi kaikki projektinne”. Minun realismihan (tai lievä pessimismi) tulee nimenomaan siitä, että tiedän varsin hyvin mitä Reaktor, Houston Inc, Kisko Labs, Eficode, Solita, Wunderkraut, Futurice ja muut toimijat omalla sektorillani tarjoavat, millä hinnalla ja mitä tulee lopputuloksina. En siis ole nähnyt, että tekemällä ketterästi ne isoimmat ongelmat vielä ratkeaisivat maagisesti paremmin. Lähinnä realismi on ollut sitä että ne vain takaavat projektin maksavan paljon jos asiakkaan kontrolli ja johtamiskyky ei ole tarkkana koko ajan. (Ja huom. tässä en siis kritisoi mitenkään ketteryyttä mallina, vaan totean havainnon joka johtuu monesta asiasta – ja ei välttämättä ollenkaan siitä että mallissa olisi jotain vikaa.)

    Erilaisia tavoitehintamalleja ja ketterää kehitystä suosittelemme kyllä mekin jatkuvasti, mutta samanlaiseen ”kaikki muuttuu paremmaksi kun tehdään ketterästi” -hurmokseen en suostu vain vielä uskomaan.

    Toivon törmääväni enemmän onnistuneisiin ketteriin projekteihin jatkossa, ja uskon että törmäänkin. Tämän Apotin suhteen ainakin olemme samaa mieltä.

    • Kiitos Perttu. Samoilla linjoilla ollaan.

      Kaupalliseen toimintaan liittyy luonnollisena osana voiton tavoittelu.

      Iteratiivisissa projekteissa ostetaan tyypillisesti henkilöitä eikä sisältöä, joten projektin hinnalla keinottelu on lähtökohtaisesti vaikeampaa. Omaa ketterää tiimiä kasatessaan voi toimitussopimukseen myös pyytää pykälän kehittäjän korvaamisesta vastaavalla, jos homma ei jostain syystä lähde sujumaan (ikäänkuin koeaika). Lisäksi voi käyttää tavoitehintamallia, jolloin projekti voidaan tilaajan niin halutessa toteuttaa perinteiseen tyyliin koko suunniteltu sisältö kerralla. Tällöin tosin kysyisin, miksei tilaajaa kiinnosta katselmoida työn etenemistä?

      Ketterässä projektissa on tietysti mahdollista sössiä esim. työn priorisoinnissa, vaikka julkaisulle on tehty priorisoitu ja työmääräarvioitu kehitysjono. Omalla kokemuksellani useimmat työnohjauksen mokat sisältävät kuitenkin tärkeitä oivalluksia optimaaliseen lopputulokseen pääsemiseksi. Virheitä tehdään projekteissa edelleen, mutta iteratiivisessa mallissa ne havaitaan nopeammin ja tarvittavia muutoksia voi tehdä, kunnes aika tai raha loppuu.

      Ketterä kehitysmalli ei itsessään ratkaise tai takaa mitään. Se ainoastaan tarjoaa viitekehyksen, jonka puitteissa onnistuminen on tutkimusten mukaan kolme kertaa todennäköisempää kuin aikaisemmin. Apotin kannattaisi mielestäni hyödyntää tämä mahdollisuus.

      Kevätaurinkoa ja energiaa!

      PS. Käytin juuri auton katsastuksessa ja kysyin nuorelta autoinssiltä mikä on hänen mielestään laadukkain automerkki. Välitön vastaus oli Toyota. Kyseinen valmistaja on monelle esikuva Agile/Lean/Kanban-ajattelusta autoteollisuudessa, ja se siis myös näkyy.

  7. Hei Lare ja kiitos vastauksista ja perusteluista!

    Tuo Standish Groupin raportti, johon useasti viittaat sanoessasi, että ”ketterän mallin avulla voi jopa kolminkertaistaa projektin todennäköisyyden onnistua”, on ollut kyseenalainen jo vuosia. Kannattaa lukea muun muassa nämä tieteellisissä lehdissä julkaistut artikkelit: ”The Standish Report: Does It Really Describe a Software Crisis?” vuodelta 2006 ja ”The Rise and Fall of the Chaos Report Figures” vuodelta 2010. Viimeiseksi mainitusta ilmenee, että Standish Groupin tekemän tutkimuksen määritelmät ovat harhaanjohtavia ja että koko tutkimus mittaa lähinnä huonosti sitä, miten hyvin alkuperäisissä arvioissa kustannusten, ajan ja toiminnallisuuden suhteen on pysytty. Tällainen määritelmä ei todellisuudessa vastaa sitä, onko projekti oikeasti onnistunut vai ei. Ongelmana raportissa on myös se, että Standish Group ei ole julkaissut mitään tietoa siitä, miten he määrittelevät vesiputousmallin ja ketterät menetelmät. Siinä mielessä viittaamaasi raporttiin kannattaa suhtautua varauksella. Mike Cohnin blogissa on myös mielenkiintoista keskustelua (lukekaa erityisesti kommentit) liittyen Standish Groupin raporttiin (http://www.mountaingoatsoftware.com/blog/agile-succeeds-three-times-more-often-than-waterfall).

    Olen luottavainen siitä, että ketterät menetelmät toimivat paremmin kuin vesiputousmalli tai sen variaatiot monissa konteksteissa, mutta toivoisin näkeväni luotettavaa tietoa siitä, miten ketterät menetelmät toimivat erityisesti isoissa, hajautetuissa ja/tai kriittisissä ohjelmistoprojekteissa. Riskinä Standish Groupin tapaisissa raporteissa voi olla, että ihmiset kokevat ketterien menetelmien olevan jonkinlainen maaginen ratkaisu kaikkiin ongelmiin ja sitten he yrittävät soveltaa niitä sellaisissa konteksteissa, joihin ketterät menetelmät eivät välttämättä sovellu. Sellaiset tapaukset voivat tahrata ketterien menetelmien maineen.

    Minulla on kokemusta ketterien menetelmien käytöstä projekteissa ja tiedän hyvin, ettei se tarkoita sitä etteikö vaatimuksia kerättäisi tai arkkitehtuuria suunniteltaisi etukäteen. Yksi tapa on esimerkiksi ottaa tätä varten käyttöön niin kutsuttu 0-sprintti, vaikka se voikin olla ”puhtaiden” ketterien menetelmien periaatteiden vastaista. Vaikka ketterässä manifestissa suositaan ”toimivaa sovellusta enemmän kuin kokonaisvaltaista dokumentaatiota”, ei se myöskään tarkoita etteikö dokumentaatiota voisi olla. On myös hyvä ymmärtää, että arkkitehtuurisuunnitteluun panostamisen määrä riippuu myös projektin kontekstista. Haluan vielä painottaa, ettei arkkitehtuurisuunnittelu ja ketterät menetelmät mielestäni ole poissulkevia. Näiden yhteensovittamisessa tosin usein herää paljon kysymyksiä kuten mikä arkkitehdin rooli on ketterissä menetelmissä ja miten ketterät menetelmät tukevat arkkitehtuurin kokonaiskuvan luontia. Puolin ja toisin on myös paljon väärinymmärryksiä kuten se, että ketterät menetelmät olisivat amatöörimäisiä tai että arkkitehtuurisuunnittelu ei tuo lisäarvoa asiakkaalle tai että ainoa oikea tapa on antaa arkkitehtuurin syntyä asteittain sprintistä sprinttiin. Arkkitehtuurisuunnittelua ei myöskään pidä sekoittaa alemman tason suunnitteluun (software design).

    Siitä olen kanssasi täysin samaa mieltä, että nykyinen hankintamalli, jossa kaikki vaatimukset pitää luvata etukäteen, on yksi suurimmista syistä isojen ohjelmistoprojektien epäonnistumiselle. Tällainen hankintamalli voi korkeintaan toimia aivan pienissä ja yksinkertaisissa projekteissa, joissa tiedetään täysin mitä ollaan tekemässä. Siihen en kuitenkaan halua ottaa kantaa, onko tämän hankintamallin syy esimerkiksi Roycen väärinymmärretyssä prosessimallissa, USA:n puolustusministeriön DoD STD 2167 -standardissa vai siinä, että yritetään istuttaa muiden toimialojen hankintamalleja ohjelmistoprojekteihin. Tällä hetkellä julkiset IT-hankkeet Suomessa ovat valitettavasti vain muutaman suuren yrityksen temmellyskenttä, mikä myös heikentää kilpailua. Voisi olla mielenkiintoista tutkia ja kokeilla, jos tällaisia isoja IT-hankkeita voitaisiin pilkkoa pienempiin osiin, jolloin myös ketterien menetelmien käyttö voisi olla hyvinkin mielekästä.

    Ymmärrän, että kirjoituksesi idea ei ole vastata Apotin IT-kysymyksiin, vaan tarjota vaihtoehto Apotin julkisen hankinnan, projektoinnin ja budjetoinnin perinteisille haasteille. Vastaan kuitenkin vielä edellisestä kommentistani nostamiisi pointteihin.

    Potilastietojärjestelmien integroimiseen liittyen tarkoitin lähinnä datan integroimista enkä niinkään vanhojen järjestelmien integroimista. Myönnän, että minun olisi pitänyt olla täsmällisempi sananvalinnassa. Se olisi sulaa tyhmyyttä lähteä integroimaan satoja vanhoja järjestelmiä, jotka alun perin ovat meidät tähän tilanteeseen saattaneet. Näiden satojen vanhojen potilastietojärjestelmien integroiminen räjäyttäisi viimeistään Apotti-hankkeen budjetin ja tekisi ylläpidosta erittäin kallista. Vanhoissa potilastietojärjestelmissä olevat tietomallit ja data on kuitenkin pakko yhdenmukaistaa ja yhdistää. Ei niitä voi heittää poiskaan ja aloittaa täysin tyhjältä pöydältä. Ilman tätä taakkaa Apotti-hanke olisi huomattavasti helpompi ja halvempi toteuttaa.

    Laajakaistan kuuluminen välttämättömiin yleispalveluihin ei mielestäni ole mikään peruste Apotin verkkoyhteyksien toimimiselle. Yritysten tietojärjestelmät ovat käyttäneet nopeita verkkoyhteyksiä kauan ennen kuin laajakaistasta tuli niin kutsuttu välttämätön yleispalvelu. Lisäksi kuluttajille ja yrityksille yleisesti tarjottu laajakaistakin joskus pätkii eikä toimi. En tiedä, mitä ominaisuuksia Apottiin on suunniteltu, mutta on tietenkin mahdollista, että kansalaisille tarjotaan joku oma käyttöliittymä esimerkiksi omien potilastietojen tarkistamiseen. Tämän käyttöliittymän tarjoaisin ehdottomasti verkkopohjaisena ja silloin kuluttajien laajakaistalla on palvelun saatavuuden kannalta merkitystä.

    Mikä sitten on niiden lääkärien ja sairaanhoitajien käyttöliittymä, jotka ensisijaisesti käyttävät Apottia omassa työssään? Tälle käyttäjäryhmälle Apotin saatavuus ja luotettavuus ovat erityisen tärkeitä laatuvaatimuksia. Puolen tunnin mittainen katkos Apotissa voi muodostua jo hyvinkin isoksi ongelmaksi sairaalassa. Apotin tarjoaminen pilvipalveluna on tietenkin kiinnostava idea, mutta voitaisiinko palvelun saatavuuteen luottaa kaikissa tilanteissa? Pitäisikö jokaiseen sairaalaan ja terveysasemaan Suomessa vetää useammat verkkokaapelit, siltä varalta, että verkkoyhteys yhden kaapelin kautta Apottiin katkeaa? En usko, että se on niin yksinkertaista, että Apotti pistetään pyörimään yhteen palvelinbunkkeriin varmennettuna. Todennäköisesti palvelinbunkkereita tarvitaan useampi ja verkkoyhteyksien toimivuus palvelinten ja sairaaloiden välillä pitää myös jotenkin varmistaa. Tämä voi olla edessä riippumatta siitä toteutetaanko Apotti verkkopalveluna vai desktop-pohjaisena. Toisaalta voi jopa olla, että sairaaloiden nykyisten järjestelmien verkkoyhteydet on jo jotenkin varmistettu.

    Vanha teknologia ei aina ole sama kuin huono teknologia, eikä vanha tarkoita, että teknologia välttämättä olisi vanhentunut. Vanha teknologia voi toimia huomattavasti varmemmin kuin uusi teknologia, koska siitä on enemmän kokemuksia pidemmän käytön takia. Lopulta voi käydä niin, että uusi teknologia ajaa vanhan ohi, mutta desktop-teknologian tapauksessa en sanoisi näin vielä tapahtuneen. Sitten kun tietokoneeni ja älypuhelimeni käyttöjärjestelmät pyörivät pilvipalveluna, niin tilanne on toisin. Toistaiseksi natiivit sovellukset toimivat älypuhelimessani usein paremmin kuin verkkopohjaiset ja monet desktop-sovellukset toimivat myös paremmin kuin verkkopohjaiset kilpailijansa. Poikkeuksiakin tähän löytyy ja tilanne kehittyy koko ajan. Olkiluoto kolmonen ja Talvivaara osoittavat kuitenkin millaisia riskejä uuden teknologian käyttöönotto ja käyttäminen voivat tuoda mukanaan. Siinä mielessä ei ole välttämättä ollenkaan perusteetonta polttaa puoli miljardia euroa hyväksi todettuun ja ”vanhaan” teknologiaan kuin uuteen teknologiaan. Lisäksi täytyy muistaa, miten desktop-sovelluksen ja verkkopalvelun tietoturvan varmistaminen onnistuu. Desktop-Apotti tarvitsisi tietenkin myös verkkoyhteyksiä, mutta desktop-Apotti saattaisi virhetilanteissa toimia paremmin kuin verkkopalveluna toteutettu Apotti.

    Jos palataan asiaan eli hankintamalleihin, niin minun mielestä kannattaisi verrata Apotti-hanketta vastaavankokoisiin ja kriittisiin hankintaprojekteihin. Jos nyt nostan Facebookin taas esimerkkinä, niin siihen on siinäkin mielessä huono verrata Apottia, koska Facebookia ei ole toteutettu hankintaprojektina. Jos tiivistän blogikirjoituksesi viestin karkeasti, niin se on kutakuinkin Apotti-hanke + ketterät menetelmät = todennäköisesti onnistunut + halvempi projekti. Onko sinulla tietoa, onko Apotti-hankkeen kokoa ja kriittisyyttä vastaavia hankintaprojekteja toteutettu aikaisemmin ketterillä menetelmillä maailmalla? Olisi todella mielenkiintoista kuulla, miten vastaavanlaiset projektit ovat onnistuneet ja niistähän voisi myös ottaa oppia, jos Apotti-hanke vaikka toteutettaisiin ketterillä menetelmillä. Ihan mielenkiinnosta haluaisin myös kysyä sinulta sopivatko ketterät menetelmät mielestäsi kaikkiin projekteihin projektin kokoon, kriittisyyteen tai muuhun kontekstiin katsomatta?

    Kommentistani tuli paljon pidempi kuin odotin, mutta lopuksi haluaisin vielä sanoa, että toivottavasti tästä Apotti-hankkeesta otetaan sen verran opiksi, että kunnat tekevät jatkossa tietojärjestelmien hankkeet edes jossain määrin keskitetysti sen sijaan, että jokainen kunta tilaa omat järjestelmänsä. Silloin voitaisiin jatkossa välttyä sellaisilta ongelmilta, joita Apotti-hankkeeseen nyt liittyy.

    Hyvää ja aurinkoista kevättä!

    • Hei Jari ja kiitos tarkennuksista! Tosi hienoa, että tämä asia kiinnostaa sinua.

      Tunnet varmaan vanhan vitsin: ”Vale, emävale, tilasto”. Tutkimuksiin on aina hyvä suhtautua pikku varauksella. Arvostan kovasti sitä, että sinä ja agile-genressä toimivat ihmiset kyseenalaistavat Standish Groupin tutkimustuloksen (joka on kieltämättä paradoksaalista: http://larelekman.com/2012/09/01/onnistu-kolme-kertaa-todennakoisemmin). Tämä kuvastaa mielestäni ketterää kulttuuria, jossa arvostetaan läpinäkyvyyttä ja suoraa kommunikointia.

      Standish Groupin tutkimus on puutteistaan huolimatta senverran tunnettu ja laaja, ettei sen tuloksia voi täysin sivuuttaa. Tapaan päivittäin kaikenkokoisia firmoja pörssiyhtiöistä startupeihin, joissa treenataan tätä uutta tapaa tehdä asioita. Sain juuri tänään USA:sta uutta tutkimustietoa, josta kirjoitan seuraavaksi. Tiivistettynä 83% noin 4000:sta vastanneesta henkilöstä aikoo jatkossa tehdä ketteriä projekteja. Vuosi sitten luku oli 59%. Kasvu on aikamoinen.

      Agile/Scrum/Lean ei todellakaan itsessään lupaa mitään. Se vain tarjoaa viitekehyksen, jossa onnistuminen on todennäköisempää kuin aikaisemmin. Itselleni riittäisi hyvin ”vain” kaksinkertainenkin todennäköisyys, kun puhutaan Apotista ja parin miljardin verorahoista.

      Internet-pohjainen Apotti on ihan oma unelmani. Jos nyt kuitenkin otetaan vertailuun esimerkiksi Nordean verkkopankki, en muista montaakaan minuuttia 10 vuoden aikana, jolloin palvelu olisi ollut itselleni saavuttamattomissa tavallisella kotiyhteydellä. Fyysisen Internet-yhteyden turvaamiseksi voisi ehkä käyttää useampien operaattoreiden langattomia 3G-modeemeja, joiden kaista jaettaisiin sairaalan verkkoon Apotti-käyttäjien kesken.

      Jos lyhyt katkos kuitenkin sattuisi backup-yhteyksistä huolimatta, tarjoaa esim. HTML5 mahdollisuuden tallentaa selaimen muistiin paikallista tietoa, jonka voi synkronoida palvelimelle, kun yhteys palaa (http://mislav.uniqpath.com/diveintohtml5/storage.html). Palvelimet tietysti varmennettaisiin pommin- ja virheensietoisiksi useampiin bunkkereihin alan parhaiden käytäntöjen mukaan. Valtionhallinto joutuu joka tapauksessa ratkaisemaan kriittisten internet-palveluiden saatavuuden kriisiaikana. Mutta se tekniikasta, kun menee ohisektorille… Pointtini on, että internet-pohjainen keskitetty Apotti todennäköisesti kasvattaisi projektin onnistumisen mahdollisuuksia huomattavasti. Tottakai se alustettaisiin nykyisellä potilastiedolla, joka kerättäisiin nykyisistä purkeista ja harmonisoitaisiin yhteen.

      Toivon itsekin sydämestäni, että saisimme Apotista kelpo esimerkin keskitetystä julkishallinnon hankkeesta, johon kaikki osapuolet aktiivisesti sitoutetaan ja sitoutuvat. Joskus on käynyt niinkin, että valtion keskitetty suurhanke epäonnistuu, kun käyttäjät eivät jaksa odotella järjestelmää ja hankkivat omat ratkaisunsa. Ketterä malli pienentää tällaista mahdollisuutta, koska se ”sitouttaa” asiakkaita luontevasti mm. välikatselmuksilla, aktiivisella palautteen pyytämisellä, vuoropuhelulla ja nopeammalla käyttöönotolla. Toivottavasti Apottikin voisi hyödyntää ja onnistua näissä.

      Mukavaa kevättä Jari!

Kommentoi

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out / Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out / Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out / Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out / Muuta )

Muodostetaan yhteyttä palveluun %s