IT-alan hassu käsitys työkokemuksesta

Koodaripula on ollut kesto-otsikkona jo vuosia. Vuosituhannen vaihde Nokian nousuineen potkaisi liikkeelle IT-koulutushuuman, ja nyt työmarkkina näyttää jakautuvan yhä selkeämmin kahtia. Kuten Hesarikin taannoin kirjoitti, alalle valmistuvia junioreita odottaa haastava ja mahdollisesti pitkäkin työnhaku, samalla kun headhunterit piinaavat senioreita. Tässä jutussa tarkastelemme kokemuskäsityksen vinoutumia ja pohdimme, mikä neuvoksi.

Mitä kehittäjän osaaminen oikeastaan on?

IT-alan hurja kasvu on kyseenalaistanut myös koulutuksen roolin. Jos itseoppineet tekijät voivat olla maailman huippuja, mikä merkitys yliopistolla tai AMK:lla lopulta on? Mitä CV:ssä oikeastaan pitää olla, jotta tulee rekrytoiduksi? Ja onko töihin pääsyn kriteereillä edes kunnon yhteyttä siihen, millä taustalla saadaan tuotettua asiakkaalle – sisäiselle tai ulkoiselle – sitä hyötyä, jonka takia töissä ollaan?

Oikean osaamisen tunnistamista vaikeuttaa se, että kyse on paljolti myös ympäröivän tiimin ja organisaation tarjoamasta tuesta ja muotista. Riittääkö devaajalle C#, vai tarvitaanko myös suomea? Onko kyky arvioida työmääriä olennainen? Tarvitaanko paineensietokykyä, entä taitoa nopeaan ajatteluun sosiaalisissa tilanteissa? Onko viiden vuoden Azure-tausta tärkeämpi kuin vuosikymmen sillä toimialalla, johon ratkaisua kehitetään?

Yleisiä oikeita vastauksia ei ole – tiimit, projektit ja sopimusmallit vaihtelevat. Selvää kuitenkin on, että IT-ala sabotoi sekä työntekijäviihtyvyyttä että lopputuloksen laatua keskittymällä niin rekrytoinnissa kuin ostamisessa ja myynnissäkin teknologiaosaamiseen, ja vielä liian yksinkertaisilla mittareilla: mitä enemmän vuosia tietyn asian parissa, sitä parempi osaaja.

Vuosi ei aina ole vuosi

Kokemustason mittaaminen on hyvin hankalaa. Varsinaisia selkeitä tasomittareita tietotyöosaamiselle on kaiken kaikkiaan hyvin vähän – kansainväliset kielikokeet ja muutamat sertifioidut alueet poislukien. Monet vakioidut testitkin, esimerkiksi Microsoftin sertifiointitentit, perustuvat tietämiseen, eivät käytännön osaamiseen tai soveltamiskykyyn. Ongelma on hyvin tunnettu. Sen vaikeuden edessä monet kuitenkin sulkevat aivonsa, ja päättävät tarttua helpommin mitattavaan suureeseen: kokemusvuosiin.

Vuosien laskemisen tavastakaan ei ole yksimielisyyttä. CV:ssä puhutaan herkästi 10 vuoden Oracle-kokemuksesta, jos on tehnyt yhden Oracle-projektin vuosikymmen sitten ja ylläpitänyt sitä sen jälkeen satunnaisesti. Entä voiko web-kehittäjä puhua 20 vuoden kokemuksesta, jos hän käyttää työssään vain niitä teknologioita ja toimintatapoja, joilla aloitti aikanaan – samalla kun koko ala on keksinyt itsensä uudelleen viimeisen vuosikymmenen aikana?

Kokemusvuosimittari peittää myös alleen suuren joukon työn sisältöön liittyviä vaihtelutekijöitä. Onko vuosikymmenen devausuran aikana tehty 300 erilaista lomaketta laajaan sisäiseen asiantuntijasovellukseen, vai onko sinä aikana palveltu kymmeniä eri asiakkaita eri toimialoilta? Yhden sovelluksen puurtaja saattaa olla kehittynyt melkoiseksi toimialan asiantuntijaksi, mutta relevanttia teknistä osaamista on voinut kertyä vain vuoden verran. Vuosikymmenen verran kukasta kukkaan hyppinyt devaaja taas voi olla teknisesti monipuolinen ja uusiin tilanteisiin aina valmis konsultti, mutta häneltä saattaa puuttua täysin kokemus siitä, miten tehdä sovellussuunnittelua ja ylläpitoa pitkän elinkaaren ratkaisuille.

Setä hämmästelee nuoria senioreita

Vauhdikkaasti kasvaneelle ja kehittyneelle alalle on syntynyt myös tehtävänimikekulttuuri, jossa koodareita aletaan kutsua senioreiksi muutaman vuoden kokemuksella, ja sitten pitäisikin jo edetä principaliksi tai arkkitehdiksi. Esimerkiksi Devisioonan tuotantotiimeissä ei käytetä varsinaisia tehtävänimikkeitä ollenkaan – osittain siksi, että emme ole keksineet tapaa kodifioida ihmisten osaamista mihinkään tittelihierarkiaan. Otetaanpa väliin henkilökohtainen muistelo:

Aloitin tietoteknisten järjestelmien kehittämisen työkseni 16-vuotiaana – 90-luvulla, kun IT:tä kutsuttiin vielä ATK:ksi ja web-palveluita uusmediaksi. Teini-iän loppupuolella jatkoin devailuhommia, ja vastasin samalla lisäksi 15 hengen tiimistä ja sen muodostamasta liiketoiminnasta. En enää muista, missä kohtaa kuvittelin olevani senioridevaaja, mutta näin jälkikäteen arvelen, että oikeasti pallo rupesi pysymään hanskassa siinä kohtaa, kun relevanttia työkokemusta oli 10–15 vuotta. Titteleistä oli löytynyt tuohon mennessä ainakin devaajaa, arkkitehtia, paria erilaista manageria ja CTO:ta.

Kyllähän sitä tuli toimitettua hurja määrä projekteja jo ennen kuin koin itseni senioriksi, mutta nyt kun nuoruuden huuma taittuu konservatiiviseksi keski-iäksi, hahmotan asioita kirkkaammin. Ehkäpä en ollutkaan 20 vuotta sitten se superstara, jolle jalustalle ympäristökin minua nosti?

Koodaustaitoni kehittyi hyvälle tasolle jo uran alkumetreillä, ja arkkitehtuuriosaamista tuli viidessä vuodessa varsin runsaasti – kun satuin tehtäviin, jossa uutta haastetta riitti joka kuukaudelle. Sen sijaan vainu liiketoimintaa parhaiten tukevista ratkaisuista, taito hankkia poliittista konsensusta speksin tueksi, kyky jakaa osaamista ja tekemistä uusille tiimiläisille… kaikki nämä tuottavuuden kannalta kriittiset taidot kehittyivät vasta paljon sen jälkeen, kun tekninen suorituskyky alkoi olla jo hyvinkin kohdallaan.

Sitä paitsi arkkitehtuurinäkemyskin on kasvanut. Kyse ei ole enää vain siitä, mikä on teknisesti tyylikkäin tapa toteuttaa jotain. Nykyinen ymmärrys on laajentunut enemmän mm. liiketoiminnan jatkuvuuden suuntaan – sellaiset näkökulmat kuin toimittajariippuvuudet, teknologiariskit, tietoturva ja kokonaisarkkitehtuuri ovat kypsyneet isolta osin vasta 15 vuoden urarajapyykin jälkeen.

”Mutta eiväthän nuo ole devaajan toimenkuvaa”, älähtää joku siellä takarivissä. Eivätkö?

Järjestelmäkehityksen monet kasvot

Lähes jokainen IT-ammattilainen laskeutuu osaksi tiimiä, jossa tekijöiden osaamiset toivottavasti täydentävät toisiaan. Harvoin kuitenkaan tilanne on niin puhdasoppinen, että projektipäällikkö vain hallinnoi, arkkitehti suunnittelee ja devaaja devaa. Käytännössä koodari on monitahoinen linkki projektinjohdon, vaatimusten omistajien, testaajien, ylläpitäjien ja asiakkaita palvelevien toimijoiden kesken.

Jos mietitään järjestelmäkehityksen tuottavuutta, koodilla ja sen laadulla on suuresti merkitystä. Silti vain harva kariutunut projekti epäonnistui siksi, että koodia ei ollut tarpeeksi – tai edes siksi, että sen laatu oli riittämätön. Useimmiten syvät ongelmat kumpuavat siitä, että ratkaistaan vääriä ongelmia, hallitaan aikaa huonosti tai ymmärretään liiketoimintaa puutteellisesti.

Varsinkin Suomen IT-projektien mittakaavassa koodarin viimekätinen vastuu toteutuksen laadusta on usein hämmästyttävän suuri. Harvassa ovat ne projektit, joissa devaajat ovat niin syvällä teknisessä siilossaan, etteivät heidän ei-tekniset kykynsä olisi kriittisiä projektin kannalta. Käytännössä siis: jos haluat mahdollisimman tuottavan tiimin tai hankkeen, unohda ajatus siitä, että kehittäjät olisivat vain teknisiä toimijoita.

Kaikki sanottu johtaa luontevasti siihen, että tiimien suorituskykyä ei kannata arvioida yksioikoisesti työhistorian perusteella. Tärkeämpää on ymmärtää tiimidynamiikka, suunniteltu työnjako ja ihmisten sopiminen siihen, sekä tiimin ympärillä olevat tukiresurssit – kenen kanssa sparrataan, jos vastaan tulee yllätyksiä? Jos asiaa tarkastelee tästä näkökulmasta, raa’at kokemusvuosiluvut eivät tunnu kovin olennaisilta.

Sitten pitääkin enää ratkaista yksi kysymys…

Kuka haluaisi juniorin?

Asetelma näiltä osin on kovin vino. Ensinnäkin IT-ostaminen on taas liukunut henkilöstövuokrauksen suuntaan, mikä kannustaa myös toimittajaorganisaatioita rekrytoimaan seniorivetoisesti – asiakkaat kun monesti haluavat ostaa vain ”kokeneita resursseja”.

Ajatuksen ymmärtää, mutta ratkaisu on varsin lyhytnäköinen. Ensinnäkin valtaosa hankkeista on sellaisia, ettei niiden tekemiseen vaadita suurtakaan senioriteettia. Kokemusvuosirimalla tavoitellaankin usein lähinnä sitä, ettei hommiin tarjottaisi ketä tahansa tumpeloita – olkoonkin, että alalta löytyy yllin kyllin esimerkkejä hahmoista, joille kaksi vuosikymmentäkään ei ole välttämättä tuottanut itsenäistä, laadukasta työotetta. Senioritiimien hankaluus on siinä, että perustason haasteet kiinnostavat vain rajallisen määrän aikaa, ja paine tiimin muuttamiseen kasvaa ajan yli – jos ei sopimalla, niin työpaikanvaihtojen kautta.

Toisekseen juniorien poissulkeminen tiimeistä rajoittaa niitä erilaisia tiimidynamiikan vaihtoehtoja, joita viisas resursoija – joko talon sisällä tai toimittajan päässä – voi keksiä. Keskimäärin senioritiimit hyötyvät mukana olevista junioreista (jopa pariohjelmoinnin kaltaisissa vaativissa malleissa).

Monesti tuoreemman kasvon mukanaolo pakottaa osapuolet artikuloimaan selkeämmin ja yksityiskohtaisemmin. Tämä voi hidastaa hieman yksittäisen tehtävän suoritusta, mutta usein maksaa vaivan takaisin – joko siksi, että puhuessa huomataan asioita, jotka muuten olisi tullut vain koodattua (väärin), tai sitten viimeistään siinä kohtaa, kun ylläpitoon siirtyvän sovelluksen dokumentaatio, tukirakenteet ja työkalut ovat paremmat kuin millaiseksi ne olisi tehty ilman juniorin mukanaoloa.

Vastasin juuri taannoin taas tarjouspyyntöön, jossa tiimi sai pisteitä Azure-kehityskokemusvuosiensa perusteella – ja koko tiimin pisteet määräytyivät sen vähiten kokeneen jäsenen mukaan. Tällainen ratkaisu ei kannusta punnitsemaan optimaalista työnsuunnittelua ja vastuunjakoa, ja joka tapauksessa sulkee junnujen tarjoamisen pois niissäkin tilanteissa, kun heille olisi osoitettavissa mielekäs, selkeä ja tuottava vastuualue hankkeessa.

Hyvään kasvuroolin päässyt junior-tekijä toimii monesti luontevana pitkäjänteisenä linkkinä kehitys- ja ylläpitovaiheiden tiimien välillä. Senioripulan aiheuttama suuri vaihtuvuus kasvattaa hankkeiden ylläpitokustannuksia, ja sopivat junnuroolit voisivat olla tähän yksi ratkaisu – jos vain asiakas uskaltaa ajatella sovelluselinkaarta projektivaihetta pidemmälle. Ostamisen mallit pyyhkivät monet näistä mahdollisuuksista taululta, ja samalla vaikeuttavat junnujen pääsyä alalle. Senioripula pahenee, ja noidankehä on valmis.

Tuottavuus syntyy hyvästä porukasta ja toimivasta työnjaosta

Jostain syystä IT-alalla on tapana aliarvioida työn organisoinnin merkitystä. Tiimit ovat kuitenkin paljon muutakin kuin vain CV:idensä summa – asia, minkä useimmat hiljaisesti mielessään tietävät, ja jota esimerkiksi ansiokas Peopleware-kirja analysoi varsin monitahoisesti.

Jostain syystä silti hankkeita käynnistettäessä työnjaolle ja sen toimivuudelle annetaan vain suhteellisen vähän painoarvoa. Osin kyse on myös mitattavuuden maksimoinnista – varsinkin julkisissa tarjouskilpailuissa tuntuu monesti vaikealta nojata haastatteluihin valintakriteereinä. Tämänkin näkökulman ymmärtää, sillä onhan osaamisen mittaaminen haastavaa jo yhden henkilön kohdalla, saati sitten kokonaisen tiimin.

Silti, monet parhaista ja pitkäkestoisimmista asiakas-toimittajasuhteista ovat lähteneet liikkeelle nimenomaan siitä, että asiakas on nimenomaan etsinyt sopivaa visiota edustavaa hyvää tiimiä, jonka he ovat halunneet tavata ennen töiden aloittamista. Kun sosiaalinen dynamiikka toimii, se vain toimii. Avoimuus, motivaatio ja uteliaisuus tarttuu, ja kaikki tämä rakentaa yhteistyösuhdetta tuottavammaksi ja toimivammaksi.

Ai niin – usein ne avoimimmat, motivoituneimmat ja uteliaimmat tyypit ovat niitä junnuja. Alalla taitaa olla vielä jotain opittavaa uusiutumisesta, luovuudesta ja tehokkuudesta.

Haluatko hankkeellesi toimittajan, joka miettii ihmisten viihtyvyyttä ja yhteensopivuutta – niin asiakkaan kuin toimittajankin päässä? Tai haluatko työpaikan, jossa näitä asioita pohditaan? Ota yhteyttä!

Kiitokset kuvista: Siora Photography, Aron Visuals, bert b