hipster
29.10.2018 Petri Tuomaala Tuotekehitys

Teknologiavalinnat ilman hipsterikerrointa

Teknologia

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 kokemusta teknologista kertyy, joko oman tai suuren yleisön kokeilujen kautta, on niiden käyttöä paljon helpompi harkita.Jos kokemusta ei ole, on syytä perustella valinnat mieluummin tuttujen ja turvallisten teknologioiden kautta ja ottaa niistä kaikki irti. Tällä tarkoitan sitä, että opetellaan niiden sisäinen toiminta, parhaat käytännöt ja 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 painottuvat 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 miettiä teknologiavalintoja ja pyri tekemään niistä lisäselvityksiä. Kun vaatimukset alkavat selvitä tai niiden osalta pystytään tekemään päätöksiä, 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, 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.

Kuin 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 huoneisiinsa, voidaan ovi tarvittaessa laittaa kiinni tai huone rakentaa uudelleen vaikuttamatta koko talon toiminnallisuuteen. Jos kuitenkaan rakennelman vaatimukset eivät ole tiedossa – 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.