Ohjelmistofirmojen markkinointipuheissa korostuu usein se, miten sujuvasti projektit vedetään maaliin milloin mitäkin mallia käyttäen ja toinen toistaan kauniimpien teknologioiden avulla. Softan tekeminen on kuitenkin käyttäjäläheistä ja niin koodarit kuin asiakkaatkin vain ihmisiä. Kaikki alalla toimivat tietävät, että räätälisoftan tekeminen ei koskaan ole ihan helppo nakki.

Erehtyminen on inhimillistä ja niinpä myös me Systems Gardenilla olemme toisinaan menneet mokien kautta maaliin. Tärkeintä on kuitenkin ottaa opikseen ja kääntää virheet voimavaraksi. Vankan kokemuksemme turvin (ja ehkä myös mokista oppineena) tunnistamme ohjelmistojen arvon liiketoiminnalle ja ymmärrämme niiden käyttäjiä.

10 yleisintä sudenkuoppaa softaprojekteissa

Tähän artikkeliin olemme listanneet ohjelmistotarpeen määrittelyn 10 yleistä sudenkuoppaa sekä kokemuspohjaiset vinkkimme niiden välttämiseksi. Virheitä voi toki tehdä myös teknologiatasolla, mutta kokemuksemme mukaan kaikkein vaikeimmat haasteet syntyvät jo suunnittelussa, määrittelyssä ja liiketoimintatarpeiden ymmärryksessä.

1. Sisäinen työkalu vai asiakasohjelmisto?

Etenkin Suomen kokoisilla markkinoilla on turhaa yksinkertaistamista, että softa kannattaisi tehdä aina tietyllä tavalla. Karkeasti jaotellen on olemassa sovelluksia, jotka näkyvät asiakkaan suuntaan ja tavoittelevat kilpailuetua tai asiakaspalvelun parantamista, ja toisaalta softia voidaan käyttää sisäisiin prosesseihin ja toiminnan tehostamiseen oman väen kesken.

Organisaatioilla voi siis olla paljon tarvetta erilaisen tiedon keräämiselle, järjestämiselle ja jakamiselle. Jos kaikkea lähdetään toteuttamaan samalla sabluunalla, saatetaan toisinaan ampua norsupyssyllä kärpästä.

Eräässä tapauksessa rakennusalan palveluyritykselle oltiin toteuttamassa asiakasportaalia, jolla luotaisiin uusi palvelukanava sähköiseen asioinnin kautta. Kun siirryttiin toteutukseen, kävikin ilmi, etteivät asiakkaan tuotantoprosessit tai toimintamallit tukeneet tällaista ajatusta lainkaan. Laskentamalliin ja asiakaspalveluun ei ollut saatavilla riittävää dataa, koska toiminta ja suunnittelumallit perustuivatkin ihmisten osaamiseen. Koska syötettä ei ollut, ratkaisu oli jäämässä pelkäksi markkinointikanavaksi.

Lopputuloksena toteutettiinkin sisäiseen käyttöön toiminnanohjausjärjestelmä, johon kului lopulta koko budjetti, mutta jolla sentään saatiin tuettua sisäisiä prosesseja. Asiakaspalvelukanava jäi odottamaan aikaa parempaa.

Ohjelmistotarpeen määrittelemiseksi tulee ensin ymmärtää liiketoiminnan tarpeet ja se, mitä, kenelle ja miksi ollaan rakentamassa.

2. Ohjelmiston alkuperäinen käyttötarkoitus unohtuu

Asiakas on oman tekemisensä asiantuntija ja tärkeimmässä roolissa siinä määrittelyssä, jonka turvin saadaan aikaiseksi hänen tarvitsemansa ratkaisut. Edellisen kohdan esimerkkiprojektissa oli kuitenkin ongelmana myös päätavoitteen hämärtyminen. Projektiryhmän toiminta ohjautui siihen, mikä milloinkin muodosti ongelman, eikä näin ollen aina välttämättä tehty sitä, mikä olisi ollut oikeasti tärkeää.

Ohjelmistotarpeen määrittelyssä tulisi aina joko kirjata tavoitteet tai vaihtoehtoisesti hyväksyä se, että projektia lähdetään toteuttamaan pala kerrallaan ketterästi ohjautuen. Joskus pitää vain tehdä tietoisesti se päätös, että jostain luovutaan hetkellisesti, jotta jotain tärkeämpää saadaan toteutettua.

On helppo sortua määrittelemään liikaa etukäteen sitä, minkälainen sovelluksen käyttöliittymän halutaan olevan, kun järkevämpää olisi keskittyä siihen, millainen sen pitäisi liiketoimintaa palvellakseen olla.

Kannustamme myös ehdottomasti ohjausryhmän käyttöön. Ohjelmistoprojekteissa tulee väistämättä eteen hankalia priorisointipäätöksiä, jolloin projektiryhmän ohella on hyvä olla toinenkin foorumi. Sen vain pitää olla avoin ja valmis puhumaan vaikeista asioista.

Ohjausryhmään viedään usein lähinnä budjettiin tai aikatauluun liittyviä asioita, mutta sinne pitäisi viedä myös esimerkiksi sellaisia haasteita, että teknologia ei taivu haluttuun ratkaisuun tai liiketoiminnan muoto ei tue sovellukselta kaivattua toimintaa.

On kuitenkin tärkeää muistaa, että ohjelmisto tulisi laatia tukemaan prosessia sen sijaan, että prosessia muutettaisiin ohjelmiston ehdoilla.

3. Ohjelmiston käyttäjiä ei tunneta tai ainakaan ymmärretä

Silloin tällöin olemme saattaneet ryhtyä luomaan hienoa softaa intuitiivisella käyttöliittymällä, kunnes on käynyt ilmi, että sovellusta tulee käyttämään yksi ihminen. Tarve on voinut koskea esimerkiksi sihteerin työhön kuuluvaa datan keräämistä tai sen esittämistä tietyssä muodossa.

Olemmekin joskus todenneet jotkin softat, joista tulisi hyötymään 1-2 ihmistä niin kalliiksi, että niitä ei yksinkertaisesti kannata tehdä. Me olemme tyytyväisiä, vaikka määrittely jäisi tähän, sillä ei ole mitään ikävämpää kuin toteuttaa hienoa ja kallista softaa, joka ei hyödytä asiakasta samassa suhteessa.

Nykyisin on vaikeaa keksiä asiaa, johon ei löytyisi erikoissoftaa. Siksi myös valmisohjelmistot kannattaa lähes aina kartoittaa. Vastaamme on tullut paljon tapauksia, joissa kaivatut työkalut saa jo ostettua muutamalla dollarilla.

Yhdelle työntekijälle onkin yleensä halvempaa hankkia olemassa olevan ohjelmiston lisenssi kuin teettää kokonaan uusi ratkaisu. Sopivan sovelluksen löytyminen voi myös herättää siihen, tarvitaanko ratkaisulta ihan oikeasti kaikkia haaveiltuja nyansseja.

Osana ohjelmistotarpeen määrittelyä me Systems Gardenilla laadimme ns. käyttäjätarinat, jotka auttavat ymmärtämään käyttäjien rooleja. Käyttäjäpersoonien määrittelyn ohella kannattaa kuitenkin huomioida myös sellaiset tahot, jotka eivät välttämättä käytä sovellusta ollenkaan, mutta hyötyvät sen keräämästä datasta.

4. Ohjelmiston toimintaa ei piirretä auki

Kaikki softat ovat viime kädessä tietoa kerääviä lomakkeita ja niitä esittäviä listauksia ja näkymiä. Tiedon keruu ja esitys voidaan kuitenkin toteuttaa hyvin monessa eri muodossa ja monella erilaisella mekanismilla. Asiakkaalla on usein niin selkeä visio siitä, mitä tavoitellaan, että kaikkea ei tule mieleen ilmaista.

Jos suunnittelu on toisaalta vain sanallista, jää väärinymmärryksille edelleen paljon tilaa ja seurauksena voi olla vaikeita tilanteita. Olettamus on kaikkien emämunausten äiti.

Eräässä esimerkkitapauksessa asiakasyrityksen tavoitteena oli, että heidän asentajansa löytävät oikeat keikat. Vasta piirtämällä ajatus kuvaksi oivallettiin, että asentajat ilmestyisivät kohteisiinsa milloin sattuu, ja järjestelmä saattaisi laittaa keikat uusiksi kesken päivää, kun asentaja on jo puolimatkassa jonnekin muualle.

Usein onkin helpompi todeta, mitä sovellukselta ei haluta. Kun se piirretään kuvaksi, on helpompi havaita se, mikä ei toimi tai mikä vielä puuttuu.

On myös tärkeää huomioida se, toimiiko prosessi kaikissa tapauksissa sovellukselta vaadittavalla tavalla. Vaikka poikkeustapauksia olisi vain 2 %, softan toiminta tulee tökkäämään niihin. Ketterä ohjelmistokehitys mielletään usein siten, että mitään ei tarvitse määritellä kovin tarkasti, vaikka todellisuudessa softan taustalla voi olla kokonainen tiimi tekemässä koodiin muutoksia, jotka voivat olla hyvinkin työläitä. Rautalankamallin muuttaminen on aina halvempaa kuin toimivan softan uudelleenkoodaus.

Kuvallinen havainnollistaminen on kuitenkin tärkeää pitää rautalankamallin tasolla menemättä ulkoasullisiin seikkoihin. Heti, kun mukaan tulee värejä tai grafiikkaa, keskittyminen ohjautuu vääriin asioihin ja niitä paalutetaan turhan varhaisessa vaiheessa. Rautalanka on koodiin verrattuna halpaa, mutta silläkin kyetään demonstroimaan paljon.

5. Käyttäjien tarpeita tai motivaatioita ei huomioida

Muutosvastarintaa softan käyttöönottoa kohtaan esiintyy sitä herkemmin, mitä myöhäisemmässä vaiheessa tulevat käyttäjät huomioidaan – puhumattakaan siitä, että heitä ei huomioida ollenkaan. Klassisessa esimerkissä (ja aivan liian usein) toimistotyöntekijä tai johtaja suunnittelee jotain kentällä toimivalle asentajalle, jota lopputulos ei ensinkään palvele.

Toisinaan ennakkoluulot liittyvät pelkoon siitä, että softa vähentää työvoimatarvetta, vaikka uuden ohjelmiston tarkoitus on yleensä vain turhan työn vähentäminen ja työntekijöiden vapauttaminen siihen, missä he ovat hyviä ja tuottavat eniten arvoa.

Ohjelmisto ei tee yksin mitään, vaan esimerkiksi putkimies rakentaa LVIS-järjestelmiä ja saa ohjelmiston avulla tiedon siitä, missä on seuraava keikka. Avoin kommunikointi sovelluksen tarkoituksesta onkin avainroolissa.

Ohjelmisto on usein välttämätöntä pilotoida ensin pienellä ryhmällä, mutta toisaalta sen todellinen hyöty paljastuu tyypillisesti vasta, kun yli 80 % kirjauksista saadaan järjestelmään.

Kun töitä sitten tehdään vanhan järjestelmän kanssa päällekkäin, käyttäjässä herää helposti tunne uuden kyseenalaisesta tarpeesta. Niinpä hyväkin sovellus on joskus kaatunut siihen, että sitä ei vain ole saatu käyttöön.

Olennaista on tunnistaa kriittinen massa, jonka avulla sovellus myy itse itsensä. Kun hyödyllinen ratkaisu nähdään toisten käytössä, se usein halutaan helpottamaan myös omaa työtä.

Tarkoituksenmukaisin sovellus ja sujuvin käyttöönotto saavutetaan joka tapauksessa silloin, kun käyttäjiä osallistetaan ja sitoutetaan prosessiin mahdollisimman varhaisessa vaiheessa. Ohjelmiston arvo ei muodostu sen valmistuessa, vaan vasta silloin kun se on otettu riittävän laajasti käyttöön.

6. Samoja tietoja kirjataan useita kertoja

Mikäli ohjelmiston liittymätarpeita ei huomioida ajoissa, saattaa niitä ilmetä runsaastikin vasta käyttöönottovaiheessa. Moni ohjelmistoprojekti pysähtyykin aikataulullisesti tällaiseen pullonkaulaan juuri loppuvaiheessaan.

On olemassa tapauksia, joissa liittymävaihe on kestänyt peräti kolme kertaa kauemmin, ja vastaavasti maksanut kolme kertaa enemmän kuin itse softan luominen. On hyvä muistaa, että jos dataan sisältyy esimerkiksi asiakkaiden nimien kaltaista tietoa, jonkun tulee myös ylläpitää sitä.

Aina tulisikin mieluummin pyrkiä siihen, että tieto kirjataan vain kerran, minkä jälkeen se soljuu järjestelmien välillä. Sitä varten määrittelyssä tulisi yhtä aikaa kyetä hahmottamaan kokonaisuus, mutta mennä myös siinä määrin yksityiskohtiin, että ohjelmiston paikka prosessissa sekä sen vaatimat liittymät tunnetaan.

Toisin sanottuna: mikä on se paikka, jossa tietoa ylläpidetään, ja missä muualla sen pitäisi olla käytettävissä. Tätä voidaan havainnollistaa prosessikaaviolla ja automatisoida integraatioilla.

7. Testailun ja testaamisen eroa ei ymmärretä

Testailu on sitä, että sovellusta vain klikkaillaan sieltä täältä ja sen toimintoja hieman kokeillaan. Kun sovellus otetaan sen jälkeen suoraan käyttöön, voidaankin joutua toteamaan, että se ei toimi ollenkaan todellisen prosessin mukaisesti.

Sen sijaan testaaminen on suunnitelmallista toimintaa, jolla varmistetaan, että sovellus tekee sen, mitä siltä vaaditaan. Tärkeää on myös sen huomioiminen, mitä sovellus ei saa tehdä, ja testata, mitä mahdollisissa virhetilanteissa tapahtuu. Testausvaiheessa olisi hyvä olla mukana niin toteuttajan kuin asiakkaan taholta sellaisia henkilöitä, jotka eivät ole osallistuneet ohjelmiston kehitykseen.

Klassinen moka testausvaiheessa on, että järjestelmään ei syötetä todellisia tietoja. On eri asia verifioida, meneekö ”Testikeikka” läpi ”Testiasentajalle”, kuin oikeasti simuloida koko työnkulku toimistosta kentälle ja takaisin oikeiden ihmisten kautta.

8. Ohjelmistosta laaditaan turha käyttöohje ja oletetaan sen riittävän

Ohjelmistojen hankintaan liittyy usein eräänlainen opittu tarve seikkaperäiselle käyttöohjeelle. Käyttöohjettakin täytyy kuitenkin ylläpitää, ja se täytyy päivittää aina kun asioihin tehdään muutoksia. Mitä laajempi käyttöohje on, sitä enemmän ylläpidettävää. Mikään ei myöskään harmita niin paljon kuin se, kun etsii käyttöohjeesta apua, mutta tieto onkin virheellistä tai vanhentunutta.

Ohjelmistomäärittelyssä on järkevää pohtia käytäntöjen ja vaatimusten perimmäistä tarkoitusta ja suoraan sanoen sitä, lukeeko käyttöohjetta viime kädessä kukaan? Mikäli kyseessä on sisäinen softa, jota käyttää rajallinen määrä ihmisiä, pärjättäisiinkö suppeammalla käyttöohjeella tai saataisiinko se vaikka intranetiin? Voisiko kenttien yhteyteen lisätä lyhyen infotekstin sen sijaan että tuotetaan 20 sivua ruutukaappauksia Word-dokumenttiin?

Kannattaa kuitenkin huomioida, että B2B-sovellusta ei usein edes voi toteuttaa niin yksinkertaseksi, etteikö sen käyttäminen vaatisi koulutusta. Kuluttajasoftan puolestaan tulisi yleensä olla kenen tahansa käytettävissä enintään lyhyellä opastuksella. Molempia yhdistää se, että mitä paremmin jo alussa määritellään käyttöliittymän kanssa pärjäämiseksi vaadittavat tiedot, sitä vähemmän kaikilla on töitä loppupäässä. Panostukset käytettävyyteen näkyvätkin yleensä suorina säästöinä koulutusbudjetissa. Tärkeämpää on, että käyttäjätuki on kunnossa ja palautetta kerätään ja siitä opitaan.

9. Ohjelmisto suunnitellaan valmistuvaksi kerralla.

Ohjelmistojen elinkaareksi mainitaan usein keskimäärin seitsemän vuotta, mutta sinäkin aikana voi syntyä runsaasti uusiin asetuksiin ja tietoturvaseikkoihin liittyviä muutostarpeita. Jos lähdetään teettämään omaa customsoftaa, on syytä varautua siihen, että muutostarpeita tulee matkan varrella paljon.

On ikävää joutua toteamaan, että softa ei ole tietoturvallinen koska joku alustakomponentti on vanhentunut, tai huomata, että värkki ei enää toimikaan kuin yli kolme vuotta vanhoilla kännyköillä.

Järkevintä on pyrkiä hahmottamaan kokonaisuus, luoda siitä road map, toteuttaa sitä pala kerrallaan ja valmistautua tekemään muutoksia myös pilotoinnin jälkeen.

Sen sijaan, että ajatellaan mitä kaikkea voitaisiin tehdä, on fiksumpaa keskittyä siihen, mitä täytyy tehdä. Silloin ei myöskään hämmennetä käyttäjiä turhilla toiminnallisuuksilla. Kun aluksi luodaan vain ehdottomat toiminnallisuudet, saatetaankin huomata, että enempää ei edes tarvita.

10. Ohjelmistoa ei suunnitella skaalautuvaksi

Toisinaan käy niin, että ohjelmistoa on käytetty vasta ensimmäiset kolme kuukautta, kun dataa on karttunut jo niin paljon, että sitä ei kyetä hallitsemaan. Vastaavasti softa on voinut toimia hyvin vuodenvaihteen katkoon saakka, mutta ongelmia ilmenee, kun pitäisi tuottaa väliraportti.

Vanhojen sovellusten modernisoinnissa saadaan usein etumatkaa, sillä niiden parissa käytettävissä on heti suuri määrä dataa sen testaamiseen, mitkä elementit eivät mahdollisesti toimikaan. Mikäli kyseessä on uusi sovellus, tulee yrittää mahdollisimman hyvin arvioida, missä määrin ja millä tahdilla datan määrä kasvaa. Toimivuutta voidaan testata myös rakentamalla tekstieditorien käyttämän lorem ipsumin tavoin ns. mokkidataa.

Ongelmia voidaan lisäksi ehkäistä sillä, että valitaan toimintatapoja, joissa ei synny toimittajalukkoja tai tarvita suojattuja komponentteja.

Koska yllätyksiä voi ilmaantua ja asioihin joutua palaamaan, suosittelemme lämpimästi hyödyntämään tarjontaamme kuuluvaa tukisopimuspalvelua.

Lue lisää