Näin VR sotki lippujärjestelmänsä – Miksi it-projektit epäonnistuvat?

Lauri Vanhala
Kotimaa 30.1.2012 11:00

VR:n uusi lipunmyyntijärjestelmä maksoi 15 miljoonaa euroa. Sen rakentaminen kesti kolme vuotta. Järjestelmä kesti käytössä noin kolme tuntia.

Syyskuun 14. päivän aamu ei ollut vielä valjennut, Helsingin päärautatieaseman kello näytti neljää. VR:n tietohallintojohtaja Jukka-Pekka Suonikko oli ollut työpaikallaan pian vuorokauden, edellisestä aamusta asti.

Suunnitelma oli kirjattu Exceliin minuutin tarkkuudella, sillä aikaa oli vähän: vain yksi yö. Vanha järjestelmä suljettiin, kun VR:n lipunmyynti hiljeni syyskuun 13. päivän iltana. Seuraavana aamuna uuden lipunmyynnin piti olla jo käytössä.

Kaikki näytti hyvältä. Uusi verkkokauppa oli juuri avattu, ja valvontamonitorit kertoivat, että ensimmäiset uteliaat surffaajat olivat jo löytäneet sivustolle. Päivästä tulisi vilkas.

Myös media seuraisi tarkasti, kuinka VR:n lipunmyyntiuudistus sujuu.

Kyseessä oli VR:n historian laajin it-projekti. Miljoonien eurojen myyntijärjestelmän uudistusta oli tehty jo vuodesta 2008. Lippuautomaatit ja konduktöörien laitteet oli vaihdettu ja vanhahtava verkkopalvelu oli päivitetty nykyaikaisemmaksi.

Oikeastaan uudistuksen piti olla valmis talvella, mutta aikataulu oli venynyt kaksi kertaa, koska ohjelmistot ja laitteistot olivat olleet keskeneräisiä. Julkaisua oli siirretty ensin maaliskuusta kesäkuuhun ja sitten syyskuun 14. päivään.

Junamatkustajille uusi lipunmyyntijärjestelmä oli sivuasia, isompi uutinen oli junalippujen hinnoittelun uudistuminen. Junalipusta saisi alennusta, jos sen ostaisi etukäteen.

Yleisöryntäys oli odotettavissa, joten VR oli pelannut varman päälle. Asiantuntijat olivat suunnitelleet järjestelmän, joka kestäisi pahimmatkin kävijäpiikit. Kapasiteettia oli lisätty vielä puolella asiantuntijoiden suosituksen päälle.

Rautatieaseman neljännen kerroksen projektitiloissa kävi kuhina läpi yön, kun 40 hengen asiantuntijajoukko ohjasi ja valvoi käyttöönottoa. Vanhoja järjestelmiä suljettiin, liikennettä ohjattiin uusiin.

Aamuviideltä avattiin Turun Kupittaan lipunmyynti, ensimmäinen asiakaspalvelupiste. Kaikki sujui hyvin.

Suonikko seurasi monitorilta verkkopalvelun kävijämääriä. Aamuseitsemältä ihmisten herääminen alkoi näkyä kasvavana liikennevirtana. Kahdeksalta tietoliikenne oli jo vilkasta.
Kahdeksan ja yhdeksän välillä kävijämäärä rikkoi kaikki aiemmat ennätykset – myös turvarajat, joiden mukaan järjestelmä oli suunniteltu.

Pian osa asiakkaista ei päässyt enää palveluun, ja nekin jotka pääsivät, joutuivat odottamaan sivujen latautumista pahimmillaan kymmeniä sekunteja. Tilanne paheni keskipäivän lähestyessä.

VR:n pääkonttorin naapurissa, päärautatieaseman lipunmyynnissä, asiakkaat alkoivat hermostua. Asiakaspalvelun laitteet muuttuivat yhä hitaammiksi, ja uudet pirteänvihreät lipunmyyntiautomaatit jumiutuivat ympäri Suomen.

Kaikki junaliput myydään saman varausjärjestelmän kautta, minkä vuoksi verkkopalvelun tuoma asiakastulva haittasi myös paperilippujen ostamista. Lopulta lippuja sai vain konduktööreiltä.

Pelkkä kävijämäärä ei kuitenkaan selittänyt kaikkia ongelmia, järjestelmässä oli jotain muutakin mätää. Suonikon työpäivä venyi 38 tunnin mittaiseksi.

Ohjelmoinnista tuli helppoa

Mikä it-alaa vaivaa? Hankkeet tuntuvat epäonnistuvan, vaikka niiden tavoitteet vaikuttaisivat yksinkertaisilta, kuten helppokäyttöisen lippukaupan tekeminen.

Sähköinen resepti viivästyi vuosikausia. Sampo Pankin asiakkaat saivat kärsiä, kun sen tietojärjestelmät yhdistettiin Danske Bankin kanssa. Kuntavaalit jouduttiin uusimaan Karkkilassa, Kauniaisissa ja Vihdissä, kun sähköinen äänestysjärjestelmä hukkasi 232 ääntä.

Lisäksi hankkeiden budjetit pyörivät mittaluokassa, jota on vaikea ymmärtää, ellei ole ollut niissä osallisena.

Huomiota on herättänyt muun muassa eduskunnan uusi tietojärjestelmä, jonka avulla asiakirjoja voi käsitellä sähköisesti yhden yhteisen järjestelmän kautta. Se tilattiin 4,7 miljoonalla eurolla.

On perusteltua ihmetellä, kuinka esimerkiksi julkishallinnon projektit maksavat yhä miljoonia, vaikka ohjelmointityö muuttuu vuosi vuodelta helpommaksi. Erilaiset lippupalvelut, lomakkeet ja viestintäjärjestelmät on tehty jo useaan otteeseen, ja niiden suunnittelua opetetaan yliopistojen peruskursseilla.

Samaan aikaan muutaman hengen start-up-yritykset ympäri maailman tekevät teknisesti edistyksellisiä tuotteitaan murto-osan budjetilla.

”Tuntuu, että julkishallinnon hankkeissa on jämähdetty 20 vuoden takaiseen aikaan, jolloin tietoprojektit olivat jättihankkeita”, sanoo tekniikan tohtori Risto Sarvas ohjelmistoyritys Futuricesta.

”Tärkein huomio on, että it-järjestelmät eivät ole enää suuria ja kalliita eivätkä ne vaadi vuosien kehittämistä.”

Tekniikka on kehittynyt merkittävästi 1990-luvulta. ”Ohjelmakoodin tuotantokustannukset lähenevät nollaa”, Sarvas sanoo.

Toimiviksi havaittuja, valmiita ratkaisuja on olemassa niin paljon, että ohjelmoija saa aikaan näkyviä tuloksia yhä nopeammin.

Alan harrastajakin pystyy valmiita osia ja palveluita hyödyntämällä rakentamaan verkkosivuston, joka palvelee joustavasti ja katkotta koko Suomen käyttäjiä. Eikä sen tekemiseen tarvitse käyttää vuosikausia tai edes kuukausia, saati satojatuhansia euroja.

Tilauksissa paljon turhaa

Ongelmat alkavat usein jo ostamisesta – ennen kuin riviäkään ohjelmakoodia on kirjoitettu.

Laki vaatii kilpailuttamaan yli 30 000 euron arvoiset julkiset ohjelmistohankinnat. Silloin tilaaja laatii tarjouspyynnön, jossa kuvataan järjestelmältä vaaditut ominaisuudet sekä kerrotaan ne kriteerit, joilla toimittajavalinta tehdään.

Lain mukaan toimittaja täytyy valita joko hinnan tai kokonaistaloudellisuuden perusteella. Se voi viitata esimerkiksi käyttökustannuksiin tai muihin tarjouspyynnössä mainittuihin kriteereihin.

Nykyistä hankintamallia kritisoidaan usein epäsopivaksi ohjelmistojen, eli asiantuntijatyön ostamiseen. Yksi ongelma on hankintojen paisuminen, kun työtä ostetaan projektiluontoisesti.

Hankintamenettelyssä ohjelman ominaisuudet pyritään määrittämään huolellisesti etukäteen. On kuitenkin äärimmäisen vaikea ennustaa, mitkä ominaisuudet ovat oleellisia ja mitkä eivät.

Mukaan otetaan varmuuden vuoksi vähän liikaakin. Usein siteeratun tutkimusyritys Standish Groupin arvion mukaan tilattujen ohjelmistojen ominaisuuksista 45 prosenttia on turhia.
Se tarkoittaa montaa haaskattua euroa ja työtuntia.

”Nykyään yritetään priorisoida niitä ominaisuuksia, jotka ovat ehdottoman tärkeitä, mutta se on helpommin sanottu kuin tehty”, sanoo ohjelmistotekniikan professori Pekka Abrahamsson Helsingin yliopistosta.

Jättimäiseksi kasvaville hankkeille on Suomessa vähän tekijöitä. Toimittaja joutuu puntaroimaan suurten hankkeiden riskiä tarkkaan, sillä tarkan työmääräarvion tekeminen on aina jossain määrin arvailua. Toisaalta tilaaja haluaa vakavaraisen ja luotettavan – eli suuren – toimittajan.

Jäljelle ei jää Suomessa montaa ehdokasta. Uutisissa pyörivät samat nimet, kuten Accenture, Tieto, Logica ja Fujitsu.

Toimittajavalinnassa hinnan merkitys on suuri. Tarjouskilpailuista tippuneet yritykset esittävät usein toivomuksen siitä, että laatua arvioitaisiin nykyistä tarkemmin ja sen merkitystä korostettaisiin.

Heikkolaatuisen ohjelmiston korjailu ja ylläpito voivat osoittautua monin kerroin luultua vaikeammiksi tai kalliimmiksi.

VR:llä yllättäviä vikoja

”Työtä todella tehtiin yötä päivää”, VR:n Suonikko sanoo. Alihankkijat pyysivät paikalle asiantuntijoita ulkomailtakin. Oli kiire, koska koko järjestelmä oli jumissa, myös lipunmyyntiautomaatit.

Uusi palvelu oli suunniteltu kestämään helposti suurin koskaan koettu kävijämäärä, tuhkapilven aikana syntynyt 420 000 latauksen ennätys. Ensimmäisenä päivänä latauksia oli 1,2 miljoonaa.

Jonottamista ei tietokonemaailmassa tunneta, vaan kaikki verkkokaupan kävijät pyrkivät virtuaaliselle lippuluukulle samanaikaisesti. Kaikki verkkopalvelun asiakkaat saavat huonoa palvelua, jos laitteiden teho loppuu kesken.

Hitausongelmaa alettiin ratkoa monella eri suunnalla, sillä varausjärjestelmä oli rakennettu alihankkijoiden yhteistyönä.

Accenture oli vastannut järjestelmän tekemisestä, mutta sen alihankkija Enfo oli toimittanut lipunmyyntiautomaatit ja konduktöörien laitteet. Tieto vastasi konesaleista ja palvelimista, joilla järjestelmä pyöri. Lisäksi yksi osa, paikkavarausjärjestelmä, oli peruja vanhasta lippukaupasta, ja oli alun perin Logican tekemä.

VR pyysi Tietoa kolminkertaistamaan palvelinkapasiteetin heti ensimmäisenä päivänä. Se ei kuitenkaan ratkaissut tilannetta. Paljastui, että palvelimet toimivat epävakaasti, koska niiden ohjelmistoissa oli tunnettu, mutta korjaamatta jäänyt vika.

Ongelma ei ollut paljastunut kuormitustesteissä. Lippuja myydään automaateissa, tiskeillä, verkossa ja junassa, eikä joka suunnasta tulevaa kuormitusta ollut osattu simuloida etukäteen tarpeeksi realistisesti.

Paljastui myös, että lippuautomaateissa oli vika, joka kuormitti muuta varausjärjestelmää tarpeettomasti. Automaatit päätettiin sulkea korjaustöiden ajaksi. Ne venyivät lopulta lähes kahteen viikkoon.

Tärkein hyytymisen syy oli kuitenkin yllättävän suuri kävijämäärä, Suonikko sanoo.

”Heti alkupäivien aikana huomattiin, että kuormitus jää hyvin korkealle tasolle eikä tule palaamaan lähellekään sitä, mitä se oli aiemmin.” Alun huippulukujen jälkeen sivulatausten määrä jäi yli 500 000:een, yli kaksinkertaiseen aiemmasta.

Verkkokaupassa otettiin käyttöön ominaisuus, joka rajoittaa kävijämäärää silloin, kun samanaikaisia käyttäjiä alkaa olla liikaa. Pikaisesta muutoksesta seurasi ongelmia: osa asiakkaista ei enää saanut lippua, vaikka rahat katosivat tililtä.

Virheellisesti toiminut rajoitin saattoi potkia maksaneen asiakkaan ulos palvelusta ennen kuin tämä ehti saada lippuaan. Tämäkin ongelma oli jäänyt testeissä löytämättä. Rajoitinominaisuutta ei ollut alun perin tarkoitus edes käyttää.

Kun käyttöönotosta oli kulunut viikko, korjaustyöt olivat edelleen kesken.

Iso hanke onnistuu harvoin

It-projektia ei voi johtaa tehdastyön periaattein. Jo vuonna 1975 IBM:n insinööri Fred Brooks huomasi tärkeän piirteen: myöhässä olevaan ohjelmointiprojektiin ei kannata lisätä työvoimaa, sillä se saa projektin myöhästymään entistä enemmän.

Ohjelmistosuunnittelu on asiantuntijatyötä, joka vaatii omat johtamistapansa. Mutta parhaiden käytäntöjen keksiminen on osoittautunut vaikeaksi, eikä onnistumisia ole ollut helppo toistaa.

Ihmiset tekevät virheitä, ja niitä tulee sitä todennäköisemmin, mitä monimutkaisemmista töistä on kyse. Nasa hukkasi 120 miljoonan dollarin Mars-luotaimen, kun osa insinööreistä käytti metrijärjestelmää, osa brittiläistä.

Standish Groupin tutkimuksen mukaan vuonna 2009 vain 32 prosenttia uusista it-projekteista valmistui aikataulussa ja budjetissa, ilman merkittäviä virheitä.

Sen aiemmassa tutkimuksessa kävi ilmi, että yli kymmenen miljoonan dollarin hankkeista onnistui vain joka viideskymmenes. Alle 750 000 dollarin hankkeista onnistui 46 prosenttia.
Standish Group arvioi it-hankkeita tutuin projektimittarein: pysyivätkö ne aikataulussa, tuliko yllätyksiä, ylittyikö budjetti.

Tapaa on moitittu huonoksi, sillä käyttäjät arvioivat onnistumista eri tavoin. Lääkärille sähköinen potilastietolomake on hyödyllinen vain, jos sen käyttö on paperilomaketta nopeampaa tai jos se parantaa potilasturvallisuutta.

Mitä hyötyä on arviosta, josta ei käy ilmi, onko ”onnistunut” järjestelmä helppokäyttöinen vai lähes käyttökelvoton?

Kankeus käy kalliiksi

It-epäonnistumisten taustalla on usein sama syy: liian etupainotteinen suunnittelu.

It-hankkeissa olisi tärkeää pystyä pitämään uutta tietoa ja uusia ideoita positiivisina asioina, ei uhkina alkuperäiselle suunnitelmalle. Jos esimerkiksi koekäyttäjä tai ohjelmoija keksii tärkeän parannusidean, olisi hyvä, että muutos pystyttäisiin tekemään lopulliseen tuotteeseen.

Muutosehdotuksia tulee kuitenkin vuosikausia kestävien projektien aikana suunnattoman paljon. Jos työtapa on kankea, hyviäkään ideoita ei voi huomioida tai ne saattavat pysäyttää koko työn edistymisen.

Perinteisessä työtavassa, jossa projektin sisältö ja aikataulutus on saneltu etukäteen, ja kenties jopa vahvistettu tiukoin sopimuksin, törmätään ongelmiin. Tilaaja haluaa saada mahdollisimman paljon, toimittaja haluaa tehdä mahdollisimman vähän.

Lisäksi työskentely muistuttaa usein niin sanottua vesiputousmallia, jota on parjattu alan oppikirjoissa viimeiset neljäkymmentä vuotta.

Vesiputousmalli tarkoittaa työtapaa, jossa edetään suoraviivaisesti vaiheesta toiseen: ensin suunnitellaan, sitten toteutetaan, lopuksi testataan ja julkaistaan.

Sen seurauksena projektin puutteet paljastuvat vasta aivan loppuvaiheessa, jolloin niiden korjaaminen on vaikeaa ja erityisesti kallista.

Kokemus osoittaa, että toimivien ja helppokäyttöisten järjestelmien tekeminen edellyttää jatkuvaa testaamista ja koekäyttäjien osallistumista.

Se, että lääkärit kiroilevat huonosti toimivia ja vaikeasti käytettäviä tietojärjestelmiä, kielii vesiputousmallin käyttämisestä: lääkärit osaisivat antaa korjausehdotuksia, mutta heidän ideoitaan ei voida huomioida, koska ominaisuudet lyötiin lukkoon jo vuosia sitten projektin alkuvaiheessa.

Sama ongelma vaivaa useita suurella budjetilla, yhtenä projektina tehtyjä palveluita: niissä on virheitä ja järjettömyyksiä, jotka on varmasti huomattu. Suunnan vaihtaminen vain on onnistunut yhtä kankeasti kuin Titanicilla.

Palaute korvaa suunnittelun

”On parempi epäonnistua nopeasti ja edullisesti kuin kolmen vuoden päästä jättimäisesti”, sanoo ohjelmistoyritys Reaktorin operatiivinen johtaja Timo Lukumaa.

Reaktor on yksi 2000-luvulla perustetuista suomalaisista ohjelmistoyrityksistä, jotka luottavat niin sanottuihin ketteriin menetelmiin it-hankkeiden toteuttamisessa. Uudet menetelmät pohjautuvat siihen huomioon, että suunnittelutyön ennustaminen pitkälle tulevaisuuteen on vaikeaa. Työ pyritään organisoimaan siten, että virhearvioinneista voidaan ottaa opiksi mahdollisimman pikaisesti.

Kun ohjelmiston tekeminen aloitetaan ketterin menetelmin, ei kirjoiteta monikymmensivuista vaatimusmäärittelyä. Sen sijaan selvitetään tarkasti, mitä käyttäjä haluaa ohjelmalla tehdä.

Sen jälkeen ohjelmistoa yksinkertaisesti aletaan toteuttaa, osa osalta.

Ohjelmiston ensimmäinen toimiva palanen valmistuu pikaisesti, ja sitä voidaan välittömästi arvioida.

Jos tiimi on tehnyt esimerkiksi sähköisen lomakkeen lääkärin käyttöön, lomake voidaan antaa oikean lääkärin arvioitavaksi, vaikka muu järjestelmä olisi vielä kesken. Palautteen pohjalta lomaketta voidaan parannella, ja uusi versio voi olla valmis jo seuraavalla viikolla.

Ajatustapaan kuuluu, että uusi versio ohjelmistosta voidaan julkaista vaikka päivittäin. Testausta tehdään jatkuvasti, jolloin loppuvaiheeseen ei pitäisi jäädä suuria yllätyksiä. Tiheän julkaisutahdin ansiosta asiakas näkee koko ajan, kuinka työ edistyy.

Sen sijaan, että projektille tehtäisiin vuosikausien pituinen tarkka aikataulu, ohjelmiston toiminnallisuuksia aletaan tehdä tärkeysjärjestyksessä. Kehitystyö voi tapahtua prosessina niin pitkään kuin se on järkevää. Useimmiten parannuksia tehdään pitkään julkaisun jälkeenkin, jopa palvelun eliniän ajan.

Mikään yksittäinen menetelmä ei ole kuitenkaan ratkaisu it-alan ongelmiin. Ketteristä menetelmistä on saatu hyviä kokemuksia, mutta nekään eivät pakota esimerkiksi suunnittelemaan käyttäjäystävällisiä järjestelmiä.

Jälkiviisaus on helppoa

Yhteistyön ongelmat vaivaavat jokaista it-hanketta. Tiedonkulku vaikeutuu, kun projektiin osallistuu eri alojen ihmisiä eri yrityksistä. Lisäksi yhteistyöhön osallistuvat alihankkijat ovat usein kilpailijoita keskenään.

VR:n alihankkijoilta meni viisitoista päivää ongelmien korjaamiseen. Mitä projektista voisi oppia?

”Jälkiviisaus on aina helppoa”, Suonikko toteaa. ”Teknisen suorituskyvyn kysymykset eivät ole itsestään selviä ja niihin täytyy suhtautua vakavasti.”

Suonikko painottaa myös kokonaisvastuun merkitystä projektissa, jossa on monta alihankkijaa.

”Siinä tilanteessa kun ongelma syntyy, ei voi tehdä muuta kuin korjata se kuntoon”, Suonikko toteaa. Tärkeintä olisi kuitenkin estää ongelmien synty jo etukäteen. ”Jälkeenpäin nousee kysymys, oliko yhteistyö sittenkään riittävän toimivaa.”

VR uusi verkkopalvelunsa, jotta sen kehittäminen olisi jatkossa helpompaa. Tulossa on esimerkiksi uusia mobiilipalveluita. ”Ollaan tietyllä tavalla kehityspolun alussa”, Suonikko sanoo.

Mutta ihmisen muisti on valikoiva. Kehityspolusta, uusista ominaisuuksista ja uudesta hinnoittelusta huolimatta matkustajat muistavat vain, kuinka vaikeaa junalipun ostaminen oli syksyllä 2011.

Esimerkkinä Sampo Pankki, Sitra ja eResepti

Sampo Pankin 200 miljoonan euron tietojärjestelmäuudistus vuonna 2008 lähti liikkeelle kangerrellen.

Pankin järjestelmät oli määrä yhdistää emoyhtiö Danske Bankin järjestelmiin pääsiäisen aikana, mutta uudistuspäivänä verkkosivuilla näkyi pelkkä vikailmoitus.
Se oli vasta alkusoittoa.

Alihankkija IBM:n laitteet kaatuivat kolme päivää käyttöönoton jälkeen. Lisäksi järjestelmästä löytyi lukuisia ohjelmointivirheitä.

Seuraavina kuukausina maksukortit lakkasivat useita kertoja toimimasta, ja asiakkaat valittivat verkkopankin toimintahäiriöistä.

Danske Bankin toimitusjohtaja Peter Straarup antoi Helsingin Sanomille elokuussa 2008 tutulta kuulostavan selityksen julkaisupäivän ongelmista:

”Verkkopankin käyttömäärä ylitti kolminkertaisesti arvion, jonka saimme Suomesta. Ihmiset olivat uteliaita ja tulivat kokeilemaan uutta pankkia. Ensimmäisenä päivänä verkkopankkiin kirjautuneiden määrä oli aivan eri tasolla kuin koskaan edellisen järjestelmän aikana.”

Sampo Pankki menetti vuonna 2008 yli 27 000 henkilöasiakasta. Lisäksi se maksoi hyvitysmaksuja saman vuoden huhti-kesäkuussa kuuden miljoonan euron edestä.

Hidas eResepti

”Emme anna minkäänlaista aika-arviota, koska koekäyttö on siirtynyt jo viisi kertaa”, ilmoitti Kotkan kaupungin projektipäällikkö Johanna Andersson Mediuutisille helmikuussa 2010.

Sähköisen reseptin käyttöönoton piti alkaa Suomessa jo vuonna 2008, mutta toisin kävi. Kotkassakin ensimmäinen resepti kirjoitettiin vasta huhtikuussa 2011.

Ajatuksena sähköinen resepti kuulostaa simppeliltä. Lääkäri kirjaa lääkemääräyksen reseptijärjestelmään, josta apteekki voi sen tarkistaa. Paperilappuja ei tarvita, vaan potilas voi noutaa lääkkeet pelkällä henkilötodistuksella.

Järjestelmän käyttöönotto on kuitenkin viivästynyt.

Apteekeissa ja terveysasemilla on käytössä useita eri tietojärjestelmiä, jotka täytyy kaikki saada keskustelemaan kansallisen järjestelmän kanssa.

Järjestelmätoimittajia on useita, ja yhteistyön hitaus on yllättänyt. Viimeisimpien arvioiden mukaan sähköinen resepti on joka toisen suomalaisen ulottuvilla vasta tämän vuoden lopussa.

Lain mukaan sähköisen reseptin tulee olla käytössä julkisessa terveydenhuollossa huhtikuussa 2013 ja yksityisessä huhtikuussa 2014.

Ketterä hankinta

Kun Suomen itsenäisyyden juhlarahasto Sitra alkoi uudistaa verkkopalveluaan vuonna 2010, se haki hankkeelle toteuttajaa poikkeuksellisella kilpailutuksella.

Kilpailutuksen ensimmäisessä vaiheessa hakijoiden tuli nimetä työhön tarjoamansa tiimin jäsenet. Sitra arvioi yrityksiä ja niiden ehdottamia tiimejä yksittäisten jäsenten työkokemuksenperusteella ja lähetti lopulta tarjouspyynnön kahdeksaan paikkaan.

Toisessa vaiheessa tarjouksia arvioitiin perinteisemmin: Sitra arvioi muun muassa yritysten tekemiä verkkosivuluonnoksia sekä ehdotettuja teknologioita ja työtapoja.

Kilpailutus päättyi tulikokeeseen, jossa kaksi finalistiyritystä sai viikon aikaa näyttää osaamisensa. Molemmat yritykset saivat 150 tuntia ja 5 000 euroa Sitran verkkopalvelun demoversion toteuttamiseen mahdollisimman pitkälle.

Sitra laati listan toivotuista ominaisuuksia, ja yritykset saivat päättää, mitä ominaisuuksista ne halusivat toteuttaa. Suorituksia arvioitiin työn tehokkuuden, työmenetelmien ja laadun perusteella.

Molemmat tarjoajat rakensivat kiireisen pyrähdyksen aikana toimivan demosivuston, jossa oli suuri osa toivotuista ominaisuuksista.

Juttu on julkaistu ensimmäistä kertaa Suomen Kuvalehdessä 3/2012.

Kuvitus Jorma Marstio, Katja Saarela, Markus Pentikäinen, Lehtikuva.

Keskustelu

VR:n tapauksessa oli kyseessä asiakkaiden järjestämä laajamittainen palvelunestohyökkäys. Jos Suomen laki tuomitsisi jyrkemmin moisen toiminnan, asiakkaat olisivat sakkokorvausten suunnattoman määrän vuoksi lopulta maksaneet koko VR:n järjestelmän (, vaikka ehkä he sen oikeasti maksoivatkin mutta ilman oikeusistuntoja).

”Mikä it-alaa vaivaa? Hankkeet tuntuvat epäonnistuvan, vaikka niiden tavoitteet vaikuttaisivat yksinkertaisilta, kuten helppokäyttöisen lippukaupan tekeminen.”
Kyllä myöhästymisiä on muuallakin. Luepa lehtien otsikot Olkiluodon uusimmasta ydinvoimalaprojektista, erilaisista (sortuvista) tierakennusprojekteista tai vastavalmistuneista kerrostaloista, joissa vesijohto-, likaviemäri- tai ilmastointiliitännät ovat menneet sekaisin.

”Mikä it-alaa vaivaa? Hankkeet tuntuvat epäonnistuvan, vaikka niiden tavoitteet vaikuttaisivat yksinkertaisilta, kuten helppokäyttöisen lippukaupan tekeminen…
On perusteltua ihmetellä, kuinka esimerkiksi julkishallinnon projektit maksavat yhä miljoonia, vaikka ohjelmointityö muuttuu vuosi vuodelta helpommaksi.”
IT-alaa vaivaavat (ylioptimoidut asiakas)projektit. Mielestäni Suomessa (tai suomalaisperäisissä yrityksissä) tehdään monenlaista hienoa ohjelmistokehitystä. Ainakin luulen niin, koska muuten en olisi tänäänkään päässyt Koneen hissillä yläilmoihin tai en olisi onnistunut saamaan Nokian matkapuhelimellani yhteyttä tukiasemaan ja soittamaan puheluani.

Ohjelmointityö ei ole tullut helpommaksi, ei ainakaan, jos siihen lasketaan pelkän ohjelmoinnin lisäksi myös tuotteen tai palvelun määrittely, suunnittelu, testaus sekä kaikki asiaankuuluva (tai -kuulumaton) hallintohömppä. Päinvastoin ohjelmistokehitys on muuttunut entistä mutkikkaammaksi, koska markkinoilla on suunnaton määrä erilaisia kehitystyökaluja ja ’(puoli)valmiita’ ratkaisuja, joista pitäisi osata optimoida kustannustehokkain (eli nykyään yleensä nopeiten toteutettava ja mielellään ilmainen) ratkaisu, joka skaalautuu sujuvasti tarpeiden mukaan (tai ’kasvaa isältä pojalle veroja kiertäen’), joka toimii monenmoisissa laitteistoissa ja ympäristöissä, joka käyttökokemuksellaan houkuttaa ja koukuttaa asiakkaat sekä joka tietoturvan tasollaan häikäisee pahimmatkin verkkokonnat.

Moni muukin asia kuin tieto- ja reikäkorttikone on muuttunut ohjelmistokehityksessä. Seinät kaadettiin 1980-luvulla ja tilalle tulivat avokonttorit. Projekteja alettiin tosissaan hajauttaa erilaisille konsulttiyrityksille ja jopa ulkomailla majaileville tiimeille 1990-luvulla. Ketteriä, hetivalmisuusiominaisuus-projekteja alettiin kokeilla 2000-luvulla. Alkaneen vuosikymmenen trendinä on sutaista kuvitusta roskikseen päätyvään paperiin, jutella päivän uutiset päivittäisessä pikapalaverissa, viestitellä ongelmista sähköpostilla, puhelimella ja pikaviestimilla ja unohtaa kaikkien ongelmien ja muutosten ja kaiken opitun kirjaaminen pysyvästi talletettuun tietopankkiin, minkä takia vuosien päästä ei enää muisteta, miksi johonkin ratkaisuun lopultakin päädyttiin, eikä valittukaan sitä ilmeisintä vaihtoehtoa.

Jos siis väitetään, että itse ohjelmointi on tullut helpommaksi ja ohjelmistojen laatu romahtanut viimeisten 30 vuoden aikana, voidaankin etsiä syitä työympäristöistä, projektien hajanaisuudesta ja pakonomaisesta kiireestä. Tieto ja (toivottavasti) tietämyskin on lisääntynyt, mutta ehkä ohjelmistotyöntekijöillä ei ole enää aikaa seuloa ja omaksua olennaista tietoa kaikesta ympärillä vellovasta suunnattomasta tietomassasta.

Lisäksi nykyajan nettimaailma on mahdollistanut palvelut, joilla on satoja miljoonia asiakkaita. On melko vaikeaa ennakoida kaikkien asiakkaiden ajattelutottumukset tai käyttötavat. Varsin usein palvelua suunniteltaessa kuvitellaan mielessä tavallinen mattimeikäläinen, joka käyttää palvelua hallitusti ja oikein juuri palvelun suunnittelijoiden toivomalla tavalla. Palvelua toteutettaessa ei aina varauduta erilaisiin keskiarvoista poikkeaviin omituisuuksiin, kuten vääränlaisiin tietoliikenneyhteyksiin, vanhentuneisiin nettiselaimiin, nörttien suosimiin käyttöjärjestelmiin ja laitteistokokoonpanoihin tai hyvin ilkeisiin, pahantahtoisiin ihmisiin (eli ’asiakkaisiin’).

”Se, että lääkärit kiroilevat huonosti toimivia ja vaikeasti käytettäviä tietojärjestelmiä, kielii vesiputousmallin käyttämisestä: lääkärit osaisivat antaa korjausehdotuksia, mutta heidän ideoitaan ei voida huomioida, koska ominaisuudet lyötiin lukkoon jo vuosia sitten projektin alkuvaiheessa.”
Ei kieli vesiputousmallista vaan siitä, että tuotteen määrittely on tehty huonosti. Määrittely- ja (käyttöliittymä)suunnitteluvaiheessa on itse asiakas (eli se kiroileva lääkäri ja hänen kohtalokumppaninsa) unohdettu. Tuotteen ovat suunnitelleet tekniikkaan ja sen mahdollisuuksiin huonosti perehtynyt konsulttitalon markkinointipäällikkö ja sairaanhoitopiirin hallintobyrokraatti, joka ei ole itse ajatellut käyttää ostamaansa tuotetta. Lopulliseen tuotteeseen osia tekevät henkilöt eivät välttämättä koskaan saa tietää, mitä koko tuotteen pitikään tehdä. (Ehkäpä nykykoodarit, -suunnittelijat tai -testaajat eivät koe tuotetta omakseen, eivätkä kyseenalaista määrittelyistä taVaamiaan epäilyttäviltä vaikuttavia kohtia, koska he eivät tiedä tuotoksensa lopullista kohdetta ja tarkoitusta, koska heillä ei ole omasta tai kulttuurinsa mielestä oikeutusta tai valtaa kyseenalaistaa asioita tai koska heillä ei edes ole tietämystä tai tietoa, miten tai mistä kysyä tai löytää sujuvasti oikeaa tietoa.)

Ketterä kehitys on vain yksi trendi satojen edellisten joukossa. Aikaa myöten sekin korvautuu jollain toisella ja joidenkin muiden markkinoimalla silmänlumeella. Usein äärimmäisyydet seuraavat toinen toistaan. Ehkä vielä jonakin päivänä löydetään se kultainen keskitie, jota keskiarvopaavonkin on helppo noudattaa.

”Nasa hukkasi 120 miljoonan dollarin Mars-luotaimen, kun osa insinööreistä käytti metrijärjestelmää, osa brittiläistä.”
Kulttuurien törmäys, ja tätähän tapahtuu yhä enemmän.

”Kun ohjelmiston tekeminen aloitetaan ketterin menetelmin, ei kirjoiteta monikymmensivuista vaatimusmäärittelyä. Sen sijaan selvitetään tarkasti, mitä käyttäjä haluaa ohjelmalla tehdä.”
Ilmaus ’haluaa ohjelmalla tehdä’ on pidempi ilmaisu vaatimusmäärittelylle, vaikka vaatimusmäärittely saattaa toki sisältää myös asiakkaan kannalta ’epäolennaisia teknisiä kommervenkkejä’.

”Jälkiviisaus on helppoa”
Testatkaa ensi kerralla paremmin.

”Jälkiviisaus on helppoa”
Älkää ensi kerralla luopuko kerralla kaikesta toimivasta. Ei Suomessakaan korvattu yhdessä päivässä kaikkia bensa-asemia sähköautojen latauspisteillä. Sen sijaan yksittäisiä latauspisteitä on pystytetty ilman, että nykyisiä bensa-asemia on lakkautettu. Ottakaa siis mallia muiden alojen toimivista käytäntötavoista, tai jos ette ota, varautukaa ainakin mittavaan asiakaskatoon.

”Jälkiviisaus on aina helppoa”…
ja viisas ihminen oppii virheistä, mutta organisaatiot eivät ole ihmisiä, vaikka niitäkin siellä saattaa olla.

Jäin odottamaan jutulta enemmän kaivelua siitä miten suuret IT-toimittajat toteuttavat julkishallinnon suuria projekteja.

Itse parissa suuressa kotimaisessa IT-toimittajatalossa toimineena havaitsin, että ei vaatimuksiin edes välitetä suhtautua sillä vakavuudella mitä ne on tehty. Joka paikassa koetetaan mennä siitä missä rima on matalin. Sama koskee myös toteutusvaihetta.

Olen väitellyt tohtoriksi koodin analysoimisesta ja kirjoittanut kirjan ohjelmisto-ongelmien paikantamisesta. Kirja ei suuremmasti kiinnosta alan yrityksiä, sillä eivät kuulemma jaksa lukea teoriaa. Tämä oppimattomuus johtaa siihen, että virheistä ei jatkossakaan päästä eroon.

Suurilta osin tuo artikkeli on ok, mutta lääkettä ohjelmien poistamiseksi etukäteen tai silloin kun ne ovat pinnassa, se ei esitä. Diagnosiikan perusteet on silti luotu jo 1970-luvulla, mutta nämä agile – kehittäjät eivät tunne niitä. IT-ammattilaiset ovat heikosti koulutettuja, heillä huono ammattitaito ja stressaava työ, mitkä näkyvät laadussa.

Milloinkahan softayritykset pystyvät siirtymään pyörän uudelleen keksimisestä todelliseen kierrätykseen hyvine työkaluineen – ammattimaisella asenteella?

Eräs tuotepäällikkö Digiasta väitti minulle syksyllä, että softayritykset tekevät virheitä tahallaan, koska he saavat korjauksistakin korvauksen.

Erkki: Eihän ne jotka asioista päättävät, koskaan ole jaksaneet teorioihin perehtyä. Antavat alaistensa sen tehdä ja sitten tekevät päätöksensä kuitenkin omalla mutu-tuntumalla. Ja saattavat olla sen ajan kasvatteja jolloin kotilaskut tehtiin kynällä, paperilla ja laskutikulla.

Ihan hyvä artikkeli. Tosin alku hiukkasen naiivi. Järjestelmien kompleksisuus kasvaa vuosi vuodelta ja suurten järjestelmien rakentaminen tulee olemaan aina vaikeaa. Agile tuo mukanaan hyviä menetelmiä ja läpinäkyvyyttä, mutta ei ole oikotie onneen.

Myös kommentit tahallisesta huonosta koodista ovat typeriä. En ole koskaan nähnyt kenenkään kirjoittavan huonoa koodia tarkoituksella, mutta sitäkin enemmän olen nähnyt huolimatonta koodia, johtuen varmaankin aikataulupaineesta tms.

”Jonottamista ei tietokonemaailmassa tunneta, vaan kaikki verkkokaupan kävijät pyrkivät virtuaaliselle lippuluukulle samanaikaisesti.” Tässä on ongelman ydin! Kyllä ”tietokonemaailmassakin” voi yhtä hyvin järjestää käyttäjät jonoon ja päästää heidät hallitusti sisään.

Mitenkähän lie noiden Sitran sivujen kanssa – jos homma alkoi jo vuonna 2010 ja valmista tuli vasta tammikuussa 2012, niin ei tuota kovin nopeaksi voi ”pienenkään” toimittajan kanssa sanoa. Paljonko mahtoi palaa veronmaksajien euroja siihen hankkeeseen?

”Aika moni huippusuosittu palvelu on syntynyt kovin ketterillä menetelmillä, Flickr yhtenä esimerkkinä, joka tuottaa jopa kymmeniä kertoja päivässä uusia versioita (ks. continuous deployment). Tai GitHub. Tai fimoista suomalainen Reaktor, joka on tunnettu hyvintuotetuista projekteista.”

Reaktor, joka on tunnettu hyvin tuotetuista projekteista, anna minun nauraa. Reaktor nahkasohvineen ja ”käyttäjä”lähtöisine määrittelyineen on ehkä isoin kasa schaissea mitä viime vuosina suomen IT-alalla on tapahtunut.

Aina kun julkisuudessa retostellaan isoja IT-hankkeita, niin haastatellaan järjestelmän tilaajaa ja asiakkaita. Miksei koskaan kerrota toimittajan näkökulmaa asiaan? Olisi mielenkiintoista kuulla mitä Tiedon ja Accenturen projektipäälliköt ovat mieltä VR:n hankejohdon toiminnasta. Taitaa vain olla niin, että maksavaa asiakasta ei ole varaa arvostella.

”Accenture, Tieto, Logica, Fujitsu jne tekevät juuri niin hyvää jälkeä, kuin mitä artikkelissa mainittu Helsingin yliopisto ja naapurin Aalto osaavat projektihenkilöstöä kouluttaa. Miksei puhuta yliopistollisen koulutusjärjestelmän kriisistä?”

Tässä on paha looginen virhe: Ko. firmat ovat tekemässä ensisijaisesti rahaa eivätkä tietojärjestelmiä.

Siis rahaa. 3v sokkolennettyä projektia tuottaa firman taskuun saman määrän rahaa, menee se täysin pieleen tai ei ja nämä firmat saavat _aina_ tarjouspyynnöt kun isoja hankintoja tehdään, vaikka jo etukäteen tiedetään että nämä ovat vain rahantekomielessä liikkellä.

Yksikään valtion virasto ei kykene oppimaan yhtään mitään siitä että _mistä ei missään tapauksessa pidä ostaa mitään_. Siitä aivan suoraan seuraa se, että vuosikymmeniä kaadetaan miljarditolkulla rahaa kaivoon ja joka kerta aivan samasta syystä: Konsultit ovat pätevämpiä putsaamaan valtion rahat kuin virkamiehet pitämään niistä huoli.

Mutta selvästi tämä on mahdoton käsittää ja syylliseksi lavastetaan koodaritason kavereita, heppuleita, joilla ei ole mitään vaikutusta projektin aikatauluun tai kustannuksiin.

”Eräs tuotepäällikkö Digiasta väitti minulle syksyllä, että softayritykset tekevät virheitä tahallaan, koska he saavat korjauksistakin korvauksen.”

Ja ylläpidosta ja raudan pitämisestä pystyssä ja niin poispäin.

Mm. Tieto on todistetusti onnistunut venyttämään 2 vuoden projektin 16-vuotiseksi ja _koko ajan laskutus pyörii tuntihinnalla_, koska tilaaja on idiootti ja maksaa, kansalaisten rahoilla tottakai. Valtionhallinnossa kun ei ole mitään vastuuta siitä että montako sataa miljoonaa tuhlataan.

Tuntilaskutus on se mikä tuo rahaa ja isolla talolla on varaa myydä ”projekti” roimalla alihinnalla: Ei tule kilpailua ja rahat otetaan takaisin vuosikausia jatkuvalla tuntilaskutusruletilla, moneen kertaan.

40-50 ihmistä ja 120e/h tuo mukavasti käteisvirtaa kassaan vaikka 5v projektista. Siinä kohdasa on jo aivan sama millä hinnalla se alkuperäinen tuote, eli koukku eli täky on luvattu. Aivan perinteinen syötti ja koukku-menetelmä ja kun saalis on koukussa, aletaan rahastaa. Tuntihintaa.

Kun toimittaja vielä itse toimittaa hankintasopimuksen pohjan tilaajalle (valtionhallinnossa enemmän sääntö kuin poikkeus) niin voitte olla varma että mitään sanktioita myöhästymistä ei ole eikä sakkoa projektin kaatumisesta. Tai jos onkin, ne ovat niin pieniä että viikon tuntihinnalla kattaa kaiken ja loput 51 viikkoa ovat nettoa.

Siis: jokainen saatu euro on tekijälle puhdasta nettoa eikä ole mitään paineita saada koskaan valmista.

Miten tälläisestä yhtälöstä ikinä voi tulla kunnollista jälkeä kun se ei ole toimittajan etu millään mittarilla, päinvastoin.

Tämä on vallitseva käytäntö kaikilla isoilla toimittajilla, ellei ole sattumalta ollut joku joka osaa kirjoittaa sopimukset niin että myöhästymiset maksavat toimittajalle enemmän kun asiakas maksaa maksuja samaan aikaan. Ts. toimittaja ei saa voittoa myöhästymisestä huolimatta.

Sellaiset lasketaan yhden käden sormilla Suomessa nykyisin.

”VR:n kaltaiset isot Online-järjestelmähankkeet ovat mielestäni nykään rinnastettavissa edellä mainittuihin ERP-hankkeisiin.”

Bullshit-mittari kolahti juuri tappiin, onnittelut.

VR:n systeemi on verkkokauppa noin teknisesti ja sellaisessa ei ole mitään ihmeellistä, puhumattakaan että 1,2M kävijää päivässä olisi mitenkään valtava määrä.

Toisekseen: Jos projekti on liian iso, on tehty jotain päin seiniä jo määrittelyvaiheessa: Ei ole osattu tai haluttu palastella projektia hallittavan kokoisiin palasiin, vaan lähdetään tekemään monoliittisesti kaikkea kerralla.

Takuuvarma tie tuhoon. On henkilöinä ketä tahansa, liikkuvia osia on vain liikaa.

Artikkelissakin mainituille firmoille tälläinen prosessi sopii loistavasti: Tehdään vuosia ”projektia” ja kun pitäisi saada jotain toimivaa, ei olekaan mitään esittää. Laskut ovat kyllä juosseet koko ajan ja projekti on roimasti voitollinen kaikille osallistujille: Onnistunut kuppaus veronmaksajan taskusta ja syylliset istuvat viroissaan eläkkeelle asti.

VR ei selvästi oppinut mitään edellisestä lippujärjestelmän uusimisprojektista, ainakin näin sivusta katsottuna: Aivan samat munaukset tehtiin toistamiseen, nyt vain 10* kalllimmassa mittakaavassa.

Oliko järkeä?

”Miksei koskaan kerrota toimittajan näkökulmaa asiaan? Olisi mielenkiintoista kuulla mitä Tiedon ja Accenturen projektipäälliköt ovat mieltä VR:n hankejohdon toiminnasta. Taitaa vain olla niin, että maksavaa asiakasta ei ole varaa arvostella.”

Projektipäälliköt toistelevat firman linjaa ja firman linja (rahastamien) on vaittu paljon, paljon ylempänä ja sitä ei voi arvostella. Ainakin jos aikoo pitää työpaikkansa tai saada töitä muista isoista firmoista.

Johto taas valehtelee ihan mitä tahansa, sieltä ei todellista syytä saa kirveelläkään: Ehkäpä lehdistö on jo oppinut että toimittajan edustaja pelkästään valehtelee: Kun on omat miljoonat kyseessä niin todellisuus lakkaa olemasta samantien: Iso Raha(TM) luo aivan oman todellisuutensa joka ei kellekään muulle näy.

”On melko vaikeaa ennakoida kaikkien asiakkaiden ajattelutottumukset tai käyttötavat. Varsin usein palvelua suunniteltaessa kuvitellaan mielessä tavallinen mattimeikäläinen, joka käyttää palvelua hallitusti ja oikein juuri palvelun suunnittelijoiden toivomalla tavalla. Palvelua toteutettaessa ei aina varauduta erilaisiin keskiarvoista poikkeaviin omituisuuksiin, kuten vääränlaisiin tietoliikenneyhteyksiin, vanhentuneisiin nettiselaimiin, nörttien suosimiin käyttöjärjestelmiin ja laitteistokokoonpanoihin tai hyvin ilkeisiin, pahantahtoisiin ihmisiin (eli ’asiakkaisiin’).”

Ei VR:n tapauksessa käyttäjien käytös ollut mitenkään oletuksista poikkeavaa ja ongelmia oli osaltaan aiheuttamassa projektiin sisältyneet omat laitteet (automaatit).

Erilaisten vastaantulevien tilanteiden huomioonottaminen on sitä osaamista ja ammattitaitoa. Otetaan huomioon, että tilanteet muuttuvat, laitteistot, ohjelmaversiot, liitynnät ja käyttöprofiilit muuttuvat. Ymmärretään, että elävässä maailmassa mitään ei voi tehdä puhtaalta pöydältä eikä mikään säily loputtomasti muuttumattomana. Robusti järjestelmä sietää muutokset.

Muistaakseni terveydenhuollon surkeasti toimivat ”ohjelmabisnekset” maksoivat 150 miljoonaa veronmaksajien rahoja.

Suurin syy on kilpailutuslainsäädännössä. Osaavilla vuosikausia osaamistaan todistaneilla IT firmoilla ei ole resursseja käyttää kuukausia ja jopa vuosia tarjousten tekemiseen vaikka heille olisi helpostikin totetuttavia ideoita asiakkaan tarpeen tyydyttämiseksi. Julkiset tarjouskilpailut voitaa yleensä yhtiö jolla on parhaat juristit vääntämässä sananmuodot juuri vastaaviksi kuin tarjouskyselyssä on määritelty.

Toinen syy miksi aina nämä samat isot töpeksivät yhtiöt valitaan on ostavan organisaation johtajuuden puute. Reppahousut joilla lukee Senior Vice Presidenttiä ym käyntikoriteissaan eivät uskalla ostaa kuin tahoilta joilta voidaan tarvittaessa sitten hakea korvauksia jos (kun) projektit menevät munilleen. Asiakkaan syytä puolet näissä pieleen menneissä projekteissa. Meidän firmassa on annettu jo ohjeet että varsinkaan julkishallinnon kilpailutuksiin ei tuhlata työaikaa vaikka osaamista olisi.

Asiaa ymmärtämättömät populistisesti arvioivat projekteja omista lähtökohdistaan.
Kansainvälisissä jättiprojekteissa mukana olleena tiedän, ettei tehtävä ole helppo.

Pari epäonnistumisen syytä:

Maallikoista koostunut johtoryhmä ei osaa tehdä päätöksiä nopeasti.

Jos poliittiset edustukselliset ihmiset pääsevät päättämään asioista, projekti menee mäkeen. Kompromisseja, lehmänkauppoja, järjen puutetta. Herra varjelkoon projektia, jos siihen pääsevät poliitikot sotkeutumaan.

Epäonnistunut projektipäällikön valinta on paha juttu.

Entinen esimieheni sanoi kerran, että hän suhtautuu it-projekteihin niin, että kertoo budjetin mielessään kolmella. Ja lykkää mielessään aikataulua toisella mokomalla. Sattuu aika hyvin kohdalleen.

Usein tuntuu unohtuvan, että ohjelmointi ei loppujen lopuksi olekaan joukkuelaji.
Koko homma on yhdestä tai kahdesta gurusta kiinni. Loput sata pistää pakkaa sekaisin:
joko suoranaisesti tekevät taitamattomuuttaan vahinkoa tai sitten tuottavat hirmuisella
vauhdilla megatavuittain koodiroskaa, mitä ei kukaan ehdi koskaan siivota eikä kiinnostaisikaan.

Kaikki eivät vaan osaa ja sehän sopii hienosti Tiedon ja kumppaneiden bisnesmalleihin.

Sairaalamaailmassa Pegasos ja Effica ovat vuosia hankaloittaneet potilaiden hoitoa.

Vain privaatin Doctorex hyödyttää ja nopeuttaa potilaan hoitoa.

Jos terveydenhuolto olisi VR ei Pegasoksella ja Efficalla kulkisi yksikään juna ajoissa-kaikki jäisivät asemalle.

Kaiken kaikkiaan samaa surullista luettavaa, mitä on uutisoitu muutama kymmenen vuotta. Vähän on opittu. Mutta epäonnistumisien puolustamiseksi/selittämiseksi todettakoon, että onhan suurien projektien koko ja kompleksisuus kasvanut. 20 – 30 vuotta sitten 20 hengen projekti oli suuri, nykyään satojen henkilöiden projektit ovat tuiki tavallisia. Ja kaikkinainen muutos on lisääntynyt. Juuri kun porukka olisi oppinut tekemään asioita kohtuullisen hyvin yhdellä tavalla, joku asia muuttuu (työkalut, sovellusalue, asiakas, tekijät, organisaatio, jne., jne.) ja taas ollaan opettelumoodissa.

Eniten jutussa ihmetyttää Sarvaksen lausunto:
”Ohjelmakoodin tuotantokustannukset lähenevät nollaa”
Aikamoista puppua, varsinkin kun sen sanoo softatalon edustaja, jonka firma tekee liikevaihtoa n. 100.000 e/työntekijä – hyvät katteet nolla-työstä.

Abrahamsson toteaa yhden oleellisen asian: ”Nykyään yritetään priorisoida niitä ominaisuuksia, jotka ovat ehdottoman tärkeitä, mutta se on helpommin sanottu kuin tehty”. Agilisteille priorisointi on hopealuoti, joka ratkaisee kaiken. Nyt jälkikäteen voidaan sanoa, että VR:n projektissa kaikkein tärkein ominaisuus olisi ollut tietokantaohjelmistossa olleen vanhan virheen korjaaminen ensimmäisenä. Mutta mistä olisi löytynyt se guru, joka olisi ensinnäkin osannut laittaa tämän asian projektin tuhansien tai kymmenien tuhansien ominaisuuksien joukkoon ja kuka/ketkä olisivat olleet riittävän fiksuja bongaaman sen ja saamaan sen tärkeimmäksi ominaisuudeksi. Tuskinpa ainakaan Reaktor, joka olisi alkanut ensimmäisenä päivänä koodaamaan lippuautomaatin lipunostonäyttöä.

Agilistit piirtävät muutenkin aika yksinkertaisen ratkaisun ongelmiin:
”selvitetään tarkasti, mitä käyttäjä haluaa ohjelmalla tehdä. Sen jälkeen ohjelmistoa yksinkertaisesti aletaan toteuttaa, osa osalta.”
Iso ongelma (siis ongelma, ei haaste) esim. VR:n tapauksessa on, että eri tyyppisiä käyttäjiä on lukemattomia pelkästään VR:n puolella (lipunmyyjät, konduktöörit, automaatit, lippujen hinnoittelijat, aikataulusuunnittelijat ja mitä kaikkea siellä onkaan). Jokaisessa käyttäjäryhmässä on eri tyyppisiä käyttäjiä, joilla on erilaisia tarpeita ja prioriteetteja. Kuka pystyy tekemään oikean päätöksen, mikä on tärkein käyttäjäryhmä ja mikä/kuka tärkein käyttäjä, jonka tarpeista lähdetään liikkeelle ja osaako se tärkein käyttäjäkään oikeasti sanoa, mikä sille/hänelle on tärkeintä? Eri käyttäjäryhmien/käyttäjien tarpeiden välillä on aina ristiriitoja eikä kukaan pysty tekemään niiden välillä oikeaa priorisointia. Vrt. valtion tai kunnan menokohteiden priosisointi. Teki sen ketkä tahansa, aina se on väärä jonkun tahon/joidenkin tahojen näkökulmasta.

Ja mitä tulee inkrementaalisuuteen, kaikkea voi ja on kautta maailman sivu kehitetty inkrementaalisesti, mutta aina ei voi ottaa käyttöön inkrementaalisesti. En pysty sanomaan VR:n lipunmyyntijärjestelmästä olisiko se voitu ottaa käyttöön inkrementaalisesti, mutta otetaan esimerkiksi vaikka miehitetyn Mars-lennon softa. Se voidaan kehittää inkrementaalisesti, sitä voidaan simuloida (epätäydellisesti) maan päällä ennen ensimmäistä lentoa, mutta käyttöönotto tapahtuu big-bangina ensimmäisellä lennolla.

Aiheesta riittäisi juttua muutaman kirjan verran, mutta asian tiivisti Fredi erinomaisesti jo 60-luvulla Roskisdyykkarin ballaadissa:
“Vaikka paremmaksi kaikki muuttuu, silti hyväksi ei milloinkaan”.
Suurien softien tekeminen voi parantua, mutta ei tule koskaan hyväksi. Sitä on yritetty 60 vuotta erilaisten hopealuotien avulla eikä mikään niistä ole tehonnut. ”Näin on aina ollut ja näin on aina oleva”, sanoi jo Sinuhe-vainaakin.