Jos markkinoilta ei jo löydy tarpeeseen sopivaa valmista ohjelmistoa tai SaaS-palvelua, tai jos olet itse tarjoamassa nimenomaan softapohjaista palvelua omille asiakkaillesi, olet todennäköisesti ohjelmistoprojektin kynnyksellä.

Miksi sitten ohjelmiston tai verkkopalvelun rakentaminen ei käy samalla budjetilla, jolla viime vuonna uudistettiin firman verkkosivut? Mikä ihme sovelluksessa maksaa?

Sovelluksen tai ohjelmiston rakentamisen vertaaminen verkkosivujen tuottamiseen ontuu monella tapaa, eikä vähiten siksi, että verkkosivuihin on olemassa valmiita suunnitteluohjelmia, pohjaratkaisuja ja alustoja, joiden päälle sivut voidaan rakentaa. Verkkosivut ovat kaikki pitkälti teknisesti melko samanlaisia, eikä pyörää kannatakaan lähteä keksimään uudelleen näin geneerisen palvelun tuottamiseen.

Kun taas teet uutta softaa, se tehdään aina jollakin tapaa räätälöidysti, eikä valmiita ratkaisuja pystytä samassa mitassa hyödyntämään. Asiaa toki helpottaa, että softan tuottamiseen käytetään jotain yleisesti käytössä olevaa teknologiaa, johon löytyy paljon sellaisia komponentteja, joita pystytään hyödyntämään myös uudessa projektissa.

Tästä huolimatta ohjelmiston rakentamisessa tehdään paljon räätälöityjä ratkaisuja. Mitä enemmän niitä on, sitä enemmän kehitystyö maksaa. Yleistettynä siis, mitä monimutkaisempi järjestelmä, sitä enemmän se maksaa.

 

Softaprojektin hintaa eriteltynä

Jos järjestelmään pitää rakentaa esimerkiksi erilaisia käyttöliittymänäkymiä eri käyttäjäryhmille, esimerkiksi omanlaisensa admin-näkymä ja käyttäjänäkymä erikseen,  ja jos nämä sisältävät erilaisia toiminnallisuuksia, kyseessä ei ole pelkkä kopioimistyö. Kehittäjän aikaa menee näkymien speksaamiseen eri käyttäjäryhmille sekä niiden toteutukseen.

Edelleen kakkua kohottaa, mikäli dataa halutaan tuoda jostain muualta tai viedä sitä järjestelmästä ulos, jolloin tehtäväksi tulee integraatioiden rakentaminen. Se, paljonko integraation rakentaminen kestää, riippuu paljon siitä, minkälaisia linkitettävien järjestelmien rajapinnnat ovat. Jos vastassa on vanhaa protokollaa ja legacy-ratkaisuja, voi integroiminen olla huomattavasti monimutkaisempaa kuin modernimmalla teknologialla.

Myös käyttöliittymän ulkoasu vaikuttaa hintaan; mitä huolitellumpaa, hiotumpaa ja näyttävämpää halutaan, sitä enemmän työtunteja kuluu, ja projektiin on hyvä silloin ottaa myös käyttöliittymäsuunnittelija mukaan. Jos vaatimus on taas yksinkertainen “insinöörikäyttöliittymä”, voidaan kehittäää käyttöliittymä, jolla asiat voi järjestelmässä helposti suorittaa tinkimällä hieman ulkoasusta.

Keskeistä tässä lienee se, kenelle järjestelmä on suunniteltu – mikäli sitä käyttää harva asiantuntija, voi käyttöliittymä olla hyvinkin funktionaalinen. Kuluttajille sen sijaan tehdään aina huoliteltuja käyttöliittymiä, jolla varmistetaan sovelluksen hyvä käyttökokemus, mikä on monesti elinehtona laajan käyttäjäkunnan kuluttajasovelluksille.

Raportointi voi olla iso siivu ohjelmistoprojektin kustannuskakussa. Jos järjestelmään halutaan erilaisia raportointityökaluja, esimerkiksi sensoridatasta pdf-sivuja, kasvatetaan jälleen työmäärää.

Olennaista onkin kysyä mitkä ovat raportteja, jotka ovat sovelluksen käytön kannalta tärkeä olla mukana. Raportointimahdollisuuksia on helppo laajentaa jos sovelluksen käytön aikana huomataan jonkin olennaisen raportointimahdollisuuden puuttuvan valikoimasta.

 

Miten ohjelmistoprojekti budjetoidaan?

Useimmissa organisaatiossa tehdään vuosibudjetti tai projektibudjetti, jonka raameissa tulisi pysyä. Yksittäisen ohjelmistoprojektin budjetointia on hankala miettiä tämän kehyksen sisällä, sillä projekti taas saattaa kestää budjettikaudesta toiseen.

Suotavaa olisi tästä huolimatta varata projektiin ketterää budjettivaraa yllätyksien varalle. Kehitysprojektin ja varsinkin testauksen aikana saattaa tulla tarpeita uusille ominaisuuksille, jolloin niitä olisi harmillista jättää budjetin puutteen vuoksi pois.

Ketterän kehityksen lainalaisuuksiin kuuluu myös kehitysprosessin aikana oppiminen, jolloin on tärkeää voida tehdä nopeitakin kehityssuunnan muutoksia mikäli huomataan ominaisuuksien prioriteettijärjestyksen muuttuvan.

Kun työmääräarvioita tehdään, perustetaan ne omiin kokemuksiin. Mikään softaprojekti ei kuitenkaan ole samanlainen, jokaisessa on aina jotain uutta, jota ei voida ennakoida. Kehitystiimin vastuulla on toki osata arvioida ja ottaa aikavaraa yllätysten varalle.

Niinkin päin voi olla, että lähdettäessä tekemään projektia asiakas on osannut itse tilaajana ottaa huomioon kaikki olennaiset seikat. Useimmiten kuitenkin käy ilmi, että näin ei ole ollutkaan. Siinä kohdin kehitystyötä olisi ikävä jättää kesken, koska esimerkiksi kriittisen ominaisuuden tarvetta ei huomattu alun speksauksessa.

 

Osta kokeneelta tiimiltä

Tiimi, joka on tehnyt enemmän yhdessä hommia, osaa paremmin arvioida, kuinka nopeasti he pystyvät tuottamaan valmiita ohjelmisto-osuuksia. Tiiviisti hitsautunut tiimi osaa tehdä töitä tehokkaammin ja osaa myös arvioida paremmin työhön kuluvan ajan. He myös tuntevat toistensa vahvuudet ja heikkoudet, jolloin kehityssprintin suunnittelussa tiimi osaa valita jäsenilleen sopivimmat taskit.

Jos tehdään jotain, mitä toimittaja on tehnyt jo aiemmin, on tekeminen yleensä helpompaa. Yleensä se tuo myös lisäpotkua projektiin, kun aiemmista projekteista tuttujen komponenttien joukosta löytyy sellasia, joita voidaan hyödyntää käsillä olevassa työssä, jolloin projektille saadaan lentävä lähtö.

 

Mitkä ovat ohjelmistoprojektisi kustannukset? Arvioi hintalaskurilla.

Jami Sjöblom

Jami Sjöblom