Riskit kannattaa ottaa heti kättelyssä

28.5.2019Lukuaika 10 min

Faces of Frantic -postaussarjamme saa pitkästä aikaa jatkoa, kun tech leadimme Hannu Räisänen jakaa tietojaan ja kokemuksiaan sovelluskehityksen kiemuroista yli 30 vuoden ajalta.

Miten menee, Hannu?

Kuuluu ihan hyvää, kiitos! Konsulttitoimeksianto, jonka parissa työskentelin yli puoli vuotta, päättyi tammikuun lopussa. Projektin tuotoksena syntyi Minimum Viable Product, ja nyt muut jatkavat kehitystyötä. Projekti oli kyllä todella mielenkiintoinen, mutta toisaalta nyt pitkähkön työrupeaman ja sitä seuranneiden lomien jälkeen on ollut hyvä tilaisuus keskittyä muihin asioihin, jotka jäivät intensiivisen toimeksiannon jalkoihin.

Mitä teet Franticilla?

Jos ajatellaan tittelinä, niin ratkaisuarkkitehti on varmaan lähimpänä nykyistä toimenkuvaani. Suunnittelen ja toteutan erilaisia sovelluksia ja tietojärjestelmiä eri mittakaavoissa ihan pienistä isompiin. Toteutusosa tarkoittaa pääasiassa ihan raakaa ohjelmointia, ja sen osalta olen kaikkiruokainen. En ole visuaalisesti mitenkään erityisen siunattu, mutta muuten kaikentyyppinen ohjelmointi käy. Usein tehtävänäni on ollut enemmän tällaiset laajemmat asiat, kuten arkkitehtuurin ja työtapojen määritteleminen kuin mitkään yksittäiset loppukäyttäjän toiminnallisuudet. Jos teen jonkun toiminnallisuuden, se on useimmiten yksittäinen integraatio toiseen järjestelmään.

Millaisia haasteita ratkot?

Tämä on oikeasti aika vaikea kysymys, mutta minä osaltani mallinnan asiakkaan liiketoimintaa – sekä nykyistä että ennen kaikkea tulevaa – tietojärjestelmäksi niin, että olennaiset osat siitä tulee kuvattua siihen järjestelmään. Oli sitten kysymys tiedon varastoinnista, prosessoinnista tai siirtämisestä toisiin järjestelmiin, ne ovat niitä ratkaisun isompia pilareita, joihin arkkitehtuurikin liittyy. Osan niistä saa päättää aika vapaasti, mutta erityisesti integraatiotapauksissa, joissa toinen pää on kiinnitettynä, ei ole vaihtoehtoja. Silloin etsitään parasta tapaa sopeutua.

Miten sinusta tuli ohjelmoija?

Minusta tuli ohjelmoija oikeastaan siksi, että tykkään rakennella kaikennäköistä. Pienenä tykkäsin rakentaa legoilla ja ne olivat siitä hyviä, kun oli valmiita palikoita joilla rakentaa. Kyllä minä tykkäsin veistellä puukollakin, mutta siinä en koskaan ollut hirveän hyvä. Jos ei sielunsa silmin näe sitä puu-ukkoa, niin on hankala vuolla tavoitteellisesti. Paremmalla silmä-käsi-koordinaatiolla minusta olisi voinut tulla puuseppä, mutta omat vahvuudet johdattivat toiseen suuntaan.

Koska olen aina ollut jossain määrin matemaattisesti ja kielellisesti lahjakas, aloin tehdä rakentamista mielessäni. Ohjelmointihan on erilaisten konstruktioiden rakentamista pään sisällä ja sen kuvaamista koodiksi. Omat taustavaikuttimeni lienevätkin siis  jonkin sortin looginen ja kielellinen lahjakkuus ja kiinnostus, sekä toisaalta rakentamisen ambitio ja viehätys säännönmukaisuuteen.

Varsinaisen ohjelmoinnin pariin pääsin, kun pitkään kinuttuani sain kolmosluokkalaisena vanhemmiltani tietokoneen ja kirjoitin ensimmäiset ohjelmani. Eivät ne kovin monimutkaisia olleet, mutta siitä se sitten hitaasti 30 vuotta sitten lähti. Ensimmäiset vuodet olivat tietysti leikkimistä koodilla ilman pitkäjänteisyyttä.

Tosissaan osaamisen syventäminen lähti liikkeelle vasta, kun aloitin yliopistolla tietojenkäsittelytieteen opinnot. Vuoden opiskelun jälkeen siirryin työelämään kesäduuniin ja siitä alkoi toden teolla se oppiminen ja yhtä oppimista se on ollut siitä lähtien. Loppua ei näy ja hyvä niin, se lienee yksi osa tämän alan viehätystä. Samaan aikaan on opittu valtavasti sellaista syvällistä perustaa, mikä pätee edelleen, ja sitten yksittäisiä teknologioita, joista moni on painunut jo manan majoille.

Mikä on työssäsi kaikkein haastavinta?

Oppiminen on tietysti haastavaa, mutta se on niin oleellinen osa tätä työtä, etten oikeastaan halua erottaa sitä erilliseksi prosessikseen, että ensin opitaan ja sitten mennään opeilla tekemään jotakin. Kyllä se aika usein on niin että on pakko opetella tehdessä, koska periaatteessa kaikki, mitä teemme, on enemmän tai vähemmän ainutkertaista. Vaikka joku olisi tehnyt samantyyppisiä ratkaisuja, niin ihan samanlaista ei ole tehty - ja jos on, niin siinä tapauksessa on typerää tehdä sitä uudestaan.

Mikä on kivoin asia työssäsi?

Tätä minä lähden purkamaan toisesta suunnasta, eli sieltä loppuasiakkaan päästä. On tosi hienoa olla mukana tekemässä sellaisia ohjelmistoja, joiden ansiosta loppukäyttäjän toiminta muuttuu oleellisesti helpommaksi. Siitä tulee hyvä fiilis.

Kivaa on myös abstraktioiden rakentaminen pään sisällä erityisesti silloin kun niitä pääsee pallottelemaan työkavereiden kanssa. Rakennetaan jotain mikä ei näy, mutta sitäkin rakennetaan yhdessä. Meitä on useampia näitä henkisiä puuseppiä hommissa.

Edellisessä toimeksiannossasi johdit asiakkaan kehitystiimiä, millaista se oli?

Teimme lisäarvopalveluita Suomen suurimpaan käytettyjen autojen nettimarkkinapaikkaan, nettiauto.comiin. Olin päättämässä hankkeen teknisistä suuntaviivoista kuten teknologiavalinnoista ja arkkitehtuuriratkaisuista ja käytännön työtavoista annettujen raamien sisällä. Vaikka tuotettu järjestelmä oli nettiauto.comista erillinen, niin synergiaetujen saavuttamiseksi tietyt yhteneväisyydet arkkitehtuurissa oli mielekästä ottaa huomioon. Kuten niin usein ennenkin, jälleen jo olemassa oleva oli määrittelemässä tulevaa.

Minulla oli meidän tiimin sisällä poikkeuksellisen hyvä mahdollisuus vaikuttaa siihen että mitä tehdään, millä suunnalla sitä tehdään ja mitä teknologioita siihen valitaan ja toisaalta sen suhteen miten ohjelmiston sisäinen arkkitehtuuri niillä palikoilla rakentuu. Vaikka me muutenkin katselmoimme ristiin toistemme koodia, niin minä katsoin muiden koodia lisäksi erityisesti siitä vinkkelistä, että muutokset eivät sotineet sitä miettimääni arkkitehtuuria vastaan.

Tarkoitukseni oli pyrkiä pitämään koodi selkeänä, helposti testattavana ja toisaalta muutettavana, että kun maailma muuttuu ja uusia tarpeita ilmenee, niin arkkitehtuuri ei olisi muutoksen tiellä. Ei tietenkään kannattanut käyttää liikaa aikaa varautuen johonkin mitä ei ole tulossa, mutta kun tiedetään, että jotain on tulossa niin ihan jokaiseen mäntyyn ei kannata käydä kopsauttamassa päätään. Siten työni oli välillä tasapainoilua sen kanssa, että minkä verran varaudutaan tulevaisuuteen ja minkä verran eletään tässä hetkessä.

Miten ulkopuolisen tiimin johtaminen eroaa Franticin projekteissa tiimin johtamisesta?

Jos lähdetään ihan siitä että Franticilla tehdään töitä tuttujen ihmisten kanssa, niin konsulttikomennuksella pitää uusien tekniikoiden ja toimialan lisäksi tutustua tekijöihin. Tech Leadina sitä lisäksi arvioi tuollaisessa tilanteessa, minkä tyyppisiä tehtäviä kenellekin kannattaa antaa. Siihen vaikuttaa tietysti kunkin oma osaaminen ja kiinnostus, mutta myös sen miettiminen miten pystymme takaamaan jokaisen kehittäjän ymmärryksen tietyistä ohjelmiston osista sellaisella tasolla, että mitään liian tärkeää tietoa ei poistu kenenkään yksittäisen kehittäjän mukana. Homman pitää pyöriä ja kehittyä edelleen riippumatta siitä, kuka projektia jatkaa.

Toinen iso ero oli se, että tässä projektissa kaksi koodaajaa työskenteli Intiasta käsin, enkä koskaan tavannut heitä henkilökohtaisesti. Open source -maailmassa tässä ei tilanteena ole mitään ainutlaatuista, mutta itselleni oli uutta se, että tein näin tiivistä yhteistyötä sellaisten tiimiläisten kanssa, joita en ole koskaan tavannut.

Olet vankka ketterän tekemisen puolestapuhuja - mitä hyötyjä siitä on asiakkaalle?

Minun mielestäni asiakkaan kannattaa aina tilata ketterää työtä, ja mitä enemmän asiakas pystyy siihen sitoutumaan, sitä hyödyllisemmäksi ketterä kehitys muodostuu asiakkaalle.

Scrumin edut liittyvät omissa silmissäni siihen, että se toteuttaa samaan aikaan ketterän kehityksen periaatteita ja ajatusmallia, ja tarjoaa päälle vielä timeboksauksen. Koska kaikki ennustettavuus ohjelmistotekniikassa on kohtuullisen vaikeaa, niin Scrum ei ikään kuin pyrikään ennustamaan yhtä sprinttiä pidemmälle. Mutta silloin kun ei ole liiketoiminnallista hyötyä ennustaa edes kahden viikon päähän, niin sitä ei kannata tehdä. Sekin on Lean-periaatteen mukaisesti ajanhukkaa. Arvioita ei kannata tehdä, jos niillä ei ole mitään arvoa kenellekään.

Paljon tärkeämpää olisi tehdä koko ajan sitä, mistä on eniten hyötyä ja pyrkiä taklaamaan riskejä aikaisin. Viisas malli kehitykseen olisi mielestäni alussa miettiä budjetti jollekin asialle mitä halutaan lähteä tekemään ja seuraavat askeleet määräytyisivät aina sen mukaan 1) mistä on eniten liiketoiminnallista arvoa ja 2) mikä on riskialtteinta. Jos on jotain minkä epäillään sisältävän riskejä, niin ne riskit kannattaa ottaa aikaisin, jotta niihin jää enemmän aikaa reagoida.

Mitä asiakkaiden pitäisi tietää tällä toimialalla nykyhetkestä ja tulevaisuudesta?

Asiakkaan olisi hyvä tuntea oma liiketoimintansa, se polku mihin he haluavat mennä ja mitä saavuttaa, ja sitten luottaa enemmän muihin siinä, miten sinne päästään. Ei kokonaan, mutta niin, että antaa muiden auttaa “miten”-vaiheessa tarjoten työkaluja. Asiakas näyttäisi suuntaa, ja muut toimisivat moottorina.

Meillä on monipuolisesti muutakin ammattitaitoa kuin tietyn tarkan ajatuksen siirtäminen teknisesti toimivaksi verkkopalveluksi. Apua löytyy myös asioiden ajatteluun ja miettimiseen, ei pelkästään toteuttamiseen. Kuulemme mielellämme asiakkaan ajatuksia liiketoiminnastaan ja pohdimme yhdessä, millaisiksi palveluiksi sen pitäisi muotoutua tai millaisia palveluja ylipäätään voidaan rakentaa tukemaan asiakkaan liiketoiminnallista visiota.

---

Mietitkö oman tiimin täydentämistä valikoiduilla ulkoisilla asiantuntijoilla? Onko tavoitteenasi muodostaa organisaatioosi monitoimittajatiimi digitaalisen asiakaskokemuksen kehittämisen tueksi ja veturiksi? Allokoimme mielellämme projektinjohdon, suunnittelun ja sovelluskehityksen asiantuntjoitamme auttamaan digitaalisten liiketoimintahaasteiden ratkaisemisessa, hankkeiden johtamisessa ja asiakaskokemuksen konkreettisessa toteuttamisessa. Konsultointiliiketoiminnan johtajamme Maija Typpi-Häkkinen kertoo palveluistamme mielellään tarkemmin. Ota yhteyttä!