Pirkka Rannikko

Pirkka Rannikko

UX and Service Design

pirkka.rannikko@vincit.fi
+358 40 015 8486

TwitterLinkedIn

Tuoteomistaja on avainroolissa räätälöidyssä ohjelmistokehityksessä, kun halutaan maksimoida tehdyn investoinnin arvon tuotto. Tuoteomistajan työ voi olla haastavaa ja moni tekee sitä oman toimen ohella sen minkä muilta vastuiltaan ehtii. Ketterä ohjelmistokehitys edellyttää tuoteomistajalta paljon ja tiimillä voi olla suuret odotukset tuoteomistajaa kohtaan. Kehitystiimi voi kuitenkin auttaa tuoteomistajaa onnistumaan työssään ja seuraavassa avaan tätä ajatusta parin eri näkökulman avulla.

Tämän syksyn aikana olemme Vincitillä keskustelleet muun muassa projektikäytänteistä, työtavoista ja ketterän ohjelmistokehitysprojektin eri roolien vastuista ja tehtävistä. Entisenä SaaS-tuotetalojen tuoteomistajana koen olevani aiheen kokemusasiantuntija ja kollegat ovat joutuneet ja pääseet nauttimaan anekdooteistani.

Tuoteomistaja on avainroolissa räätälöityyn ohjelmistokehitykseen tehdyn investoinnin arvon tuoton maksimoinnissa. Tivi 11/2019 kirjoitti väärinymmärretystä Scrumista. Jutussa listattiin syitä sille miksi Scrum epäonnistuu ja viidentenä listalla oli nostettuna “tuoteomistaja ei ole tehtäviensä tasalla”. Myös Goforen Jari Hietaniemi on kirjoittanut ansiokkaasti tuoteomistajan roolista, vastuista ja tehtävistä sekä vaikeuksista. Googlaamalla “product owner anti patterns” (ns. epätoivottu käyttäytymismalli) löytyy merkittävät määrät listauksia siitä, mitä tuoteomistaja voi tehdä väärin. Moni ohjelmistokehityksestä leipänsä ansaitseva tuoteomistaja onkin hyvin itsetietoinen omasta riittämättömyyden tunteestaan ja pystyy ruoskimaan itseään aiheesta loputtomiin. Miksi se tuoteomistajan työ sitten on niin vaikeaa? Syitä on tietysti lukuisia, mutta pohdin niitä tässä kahdesta eri näkökulmasta:

1. Tuoteomistajan roolia, vastuita ja tehtäviä ei ymmärretä.

2. Organisaatio ei luo onnistumisen edellytyksiä tuoteomistajalle.

Tuoteomistajan rooli ja maallikkotuoteomistajat

Osalle tuoteomistajista rooli ja sen vastuut ja tehtävät ideaalimaailmassa ovat hyvin selviä. Ymmärrys on muodostunut ohjelmistotuotteiden parissa kertyneen työkokemuksen ja mahdollisesti jopa aiheen opiskelun kautta. Jos henkilö on työskennellyt ohjelmistokehityksen parissa eri rooleissa, esim. kehittäjänä jossain vaiheessa uraansa, on hänen helpompaa ymmärtää roolinsa useista eri näkökulmista. Tuoteomistaja voi esim. hypätä hetkeksi kehittäjän saappaisiin miettimään, mitä odotuksia heillä on ja mitä minä voin tuoteomistajana tehdä palvellakseni kehitystiimiä paremmin?

Kaikilla ohjelmistotuotteiden parissa kokopäiväisesti työskentelevillä tuoteomistajilla ei kuitenkaan ole taustaa ohjelmistokehityksestä ja heidän aikaisempi kokemuksensa voi olla kertynyt aivan muulta alalta. Esimerkiksi heillä saattaa olla kokemusta jonkin liiketoimintaprosessin tai -toiminnon omistajuudesta tai asiantuntijatyöstä sen parissa. Tai voi olla, että tuoteomistajalla on kokemusta valmisjärjestelmien ostamisesta ja operoinnista, mutta ei räätälöidyn ohjelmistokehityksen ohjaamisesta.

Sitten on suuri joukko maallikkotuoteomistajia eli ihmisiä, jotka toimittavat tuoteomistajan virkaa oman toimen ohella. Yrityksen toimitusjohtaja, liiketoiminnon omistaja, kehityspäällikkö jne. toimii kehitystiimin työparina, mutta tehtävä ei ole heidän pääasiallinen vastuunsa vaan yksi muiden lukemattomien nakkien joukossa, jotka pitää jotenkin hoitaa. Vaikka kokemusta ja näkemystä roolista olisi, tilanne on silti aivan toinen kuin ns. ammattituoteomistajilla, jotka eivät tee muuta työkseen. Monesti kehitystiimille jää suuri vastuu tuoteomistajan kouluttamisesta ja valmentamisesta, joka on hyvä tiedostaa ja ymmärtää.

Oli tuoteomistajan ja tiimin taustat sitten mitkä hyvänsä, on heidän syytä keskustella kunkin roolin vastuista ja tehtävistä ja siitä miten eri ihmiset niiden odottavat käytännössä arjessa toteutuvan. Kaikilla meillä on omat subjektiiviset kokemuksemme, tietomme ja oletuksemme esimerkiksi siitä mitä Scrum on. Tästä syystä tiimin pitää keskustella ja sopia mitä se kulloisessakin hankkeessa tarkoittaa ja miten se vaikuttaa työtapoihin. Vastaavasti tiimin ja tuoteomistajan tulee selkeyttää roolit, jotta heillä olisi edellytykset tehokkaaseen ja tulokselliseen työntekoon.

Vastuut, tehtävät ja panostus, millä kukin voi hankkeeseen sitoutua kannattaa kirjata muistiin ja näkyviin (sekä merkitä kalenteriin). Näin on helpompi käydä älyllistä keskustelua ja tarvittaessa palata niihin esim. retrojen yhteydessä. Muuten voidaan olla tilanteessa, jossa muistetaan, että jotain on sovittu, mutta eri osapuolet ymmärsivät asian eri tavalla. Esimerkiksi tiimi voi olettaa, että tuoteomistaja on saatavilla sprintin palavereihin joka toinen viikko kokonaisen arkipäivän aina samana viikonpäivänä, kun tuoteomistaja olettaa sitoutuneensa parin tunnin palaveriin aina silloin tällöin.

Organisaation luomat edellytykset onnistumiselle

Yksi päällimmäisistä tuoteomistajan epätoivotuista käyttäytymismalleista on se, että tuoteomistaja ei ole saatavilla eikä hänellä ole vastauksia, koska ei ole aikaa. Ja tämä on yksi niistä asioista mistä tuoteomistajat ovat usein tietoisia ja kokevat huonoa omaatuntoa. Scrum tuotekehityksen viitekehyksenä on luotu kehittäjien lähtökohdista ja se luo kovat odotukset tuoteomistajan työpanokselle. Toteaahan Agile Manifeston neljäs periaate seuraavaa: “Business people and developers must work together daily throughout the project". Voiko olla, että Scrum vaatii “keskivertoasiakkaalta” liikaa?

Uskallan väittää, että nykyajan matriisiorganisaatioissa ja muissa verkostohimmeleissä työskentelevillä ihmisillä ei ole kovin hyviä edellytyksiä vastata näihin vaatimuksiin. Tuoteomistajan virkaa täyttävät ihmiset työskentelevät usein tiimien, asiakkaiden ja asioiden rajapinnoilla ja heitä vedetään ja työnnetään moneen suuntaan. Ihmisten ei ole helppoa päästä selvyyteen omista vastuista, tehtävistä ja tavoitteista sekä kaikkien näiden riippuvuuksista ja syy-seuraussuhteista saati kommunikoida tilannetta muille. Ja jos henkilö ei tähän itse pysty, niin miten voisi hänen kollegansa tai johtajansa pystyä tehdessään viikoittain tai jopa päivittäin henkilön työkuormaan vaikuttavia päätöksiä?

En ole vielä keksinyt tai löytänyt työkalua joka ratkaisisi edellä mainitun ongelman. Työkalua joka visualisoisi tämänlaisen limbossa olevan henkilön vastuut, tehtävät ja koetun työkuorman kulloisellakin päätöksentekohetkellä. Tästä syystä asioita, joita pitäisi syystä tai toisesta hoitaa, on naurettavan paljon enemmän kuin on kykyä tai kapasiteettia hoitaa niitä. Tilanteeseen tietysti vaikuttaa myös se, että on vaikea sanoa kaverille päin naamaa, että "en pysty, en kykene", koska suurin osa meistä haluaa oikeasti olla toiselle avuksi.

Mainittua työkalua odotellessa pitäisi siis avoimemmin keskustella siitä, mikä on organisaation ja yksilöiden kantokyky ottaa uusia asioita pöydälle. Päätöksentekohetkellä voisi tehdä nopean "sanity checkin" ja kuulla ihmisiä, että mikä heidän kokemuksensa on työkuormastaan ja uskovatko he, että asia voidaan oikeasti hoitaa niillä pelimerkeillä mitä on.

Tätä “kokemusasiantuntijuutta” kuvataan myös artikkelissa 15 Things You Should Know About Product Managers loistavalla tavalla. Jälleen kerran nämä asiat eivät välttämättä ole itsestään selviä tiimille, jotka tuskailevat tuoteomistajansa hoitamattomien vastuiden kanssa. Missä tahansa semijärkevässä organisaatiossa yhden teeman/aiheen ympärille kasattua tiimiä, on kohtalaisen helppo suojata sekoilulta sopimalla yksinkertaiset työjärjestysasiat esimerkiksi backlogit ja synkkaus sidosryhmien kanssa jne. kuntoon. Tiimin kuormitus ja lähitulevaisuuden näkymät ovat kohtalaisen helppo pitää hanskassa, kun kaikki työ kirjataan ja laitetaan näkyviin. Kilpensä suojissa tiimi ei kuitenkaan näe puoliakaan siitä sotkusta minkä kanssa tuoteomistaja saattaa tuskailla.

Jos kehitystiimi on kuitenkin oikeasti sitoutunut auttamaan tuoteomistajaansa onnistumaan työssään, ottaa se selvää tuoteomistajan muista sidosryhmistä ja sitoumuksista. Tiimi ja tuoteomistaja yhdessä mukauttavat toimintaansa ja odotuksiaan siten, että arkeen syntyy onnistumisen edellytykset kaikille osapuolille. Esimerkiksi tuoteomistajan on mahdotonta sitoutua lukittuihin sprinttipalavereihin ja -sykliin, koska matkustaa tapaamassa asiakkaita, niin kannattaako tiimin ylipäätään työskennellä Scrum-sykleissä? Toimisiko Kanban-tyyppinen virtauspohjainen malli ja viikoittaiset lyhyet tavoitepalaverit tiimille paremmin?

Jos tuoteomistaja ei ehdi tai osaa pohtia käyttäjätarinoiden hyväksyntäkriteerejä, kerätä käyttäjä- ja asiakaspalautetta, konseptoida uusia ominaisuuksia, niin mitä näistä töistä voidaan siirtää tiimille? Muun muassa UX-designerit ovat yleensä kultaakin arvokkaampia työpareja tuoteomistajille vaatimusten keräämisessä, validoinnissa ja kommunikoinnissa muulle tiimille – voimavara mitä kannattaa ehdottomasti hyödyntää.

Jos tuoteomistaja ei itse ehdi selkeyttää, kiteyttää ja viestiä, kannattaa hänen delegoida se mikä on järkevää ja keskittyä itse päätösten tekemiseen ja vastausten kaivamiseen. Näin tiimi pystyy tekemään omat työnsä, vaikka tuoteomistajan oma tilanne olisikin haastava.

Avoimet kortit

Tuoteomistajia, tiimejä, hankkeita ja organisaatiota on monenlaisia ja niillä on erilaisia lähtökohtia, joiden varaan onnistuminen rakennetaan. Selkeät roolit ja sovitut vastuut ja tehtävät muodostavat kestävän kivijalan. Toinen syntyy siitä, että vastuut ja tehtävät on yhdessä sovitettu vallitsevaan tilanteeseen ja ne vievät tiimiä kohti tavoitetta tehokkaasti ja tuloksellisesti.

Tuoteomistajan kannattaa jutella tiimin kanssa avoimin kortein. Yhteinen sävel ja luottamus löytyy vain sitä kautta. Tai Agile Manifeston sanoin: "Individuals and interactions over processes and tools".

PS. Suosittelen kaikille tuoteomistajille lukemiseksi Lean UX: Designing Great Products with Agile Teams kirjaa. Se täydentää hienosti ketterän kehityksen menetelmiä tuomalla pöytään työkaluja, joilla voidaan muun muassa selvittää, mitä ongelmia oikeasti kannattaa ratkaista ja millainen ratkaisun tulisi olla, jotta se sopisi ihmisille.

Tykkäsitkö artikkelista?

Anna pienet aplodit!

Kommentit

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *