Kestävä ohjelmistokehitys kannattaa
Meillä Monadilla uskotaan kestävään ohjelmistokehitykseen; kaikessa toiminnassa pyritään luomaan mahdollisimman laadukas ohjelmistotuote oikeaan tarkoitukseen pienimmillä kokonaiskustannuksilla. Jotta tähän päästäisiin, keskeisenä tavoitteena on kehittää alusta asti tuote, jolla on pitkä elinkaari.
Monet tosimaailman esimerkit antavat kuitenkin syyn epäillä, ovatko kohtuulliset kustannukset ja pitkä elinkaari edes mahdollinen yhdistelmä. Projektin alussa muutokset ohjelmistoon saadaan nopeasti, mutta myöhemmässä vaiheessa ne vaikuttavat tuskaisen hitailta, mikä antaa mielikuvan aina vain nousevista kustannuksista. Pitkän elinkaaren tuotteen arvoa nakertavat osaltaan esimerkit, joissa tuote ei millään pysty reagoimaan muuttuviin vaatimuksiin. Usein molempien ongelmien uskotaan korjaantuvan sillä, että tuodaan uusi tuote korvaamaan vanha.
Nousee kysymys: jos ohjelmistotuotteet täytyy kuitenkin tehdä uudelleen, onko ollenkaan edes kannattavaa pyrkiä tekemään ohjelmistoa, jonka tarkoituksena on olla pitkän elinkaaren tuote? Me sanomme, että kyllä on. Sen lisäksi väitämme, että vaikka tarkoituksena on tehdä korkealaatuinen ja pitkään kestävä ohjelmistoratkaisu, on se myös lopulta halvempi vaihtoehto.
Tähtäimessä tuotteelle pitkä elinkaari
Useimmilla uusilla ohjelmistoilla on tavoitteena olla pitkään käytettävä tuote, vaikka sitä ei projektin alkuvaiheessa erityisesti ajateltaisi niin. Joitain poikkeuksia tietysti on: voidaan haluta tehdä esimerkiksi kertaluontoinen projekti, jossa kokeillaan jonkin asian toimivuutta tai tuote voi olla luonteeltaan sellainen, jota käytetään vain hetken aikaa. Kuitenkin usein kun harkitaan uuden ohjelmistotuotteen tilaamista, on tahtotilana saada tuotos, joka tuottaa arvoa pitkälle tulevaisuuteen. Ostaja haluaa saada käyttöön hyvän ohjelmistotuotteen, joka palvelee ensimmäisestä versiosta lähtien ja jota pystytään parantamaan ilman, että tarvitsee tehdä suuria ja kalliita muutosprojekteja; puhumattakaan, että joudutaan rakentamaan uusi korvaava ohjelmisto.
Ohjelmiston kehittäminen on lähes aina mittava projekti. Siitä syystä monet ohjelmistotuotteet – riippumatta siitä onko ne tehty hyvin tai huonosti – ovatkin käytössä pitkään. Pitkään käytössä olevista järjestelmistä ensimmäisenä tulee mieleen jättimäiset lentokentän tai terveydenhuollon järjestelmät, joihin investoidaan aluksi paljon ja niitä käytetään tunnollisesti kymmeniä vuosia osittain näiden korkeiden investointien vuoksi. Kuitenkin myös pienellä kustannuksella tehty ja hyvin rajattu tuote voi olla pitkään käytössä. Hyvänä esimerkkinä on Windows Task Manager, joka on yksinkertainen sivuprojektina aloitettu ohjelmisto, mutta on pohjimmiltaan sama 25 vuoden jälkeen [1]. Silti se on joka päivityksen jälkeen näyttänyt vähän erilaiselta ja sen käytettävyys on parantunut.
Siinä on kuitenkin selvä ero, onko tuote kehitetty kestävän ohjelmistokehityksen periaatteiden mukaisesti vai ei. Mitä eroa on ohjelmistotuotteella, jota käytetään pitkään ja pitkän elinkaaren käyttöön suunnitellulla kestävästi kehitetyllä ohjelmistotuotteella? Jos tuotetta ei kehitetä kestävän ohjelmistokehityksen mukaisesti, se saattaa kyllä olla pitkään käytössä, mutta sen kustannukset kasvavat ja kun uusia ominaisuuksia ei enää saada helposti lisättyä, sen käyttäjät alkavat toivomaan parempia vaihtoehtoja. Tällöin tuotteen potentiaalinen arvo jää saavuttamatta ja pahimmillaan tuotteesta tulee enemmän ongelmia kuin hyötyjä. Jos tuotetta yritetään tehdä ainoastaan lyhyellä tähtäimellä, voi näyttää siltä, että saadaan lyhyen aikavälin “voittoja”, mutta niistä voitoista joudutaan maksamaan moninkertaisesti myöhemmin. Tässä taustalla on jo pitkään tunnettu fakta: jokaiseen tuotteeseen tarvitaan aina muutoksia.
Menestyvä ohjelmistotuote on aina keskeneräinen
Kuvitellaan uuden ohjelmistotuotteen syntyhetkeä: ohjelmistotuotteen hankkijalla on usein paljon ajatuksia, mitä valmiilla tuotteella pitäisi saada tehtyä, mutta ne ovat harvoin suorilta käännettävissä toimivaksi ohjelmistotuotteeksi. On usein huomattu, että ajatukset selkenevät parhaiten siinä vaiheessa kun itse kehitystä tehdään; löydetään parempia tapoja täyttää käyttäjän tarpeet ja huomataan, että joitain asioita ei kannata tehdä ollenkaan. Tässä prosessissa kokenut projektitiimi on erityisen arvokas: asiantuntevat tekijät tietävät projektin alkuvaiheessa mihin kannattaa panostaa, jotta voidaan tehdä oikeita asioita ja jättää epäoleellisemmat asiat myöhemmäksi. Projektin edetessä yksityiskohdat jatkavat hahmottumistaan ja kun pohjatyö on tehty se mielessä että muutoksia tullaan tekemään, ne pystytään tekemään helposti.
”Successful software always gets changed” – Fred Brooks
Voidaan helposti olettaa, että kukaan ei halua tehdä ohjelmistoa, joka ei ole onnistunut tai menestyvä. Oli kyse ohjelmistosta, joka tehostaa liiketoiminnan osa-alueita sisäisesti tai on itse uusi myytävä tuote, sen halutaan olevan menestys. Menestys tuo tullessaan isompia käyttäjämääriä ja uusia käyttötarkoituksia – ja näiden kautta lopulta myös muutoksia ohjelmistoon. Toisaalta vaikka ihanteellisesti kaikki muutokset johtuisivat mahtavasta menestyksestä, joudutaan ohjelmistoon tekemään myös muutoksia vähemmän miellyttävistä syistä. Jokaisesta ohjelmistosta löytyy kovalla käytöllä puutteita, joita ei ole aluksi otettu huomioon, tai jotkut toiminnallisuudet eivät jossain käytännön tilanteissa vain toimi.
Oli syy menestys tai puutteelliset ominaisuudet, yksi keskeinen asia on kuitenkin selvä – käytössä olevaan ohjelmistotuotteeseen tulee aina muutospaineita. Tämän vuoksi on epärealistista ajatella, että ohjelmistotuote olisi valmis kun ensimmäinen versio siitä syntyy. Jos haluaa oikeasti selvittää mitä ohjelmistotuotteen tekeminen maksaa, täytyy katsoa pidemmälle.
Kestävä kehitys on halvempaa vaikka se ei aluksi näytä siltä
On tärkeää tuoda esiin, että kestävä ohjelmistokehitys, jonka lopputuloksena pyritään tuottamaan pitkän elinkaaren tuote, ei tarkoita sitä, että tuotteen ominaisuuksia tehtäisiin pitkään. Sen sijaan kehityksessä otetaan huomioon, että tuotettava ohjelmisto on pitkäikäinen ja pitkän iän aikana sen tarvitsee olla myös joustava siihen kohdistuville muutospaineille. Tämä on myös halvempaa, koska kuten itse ohjelmistoa, myös kustannuksia pitää katsoa pitkällä tähtäimellä.
Kustannuksia ei kuitenkaan aina haluta tai voida katsoa pitkällä tähtäimellä. Ohjelmistoprojektien kilpailutustilanteet ovat erityisen alttiita sille, että keskitytään lyhyen aikavälin kustannuksiin. Kovan kilpailun vuoksi ohjelmistotaloilla on usein paine tarjota ohjelmistoa, joka näyttää tarjousten vertailussa hyvältä kilpailijoihin nähden. Tarjouksessa pyritään tuomaan kehittämisen kustannukset mahdollisimman alas ja saada lopputulos näyttämään nopeasti toteutettavalta. Paperilla hyvältä näyttävä tarjous luultavasti saa paremman sijoituksen kilpailijoihin nähden ja saa täten paremmat todennäköisyydet tulla valituksi. Todellisuudessa liian hyvältä näyttävä tarjous sisältää kuitenkin ainoastaan ensimmäisen version kustannukset.
Jos keskitytään vain ensimmäisen version kustannuksiin, tehdään nopeasti virhearviointeja. On tutkittu, että suurin osa koko elinkaaren kustannuksista syntyy vasta ensimmäisen version julkaisun jälkeen – jopa 60-80 % [2]. Usein “nopeasti tehdyllä” ja vain paperilla hyvältä näyttävillä tuotoksilla on lisähinta, mikä näkyy kalliina eränä ensimmäisen version jälkeisissä kustannuksissa, ja jonka kanssa joutuu elämään mahdollisesti koko tuotteen elinkaaren ajan: alhainen sisäinen laatu (kts. artikkeli). Alan ammattilaiset ovat huomanneet, että vaikka nopeasti tehty ensimmäinen versio voi näyttää aluksi halvemmalta, ohjelmiston jatkokehityksessä huomataan alhaisen laadun aiheuttavan hidastuksia ja lisäkustannuksia [3]. Ja kuten ollaan huomattu, jos ohjelmistoa aiotaan käyttää, jatkokehitystä on aina tulossa.
Lähdetään kestävällä kehityksellä alusta lähtien
Ohjelmistoa kannattaa aina lähteä tekemään kestävän ohjelmistokehityksen mukaisesti heti alusta lähtien. Kun ohjelmistolla on käyttöä, sille tarvitaan ominaisuuksia, että se voi muovautua tulevaisuuden paineiden edessä. Samalla tuotetta, jota ei käytetä ei kannata lähteä edes tekemään. Jotta jatkokehitys olisi nopeaa ja kustannustehokasta, pitää tulevat muutokset huomioida aina uusia ominaisuuksia suunniteltaessa ja kehitettäessä. Jos alkaa etsimään pikavoittoja aikaisissa vaiheissa, päädytään pian tilanteeseen, missä muutokset ovat koko ajan hitaampia ja täten myös kalliimpia. Tämä on tilanne, joka ei palvele ketään.
Monad haluaa olla tekemässä laadukkaita ohjelmistotuotteita, joita ei haluta korvata hetkeen. Tämän vuoksi jo projektin alkuvaiheessa ollaan tarkkoja että tehdään päätöksiä, jotka mahdollistavat ohjelmiston joustavuuden kun vaatimukset vääjäämättä kehittyvät. Kun nämä asiat ovat mielessä alusta lähtien, saadaan lopputulos joka on laadultaan korkea ja kustannustehokas. Samalla saadaan lopputuloksena sellainen ratkaisu, joka saavuttaa parhaimman lopputuloksen ohjelmiston loppukäyttäjille, sen kehittäjille ja sen tilaajalle.
Lassi Pohjoisvirta
Senior Software Engineer
Lähteitä:
[1] 01. Secret History of Windows Task Manager – Part 1 – Origins (viitattu 26.2.2021) https://www.youtube.com/watch?v=f8VBOiPV-_M
[2] Continuous Quality Control of Long-Lived Software Systems (viitattu 27.1.2021): https://www.cqse.eu/fileadmin/content/news/publications/2009-continuous-quality-control-of-long-lived-software-systems.pdf
[3] Is Quality Worth the Cost? Martin Fowler (viitattu 27.1.2021) https://martinfowler.com/articles/is-quality-worth-cost.html
Lisätietoja
Tagit
Erikoisosaaminen
Analytiikka | |
Arkkitehtuuri | |
Integraatiot | |
IoT | |
Ketterät menetelmät | |
Ohjelmistokehitys | |
Pilvipalvelut / SaaS | |
Tekoäly (AI) ja koneoppiminen | |
Webkehitys |
Teknologia
Amazon Web Services | |
Azure | |
Tarjonnan tyyppi
Konsultointi | |
Koulutus | |
Toteutustyö | |
Tuki- ja ylläpitotyö |
Monad - Asiantuntijat ja yhteyshenkilöt
Monad - Muita referenssejä
Monad - Muita bloggauksia
It- ja ohjelmistoalan työpaikat
- Ready Solutions Oy - Senior Data Scientist
- Nordea - Qualtrics XM Process Specialist
- Laura - Analyytikot, tietohallinto
- Laura - Project Director, PMO
- Nordea - Sr IT Operations Support Engineer (Adobe/SAS Marketing Automation)
- Laura - Full Stack kehittäjä
- Digia Oyj - iPaaS-integraatiokehittäjiä ja -arkkitehteja
Premium-asiakkaiden viimeisimmät referenssit
- Red & Blue Oy - Taivalkosken uusi saavutettava ja erottuva verkkopalvelu
- Hion Digital Oy - Vauvan ja vanhemman matkassa – Verkkosovellus, jonka sisältö mukautuu elämäntilanteeseen
- Verkkovaraani Oy - Uudet kotisivut Talin ja Ruusulan keilahalleille
- S1 Networks Oy - Pitäiskö teidän hankkia parempi netti?
- Altoros Finland Oy - Automaattinen kestävyysraportointityökalu CSRD siirtymää varten / Sustashift
- Digiteam Oy - Verkkokaupan toteutus Apollokaihdin.fi
- Digiteam Oy - Kattokeskuksen sivut ykköseksi Googlessa
Tapahtumat & webinaarit
- 13.12.2024 - AamuAreena 13.12.2024: Kestävä kehitys – Vihreät ICT-laitehankinnat
- 17.12.2024 - Rakettiwebinaari: jouluspesiaali – kysy mitä vain!
- 15.01.2025 - Datavastuullisuuden valmennus: hanki valmiudet vastuulliseen datan ja tekoälyn hyödyntämiseen
- 23.01.2025 - Generatiivisen tekoälyn hyödyt liiketoimintajohtajalle
Premium-asiakkaiden viimeisimmät bloggaukset
- Nordea - Dušana Milinkovićin kokemus Nordean graduaattiohjelmasta
- Kisko Labs Oy - Hackathonien haasteet ja ratkaisut: reiluuden ja tuloksellisuuden tavoittelu
- SD Worx - Herkkukori tai viinipullo, ovatko ne enää nykypäivää? Mitä työntekijöille joululahjaksi
- SD Worx - 5 HR-trendiä vuodelle 2025: ihmislähtöisen ja tekoälyvetoisen tulevaisuuden rakentaminen
- Timeless Technology - Aranet4 HOME sisäilman laadun langaton mittari!
- Kisko Labs Oy - Innovatiivisuuden kiihdyttäjä: Miten hackathonit voivat tuoda yrityksellesi uutta potentiaalia
- Ready Solutions Oy - Harjoittelu data- ja tekoälyratkaisujen parissa Ready Solutions Oy:lla
Digitalisaatio & innovaatiot blogimediaBlogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä |