Aki Haapamäki.
Olipa digitaalinen ratkaisu minkä laajuinen tahansa, tulee se hetki, jolloin se ei enää palvele käyttäjiä, eikä skaalaudu liiketoiminnan tarpeisiin. Tällöin moni ohjelmistosta vastaava saattaa huokaista syvään: täytyykö kehitystyö käynnistää uudelleen?
Ohjelmiston käyttö- tai soveltuvuushaasteiden vaakakupissa painavat usein kehitystyön suorat kustannukset sekä välilliset seuraukset, jotka voivat näkyä erilaisten määrittelypalavereiden, testaamisen ja koulutuksien sumana.
Kun käytössä olevia järjestelmiä on useita ja ne palvelevat hyvin erilaisia liiketoiminnan osa-alueita, voidaan olla tilanteessa, jossa joudutaan priorisoimaan liiketoiminnalle yhtäläisesti tärkeitä ohjelmistoja ja järjestelmiä resurssien puitteissa. Tämä voi tarkoittaa, että jokin liiketoiminta-alue saattaa kärsiä puutteellisista järjestelmistä pidempäänkin.
Kestämätön ohjelmistokehitys voidaan nähdä myös ohjelmistoalaa negatiivisesti työllistävänä tekijänä. Voidaankin jopa väittää, että alan työvoimapula on osin seurausta teknisestä velasta, jota aiemmissa ohjelmistokehityshankkeissa on otettu.
Vanhojen hankkeiden ohjelmistojen sisäinen laatu on heikentynyt niin, että suora jatkokehitys ei ole mahdollista. Aika menee arkkitehtuurin ja kooditason rakenteellisten ongelmien korjaamiseen tai umpikujaan joutuneen ohjelmiston täydelliseen uudelleen kirjoittamiseen, ei varsinaiseen jatkokehitykseen.
Kestävää kehitystä myös digitaalisissa ratkaisuissa
Kestävä ohjelmistokehitys kulkee käsikkäin kehitystyön laadun kanssa, ja se nojaa vahvasti tekijöidensä vankkaan ammattitaitoon. Yksi näkökulma kestävään ohjelmistokehitykseen on, että ohjelmisto ei ole koskaan valmis. Tämä ei tarkoita ikuisuusprojektia, vaan sitä, että ohjelmisto rakennetaan pitkää käyttöikää ajatellen ja asiakkaan kehittyviin tarpeisiin soveltuvaksi. Näin ohjelmistoa voidaan kehittää eteenpäin tehokkaasti, kun jatkokehitystarvetta ilmenee.
Ohjelmistoille asetut vaatimukset voivat muuttua, vaikka sen perustoiminta-ajatus pysyisi samana. Erilaiset järjestelmäintegraatiot tai vaikkapa loppukäyttäjän käyttötapojen muutokset asettavat paineita kehitykselle. Hyvänä esimerkkinä monien ohjelmistojen käyttö on siirtynyt kuin huomaamatta desktop-laitteilta mobiiliin.
Vaaditaan kykyä ja kokemusta ennakoida tulevaisuutta, kun palvelun ensimmäistä versiota aletaan suunnitella. Ohjelmistoprojektissa asiantunteva kumppani miettii yksityiskohdat siten, että kehitettävä palvelu toimii pitkään, palvelua pystytään skaalaamaan tarvittaessa ja sen jatkokehittäminen on helposti mahdollista.
Kestävä kehittäminen ei ole hidasta
Usein asiakasvaatimukset muuttuvat siten, että palvelun alkuperäinen arkkitehtuuri ei enää suoraan tue muuttuneita vaatimuksia. Tällöin täytyy olla näkemystä ja rohkeutta muuttaa ohjelmiston arkkitehtuuria ja suunnittelun lähtökohtia, vaikka se tarkoittaisi hieman suurempaa työmäärää. Suunnitteluvelan ottaminen tässä kohtaa johtaa yleensä suurempiin kustannuksiin palvelun myöhemmässä elinkaaressa.
Osaava kumppani uskaltaa myös kertoa rehellisesti, miksi oikotiet eivät ole kannattava vaihtoehto pitkällä aikavälillä. Kestävä ohjelmistokehitys ei kuitenkaan ole synonyymi hitaudelle. Kestävät menetelmät ja korkealaatuinen ketterä kehitys toimivat hyvin yhteen. Kun koko hanke on suunniteltu kestävän ohjelmistokehityksen ehdoilla, voidaan kehittää ohjelmistoa sopivan kokoisissa erissä “Minimum Viable Product” -tyyppisesti. Tällöin ohjelmisto on aina valmis ja toimii sille kulloinkin asetettujen tavoitteiden mukaisesti.
Kun hanke on suunniteltu kestävän ohjelmistokehityksen ehdoilla, vältytään massiivisen ja uuvuttavan ohjelmistoprojektin suolta. Kehitys etenee suunnitellusti ja ennakoitavasti vaiheesta toiseen ilman resursseihin liittyviä yllätyksiä. Kestävät ratkaisut eivät ole ohjelmistokehityksen menoerä, vaan investointi ohjelmiston koko elinkaaren ajaksi.
Aki Haapamäki
senior software engineer
Monad Oy