Ketterä tuotehallinta: prosessien ja roolien opas &

Agile-tuotehallinnasta on saatavilla paljon sisältöä, oppaita, oppikirjoja, kursseja ja sertifiointeja. Rehellisesti sanottuna et tarvitse niitä kaikkia.

Perimmiltään Agile-tuotehallinta perustuu yksinkertaiseen, ihmislähtöiseen filosofiaan. Monet prosesseista, joissa Agile ilmenee, ovat yksinkertaisia ja helposti ymmärrettäviä. Monimutkaisuus syntyy kuitenkin väärin ymmärretyistä odotuksista, rooleista ja prosesseista.

Tässä oppaassa:

• Tutustumme tuotehallintaan Agilen näkökulmasta, sen filosofiaan ja prosesseihin, joissa se saa muotonsa.
• Tarkastelemme tyypillisen Agilea hyödyntävän tuotekehitystiimin muodostavia rooleja, niiden sisältöä ja yhteistyötä.

Näiden keskeisten alueiden ymmärtäminen on tärkeää. Se tarjoaa sinulle työkalut Agile-tuotehallinnan toteuttamiseen tai parantamiseen tiimissäsi tai organisaatiossasi.

Mitä Agile-tuotehallinta on?

Agile on filosofia siitä, miten tiimit voivat tehdä tehokkaasti yhteistyötä tavoitteen saavuttamiseksi. Vuonna 2001 julkaistu alkuperäinen Agile-manifesti ilmaisee Agilen periaatteet parhaiten:

• Yksilöt ja vuorovaikutus prosessien ja työkalujen sijaan
• Toimiva ohjelmisto kattavan dokumentaation sijaan
• Yhteistyö asiakkaan kanssa sopimusneuvottelujen sijaan
• Muutokseen vastaaminen suunnitelman noudattamisen sijaan

Siinä on Agile-tuotehallinnan ydin. Siinä ei mainita tarinapisteitä tai työjonoja. Ei päivittäisiä tilannepalavereita tai sprinttejä.

Vaikka Agile-manifesti ei määrää käyttämään prosesseja ja työkaluja, se vähättelee niiden merkitystä ja suosii ihmiskeskeistä, mukautuvaa yhteistyötä. Kun lähestyt Agile-tuotekehitystä ensimmäistä kertaa (tai haluat kerrata perusteita), voi olla valaisevaa aloittaa perusteista eli manifestista.

Kun siirrymme käsittelemään Agilen käytännön toteutusta, on tärkeää pitää manifesti edelleen mielessä. Prosessit, dokumentaatio ja suunnittelu ovat kaikki hyödyllisiä. Jos kuitenkin huomaat, että sinä tai tiimisi asetatte ne tiiminne tai toimivan tuotteen edelle, tähän kannattaa kiinnittää huomiota.

Tarkastellaan seuraavaksi joitakin Agile-tuotekehityksen ajattelutavan hienovaraisempia puolia.

Ihmiskeskeinen

Agile-ohjelmistokehityksessä keskitytään voimaannuttamaan tuotekehitystiimin muodostavia ihmisiä. Jotta voit soveltaa sitä hyvin, sinun on todella luotettava kanssasi työskenteleviin ihmisiin. Ilman luottamusta tiimisi psykologinen turvallisuus on vaarassa ja tuottava yhteistyö voi horjua.

Käyttäjäkeskeinen

Käyttäjiin keskittyminen herpaantumatta on välttämätöntä. Emmekö nimittäin rakenna tuotteita juuri heitä varten?

Tehokas Agile-tiimi haastattelee jatkuvasti käyttäjiä saadakseen palautetta tuotteistaan. Tiimi lähettää kyselyitä ja käsittelee niiden vastauksia ohjatakseen uusien ominaisuuksien kehittämisen priorisointia. Agile-tuotepäälliköt etsivät aina tapoja jakaa työ pieniksi, julkaistaviksi kokonaisuuksiksi, joita voidaan validoida käyttäjien kanssa työn edetessä, samalla kun he pyrkivät välttämään ominaisuuksien hallitsematonta lisääntymistä.

Jos käyttäjiä ei kutsuta säännöllisesti mukaan, se mitä suunnittelemme tänään, voi olla huomenna jo vanhentunutta.

Haastava

Agile-tuotehallinta on uskomattoman haastavaa, mutta ei ehkä niistä syistä, joita voisi odottaa.

Tehokkailla Agile-tiimeillä on yleensä vähemmän prosesseja ja muodollista raportointia kuin muilla kuin Agile-tiimeillä. Tämä johtuu siitä, että Agile keskittyy jatkuvaan työvirtaan ja läpinäkyvyyteen sekä asettaa yhteistyön yksittäisten virstanpylväiden edelle.

Prosessien puuttumiseen liittyy monille tuotepäälliköille myös tunne kontrollin puutteesta. Heillä on kuitenkin edelleen rooliinsa liittyvä suuri vastuu. Itsensä tasapainottaminen niin, ettei ylitä rajojaan ja häiritse tiimin keskittymistä, on taitolaji, joka voi vaihdella tiimistä toiseen dynamiikan mukaan.

Kun tuotepäällikkö kuitenkin omaksuu palvelevan johtajan lähestymistavan, pitkällä aikavälillä voidaan saavuttaa enemmän hyötyjä — ja ironisesti myös enemmän kontrollia —  kuin muilla tavoin. Tämä johtuu hyödyistä, joita luottamukseen perustuvien Agile-prosessien määrätietoinen hyödyntäminen voi tuottaa.

On myös ihanteellista, että työskentelykulttuuri tukee ketteryyttä. Tällaisessa kulttuurissa on mahdollista aloittaa ilman ketteryyden tukea, mutta se on haastavampaa ja huomaat toimivasi vastavirtaan. Ketteryyttä tukeva organisaatio suhtautuu tarkoituksella ylimalkaisiin suunnitelmiin luontevasti, koska se ymmärtää suunnitelmien tarkentuvan ajan myötä.

Lean-ajattelu

Lean-ajattelun soveltaminen käytännössä on ratkaisevan tärkeää. Tuloksiin keskittyminen pitää ketterät tiimit liikkeessä kohti tavoitetta vähäisin häiriötekijöin. Keskittymällä pienimpään mahdolliseen työmäärään, jolla tavoite voidaan saavuttaa, tiimi pystyy jatkamaan etenemistä ja saavuttamaan markkinamenestyksen mahdollisimman nopeasti.

Ketterän kehityksen työnkulku

Ennen kuin perehdymme muutamiin erityisiin prosesseihin, joita voit käyttää ketterän tuotehallinnan käyttöönottoon, käsitellään yleistä prosessin kulkua ja ketterän menetelmän vaiheita, joita useimmat prosessit noudattavat. 

Aiheeseen liittyvää luettavaa: Ketterän tuoteportfolion hallinnan periaatteiden käyttöönotto

Strategia

Erinomainen ketterä kehitys alkaa hyvästä strategiasta ja yhteisestä suunnasta. Kun kaikki tiimin jäsenet tuodaan samaan huoneeseen (tai Zoom-kokoukseen), voidaan saavuttaa paljon yhtenäisen tuotevision ja suunnan luomisessa. Harkitse kiinnostavan visuaalisen yhteistyöohjelmiston käyttöä, jotta ihmiset eivät menetä mielenkiintoaan.

Tämä voi antaa tiimille mahdollisuuden muodostaa yhteinen näkemys liiketoimintasuunnitelmasta, visuaalisesta suunnasta, kohdekäyttäjistä ja muusta. Se toimii tiimille tärkeänä yhteisenä lähtökohtana, johon keskittyä.

On tärkeää huomata, että tänä aikana laadittuja suunnitelmia ja dokumentaatiota käsitellään oletuksina. Niitä on tarkoitus tarkastella ja kehittää säännöllisesti ajan myötä.

Kokeilu

Kaikki on kokeilua. Heti alussa ensimmäinen keskittynyt työvaihe kannattaa rajata ajallisesti ja testata sitten käyttäjillä. Työ voi olla hyvin alkeellista, jopa niinkin yksinkertaista kuin karkeat luonnokset, jotka käyt jonkun kanssa läpi.

Tarkoituksena on lähestyä työtä tieteellisen menetelmän mukaisella ajattelutavalla. Olemme tietotyöläisiä, joten keskitymme muuhunkin kuin pelkkään toteutukseen. Keskiössä ovat myös tiedon luominen ja uuden löytäminen.

Testaus

Jokainen kokeilu tulee testata laadullisesti ja määrällisesti. Kun tarkastelet tuloksia säännöllisesti, sinulla on tarvittavat välineet vahvistaa, että tiimisi rakentama tuote tuottaa arvoa ja hyväksytään markkinoilla.

Validointi

Kun julkaiset uuden ominaisuuden käyttäjille, seuraa sen tilannetta jatkuvasti. Käytetäänkö sitä? Löytävätkö ihmiset sen? Onko tämän ominaisuuden käyttöönotto vaikuttanut myönteisesti tai kielteisesti tuotteesi muihin osa-alueisiin?

Julkaisemiesi ominaisuuksien säännöllinen tarkastelu ja seuranta sen jälkeen, kun ne ovat "valmiita", antaa lisää välineitä ja ohjeita entistä parempien päätösten tekemiseen.

Toistaminen

Tämä on tärkein vaihe. Palaa jatkuvasti ketterän prosessin kulkuun kuin moottoriin. Tämä kulku on tarkoituksella syklinen, ei lineaarinen, jotta oppiminen olisi mahdollista. Opi siitä. Muuta toimintaasi sen perusteella. Juhlista sitä. Omaksu muutoksen virta.

2 yleistä ketterää lähestymistapaa

Ketterä ajattelu on voimaannuttava filosofia, joka yhdistää tiimit yhteisen tavoitteen ympärille yhteistyöhön perustuvilla tavoilla, jotka eivät ole mahdollisia liian rakenteistetuissa prosesseissa ja raportoinnissa.

Jotkin prosessit ovat kuitenkin hyödyllisiä. Kun prosessit toteutetaan asianmukaisesti ja niitä käytetään tiimin ainutlaatuisen kulttuurin huomioiden, ne voivat toimia kaiteina, jotka pitävät tiimin keskittyneenä tavoitteiden saavuttamiseen ja tukevat samalla luovaa vapautta.

Perehdymme seuraavaksi joihinkin suosituimpiin prosesseihin, jotka muuttavat ketterän ajattelun käytännön toiminnaksi.

Scrum

Scrum on ehkä suosituin ketterä prosessi, ja hyvästä syystä: se jakaa sitoumukset ja oppimisen omiin työskentelyn ajanjaksoihin, joita kutsutaan "sprinteiksi". Tämä edistää tervettä oppimisen määrää ja tarjoaa enemmän mahdollisuuksia mukautua opittuun.

Näiden sprinttien keskiössä on itse scrum-tiimi. Scrumissa ei ole nimikkeitä: jokaisella tiimin tuottajalla on "kehittäjän" rooli. Tämä kannustaa tiimiä keskittymään voimakkaasti yhteistyöhön ja kunkin sprintin tavoitteen saavuttamiseen. 

Käytännössä tämä tarkoittaa, että jos testausinsinööri odottaa testattavaa ominaisuutta, hän voi käyttää aikaa uuden ominaisuuden koodaamiseen. Tämä monialainen ajattelutapa on parhaimmillaan uskomattoman tehokas, koska sen ansiosta tiimi voi saavuttaa erinomaisia tuloksia.

Scrumin tavoitteena on minimoida kokousten määrä, jotta kehitystyölle jää mahdollisimman paljon keskittynyttä aikaa. Tätä varten käytössä on joukko toistuvia kokouksia eli seremonioita:

• Sprintin suunnittelu: Käytetään suunnittelemaan työ, johon tiimi haluaa sitoutua seuraavan sprintin aikana.
• Sprintin katselmointi (demo): Aika, jolloin esitellään toisille tiimin jäsenille ja sidosryhmille saavutettu edistys sekä käydään läpi opitut asiat.
• Sprintin retrospektiivi: Avoin tilaisuus, jossa tiimi tarkastelee edellistä sprinttiä ja keskustelee siitä, mikä sujui hyvin, mikä ei sujunut ja missä olisi mahdollisuuksia kehittyä.
• Työjonon jalostaminen ja arviointi: Tämä on toistuva ajankohta, jolloin jatkuvasti muuttuvaa tuote-työjonoa tarkastellaan ja priorisoidaan liiketoimintaa ja teknisiä oppeja hyödyntäen. Kun työjonon kohteista on päästy yhteisymmärrykseen, ne arvioidaan suunnittelua varten.
• Päivittäiset tilannepalaverit: Päivittäinen ajankohta, jolloin tiimi kertoo, mitä se sai eilen valmiiksi, minkä parissa se työskentelee tänään ja estääkö jokin asia työn etenemisen.

Jotta sprinttiin keskittyvä työ voidaan yhdistää kokonaisuuteen, scrum kannustaa käyttämään arvioinnissa ”tarinapisteitä” rakenteellisten sprintin suunnittelutilaisuuksien avulla. Ne ovat tiimin kullekin työjonon kohteelle määrittämä mielivaltainen työmäärän taso.

Tämän menetelmän erityinen vahvuus on, että se tukee nopeuden seurantaa. Sillä tarkoitetaan tarinapisteiden keskimääräistä määrää, jonka tiimi saa valmiiksi kunkin sprintin aikana. Muutaman ensimmäisen sprintin jälkeen tämä luku pitäisi saada kohdalleen, ja sitä voidaan käyttää kohdennettuun julkaisujen ennustamiseen ja suunnitteluun.

Jos näitä työkaluja käytetään tiimin kanssa huolellisesti ja kokenut scrum-mestari ohjaa toimintaa, scrum voi olla tehokas prosessi, joka tukee keskittynyttä ketterää kehitystä ja tarjoaa runsaasti mahdollisuuksia tehokkaaseen iterointiin.

Kanban

Kanban lainaa paljon scrumista ja sisältää monia tuttuja elementtejä, kuten työjonon jalostamisen, sprinttitaulua muistuttavan taulun ja paljon muuta.

Scrum keskittyy pieneen määrään työtä, kun taas kanban painottaa jatkuvaa työvirtaa.

Prosessin keskeinen osa on kanban-taulu. Kohteita priorisoidaan jatkuvasti vasemmalla, ja ne siirtyvät tiimin mukautetun prosessin läpi oikealle päätyen tilaan ”valmis”. Työkuorman tasapainottamiseksi kullakin sarakkeella voi usein olla keskeneräisen työn (WIP) rajoite, joka määrittää, kuinka monen tehtävän parissa voidaan työskennellä samanaikaisesti.

Kanban sopii erinomaisesti tukityöhön tai tiimeille, joilla on epäsäännölliset mahdollisuudet sitoutua työhön.

SAFe, XP ja muut

Ketteristä prosesseista on olemassa monia muitakin muunnelmia, joista kukin sopii tiettyihin organisaation tarpeisiin ja kulttuurisiin normeihin.

SAFe on kattava ketterä järjestelmä ketterän toimintatavan käyttöönottoon organisaation laajuisesti, tyypillisesti suuressa yrityksessä. Se koostuu useista ”ketteristä julkaisujunista”, jotka ovat käytännössä yksittäisiä scrum-tiimejä. Mukana on useita rooleja ja seremonioita, joiden avulla varmistetaan, että kaikki tiimit työskentelevät yhteisten organisaation tavoitteiden ja julkaisusuunnitelmien mukaisesti.

Ääriohjelmointi (XP), DevOps, Modern Agile ja muut menetelmät on kehitetty ketterän toimintatavan käyttötapauksiin, jotka liittyvät tiettyihin rooleihin tai kulttuureihin.

Erilaisten ketterien käytäntöjen kokeileminen on hyödyllistä. Se voi auttaa ymmärtämään tehokkaasti, mikä toimii juuri sinun organisaatiossasi.

Ketterän tuotehallinnan sertifikaatit

Olet todennäköisesti nähnyt lukuisia sertifikaatteja, joita voi suorittaa tiettyyn ketterään prosessiin liittyen. Niitä markkinoidaan tavalla, joka saa sinut uskomaan, että kyseinen prosessi on ainoa oikea tapa ja ettet pysty todella käyttämään prosessia ilman kalliin sertifikaatin suorittamista.

Jätä se huomiotta.

Ihannetapauksessa tämä opas antaa sinulle riittävästi vauhtia oman oppimispolkusi aloittamiseen. Ketterät menetelmät ovat käytännön työkalupakki, eivät jotain, josta sinua tullaan testaamaan. Kullekin prosessille ominaisen prosessin, seremonioiden ja dokumentaation tuntemus on arvokasta, mutta palataksemme manifestiin, on tärkeämpää ottaa tiimisi mukaan valitsemasi ketterän prosessin käyttöönottoon. On olemassa organisaatioita, jotka keskittyvät sertifiointien luomiseen ja ylläpitämiseen; niiden etujen mukaista on luonnollisesti edistää prosessia ihmisten sijaan.

Onko se todella ketterää?

Kaikki tämä tarkoittaa sitä, että kyseessä on yksinkertaisesti varoitus omalle ketterän oppimisen matkallesi. Sertifioinneista voi olla hyötyä. Jos osallistut työpajaan, se voi olla kohdennettu tapa oppia nopeasti tietyn prosessin kaikki yksityiskohdat. Jotkin organisaatiot arvostavat sitä, että olet sertifioitu, koska se auttaa rakentamaan luottamusta nopeasti.

Jos sertifioinnin hankkiminen auttaa sinua saavuttamaan haluamasi lopputuloksen ja sen saavuttaminen vaatii vain vähän vaivaa, hanki se. Jos et kuitenkaan tarvitse sertifiointia, kokeilu ja jatkuva oppiminen ketteryyden toteuttamisesta ovat tehokkain polku ketterällä matkallasi.

Aiheeseen liittyvää: 4 parasta verkossa suoritettavaa ketterän tuotehallinnan sertifiointia

Mitä ovat ketterän tuotekehityksen roolit?

Ketteriä prosesseja käsitellessämme olemme alkaneet nimetä keskeisiä rooleja, joista ketterä tuotekehitystiimi muodostuu. Näihin rooleihin kuuluvat:

• Tuotepäällikkö
• Tuoteomistaja
• Kehittäjä
• Suunnittelija
• Testausinsinööri / QA

Jokaisella organisaatiolla on yleensä oma tapansa määritellä nämä roolit. Esimerkiksi tuotepäällikön vastuut yhdessä yrityksessä saattavat vastata paremmin tuoteomistajan vastuualuetta toisessa yrityksessä. Kun tämä joustavuus pidetään mielessä, tarkastellaan seuraavaksi joitakin laajempia määritelmiä, jotka havainnollistavat tuotetiimin rooleja.

Tuoteomistajien, tuotepäälliköiden ja projektipäälliköiden roolit menevät usein osittain päällekkäin, ja tiimeissä voi olla yksi, kaksi tai kaikki kolme roolia. Tuotepäälliköt tai tuoteomistajat ottavat usein projektinhallinnan vastuulleen, jos tiimissä ei ole projektipäällikköä.

Tuotepäällikkö

Eli mitä tuotepäällikkö tekee? Tuotepäällikkö vastaa tuotteen – no, tuotteen hallinnasta.  Tuotehallinnan roolin keskeinen vastuu on varmistaa, että kaikki on linjassa keskeisten tulosten saavuttamiseksi käyttäjätestauksen, tiimin näkemysten ja strategisen suunnittelun perusteella.

Tehokkaassa tuotehallinnassa on kuitenkin kyse tuotetiimin voimaannuttamisesta. Siksi tuotepäällikön rooli on generalistinen. Toisin sanoen tuotepäällikön on pystyttävä hyödyntämään laaja-alaisesti erilaisia taitoja ollakseen tehokas, mutta hänen ei välttämättä tarvitse olla taitava kehittäjä tai suunnittelija (vaikka onkin tavallista, että tuottajan roolista siirrytään tuotehallintaan).

Generalistin taidot auttavat tuotepäällikköä toimimaan empaattisena palvelevana johtajana tiimilleen. Kun tuotepäällikkö ymmärtää juuri riittävästi siitä, mitä kehittäminen vaatii, hän voi auttaa ohjaamaan tiimiä kohti tehokasta tuotteen määrittelyä ja suunnittelua puuttumatta samalla tiimin osaamiseen.

Aiheeseen liittyvää luettavaa: Miksi tuotehallinta on tärkeää

Tuotepäällikön vastuut

• Tuotteen tulokset
• Tuotteen kehitysjonon hallinta
• Sidosryhmien hallinta
• Käyttäjätestaus
• Käyttäjätarinoiden kirjoittaminen
• Monialaisen tiimin fasilitointi
• Tuotteen tiekartan hallinta
• Tuoteanalytiikka

Tuoteomistaja

Siinä missä tuotepäällikkö vastaa tuotteen taktisesta menestyksestä, ketterä tuoteomistaja on vastuussa tuotteen liiketoiminnallisesta ja markkinamenestyksestä.

Yleensä tuoteomistaja on keskeinen liiketoimintarooli, joka voi joskus olla tuotetiimin keskeinen sidosryhmä. Hänen markkinatuntemuksensa ja 50,000ft:n näkökulmansa liiketoimintaan tekevät hänestä tärkeän ja asiantuntevan resurssin, joka auttaa optimoimaan tuotetiimin menestystä varten. 

Tuoteomistajan vastuut

• Tuotteen menestys 
• Markkinatutkimus ja -tuntemus
• Liiketoiminnan kehittäminen
• Rahoitus
• Tasatilanteen ratkaisija

Yleinen haaste on tuoteomistajan ja tuotepäällikön roolien päällekkäisyys ja erot. Joskus tämä rooli on osa tuotepäällikön roolia ja päinvastoin. Kun nämä kaksi roolia ovat erillisiä, niiden vastuualueet ovat usein osittain päällekkäisiä. Jotkin organisaatiot jopa vaihtavat tuotepäällikön ja tuoteomistajan roolien vastuita keskenään.

Tämä on kuitenkin ihan hyväksyttävää!

Mahdollisista haasteista huolimatta nämä roolit voivat yhdessä työskennellessään löytää terveen tasapainon toisiaan täydentävälle yhteistyölle, mikä voi johtaa erinomaisiin tuloksiin. Esimerkiksi toinen rooli voi keskittyä väsymättä tuotteeseen, kun taas toinen keskittyy liiketoimintaan. Toinen voi keskittyä tuotteen yksityiskohtiin, kun taas toinen keskittyy markkina-asemointiin kokonaiskuvan tasolla.

Kun nämä kaksi roolia sitten yhdistetään yhteistyöhön, voi sattumalta syntyä mullistavia strategisia oivalluksia, jotka vaikuttavat myönteisesti tuotteen ja tiimin menestykseen. Onhan kaksi päätä parempi kuin yksi!

Kehittäjä

Tehokkaassa tuotetiimissä kehittäjän rooli ei rajoitu pelkästään koodin kirjoittamiseen, vaan kehittäjä tekee yhteistyötä kaikkien roolien kanssa strategisessa ja teknisessä suunnittelussa sekä suositusten laatimisessa.

Vahvan tuotekehitystyökalujen, käyttäjien tarpeiden ja tuotteen sekä markkinoiden tavoitteiden tuntemuksen avulla kehittäjät pystyvät luomaan tuotteeseen täydellisesti sopivan teknisen suunnitelman. Kehitystiimin jäsenten varustaminen tällä tietämyksellä ja valmiudella tehdä keskeisiä teknisiä päätöksiä voi merkitä eroa kuukauden mittaisen kehitysaikataulun ja moninkertaisesti pidemmän aikataulun välillä, sillä näihin päätöksiin liittyy teknisiä kompromisseja.

Kun kehittäjät integroidaan kehitystiimin tuotteeseen liittyvään osa-alueeseen, he voivat moninkertaistaa tiimin menestyksen.

Kehittäjän vastuut

• Tuotekehitys
• Tekninen suunnittelu ja tutkimus
• Teknologia-arkkitehtuurin konsultointi
• Toiminnallinen prototypointi
• Yksikkötestaus
• DevOps (joskus erillinen rooli)
  • Julkaisuputken luominen ja hallinta

Suunnittelija

Aivan kuten kehittäjiä ei pitäisi rajoittaa pelkästään koodin kirjoittamiseen, suunnittelijoiden vaikutusalueen tuotetiimissä tulisi ulottua suunnittelun luomista laajemmalle. Itse asiassa parhaat yhteistyötilanteet tuotetiimissä syntyvät usein suunnittelijan ja tuotepäällikön roolien välisessä yhteistyössä.

Tuotetiimien suunnittelijat aloittavat tarkastelemalla strategisesti tuotestrategiaa ja liiketoimintaa. He ovat usein tiimin vahvimpia käyttäjien tarpeiden puolestapuhujia. Näiden oivallusten avulla he voivat sitten suunnitella, tosin kohdennetusti.

Kehityksen tehokkuuden ja oppimisen mahdollistaminen on suunnitteluroolien keskeinen painopistealue. Suunnittelujärjestelmien luominen auttaa kehittäjiä rakentamaan uusia ominaisuuksia nopeasti jatkuvan integraation työnkulkujen avulla. Vuorovaikutteisten ja visuaalisten prototyyppien rakentaminen mahdollistaa käyttäjätestauksen ennen kuin riviäkään koodia on kirjoitettu, mikä auttaa vahvistamaan lisäinvestointien tarpeen.

Suunnittelijan vastuut

• Tuotesuunnittelu
• Luonnokset
• Prototypointi
• Tyylioppaan luominen
• Suunnittelujärjestelmän luominen ja tukeminen
• Käyttäjätestaus yhteistyössä tuotepäällikön kanssa
• Jatkuva käyttäjätutkimus

Testausinsinööri / laadunvarmistus

Testausinsinööri (josta käytetään joskus nimitystä laadunvarmistus eli QA) voi olla yksi tuotetiimin vaikuttavimmista rooleista. Vaikka heidän pääpainopisteensä on tuotteen ominaisuuksien testaamisessa ennen niiden julkaisemista käyttäjille, heidän tarkka silmänsä voi auttaa selkeyttämään tiimin painopisteitä ennen uuden ominaisuuden rakentamista.

Testausinsinöörien tulisi olla mukana tuotekehityksen varhaisimmista vaiheista lähtien. Näin he voivat määritellä tuotteen käyttäjätarinoille hyväksymiskriteerit, jotka ohjaavat muuta tiimiä työn loppuun saattamisessa.

Käyttäjälähtöisen ajattelutavan ansiosta testausinsinöörit voivat ennakoida tulevan julkaisun mahdollisia seurauksia. Kun tämä rooli voi neuvoa tuoteomistajaa strategisesti, sillä voi olla konkreettinen vaikutus uuden käyttäjille suunnatun julkaisun liiketoiminnalliseen onnistumiseen tai epäonnistumiseen.

Testausinsinöörin/QA:n vastuut

• Toiminnallinen testaus
• Regressiotestaus
• Tutkiva testaus
• Hyväksymiskriteerien määrittely
• Jatkuva riskien arviointi ja analysointi

Muut roolit

Vaikka aiemmin mainitut roolit muodostavat tuotetiimin, tiimin ulkopuolella on monia rooleja, jotka tukevat tiimin tuloskeskeistä toimintaa.

Näihin rooleihin kuuluvat markkinointi, myynti, asiakastuki ja monet muut. Yleensä nämä roolit tuodaan organisaatioon tukemaan tuotetta, kun markkinoilla saavutetaan menestystä. Tyypillisesti ne eivät kuulu tuotetiimiin. Vahva ja yhteistyöhön perustuva suhde näihin rooleihin auttaa kuitenkin edelleen edistämään liiketoiminnan menestystä.

Yhteistyö

Vaikka jokaisella roolilla on tuotetiimissä oma asiantuntemusalueensa, oletuksena on, että kaikki tekevät yhteistyötä. Kun jokainen rooli tuo tiimiin "T-muotoisen" ajattelutavan, kaikki voivat tuoda erityisosaamisensa yhteiseen pöytään ja samalla omaksua keskittymisen tuotteeseen osana omaa roolimäärittelyään. Kaikki menevät syvälle omaan asiantuntemukseensa ja samalla laajalle kaikkiin muihin taitokokonaisuuksiin löytääkseen menestyksen yhdessä yhtenä yksikkönä.

Yhteistyö tuotetiimissä tarkoittaa jatkuvaa keskittymistä tuotteen tuloksiin ja käyttäjäkokemukseen. Kaikki osallistuvat tämän vision saavuttamiseen ja etenevät yhdessä yhtenäisenä tiiminä.

Yhteenveto

Tärkeimmät opit

• Ketteryyslähtöinen tuotehallinta on ihmisiin ja käyttäjiin keskittyvä filosofia, jonka avulla oikea lopputulos toimitetaan nopeammin.
• Vaikka ketteryys on pohjimmiltaan yksinkertaista, prosessit, organisaatiokulttuuri ja monet muut tekijät tuovat mukanaan monimutkaisuutta ja haasteita.
• Ketteriä prosesseja ja rooleja voidaan ohjata esimerkiksi scrumin, kanbanin ja SAFe-mallin kaltaisilla prosesseilla.
• Ketterän tuotetiimin muodostaviin rooleihin kuuluvat kehittäjät, suunnittelijat, testausinsinöörit, tuotepäällikkö ja tuotteen omistaja.

Ketteryyslähtöinen tuotehallinta on uskomattoman ja tarkoituksellisesti yksinkertaista. Se on voimakas filosofia, joka voi moninkertaistaa tiimisi luoman arvon. Mitä syvemmälle kuitenkin perehdyt sitä tukeviin prosesseihin ja rooleihin, sitä monimutkaisemmaksi se saattaa muuttua.

Tämän monimutkaisuuden keskellä piilee mahdollisuuksia, joiden avulla voit vahvistaa tuotteesi tiimiä ja organisaatiota. Näiden taktiikoiden hyödyntäminen tiimisi kanssa on tasapainoilua, sillä samalla on varmistettava, etteivät ne aiheuta tahatonta organisaation hidastumista normaalin yhteistyön aikana.

Hyvin toteutettuna ja kokeilevaan asenteeseen yhdistettynä ketteryys voi kuitenkin ohjata tuotetiimisi menestyksen tulevaisuutta.

Oletko nähnyt ketteryyttä toteutettavan tai onko sinulla kokemusta siitä? Onko se ollut samanlaista vai erilaista kuin tässä oppaassa kuvataan? Kerro meille kommenteissa! Muista myös tilata tuotepäälliköille suunnattu uutiskirjeemme, niin saat lisää näkemyksiä ja oppaita.

Voit myös jatkaa oppimista tutustumalla tähän podcastiin, jonka voit kätevästi lukea, katsoa tai kuunnella: Yhdenmukaisuus tuotesuunnitelmien avulla (Brandon Blackman Cremasta)

Aiheeseen liittyvää luettavaa:

• Mikä on ketterä epikki? Parhaat käytännöt, mallipohja ja esimerkki
• Näin rakennat ketterän tuotesuunnitelman
• Ohjelmiston julkaisun elinkaari (SRLC): tutustu kuuteen päävaiheeseen

Tutustu myös näihin:

• Kuinka monday.comia käytetään tuotehallintaan
• Kuinka laatia tehokas ketterän tuotepäällikön työnkuvaus (+esimerkki)
• 15 parasta tuotetoimintojen priorisoinnin viitekehystä: mikä on paras?
• 8 ominaisuuslippujen parasta käytäntöä, jotka sinun pitäisi tuntea
• Ilmaiset tuotteen tiekarttamallit sidosryhmiisi vaikutuksen tekemiseksi
• Kuinka kirjoittaa tehokkaat ohjelmiston julkaisutiedot, jotka ilahduttavat käyttäjiä
• Visuaaliset raportointityökalut tuotetiedoille
• Kanban-työkalut tuotehallintaan