1. Epätarkka suunnittelu ja rajaus

Ensimmäinen tapa saada projekti väärille raiteille on jo alussa päätyä eri oletuksiin siitä, mitä projektiin sisältyy ja mitä ei. Ei voida luottaa siihen, että toinen osapuoli osaa lukea toisen ajatukset, eikä siihen että asiakkaalle ja sovellustoimittajalle syntyy sama mielikuva projektista pelkän suullisen keskustelun perusteella.
‍
Ratkaisu:
Tämä ongelma vältetään parhaiten sillä, että listataan ja käydään läpi asiakkaan kanssa erittäin tarkasti, ei pelkästään mitä sovittuun projektiin kuuluu, vaan myös mitä siihen ei kuulu, eli mikä on erikseen laskutettavaa lisätyötä. Kun nämä ovat sovittu tarkasti ja jokaiselle vaiheelle on määritetty realistiset ja selkeät kehitysajat, vältytään suurimmaksi osaksi sekä budjetti- että aikatauluylityksiltä ja yllätyksiltä, jotka ovat sovellusprojekteissa valitettavan tavallisia.

2. Liian vähän kommunikaatiota

Vaikka alussa olisikin määritelty tarkasti miltä sovellus tulisi näyttämään ja miten eri toiminnallisuudet toimivat, käy helposti niin, että kehittäjä toteuttaa sovelluksen ulkonäköön ja toiminnallisuuksiin itse parhaiksi katsomiaan ratkaisuja, jotka eivät aina olekaan linjassa sen kanssa, mitä asiakas yritti sanoa tai oletti saavansa.

Ratkaisu:
Tämä voidaan välttää pitämällä säännöllisiä välitsekkejä, tiivistä keskustelua ja avoimia kommunikaatiolinjoja kehittäjien ja asiakkaan välillä. "Nämä toiminnallisuudet on tehty näin ja näyttävät tältä, onko tämä se mitä halutaan?". Ja hyväksymisen jälkeen siirrytään eteenpäin.

3. Liikaa muutoksia projektin aikana

Joskus alkuarviointi menee hieman pieleen tai projektin edetessä tuleekin uusia ideoita tai tapoja toteuttaa toiminnallisuuksia. Tämä on lähtökohtaisesti hyvä asia, mutta se saattaa suistaa projektin helposti sivuraiteille.

Käytännössä voisi käydä esimerkiksi niin, että yhteen toiminnallisuusketjuun halutaankin lisätä yksi välisteppi tai uusi näkymä, joka ei kuitenkaan teknisesti olekaan vain yhden lisäyksen juttu, vaan muutoksia joudutaan tekemään olemassaolevan ketjun jokaiseen vaiheeseen. Tällöin pieneltäkin vaikuttava "lisäidea" saattaa olla yllättävän työläs toteutus ja se ei välttämättä sen vuoksi kuulu alkuperäiseen speksaukseen.

Ratkaisu:
Tämä ongelma taklataan sillä, että uusia ideoita tuodaan avoimesti pöytään, mutta niistä keskustellaan ja mietitään parasta toteutustapaa sen sijaan, että lähdettäisin suinpäin toteuttamaan muutoksia miettimättä koko kokonaisuutta. Tässä auttaa myös alussa luotu rajaus. "Muistatko, että sovimme, että tämä ketju toteutetaan tällä tavalla ja se sisältää nämä stepit ja jos tämä muuttuu merkittävästi, on se alkuperäisen rajauksen ulkopuolella ja tästä syystä lisätyönä laskutettava muutos".

4. Luotetaan liikaa sovellustoimittajaan 

Lähtökohta on se, että asiakkaan ei tarvitse olla tekninen osaaja voidakseen ostaa sovelluskehitystä.

Tietämättömyys ja luottavaisuus saattavat kuitenkin aiheuttaa ongelman, jos sovellustoimittajan työn laatua ei pystytä tarpeeksi arvioimaan. Olemme olleet mukana projekteissa, joissa yksi sovellus on tehty hitaasti, kalliisti ja yksinkertaistettuna huonosti, jolloin asiakas on käytännössä maksanut tyhjästä, sovelluksesta, jonka tärkeimmät tehtävät ei toimi ja sovellus on käytännössä käyttökelvoton. Tämän lisäksi sovellustoimittaja oli jopa alkanut välttelemään yhteydenottoja, sekä lähettämään ylimääräisiä, perusteettomia laskuja asiakkaalle.

Joskus ainoa tapa päästä eteenpäin on ollut jopa rakentaa täysin uusi sovellus sen sijaan, että lähdettäisiin korjaamaan huonosti tehtyä koodia.

Ratkaisu:
Tämä ongelma vältetään parhaiten siten, että varmistetaan, että projektissa on mukana tarpeeksi kokeneita kehittäjiä, selkeä vastuuhenkilö ja sopimukset siitä mitä tapahtuu, jos projektin laatu ei vastaa siihen, mitä on sovittu tai jos sovellus epäonnistuu eikä esimerkiksi toimittajaan saada yhteyttä sovitusti. Toimittajan luotettavuutta ja työn laatua voi varmistaa myös referensseistä ja suosituksista.

5. Ei mietitä tarpeeksi eteenpäin

Varsinkin Low-code teknologialla tehdessä on järkevää lähteä hyvin pienestä liikkeelle. Tehdä sovelluksesta paras mahdollinen ensimmäinen versio, kerätä palautetta oikeilta käyttäjiltä ja kehittää niiden mukaan sovellusta paremmaksi osio kerrallaan. Ei kannata tehdä vuoden monsteriprojektia, vaan tehdä suoraviivainen ja yksinkertainen sovellus, jotta oman idean saa markkinalle tai omaan yritykseen testikäyttöön mahdollisimman nopeasti.

Kannattaa kuitenkin heti alussa miettiä pientäkin sovellusprojektia pidemmälle. Mihin tämä sovellus voisi pystyä kahden tai viiden vuoden päästä? Mitä esteitä näissä uusissa vaiheissa saattaa tulla vastaan?

Ratkaisu:
Kun sovellus kehitetään alusta asti skaalautuvuutta, laajentamista ja jatkokehitysideoita ajatellen, saadaan tehtyä ketterä sovellus, johon voidaan nopeasti lisätä uusia toiminnallisuuksia ja näkymiä ilman, että jo kehitettyyn versioon tarvitsee tehdä muutoksia montaa kertaa.

Mietityttääkö oma sovellusprojekti?

Paras tapa lähteä liikkeelle oman idean kanssa on varata maksuton 30 min sparraus, jossa autamme sinua kartoittamaan mitä tarvitset, paljonko projektisi maksaa ja mitä sinun on hyvä tietää, kun lähdet edistämään omaa ideaasi. Tule rohkeasti sparraukseen, me puhumme ihmistä, emme koodia!