Huomenta! Mikään ei vetristä palaveriputkien uuvuttamaa niskaa ja käynnistä uutta työpäivää paremmin kuin perinteinen Huonon Tuoteomistajan Aamujumppa:
- Mene peilin eteen
- Ota ryhdikäs asento
- Hymyile ja nyökyttele reilusti päätäsi
- Toista ääneen: ”Kyllä, kyllä, onnistuu, kyllä hoituu”
Tuoteomistaja pärjää parhaiten, kun sidosryhmät ovat sinuun tyytyväisiä, eli kun lupaat kaiken mitä he keksivät toivoa.
Hyvä tuotekehitys alkaakin viestimällä ylimmälle johdolle ja sidosryhmille kustannusten ja työn keston alustavat arviot kiveen kirjoitettuina.
Muista painottaa, että nämä ovat kehitystiimin lupauksia, oli tiimi sitten alihankkijalta tai omista kehittäjistä koostettu. Näin turvaamalla selustan hyvissä ajoin, turvaat myös omat onnistumisedelletyksesi. Ja jos aikataulut jostain syystä pettävät, niin onpahan jotain millä hiillostaa tekijöitä ja alihankkijoita.
Tarvitseeko tuoteomistajan osallistua seremonioihin?
Kuinka paljon tuoteomistajan tulisi varata aikaa kehitystiimin kanssa työskentelyyn? Kehityksenhän tekee kehitystiimi, joten voit hyvin olla tuoteomistaja muiden töiden ohella. Muutama palaveri per sprintti pitää istua, mutta niistäkin voit luistaa, jos jokin mielenkiintoisempi asia osuu samaan aikaan.
Yleensä pari viikkoa kestävä sprintti pitää sisällään seuraavat tapahtumat eli seremoniat:
Sprintin suunnittelu
- Erinomainen tilaisuus käydä kertomassa, kuinka tärkeitä jokainen työjonossa oleva tehtävä on.
- Varoituksen sana: Älä mene siihen lankaan, että antaisit kehitystiimin luistaa työmäärän arvioinnista, jokaiselle työjonon tehtävälle pitää löytyä vähintään vartin tarkkuudella työmäärälupaus.
- Tiimi voi kyllä hallita työjonon, hehän sitä työtäkin tekevät. Haukut sitten jälkeenpäin, jos tekivät vääriä asioita.
Sprintin katselmointi ja demo
- Tilaisuus, jossa tiimin sprintin suunnittelussa tekemät lupaukset punnitaan.
- Kun vaadit tuntiraportointi per tehtävä, voit varmistaa planningissä annettujen työmäärälupausten toteuman. Tunteja sinun on helpompi mitata kuin saavutettua arvoa, joten keskity siihen.
- Asetu sidosryhmäläisten kanssa eri puolen pöytää kuin tiimi ja arvostele rohkeasti esiteltävää toteutusta. Ohjaa sidosryhmäläisten palaute tiimille, älä ota sitä itseesi.
- Varoituksen sana: Sanoiko joku tehneensä refaktorointia? Sehän tarkoittaa, että kehittäjät ovat tehneet virheitä ja korjaavat näitä sinun budjetistasi!
Retrospektiivi
- Lähtökohtaisesti ylimääräinen palaveri, joka ei edistä tuotteen kehitystä. Jos näitä kuitenkin pidetään, niin vaadi päästä mukaan. Muutoin on se vaara, että tiimiläiset puhuvat sinusta pahaa.
- Muista että hyökkäys on paras puolustus, joten varmuuden vuoksi kannattaa heti retrospektiivin kärkeen ottaa luulot pois kehittäjiltä.
Dailyt
- Jälleen yksi liian usein pidettävä palaveri, jota sinä et ole kutsunut koolle. Osallistu kuitenkin mahdollisimman usein ja tartu mahdollisimman moneen yksityiskohtaan.
Vaikka näitä sprintin seremonioita onkin säännöllisesti, niin älä anna niiden sitoa luovuuttasi.
Kun jokin uusi idea tai vaatimus tulee kesken sprintin, niin älä epäröi viedä sitä ohituskaistalta kehitykseen. Tässä pieni oveluus on avuksi. Kuiskimalla tehtävän vain yhden kehittäjän korviin, voit varmistaa, että se myös tulee tehdyksi. Yhteiselle boardille näitä erityistehtäviä on turha tuoda.
Älä myöskään epäröi muuttaa tehtävien määrityksiä kesken sprintin, sillä muutoksiahan ketterä kehitys juuri rakastaa.
Päätökset ja työmäärän paras mittari
Vaikka päätökset ovatkin yksinoikeutesi, niin riittävällä lakeijajoukolla voit sementoida ne. Joten älä aliarvioi yli kymmenen hengen kokouksia, joissa päätöksiä voidaan vatuloida.
On tärkeää osallistuttaa mahdollisimman moni mukaan tekemiseen. Sillä ainoa keskijohdon työmäärän näkyvä mittarihan on ylibookattu kalenteri. Äläkä huolestu, vaikkei näissä palavereissa synny päätöksiä, sillä ainahan on seuraava palaveri.
Ja ennen kaikkea, anna itsellesi ja lakeijajoukolle aikaa miettiä pienimmätkin detaljit. Jos kehitystiimistä joku kysyy mielipidettä, niin älä mene siihen lankaan, että vastaisit heti. Lisäarvoa päätöksille voi luoda pienellä pohdinnalla – sanotaanko vaikka kolmen palaverin ajan.
Testaus ja valmis tuote
Testaamisessa moni kehitystiimi tekee sen virheen, että panostaa siihen liian vähän ja liian aikaisin.
Keskeneräistä tuotetta on turha testata, koska tämä vain luo bugihavaintoja kehityksessä olevista ominaisuuksista. Lähes valmiin tuotteen testaaminen onkin nopeampaa, koska tuote ei ole enää keskeneräinen ja bugeja on vähemmän. Toisaalta tuotteen julkaisun lähestyessä testausta tehdään usein liian vähän.
Peukalosääntönä voikin sanoa, että voit keskittää testauksen tuotekehityksen viimeiselle kymmenykselle, mutta tällöin tarvitset testaajia kaksi tai jopa kolme kertaa enemmän. Tämä voi kuulostaa budjettipainajaiselta, mutta jos suunnittelit käyttäväsi yhtä testaajaa kymmenen viikon hankkeessa jatkuvasti, niin nyt siis riittäisi kaksi tai kolme testaaja yhdeksi viikoksi.
Tämä testausmalli tietenkin vaatii sen, että tuote on hiottu erittäin kypsäksi ennen ensimmäistä julkaisua. Tässäkin on oma peukalosääntönsä: ”Kun tuote tuntuu valmiilta, niin hio sitä vielä hieman.”