Petri Tuomaala | Tuotekehitys | 24.3.2017 11:48

Teknologiavalintojen sietämätön keveys

Teknologia  Prosessi 

FCG Elbit Oy - Teknologiavalintojen sietämätön keveys

Aika-ajoin työssä on niitä hienoja hetkiä kun aletaan tekemään jotain ihan uutta (tämä hetki on muuten nyt, hae mukaan). Meille ohjelmistoalan ammattilaisille tämä tarkoittaa, että päästään valitsemaan uuden hankkeen tai tuotteen teknologioita. Tätä varten on opiskeltu ja kaikki aikaisempi tekeminen on luonut tälle pohjaa. Muistissa on vanhat virheet ja miten ne tällä kertaa vältetään. Kädessä on kuuma kahvi, aurinko kerrankin paistaa, pieni tuulenvire kutittelee jäljellä olevaa hiusta ja uuden tekemiselle on vain taivas rajana. Tästä tulee parhaiten suunniteltu hanke koskaan!

TAKAISIN TODELLISUUTEEN

Kuluu päivä tai kaksi kun realiteetit iskee. Edessä on ainoastaan taiteilijoilta tuttu tyhjä valkoinen canvas. Riskit ja vaihtoehtojen määrä alkaa painaa leukaa tutusti kohti rintaa. Samaan aikaan Raahelainen pessimismi alkaa nostamaan omaansa. Ei tästä mitään tule! Vaikeuksien hetkellä palaan itse perusasioiden äärelle. Näiden perusasioiden huomioimisella teknologiavaihtoehtojen määrää saadaan rajattua ja riskiä vääristä valinnoista pienennettyä.

YHDESSÄ TEKEMINEN

Ensimmäinen nyrkkisääntö teknologiavalintoihin on tiimin huomioiminen. Huomioimisella tarkoitan sitä, että tiimi osallistuu teknologiavalintojen tekemiseen ja vastaavasti teknologiavalinnat on sellaisia, joihin tiimillä on osaamista tai potentiaalia. Kaukana on ne päivät, jolloin yksittäinen arkkitehti, tai vastaavassa asemassa ollut, määritteli hankkeen teknologiavalinnat.

Pelkkää demokratiaa valintojen tekeminen ei kuitenkaan ole. Kaikille on eduksi, jos arkkitehti tai valinnoista vastaava, on pystynyt rajaamaan mahdollisuuksia esimerkiksi muutamaan vaihtoehtoon. Tällöin tiimi pystyy evaluoimaan niiden toimivuuden ennen lopullista valintaa. Samalla saadaan kokemusta vaihtoehdoista ja löydetään niistä parhaiten tiimille sopivat. Kun asioita evaluoi isommalla joukolla, tulee vaihtoehtojakin tarkasteltua useasta eri näkökulmasta. Tällöin voi paljastua uusia vaatimuksia tai voi selvitä, että ollaan turhaan ampumassa tykillä kärpästä.

NYKYOSAAMINEN

Tiimin nykyinen osaamisalue on mielestäni teknologiavaihtoehtoja eniten rajaava tekijä. On turhaa kuvitella, että teknologiavalinta on tuottava, jos aikaisemmin pelkkiä Java-hankkeita tehneelle tiimille valitaan teknologiaksi esimerkiksi .NET. Toki aika korjaa puutteen, mutta ensimmäisen hankkeen uudella teknologialla voi aina enempi mieltää harjoitteluksi kuin laadukkaaksi tekemiseksi.

On kuitenkin kaikkien etu, että tiimi pystyisi toimimaan erilaisilla teknologioilla. Tätä voi tukea esim. sillä, että ydinteknologia olisi vaikka entuudestaan tuttu ja turvallinen Java, mutta osassa järjestelmää voidaan kokeilla jotakin uutta. Tällöin on tärkeää kapseloida kokeilut rajapintojen taakse, jolloin kokeilun hylkääminen tai uudelleenkirjoittaminen heijastuu mahdollisimman vähän kokonaisjärjestelmään. Tämähän oli yksi ydintoiminnoista eläkkeelle siirtyvässä SOA:ssa ja samaa ajattelumallia on myös mikropalvelulähtöisessä arkkitehtuurissa (korotettuna potenssiin X).

HIPSTERIKERROIN (TAI SEN VÄLTTÄMINEN)

Edellisessä blogissani jo hiukan kritisoin sitä, että teknologiavalintoja tehdään osin trendikkyyden kautta. Kaikki näyttää teknologian osalta hyvältä yleensä silloin, kun aihe on pinnalla ja teknologiasta on vähän kokemusta oikeissa järjestelmissä. Trendikkäitä ja uusimpia teknologioita on kuitenkin parempi testata omissa harrasteprojekteissa tai pienemmän riskin hankkeissa, kuin hypätä niiden kanssa suoraan pääedellä tuntemattomaan veteen. Kun kokemus teknologista kerttyy, joko oman tai suuren yleisön kokeilujen kautta, on niiden käyttöä paljon helpompi harkita.

Jos tällaista kokemusta ei ole, on syytä perustella valinnat mielummin tuttujen ja turvallisten teknologioiden kautta ja ottaa niistä kaikki irti. Tällä tarkoitan sitä, että opetellaan niiden sisäinen toiminta ja parhaat käytännöt, sekä mukautetaan omia toimintatapoja, työkaluja ja prosesseja niitä tukevaksi. Tämä korostuu hankkeissa, joiden elinkaari on pitempi kuin vuosi tai kaksi. Tällöin teknologiavalinnoissa painottuu ne (ehkä tylsätkin) teknologiat, joissa on todistetusti hoidettu taaksepäin yhteensopivuus (tai vähintään lupaus siitä) ja joissa ei ole vaaraa siitä, että ne katoavat yön aikana. Tämä tarkoittaa käytännössä yleisesti suosittujen teknologioiden käyttämistä tai avoimen lähdekoodin hankkeiden suosimista.

AI NIIN, NE VAATIMUKSET

Ilman, että tiedetään kehitettävän järjestelmän toiminnallisia ja ei toiminnallisia vaatimuksia, ei millään teknologiavalinnoilla voida tehdä onnistunutta hanketta. Hyviä arvauksia toki voidaan tehdä ilman tarkkaakin tietämystä siitä mitä ja minne ollaan tekemässä. Tällöin perustelu valinnoille ei voi kuitenkaan olla kuin tasoa: "... tämä nyt näytti hyvälle ja se sai paljon kehuja redditissä". Paneudu toiminnallisiin ja ei toiminnallisiin vaatimuksiin ennen kuin alat edes miettimään teknologiavalintoja ja pyri tekemään niistä lisäselvityksiä. Kun vaatimukset alkavat selviämään tai niiden osalta pystytään tekemään päätöksiä, niin pystyt hyödyntämään niitä teknologiavaihtoehtojen rajaamiseen ja säästät mahdollisesti itsesi isoilta yllätyksiltä hankkeen aikana.

Mikäli jostain syystä ei ole aikaa tai mahdollisuutta kunnolla selvittää vaatimuksia, niin toimintojen pilkkominen pieniksi rajapintojen takana toimiviksi kokonaisuuksiksi voi pelastaa tilannetta. Pyri tällöin määrittelemään tuotteen MVP-taso ja tekemään päätöksiä osissa matkan varrella. Tällöin mahdolliset virhevalinnat koskettavat pienempää osaa järjestelmästä ja niiden uudelleen tekeminen ei välttämättä kaada koko hanketta.

TALOA RAKENTAMASSA

Teknologiavalintojen tekeminen on vähän niin kuin talon rakentamista. Hyvän perustan päälle on helppo lähteä rakentamaan ja onnistuminen on todennäköisempää tutuilla rakennusmateriaaleilla. Välillä tulee kokeilla jotain uutta, nopeampaa ja hienompaa, jolla uudistetaan menetelmiä tai pienennetään kustannuksia.

Eristämällä nämä kokeilut omiin huoneisiin, voidaan ovi tarvittaessa laittaa kiinni tai huone voidaan rakentaa uudelleen, vaikuttamatta koko talon toiminnallisuuteen. Jos kuitenkaan rakennelman vaatimukset eivät ole tiedossa ja esimerkiksi maaperän koostumuksesta ei ole tietoa, voi matkan aikana tulla mutkia matkaan, jotka mahdollisesti vaarantavat koko rakennuksen. Panosta siis etukäteen siihen, mitä ollaan rakentamassa ja miksi sekä mitkä ulkoiset tekijät asettavat rakennukselle omia rajoituksia.

Teknologia  Prosessi 

Haemme nyt kokonaista tuotekehitystiimiä

Lue lisää

BLOGIuusimmat

Oulu

FCG Elbit Oy
Kiilakiventie 1
90250 OULU
020 761 4200

Helsinki

FCG Elbit Oy, Helsinki
Osmontie 34
00610 HELSINKI
020 761 4200

Toimitusjohtaja

Juho Toivonen
020 761 4250

Yhteys

p. 020 761 4200
s-posti: Javascript on pakollinen.

Seuraa...

Kerro muillekin...