Sovelluskehittämisessä harva asia menee niin kuin etukäteen kuvittelit

Sovelluksen siirtäminen alusta toiselle on kuin viskelisi vettä ämpäristä toiseen.

Tässä sinulle hauska ja opettavainen kesäleikki. Ota kaksi ämpäriä, laske toinen täyteen vettä, jätä toinen tyhjäksi ja anna se kaverille. Kiipeä täysi ämpäri kainalossa talosi katolle ja käske kaverin ottaa koppi vedestä omalla ämpärillään.

Hauskaa tässä on kaverin, tai oma, kastuminen. Opettavaista taas se, että vaikka kymmenen litraa vettä on kymmenen litraa vettä, ei ole aivan läpihuutojuttu vaihtaa sitä astiasta toiseen.

Tämä jätetään hämmästyttävän usein huomiotta softaprojektin alla, kun on esimerkiksi tarkoitus luoda verkkopalvelusta mobiilisovellusta. Kehitystiimi marssii soitellen sotaan ja vasta viikkojen tai jopa kuukausien ryönääminen ohjelmoinnin, designin ja käyttäjätestien juoksuhaudoissa saa suomut putoamaan silmiltä: palvelun siirtämisessä alustalta toiselle ei juuri mikään mene niin kuin etukäteen kuvitteli.

Ennakko-oletukset ja todellisuus

Verkostoitumistyökalu Brella on selaimella ja älypuhelimella käytettävä sovellus, jolla saat tolkkua konferensseissa ja messuilla sovittuihin tapaamisiin. Brellan avulla organisoit ja aikataulutat näppärästi missä ja milloin haluat tavata kenetkin massatapahtuman tuhansien ihmisten joukossa.

Kun lähdimme vuoden 2016 lopulla rakentamaan Brellan mobiiliversioita Androidille ja iOS:lle, kuvittelimme vesiämpärillisen lentävän kauniista kaaressa alustasta toiseen, ilman että pisaraakaan menisin haaskuuseen.

Elegantti yksi yhteen -konvertointi saatiin kuitenkin unohtaa heti kättelyssä.  Läksimme läpimärkinä moppaamaan kasaan oleellisten ominaisuuksien listaa, jolla selainversio saataisiin toimimaan älypuhelimella kohtuullisesti, kohtuullisessa ajassa.

Tämän tunnustaminen ei suinkaan tarkoita sitä, että olisimme lähteneet tekemään kehitysprojektia jotenkin vasemmalla kädellä, vaan ennemminkin sitä, että parhaimpiakin suunnitelmia joudutaan korjaamaan matkan varrella. Todellisuudella on tapana yllättää, etenkin kun astutaan ulos kehitystiimin kammiosta ja aletaan kuunnella käyttäjäpalautetta.

Miten karvalakkiversio kasataan

Brellan webversio kääntyi ensi vaiheessa mobiiliappiksi noin 80-prosenttisen onnistuneesti. Teknisen toteutuksen haasteiden heittäessä jatkuvasti kierrepalloja, deadlinet paukkuivat, ja lopulta projektissa eteenpäin pääsyn kannalta oli viisainta tehdä päätös enimmäkseen toimivan version julkaisemisesta. Vaihtoehtona oli, että kovasti kysyttyä Brellan mobiilisovellusta ei saada ulos nyt eikä 15. päivä – ja kun olet markkinoiden ainoa palvelu, jolla ei ole mobiiliappia, on paine saada sellainen julkaistua melkoinen.

80 pinnan versioon ei kehitystiimi tietenkään voi olla tyytyväinen, mutta sekin on parempi kuin ei mitään. Kyse oli kompromissista. Emme esimerkiksi tehneet suomenkielistä sovellusversiota ollenkaan. Webissä suomiversio on.

Ensi vaiheessa kyse on ennen kaikkea käyttökokemuksen monipuolisuuden karsimisesta. Emme siis olleet tyrkkäämässä markkinoille bugien riivaamaa sovelluksen irvikuvaa, vaan prosessia kuvaa paremmin vertaus, jossa rakennetaan ensin potkulauta, sitten mopo ja lopuksi täysiverinen moottoripyörä.

Tuotekehityksessä tätä kutsutaan MVP-periaatteeksi (Minimum Viable Product). Ideana on luoda kaupallisesti elinkelpoinen tuote, joka tyydyttää ensivaiheen käyttäjien tarpeet ja tarjoaa riittävän käyttäjäpalautteen jatkokehittämistä varten.

Appi ei ole webbi

Seuraavalla kierroksella saimme hitsattua Brellan appiin viisi pinnaa lisää hyvää. Toisaalta, kaikkea mikä toimii isolla ruudulla ei ole järkeäkään yrittää sulloa älypuhelimen näytön muutamalle tusinalle neliösentille. Ja jälleen toisaalta, palvelun ydintoiminnot on saatava toimimaan jouhevasti alustasta riippumatta.

Mobiilisovellusta rakennettaessa on oleellista pohtia mikä toimii milläkin alustalla.  Ratkaisuissa piti käyttää luovuutta ja ymmärtää älypuhelin omaksi ympäristökseen. Joskus toiminnallisuutta saatetaan muokata radikaalistikin, ilman että ruudulla muutetaan pikseliäkään.

Operoimme niin sanotusti oppikirjan ulkopuolelta, soveltaen osaamista. Tämä vaatii jatkuvaa kommunikointia ja teknistä osaamista, jolla projektin hallittu kaaos saadaan maaliin.

Tuotekehitys on raakaa touhua

Summaten, onnistunut toteutus vaatii muutakin kuin vain ongelmanratkaisukykyä ja koodaustaitoa. Käyttäjäpalaute on tärkeää, mutta silläkään ei tee mitään, jos et kykene nöyrtymään palautteen äärellä ja kyseenalaistamaan omia upeita ideoitasi.

On vaikea painottaa riittävästi kuinka tärkeää käytettävyys on – etenkin kun on kyse Brellan kaltaisesta sovelluksesta, jota käytetään kiireen ja hälinän keskellä. Viimeinen asia mitä haluat tehdä kiirehtiessäsi tapaamisesta toiseen on alkaa tuskailla softan tiltattua tai sovelluksen tehtyä jotain hämärää mistä et pysy kärryillä.

Tämän päivän tuotekehitys on raakaa touhua. Ohjelmistopalveluiden reunaehdot muuttuvat jatkuvasti eikä painetta vähennä asiakaskunnan armottomat odotukset. Kaiken tulee toimia kuten Facebook ja jos näin ei ole, on palaute sen mukaista. Tästä kaikesta saat lukea lisää tulevissa blogikirjoituksissa.

 

Brella on verkostoitumissovellus tapahtumiin ja konferensseihin ja sitä käytetään jo yli 25 maassa. Asiakkaisiin kuuluu maailman isoimpia yrityksiä ja tapahtumajärjestäjiä, kuten Samsung, TechCrunch ja Slush. Brella sai alkunsa MEOMin sisäisenä projektina ja se yhtiöitettiin omaksi liiketoiminnaksi vuonna 2016.

Kirjoittanut

Product Owner & Lead Designer @ Brella

Lue seuraavaksi