Maailmassa, jossa ominaisuuden voi suunnitella, ohjelmoida ja julkaista nopeammin kuin koskaan, kehityksen nopeus ei enää ole suurin ongelma. Ongelma on päätös siitä, mitä oikeastaan kannattaa rakentaa.
On vaihe lähes jokaisen järjestelmän elämässä, kun ominaisuuslista alkaa elää omaa elämäänsä.
"Asiakas pyysi tätä."
"Kilpailija tekee niin."
"Sen ei kai pitäisi olla vaikeaa."
"Koska meillä on jo tämä moduuli, lisätkäämme vielä..."
"AI hoitaa sen nopeasti."
Ja yhtäkkiä uusi ominaisuus päätyy backlogiin. Sitten toinen. Ja taas toinen. Muutaman vuoden jälkeen yrityksellä on sovellus, joka osaa lähes kaiken. Mutta käyttäjän on yhä vaikeampaa löytää se, mitä hän oikeasti tarvitsee.
Tämä ei ole pelkästään UX-ongelma. Tämä on liiketoimintaongelma.
Milloin enemmän ominaisuuksia ei enää tarkoita parempaa tuotetta
Ohjelmistokehitys on pitkään noudattanut melko yksinkertaista logiikkaa: jos käyttäjät tarvitsevat uusia mahdollisuuksia, lisäämme uusia ominaisuuksia. Kuulostaa järkevältä.
Ongelma alkaa, kun tuotteen kehitys mitataan toimitettujen ominaisuuksien määrällä. Silloin tiimi alkaa optimoida ei käyttäjän arvon, vaan niiden asioiden määrän mukaan, jotka se on "toimit- tanut".
Tällöin syntyy niin kutsuttu Feature Factory — organisaatio, joka tuottaa jatkuvasti uusia toiminnallisuuksia, mutta ei välttämättä mittaa, ratkaisevatko ne asiakkaiden ongelmia.
Ilmiö ei ole uusi. Uutta on se vauhti, jolla sitä voi tänään tapahtua.
AI lyhentää merkittävästi matkaa ideasta toimivaan prototyyppiin. Atlassian kuvailee muutosta suoraan: kehitysagenttien ansiosta tie siitä, että "tiedämme mitä haluamme rakentaa", toimivaan prototyyppiin voi lyhentyä viikoista tunteihin.
Se on valtava mahdollisuus. Mutta myös ansa.
Sillä jos rakentaminen käy halvemmaksi ja nopeammaksi, helpommin aletaan rakentaa myös asioita, joita kukaan ei aiemmin olisi uskaltanut pyytää.
"Koska voimme, tehdään se"
Se on yksi kalleimmista lauseista IT-projekteissa. Ei siksi, että jokainen lisäominaisuus maksaisi omaisuuden. Ongelma on se, että ominaisuus ei lopeta elinkaartaan julkaisuhetkeen.
Jokaista uutta moduulia on myöhemmin ylläpidettävä. Sitä pitää testata. Se on otettava huomioon seuraavissa muutoksissa. Sen toimintaa pitää dokumentoida. Virheet on korjattava. Käyttäjiä on koulutettava. Se on huomioitava UX:ssa. Sen turvallisuudesta on huolehdittava. On tarkistettava, etteivät seuraavat muutokset riko jotain.
Siksi ominaisuuden kustannus ei ole vain sen rakentamisen kustannus. Se on myös sen tulevan olemassaolon kustannus.
Ja juuri tätä kustannusta ei usein nähdä hetkellä, jolloin joku sanoo:
"Lisätään vielä tämä..."
Kallein ominaisuus voi olla se, jota kukaan ei käytä
Kuvitellaan yritys, joka kehittää B2B-hallintapaneelia.
Asiakkaat voivat tehdä tilauksia, tarkistaa ostohistorian, ladata dokumentteja ja ottaa yhteyttä account manageriin.
Syntyy idea laajennetusta raportointijärjestelmästä. Tiimi suunnittelee sen. Kehittäjät rakentavat sen. Syntyy kaavioita, suodattimia, vientitoimintoja, yhteenvetoja ja kymmeniä lisäparametreja. Ominaisuus julkaistaan.
Ja sitten käy ilmi, että suurin osa asiakkaista haluaa yksinkertaisesti tietää: kuinka paljon olen ostanut, mitä on matkalla ja mikä on hinta.
Muuta oletettiin. He eivät sitä tarvitse. Tämä on erittäin tärkeä ero.
Asiakas voi pyytää ominaisuutta. Se ei vielä tarkoita, että se ratkaisee hänen ongelmansa.
"Kilpailija tekee niin"
Se on toinen klassikko.
Yritys analysoi kilpailijaa. Näkee uuden moduulin.
Ja alkaa: "Meidän on oltava siinä mukana."
Mutta kilpailijalla voi olla täysin eri liiketoimintamalli, eri asiakassegmentti, eri myyntiprosessit ja eri tuotstrategia.
Ominaisuus, joka on järkevä yhdessä järjestelmässä, voi olla täysin tarpeeton toisessa.
Tämä on erityisen tärkeää räätälöidyissä projekteissa. Ei ole olemassa universaalia ominaisuuskatalogia, joka tekisi jokaisesta sovelluksesta hyvän.
Teollisuusvalmistajan järjestelmää ei pitäisi suunnitella samalla tavalla kuin koulutusyrityksen alustaa.
Myyjien CRM ei pitäisi toimia samalla tavalla kuin vakioasiakkaiden B2B-paneeli.
Premium-tuotteita myyvän verkkokaupan ostokokemuksen tulee olla täysin erilainen kuin hintavetoisen kaupan.
Ohjelmisto tulisi johtaa liiketoimintamallista, ei kilpailijan ominaisuuskatalogista.
AI muuttaa tätä todella paljon
Siksi tämä aihe on erityisen kiinnostava juuri nyt.
Vielä muutama vuosi sitten idea uudesta ominaisuudesta joutui monen vaiheen läpi ennen kuin käyttäjä näki sen.
Analyysi.
Suunnittelu.
UX.
Kehitys.
Testaus.
Julkaisu.
Nykypäivänä osa näistä vaiheista voidaan merkittävästi nopeuttaa AI:n avulla. Voimme rakentaa prototyypin nopeammin. Valmistella käyttöliittymän nopeammin. Kirjoittaa koodin nopeammin. Generoida testit nopeammin. Analysoida datan nopeammin.
Ja siksi itse kehityksen nopeus ei enää yksinään ole riittävä kilpailuetu.
Jos kuka tahansa voi rakentaa jotain nopeammin, etu on sillä, joka osaa paremmin valita, mitä rakentaa.
Atlassian huomauttaa tuotesuunnittelun tulevaisuutta käsittelevässä raportissaan tästä paradoksista: AI lisää työn nopeutta, mutta pelkkä nopeuden lisääntyminen ei takaa parempia tuotteita. Samalla 89 % Atlassianin kyselyn johtajista raportoi nopeuden kasvaneen AI:n ansiosta, kun vain 6 % koki pystyvänsä selvästi määrittämään AI:n ROI:n organisaation mittakaavassa.
Se havainnollistaa eroa tehdä nopeammin ja saavuttaa parempi tulos välillä.
Ensin ongelma. Vasta sitten ominaisuus
Hyvän tuoteprosessin tulisi alkaa kysymyksellä: Mitä ongelmaa yritämme ratkaista?
Ei: "Mitä ominaisuutta meidän pitäisi lisätä?"
Vaikuttaa pieneltä erolta. Käytännössä se muuttaa kaiken.
Jos asiakas sanoo: "Tarvitsemme mobiilisovelluksen",
on syytä kysyä: Miksi?
Ehkä hän todella tarvitsee sovelluksen. Mutta ehkä ongelma on epämukava pääsy paneeliin puhelimella. Ehkä riittää hyvin suunniteltu responsiivinen käyttöliittymä. Ehkä PWA. Ehkä mobiilimoduuli vain yhdelle prosessille. Tai ehkä sovellus on tarpeen, mutta aivan eri syistä kuin asiakas aluksi kuvitteli.
Sama pätee ominaisuuksiin.
"Tarvitsemme automaattisia raportteja." — Miksi?
"Koska myyjät tuhlaavat aikaa." — Mihin?
"Tietojen kopioimiseen järjestelmästä."
Silloin saattaa käydä ilmi, että ongelma ei ole raportin puute. Ongelma on integraation puute.
Hyvä analyysi voi säästää kuukausia kehitystyötä.
Joskus paras ominaisuus on sen puuttuminen
Se kuulostaa paradoksaaliselta, mutta juuri tällainen tulisi olla kokeneen teknologia- kumppanin rooli.
Ei pelkästään toteuttaa. Myös kyseenalaistaa oletukset, kun siihen on syy.
Jos asiakas tulee 20 kohdan ominaisuuslistalla, software house ei saa automaattisesti pitää sitä teknisenä speksinä hakatun kiveen.
Sen tulisi kysyä: Mitkä näistä ominaisuuksista ratkaisevat reaalisen ongelman? Mitkä ovat kriittisiä? Mitkä lisäävät myyntiä? Mitkä lyhentävät työtä? Mitkä parantavat asiakaspalvelua? Mitkä ovat lakisääteisiä tai operatiivisesti välttämättömiä? Mitkä ovat vain "kiva lisä"?
Ja ennen kaikkea: mistä tiedämme, että ominaisuus on ollut menestys?
Ilman tätä viimeistä kysymystä on helppo luoda tuote, joka kasvaa jatkuvasti, mutta ei koskaan ole tiedossa, paraneeko se todella.
Tuotteen pitää osata sanoa "ei"
Hyvässä product developmentissa yhtä tärkeä kuin rakennettavien asioiden lista on lista asioista, joita emme rakenna. Se vaatii rohkeutta.
On helppo sanoa: "Kyllä, teemme sen."
Vaikeampaa on sanoa: "Nykyisen tiedon perusteella emme vielä näe syytä siihen, että tästä kannattaisi maksaa."
Vielä vaikeampaa on sanoa se asiakkaalle, joka juuri tuli valmiin idean kanssa.
Mutta juuri silloin alkaa aidosti kumppanuuteen perustuva yhteistyö.
Software house ei saisi olla vain tiimi, joka muuttaa käskyt koodiksi. Sen tulisi auttaa asiakasta tekemään teknologiapäätöksiä.
Joskus se tarkoittaa ominaisuuden suunnittelua.
Joskus sen yksinkertaistamista.
Joskus sen korvaamista toisella ratkaisulla.
Ja joskus kokonaan luopumista ideasta.
Miten tunnistaa ominaisuus, jota et todennäköisesti tarvitse?
Yhtä taikakoetta ei ole, mutta muutama kysymys voi nopeasti viilentää innostusta.
Kuka tarkalleen hyödyntää tätä?
Jos vastaus on "kaikki", kannattaa täsmentää.
Mitä ongelmaa ratkaistaan?
Jos vastaus on "se on kätevämpi", ongelma tarvitsee todennäköisesti lisäanalyysiä.
Kuinka usein käyttäjä tätä käyttää?
Kerran vuodessa? Kerran kuussa? Päivittäin?
Onko yksinkertaisempi tapa ratkaista sama ongelma?
Tämä kysymys on erityisen tärkeä.
Miten mittaamme vaikutuksen?
Lisääkö se myyntiä? Vähentääkö se työtä? Lyhentääkö se prosessia? Vähentääkö se virheitä? Lisääkö se reten- tiota?
Mitä tapahtuu, jos emme rakenna tätä ominaisuutta?
Jos vastaus on "eikä oikeastaan mitään", olemme ehkä löytäneet ominaisuuden, jota ei tarvitse rakentaa.
Jokainen käyttäjäpyyntö ei kuulu backlogiin
Myös tämä on tärkeä asennemuut- os.
Käyttäjäpalautteet ovat korvaamattomia. Mutta palaute ei ole automaattisesti tuotteen speksaus.
Käyttäjä kertoo ongelmastaan oman kokemuksensa kautta.
Hän voi sanoa: "Tarvitsen painikkeen X."
Tuotetiimin rooli ei ole tehdä nappia X ajattelematta.
Tiimin tehtävä on ymmärtää: miksi käyttäjä sitä tarvitsee.
Vasta sitten voidaan päättää, onko paras ratkaisu todella painike X.
Se voi olla automaatio.
Se voi olla integraatio.
Se voi olla prosessin muutos.
Se voi olla parempi käyttöliittymä.
Se voi olla käyttäjän koulutus.
Ja joskus se todella on uusi ominaisuus.
Tämä on ero feature deliveryn ja product developmentin välillä.
Data voi myös sanoa: "poistetaan tämä"
Tuotteen kehitys ei saa loppua lisäämiseen.
On myös tarkasteltava olemassa olevaa.
Mitkä ominaisuudet ovat käytössä?
Mitkä ovat jääneet huomiotta?
Missä käyttäjät putoavat pois?
Mitkä prosessit vievät eniten aikaa?
Mitkä elementit aiheuttavat eniten tukipyynnöjä?
Mitkä ominaisuudet lisäävät konversiota?
Ja mitkä vain mutkistavat käyttöliittymää?
Joskus paras kehitysprojekti ei ole uuden moduulin lisääminen. Se on kolmen tarpeettoman poistaminen. Se voi parantaa UX:ää enemmän kuin toinen kuukausi kehitystä.
AI voi auttaa myös tässä
Mielenkiintoista on, että AI ei ole vain ominaisuuksien luomista varten.
Se voi myös auttaa analysoimaan, ovatko ominaisuudet järkeviä.
Se voi analysoida käyttäjäpalautetta.
Ryhmätä ilmoituksia.
Tunnistaa toistuvia ongelmia.
Analysoida tukidataa.
Yhteenvetää asiakaspalavereita.
Auttaa tiimiä vertailemaan hypoteeseja.
Valmistella ratkaisuvaihtoehtoja.
Tukea käyttäjäkäyttäytymisen analyysiä.
Eli paradoksaalisesti AI:n parhain käyttö product developmentissa voi joskus olla se, että sen avulla löydämme nopeammin, ettei meidän pitäisi rakentaa ominaisuutta.
Web24: ensin kysymme "miksi?"
Jokainen ohjelmistoprojekti alkaa tarpeesta.
Joskus asiakas tietää tarkalleen, mitä tarvitsee.
Joskus hänellä on valmis spesifikaatio.
Joskus hän tulee vain ongelman kanssa: "Tämä prosessi vie meille kolme tuntia päivässä."
Ja se on erinomainen lähtökohta.
Silloin voimme miettiä, miten parhaiten ratkaista ongelma, ei niinkään kuinka koodata esitetty ratkaisu.
Tämä erottaa räätälöidyn ohjelmiston rakentamisen komponenttipohjaisen tuotteen kasaamisesta.
Web24:ssa ei pyritä siihen, että jokaisessa sovelluksessa olisi mahdollisimman monta ominaisuutta.
Tavoitteena on, että sillä on ne ominaisuudet, joita kyseinen liiketoiminta todella tarvitsee.
Siksi kaksi samankaltaista järjestelmää voi näyttää ja toimia täysin eri tavalla.
Koska prosessit eroavat.
Koska käyttäjät eroavat.
Koska tavoitteet eroavat.
Koska myyntitavat eroavat.
Koska asiakaspalvelu eroaa.
Ja koska ongelma, jonka ohjelmiston pitää ratkaista, on erilainen.
Kallein backlog on se, jota kukaan ei kyseenalaista
AI-maailmassa voimme astua hyvin mielenkiintoiseen kehitysvaiheeseen ohjelmistojen teossa.
Teknologia osaa yhä paremmin vastata kysymykseen: "Miten tämän rakennetaan?"
Ihmisen on entistä paremmin vastattava kysymykseen: "Pitäisikö meidän ylipäätään rakentaa tämä?"
Tämä voi olla yksi tärkeimmistä muutoksista ohjelmistotuotannossa.
Sillä jos seuraavan ominaisuuden kustannus ja toteutusaika laskevat, houkutus lisätä niitä kasvaa.
Ja samassa suhteessa kasvaa Product Discoveryn, UX:n, datanalyysin, käyttäjäkeskustelujen ja strategisen tuotepäätöksenteon merkitys. Gartner varoittaa, että AI:n vauhdittama nopea tuotekehitys voi johtaa muun muassa strategisen linjauksen ongelmiin ja teknisen velan kasvuun, jos teknologinen tempo ei kulje käsi kädessä tuotteen johtamisen kanssa.
Siksi tulevaisuus ei kuulu vain yrityksille, jotka osaavat rakentaa nopeammin. Se kuuluu myös niille, jotka osaavat paremmin valita, mitä rakentaa.
Sillä joskus paras tekninen päätös ei ole: "Tehdään vielä yksi ominaisuus."
Vaan: "Selvitämme ensin, tarvitsemmeko sitä todella."
