Mahdollista parhaan ohjelmistoratkaisun löytäminen

Kirjoittanut Raine Kelkka
Reaalimaailman projekteissa käytetylle ajalle ja rahalle täytyy saada tuottavaa vastinetta. Kun ohjelmistotuotteen kehittämistä tehdään projektiluonteisesti, on tunnistettava, mitkä keinot mahdollistavat parhaiden ratkaisujen löytämisen ja mitkä estävät sen. Tarkoitus ei ole käyttää enempää resursseja vaan saada resursseista paras mahdollinen irti.
Tuotekehityksessä lopullinen tuote voi olla hyvinkin koukeroisen polun takana ja tarkkarajainen projekti ei tällöin sovellu. Usein projekteissa lyödään ensimmäisenä lukkoon aikataulut ja resurssit vaikka lopullinen tuote on vielä sarastava visio. Jos ei tiedetä kohdetta, on hyvin vaikea ennustaa matkan kestoa.
Laajojen kokonaisuuksien arviointi on vaikeaa ja riski aikataulusta lipsumiseen kasvaa. Jos etukäteen päätetystä aikarajasta pidetään kiinni väkisin, on projekti pakotettu tuottamaan jotain, mikä ei välttämättä vastaa lainkaan tarpeita.
Tuotekehityksen jakaminen pieniin askeliin, jotka keskittyvät tuottamaan aidosti arvokkaita ominaisuuksia, pienentää riskiä isosta pettymyksestä kovan deadlinen ääressä.
Ohjelmistokehitys on oppimisprosessi
Ohjelmistokehitys ei ole suoraviivainen valmistusprosessi vaan se muistuttaa enemmän oppimisprosessia. Oppiminen tapahtuu pienin askelin, kun reaalimaailman kokemuksesta havaitaan, miten toteutus vastaa arvioituun ongelmaan.
Ketterissä menetelmissä kehityksen ja palautteen välinen sykli pidetään lyhyenä, sillä mitä kauemmin palautteen saamiseen menee, sitä vaikeampi siihen on reagoida ratkaisusssa.
Kehityssyklin viiveen vaikutus tuotekehitykseen:
- Pieni viive ➡️ harha-askel saadaan korjattua nopeasti ➡️ mahdollistaa paljon kokeiluja ➡️ uskallus innovoida ➡️ löydetään parhaat ratkaisut jalostettavaksi lopulliseen muotoon.
- Suuri viive ➡️ harha-askel on kallis ➡️ rajoitettu määrä kokeiluja ➡️ pelko innovoida ➡️ otetaan varman päälle ja tyydytään pienimpään mahdolliseen riskiin.
Ketterät menetelmät eivät auta, jos sykli ideasta käyttökokemuksiin on liian pitkä suhteessa projektin elinkaareen. Vastaavasti iteratiivinen, eli pala palalta toteutusta jalostava, kehitysmalli ei auta, jos on keskimäärin yksi mahdollisuus saada ominaisuudet tehtyä allokoidun projektin puitteissa. Näin muodostuu väkisinkin vesiputous, jossa varovaisuus voittaa ja innovaatio katoaa.
Kehityssyklin lyhentäminen vähentää hukkaa
Varsinkin raskaalla ohjelmistoprosessilla idean vieminen koko tuotekehityspolun läpi formaaleista vaatimuksista hyväksyntätestauksiin on kallista. Tällöin heikosti arvoa tuottavien ratkaisuiden karsiminen mahdollisimman aikaisessa vaiheessa parantaa kokonaistehokkuutta.
Yksi tapa pyrkiä lyhentämään kehityssykliä on jakaa yksittäisten ominaisuuksien toteutusta eri vaiheisiin, jolloin tuotekehityksen paukut tuottaisivat mahdollisimman vähän hukkatavaraa.
Tällä ajatuksella olen mukaillut Kent Beckin 3x-mallia tuotekehityksen triathlonista:
- aluksi laaditaan useita ratkaisuja mahdollisimman kevyesti ja nopeasti
- seuraavaksi potentiaalisin ratkaisu laitetaan koetukselle ja yritetään kaikin keinoin tunnistaa mahdolliset ongelmat, jotka estävät sen toteutuksen
- toteutuskelpoiseksi arviotu ratkaisu toteutetaan projektissa käytettävän ohjelmistokehitysprosessin mukaisesti
Rohkea ideointi mahdollistaa oivallukset
Uutta ominaisuutta tehdessä voi vapaasti kokeilla kenties älyttömiäkin ideoita esimerkiksi käyttöliittymäprototyypeillä. Nopeallakin demolla voidaan saada ahaa-elämyksiä, jotka johtavat oikean ohjelmistoratkaisun äärelle.
Kustannus epäonnistumisesta pidetään pienenä kevyellä prosessilla ja nopealla palautteella. Kun kehittäjätkin osallistetaan ideointivaiheeseen, saadaan laajempi kirjo ajatuksia ja vältetään yhden suunnittelijan pullonkaula.
Potentiaalisen ratkaisun löydyttyä yritetään paljastaa mahdolliset loogiset puutteet tai ongelmat, jotka estäisivät sen käytön arvioidussa toimintaympäristössä. Jos kyseessä on esimerkiksi isoa datamäärää käsittelevä toiminto, se voidaan käytännössä toteuttaa prototyypin muodossa oleellisilta osin ja altistetaan arvioitua käyttöä vastaavaan kuormaan.
Tämän vaiheen tarkoitus on suhteellisen nopeasti joko validoida idean toteuttamiskelpoisuus tai hylätä se. Tavoite on karsia pois kalliit ja mahdolliset käytön estävät yllätykset tuotekehityksen loppupäässä.
Hyvin suunniteltu on ennustettavampi
Näiden vaiheiden jälkeen voidaan olla melko luottavaisin mielin, että valittu ohjelmistoratkaisu on hyödyllinen ja se toimii myös käytännössä. Seuraavassa vaiheessa on aika laatia toteutus huolellisesti ja viedä laadunvarmistuksen kautta tuotantoon. Varsinainen toteutus on ennustettavampi verrattuna tilanteeseen, jossa lopullista koodia ruvetaan tekemään tyhjältä pöydältä.

Lisätietoja
Tagit
Liiketoimintaprosessi
![]() |
Laatu, turvallisuus ja ympäristö |
![]() |
Tuotekehitys ja suunnittelu |
Erikoisosaaminen
![]() |
Arkkitehtuuri |
Toimialakokemus
![]() |
Asiantuntijapalvelut |
Tarjonnan tyyppi
![]() |
Konsultointi |
Monad - Asiantuntijat ja yhteyshenkilöt
Monad - Muita referenssejä
Monad - Muita bloggauksia
It- ja ohjelmistoalan työpaikat
- Rekrytointi.com - HW Engineer / Senior HW Engineer
- Nordea - Senior Java Developer, Oulu
- Nordea - Full stack developer with backend focus, Oulu
- Nordea - (Senior) IT Analyst vaatimusmäärittelyjen pariin Nordealle Helsinkiin
- Rekrytointi.com - TUOTEPÄÄLLIKKÖ, itsehoidon ja sähköisen asioinnin palvelut
- Rekrytointi.com - TUOTEPÄÄLLIKKÖ, omahoidon ja sähköisen asioinnin palvelut
- Rekrytointi.com - Palvelumuotoilija, Luontopalvelut
Premium-asiakkaiden viimeisimmät referenssit
- Taitori Oy - Taitorin ja Haltianin yhteistyön avulla kohti parempia työntekijäkokemuksia ja tyytyväisempiä työntekijöitä
- Cerion Solutions Oy - Centria aloitti modernin teknologia-arkkitehtuurin rakennustyöt
- Rillion - Rillion ratkaisi Minimanin ostolaskuprosessien haasteet
- Aveso Oy - Case Tikkurila – Datan laadunhallintaa keskitetysti Aveso Data Studiolla
- Innofactor Oyj - Traficomin sähköisen asioinnin alusta
- Innofactor Oyj - Yhteinen CRM-järjestelmä luo läpinäkyvyyttä
- SC Software Oy - Asiakaskohtaisesti räätälöity SaaS-palvelu kehitettiin alle kahdessa kuukaudessa Puumiehet ry:lle
Tapahtumat & webinaarit
- 30.05.2022 - SIAM™ Foundation
- 31.05.2022 - Luohi prosessit ja automatisoi tekoälyllä
- 01.06.2022 - Ohjelmistotestauksen avaintekijät | Upload
- 01.06.2022 - ITIL 4 Foundation | Upload
- 02.06.2022 - Eventilla demo (EN)
- 02.06.2022 - Eventilla demo (EN)
- 06.06.2022 - Certified Agile Service Manager®
Premium-asiakkaiden viimeisimmät bloggaukset
- Taitori Oy - 5 syytä ottaa käyttöön työpisteiden varausjärjestelmä
- Taitori Oy - Korona-exit: mitä kaikkea se oikein tarkoittaa?
- Taitori Oy - Sovita Taitorin Smart Office -ratkaisut yrityksesi brändäykseen!
- Pedab Finland Oy - Kaikki mitä sinun tarvitsee tietää Cloud Pakeista - Osa 6: Datan hallinta ja hyödyntäminen
- Pedab Finland Oy - Päätelaitteet hallintaan ja tietosuoja kuntoon
- Pedab Finland Oy - 10 asiaa, jotka tulee huomioida tietoturvapalvelua valittaessa
- Pedab Finland Oy - Neljä syytä valita IBM Cloud Pakit konttien hallintaan
![]() |
Digitalisaatio & innovaatiot blogimediaBlogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä |