Ohjelmistokehitystä ostamassa? Vältä lukittautumasta liiaksi lähtöolettamiin, sillä ymmärrys kasvaa toteutusvaiheessa merkittävästi.

Suunnitteilla uusi digipalvelu tai uudistushanke?

Räätälöidyn ohjelmiston ostamiseen liittyy paljon huomioitavaa. Edellisessä blogissa jaoimme tarkistuslistan asioista, joita sinun olisi hyvä pohtia heti alkumetreillä.

Tässä blogisarjan toisessa osassa avaamme kuinka ymmärrys kasvaa kehitystyön aikana sekä miten ja miksi se kannattaa huomioida työskentelytavoissa ja kilpailutuksessa.

Perinteisen mallin haasteet

Perinteisesti ohjelmistokehitystyö lähtee liikkeelle esitutkimuksella, jota seuraa määrittelytyö. Esitutkimusvaiheessa pyritään selvittämään mitä markkinoilla on ja mitä kaivattaisiin. Tässä vaiheessa helposti sorrutaan oikaisemaan ja käsitys käyttäjien tarpeista ja markkinatilanteesta perustuu enemmänkin omiin oletuksiin kuin tutkittuun tietoon.

Seuraavaksi alkaa määrittelytyö. Vaatimuksia kirjataan enemmän tai vähemmän valistuneiden arvausten pohjalta. Jos kyseessä on vähänkään laajempi järjestelmä, kalenteriaikaa kuluu tyypillisesti kvartaaleista vuosiin. Jossain kohtaa sitten päätetään, että määrittelyt ovat valmiit ja kilpailutetaan niiden mukainen toteutus. Työ annetaan halvimmalle toimittajalle ja 1-2 vuoden päästä on syntynyt uusi, markkinoita johtava järjestelmä.

Kuulostaako reseptiltä menestykseen? Valitettavasti tämä ei räätälöityjen ohjelmistojen osalta ole osoittautunut toimivaksi reseptiksi. Matkassa on monta mutkaa ja malli perustuu illuusioon siitä, että yllätyksiä ja muutostarpeita ei tulisi.

Täydellistä määrittelyä ei ole olemassa

Täydellisen määrittelyn teko etukäteen on käytännössä mahdoton tehtävä. Huomioitavia asioita on valtavasti, koska myös erikoistapaukset ja erilaiset poikkeustilanteet on käsiteltävä. Haastetta ei helpota se, että meillä ihmisillä on rajallinen kapasiteetti. Laajoja suunnitelmia on vaikea hahmottaa ja kun asioiden määrä kasvaa, inhimillisiä virheitä ja puutteita alkaa esiintyä väistämättä.

Lisäksi on muistettava, että nykymaailmassa muutosvauhti on hengästyttävä. Kilpailijat ovat aktiivisia, markkinatilanteet muuttuvat nopeasti ja teknologiat vanhentuvat. Vuoden vanhan määrittelyn toteutus on jo melko todennäköisesti ainakin osittain hukkaan heitettyä aikaa ja rahaa.

"Kun hankit räätälöityä ohjelmistoa kiinteähintaisena projektina, suurimmat rajoitteet ovat esitutkimus- ja määrittelyvaiheessa asetetut vaatimukset. Jos ne osoittautuvat matkan varrella vääriksi tai johtavat epäoptimaaliseen tulokseen, ei suunnitelmia noin vain muutetakaan."

Ketterä malli mahdollistaa muutoksiin reagoimisen ja johtaa parempaan lopputulokseen

Ymmärrys kasvaa kehityshankkeen aikana

Ketterän kehitysprojektin aikana selvitämme, määrittelemme ja toteutamme pala kerrallaan asioita, joiden myötä ymmärryksemme aihealueesta kasvaa. Sen ansiosta meillä on aina entistä parempi näkemys seuraavan palan suunnittelua varten. Myös muutostarpeisiin on mahdollista reagoida ja löytää toimivimmat ratkaisut.

Ohjelmistokehityksessä kysymys on osaltaan myös luovasta työstä, jonka voi rinnastaa vaikka tämän blogin kirjoittamiseen. Etukäteen blogin ydinidea oli kirjoittaa ymmärryksen kasvamisesta kehityshankkeen aikana. Kirjoittaessa tuli kuitenkin selväksi, että tarvitaan taustoitusta ja on syytä kertoa myös etukäteen tehtävän määrittelytyön ongelmista. Vastaavalla tavalla sovelluksen kehitys on luovaa työtä ja sovelluksesta hioutuu timantti vasta iteraatioiden avulla.

Vaatimusten kiinnittaminen visualisointi

Kolme asiaa, joita ymmärryksen hyödyntäminen vaatii:

  1. Yhteistyön malli
    Kaupallisten hankintaehtojen täytyy perustua tehdyn työn määrään, jotta sisältöä voidaan muuttaa hankkeen edetessä. Tässä mallissa tilaajalla tulee säilyä tuoteomistajan rooli ja sitä myötä täysi valta siitä mitä tehdään.
  2. Ketterät menetelmät
    Iteratiivinen kehitystyö, jossa samanaikaisesti tehdään aina seuraavaksi toteutettavien toimintojen määrittelytyötä, mahdollistaa parhaiten reagoinnin ymmärryksen kasvusta tunnistettuihin tarvittaviin muutoksiin. Läpinäkyvyys kaikkeen tekemiseen on yksi tärkeimpiä ketterän kehityksen periaatteita ja asiakkaan kannattaa huolehtia, että se myös toteutuu.
  1. Modernit ohjelmistokehitysmallit ja työkalut (DevOps)
    DevOpsin tavoitteena on automatisoida ohjelmiston paketointi-, laadunvarmistus- ja julkaisuprosessit, jolloin kehitystyöstä tulee avoimempaa ja laadukkaampaa. Jotta uusia versioita saadaan sujuvasti tilaajan testattavaksi ja julkaistavaksi, tulee kehitystiimillä olla käytössään nykyaikaiset DevOps-työkalut niin julkaisuun kuin testausautomaatioonkin.

Kiinteähintaista ketteryyttä ei ole olemassa

Joskus mainospuheissa kuulee, että ohjelmistokehitystä tehdään ketterästi, mutta kiinteähintaisella mallilla. Tätä ei kannata uskoa, koska myös toimittajien täytyy tehdä kannattavaa liiketoimintaa.

Käytännössä kiinteähintainen yhteistyömalli ohjaa toimittajaa minimoimaan käytettyä työaikaa. Se tapahtuu rajoittamalla vaatimuksiin kohdistuvia muutoksia ja parannuksia. Alkuperäiset vaatimukset kyllä katetaan, mutta lopputuloksen kannalta jäädään usein toiminnallisuuksien näkökulmasta välttävälle tasolle. Lisäksi kiinteähintaisissa toimituksissa helposti tingitään toteutuksen teknisestä laadusta.

Ketterää ostamista ei pidä pelätä

Osa asiakkaista tuntuu pelkäävän toteutuneeseen työhön pohjautuvaa hinnoittelua. Pelko on turha, kunhan säilyttää itse kontrollin hankkeen sisältöön ja oma tuotteenomistaja on aktiivisesti projektissa mukana. Itse asiassa toteutuneeseen työhön pohjautuvalla ostamisella voidaan saavuttaa paljon hienojakoisempi mahdollisuus hallita budjetin käyttöä.

Kun ostat ketterästi, varmista, että:

  • Kaikki tekeminen ja kustannukset ovat läpinäkyviä
  • Teet itse tilaajana sisällölliset päätökset ja ohjaat tiimin ajan ja budjetin käyttöä
  • Saat tilaajana kaikki oikeudet työn tuloksiin
  • Teknologiat ovat yleisesti käytössä olevia ja osaamista on saatavilla useilta toimittajilta
  • Työt on mahdollista keskeyttää lyhyellä varoitusajalla, jos tulokset eivät ole riittävän hyviä, ja toimittaja on velvollinen perehdyttämään seuraavan toimittajan hankkeeseen
  • Teknisen tekemisen osalta varmista, että tiimissä on mukana myös konkareita. Varmista myös, että kehitystiimillä on käytössä korkean laadun mahdollistava nykyaikainen automaatiotestaus ja automaattinen koodianalyysi, joiden tulokset ovat kaikkien nähtävillä.

Kun nämä asiat ovat kunnossa, hankkeen aikana kasvava ymmärrys voidaan hyödyntää ja kustannusten hallinta säilyy omissa käsissä.

Autamme sinua koko ohjelmistohankkeen elinkaaren aikana.

Haluatko keskustella omasta kehityshankkeestasi?

Ota yhteyttä

 

Julkaistu: 15. toukokuuta 2020

Päivitetty: 28. syyskuuta 2021

Software developmentDesign and UX