Tämän Fiidin teemana on IT-projektit. Kukapa olisikaan parempi kertomaan niistä kuin lukuisissa eri projekteissa sekä toimittajan että asiakkaan rooleissa mukana ollut Jesse Julkunen, joka toimii Biitillä senioriarkkitehtina ja tiiminvetäjänä.
Haastattelu: Jaakko Koivisto
Julkunen on ollut mukana projekteissa, jotka ovat arvoltaan sahanneet kymppitonnien ja satojentuhansien eurojen välillä. Kerran hän on ollut ratkaisuarkkitehtina mukana hankkeessa, jonka arvo ylitti peräti viiden miljoonan euron rajapyykin. Myös “roolileikit” ovat tulleet hänelle vuosien varrella tutuiksi, sillä Julkusen roolit ovat vaihdelleet testauspäälliköstä projektipäällikköön ja toimitusjohtajasta arkkitehtiin.
Mitkä projektit ovat olleet niitä kaikkein ikimuistoisimpia? Tässä haastatelussa Julkunen käy läpi oman uransa mieleenpainuvimpia projekteja sekä kertoo samalla, mitä hän on niistä oppinut.
Suurimmat onnistumiset
Aloitetaan projektien perkaaminen niistä kaikkein mieluisimmista, eli isoimmista onnistumisista.
Julkunen kertoo, että yhteistä näille projekteille on ollut vähemmän yllättäen erinomainen lopputulos. Onnistuneimmissa projekteissa lopputulos on siis vastannut tai jopa ylittänyt sille asetetut odotukset.
Lopputulos ei kuitenkaan ole Julkusen mielestä ainoa mittari onnistumiselle. Hänen mielestään onnistuneimmissa projekteissa myös yhteistyö eri osapuolten välillä on toiminut erinomaisesti sekä ollut kaikille osapuolille antoisaa.
”Selkeän ja jatkuvan kommunikaation tärkeyttä ei voi projektityössä liikaa korostaa.”
– Selkeän ja jatkuvan kommunikaation tärkeyttä ei voi projektityössä liikaa korostaa. En ole koskaan kuullut, että kukaan olisi valittanut liian selkeästä tai liiallisesta viestinnästä.
Toisin kuin voisi äkkiseltään kuvitella, niin budjetin toteutuminen ei useinkaan ole ollut hyvä mittari koko projektin onnistumiselle. Joskus jopa budjetin ylittäminen on ollut perusteltua ja auttanut pääsemään parempaan lopputulokseen, jolloin lopulta myös asiakas on ollut kokonaisuuteen tyytyväinen.
Mitkä ovat sitten olleet niitä onnistuneimpia projekteja? Julkunen haluaa mainita kaksi aivan erityyppistä onnistumista.
– Onnistuneita projekteja tulee mieleen useita, mutta voisin kertoa kahdesta hieman erityyppisestä tapauksesta. Ensimmäinen projekti oli sellainen, jossa teimme edellisen toimittajan työn yliottoa. Asiakas oli siinä tilanteessa, etteivät he enää saaneet silloiselta kumppaniltaan riittävää huomiota tai uusia näkemyksiä. Lähtökohdat olivat haastavat, koska yhteistyön päättyessä nykyiseltä kumppanilta luonnollisesti katoaa kaikki motivaatio asioiden hoitamiseen. Asiakas hoiti kuitenkin tilanteen niin timanttisesti, että yhteistyön siirtäminen meille sujui jopa hämmästyttävän jouhevasti.
Julkunen kertoo, että varsinainen yhteistyö alkoi asiakkaan arkkitehtuurin läpikäymisellä. Sen katselmuksen pohjalta laadittiin yhteinen suunnitelma siitä, mitä asioita olisi syytä tehdä missäkin järjestyksessä. Yhteinen ymmärrys tavoitteista ja toimenpiteistä löytyi nopeasti. Näistä lähtökohdista ei ollut yllättävää, että koko projekti onnistui lupaavan alun jälkeen erinomaisesti. Sittemmin yhteistyötä on jatkettu useammalla jatkoprojektilla.
– Toinen esimerkki on aivan urani alkuvaiheilta. Olin mukana projektissa, jossa teimme peliriippuvaisille suunnattua softaa, joka auttaisi peliongelmaisia lopettamaan ajoissa. Tämä oli POC-tyyppinen (Proof of Concept) projekti, jota tehtiin agiilisti eli ketterästi. Projektin aikana tuntui välillä siltä kuin olisi kirjaimellisesti istunut asiakkaan kanssa sylikkäin. Tässä projektissa kaikki osa-alueet olivat kunnossa: asiakas osallistui aktiivisesti projektin kulkuun ja testaukseen, kommunikaatio oli erinomaista sekä pysyimme alusta loppuun budjetissa ja aikataulussa.
Julkunen kertoo, että näistä molemmista projekteista tärkeimpiä oppeja olivat sujuvan kommunikaation lisäksi oikeiden henkilöiden saaminen mukaan projektitiimiin sekä asiakkaan tuominen mukaan lopputuotteen kehittämiseen ja testaamiseen riittävän aikaisessa vaiheessa.
Epäonneakin matkassa
Toisinaan rajanveto onnistuneen ja epäonnistuneen projektin välillä on häilyvä. Joskus nimittäin sattuma voi puuttua peliin, jolloin lopputulos voi olla onnistuneesta projektista huolimatta jotain aivan muuta kuin odotettiin.
Julkunen muistaa uraltaan yhden tällaisen tapauksen erityisen hyvin.
– Asiakas halusi uudistaa järjestelmäänsä sekä siirtää samalla palveluita yhdelle alustalle. Tavoitteena oli rakentaa 360 asteen asiakasnäkymä. Olimme puolin ja toisin projektista innoissamme. Kyseessä oli teknisesti sinänsä yksinkertainen toteutus, johon saimme vieläpä asiakkaalta erinomaiset määrittelyt. Projektia vietiin eteenpäin hyvässä hengessä. Saimme työn valmiiksi parissa kuukaudessa, minkä jälkeen soitimme asiakkaalle ja kysyimme, milloin palvelu lanseerataan. Tässä kohtaa asiakas ilmoittikin, ettei palvelua lanseerata ollenkaan. He olivat päättäneet haudata koko palvelun, mille siinä sitten yhdessä asiakkaan kanssa hieman naureskelimme.
”Asiakkaan kannattaisi aina miettiä jo ennen projektin aloitusta, onko projekti organisaation strategian mukaista ja kannattaako sitä tehdä.”
Tätä projektia Julkunen ei laske epäonnistumiseksi, sillä projekti vietiin aikataulun ja budjetin puitteissa maaliin sekä asiakas sai juuri mitä halusikin. Tärkeimpänä oppina Julkunen pitää kuitenkin sitä, että asiakkaan kannattaisi aina miettiä jo ennen projektin aloitusta, onko projekti organisaation strategian mukaista ja kannattaako sitä tehdä.
Julkunen muistuttaa, että tässä epäonnisessa projektissa onni onnettomuudessa oli projektin toteutustapa. Kun kyse oli kuitenkin suhteellisen nopeasta ja ketterin menetelmin toteutetusta projektista, niin hukkaan heitetyn työn määrä jäi onneksi melko pieneksi.
Vaietut epäonnistumiset
Vaikka epäonnistumiset ovat projektimaailmassa verrattain yleisiä, niin harva haluaa puhua niistä avoimesti. Julkunen on kuitenkin sitä mieltä, että myös niistä pitäisi kertoa avoimesti. Tärkeintä on hänen mielestään oppia epäonnistumisista.
– Osana isompaa uudistusta rakensimme aikoinaan asiakkaalle isoa tuotekatalogia, johon tulisi kohdistumaan paljon hakuja. Heidän käyttämällään alustalla oli jo valmis hakukone, jonka uskoimme riittävän. Projektin edetessä vaatimukset alkoivat kuitenkin kasvaa, jolloin hakukoneen kyvykkyydet loppuivat kesken. Kun asiakas odotti, että hakujen tekemiseen kuluisi muutamia millisekunteja, niin pahimmillaan hakutuloksia joutui odottamaan 20 sekuntia. Jouduimme siinä kohtaa heittämään 300 työtuntia hukkaan ja miettimään koko hakuarkkitehtuurin uudelleen.
Julkunen muistelee, että monenlaisten vaiheiden ja erikoiskikkailujen jälkeen järjestelmä saatiin toimimaan halutulla tavalla. Lopulta siihen ei kuitenkaan ollut kukaan tyytyväinen, joten vain muutamia vuosia käyttöönoton jälkeen koko alustaratkaisu kirjoitettiin uudelleen. Silloin haudattiin kaikki se kehitystyö, johon oltiin siinä vaiheessa uhrattu jo valtavasti aikaa.
”Roadmap-ajattelu olisi ratkaissut ne ongelmat, joihin sitten yhdessä asiakkaan kanssa kompastuimme.”
– Isoin oppi tästä projektista oli pohjatyön tekemisen merkitys. Tässä projektissa esimerkiksi suorituskykyvaatimukset ohitettiin projektin alkuvaiheessa aivan liian köykäisesti. Käytännössä koko projekti vietiin ensin maaliin ja tarkasteltiin vasta sitten suorituskykyä. Myös asiakkaan olisi pitänyt miettiä asioita pidemmälle. Roadmap-ajattelu olisi ratkaissut ne ongelmat, joihin sitten yhdessä asiakkaan kanssa kompastuimme.
Joskus isommalta epäonnistumiselta voidaan välttyä sillä, että pinnan alla kytevät ongelmat ehditään huomaamaan aikaisessa vaiheessa. Myös tällaisista projekteista Julkusella on kokemusta.
– Rakensimme asiakkaalle heidän asiakkaidensa henkilötietoja käsittelevää palvelua, jonka tavoitteena oli digitalisoida ja samalla merkittävästi nopeuttaa päätöksentekoprosessia. Teknisesti rakensimme eräänlaista sateenvarjojärjestelmää, joka osaisi hakea useista eri järjestelmistä tietoa yhteen paikkaan. Hankeorganisaatio oli jaettu tiimeihin ja ongelmaksi muodostui se, etteivät tiimit keskustelleet keskenään. Olin tässä hankkeessa mukana testauspäällikkönä ja samalla ensimmäisenä henkilönä, joka tarkasteli kokonaisuutta yli tiimirajojen. Huomasin, että samat asiakaskäsitteet esiintyivät suunnitelmissa viidessä eri muodossa, eli lopputuloksena olisi ollut järjestelmä, joka ei olisi osannut linkittää eri lähteistä kerättyjä henkilötietoja samaan henkilöön.
Tämän projektin tärkein oppi liittyi Julkusen mielestä kommunikaatioon. Varsinkin jos samaa projektia työstetään useissa eri tiimeissä, niin yhteydenpidon täytyy toimia myös yli tiimirajojen. Projekti oli erinomainen oppitunti myös testauksen tärkeydestä, sillä ilman testausta – ja Julkusen itsensä tekemää huomiota – projektin lopputuloksena olisi ollut järjestelmä, josta ei olisi ollut juurikaan apua asiakkaiden tietojen käsittelemisessä.
Haastavimmat projektit kysyvät hermoja
Moni kertoo syttyvänsä haasteista. Tiettyyn pisteeseen asti haasteet innostavat, pakottavat meidät epämukavuusalueelle ja rohkaisevat meitä ylittämään itsemme. Sen tietyn pisteen jälkeen haasteet saattavat kuitenkin muuttua vuoriksi, joiden yli on vain päästävä. Toisinaan myös IT-projektit ovat sellaisia.
– Olin mukana todella isossa ja monimutkaisessa hankkeessa, jossa rakennettiin asiankäsittelyjärjestelmää. Järjestelmän piti noudattaa tarkasti silloin säädettyjä lakeja. Tähän projektiin liittyi todella paljon pieniä asioita, jotka oli saatava kuntoon. Minä olin laittamassa yhtä sellaista kuntoon. Roolini oli varmistaa, että PDF-tiedostot tulostuvat järjestelmästä oikein. Kun ensimmäisen kerran kokeilimme tulostamista, niin huomasimme tulosteiden näyttävän karmeilta. Tajusimme siinä kohtaa, että testattavaa olisi edessä hirvittävät määrät. Selkärangasta oli kaivettava “vielä jaksaa painaa” -asenne, joka lopulta auttoi hiomaan kaikki sadat eri tulostusvariaatiot kuntoon.
”Julkunen arvioi kokemustensa pohjalta, että testaamiseen vaadittava aika aliarvioidaan todella usein sekä asiakkaan että toimittajan puolelta, mikä johtaa ikäviin yllätyksiin matkan varrella.”
Vaikka tämä Julkusen mainitsema projekti vietiin kunnialla päätökseen, niin suurimpana oppina Julkunen pitää testaamiseen vaadittavan ajan realistista huomioimista jo projektia suunniteltaessa. Julkunen arvioi kokemustensa pohjalta, että testaamiseen vaadittava aika aliarvioidaan todella usein sekä asiakkaan että toimittajan puolelta, mikä johtaa ikäviin yllätyksiin matkan varrella. Tyypillisesti siitä seuraa joko mutkien suoristamisesta johtuvia laatuongelmia tai budjetin ja aikataulun venymistä.
Yleisellä tasolla Julkunen mainitsee vielä, että haastavimpiin projekteihin liittyy lähes järjestäen yksi piirre. Ne kärsivät ilmiöstä, jota kutsutaan scope creepiksi. Sillä tarkoitetaan tilannetta, jossa projektin laajuus kasvaa holtittomasti samalla, kun ratkaisuun lisätään uusia toiminnallisuuksia ja ominaisuuksia. Tyypillisesti tähän vielä yhdistyy tilanne, jossa unohdetaan tarkastella lisäysten vaikutuksia budjettiin ja aikatauluun, jolloin soppa muuttuu entistä sakeammaksi.
– Varsinkin isommissa projekteissa ajaudutaan herkästi tähän tilanteeseen. Vaatii hyvää projektijohtamista sekä rohkeutta ja kykyä osata myös sanoa asiakkaalle ei, jotta projekti saadaan pidettyä raiteillaan.
Lopuksi vielä ne erikoisimmat
Entä sitten ne erikoisimmat projektit, joissa Julkunen on ollut mukana? Niiden osalta pitää palata uran alkumetreille.
– Erikoisin projekti on ehdottomasti ollut ensimmäinen projekti, jonka vedin opintojeni päätteeksi. Teimme energiapuolella käytännössä IoT-hanketta aikana ennen IoT-laitteita. Meidän piti harjoitusprojektina luoda anturidataa analysoiva sovellus, joka osaisi tunnistaa, milloin laite olisi menossa rikki. Projekti oli hyvin erikoinen, koska meillä ei ollut mitään esimerkkejä, joista olisimme voineet ottaa mallia. Projekti oli myös siitä mielenkiintoinen, ettei meidän tarvinut murehtia ajasta tai rahasta, koska siitä ei maksettu mitään. Kyse oli vain siitä, kuinka kauan jaksoimme opiskelijaporukalla pakertaa projektin parissa.
Julkuselle projekti opetti ketterää kehittämistä, sillä loppujen lopuksi se oli hänen muistikuviensa mukaan lopulta noin versio 380, joka päätyi lopulliseksi toteutukseksi. Siinä välissä Julkunen oppi tiiminsä kanssa ideoimaan ja valikoimaan ideoista parhaat äärimmäisen nopealla syklillä. Ilman sitä toimintamallia tämä projekti saattaisi vieläkin olla kesken – ja Julkunen edelleen koulunpenkillä.
