Ohjelmistokehityksen uusi pullonkaula ei ole koodi
Mitä tapahtuu, kun ohjelmistokehittäjät ehtivät tehdä kaiken, mitä heiltä pyydetään, mutta kukaan ei ehdi kertoa, mitä pitäisi tehdä seuraavaksi?
Edutenin pedagogiikkajohtaja Einari Kurvinen nosti Prochat-podcastissa esiin kiinnostavan havainnon. Heidän kehittäjänsä pystyvät toteuttamaan käytännössä kaiken, mitä heiltä pyydetään. Haaste onkin siirtynyt muualle: liiketoiminnan pitäisi pystyä määrittelemään uusia tarpeita riittävän nopeasti.
Tilanne kuulostaa aika hyvältä ongelmalta. Kehittäjillä on kapasiteettia, eikä toteutuksia tarvitse odottaa kuukausikaupalla.
Mutta mitä hyötyä nopeasta kehityksestä on, jos kukaan ei ehdi päättää, mitä seuraavaksi pitäisi rakentaa?
Tekoäly muuttaa ohjelmistokehityksen vauhtia, mutta samalla se paljastaa organisaatioista pullonkauloja, jotka ovat aiemmin jääneet koodaamiseen kuluvan ajan varjoon.
CTO näkökulmasta kysymys ei olekaan enää pelkästään siitä, miten kehittäjien tuottavuutta kasvatetaan. Yhä tärkeämpää on, miten koko organisaatio pystyy hyödyntämään kasvaneen toteutuskapasiteetin.
Ohjelmistokehityksen pullonkaula ei välttämättä ole enää koodi
Ohjelmistokehityksessä on totuttu ajattelemaan, että kehittäjien aika on yksi niukimmista resursseista.
Backlogissa on enemmän tehtäviä kuin tiimi ehtii toteuttaa, ja priorisoinnissa päätetään, mitkä ominaisuudet tehdään nyt ja mitkä joskus myöhemmin.
Tekoälyavusteinen ohjelmistokehitys voi muuttaa tätä asetelmaa merkittävästi.
Kun AI-agentit auttavat toteutuksessa, testauksessa ja refaktoroinnissa, kehittäjät voivat saada aiempaa enemmän aikaan samassa ajassa. Se ei kuitenkaan tarkoita, että uudet ominaisuudet päätyisivät käyttäjille samassa suhteessa nopeammin.
Kuvitellaan, että ominaisuuden toteuttamiseen kului aiemmin kymmenen päivää ja tekoälyn avulla siihen kuluu enää yksi. Jos tarpeen selvittämiseen, päätöksentekoon ja hyväksyntään menee edelleen kaksi viikkoa, kokonaisuuden läpimenoaika ei muutu läheskään yhtä dramaattisesti.
Pullonkaula vain siirtyy seuraavaan vaiheeseen.
Nopeampi koodaus ei automaattisesti tarkoita nopeampaa ohjelmistokehitystä.
Siksi kehitystiimin tehokkuutta pitäisi tarkastella yhä enemmän sen perusteella, kuinka nopeasti tunnistettu tarve muuttuu käyttäjälle tai liiketoiminnalle tuotetuksi arvoksi.
Ei vain sen perusteella, kuinka monta tehtävää saadaan valmiiksi.
Kun määrittely ei pysy toteutuksen perässä
Pullonkaulan siirtyminen ei välttämättä näy heti kehitystiimin mittareissa. Kehittäjät saattavat sulkea tikettejä aiempaa nopeammin ja koodia syntyy enemmän kuin koskaan.
Samaan aikaan voi kuitenkin tapahtua jotain ongelmallista.
Kehittäjät alkavat odottaa päätöksiä. Backlogista poimitaan tehtäviä, joiden tavoitteet tai hyväksymiskriteerit ovat epäselviä. Valmiit ominaisuudet jäävät odottamaan liiketoiminnan hyväksyntää tai käyttöönottoa.
Pahimmillaan tiimi alkaa tehdä sitä, mikä on helppo määritellä, eikä sitä, mikä olisi liiketoiminnalle arvokkainta.
Sisäisiä työkaluja kehitetään ja teknistä velkaa vähennetään, koska niihin voidaan tarttua ilman uusia päätöksiä. Nämä voivat itsessään olla hyvinkin arvokkaita töitä, mutta ongelma syntyy, jos niiden pariin päädytään vain siksi, ettei tärkeämpiä asiakastarpeita ole ehditty selvittää.
Tässä on aika olennainen ero tekemisen ja vaikuttavuuden välillä.
Tiimi voi olla erittäin tuottava, vaikka sen tekeminen ei edistäisi liiketoiminnan tärkeimpiä tavoitteita.
CTO:n kannattaakin kysyä, onko kehitystiimin suurin este enää toteutuskapasiteetti vai se, ettei toteutettavia asioita pystytä valmistelemaan riittävän nopeasti.
Miten kehitysprosessin pitäisi muuttua?
Jos tekoäly nopeuttaa toteutusta merkittävästi, myös kehitysprosessin muiden vaiheiden pitää kehittyä.
Se ei tarkoita sitä, että jokaista ominaisuutta varten tarvittaisiin entistä pidempi vaatimusmäärittelydokumentti. Pikemminkin tarvitaan parempia tapoja selvittää, mitä kannattaa rakentaa, ja varmistaa, että toteutus ratkaisee oikean ongelman.
1. Määrittelystä tulee entistä tärkeämpi osa kehitystyötä
Aiemmin epätarkka määrittely saattoi johtaa pitkään keskusteluun kehittäjän ja tuoteomistajan välillä ennen toteutusta. Nyt tekoälyagentti voi tuottaa teknisesti toimivan ratkaisun nopeasti myös puutteellisen määrittelyn pohjalta.
Se ei kuitenkaan tarkoita, että ratkaisu olisi oikea.
Jos agentille annetaan epäselvä tehtävä, lopputuloksena voi olla täysin toimivaa koodia, joka ratkaisee väärän ongelman.
Siksi kehitystehtävässä pitäisi olla selvillä ainakin kolme asiaa: mitä halutaan saavuttaa, miksi se on tärkeää ja mistä tiedetään, että lopputulos vastaa tarvetta.
Tekoälyä voi hyödyntää myös itse määrittelyssä. Sen avulla voidaan esimerkiksi rakentaa nopeasti prototyyppejä, vertailla vaihtoehtoja ja tunnistaa puuttuvia vaatimuksia jo ennen varsinaista toteutusta.
Kun käyttäjä näkee toimivan luonnoksen pelkän kirjallisen kuvauksen sijaan, väärinkäsitykset voivat paljastua huomattavasti aikaisemmin.
Tärkeintä ei siis ole kirjoittaa enemmän speksejä, vaan saada oikeat ihmiset tekemään oikeita päätöksiä aikaisemmin.
2. AI-agentti tarvitsee muutakin kuin tehtävänannon
Määrittelyn lisäksi merkitystä on sillä, kuinka hyvin tekoäly ymmärtää ympäristön, jossa se työskentelee.
AI-agentti voi kirjoittaa toimivaa koodia ymmärtämättä, miksi järjestelmä on alun perin rakennettu tietyllä tavalla.
Se saattaa esimerkiksi muuttaa palveluiden välistä toimintalogiikkaa ymmärtämättä, että nykyinen ratkaisu perustuu tietoturvaan, suorituskykyyn tai liiketoiminnan erityisvaatimukseen.
Siksi ajantasaisen dokumentaation arvo kasvaa.
Arkkitehtuuripäätökset, rajapintojen riippuvuudet, järjestelmien vastuut ja tekniset reunaehdot pitää olla tavalla tai toisella sekä kehittäjien että agenttien saatavilla.
Mitä enemmän toteutusta automatisoidaan, sitä tärkeämpää on varmistaa, että agentti toimii oikean kontekstin pohjalta.
Hyväkään malli ei voi huomioida sellaista tietoa, jota sille ei ole annettu.
3. Kaikkea koodia ei kannata katselmoida samalla tavalla
Kun koodia syntyy nopeammin, myös katselmoinnin ja laadunvarmistuksen pitää mukautua.
Jos jokainen tekoälyn tuottama muutos käydään läpi samalla tavalla kuin ennen, pullonkaula saattaa vain siirtyä koodin kirjoittamisesta sen tarkistamiseen.
Ratkaisu ei kuitenkaan ole ihmiskatselmoinnin poistaminen, vaan sen kohdistaminen sinne, missä ihmisen asiantuntemuksesta on eniten hyötyä.
Pienen käyttöliittymämuutoksen ja maksuliikenteeseen vaikuttavan tietokantamuutoksen riskit ovat aivan eri tasolla.
Katselmoinnin perusteellisuus pitäisi siksi suhteuttaa muutoksen vaikutuksiin, monimutkaisuuteen ja mahdollisiin riskeihin.
Tekoäly voi auttaa löytämään virheitä, tarkistamaan muutoksia ja tunnistamaan mahdollisia ongelmia. Automaattiset testit voivat puolestaan varmistaa, että järjestelmä käyttäytyy odotetusti.
Kriittisissä muutoksissa tarvitaan kuitenkin edelleen ihmistä, joka ymmärtää kokonaisuuden ja kantaa vastuun lopputuloksesta.
Tavoitteena ei ole vähentää laadunvarmistusta, vaan käyttää asiantuntijoiden aika siellä, missä sillä on suurin vaikutus.
4. Valmis koodi ei vielä tarkoita toimitettua arvoa
Vaikka ominaisuus valmistuisi päivässä, siitä ei synny liiketoimintahyötyä ennen kuin se päätyy käyttöön.
Jos julkaisu vaatii useita hyväksyntäkierroksia, asiakastuki ei tiedä muutoksista tai käyttäjien perehdytys laahaa jäljessä, nopeutunut toteutus ei välttämättä näy asiakkaalle asti.
Siksi myös käyttöönottoa, viestintää ja julkaisukäytäntöjä kannattaa tarkastella osana samaa kokonaisuutta.
Automaattinen julkaisuputki, ominaisuusliput ja jatkuvasti päivittyvä dokumentaatio voivat auttaa teknisessä toteutuksessa. Yhtä tärkeää on kuitenkin varmistaa, että liiketoiminta ja käyttäjät pysyvät muutosten mukana.
Ohjelmistokehitys ei ole valmis silloin, kun koodi on valmis. Se on onnistunut silloin, kun ratkaisu tuottaa arvoa.
Mistä hyvän ohjelmistokonsultin arvo syntyy jatkossa?
Tekoälyn vaikutus ei rajoitu yritysten sisäisiin kehitystiimeihin. Se muuttaa myös sitä, millaista osaamista ohjelmistokumppanilta kannattaa ostaa.
Jos konsultin tärkein arvo on ollut se, että hän pystyy kirjoittamaan koodia nopeasti, tekoäly muuttaa kilpailuasetelmaa aika merkittävästi.
Asiakas ei välttämättä tarvitse enää lisää käsiä pelkkään toteuttamiseen. Sen sijaan hän saattaa tarvita osaamista siihen, mitä ylipäätään kannattaa rakentaa.
Kuvitellaan, että asiakas pyytää konsultilta uutta raportointinäkymää.
Nopea toteuttaja voi rakentaa näkymän muutamassa päivässä. Hyvä konsultti pysähtyy kuitenkin ensin kysymään, mihin ongelmaan raportointia tarvitaan.
Jos tavoitteena on tunnistaa poikkeamat liiketoiminnassa mahdollisimman aikaisin, ongelma saattaisi ratketa yksinkertaisella automaattisella hälytyksellä. Kokonaista raportointinäkymää ei ehkä tarvittaisi lainkaan.
Tällöin konsultin suurin arvo ei ole nopea toteutus, vaan se, että asiakas välttyy rakentamasta jotain tarpeetonta.
Sama pätee riskien tunnistamiseen. Kokeneen kehittäjän pitää pystyä arvioimaan, mitä muutoksesta seuraa, miten se vaikuttaa muihin järjestelmiin ja mitä liiketoiminnan kannalta kriittistä siinä pitäisi huomioida.
Tekoäly voi auttaa analysoimaan näitä asioita, mutta kokonaisuuden ymmärtäminen vaatii edelleen asiantuntemusta asiakkaan liiketoiminnasta.
Tämän vuoksi ohjelmistokumppania kannattaa arvioida muullakin kuin toteutusnopeudella tai tuntihinnalla.
Hyvä kumppani osaa haastaa asiakkaan ajatuksia, tehdä perusteltuja teknisiä ratkaisuja ja tunnistaa ongelmia, joita asiakas ei välttämättä itse osaa ennakoida.
Kun toteuttaminen nopeutuu, oikeiden päätösten arvo kasvaa.
Ja joskus arvokkain asia, jonka konsultti voi asiakkaalle tehdä, on kertoa, ettei jotain kannata rakentaa ollenkaan.
Seuraava tuottavuusloikka ei välttämättä synny koodaamisessa
Tekoälyn vaikutusta ohjelmistokehitykseen on helppo tarkastella sen kautta, kuinka paljon nopeammin kehittäjät saavat asioita valmiiksi.
Mutta jos toteutus ei enää ole hitain vaihe, sen jatkuva nopeuttaminen tuottaa yhä rajallisempia hyötyjä.
Silloin huomio pitäisi siirtää siihen, miten tarpeet tunnistetaan, päätökset tehdään ja ratkaisut saadaan tuotantoon asti.
Edutenin esimerkki osoittaa hyvin, millaisia uusia kysymyksiä ohjelmistokehityksen nopeutuminen voi nostaa esiin.
Kun kehittäjien kapasiteetti ei enää rajoita tekemistä entiseen tapaan, liiketoiminnan pitää pystyä hyödyntämään sitä.
Ja juuri siinä voi piillä seuraava suuri tuottavuusloikka.’
Kuuntele lisää Prochat-podcastissa
Prochat-podcastissa keskustelimme Edutenin pedagogiikkajohtaja Einari Kurvisen kanssa siitä, miten tekoäly muuttaa ohjelmistokehitystä, oppimisteknologiaa ja kehitystiimien toimintaa. Keskustelussa Einari avaa, millaisia muutoksia tekoäly on tuonut heidän kehitystyöhönsä ja miksi nopeampi toteutus ei yksin ratkaise kaikkea.
Katso koko keskustelu YouTubessa tai kuuntele Spotifyssa →
Eduten on suomalainen oppimisteknologiayritys, jonka Turun yliopiston tutkimukseen pohjautuvaa matematiikan oppimisalustaa käytetään yli 50 maassa.