Miten pedataan onnistunut mobiiliprojekti?
Vaativien mobiilisoftien kehittämiseen tarvitaan kokeneita devaajia, jotka voivat pienentää projektin kustannuksia ja nopeuttaa läpivientiä. Vaikka koodari on tukena ja turvana tekkivalintojen ja muidenkin pulmien edessä, on jokaisen sovelluskehitystä ostavan hyvä tietää, mitä kaikkea onnistunut mobiiliprojekti vaatii.
Uusia sovelluksia syntyy kuin sieniä sadepäivänä, joten joukosta erottautuminen on mobiilisovelluksen kehittäjän ensimmäinen koetinkivi. Esimerkiksi Androidilla on yli kolme miljoonaa applikaatiota Google Play Storessa (Android-statistiikasta lisää täällä).
Yksi tapa olla sovellusmetsän halutuin saalis – loistavan idean lisäksi – on tehdä kaikki vähän paremmin kuin kisakaverit. Yritysten mobiilistrategioiden viilaaminen ei ole ajanhukkaa, sillä mobiililaitteiden iloista nauttii yhä useampi yhä useammin. 3,8 miljardin ihmisen arvioidaan käyttävän älypuhelimia vuonna 2021 – vain viisi vuotta sitten vastaava luku oli 2,5 miljardia. Luureja hiplataan tiuhaan: esimerkiksi amerikkalaiset vilkuilevat puhelintaan lähes sata kertaa päivässä, ja erään selvityksen mukaan suomalaiset ovat näyttöjen skrollauksen EM-mittelöinnissä hopeasijalla, sillä ruutua rullataan jopa 227 metriä päivässä!
Sovelluksen pitäisi hurmata käyttäjät jo sovelluskaupan kynnyksellä muutamien kriittisten silmänräpäysten aikana, jotta käyttäjä ylipäätään tarttuu tarjoukseen. Ensivaikutelma ei tosin ole kaikki kaikessa, sillä jopa neljännes mobiiliapplikaatioista on kertakäyttökamaa ja ne haudataan roskakoriin heti ensimmäisen kokeilun jälkeen.
Appien konkreettinen hyöty tai hupi punnitaankin vasta sitten, jos ne aidosti auttavat käyttäjiään tai tuovat palvelulle lisäarvoa. Vaikka sujuva käyttökokemus on monen elementin summa, sovelluksilta odotetaan yleensä virheettömyyttä, laadukkuutta ja helppokäyttöisyyttä. Jos käyttäjillä on vaikeuksia löytää tai käyttää sovelluksen ominaisuuksia tai toimintoja, on syytä miettiä, miksi ne ovat edes olemassa – ja silloin ongelmiin on reagoitava nopeasti.
Aloittelijakin saa mobiiliappiksen helposti uunista ulos ja jakoon, mutta vaativimmissa softissa kehittämiseen tarvitaan kokeneita devaajia. Androidiin erikoistunut rakettitieteilijä Jussi Salmi kertookin seuraavaksi, mitä asioita kannattaa huomioida mobiilikehityksessä.
Cross platform -sovellus on nopea kehittää mutta haastava ylläpitää
Käytettävät tekniikat päätetään aina kunkin projektin tavoitteiden ja vaatimusten mukaan, ei uutista siinä. Tekkivalintoihin on kuitenkin olemassa joitakin nyrkkisääntöjä.
Jos sovelluksella on tarkoitus hoidella esimerkiksi firman sisäisiä prosesseja, kuten myyntiä tai vaikkapa varastonhallintaa, appia ei välttämättä tarvitse kehittää kaikille alustoille (lue: kahdelle). Tässä tapauksessa ovat cross platform- ja natiivikehitys lähes yhtä aikaa vieviä. Yleensä appikset kuitenkin kehitetään sekä Androidille että iOS:lle. Samaa koodipohjaa hyödyntävällä cross platform -alustalla sovellus saadaan käyttäjien puhelimiin ripeästi ja usein myös kustannustehokkaasti.
Salmen mukaan cross platform -kehitys voi olla nappivalinta silloin, kun sovelluksella ajatellaan olevan lyhyt elinkaari, sovelluksen ominaisuudet muuttuvat nopeasti tai sovellus ei käytä puhelimen antureita tai muita oheislaitteita.
“Cross platform -alustojen suorituskyky on heikompi kuin natiivisovellusten, varsinkin jos käytetään hybridialustaa, jolloin sovellusta ajetaan käyttäen webbiteknologioita. Tällaisten kehitysympäristöjen haittapuolena on myös se, että ominaisuuksia voidaan joskus joutua karsimaan, jotta sovellus saadaan toimimaan monessa käyttöjärjestelmässä. Cross platform -alustoille voidaan joutua odottamaan käyttöjärjestelmien uusimpia ominaisuuksia, kun natiivina ominaisuudet voidaan ottaa heti käyttöön”, Salmi sanoo.
Cross platform -alustoilla koodaaminen voi olla helppoa mutta ylläpitäminen haastavaa. “Cross platform -kehitysalustat elävät hyvin nopeasti. Alustojen suosiot saattavat vaihdella ja voi tapahtua niin, että tänään hyväksi havaitulle alustalle ei olekaan enää huomenna osaavia kehittäjiä”, Salmi selventää.
Natiivi tarjoaa hyvän käyttäjäkokemuksen
Googlen ja Applen omien kehitysympäristöjen ja -työkalujen avulla voidaan kehittää sekä Androidille että iOS:lle omat applikaationsa. Milloin natiivisovellus kannattaa sitten tehdä?
Mitään tarkkoja sääntöjä tähän ei ole, mutta natiivisovellukset sopivat yleensä raskaisiin tehtäviin hybridiä paremmin.
“Päätös kallistuu usein natiivin puolelle, jos sovelluksella on nähtävissä pitkä elinkaari ja sovellus on erittäin olennainen osa palvelua, jota sen on tarkoitus tukea, tai jos halutaan varmistaa, että valittu teknologia ei vanhene ja osaavia devaajia on tarjolla myös tulevaisuudessa. Käyttäjille voidaan tuoda ominaisuuksia, jotka voivat hyödyntää kaikkia laitteen ohjelmointirajapintoja”, Salmi toteaa.
Kannattaa muistaa, että mobiilimaailma jos mikä muuttuu ja kehittyy vauhdikkaasti. On olennaista pysyä ajan tasalla uusista trendeistä, jotta sovellus voi tarjota kaiken, mitä käyttäjät yleensä odottavat ominaisuuksien suhteen. Sovelluskehityksessä pitää lisäksi olla halua ja uskallusta ottaa uusia teknologioita käyttöön, ettei synny isoa teknistä velkaa. Kokeneen ja osaavan kehittäjän on helppo omaksua uudet teknologiat, vaikka ne eivät juuri nyt löytyisikään työkalupakista.
Tiimityön merkitys
Mitä laajempi sovellus tai palvelukokonaisuus, sitä erikoistuneempia kehittäjiä tiimissä yleensä on.
Salmi työskentelee tällä hetkellä Helsingin Sanomien Android-applikaation parissa useamman hengen tiimissä. “Sanomilla uutisten julkaisujärjestelmät ovat olleet olemassa jo paljon ennen mobiilisovelluksia, ja niiden vaatimusten määrittäminen sekä kehittäminen on heidän ydinosaamistaan. Kun mobiilisovellus liittyy nykyiseen järjestelmään, järjestelmän ja sovelluksen väliin kehitettävä bäkkäri palvelee sovelluksen tarpeita. Kun puhutaan näin suuresta järjestelmästä, mobiilisovelluksen kehittäjillä ei ole aikaa eikä yleensä parhainta osaamistakaan kehittää back endia. Erikoistuminen siis luo tuottavuutta”, Salmi sanoo.
Tiimin toimimisen elinehto on, ettei kukaan jää tuppisuuna nurkkiin pyörimään. “Jos koko palvelukokonaisuus kehitetään erillisissä tiimeissä, tulee tiimien pystyä välittömään kommunikaation, jotta kokonaisuus saadaan mahdollisimman nopeasti valmiiksi ja toimivaksi”, Salmi painottaa. Kehitystyön kitkaton reagointi muutoksiin ja työn tuloksien jatkuva integrointi tiimin kesken mahdollistavat nopeat suunnanmuutokset, jos tarpeet muuttuvat tai eteen tulee yllättäviä ongelmia.
Joskus koodaaja saattaa imeytyä liikaa omaan työhönsä ja puhtaasti tekniseen näkemykseen. Hyvä kehittäjä huomioi sidosryhmät sekä ymmärtää bisnesvaatimukset ja on valmis etsimään kompromisseja ja neuvottelemaan niistä. “Kehitystyössä tärkeintä on tietynlainen mielentila: on oltava valmis puolustamaan mutta myös luopumaan rakkaistakin asioista”, Salmi kiteyttää.
Väki vaihtuu huipputiimeissäkin. Koodarien on mietittävä koodissa tekemiään arkkitehtuurivalintoja ja tapoja toteuttaa asioita niin, että tiimin uudetkin kehittäjät oppivat ja ymmärtävät ratkaisut helposti. “Harmittavan usein sovelluksissa on tehty arkkitehtuurivalintoja, joiden ominaisuudet ylittävät sovelluksen tarpeet ja tarpeettomasti hidastavat devaajan pääsyä sisään koodiin. Esimerkiksi ajoaikainen service locator -kirjasto on lähes aina riittävä eikä käännösaikaiselle dependency injection -kirjastolle ole oikeaa tarvetta”, Salmi toteaa.
Testaamisen tarkoituksena on tunnistaa mahdollisimman aikaisessa vaiheessa viat ja se, että kehittäjät ovat ymmärtäneet ja toteuttaneet vaatimukset oikein. Usein manuaalisesta testaustyöstä pyritään eroon automatisoimalla testausta mahdollisimman pitkälle. Testausautomaation rajahyöty pienenee kuitenkin nopeasti käyttöliittymäpainotteisissa mobiiliappiksissa – on varottava tilannetta, jossa automaation kehittämisestä ja ylläpitämisestä saavutettava hyöty on pienempi kuin sen kustannukset.
Automaattisen testauksen lisäksi tarvitaan hyviä testaajia. Huipputestaajan persoona sopii useimmiten rutiininomaiseen suorittamiseen, mutta hänellä on myös teknistä osaamista mennä testaamisessa käyttöliittymää syvemmälle – huipputestaajia saattaa olla jopa harvemmassa kuin huippudevaajia.
Sovellusta päivitetään palautteen perusteella
Kehitystyö ei pääty sovelluksen julkaisuun, vaan appiksiin sorvataan uusia ominaisuuksia ja vanhoja viilataan muun muassa käyttäjäpalutteen perusteella. “Palautetta pitää kuunnella herkeämättä ja siihen pitää reagoida mahdollisimman nopeasti”, Salmi sanoo. Tässä vaiheessa jyvät erotellaan akanoista, koska hyvä sovellus saa hyvää palautetta – tai ainakin vain vähän negatiivista palautetta. Kuten elämässä yleensä, vikoja ja puutteita osoitellaan herkästi, mutta kehujen antamiseen on huomattavasti suurempi kynnys.
Hyvillä sovelluksilla on pitkä elinkaari, joten ne vaativat hoivaa ja huolenpitoa eli päivityksiä, korjauksia ja uudistuksia. Mitä enemmän applikaatio saa käyttäjiä ja arvosteluja sovelluskaupoissa, sitä enemmän kehitystiimi saa ideoita ja vinkkejä, mitä voisi heittää roskikseen tai mihin voisi laittaa paukkuja myöhemmin.
Korkeat listasijoitukset parantavat näkyvyyttä, joten mitalisijoista saatetaan taistella sovelluskaupoissa. Usein sovellukset kuitenkin ovat bisnestä tukevia, ja käyttäjä tekee sovelluksen valinnan kärkikahinoista piittaamatta: esimerkiksi pankkisovellus tulee ikään kuin pankin kylkiäisenä ja uutissovelluksen käyttäjä valitsee apin sisällön tai tilaamansa paikallislehden mukaan.
Osaava tekijä nopeuttaa projektia
Mobiiliprojektin kustannuksia voi pienentää ja projektin läpivientiä nopeuttaa erittäin hyvien koodarien avulla.
Pienen budjetin sovelluksissa koodaajaltakin tarvitaan näkemystä käyttöliittymästä, mutta suuremmissa projekteissa on yleensä aina erikseen käyttöliittymäsuunnittelijat. Koodarin näkemys käyttöliittymään pitää silloin olla hiukan erilainen, ja se liittyy toiminnan sujuvuuteen ja käyttöliittymän skaalautuvuuteen erilaisille laitteille.
Devaajan tehtävänä on myös asettaa tekniset rajat käyttöliittymäsuunnittelijan luovuudelle. Pelkkä koodaustaito ja näkemys käyttöliittymästä eivät tosin riitä – tarvitaan myös rohkeutta sanoa asioita ääneen ja pohtia yhdessä parhaita ratkaisuja mobiilikäyttäjän näkökulmasta.