Osaavat ohjelmistokehittäjät ovat avainasemassa ohjelmistoprojektin onnistumisessa.

Rakettitieteen ohjelmistokonsultit Tuomas Terho ja Joonas Muhonen kertovat Ite wikin haastattelussa konsultin roolista it-projekteissa. Samalla selviää, millaisiin vaaranpaikkoihin ohjelmistoprojektit voivat törmätä ja miten ne voitaisiin välttää.

Tuomas Terho aloitti ohjelmistotekniikan insinööriopinnot vuonna 1997. Hän suoritti ylemmän ammattikorkeakoulututkinnon 2017 ja on suuntautunut työelämässä sulautettujen järjestelmien ohjelmisto- ja elektroniikkasuunnitteluun.

– Olen työskennellyt useissa pienissä ja keskisuurissa firmoissa monenlaisissa tehtävissä rautasuunnittelijasta projektipäällikköön, Terho kuvailee työuraansa.

Joonas Muhonen on työskennellyt täysipäiväisesti vuodesta 2000. Hän valmistui töiden ohessa tietojenkäsittelytieteen maisteriksi vuonna 2007.

– Olen toiminut erilaisissa rooleissa, mutta ollut aina mukana myös käytännön ohjelmistokehityksessä. Olen työskennellyt erilaisissa suomalaisissa firmoissa suurista pieniin, suurimpana Elisa ja nyt pienimpänä Rakettitiede, kertoo Muhonen.

Rakettitiede välittää konsulteilleen keikat ja tarjoaa työkalut, mutta loppujen lopuksi työskentely on Terhon ja Muhosen mukaan aina erilaista asiakasyrityksestä ja projektista riippuen. Konsulttikaksikko on siis monenlaisissa liemissä keitetty.

Miksi kokeneet konsultit ovat arvokkaita digitalisaatiohankkeissa, ja milloin ulkopuolista konsulttia tarvitaan ohjelmistokehityksessä?

”Konsultilla ei ole kiinteää työsuhdetta firmaan. Siksi kokenut konsultti uskaltaa sanoa myös epämiellyttävät totuudet, mikä vie asiakasyritystä monella tavalla eteenpäin.”

– Konsultilla ei ole kiinteää työsuhdetta firmaan. Siksi kokenut konsultti uskaltaa sanoa myös epämiellyttävät totuudet, mikä vie asiakasyritystä monella tavalla eteenpäin. Objektiivinen näkemys osoittautuu usein arvokkaaksi projektin kannalta, sanoo Terho.

Joonas Muhosen mukaan on tärkeää, että asiakasyrityksellä olisi oma vahva ydinkehitysorganisaatio, joka osaa asiansa ja tuntee tuotteensa. Kun tuotteeseen on tarve tehdä merkittävää jatkokehitystä ja kehityshanke täytyy saada maaliin, voidaan lisätyövoimaa hankkia palkkaamalla ohjelmistokonsultteja.

– Toiminta kannattaa skaalata siten, että yritys voi missä tahansa tilanteessa hoitaa oman tuotteensa ylläpidon ja maintenance-tyyppisen kehitystyön. Jatkokehitykseen voidaan hankkia konsultteja, jotka tuovat resursseja ja näkemystä kehityshankkeeseen. Usein ohjelmistokonsultit auttavat myös päivittämään yrityksen osaamista ja virkistävät työtapoja, Muhonen toteaa.

Kaksikko haluaa välttää vastakkainasettelua, johon törmää ajoittain viestinnässä konsulteista puhuttaessa.

– Konsultit eivät tule yrityksiin viemään toisten hommia. Hekin haluavat ennen kaikkea tulla tekemään hyvää projektia ja saamaan onnistumisen kokemuksia, Terho sanoo.

Miten välttää vaaranpaikat ohjelmistoprojekteissa?

Ohjelmistoprojektien kohtaamat vaikeudet ja viivästykset on yleinen puheenaihe it-maailmassa. Mistä ohjelmistoprojektien haasteet johtuvat, ja miten karikot voisi välttää?

Usein puhutaan ohjelmistoprojektien suoranaisesta epäonnistumisesta, mutta Terho ja Muhonen haluavat heti ensimmäiseksi oikaista käsityksen mönkään menemisestä – projektit eivät yleensä epäonnistu, ne vain kohtaavat erilaisia haasteita.

Projektit eivät yleensä epäonnistu, ne vain kohtaavat erilaisia haasteita. 

– Ehkä olen ollut onnekas, mutta sanoisin, että projektit epäonnistuvat harvoin. Täyttä epäonnistumista tai tuotteen tekemättä jättämistä ei ole tullut koskaan vastaan, vaikka monessa olen ollut vuosien varrella mukana. Joskus projektit eivät vain suju niin hyvin kuin voisivat. Rahaa saattaa mennä tolkuttomasti enemmän kuin aiottiin, tekijät turhautuvat ja vaihtavat työpaikkaa tai aikataulu viivästyy, toteaa Muhonen.

– Olen samaa mieltä, projektit epäonnistuvat äärimmäisen harvoin, komppaa Terho.

Mutta yleinen tai jopa todennäköinen ongelma on, että projekti viivästyy tai kallistuu. Usein syy ongelmiin löytyy suunnitteluvaiheesta.

– Yksi työurallani monesti toistunut kuvio on se, ettei ole riittävän tarkasti alun perin rajattu, mitä lähdetään tekemään, kertoo Terho.

Kun määränpäätä ei ole matkan alussa riittävän hyvin määritelty, uhkaa koko matka mennä hukkaan.

”Yksi työurallani monesti toistunut kuvio on se, ettei ole riittävän tarkasti alun perin rajattu, mitä lähdetään tekemään.”

– Monissa projekteissa törmää tähän. Asiakas haluaa sitä ja tätä ja tuota, ja siitä sitten lähdetään tekemään prototyyppiä. On suurin piirtein tiedossa se, mitä projekti tulee maksamaan, mutta suunnitellaan vain se, mikä on nähtävissä. Mitä pidemmälle mennään, sitä enemmän halutaan kehittää. Kuluu kuukausi tai toinen ja kaikki haluaisivat eteenpäin,  mutta myös kustannukset juoksevat koko ajan, Muhonen toteaa.

Siksi jo prototyyppejä tehdessä pitäisi suunnitella tarkasti etukäteen, mitä ollaan tekemässä, kauanko siihen voi mennä aikaa ja miten toiminta rahoitetaan.

Puutteet viestinnässä hidastavat työskentelyä

Moni vaaranpaikka ohjelmistoprojektin eri vaiheissa liittyy jollain tavalla viestintään, oli se sitten viestintää projektin tarkoista spekseistä, viestintää eri tiimien välillä tai sisäistä viestintää läpi myynti- ja tuotantoketjun.

Tyypillinen päänvaivan aiheuttaja on myynti- ja kehitystiimien välillä vallitseva kommunikaation tai ymmärryksen puute.

– Kun rakennetaan miljoonan euron konttoritalo, ihmisillä on yleensä melko hyvä käsitys rakennusprosessista. Ensin kaivetaan monttu ja valetaan perustukset, sitten tuodaan paikalle elementtejä, esimerkiksi asennetaan viemäriputkia, ja niin edelleen. Ohjelmistokehitykseen sen sijaan liittyy paljon abstrakteja palikoita, joita harva ymmärtää. Silti esimerkiksi myyntiosasto voi kehittäjiltä kysymättä mennä lupaamaan loppuasiakkaalle sitä sun tätä, toteaa Muhonen.

Kehittäjillä yleensä on paras ymmärrys siitä, mitä voidaan tai pitäisi tehdä ja miten kauan siinä kestää. 

Kaksikon mukaan myynti- ja tuotekehitysosastojen on tärkeää kommunikoida ja löytää tasapaino siinä, mitä asiakkaalle voidaan luvata. Tuotteista pitäisi kysyä niiltä, jotka niistä parhaiten tietävät. Kehittäjillä yleensä on paras ymmärrys siitä, mitä voidaan tai pitäisi tehdä ja miten kauan siinä kestää.

– Tiimien pitäisi luottaa kaikkien ammattitaitoon. Jos devaajilta kysytään, mikä on teknisesti mahdollista ja mikä ei, täytyisi muistaa, että kehittäjät eivät tee valintojaan ilkeyttään vaan tehdäkseen työnsä huolellisesti. Kaikessa ajatellaan asiakkaan parasta, vaikka joskus joutuisi kertomaan ikäviä uutisia.

Terhon mukaan toinen tavanomainen vaaranpaikka on töiden priorisointi ja kommunikaation puutteet johdon ja tiimien välillä. Huono johtaminen hidastaa projekteja.

– Tuotekehitystä tekevillä tiimeillä on usein monta projektia jonossa. Jos johto vaihtaa projektien prioriteettejä usein, kaikki projektit hidastuvat. Tiimeillä kestää aina hetki orientoitua uuteen järjestykseen ja saada aikaan edistystä, Terho toteaa.

Vanhentuneet työtavat edistyksen esteenä

Ohjelmistokehityksen työkalut ovat viime vuosina kehittyneet suurin harppauksin. Muhonen ja Terho kertovat törmäävänsä silloin tällöin organisaatioihin, joissa vanhentuneisiin työtapoihin takertuminen uhkaa jumittaa projektin.

– On riski, jos tuotekehitysorganisaatio on päässyt rapautumaan. Monissa yrityksissä on joukko koodareita, jotka ovat olleet pitkään samassa firmassa, eikä heille ole kertynyt riittävästi kokemusta uusista työkaluista, jotka nopeuttaisivat työskentelyä, toteaa Terho.

”On riski, jos tuotekehitysorganisaatio on päässyt rapautumaan.”

Ohjelmistokonsultille voikin olla suuri haaste tupsahtaa keskelle firmaa ja huomata, että asiat tehdään vanhentuneilla ja hankalilla teknologioilla.

– Oman väen koulutukseen pitäisi aina panostaa. Varsinkin isommissa firmoissa olisi hyvä olla oma taho, jonka vastuulla on pitää huolta työkaluista ja niiden kehityksestä, ettei se jää vain kehittäjien harteille.

Jos yritykselle on vuosien aikana muodostunut oma ekosysteemi, eivät konsultit pääse suoraan hommiin, vaan joutuvat perehtymään työtapoihin, joita ei enää työkeikan jälkeen tule missään tarvitsemaan.

Uudet työkalut, työvaiheiden automatisointi ja jatkuva integraatio mahdollistavat paremman, tuoreemman koodikannan, joustavammat muutokset ja sujuvamman versionhallinnan. Yksi tärkeimmistä on kaksikon mukaan DevOps:

– DevOpsin periaatteet jokaisen softakehittäjän tulisi tuntea, riippumatta siitä, mihin ympäristöön kehitetään.

Välillä kannattaa siis tilata ohjelmistokonsultti ihan vain laittamaan työtavat ja työkalut kuntoon.

Vanhentuneista työtavoista uusiin siirtyminen ei kaikissa organisaatioissa onnistu helposti:

– Ne, jotka menetelmiä ovat alun perin olleet tekemässä, voivat käyttää vaikutusvaltaansa ja vastustavat muutosta. Tällaisessa organisaatiossa luoviminen on konsultille hankalaa.  Haasteena on keksiä, miten asiakas houkutellaan tutkiskelemaan ja hyödyntämään uudempia työtapoja, kertoo Muhonen.

Välillä kannattaa siis tilata ohjelmistokonsultti ihan vain laittamaan työtavat ja työkalut kuntoon.

Kirjoittajat Johannes Puro & Veera Kujansuu

 

Rakettitieteen Ite wiki-profiili
Rakettitieteen verkkosivut

 

Lue myös Kestävä ohjelmistokehitys

 

Lue Rakettitieteen blogista, miten vältät softaprojektin sudenkuopat jo suunnitteluvaiheessa: Ohjelmistoprojektin 7 kuolemansyntiä