tasapaino
29.10.2018 Petri Tuomaala Tuotekehitys

Teknologia ja tuotekehityksen ketteryys

Prosessi Teknologia

JavaScript-kehyksiä syntyy joka päivälle uusia ja ne, mihin niissä päätät panostaa, ovat muuttunut yön aikana vanhanaikaisiksi. Pilvessä ollaan, vaikkei sille välttämättä ole perusteita ja ilman palvelintakin pitäisi pärjätä. Tekoäly on valtaamassa maailmaa terminaattorin tavoin. Analytiikan ansiosta kaupassakin tietävät milloin laihdutuskuurini on taas pettänyt. Teknologisen kehityksen painaessa kaasua ja oikoessa mutkia, asiakkaat lähestyvät sinua kierrepalloilla laatukäsikirjoista ja tietoturvapolitiikoista. Tukkaani ei vienyt synnyinkaupunkini Raahen ikuinen tuuli vaan tasapainoilu näiden kahden maailman välillä.

Missä asiakkaan toimintatavat ja ohjelmistokehitys kohtaavat?

Alan konferensseja vähintäänkin aktiivisesti seuraavana tuntuu, että ohjelmistokehitys on mennyt laadukkaan tekemisen sijaan trendikeskeiseksi. Valitaan tekniikka ja teknologiat, jotka ovat tänään pinnalla, sen enempää miettimättä tuotteen elinkaarta tai sitä, minkä ongelman ne edes ratkaisevat. Aina välillä se asiakaskin tuppaa sitten unohtumaan sinne seksikkään ja uuden käyttöliittymäteknologian taakse.

Toisaalta myös asiakkaan prosesseissa on parannettavaa. Ohjelmistoja ei hankita enää samalla tavalla kuin kymmenen vuotta sitten. Vincit on julkaissut aiheesta hyvän ohjelmistokehityksen ostajan pikaoppaan, johon kannustan kaikkia tutustumaan. Millä asiakkaan toimintatavat ja teknologisen kehityksen saisi sitten kohtaaman? Tämä kysymys on vienyt sinne jännän äärelle ja takaisin. Onneksi nuorimmaiseni on vielä niin pieni, että valtaa öisin paikkani sängyssä, joten tähän kysymykseen on ollut hyvin aikaa hakea vastausta.

No miten ne teknologiat sitten tähän liittyvät?

Jo se, että asiakas saa tuotteen käytettäviksi heti hankkeen alussa vaatii tuotekehitysprosessilta ketteryyttä. Tuotekehitysprosessien tulee olla pitkälti automatisoituja aina ympäristön luonnista, testaukseen, paketointiin ja jakeluun asti. Kokeilukulttuuri mahdollistaa myös eriasteiset teknologiakokeilut. Niiden kanssa ei olla loukussa seuraava kymmentä vuotta vaan toimivuutta testataan samalla tavalla kuin haetaan vastauksia asiakkaan käyttötapauksiin. 

Kaiken automatisointi aiheuttaa kuin puolivahingossa myös dokumentoinnin. Kun prosessit on vakioitu ja automatisoitu, laatukäsikirjankin ylläpitäminen on helpompaa. Haastavin vaihe alkaa kuitenkin, kun asiakkaan kanssa on löydetty tuotteelle oikea suunta. Tällöin teknologiavalintojen, arkkitehtuurin, ei-toiminnallisten vaatimusten, tietoturvan, integroitavuuden, testattavuuden jne. tulee olla yhtälailla tuotetta ja prosesseja tukevia kuin aina ennenkin. Eli perusinsinöörityö tuotekehityksestä ei ole kadonnut mihinkään. Nykyään se on vain helppo unohtaa.

Toimittajan puolella kokeilupohjaisella toimintamallilla on vaikutusta muihinkin prosesseihin kuin vain tuotekehitykseen. Myynnin ja markkinoinnin prosesseja tulee muuttaa siihen suuntaan, että ne tunnistavat tällaisia tilanteita. Vastaavasti tuotteen tulisi tuottaa myynnille ja markkinoinnille automatisaatiota, metriikoita ja analytiikkaa. Tähän aihealueeseen palaamme vielä.

Prosessit lähemmäs toisiaan

Omia ja asiakkaan prosesseja tulee yrittää mukauttaa niin, että ne mahdollistavat niiden lähestymisen. Mitä aiemmin asiakkaalle saadaan kokeiltava tuote tai sen osa-alue käyttöön, sitä aiemmin saadaan palautetta. Toimittaja taas pääsee kokeilemaan teknologioita ja niiden toimivuutta vapaammin, koska ollaan vasta hakemassa suuntaa projektille. Tässä vaiheessa tehty virhe teknologiavalinnoissa on vielä helppo korjata. Joku voisi väittää, että näinhän ketterä kehitys on aina toiminut. No tavallaan kyllä, mutta yleensä toimittajan päästessä mukaan, kehityshanke on jo määritelty, kilpailutettu & suunniteltu. Ja homma alkaa taas melkein alusta, kun vaatimuksia aletaan käymään oikeasti läpi.

Väittäisin, että synergiaedut alkavat moninkertaistua, jos mahdollinen toimittaja pääsee mukaan jo määrittelyvaiheessa. WinWin molemmille? No ei aivan niinkään. Asiakas joutuu sitoutumaan hankkeeseen paljon aiempaa enemmän. Ei riitä, että vain asiakkaan edustaja on mukana hankkeessa, vaan tulevat loppukäyttäjätkin pitäisi saada mukaan. Erityisesti julkisella puolella voi olla haasteita toimia tällä tyylillä, koska kehityshankkeet tulevat vain oikean työnkuvan ohessa. Isoissa hankkeissa vastaan tulee yleensä aina eteen myös kilpailutus.