Product Owner eli tuoteomistaja ohjelmistoprojektissa: Mitä, miten ja miksi?

Vaativissa ohjelmistohankkeissa tuoteomistajan harteilla on paljon vastuuta. Laatuvipuajatteluun kuuluu, että tekniset ongelmat pitäisi ennakoida mahdollisimman aikaisin. Kuukausien, jopa vuosien kuluessa projektin kehitysjono rönsyilee, ja puutarhasaksille riittää töitä.

Tässä artikkelissa pohditaan, miten tuoteomistajan rooli kannattaa käytännössä järjestää, jotta ohjelmistoa kehittävä tiimi pääsisi mahdollisimman laadukkaaseen lopputulokseen. Jos tuoteomistajan tehtävänkuva on jo tuttu, voit hypätä seuraavan kappaleen yli. Muussa tapauksessa lähdetään lyhyesti liikkeelle perusasioista.

Mitä tuoteomistaja tekee?

Tuoteomistaja eli Product Owner on yksi keskeisistä rooleista, joita tarvitaan ketterässä scrum-ohjelmistokehityksessä. Hän ei yleensä itse kirjoita koodia, mutta toimenkuvaan kuuluu tiivis yhteistyö sekä kehitystiimin että Scrum Masterin kanssa.

Tuoteomistajan vastuulla on huolehtia siitä, että kehitysjono on ajan tasalla ja sieltä löytyvät asiat on työstetty riittävän selkeiksi kokonaisuuksiksi. Juuri Product Owner kantaa viime kädessä päävastuun projektin vaatimusten hallinnasta. 

Tuoteomistaja on linkki kehitystiimin ja asiakkaan välillä ja hän pitää yhteyttä sidosryhmiin. Päivittäinen työ on kommunikointia ja priorisointia. Hän huolehtii yhdessä Scrum Masterin kanssa siitä, että tiimillä on puitteet sujuvaan ja tehokkaaseen työskentelyyn ja asiantuntijoiden aika kuluu oikeisiin asioihin.

Kuka toimii Product Ownerina eli tuoteomistajana?

Kun uuden ohjelmistoratkaisun suuntaviivat on hahmoteltu yhdessä asiakkaan kanssa, kokoamme Cinian asiantuntijoista tarpeisiin sopivan kehitystiimin. Ketterä ohjelmistokehitys on jatkuvaa, iteratiivista työtä päivittäispalavereineen, ja siihen tarvitaan mukaan vähintään yksi vastuuhenkilö asiakkaan päädystä – se on selvää. Onko hän automaattisesti projektin tuoteomistaja – se ei olekaan yhtä selvää, vaan riippuu aina projektista.

Asiakkaalta ei ehkä yksinkertaisesti löydy asiantuntijaa, joka osaisi kuvata ohjelmiston teknisiä vaatimuksia riittävän tarkasti. Silloin me ohjelmistokumppanina autamme pohtimaan, mitä tilanteessa kannattaisi tehdä: riittääkö, että tuemme asiakasta Product Ownerin roolissa, vai sovimmeko jopa, että tekninen tuoteomistaja nimetään projektiin suoraan Cinian riveistä?

Oma mielipiteeni on, että yksi tuoteomistaja riittää – se on ohjelmistohankkeen ja ketterän viitekehyksen kannalta tehokkainta. Olennaisinta on tunnistaa, mitä juuri kyseinen projekti ja sen tuoteomistajuus vaatii.

Tuoteomistaja ohjelmistokumppanilta

Jos päädymme asiakkaan kanssa siihen vaihtoehtoon, että tekninen tuoteomistaja tulee hankkeeseen meiltä Cinialta, emme silti jätä asiakasta yksin. Emme voi kuvitella olevamme asiakkaan bisneksen erityisasiantuntijoita. Siksi liiketoiminnan asiantuntijuus tulee aina asiakkaalta. On vain laajennettava sidosryhmiä ja löydettävä ne henkilöt, joiden kanssa tuoteomistaja voi jutella sekä nyt että myöhemmin.

Toisaalta meiltä saattaa löytyä talosta valmiiksi erityisosaamista, jota projektissa tarvitaan. Esimerkiksi terveydenhuollon lainsäädäntöön liittyy paljon erityispiirteitä, jotka pitää ottaa huomioon ohjelmistoratkaisuissa juuria myöten. Asiakkaalla saattaa olla vaikkapa sote-sektoria palveleva idea, mutta jo alkuvaiheen UX-työpajoissa huomataan, että voimme nostaa esiin liiketoimintavaatimuksia, joita asiakas ei ole tullut ajatelleeksi. Cinian tiimiin kuuluva tuoteomistaja voi jatkaa silloin samaa, rakentavaa haastamista läpi projektin.

Tuoteomistaja asiakkaalta

Jos asiakkaan yhteyshenkilöllä on varma tuntuma teknologiaan ja selkeä visio tulevan ohjelmiston toteutuksesta, tuoteomistajan viitta on helppo asetella hänen harteilleen. Siitäkin mallista meillä on monia hyviä kokemuksia. Meiltä tarvitaan herkkää kykyä muovautua tilanteeseen myös silloin: ei pidä tehdä oletuksia, vaan etsiä avoimesti keskustellen yhdessä ne kohdat, joihin asiakas kaipaa apua ja tukea. 

Jos asiakas tietää heti haluavansa tuoteomistajan vastuun, ja osaa nimetä henkilön projektia johtamaan, nimeämme Cinian päässä erikseen yhteyshenkilön hänen suuntaansa. Usein se on käytännössä Scrum Master. Talon omassa kielenkäytössä puhumme myös “Proxy Product Ownerista”, vaikka se ei puhdasoppinen agile-termi olekaan, ja vaikka varsinaisia tuoteomistajia onkin vain yksi. Emme ole perinteinen konsulttitalo vaan tiimityöhön nojaava ratkaisutalo, joten järjestely on käytännöllinen.

Aika on tuoteomistajan tärkein resurssi

Jotta koodista tulee laadukasta ja ohjelmistosta toiveiden mukainen, tuoteomistaja tarvitsee riittävästi aikaa työhönsä. Sitä tarvitaan, tuli hän sitten kummasta organisaatiosta tahansa. 

Backlogin tarkastelua käsittelevässä artikkelissa kollegani Mikko Suni toteaakin: “Varsinkin isoimmat projektit vaativat, että tekninen tuoteomistaja on sataprosenttisesti hankkeen saatavilla, eli ei joudu jakamaan aikaansa eri projektien kesken”.

Mitä vaativampi ja moniulotteisempi projekti on, sitä enemmän ongelmia on luvassa, jos tuoteomistajan rooli on aliresursoitu. Häntä tarvitaan tulevien sprinttien huolelliseen valmisteluun ja tuotosten kommentointiin, mutta myös ihan jatkuvaan, päivittäiseen tekemiseen ja tiimiläisten tukemiseen. Jos tuoteomistaja ei ole tavoitettavissa, koko karavaani jää jumiin. Pahimmassa tapauksessa ohjelmistokehitys alkaa edetä arvausten perusteella, ja useampikin asiantuntija huomaa tehneensä päivä- tai viikkokaupalla turhaa työtä. 

Mitä uteliaampi mieli meillä on asiakkaan ideoita kohtaan, mitä avoimempi keskusteluyhteys meille syntyy ja mitä täsmällisemmin sovimme tuoteomistajan vastuista, sitä paremmin onnistumme vaativissa hankkeissa.

Millaista tukea tehtävässä onnistumiseen tarvitaan? Kysyimme sitä yli 80 suomalaisen organisaation tuoteomistajilta. Hyödynnä tulokset tuotekehitysprojektissasi!