#lowcode

Kuinka kauan sovelluksen kehitys kestää?

Jos sinulla on mahtava sovellusidea tai tarve kehittää yrityksen operaatioita, et halua odottaa vuoden päiviä, ennen kuin pääset käyttämään uutta sovellustasi. Tässä tekstissä käymme läpi, mitkä asiat vaikuttavat projektin kestoon.

Laatu > Nopeus

Ennen kuin puhutaan projektin kestosta ja miten sitä voi arvoida, on hyvä teroittaa mitä tarkoitamme, kun puhumme Low-coden nopeudesta:

Toisinaan kuulee luvattavan, että yksinkertaisen sovelluksen rakentaminen onnistuu jopa tunneissa. Vaikka perussovelluksen luominen nopeasti onkin mahdollista, on tärkeää muistaa, ettei laadusta tulisi koskaan tinkiä. Sovellus kannattaa kehittää alusta asti niin, että sitä on mahdolllisuus laajentaa helposti, vaikka ensimmäinen idea olisikin hyvin yksinkertainen. Päivän projekti suunnitteluineen tarkoittaa todennäköisesti sitä, että piirrustuspöydälle palataan jo hyvin pian, kun halutaan sovellukseen lisää toiminnallisuuksia, jotka eivät automaattisesti sovi aiemmin (kiireellä) rakennetun sovelluksen päälle.

= Kiireellä kehitysprosessin läpi kulkeminen johtaa helposti huonolaatuiseen tuotteeseen, joka ei täytä käyttäjien odotuksia eikä sisällä tarvittavia toiminnallisuuksia ollakseen oikeastaan edes hyödyllinen.

Mutta jollekin, jolla ei ole kokemusta sovellusprojekteista kehittäjän tai ostajan roolista, sovelluskehitys kuulostaa lähinnä siltä, että se vie varmasti ikuisuuden. Vaikka on totta, että monimutkaiset sovellukset vaativat enemmän aikaa ja työtä, asianmukaisella suunnittelulla ja kokeneella kehitystiimillä vaativakin projekti saadaan maaliin kohtuuajassa.

= Myös laajan ja monipuolisen sovelluksen teko on verrattaen nopeaa Low-codella, joten ei ole mitään syytä tinkiä laadusta, vaikka halutaan nopeasti valmista. Sitä kompromissia ei yksinkertaisesti tarvitse tehdä!

Sneak peek: Low-code projektit kestävät keskimäärin 1-6 kk

Ei kovin paha eihän? Siinä ajassa, missä perinteisessä koodaamisessa kehittäjätiimi on päässyt asettamaan jalat lähtötelineisiin, saat jo kutsua käyttäjät sovellukseen!

Seuraavaksi mennään konkretiaan ja käydään läpi miten voit arvioida oman sovellusideasi laajuutta:

Mitkä tekijät vaikuttavat projektin kestoon

Yksinkertaisesti, sovellusprojektin kesto määräytyy siitä, mitä kaikkea sovelluksen halutaan tekevän. Mitä enemmän näkymiä, toiminnallisuuksia, sääntöjä tai yhdistämistä muihin järjestelmiin tarvitaan, sitä pidempi projekti on.

Sovelluksen koko

Onko sovelluksessa esimerkiksi ainoastaan kirjautumissivu, etusivu ja tuotesivu, vai onko siinä 17 erilaista näkymää eri tyyppisille käyttäjille? Tätä voi ajatella nettisivuina, navigaationa ja alasivuina. Voit tehdä mielessäsi pientä listaa siitä, kuinka monta erilaista näkymää sovellus vaatii toimiakseen, kuten ajattelit.

Voit testiksi availla esimerkiksi suosikkisovelluksiasi puhelimestasi ja katsoa, kuinka monta erilaista näkymää löydät.

Toiminnallisuudet

Toiminnallisuudet tarkoittavat käytännössä sitä, että kun käyttäjä painelee nappuloita, lisää tai muokkaa sovelluksen dataa, jokainen toimenpide on yksi toiminnallisuus.

"Kun käyttäjä painaa "lisää tuote" > "Lisää uusi tieto järjestelmään" > "Muokkaa tilausta" > "Korvaa vanha tieto". Mitä monimutkaisempi toimintaketju eri vaiheineen, sitä enemmän työtä sen tekeminen vaatii.

Jokainen "tehtävä" jota sovelluksessa suoritetaan, on luonnollisesti tehtävä alusta asti, sovellus ei automaattisesti osaa toimia halutulla tavalla, koska se ei tiedä, mitä ollaan tekemässä.

Toiminnallisuuksien kartoittamisessa ajatuseleikkinä auttaa esimerkiksi seuraava lause:
Kun kirjaudun sisään sovellukseen, haluan....
Kun poistan tuotteen listalta, haluan...

Tätä lähestymistapaa kutsutaan nimellä "user journey", sen tarkoitus on selventää kehittäjälle, mitä käyttäjä haluaa sovelluksella tehdä missäkin tilanteessa.

Datan visualisointi

Tarvitaanko sovellukseen pie charteja, jatkuvasti päivittyvää projektin tilan seurantaa, tilausten määrää / per myyjä tai alue, tai mahdollisuuksia käyttäjälle tutkia dataa haluamansa mukaan?

Riippuen siitä, millaista dataa sovelluksessa käsitellään ja miten se esitetään käyttäjälle yksinkertaisimmin, sovellukseen voi olla hyödyllistä lisätä erilaisia taulukoita ja filtteröintejä.

Käyttäjätasot ja säännöt

Kun sovellusta tehdään, on ensisijaista kehittää sekä käyttäjän, että sovelluksen omistajan turvallisuus huomioiden. Kenellä on oikeus luoda tili sovellukseen ja mille sivuille hänellä on pääsy? Saavatko kaikki käyttäjät tehdä samoja asioita? Saavatko he nähdä kaikki tiedot? Kuka saa muokata tietoja? Mitä tapahtuu kun käyttäjä poistetaan?

Sovellus toimii oikein silloin, kuin käyttäjä saa nähdä ja tehdä vain niitä asioita, jotka ovat hänen käyttäjätasolleen sopivia. Yleensä nämä ovat esimerkiksi admin ja peruskäyttäjä- tyyppiset tasot, mutta ne voivat olla myös tiimin mukaan: HR, myynti tai asiakaspalvelu, tai seniorieetin mukaan: C-osasto, tiiminvetäjät, tiimin jäsenet.

Mitä enemmän käyttäjätasoja ja erilaisia sääntöjä on, sitä kauemmin sovelluskehitys vie aikaa.

Yhdistäminen muihin järjestelmiin

Toimiiko sovellus omana kokonaisuutenaan, vai tulisiko sen olla yhteydessä myös joihinkin jo olemassa oleviin järjestelmiin?

Tätä yhdistämistä kutsutaan integraatioksi ja se tapahtuu yleensä APIen avulla. Esimerkki voi olla kävijädatan tuonti Google Analyticsiin, maksujärjestelmän luonti Stripen avulla, viestien vieminen Slackiin tai nykyään myös ChatGPT:n ja muiden generaviisiten tekoälytyökalujen liittäminen omaan sovellukseesi.

Riippuen siitä, mihin järjestelmään sovellus halutaan yhdistää, integraatio on joko kahden klikkauksen juttu tai koko projektin ajan mukana kulkeva työvaihe.

Integraatioita ei kannata pelätä, sillä Low-code alustoissa on valmiiksi satoja erilaisia "plugineita", joilla yhdistäminen on tehty erittäin helpoksi. Integraatiot ovat sovelluksen todellinen voima, koska ne auttavat tuomaan sovellukseen roppakaupalla lisää toiminnallisuutta hyödyntäen jo olemassa olevia järjestelmiä.

Esimerkkejä erilaisista projekteista:

Käydään seuraavaksi läpi muutama esimerkkitapaus, joiden avulla voit kartoittaa, minkä laajuinen oma projektisi mahtaisi olla. Kaikki projektit ovat hyvin yksilöllisiä, joten hyvin tarkkoja esimerkkejä on vaikea tai turhakin antaa. Näiden pohdintojen avulla osaat kuitenkin todennäköisesti asettaa oman ideasi oikeaan kategoriaan.

Pieni sovellus: 1 kk

Jos sovelluksessa on vain pari sivua, kaikki käyttäjät saavat oikeastaan tehdä kaikkea, eikä sovellusta tarvitse liittää muualle, täysin toimiva sovellus voitaisiin saada valmiiksi jopa kuukaudessa!

Keskikokoinen sovellus: 2-4 kk

Suurin osa sovellusprojekteista kuuluu lähtökohtaisesti tähän kategoriaan. Tarvitaan hieman enemmän ja monimutkaisempia toiminnallisuuksia, erilaisia näkymiä ja esimerkiksi joitain integraatioita. Tämän kokoiset sovellukset ovat oikeasti jo todella voimakkaita, esimerkiksi kokonaisia toiminnanohjausjärjestelmiä ja asiakasportaaleita saadaan tehtyä tässä ajassa, helpostikin!

Kompleksi sovellus: 6kk-1v

Tällaisessa sovelluksessa on luonnollisesti jo paljon monivaiheista toiminnallisuutta, osa käyttäjän ja osa kehittäjän tarpeesta. Sovelluksessa voisi olla esimerkiksi suurempi käyttäjämäärä (paljon dataa siirretään jatkuvasti), sääntöjä, näkymiä sekä tarvetta jatkaa sovelluksen kykyjä laajemmilla integraatioilla, eri kieliversioilla, paremmalla versionhallinnalla tai muilla "tavallisista poikkeavilla" toiminnallisuuksilla.

Suunnittelu - Toteutus - Testaus - Jatkokehitys

Projektin kestossa on syytä huomioida varsinaisen kehittämisen lisäksi myös esimerkiksi ulkoasun suunnitteluun, testaukseen, julkaisuun ja koulutukseen kuluva aika. Varsinainen kehitystyö on lopulta vain osa sovellusprojektia, harvoin kehittäjätiimi lomautetaan sovelluksen julkaisun jälkeen, vaan silloin otetaan vastaan palautetta käyttäjiltä ja kartoitetaan mahdollisia parannuksia sovellukseen, jotka toteutetaan kenties myöhemmin matkan edetessä.

Paras sovellus ei ole kerralla tehty, vaan sitä hiotaan pikku hiljaa paremmaksi, lisätään ominaisuuksia ja tehdään sovelluksen käyttämisestä aina vain helpompaa. Etenkin kuluttajalle suunnatuissa sovelluksissa on tärkeää pysyä kilpailukykyisenä ja varmistaa, että sovellus palvelee nykyisten käyttäjien lisäksi myös uusia käyttäjiä tavalla, joita kilpailija ei palvele.