Blogi

Digipalvelun kehitysprojekti usein onnistuu tai kuolee teknologian valintaan

Joonas Pajunen Bisnes Teknologia

Teknologiavalinta on yksi merkittävimmistä projektin onnistumista määrittelevistä tekijöistä. Teknologiavalinta voi osoittautua ongelmaksi monella eri tapaa – esimerkiksi oman tai saatavilla olevan osaamisen, lisenssi- tai käyttömaksujen, suorituskyvyn, sekä kyseisen teknologian kompleksisuuden näkökulmasta.

Teknologiavalinnat ovat lopulta tasapainottelua kustannustehokkuuden, tiimin osaamisen, sekä tulevaisuuden suunnitelmien välillä. Teknologiaa ja toteutustapaa pitää pystyä jatkokehittämään, jotta palvelun tarpeet on mahdollista täyttää myös tulevaisuudessa. Vaihtoehtoisesti toteutuksen pitäisi olla niin kustannustehokas, että tuotos voidaan ilman uponneiden kustannusten tuskaa korvata kokonaan myöhemmin.

Aloita suunnittelusta ja tarpeiden määrittelystä

Kaikki tekeminen kannattaa tietysti aloittaa suunnittelemalla ja sopimalla mitä tehdään, kenelle tehdään, ja missä ajassa tehdään. Kuinka pitkäikäisestä hankkeesta on kyse, millainen on tuotteen tai palvelun elinkaari ja sen vaiheet?

Suunnittelu on tärkeämpää kuin valmiin suunnitelman orjallinen noudattaminen. Ympäröivä maailma muuttuu, kuten myös saatavilla olevat teknologiat, käyttäjien tarpeet, ja palveluntarjoajan visiot. Teknologiavalintojen tulisi jättää vähintään muutamia ovia auki tulevaisuuteen, mutta ei liikaa. Liiallinen vaihtoehtoisiin tulevaisuuksiin varautuminen saattaa jättää turhia ovia auki ja monimutkaistaa abstraktiotasoja. Mutta niistä lisää myöhemmin.

Käyttäjäkohderyhmä vaikuttaa valintaan ja valinta aikatauluun

Teknologiavalintaa ohjaa lopputuloksen käyttäjäkohderyhmä: rakennammeko mobiilisaitin, PWA:n, vai natiivin App/Play Storesta löytyvän applikaation? Riippumatta edellämainittujen teknologioiden eroavaisuuksista ja teknisistä kyvykkyyksistä, on teknologiavalinnalla tässä kohtaa imagollinen vaikutus. Odottaako kuluttaja löytävänsä älypuhelimensa natiivista kauppapaikasta kaiken tarvitsevansa? Onko kilpailija vakavammin otettava, jos heiltä löytyy applikaatio ja itseltä ei?

Teknologiavalinta vaikuttaa myös kehittämisen nopeuteen ja etenkin ensimmäisen version lanseeraamisaikaan. Mitä kypsempi ja pitkäikäisempi teknologia, sitä enemmän teknologian ympärillä on pidemmälle vietyjä palveluita, jotka helpottavat ns. perusasioiden rakentamista ja niiden julkaisua. Valittu teknologia voi tarjota raamit, joilla päästään nopeasti alkuun, mutta jotka hidastavat kehitystä jatkossa. Vastaavasti alkuun hitaammin, mutta kyseiseen tarkoitukseen rakennettu pohja tarjoaa skaalautuvan ja tehokkaasti jatkokehitettävän stäkin kehittäjälle.

Aikatauluun vaikuttaa lopulta, yleensä teknologiavalintaa enemmän, budjetti, tiimin koko, ja markkinointiponnistelut. Joskus on myös järkevä vaihtoehto rakentaa ensin kevyt proof of concept -tyylinen ratkaisu, testata sitä, kerätä kokemuksia, ja sen jälkeen korvata nopeasti kasattu tuotos kunnollisemmalla ratkaisulla.

Jatkokehitys on palvelun elinehto

Kaikkia palveluja tulee jossain määrin jatkokehittää tai vähintään huoltaa. Mikäli palvelu itsessään pysyy staattisena, muuttuu ihmisten käyttäytyminen, tarpeet ja heidän käyttämänsä päätelaitteet. Lisäksi Internetin infrastruktuuri kehittyy, ja tietoturva-asioissa täytyy olla sekä valppaana että ennalta ehkäisevä muuttuvassa ympäristössä.

Jatkokehityksessä, oli se pientä hoivaa tai suurempaa iterointia, tarvitaan joskus vuosia aiemmin tehdyn teknologiavalinnan määrittämää osaamista. Vuosikausia etukäteen ilmenevää tarvetta tai trendejä on vaikea ennustaa. Teknologiavalinta tehdään parhaimmassa tapauksessa tulevaisuuden itselle ja jopa todennäköisesti tulevaisuuden kollegalle. Teknologiavalinta jopa määrittää, kuka tulevaisuuden kollega voi olla. Valinta saattaa aiheuttaa rekryyn tai rotaatioon hankaluuksia, ja samassa lukita toimittajan tai tekijän projektiin. Yhteen toimittajaan lukittautuminen voi olla asiakkaalle haitallista.

Yksi vaihtoehto on tehdä tylsiä valintoja. Valita teknologioita joita on jo käytetty pitkään, ja joita todennäköisesti tullaan käyttämään pitkään. Ns. “Lindy-efekti” kuvaa asioiden pitkäikäisyyttä vertaamalla tulevaa niiden tähänastisen elinkaaren pituuteen. Pitkään kuvioissa ollut teknologia on todennäköisemmin olemassa myös tulevaisuudessa. Mikä on ollut pitkään olemassa, sen ympärille on kasvanut yhteisöjä, toimintamalleja, osaamispääomaa, ja jopa ihmisten identiteettejä.

Huomioi tulevaisuus, mutta älä aseta sitä onnistumisen tielle

Teknologiavalintoja miettiessä tulee harkita tekemisen määrä ja toiminnallisuuksien monimutkaisuus. Kuinka paljon valittu teknologia tarjoaa itsessään valmiita ratkaisuja niihin ongelmiin, jota yrität ratkaista? Kuinka paljon teknologian ympärille rakentunut yhteisö tarjoaa ratkaisuja ja apuja ongelmatilanteisiin? Itse suosimme avoimen lähdekoodin työkaluja ja ratkaisuja, sillä näin voimme edellämainittujen asioiden lisäksi itse ratkaista asioita ja samalla kontribuoida yhteisön tuottamiin tuotoksiin.

Teknologiavalintoja perustellaan monesti tulevaisuuden suunnitelmien määrittämien käyttäjämäärien, skaalan, tai datamäärän avulla. Keskimäärin riittää, että performanssiasiat ratkaistaan vasta niiden ollessa ajankohtaisia. Silloin haasteeseen voi löytyä ajankohtaisempi ja käytännöllisempi ratkaisu, kuin mitä menneisyydessä on suunniteltu.

Valittuja teknologioita ennen pitkää korvataan toisilla valinnoilla. Kyseessä voi olla refaktorointi, porrastettu siirtyminen tai kertaheiton rykäisy täysin uuteen ympäristöön tai teknologiaan. Sopiva “separation of concerns” eli ongelmien eriyttämisen periaate, jonka mukaan keskitytään kerrallaan yhteen, hyvin määriteltyyn osaan, antaa kehittäjille tiettyä vapautta tehdä uusia valintoja tulevaisuudessa – oli kyseessä abstraktointi, mikropalveluarkkitehtuuri tai jokin muu vastaava ratkaisu.

Abstraktointi, reunatapauksiin varautuminen ja päättymätön jossittelu voi syödä tekemisestä vauhdin, paisuttaa koodipohjaa ja vähentää kokonaisratkaisun ymmärrettävyyttä. Ole siis tarkkana varautuessasi teoreettisiin mahdollisuuksiin ja uhkakuviin, jotta perinpohjaisuus ei asetu onnistumisen tielle.

Sopivan kokoisen riskin ottaminen palkitsee

Lopulta kyse on aikaansaamisen vauhdista nyt, pian, ja myöhemmin. Eri ajankohtiin vaikuttaa eri asiat; nykyinen osaaminen, oppimismahdollisuudet, rekry, käyttäjämäärän skaalautuminen, pivotoinnin mahdollisuudet, budjetti, rahoittajat, aikataulu, lupaukset. Oikeaa vastausta ei ole geneerisesti, eikä yleensä tapauskohtaisestikaan. Vastauksia ja suunnitelman sen sijaan saa kokeneilta eri alojen asiantuntijoilta.

Kyse on sopivasta riskin ottamisesta, myös teknologiavalintoja tehdessä. Ilman riskiä, on vaikea löytää erottautumistekijöitä ja kilpailuetua. Riskiä ottaessa täytyy ehdottomasti välttää katastrofaalisen riskin ottamista, jotta riskejä voi ottaa uudelleen ja uudelleen.

Toisaalta riskiä ei tarvitse ottaa teknologiaa valitessa, vaan riskiä voi ottaa liiketoiminnan muilla osa-alueilla. Teknologiavalinnat voivat olla tuttuja ja turvallisia, ennakoitavia ja tylsiä.

Bonus: Fraktion suosimat teknologiat React ja React Native

Tarkastellaan vielä muutamaa useasti tekemäämme teknologiavalintaa, nimittäin Reactia ja React Nativea, ja miksi näihin päädymme.

React on ollut kuvioissa jo pitkään. Itse valitsimme sen ollessa jo suht tuore teknologia. Nykyään sitä osaa jo niin moni, että se on tulevaisuudenkestävä turvallinen valinta. Uusia potentiaalisesti “siistimpiä” ja teknisesti parempia teknologioita tulee ja menee. Reactin ympärille on rakentunut valtava ekosysteemi ja yhteisö, jotka tarjoavat ratkaisuja ja apua lähes mihin tahansa ongelmaan.

React Native on teknologiana nuorempi, mutta omassa luokassaan jo saavuttanut sopivan kypsyyden. Osaamista ja kokemusta ei tätä kirjoittaessa ole markkinoilla läheskään yhtä paljon kun Reactia, mutta toisaalta osaaminen on osittain päällekkäistä ja yhteensopivaa. Kokenut React-kehittäjä on päivässä tuottelias RN-kehittäjä, mutta ei vielä mobiiliasiantuntija. Yleinen mobiilikontekstin ymmärtäminen ja osaaminen on spesifiä teknologiaosaamista tärkeämpi asia, ja asia, jonka kartuttamiseen tarvitaan oma aikansa.

Suosimme osaamisen kehittämisen polkua Reactista React Nativeen, sillä se on web-kehittäjän näkökulmasta vaivattomin ja selkein reitti mobiiliosaamisen kartuttamiseen. Tällaisella teknologiavalinnalla voimme mahdollistaa sekä tuotekehityksen että kehittäjien synergiaetuja – voimme luoda entistä erilaisempia tiimejä sekä reagoida tuotteiden ja palveluiden kehitystarpeisiin entistä ketterämmin.

 

Onko organisaatiollanne projekti, jonka ensiaskeleita olette ottamassa ja pohditte teknologiavalintoja? Etsittekö kumppani sparramaan tai toteuttamaan?

Laita meille viestiä, niin keskustellaan.