Projekteja vai tuotteita?
Tehdäänkö teillä projekteja vai tuotteita?
Tuotekehitys erillisinä projekteina voi olla kallista ja vaikeuttaa kokonaisuuden hahmottamista. Kun tuotteen elinkaari nähdään yhtenä jatkumona loppukäyttäjien näkökulmasta, pystytään paremmin minimoimaan elinkaaren kokonaiskustannus (Total Cost of Ownership, TCO) ja maksimoimaan loppukäyttäjien tyytyväisyys.
Tositarina: Eräässä IT-yrityksessä yhtä tuotetta kehitettiin yli sadan projektin kautta. Kysyin johtoryhmältä, paljonko aikaa jää tuotekehitykseen, kun projektien hallinta ja "resurssien optimointi" vievät suurimman osan ajasta. Vastauksena oli hiljaisuus.
Onko tuotteiden ja palveluiden kehitykseen ja ylläpitoon pysyvät tiimit?
Kun tiimeillä on pysyvä vastuu tuotteesta, ne voivat kehittää syvällistä osaamista ja omistajuutta, mikä lisää itseohjautuvuutta ja laskee elinkaaren kokonaiskustannuksia. Esimerkiksi Scrum mahdollistaa tiimin vastuun ottamisen tuotteen koko elinkaaresta – ei vain ensimmäisestä julkaisusta.
Tositarina: Scrum on aina sisältänyt tuotteen koko elinkaaren hallinnan, mutta sitä sovelletaan joskus vain ensiversion kehitykseen – joko väärin ymmärrettynä tai tietoisesti. Oikein ymmärrettynä Scrum ja DevOps, joka korostaa yhteistyötä kehityksen ja ylläpidon välillä, ovat käytännössä synonyymejä tuotteen elinkaariajattelussa.
Kolme asiaa pohdittavaksesi
1. Kuka näkee projektin ja kuka tuotteen?
Projekti näkyy vain tekijöilleen, mutta tuote on loppukäyttäjän käsissä. Keskittykää projektien hallinnoinnin sijaan siihen, mikä vaikuttaa käyttäjien tyytyväisyyteen.
2. Miten tiimien pysyvyys vaikuttaa tuloksiin?
Pysyvät tiimit kehittävät omistajuuden tunnetta, pitkäjänteisyyttä, reagointikykyä ja syvää osaamista, joka parantaa käyttäjäkokemusta ja optimoi tuotteen elinkaaren kustannuksia.
3. Voiko projektirahoituksen muuttaa tuotteen (tiimin) rahoitukseksi?
Kun projektibudjetin ajattelee pysyvän tuotetiimin rahoituksena, osaaminen säilyy ja kehittyy tiimissä. Eikä aikaa ja rahaa kulu aina uuden projektipäällikön ja tiimin kilpailutukseen ja palkkaamiseen.
Pitkäjänteinen aika- ja materiaalipohjainen ketterä puitesopimus (jossa ostetaan asiantuntijoiden aikaa eikä etukäteen määriteltyä sisältöä) johtaa 2-3 kertaa todennäköisemmin parempaan lopputulokseen varsinkin, jos tuotekehitystä ostetaan toiselta organisaatiolta.
VIISI TAPAA TUKEA TUOTEAJATTELUUN SIIRTYMISTÄ
- Siirtykää tuoteorganisaatioon: Agile Product Operating Model
- Tunnistakaa tuotteet ja palvelut asiakkaiden näkökulmasta. Hyvä tuote ratkaisee asiakkaan ongelman ja asiakas on valmis maksamaan siitä.
- Määrittäkää pysyvät tuotetiimit, jotka sisältävät tarvittavan osaamisen tuotteen jatkokehitykseen ja ylläpitoon. Tiimin vaihtaminen kannattaa kuitenkin tehdä asiantuntijoille mahdollisimman joustavaksi.
- Kouluttakaa projektipäälliköistä tuotepäälliköitä. He vastaavat tuotteensa koko elinkaaresta eikä vain yhdestä julkaisusta. Scrumin tuoteomistajaksi kannattaa valita mahdollisimman kokenut ja ketteryyttä tunteva tuotepäällikkö.
- Kannustakaa asiantuntijoita jakamaan osaamistaan. Jos asiantuntijan on "pakko" työskennellä useamman tuotteen tai projektin parissa, rajatkaa määrä enintään kahteen. Näin työaika ei kulu projektista toiseen siirtymiseen.