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.
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.
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.
”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.
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?
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.
”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ä.
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.
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ä.
”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.
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.
VR , lipunmyyntijärjestelmä , Jukka-Pekka Suonikko , tietojärjestelmät
Saat uusimmat, kiinnostavimmat ja puhutuimmat aiheet
kerran viikossa suoraan sähköpostiisi.
Onnea HSL, http://www.hsl.fi/fi/mikaonhsl/Uutiset/2012/Sivut/Page_ 20120124103735.aspx
Varmaankin aikataulussa ja budjetissa pysytään aiempien näyttöjen perusteella.
Eivät ongelmana ole tietojärjestelmät, vaan julkishallinnon toimintatapa kokonaisuudessaan: se ei yksinkertaisesti sovi järjestelmien toteuttamiseen. Armeijamainen heirarkisuus, omien tonttien varjelu jnejne väistämättä johtavat karille ennen pitkään, ja samat ominaisuudet estävät virheiden myöntämistä ajoissa. Lopulta koittaa käyttöönoton hetki ja wirallinen totuus kohtaa reaalitodellisuuden.
Ryske käy, jälkimmäinen ei suostu väistymään.
Huumorin kukkanen oli päässyt kirjoitukseen! Vaikka pienten kutsumuskoodaripajojen tekijät voivat olla tehokkaampia kuin isojen talojen jo tuoleihinsa jäykistyneet hilsehartiat, ei se tarkoita tietenkään sitä että jos malli on ketterä, syntyy muutoksia hetimiten, vaikka jo seuraavana päivänä.
Tuo tapa on kaikista toimimattomin, kohkataan ja tehdään määrittelemättä mitään kunnolla, näytetään tulos asiakkaalle ja kas, se ei ole haluttu. Ei kun tekemään päivän työn vaatinut lomake uudelleen = päivä lisää töitä.
Ketteryys tarkoittaa karrikoidusti sitä että ollaan paremmin kärryillä siitä missä
mennään, joka päivä. Ei mennä niin pahasti pieleen - tai syvälle metsään.
Jos kirjoittajan ehdottamaa tapaa soveltaisi rakentamiseen, se tarkoittaisi että näytetään asiakkaalle kerrostalon hahmotelmat ja aletaan rakentamaan. Sitten viikoittain asiakas käy paikalla toteamassa että tuon käytävän ja tuon 3. kerroksen huoneen paikkaa pitää vaihtaa, et se ei oo kiva tossa. No eihän se tietenkään itsestään tapahdu, hah?
Eikä se ohjelmointi tänä päivänäkään synny tyhjästä, muutaman käyttäjän verkkokaupan saa kivasti pystyyn olemassaolevilla palveluilla, mutta kun metsäyhtiö haluaa tietohallintopäällikölle ainoaksi vaihtoehdoksi mainostetun kalliin ja laajan alustan veppisivuilleen, tietenkin kustomoituna, se teettää työtä ja valmiin teräskehikon vääntelyä sopiviin suuntiin. Siinä palaa äkkiä satoja tuhansia yrityksen rahoja kun bussista pitää vääntää taksia.
VR:llä 1,2 miljoonaa ”latausta” päivässä. Kuulostaa ehkä jonkun muinaisjäänteen mielestä vaikuttavalta, mutta se nyt vaan on huono selitys, koska nykymittapuun mukaan se on aika vähän.
Se on keskimäärin n. 14 latausta sekunnissa. Vaikka aamun piikki olisi kymmenkertainen keskiarvoon verrattuna, 140/s, siihen (tietokantatransaktiotaajuuteen) pystyy kotitietokone, jollaisia saa Gigantista muutamalla satasella. 1-10 kHz taajuuksiin tarvitaan jo vähän tehokkaampaa rautaa, joka maksaa joitakin tuhansia euroja.
Ongelmat aiheutti vain ja ainoastaan surkeasti toimiva ohjelmisto. Mitään 2000-luvulla valmistettua rautaa ei saa kyykkyyn tuolla kuormituksella, jos ohjelmisto on edes suunnilleen kunnossa.
”Järjestelmäasiantuntijan” vertaus talonrakentamiseen ontuu siinä mielessä, että aika lailla noinhan monissa rakennushankkeissa toimitaan. Käyttäjämuutoksia päivitetään suunnitelmiin työmaan kuluessakin. Tämä vaatii hyvää ja nopeaa yhteistyötä rakennuttajan, urakoitsijoiden ja suunnittelijoiden kesken, mutta kun yhteistyö sujuu, on aivan toimivaa käytäntöä.
Useimmissa hankkeissa kun käyttäjät eivät ole lopullisesti tiedossa ennen kuin työmaan kuluessa, erityistarpeiden huomiointiin tämä on ainoa tapa.
Liiketilojen rakentamisessa varsinkin tämä on varsin yleistä. Ja joskus asuntosuunnittelussakin.
Kun kerrostalon ylimmästä kerroksesta ostaakin 300 neliötä yksi asiakas, aika vaivattomasti siinä yhdistetään muutama pienempi kämppä ja laitetaan suunnitelmat siltä osin täysin uusiksi. Arkkitehti piirtää päivän, muut suunnittelijat tarkistavat miten heidän suunnitelmansa ovat päivitettävissä, urakoitsija laskee hinnan lisättynä mojovilla yleiskustannuksilla, rakennuttaja hyväksyttää suunnitelman käyttäjällä ja taas rakennetaan.
Ja kaikki ovat tyytyväisiä. Asiakas saa 300 neliön kämpän 100 neliön saunaosastolla ja muut osapuolet paikkaavat kivasti projektin taloutta lisälaskutuksella.
Artikkelin kirjoittajalla oli mielestäni kyllä hyviä näkemyksiä suunnittelunohjauksesta.
Kun ohjelmistosuunnittelijat tulevat keski-ikään ja he ovat oppineet vihdoin oppineet tekemään työnsä kunnolla, heidät potkitaan pois. Tilalle otetaan aina uusi sukupolvi noviiseja toistamaan samat virheet vuosikymmenestä toiseen. Ketterät menetelmät ovat keisarin uusia vaatteita. Ad-hoc-hihasta vetäminen kuulostaa hienommalta kun sitä kutsutaan ketteräksi menetelmäksi. Keski-ikäisiä ei pidetä riittävän ”ketterinä” kun he eivät saa nopeasti puolivalmista aikaiseksi vaan haluavat suunnitella ja toteuttaa perusteellisesti oman osuutensa. Ketterät menetelmät ovat vieneet ohjelmistokehitystyötä vuosikymmeniä taaksepäin. Lopputuloksena on se, että ohjelmistot tehdään valmiiksi jälkikäteen käyttöönoton jälkeen.
@koodari
Tässäpä selkeä ero ”koodarin” ja integraattorin näkemyseroissa. Koodari näkyy järjestelmän tässä vain fronttina tietokantayhteydelle. VR:n järjestelmää tuntematta voin kuitenkn sanoa, että kun tehdään esim. nykystandardin mukaisia SOA-järjestelmiä, tulee se kapasiteettiongelma vastaan ihan muussa kuin siinä tietokantatransaktioiden lukumäärässä. Kannattaa tutustua aihealueeseen hieman omaa pientä pelikenttää laajemmin. Tämä toki, jos tarkoitus on tehdä töitä ammattinaan. Kotikoodarille asiat tietysti riittävät tuolla tasolla.
”Kun ohjelmiston tekeminen aloitetaan ketterin
menetelmin, ei kirjoiteta monikymmensivuista vaatimusmäärittelyä. Sen sijaan
selvitetään tarkasti, mitä käyttäjä haluaa ohjelmalla tehdä.”
Kätevästi ei tarvitse kirjoittaa monikymmensivuista vaatimusmäärittelyä, kun selvitetään tarkasti (monisataa tai -tuhatsivuisesti) se, mitä ohjelman haluaa tekevän.
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ä?
Valmiiden pakettiratkaisujen ostelu ei ole oikotie onneen, vaikka myyntimiehet näin toitottavat mieluusti.
Jos ne otettaisiin käyttöön ilman muutoksia, homma olisi ok. Mutta en ole kohdannut IT-urallani projektia, jossa valmisjärjestelmään ei haluttaisi muutoksia prosesseihin, kenttiin tai vastaaviin.
Itse vertaisin laajojen tietojärjestelmien rakentamista ydinvoimalan tekemiseen - ja joiltain osin kyse on vielä hankalammista asioista. Siinä missä ydinvoimalan toiminta noudattaa ennustettavissa olevia suureita, tietojärjestelmissä voi esiintyä ongelmia - kuten artikkelissa todetaan - paikoissa
joita ei osata ensisilmäykseltä odottaa.
Sähköisistä resepteistä (tai terveydenhuoltoalasta) ja IT-alasta yleensä: yhtenä ongelmana on tilaajan osaamisen puute. Ei osata kuvata, mitä halutaan. Jos tietäisi, näitä ongelmia ei olisi. Sisältövastuu tulee tilaajalta, tekniikan hoitaa toteuttaja.
Lääkärikunta ja terveysala tarvitsisi oman erikoistuneen IT-väkensä, jota koulutettaisiin alalle jo koulun penkiltä lähtien. Terveydenhoitoala on yksi vaikeimmista aloista toimia IT-alalla. On säädöksiä ja hierarkioita, joiden suora toteuttaminen tietojärjestelmiin tekee niiden käyttämisestä kankeata ja aikaa vievää.
Joten pitäisi katsoa myös toimintatapoja ja miettiä onko sitä kaikkea pakko siirtää uusiin järjestelmiin. Esim. tiukka käyttöoikeuksien myöntäminen ja käyttörajoitukset johtaa paperitulostuksiin ja salasanojen lainaamisiin kollegalle tai sijaiselle. Tällöin tiukka tietoturvapolitiikka nollataan käyttäjien halulla etsiä tapa nopeuttaa omaa työtään.Kannattaisi miettiä mikä on realistinen haitta ja mikä rajoituksen antama hyöty. Johtajien pöydällä piirtämät kauniit ajatukset sotivatl liian usein arjen toimintakulttuuria vastaan.
@Integraattori: Varsinaiset skaalautuvuusongelmat, jotka vaativat ”SOA:n perusteet, kappaleet 1-2 harjoitustöitä” nokkelampia ratkaisuja, tulevat eteen vasta paria kertaluokkaa kovemmilla vaatimuksilla kuin vaivaiset 100 eventtiä sekunnissa. Jos järjestelmä pykii jo tuolla taajuudella, voi ongelma toki olla muuallakin kuin tietokannassa - mistäpä minä sen voin tietää. Mutta ainakaan ei ole epäselvää, onko VR:n järjestelmän tekijä tutustunut aihealueeseensa riittävän hyvin, vai eikö ole.
Isot talot toki haluavat säilyttää ongelmat, joihin tarjoavat kalliita ja huonoja ratkaisuja. Harmi vaan, että se, mikä ehkä oli ongelma 20 vuotta sitten, ei enää sitä ole.
Suomenkuvalehden tai Otavamedian kannattaisi myös tarkastaa miksei Suomen Kuvalehteä saa tilattua netistä. Tein tilauksen pari viikkoa sitten enkä ole vieläkään saanut tilausvahvistusta sähköpostiini, eli tilaus tuskin meni perille.
Haluaisin vain sanoa, että hyvin ja monipuolisesti kirjoitettu juttu näin ohjelmistotekniikasta tietävän näkökulmasta. Sopivasti yleistajuistettu kieltä, ei häirinnyt yhtään. Anteeksi, kommenttini ei nyt täytä normaalin kommentoinnin edellytyksiä, kun en esitä kiivasta mielipidettäni mistään.
On roskaa väittää, että ketterä menetelmä tarkoittaisi ad hoc -tyylistä toteutusta. Jos jotkut noin tekevät ja kutsuvat sitä ketteräksi, ei se tee menetelmästä väärää. Jos koodaan summamutikassa ja kutsun sitä rationaaliseksi prosessiksi, onko vika prosessissa?
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.
Mulla on 14 vuoden kokemus alalta ja hävettää
kun tajusin vasta pari vuotta sitten, että koko vesiputousmalli oli kuollut malli jo syntyessään. Mutta ilmeisesti kaikki CEO:t ja moni ammattlilainenkin luki vain abstraktin läpi, eikä heti toista kappaletta, jossa mainittiin, että ei toimi käytännössä softaprojekteissa.
Loistava artikkeli! Tähän oli kiteytettynä monta asiaa joita jokaisen IT-projekteissa työskentelevän pitäis miettiä. Eri asia on sitten asioiden soveltaminen jättihankkeisiin joita VR_n lipunmyynnin uudistaminen varmaankin mennee. Hyvä SK! Lisää tällaisia.
Joku viisas voisi kysyä, että miksi ei ollut olemassa paluusuunnitelmaa vanhaan järjestelmään, jos/kun uusi järjestelmä ei toiminut kunnolla.
Olen samaa mieltä yhden kirjoittajan kanssa, projektinhallintaa ei arvosteta eikä sitä kouluteta kunnolla missään.
Voit valmistua esim. pääaineenasi tietojärjestelmätiede suorittamatta ainuttakaan kurssia projektinhallinnasta ja mitä todenäöisimmin ensimmäinen työpaikkasi on projektipäällikönä, varsinkin jo olet nainen :D
Lisäksi syy miksi ketteriä menetelmiä ei pahemmin julkishallinnossa (tai usein muuallakaan) voida käyttää on se, että IT-alan sopimusmallit perustuvat vesiputousmalliin. Tarjouspyynnössä ja sopimuksessa on tarkat sanktiot aikataulusta, projektin scopesta (ja siten lopputulemasta) ja kustannuksista, joten ketterällä menetelmällä on ihan turha lähteä erittäin työlääseen kisaan mukaan.
Suurkiitos ennätyksellisen asiallisesta artikkelista mainstream-julkaisussa. Nämä ongelmat tulevat toistumaan niin kauan kuin ostaja ei osaa ostaa ja hankintasääntö on niin raskas, että Futuricen ja Reaktorin kokoiset firmat on pelattu ulos jo ennen tarjouskilpailua ja vain Tiedolla ja Logicalla on rahkeita pelata tarjouspeliä. Ja tarjouspeli on näiden jättien ydinosaamista - ei kunnollisen softan tekeminen.
”…ohjelmointityö muuttuu vuosi vuodelta helpommaksi. …”.
Jep jep :) Ohjelmointiin pätee tasan samat lainalaisuudet hyvän pitkäaikaisen lopputuloksen suhteen kuin muuhunkin tekemiseen; vain pitkäaikaisella kokemuksella saa aikaan taattua laatua, kompetenssia ei korvaa mikään toimintatapa tmv. Sillä että kuka tahansa voi vääntää omatoimisesti hetkessä jotain koodia ei ole mitään tekemistä hyvän koodin tai puhumattakaan hyvän järjestelmän kanssa.
Edeltävissä kommenteissa on ollut jo hyviä pointteja monista käytännön ongelmista IT-projekteissa, mutta yhtä en vielä nähnyt: johdon asettamat
aikataulut ja vaatimukset. 5-vuotias tyttärenikin on ilmeisesti manageriainesta koska hänkin ”osaa” vaatia mahdottomia aikataulun ja toiminnallisuuden suhteen ja sen jälkeen huutaa ja valittaa kun painovoima ei kumoutunutkaan hänen vaatimassaan aikataulussa eli eilen. Se että johto ohittaa kriittisiä asiantuntijalausuntoja koko projektin suhteen on oman kokemukseni mukaan lähinnä sääntö eikä poikkeus. Peili tosin löytää vain harvoin sitä tarvitsevan käteen.
Ostajan osallistumisen tärkeyttä korostaisin myös lisää; on täysin epärealistista odottaa suuren järjestelmän valmistuvan eristyksissä ilman että ostaja ottaa aktiivisesti osaa sen kehityksen antamalla palautetta, priorisointia ja päätöksiä niitä pyydettäessä.
Kaiken kaikkiaan kysymys IT-projektien ongelmissa on yleensä mielestäni ns. perusasioista. Siellä kompastellaan pikkukiviin eikä vuoriin ja se kuuluisa oppimiskyky on hukassa silloin kun sitä tarvitaan. Ylpeys käy lankeemuksen edellä.
Ja kannattiko se systeemi ottaa käyttöön juuri sinä päivänä kun tuli voimaan hintauudistus ja alkoi lomakausien lipunmyynti.
Ihan ohjelmistosuunnittelijan sydäntä lämmitti miten kansantajuisesti kirjoittaja oli usein hankalaa ja jargon-pitoista aihetta kuvannut. Hieno artikkeli.
Vaikka ketterät menetelmät ovat ”virallisesti” olleet olemassa jo yli 10 vuotta, ovat ne vasta hiljalleen vakiinnuuttamassa paikkaansa. Ala on yllättäävn hidas käänteissään ja wanhat tavat ja tottumukset istuvat tiukassa.
Ongelmista pienin ei ole se, että ketterä malli vaatii asiakkaalta paljon enemmän osallistumista kuin perinteisessä mallissa, lisäksi julkisen puolen kilpailutus ja sopimusmallit ovat niin kankeita, että ne torpedoivat
helposti ketteröitymisyritykset jo ennen kuin projekti on edes alkanut.
Toinen ongelma on se, että valitettavan suuri osa ohjelmistoalan ammattilaisistakaan ei ole ymmärtänyt ketterien menetelmien filosofiaa. Tästä hyvänä esimerkkinä anonyymin kommentti:
”Ketterät menetelmät ovat vieneet ohjelmistokehitystyötä vuosikymmeniä taaksepäin. Lopputuloksena on se, että ohjelmistot tehdään valmiiksi jälkikäteen käyttöönoton jälkeen.”
Positiivista on se, että vähä vähältä jäykät käytänteet väistyvät, kun tulokset puhuvat selvää kieltään. Myös asiakkaat oppivat ennen pitkää toivomaan ja lopulta vaatimaan IT-taloilta ketteryyttä.
Jos rinnastetaan IT -projektia kerrostalon rakentamiseen useimmiten kerrostalonkin pintamateriaaleja voi tuleva asukas vielä vaihtaa kun talo on jo rakenteilla eli kyllä sitä ketteryyttä löytyy muiltakin aloilta, pitäisi ehkä ottaa oppia.
Muutamassa hankkeessa mukana olleena en lähde syyllistämään ketään mutta hankalaa on puolin ja toisin : toisella puolella asiantuntijat jotka eivät välttämättä ymmärrä vaatimuksia ja tarpeita vaikka kuinka simppelisti ne laitettaisiin ja toisella puolella ostaja joka on (ehkä pahimmassa tapauksessa) byrokraatti joka pelkää virkavirhettä ja peittelee mokiaan
uusilla tilauksilla ja paisuttaa vain toimittajan lompakkoa.
Nojaa, nuori teollisuudenhaara pitää käydä oma kivikkoinen polkunsa ennen kuin ne oikeat menetelmät löytyvät - asiaa ei tietenkään koskaan helpota se, että parin vuoden välein kaikki varusohjelmistot ja ympäristöt muuttuvat eikä pörssinoteeratut yritykset tiedota suunnitelmistaan kauhean aikaisin.
@Järjestelmäasiantuntija
Analogiasi on täysin väärä.
Rakennussuunnittelu tehdään etukäteen ja tarkasti sen takia, että fyysisen rakennuksen muuttaminen jälkikäteen on *erittäin* kallista ja hidasta.
Ohjelmistojen muuttaminen taas on erittäin halpaa ja nopeaa joka mahdollistaa asiakkaan tarpeen validoinnin ja muutoksien tekemisen hyvin nopealla syklillä.
Aihetta, miksi suuret liiketoimintakriittiset hankeet epäonnistuvat, on tutkittu kyllä aika laajasti. Suomestakin löytyy yrityksiä, jotka ovat keskittyneet tällaisten hankkeiden suunnitteluun ja johtamiseen. Ympäri maailmaa löytyy aiheesta paljon statistiikkaa ja vaikka USA:sta mielenkiintoisia oikeustapauksia, joita voi ottaa iltalukemiseksi, jos päätä joskus puristaa. Artikkeli oli kyllä hyvin maanläheisesti kirjoitettu, mutta siitä puuttui aika monta melkoisen laajasti tunnustettua näkökulmaa, eikä VR:n tietohallintojohtajakaan niihin puuttunut, joten tässä pari riviä aiheesta. Reffaan tässä
hankkeisiin, jotka vievät vuodesta useisiin vuosiin katsomatta siihen, millä menetelmällä niitä toteutetaan. En siis nyt puhu projekteista, joissa kesto on joitain kuukausia, koska niihin pätee ehdottomasti hieman eri luonnonlait.
Ensinnäkin tämän kokoluokan hankkeen ollessa kyseessä ei pitäisi puhua mistään IT-hankkeesta, kyse on aina liiketoimintahankkeesta, jolla pyritään saavuttamaan kestäviä ja mitattavia, viimeisellä rivillä näkyviä tuloksia. Hanketta tulisi ohjata liiketoiminta, eikä Tietohallinto. Kaikella kunnioituksella, en oikein ymmärtänyt, miksi pelkästään IT-johto oli haastateltu, jos haluttiin saada kokonaiskuvaa syistä, miksi homma meni puihin. Isojen hankkeiden ollessa kyseessä epäonnistumisessa on huomattavasti laajemmista asioista kyse kuin konesaleista, yksittäisestä softabugista, kuormitusongelmista tietokannassa tai siitä, käytetäänkö scrumia, vesipuotousta tai jotain niiden välimallia. Lisäksi se, että noilta osin Reaktor ja Futurice oli valittu subject matter experteiksi oli kuin jo puolensa valinnutta journalismia.
Tyypillisimmin epäonnistumisen syyt kietoutuvat seuraavanlaisiin syihin.
Yrityksessä ei ole kokemusta vastaavan kokoluokan hankkeesta, joka heijastuu kaikilla tasoilla skaalasokeutena, joka on hyvin kollektiivista ja tarttuvaa:
- johto ei osaa priorisoida hanketta ja tehdä sille ”tilaa”, vaikka se budjetiltaan ja työmäärältään voi vastata yli 50% projektiportfoliosta, jossa on jo helposti yli 100 projektia. Oikein toimiessaan johto tappaisi ison määrän meneillään olevista projekteista ja estäisi monien uusien aloittamisen. Kun tätä ei tehdä, hanke nilkuttaa vailla onnistumisen mahdollisuuksia. Myös divisioonien johtajat tappelevat kuten ennenkin projektien prioriteeteista, vaikka tämä hanke pitäisi olla koko johtoryhmän tuloskortissa ja ajaa yksittäisten divisioonien vetäjien ambitioiden yli;
- yrityksen projektipäälliköt tovat tottuneet suunnitelemaan ja johtamaan hankkeita, jotka ovat 10 jopa 100 kertaa pienempiä: John Wayne -toimintatavat toimivat muutaman kuukauden pikkuprojekteissa, mutta eivät vuosia kestävissä hankkeissa;
- asiantuntijoita, joilla ei ole mitään projektinvetokoulutusta, nostetaan projektipäälliköiksi vetämään osaprojekteja, jotka ovat kymmeniä kertoja isompia, kuin yrityksen normaalit projektit. Tämäkin on asia, jota business as usual -tilanteessa kenelläkään ei olisi tullut mieleenkään ehdottaa, mutta skaalasokeuden iskettyä tämäkin maistuu hunajalta.
Alussa nimenomaan pitää käyttää paljon aikaa siihen, että ymmärretään, mitä halutaan. Puhun nyt esimerkiksi isoista ERP-hankkeista, joissa vanhan vaihto uuteen on sama, kuin ihmiselle tehtäisiin sydämensiirto, tai vaihdettaisiin lentokoneen moottoria sen lentäessä. VR:n kaltaiset isot Online-järjestelmähankkeet ovat mielestäni nykään rinnastettavissa edellä mainittuihin ERP-hankkeisiin. On välttämätöntä, että ymmärretään liiketoiminnan vaatimukset, vaikka olen samaa mieltä, että niitä tulee matkan varrella tarkentaa. On välttämätöntä ymmärtää liiketoimintaprosessit, ja että ne on kattavasti dokumentoitu. Sama koskee kokonaisarkkitehtuuria kymmenine tai joissain tapauksissa satoine järjestelmineen. Niin hullulta kuin se kuulostaa, on paljon hankkeita, joissa näitä ei ole kuvattu lainkaan riittävästi lähtötilanteessa, vaan ”on vaan lähdetty tekemään”. Yleensäkin alussa pitäisi ymmärtää, millä keinoin aion kilpailijani voittaa, ja mitä se tarkoittaa uuden järjestelmäni vaatimuksille ja niiden priorisoinnille.
Epärealistiset odotukset - yleensä tähän liittyy epärealistiset budjetit ja hankesuunnitelmat. Ensinnäkin on paljon hankkeita, joissa toimittajavalinnat on tehty sopimuksineen ennen kuin on edes päätetty, miten käyttöönotto aiotaan suorittaa: halutaanko se tehdä mallilla big bang vai vaiheistettuna - ja vaiheistusvaihtoehtoja on taas usein ainakin puolen tusinaa. Käyttöönottotapa on päätös, joka vaikuttaa kaikkeen: kustannuksiin ja aikatauluun, ja niiden alla prioriteetteihin, resursoinintiin, tuote- ja asiakasrakenteisiin, missä järjestyksessä testataan, missä järjestyksessä ja aikataulussa hankkeesta seuraavat organisatooriset muutokset implementoidaan, koulutetaan henkilöstö jne jne. Voi vain kysyä, että mikä pohja hankkeen ROI:lla on, jos alku on noilta osin hoidettu persuus edellä puuhun. Hankkeeseen pitää lähteä asenteella, että tällä saavutetaan parempi ROI kuin aikaisemmalla - ja että tätä mitataan. Aikaisemmin mainitsemani skaalasokeus iskee alkuvaiheessa aina lähes pomminvarmasti: kun ei olla tehty kotiläksyjä vastaavista aikaisemmista hankkeista, kaikki organisaatiotasot systemaattisesti aliarvioivat työmäärät, koska ne tuntuvat viimeisen 5-10 vuoden aikana totuttuihin lukuihin järjettömiltä. Toimittaja taas mukailee helposti epärealismia saadakseen kaupan, kunhan on ensin varmistanut, että juridisesti syy ei tule kaatumaan sen päälle.
Käyttöönoton suunnittelun laajuus aliarvioidaan. VR:nkin lippujärjestelmähankkeen kaltaisen käyttöönoton suunnittelu vie helposti 6kk, kun suunnittelussa katetaan tarvittavat prosessit, järjestelmät, koulutetaan ihmiset, suunnitellaan etukäteen sisäinen ja ulkoinen viestintä kriisiviestinnän kera, tehdään jatkuvuussuunnitelmat jne. Jutusta sai sellaisen kuvan, että yksi syy olisi ollut puutteellinen kuormitustestaus. Tuokin on suurissa hankkeissa varsin normaalia: kun alusta saakka homma on ollut sivuraiteilla, kokonaisuus on kasassa on niin myöhään, että liiketoimintajohdolla ei ole ole enää sisua altistaa järjestelmää kunnon kapasiteetti- ja stabiliteettitestille.
Jokaisella hankkeella on toki omat tarinansa, yritin yllä esitellä muutamia aika monelle isolle hankkeelle tyypillistä syytä, joihin olen itse hankkeissa törmännyt ja/tai lukenut.
Jälkiviisaus on toki sitä helpointa viisausta, mutta kuten sanottu, onhan näitä tutkittu.
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.
Voit osallistua keskusteluun, kun olet rekisteröitynyt käyttäjäksi ja kirjautunut sisään.
Kirjoittaja on Suomen Kuvalehden verkkopalvelun toimittaja.
Lue kaikki kirjoittajan jutut
Hetkinen tilausta käsitellään.
HaMi kirjoitti:
Kannattaneeko IT-firmojen tehdäkään kerrasta valmista, kun tilaajilla ei riitä tietämys mitä vaatia, näin piikki pysyy auki, työllisyyden jatko on turvattu, ja käsi on valtion kukkarolla vuodesta toiseen.
http://www.talouselama.fi/uutiset/virastot+polttivat+yl i+900+miljoonaa+tietohallintoon/a671211