Valitse sivu

Tarvitseeko SAFe tuotepäälliköitä?

14 kesä 2017

Tarvitseeko SAFe tuotepäälliköitä?

kesä 14, 2017

Scaled Agile Framework®, eli tuttavallisesti SAFe®, on viime aikoina kasvattanut hurjasti suosiotaan. Ketterät ohjelmistokehitysmenetelmät ovat arkipäivää jo isoissa teollisuusyrityksissäkin ja skaalautuville prosesseille on tarvetta. Mutta miksi juuri SAFe® ja mitä se tarkoittaa tuotejohtamisen näkökulmasta?

SAFe® on yksityiskohtainen malli ketterälle kehittämiselle

SAFe®:n suosion taustalla on erittäin hyvin tehty tuotteistus (josta voisi kirjoittaa ihan omankin blogin). Malli on tarkkaan määritetty ja niin tukimateriaalia kuin valmennuksia on paljon tarjolla.

Kehitystiimeille SAFe® antaa joustavat mahdollisuudet valita eri menetelmien  väliltä, kuten scrumi tai kanban, mutta lähes kaikkeen muuhun kehitysprojekteissa löytyy SAFe®:n mukainen malli. Koko kehyksen pohjana on ”ketterä kehitysjuna” (Agile Release Train), joka puskee ennustettavasti koodia ulos. Toimitusten koosta riippuen mallissa voi olla eri tasoja arvon tuottamiselle tuotteista ratkaisun.

SAFe 4.0 for Lean Software and Systems Engineering

Kehitysprosessin lisäksi SAFe® määrittelee ohjelmistokehityksen vastuut. Alimmalla, eli tiimitasolla, pätevät tutut ketterän kehityksen roolit (scrum master, product owner, kehittäjätiimit).

Program-taso yhdistää tiimien tuotokset kehitysjunaan, josta vastaa Release Train Engineer (RTE). Hänen vastuullaan ovat yleiset ”projektipäällikön” työt, eli ensisijaisesti varmistaa että kehitysjuna puksuttaa asemalle aikataulun mukaisesti. Yhdessä RTE:n kanssa toimii tuotepäälliköt sekä mahdollisesti arkkitehdit, jotka ovat vastuussa toimituksen sisällöstä.

Organisaation koosta ja kompleksisuudesta riippuen prosessissa voi olla vielä yksi tai kaksi tasoa, jotka keräävät eri kehitysjunien sisällön suuremmiksi toimituskokonaisuuksiksi (Value stream, Solution). Työnjaossa sama periaate kuitenkin säilyy jokaisella kerroksella: arkkitehti omistaa teknisen toteutuksen, tuotejohto määrittelee sisällön ja ”projektipäällikkö” vastaa suunnitelmien toteutumisesta.

Sisällön ja aikataulujen osalta nämä kolme ovat avainasemassa, mutta SAFe® toki määrittää muutkin roolit liiketoiminnan omistajista UI suunnittelijoihin ja testaajiin asti.

SAFe ja tuotejohtaminen

SAFe määrittelee miten ohjelmistokehitys toimii, eli periaatteessa sitä voi käyttää niin tuote- kuin projektiliiketoimintaan. Jos työ tähtää puhtaaseen asiakastoimitukseen, niin Product Owner toimii asiakkaan äänenä ja vastaa vaatimuksista samalla tavalla kuin esimerkiksi scrum’ia käytettäessä.

Useimmissa teollisuusyrityksissäkin on jo huomattu, että ohjelmistoja kannattaa hallita ja uudelleen käyttää myös projektitoimituksiin. Samalla esimerkiksi IoT-ratkaisujen vaatimukset ovat luoneet tarpeita mm. rajapintojen vakioimiselle. Ja vakioidut komponentithan vaativat elinkaariajattelua, vaatimushallintaa ja muita tuotejohtamisen komponentteja.

Käytännössä SAFe:a siis käytetään yleensä tuotteiden tai tuotteistutettujen palveluiden ohjelmistokehityksen mallina. Se osa tuotteen elinkaaren johtamisesta, joka tapahtuu ennen kuin kehityspäätös tehdään tai sen jälkeen kun ohjelmisto julkaistaan, jää pääosin SAFe:n ulkopuolelle.

SAFe ei ota kantaa vaatimusten lähteisiin

Perinteinen ohjelmistokehitys on voitu ajatella ”tehtaana”, jonka sisään syötetään vaatimuksia ja josta ulos tulee ulos ohjelmistoa. Vaikka ohjelmistokehityksen ajatteleminen ”tehtaana” ei tee oikeutta hyvin toimivalle organisaatiolle, niin se muistuttaa ohjelmistokehityksen perus lainalaisuuksista, jotka pätevät myös SAFe:a käytettäessä

  1. Huonot tai tarpeettomat vaatimukset eivät voi tuottaa hyvää liiketoimintaa
  2. Jos ”tehtaaseen” syöttää liikaa tekemistä, niin tuotanto hidastuu
  3. Mitä pienemmiksi paloiksi syöte (vaatimukset) on pureksittu, sitä nopeammin ne valmistuvat ja tuottavat arvoa.

SAFe määrittää useita ketteristä kehitysmenetelmistä tuttuja käytäntöjä, jotka auttavat perinteisissä ohjelmistokehityksen haasteissa. Niistä huolimatta tuotejohtamisen rooli on edelleen selvä:

Tuotepäällikön tärkein tehtävä on varmistaa asiakasarvo.

SAFe:ssa ylimmän tason vaatimuksia kutsutaan epic’eiksi ja niitä hallitaan portfolio kanbanilla.

SAFe:n Portfolio Kanban

 

Taulun ensimmäinen sarake on Funnel, eli perinteisen ideasuppilon alkupää. Jotkut keräävät sinne kaikki vaatimukset, toiset taas hallitsevat idea-tasoa jossain muussa työkalussa, josta tärkeimmät ja parhaimmat ideat tuodaan portfolio kanbanille.

Review, eli kanbanin toinen vaihe, on usein se vaikein. Siinä kuvataan ja määritetään epic´in tuottama arvo.  SAFe suosittaa priorisointiin käytettäväksi Weighted Shortest Job First -menetelmää, jossa vaatimusten implementointijärjestys määräytyy sen mukaan miten paljon liiketoiminta-arvoa syntyy, kuinka aikakriittinen toteutus on, miten paljon siihen sisältyy riskejä ja mikä on vaadittava työmäärä. Menetelmä antaa laskukaavan, mutta vaikein työ on löytää siihen edes suhteellisen oikeat arvot.

Ideoiden ja vaatimusten liiketoiminta-arvon määritys  jää SAFe:akin käytettäessä tuotejohtamisen ammattitaidon varaan.

Joskus asiakasarvon ymmärtämiseksi pitää rakentaa MVP, joskus tehdä kokonainen business case laskelma. Parhaimmassa tapauksessa asiakas on valmis kertomaan paljonko hän uudesta vaatimuksesta maksaisi. Käytännössä arvo kuitenkin repäistään usein hihasta ja määritetään pääsääntöisesti yläkanttiin.

The hardest thing about product management is that doing the right thing for your customers means that you’re saying “no” to them 95% of the time.”  – Atlassian Sr Product Manager, Dave Meyer

Arvon määrityksen jälkeen vaatimus siirretään arkkitehtien ja tuotekehittäjien arvioitavaksi Analysis-sarakkeeseen. Tämän vaiheen tarkoitus on tutkia vaatimuksen toteutusta. Kun toteutuksen työmäärä ja muu kustannus on selvillä, voidaan uudelleen arvioida miten odotettu arvo suhteutuu kustannukseen ja tehdä päätös siirretäänkö vaatimus Portfolio Backlogille vai ei.

Portfolio Kanban suhteutettuna perinteiseen portfoliosuppiloon

Portfolio Backlog on SAFe®:n korkeimman tason työlista, josta sisältöä siirretään kehitysjuniin tiimien työtilanteen mukaan. Työlistan ”groomaus” yhdessä program managerin ja liiketoiminnan edustajien kanssa on tuotekehityksen ketterää johtamista.

Monta tasoa, monta roolia

Nimensä mukaisesti SAFe skaalautuu isoihin, jopa tuhansien työntekijöiden tuotekehitysorganisaatioihin. Tällaisissa tapauksissa myös tuotejohtamisen pitää jakautua useille tasoille. Alimmalla tasolla Product Owner varmistaa, että tiimit tekevät oikeita asioita oikeassa järjestyksessä. Tiimien työ voi yhdistyä tuotetasolla, jossa ominaisuuksista vastaa tuotepäällikkö. Tuotteet tai komponentit saattavat muodostaa eri asiakassegmenteille meneviä arvovirtoja (value stream), joista vastuussa saattaa olla Solution Manager tittelillä toimiva henkilö. Ylimmällä tasolla portfolion hallinnasta taas projektitoimiston ja liiketoimintayksiköiden kanssa saattaa keskustella VP of Product omien tuotealueidensa vastuuhenkilöiden kanssa.

Suuressa organisaatiossa on tärkeää jakaa asiakasymmärrys eri tasoille ja myös priorisoida tekemistä siellä missä paras ymmärrys sen tason tekemisestä on.

SAFe:a käyttävässä yrityksessä voi olla tuotekehityksessä parikymmentä työntekijää tai sitten pari tuhatta. Mitä enemmän porukkaa on ja mitä monimutkaisempia tuotteet ovat, sitä enemmän tarvitaan määrittelyä, ohjausta ja asiakasymmärrystä. Millä titteleillä tätä työtä tehdään, ei ole tärkeää. SAFe on vain kehys, joka jokaisen yrityksen pitäisi pyrkiä sovittamaan omiin tarpeisiinsa sopivaksi.

SAFe määrittelee ohjelmistokehityksen, ei tuotejohtamista

SAFe®:a käyttöön otettaessa ja käytettäessä kannattaa muistaa, että prosessi on tehty auttamaan kehityksen ohjaamisessa, ei ohjaamaan tekemistä.  Parhaiten SAFe® palvelee organisaatioita, jotka muokkaavat sen itselleen sopivaksi lean-agile periaatteita käyttäen.

Tuotejohtamisen näkökulmasta on tärkeä muistaa, että asiakasarvo rakentuu monista osista ja ohjelmistokehitys on vain osa siitä. SAFe ei poista tuotejohtamisen tarvetta, vaan tuotepäällikön tärkeimmät vastuut ovat edelleen:

  • Varmistaa vaatimusten ja ideoiden asiakasarvo
  • Osoittaa tekemiselle suunta ja varmistaa että asiakkaan tarpeet välittyvät tekijöille
  • Priorisoida tehtävä työ

Me Contribytellä autamme yrityksiä löytämään ja implementoimaan heille parhaat tuotekehitysmenetelmät. Olemme auttaneet ja kouluttaneet useita organisaatiota SAFe-mallin käyttöönotossa sekä tuote- ja portfolionhallinnassa. Jos SAFe tai tuotejohtaminen kiinnostaa, niin ota yhteyttä.

P.S. SAFe koulutustarjontamme löydät täältä.

Harri Pendolin

Harri Pendolin

Johtava konsultti

Harri on "tuotemies" henkeen ja vereen. 20 vuoden työuraan mahtuu niin tuotepäällikkönä toimimista isossa yrityksessä, kuin kahdeksan vuotta yrittäjänäkin, mutta aina tuotteiden parissa. Suurimmat intohimot syttyvät tuotestrategioita kehittäessä ja portfolionhallinnan parissa.

Vapaa-aika menee Harrilla liikkuessa ja lasten harrastuksissa. Harri on aina valmis jakamaan osaamistaan tuotejohtamisesta tai debatoimaan liiketoiminnan strategisista valinnoista. Lisää Harrin kokemuksia ja mielipiteitä voi lukea täältä.

Share This

Jaa tämä kollegoillesi

Jaa tämä postaus verkostoosi!