Mobiilisovelluksen työmäärä ja legopalikoiden päälle astuminen

Mobiiliprojektien arviointiperusteet

Omassa työnkuvassani yksi oleellinen osa on työmääräarvioiden tekeminen - etenkin mobiiliprojekteihin. Vincitillä on tehty kymmeniä mobiiliprojekteja, joiden työmäärä on vaihdellut kahdesta viikosta yli henkilötyövuoteen. Yritän tällä kirjoituksella hieman avata, mitkä asiat vaikuttavat mobiilisovelluksen työmäärään.

Arvioita tehdään hyvin vaihtelevien määrittelyjen pohjalta. Joskus sovellus on jo toteutettu esimerkiksi iOS-alustalle ja halutaan tehdä siitä Android-versio. Toisinaan käytössä on mainostoimiston suunnittelemat designit, joissa sovelluksen toiminnot on kuvattu melko yksityiskohtaisesti ja joskus arviota työstetään muutamasta ranskalaisesta viivasta koostuvan määrittelyn pohjalta. Mikäli määrittelyt ovat vielä kovin raakaversiot, kannattaa projekti käynnistää toimittajan kanssa workshopilla tai isompien hankkeiden kohdalla jopa konseptointiprojektilla, jossa määrittelyä ja visiota tarkennetaan. Riippumatta annettujen määrittelyjen laadusta, itse arvion teen yleensä suurin piirtein seuraavilla kriteereillä:

  1. Katson sovelluksen yleistä kokoluokkaa. Paljonko siinä on näkymiä? Kuinka paljon käyttöliittymä vaatii räätälöityjen animaatioiden ja komponenttien tekoa? Sisältääkö sovellus vaativaa taustalogiikkaa ja esimerkiksi offline-käytön mahdollisuuden?
  2. Mitkä ovat ei-toiminnalliset vaatimukset? Mitä käyttöjärjestelmiä pitää tukea? Mitä käyttöjärjestelmien versioita pitää tukea?
  3. Vertaan sovelluksen toiminnallisuutta johonkin jo meillä tehtyyn projektiin ja sen työmäärään. Otan tämän työmäärän lähtötasoksi ja säädän arviota ylös- tai alaspäin riippuen kohtien 1. ja 2. tuloksista.
  4. Tarvitseeko sovellus taustajärjestelmää? Lähes poikkeuksetta nykyään tarvitsee: en muista milloin viimeksi Vincitillä olisi tehty mobiilisovellus, joka ei olisi kytkeytynyt johonkin taustajärjestelmään. Tosin järjestelmä voi toki jo olla olemassa, tai sen voi toimittaa joku muu taho. Mikäli järjestelmää ei ole olemassa, kannattaa harkita sekä sovelluksen että järjestelmän tilaamista saman katon alta. Yleensä tämä vähentää projektin hallintaan ja kommunikointiin tarvittavaa työmäärää.
  5. Tehdäänkö sovellukseen myös UI/UX-suunnittelu vai onko se jo tehty, vai tuleeko se muualta? Tähän pätee sama sääntö kuin kohtaan 4: toteutuksen ja suunnittelun hankkiminen saman katon alta vähentää välillistä työtä.

Esimerkkisovellus

Otetaan tässä lähtökohdaksi seuraava keksitty, keskikokoinen mobiilisovellus. Asiakkaalta saimme sovelluksen määrittelyksi seuraavan, karkean listan:

  • Sovelluksen idea on pitää kirjaa siitä, millaisten legopalikoiden päälle on tallannut yön pimeydessä tapahtuvien vessakäyntien yhteydessä. Kokemuksiaan voi jakaa muiden käyttäjien kanssa ja kommentoida muiden kokemuksia.
  • Sovelluksen täysi käyttö vaatii käyttäjätilin. Sovelluksen kautta voi kirjautua ja rekisteröityä järjestelmään. Tavallinen käyttäjätunnus/salasana ja esimerkiksi Facebook-kirjautuminen ovat mahdollisia.
  • Havaintojen kirjaaminen
    • Kun käyttäjä astuu legopalikan päälle, hän voi tehdä siitä sovelluksella merkinnän. Merkintään voi lisätä seuraavat tiedot: aika, paikka, kivun kokoluokka sekä kuvan ja tiedot legopalikasta.
  • Selailu
    • Sovellus näyttää listausta siitä, millaisten palikoiden päälle muut ihmiset ovat astuneet.
    • Havaintoja voi selailla listamuodossa, jolloin sovellus näyttää viimeiset tapahtumat aikajärjestyksessä.
    • Havaintoja voi hakea legopalikan merkin mukaan.
    • Havaintoja voi myös lajitella legopalikan merkin mukaan.
    • Havaintoja voi katsella karttanäkymässä.
    • Millä tavoin havaintoja voisi lajitella ja etsiä?
  • Havainnon tarkastelu
    • Havainnosta pääsee näkemään samat perustiedot, mitä sen tekijä on laatinut.
    • Havaintoa voi kommentoida.
    • Havainnolle voi antaa "That's gotta hurt" -peukun.
  • Notifikaatiot
    • Mikäli käyttäjän havaintoa on kommentoitu, tai se on saanut "That's gotta hurt" -peukun, käyttäjä saa tästä push-notifikaation laitteeseensa.
  • Jakaminen
    • Käyttäjä voi jakaa minkä tahansa havainnon Facebookiin, Twitteriin, sähköpostilla tai SMS:llä. Jakoviestiin lähtee linkki sovelluksen lataussivulle.
  • Leaderboard
    • Sovellus näyttää tilastoa kovimmista palikoiden päälle astujista.
    • Sovellus näyttää tilastoa legopalikoista, jotka ovat aiheuttaneet eniten kivuliaita onnettomuuksia.
  • Oma profiili
    • Käyttäjä voi ladata profiilikuvan ja vaihtaa sitä.
    • Käyttäjä voi kirjoittaa lyhyen kuvauksen itsestään ja siitä kuinka kauan ja säännöllisesti hän on harrastanut legopalikoiden päälle astumista.
    • Käyttäjä voi vaihtaa salasanansa.
  • Ei-toiminnalliset vaatimukset
    • Sovellus halutaan ensin iOS-järjestelmälle, mutta jatkossa mahdollisesti myös Android- ja WP-versiot. iOS-järjestelmässä pitää tukea iOS 7 -versiota.

Esimerkkisovelluksen työmäärä

Arviointivaiheessa ei määrittelyn pieni epämääräisyys haittaa, vaan keskittyisin nimenomaan sovelluksen kokoluokkaan. Toki on mahdollista - ja näin on usein käynytkin - että avoimesti määritelty projekti vaihtaa suuntaa toteutusvaiheessa. Toteuttaessa on opittu jotain uutta ja huomattu, että jokin asia ei toimikaan, jolloin muutetaan suuntaa. Työmääräarvio ja tuleva budjetti määrittää tässä tapauksessa enemmänkin raamit kehitykselle, joiden sisällä on pidettävä huoli siitä, että saadaan tehtyä toiminnallisuuksiltaan paras mahdollinen sovellus.

Esimerkkisovelluksen kokoluokaksi ottaisin kahden hengen tiimin, joka voisi toteuttaa sovelluksen 2.5-3.5 kuukaudessa. Yhteensä siis 5-7 kuukauden työmäärä. Tämä voi vaikuttaa paljolta, mutta juuri määrittelyn avoimuus kannustaa siihen, että arvioinnissa jätetään tilaa uusille ideoille ja sisällön elämiselle.

Lisäksi sovellus tarvitsee taustajärjestelmän. Taustajärjestelmään ei haluta web-käyttöliittymää, mutta jokainen taustajärjestelmä tarvitsee jonkinlaisen hallintakäyttöliittymän, josta voi selvittää mahdollisia ongelmatilanteita. Taustajärjestelmän on lisäksi säilytettävä tieto käyttäjistä ja havainnoista tietokannassa ja tarjottava mobiilisovellukselle rajapinta näiden tietojen hakemiseen, sekä välitettävä push-notifikaatiot laitteille kun käyttäjien havaintoja kommentoidaan tai peukutetaan. Logiikkaa kannattaa tehdä mahdollisimman paljon taustajärjestelmään, jotta sitä ei tarvitse monistaa mahdollisesti jatkossa tehtäviin Android- ja WP-sovelluksiin. (Tai kenties web-sovellukseen). Varaisin taustajärjestelmään yhden tekijän samalla 2.5-3.5 kuukauden työmäärällä.

Design-työ vaatii tämänkokoisissa sovelluksissa yleensä noin 3-4 viikon työn. Tämä sisältää käyttöliittymäsuunnittelun näkymineen, siirtymineen ja käytettävyyssuunnitteluineen sekä varsinaisten designien ja ikonien piirtämisen.

Yhteensä siis:

  • Mobiilisovellus: 5-7 kk
  • Taustajärjestelmä 2.5-3.5 kk
  • Design: 3-4 viikkoa

Kaikkinensa työmääräarvio on 8-12 henkilötyökuukautta. Toki työmäärä voidaan sopia pienemmäksi, mutta tässä tapauksessa kannattaa varautua siihen, että sisällöstä joudutaan tinkimään ja uusille ideoille ei jää niin paljon tilaa. Ylipäätään mobiilisovellukset ovat niin kilpailtu alue, että siellä on hyvin vaikea pärjätä pelkällä hyvällä idealla: toteutus ja sen laatu ovat seikat, jotka ratkaisevat. Vaikka sovellus olisi ilmainen ja tulonhankinta tapahtuisi muita kanavia pitkin, heikkolaatuiset sovellukset jäävät armotta lataamatta. Ja laadukas, hiottu toteutus ei tule ilmaiseksi.

Toki kustannuksia voidaan jakaa vaiheisiin, ja ketterät työtavat mahdollistavat sen, että sovelluksen kehityksen näkee jatkuvasti. Esimerkiksi tässä tapauksessa kahden viikon työn jälkeen kasassa olisivat jo UX-rautalangat, useampi niiden pohjalta toteutettu näkymä ja sovellusta voisi testata. Taustajärjestelmistäkin olisi toteutettu jo vähintäänkin testidataa tarjoileva järjestelmä, johon voi kirjautua.

Mobiilikehityksessä täytyy aina myös huomioida se, että nyt tehty sovellus toimii vain iOS-laitteissa. Android- ja WP-tuki vaativat omat toteutuksensa, jotka voivat olla hyvin lähellä alkuperäisen iOS-sovelluksen työmäärää. Toki sovelluksen uudelleenkirjoitus on hieman nopeampaa, koska sillä kertaa maali ja sisältö on kiinteä, eikä liikkuva kuten sovellusta ensimmäistä kertaa tehdessä. Kustannusten pienentämistä varten voidaan myös käyttää muita kuin natiiviteknologioita, jolloin samaa koodia voi hyödyntää useammalla alustalla. Tätä asiaa käsittelin Vincit-blogissa kirjoituksessa Natiivi, hybridi ja HTML5.

Juha Riippi

Juha Riippi

Liity keskusteluun