Valitse sivu

Tuoteomistaja on yksi tuotekehityksen merkkihenkilöistä!

29 touko 2018

Tuoteomistaja on yksi tuotekehityksen merkkihenkilöistä!

touko 29, 2018

Kummallisen usein törmään tilanteeseen, että vaikka tiimissä on Scrum Master (joka yleensä on ”oman toimen ohella” -jobi), niin sitten tiimiltä puuttuu oikea, nimetty Product Owner (PO). Joskus tuoteomistaja on kyllä nimetty, mutta käytännössä hän ei voi PO:n hommia hoitaa joko siksi, ettei osaa, tai siksi, että siihen on liian vähän aikaa – tai sitten henkilö ei vain ole tiimin lähellä ja käytettävissä.

Product Owner -tehtävää hoitaa toisinaan Scrum Master, joskus tiimin linjaesimies. Silloin tällöin projektipäällikkö ja joskus myös tuotepäällikkö. Törmään usein myös tilanteeseen, että on useita ihmisiä, jotka ajattelevat yhtä aikaa hoitavansa Product Ownerille kuuluvia töitä.

Ymmärretäänkö organisaatioissa, kuinka paljon tuoteomistaja vaikuttaa lopputulokseen?

Joskus on sellainen fiilis, että tuoteomistajuuden vaikutusta lopputulokseen ei organisaatioissa täysin ymmärretä. On ehkä hankalaa perustella, miksi yhden ei-kehittäjä-ihmisen pitäisi olla liitettynä aika täysipäiväisesti tiimin kylkeen. Jos teidänkin organisaatiossa tämä asia tuntuu hankalalta perustella muille, toivon, että saatte tästä blogista vähän ajatuksia. Blogissa nimittäin kerron, miksi tuoteomistajuudella on suuri vaikutus. Product Ownerin suuren vaikutusvallan ymmärtää, kun oivaltaa, miten ketterä tuotekehitystiimi toimii.

product owner

Kuva 1: tiimin backlogi ja tuotekehitystiimi.

Tuotos voi olla vain niin hyvää kuin tiimille tarjottu input

Tuoteomistaja on tärkein henkilö, joka organisaatiossa päättää siitä, mitä tuossa tiimille työtä syöttävässä backlog-suppilossa on, ja millaisina sieltä tiimille työ syötetään. Vaikka tiimi olisi kuinka hyvä, lopputulos, eli output, voi olla huonoa, jos sisään syötettävät työt (eli yleensä käyttäjätarinat) ovat huonolaatuisia, väärin priorisoituja tai väärin valittuja.

Ideoita on aina paljon enemmän kuin toteutuskapasiteettia – tärkein päätös on mitä EI tehdä

Tuoteomistajan pitää oppia rehellisesti sanomaan EI.

Hyvän tuoteomistajan ensimmäinen ja ehkä tärkein päätös on raakata koko ajan vastaan tulevasta ideavirrasta ne, joissa on eniten jatkopotentiaalia – ja heittää sitten loput ideat roskiin tai kypsymään jonnekin wishlistiin. Eli ensimmäinen päätös on se, mitä EI tehdä. Eli tuoteomistajan pitää oppia rehellisesti sanomaan EI. On äärimmäisen yleistä, voisi jopa väittää, että on tuotekehityksen ”nollas laki”, että ideasyötteitä kehitystiimille on aina enemmän kuin mitä kehitystiimi voi käytännössä saada aikaan. Uusikin tiimi päätyy todella nopeasti tilanteeseen, että backlogilla olevat asiat, vaikka olisivatkin prioriteettijärjestyksessä, ottaisivat yli vuoden tehdä kaikki pois.

Pieni vai suuri valkoinen valhe: ”Laitan sen backlogille”

Tunnustan – itsekin olen syyllistynyt tähän tuoteomistajan yleisimpään valheeseen. Jos joku ehdottaa jotain ideaa, mutta on hankala itse nähdä sen potentiaalia, on paljon helpompi sanoa ”lisään sen backlogille” kuin ”ehkä emme lähitulevaisuudessa tee tuota”, tai suora ”EI kuulosta järkevältä”. Kun sanotaan, että lisätään backlogille, se tarkoittaa, että se menee suoraan backlogin loppupäähän, ja sehän tarkoittaa, ettei sitä tehdä käytännössä koskaan.

Backlogin pituus – pidä se maksimissaan 3–6 kuukaudessa

Joskus backlog sisältää monen vuoden työt. On selvää, että tällainen backlog ei enää ole käytännössä toimiva, vaan tiimi ottaa lähes jatkuvasti uusia töitä ja sijoittaa ne ”keskelle” backlogia, niin että ne saadaan muutamassa kuukaudessa tehtyä. Olisi kuitenkin parempi, että keinotekoisen pitkää backlogia ei päästettäisi edes syntymään, ja tuoteomistaja pystyisi suodattamaan ideavirrasta vain todellisesti arvokkaat ideat backlogille asti.

Backlogin tehokas hallinta olisi helpompaa, jos se olisi vain 3–6 kuukautta pitkä. Erillisissä wishlisteissa tai mappi-ö:ssä voi sitten pitää muita ideoita, mutta tosiaan ideoiden virta ei ole yleensä ongelma yrityksissä. Todella tärkeät asiat tulevat aina vastaan uudelleen. Tärkeää tässäkin on transparenttius, eli koko organisaation olisi syytä ymmärtää miten tuoteomistajana pyrit backlogia hallinnoimaan. Eli missä on ideat, missä eteenpäin vietävät tarinat ja epicit.

”Laitetaan se idealaariin”

Parempi lähestymistapa olisikin, että olisi kaksi laaria: idealaari ja varsinainen backlog.

Ehkä parempi lähestymistapa olisikin, että olisi kaksi laaria: idealaari ja varsinainen backlog. Samalla tavalla kuin varsinaista backlogia groomataan, niin idealaaristakin voisi groomata ehkä hiukan eri porukalla asioita backlogille. Tämä alkaa jo muistuttaa tuotejohtamisen kanbania.

Kaikella on paikkansa prioriteettijärjestyksessä. Arvaa jos et tiedä!

Tuoteomistajan pitäisi pystyä arvaamaan, kuinka arvokas yksittäinen idea voisi olla, ja myös kuinka isotöinen se tulee olemaan. Effortin arviointikyky paranee, kun tuoteomistaja tutustuu ja kerää kokemusta tuotteestaan. Ennen kuin kokemus on kehittynyt riittävälle tasolle, kannattaa avuksi ottaa kehitystiimin porukkaa ja tehdä ideoiden arviointia vaikkapa backlog grooming -sessiossa tai sitten informaalisti.

Tarinoiden arvotus onkin todella hankalaa ja ehkä oman blogin paikka. Toisinaan tarinaan liittyy joku suora asiakastilaus ja silloin arvotus on helppoa. Monesti se menee ihan arvailuksi.

Tarinoiden kirjoittaminen yhdessä on tärkeää

Sitten kun on tehtävät työt on valittu, tuoteomistajan seuraava homma on varmistaa, että tarinat ovat sellaisia, että niissä saadaan juuri oikeat asiat tehtyä, ja tiimi saa tehtyä niiden kanssa työtä tehokkaasti ilman hukkatyötä. Eli, tarinoiden pitäisi olla tarpeeksi pieniä, selkeitä, toisistaan riippumattomia ja niistä pitäisi keskustella tiimin jäsenten kanssa, jotta kaikki ymmärtävät mitä ollaan tekemässä ja niihin voidaan myös tehdä tarvittavia toteutusteknisiä säätöjä.

Anna tiimin huolehtia toteusteknisestä ja laatuasioista. Ole utelias, miten asia etenee ja ohjaa tarvittaessa!

Työn alla oleviin tarinoihin tuoteomistajan kannattaa suhtautua uteliaisuudella, mutta samalla kuitenkin niin, että tiimille jätetään tekninen omistajuus tehdä toteutus niin, että se on hyvälaatuista ja tervettä ja helposti ylläpidettävää. Suosittelenkin, että tuoteomistaja käy kyselemässä kehitystiimiltä, miten homma edistyy ja onko tullut mitään tenkkapoota vastaan. Usein näissä ongelmakohdissa on hyviä tilaisuuksia hienosäätää tarinaa vieläkin arvokkaammaksi.

Asiakasymmärrys ja keskustelut kaikkien kanssa ovat tuoteomistajan arkea – varaa niihin tarpeeksi aikaa

Suuri osa tuoteomistajan työtä on tehdä ”koulututettuja arvauksia”. Arvauksia siitä, mitkä tarinat ovat arvokkaimpia juuri nyt, tai siitä mitkä tarinat on nyt vaan pakko hylätä, koska ne eivät tuota tarpeeksi lisäarvoa tai ovat hankalia myydä sekä liian työläitä. Ehkä haastavin osa tuoteomistajan työtä onkin säilyttää tarpeeksi hyvä asiakaskontakti ja markkinaymmärrys, jotta nämä joka päivä vastaan tulevat arvaustilanteet menisivät mahdollisimman oikein. Asiakaskontaktien ja jatkuvan keskustelun arvo onkin todella suuri tuoteomistajalle, ja siihen on syytä osata varata tarpeeksi työaikaa.

Vie pullaa välillä myös tuotepäälliköille!

Tuotepäällikön ja tuoteomistajan yhteistyö onkin yleensä yksi hyvin toimivien tuotekehitysorganisaatioiden menestystekijä.

Organisaatioissa tuotepäällikkö on yleensä se, jolla on vielä tuoteomistajaakin enemmän vastuuta asiakaskontakteista ja asiakasymmärryksestä. Tuotepäällikön ja tuoteomistajan yhteistyö onkin yleensä yksi hyvin toimivien tuotekehitysorganisaatioiden menestystekijä. Jos et vielä lukenut aikaisemmin kirjoittamaani blogia tuotepäällikön ja tuoteomistajan roolien eroista, lue se nyt! 

Alkaisinko Product Owneriksi?

Tässä nyt vasta raapaistiin tuoteomistajuuden pintaa, mutta eikö jo vaikutakin hassulta, miten tärkeästä työstä on kysymys, ja miten usein silti törmätään tilanteisiin, joissa tuoteomistajuus on vähän epäselvä rooli organisaatiossa? Tai miten usein törmätään tilanteeseen, että tuoteomistajan rooli annetaan jollekin ihmiselle ilman sen suurempaa koulutusta tai aikaisempaa kokemusta? Tuoteomistajan rooli on ketterän kehityksen keskiössä, ja vaikka se ei olekaan mikään ylettömän hankala rooli – vaan päin vastoin, yleensä todella palkitseva ja opettava rooli – siihen on kuitenkin syytä suhtautua vakavasti ja varata siihen riittävästi aikaa ja kapasiteettia. Tuoteomistajuuteen oppii nopeasti, mutta parhaan lähtövauhdin uuteen rooliin saa asiantuntevasta koulutuksesta.

Haluatko kehittyä tuoteomistajana? Lataa kattava oppaamme aiheesta!

Product Ownerin aloitusopas

Kuinka oppia loistavaksi Product Owneriksi ja siivittää tuotteesi menestykseen.

Arto Kiiskinen

Arto Kiiskinen

Senior Consultant

Arto on urallaan nähnyt tuotekehitystä monista eri näkökulmista. Hänellä on kokemusta mm. Product Ownerin, Scrum Masterin ja tuotekehitysjohtajan tehtävistä. Niin isojen kuin pientenkin firmojen toimintatavat ovat tulleet tutuiksi. Arto rakastaa parantaa organisaatioiden oppimista sekä tuoteomistajien osaamista, ja kirjoittaa blogeja eri aiheista. Koska retrospektiivit on yksi Arton suosikkiaiheista, ovat jotkut asiakkaat antaneet hänelle lisänimen "Retromies". Vapaa-aikana Arto yrittää elää terveellisesti, ostaa mahdollisimman paljon autoja, katsoo yhä uudelleen Tähtiportti-sarjan jaksoja ja opiskelee Personal Traineriksi. Arto on kirjoittanut kirjan "OWN IT – 8 Simple Secrets of Product Owner Success". Lisää Arton ajatuksia voi lukea täältä.

Share This

Jaa tämä kollegoillesi

Jaa tämä postaus verkostoosi!