Kehitettävien asioiden syöttö tuotekehitystiimille muistuttaa tietynkaltaista suppiloa. Suppilon kapea pää lähempänä tuotekehitystiimiä sisältää tuotebacklogin, ja on pääasiassa tuoteomistajan (Product Owner) vastuulla. Se suppilon leveämpi pää, joka sisältää varhaisemmassa kehitysvaiheessa olevia ideoita, onkin mielenkiintoinen asia.

Tyypillisesti ideoiden alkukehityksestä vastaa organisaatioissa tuotepäälliköt. Suppilon leveä, paljon erilaisia ideoita sisältävä osa, on siis tuotepäälliköllä. Suppilon loppupää, tarkasti speksattuja käyttäjätarinoita hyvässä prioriteettijärjestyksessä sisältävä tuotebacklog, on tuoteomistajien vastuulla.

Ideoita pitää testata

Ideaalitilanteessa vaatimuksista ja ideoista kyettäisiin valitsemaan jatkokehitykseen kaikkein arvokkaimmat. Siten ideoita kehittävä tiimi pystyisi testaamaan ideoiden oletukset mahdollisimman kevyellä prototypoinnilla tai vastaavalla, ja iteroimaan vaatimusta eteenpäin tarpeeksi monta kertaa. Lopulta saavutetaan varmuus siitä, että

a) kyseinen vaatimus kannattaa toteuttaa,

b) pystytään arvioimaan kehitystyön takaisinmaksuaika riittävällä tarkkuudella ja

c) vaatimus on määritelty ”oikein” ja voidaan siis antaa eteenpäin tuotekehitykseen, joka tekee sitten tuotantototeutuksen.

Miksi ideoita hylätään niin harvoin?

Aärimmäisen harvoin tapahtuu sitä, että jo esiselvitykseen otettu idea tai vaatimus ”hyllytetään” tai hylätään. Koska ideoita ja vaatimuksia on paljon enemmän kuin mitä tuotekehitys pystyy toteuttamaan, ja tuotekehitystä syöttävä suppilo ”kapenee”, niin ideoita pitäisi olla esiselvityksen eri vaiheissa paljon enemmän kuin mitä suppilon loppupäästä syötetään tuotekehitykselle. Lääketeollisuushan toimii näin: koska lopulliset kliiniset testit maksavat järkyttävän paljon, kymmeniä tai jopa satoja miljoonia, sinne etenee vain muutama lääkekandidaatti. Mutta tutkimuksen alkupäässä lääkeyrityksen tutkimusosastolla saattaa olla satoja, jopa tuhansia eri lääkeainevaihtoehtoja. Joka tutkimusvaiheessa eteenpäin menee vain parhaat, ja 90 % kandidaateista hylätään.

Huonot ideat pitäisi päästää kärsimyksistään tarpeeksi ajoissa.

Minusta tuntuu, että ohjelmistokehityksessä ja teknologiateollisuudessa vastaavaa ei riittävässä määrin tehdä. Mistä tämä johtuu? Mahdollisia syitä on monia. Ehkä päätöksentekokriteerit ja testit eivät ole yhtä selvät kuin lääkekandidaateille. Ehkä ideoiden esikehitysprosessi ei ole yhtä hyvin määritelty. Saattaa olla myös niin, että ideoita kehittävät tahot ”rakastuvat” omiin ideoihinsa ja ovat kuuroja kritiikille. Ehkä palautteen hakeminen markkinoilta erilaisilla prototyypeillä on unohtunut kokonaan tai on aivan liian vähäistä.

Omalta tuotekehitysuraltakin muistan muutaman toteutuksen, joka meni aivan liian pitkälle ennen kuin havaittiin, että juu ei, ei tästä tulee takkia vaan kukkaro, ja asiakkaat eivät olekaan ominaisuudesta kiinnostuneita.

Kokeilukulttuuri ja roadmap-liukuhihna

Yksi ajatus, mikä voisi auttaa muistamaan että kaikkien ideoiden ei tarvitse edetä tuotantoon asti, on kokeilukulttuuri. Jos backlog-suppilon sisältö ajatellaankin kaksivaiheisena. Asiat, mitkä ovat ideavaiheessa, ovat roadmapilla. Asiat, mitkä on jo testattu ja joiden tekeminen on varmasti edessä, ovat backlogilla. Tällä tavalla, kahteen eri leiriin jaettuna, on helpompi ajatella että toisessa korissa on vielä epävarmat asiat, ja toisessa sellaiset joiden epävarmuuksia on riittävästi jo poistettu, ja ne ovat vain tekemistä vailla.

Backlogin kannattaa tällaisessa järjestelyssä olla aika lyhyt ja kevyt, vaikka noin 2 kuukauden työt. Roadmap voi olla paljon pidempi ja ulottua vuosien päähän. Roadmapia voikin ajatella tietynlaisena “liukuhihnana” joka kuljettaa ideoita tulevaisuudesta lähemmäs nykyhetkeä. Sopivassa ajankohdassa tuoteryhmä alkaa sitten tutkia, kannattaako idea toteuttaa ja millaisena.

Tässä järjestelyssä se “ideoiden hylkääminen” tapahtuu siinä vaiheessa kun asia roadmap-liukuhihnalta pitäisi siirtyä backlogille. Kun tarkka hylkäämisen ajanhetki on tiedossa, päätös on helpompi tehdä.

Karaise ja kitke uusia ideoita

Organisaatioiden kannattaisi tuotekehitystiimin toimintatapojen, devopsin ja toiminnan laadun lisäksi kohdistaa huomiota myös siihen prosessiin, millä ituvaiheessa olevia ideoita karaistaan ja kitketään huonot ajatukset valioyksilöiden seasta pois. Näin tuotekehitykselle syötetään voittavia konsepteja.