Kaikki ei ole pelkkää pilveä
Kesän aikana oli taas tilaisuus käydä analyyttisesti läpi sekä alan työpaikkailmoituksia että tarjouspyyntöjä. Ainakin yksi asia nousi esiin: Nyt kun softaprojektit rakennetaan pilveen, helposti ajatellaan, että pilvi – tai teknologia ylipäätään – olisi projektin ytimessä. Tässä mennään helposti harhaan.
Toukokuisesta senioriteettia koskevasta blogikirjoituksesta syntynyt keskustelu aktivoi ajattelemaan alan osaamisvaatimuksia laajemminkin. Kun etsin työntekijöitä, mitä minun pitäisi etsiä? Kun haluan uralleni uuden suunnan, mistä sitä etsin? Kun projektini pitää saada menemään putkeen, mitä surinasanoja (buzzword, toim. huom.) tiimin CV:istä pitää löytyä?
Kuinka azurekas projektini oikeastaan on?
Pilveen voidaan tehdä monenlaista. Jos työn alla on äärimmäisen reaaliaikainen pilvianalytiikkaa vaativa IoT-ratkaisu tai pitkälle hiottu integraatioalusta, oikeiden pilvipalveluiden valinta ja konfigurointi ovat hyvin keskeinen osa työtä, ja käytännön osaaminen juuri oikeista palveluista on tärkeää. Jos hankkeessa hahmotellaan pilviajan IT-infrastruktuurille sopivia hallinta- ja tietoturvakäytäntöjä, kysymys on nimenomaan pilvikeskeisestä asiantuntijatyöstä.
Toisaalta kaikissa projekteissa, varsinkaan ohjelmistotuotannossa, pilvi ei välttämättä näyttele kovinkaan keskeistä roolia. Ylivoimainen valtaosa pilveen tehtävistä sovelluksista käyttää loppujen lopuksi vain hyvin pientä joukkoa tarjolla olevista palveluista. Azure-perspektiivistä voisi kärjistää, että lähes kaikki pyörii App Servicella, SQL Databasella ja Storage Accountilla.
Microsoft on investoinut satoja tai tuhansia henkilötyövuosia tehdäkseen Azureen siirtymisestä mahdollisimman helppoa myös kehittäjille. Monelta osin Redmondin tavoitteena onkin ollut se, että pilvipalveluiden käyttö ei suuremmin vaikuttaisi koodiin, ja että ajoympäristön valinta olisi kehittäjänkin kannalta mahdollisimman merkityksetön.
Varsinkin isommissa järjestelmähankkeissa varsinaista pilveen liittyvää tekemistä on lopulta vain pieni osa itse projektista. Suurin osa aivotyöstä liittyy asiakkaan liiketoiminnan mallintamiseen, oikeanlaisiin käyttöliittymiin ja monimutkaisten komponenttikokonaisuuksien yhteentoimivuuden varmistamiseen. Nämä tehtävät eivät useinkaan riipu olennaisesti siitä, onko tuotantoympäristö Dublinin Azuressa vai Perä-Posiolla vaatekomeroon sijoitetulla vanhalla pöytä-pc:llä. Miksi siis ohjelmistoprojektissa jokaisen devaajan pitäisi olla Azure-guru?
Avainsanafetissi vääristää kokonaiskuvaa
Perusongelma teknologisiin nimikkeisiin keskittymisessä on se, että se ohjaa ajattelua liiaksi toteutuksen yksityiskohtiin. Toki projektin sujuvuuden kannalta on hyvä, että kaikki toteutustekniikat ovat tiimillä hanskassa, mutta projektin ideaalikokoonpanoa ja työjärjestystä mietittäessä olisi hyvä pohtia myös sitä, mitä oikeastaan haetaan. Riittääkö Azure-osaamiseksi webbisovellusten asentaminen Azureen, vai tarvitaanko kokemusta globaalien kuormantasausjärjestelyiden toteutuksesta? Riittääkö että tiimillä on selkeä visio palveluväylän toteuttamisesta, vai täytyykö jokaisen tekijän olla Service Bus -guru?
Samoja kysymyksiä on toki pilven ulkopuolellakin. Esimerkiksi fronttiosaajia voi olla todella montaa sorttia: yksi hallitsee suvereenisti CSS-tyylittelyn, toinen on kyvykäs JavaScript-arkkitehti, kolmannella on pitkä kokemus hakukoneoptimoinnista ja analytiikasta. Yksittäisen teknologian sisälläkin on sudenkuoppia tarjolla – esimerkiksi React-devaajaa etsittäessä pitäisi miettiä huolella, miten tämän osaamista tullaan käyttämään. Viisi vuotta React-kokemusta voi olla loistava tausta, mutta se voi myös tarkoittaa sitä, että kehittäjän näkemykset perustuvat viisi vuotta vanhaan Reactiin, joka taas ei välttämättä maistu uudempien versioiden aikana mukaan tulleille.
Oma suositukseni onkin ollut se, että näennäisselkeiden muodollisten kriteerien (”Kandidaatilla on oltava vähintään neljä vuotta kokemusta Azuresta”) kannattaisi käydä yksityiskohtaista ja syvää keskustelua rekrykandidaatin tai potentiaalisen tiimin kanssa: Miten huolehditte hakukoneoptimoinnista React-sovelluksessanne? Jos Azure Functionsin suorituskyky ei olekaan riittävä, miten lähdette selvittämään tilannetta? Miksi haluaisitte käyttää tässä kohtaa Kafkaa eikä Service Busia?
Kirjallisille kysymyksille on paikkansa, sillä niihin ehtii rauhassa miettiä perusteltuja vastauksia. Toisaalta varsinkin projektiryhmää kasattaessa on huiman arvokasta haastatella koko tiimiä. Jos kaikki vastaukset tulevat yhdeltä arkkitehtihahmolta, onko muu porukka luontevasti samaa mieltä? Täydentävätkö henkilöt toisiaan, kiistelevätkö he rakentavasti? Vaikuttaako junioreillekin löytyvän luonteva paikka, uskaltavatko he tuoda omia näkemyksiään esiin?
Vain hyvin harva projekti kompuroi pohjimmiltaan tekniseen osaamattomuuteen. Laatuvelkaan ja huonoon suunnitteluun kyllä, mutta vain hyvin harvoin projekti itsessään on tekijöilleen tekniikan puolesta liian vaikea. Sen sijaan huonosti organisoituneet, dysfunktionaaliset ja liian vaihtuvat tiimit ajavat hankkeita jatkuvasti karille.
Teknologiabingo ja urakehitys
Keskittyminen tiettyihin teknologisiin nimikkeisiin näkyy myös työnhaussa. Kandidaatit saattavat kertoa haluavansa päästä tekemään Azurea/Reactia/RESTiä tai jotain vastaavaa. Toinen taas ilmaisee oman osaamisensa kertomalla, että ”olen tehnyt full stack pilvipalveluita viisi vuotta”, olkoonkin että ilmaisussa tarkennusta tarvitsevat ainakin ”full stack”, ”pilvipalvelut” ja ”viisi”. Samalla törmätään markkinan tukkoisuuteen – ani harva ostaja tai rekrytoija ymmärtää esimerkiksi pilvipalveluiden käyttöä niin syvälti, että osaisi kaivata nimenomaan tietynlaista Azure-spesialistia. Näinpä vuosikymmenen Azure IoT:n syvää päätä jyystänyt näyttää markkinalla monesti samalta kuin App Serviceen pari webbipalvelua vienyt: Azure-osaajalta.
Syvemmät tietojenkäsittelytieteen trendit ja ajattelutavat – hajautus, oikeanlainen arkkitehtuuri, tekninen tehokkuus jne. – jäävät useimmiten käytettyjen työkalujen listan varjoon. Näin on erityisesti verkkopalveluissa, joissa ylivoimainen valtaosa menestyksen kannalta kriittisestä käyttökokemuksesta ei liity mitenkään pilveen.
Ei kuitenkaan niin pahaa, etteikö jotain hyvääkin. Teknologiabingo nostaa ajoittain yksittäisiä välineitä suureen arvoon. Koska välineen opetteleminen on yleensä triviaalia oikean syväosaamisen hankkimiseen verrattuna, uudistuva välinekirjo luo aina junioreille tilaisuuksia hypätä projekteihin ammatillista ohituskaistaa pitkin. Tämän vuosituhannen aikana Linux, PHP, AJAX ja React ovat olleet taikasanoja, joiden melko alkeellinenkin osaaminen sopivassa vaiheessa on antanut anteeksi paljon työkokemuksen puutteita.
Trendi jatkuu, ja esimerkiksi perinteisiin REST-rajapintoihin kypsyneet organisaatiot etsivät GraphQL-mainintoja sisältäviä CV:itä – täysin huolimatta siitä, että lopulta rajapinnan kyselytekniikka on vain varsin vaatimaton osa minkä tahansa rajapintapalvelun toteutusta. Taustalle jäävät erisnimettömät osat laadukasta rajapintapalvelua: tietoturvaosaaminen, skaalautuvuus, valvottavuus, löydettävyys ja monet muut, joille ei löydy tässä käsitemyrskyssä sellaista nimilappua, joka osattaisiin CV:hen ripustaa.
Parasta porukkaa valitsemassa
Lopulta avainasemassa on se, millaista hankekokonaisuutta ja elinkaarta ollaan rakentamassa. Tässä IT-alalla on vielä kehittymisen paikka: suunnittelussa usein keskitytään liikaa projektivaiheeseen ylläpitovaiheen unohtuessa. Yleensä hanke kestää kuitenkin vain vuoden-pari, sen jälkeinen todellisuus taas helposti vuosikymmenen.
Kuka sovellusta ylläpitää julkaisun jälkeen? Miten integraatioista huolehditaan, kun ympäröivät järjestelmät muuttuvat? Kenen päähän hankkeen aikana kehittyvä uusi liiketoimintaosaaminen juurtuu, ja miten sen jakamisesta huolehditaan? Kun ylläpitotiimi luultavasti on projektiryhmää pienempi, miten siihen saadaan pakattua tarvittava osaaminen?
IT-alan muutosvauhti pakottaa meidät kaikki jatkuvaan oppimiseen ja uudistumiseen. Osittain tämä toteutuu työpaikan vaihtamisen kautta: jos vanhassa juuttuu liikaa yhteen ja samaan, uutta on haettava muualta. Jos valitsee projektiin kaiken nähneitä guruja, heillä ei ole tässä projektissa mitään opittavaa, eikä luultavasti myöskään syytä pysyä siinä kaiken valmistuttua. Seniorille tylsistyttävän simppeli järjestelmä voi puolestaan tarjota juniorille kymmenen vuoden urahaasteen, ja siinä samalla parkkiintuva junnu toimii järjestelmän elinkaaren mittaisena tukipilarina.
Oikeita vastauksia ei ole, mutta jos edes tulee kysyneeksi tämän blogipostauksen esiin nostamia kysymyksiä, todennäköisesti on jo parantanut projektin onnistumisen mahdollisuuksia. Ja kyllä: hyvä hankesuunnittelu sisältää myös elinkaarisuunnittelua ja henkilöstösuunnittelua.
Jounin lähes 30 vuoden IT-uran ydin on ollut koodaamisessa, mutta nykyisin hän keskittyy teknologiastrategiaan, auditointeihin ja hankemäärittelyihin. Jouni on Devisioonan toimitusjohtaja ja yksi maailman 180 Microsoft Regional Directorista. Hänet on myös palkittu vuoden 2023 Microsoft-vaikuttajana työstään Azure-pilven ja tekoälyn parissa.
