Monologi kostautuu tuotekehityksessä

Viimeviikolla tutustuimme projektiin, joka oli kuukauden myöhässä määräajasta. Koska raha ajaa yritysten toimintaa ja testauksen tulee aina olla investointi päätimme selvittää mistä oli kysymys: Haastattelimme projektiryhmää.

Tuotekehityksen sykli yrityksessä oli kokonaisuudessaan 3 kuukautta ja testaus painottui syklin loppuun. Haastattelun jälkeen saatoimme todeta, että syklin loppusuoralla löydettyjen bugien määrä oli, kuten aina, yllättänyt tuotekehityksen housut kintuissa. Bugien määrä ei kuitenkaan ollut suurin haaste. Ongelmien korjaaminen vain vei aina hämmentävän paljon aikaa. Mutta miksi niin kävi?

Ajatellaanpa tilannetta, kun Kauno Koodaaja rakentaa uuden ominaisuuden. Koodirivejä tulee paukuteltua helposti satoja. Kaunon elo-syyskuussa tuottama koodi päätyy testausvaiheeseen lokakuussa ja bugiraportteja alkaa tipahdella. Korjaustoimet voivat alkaa, mutta mitäpä luulette: Muistaako Kauno vielä mitä muutoksia koodiin tuli elokuussa tehtyä?

Onko ollenkaan ihme, että vanhojen koodirivien kaivelu vie paljon aikaa?

Totesimme, että sama ongelma vaivasi lähes systemaattisesti projekteja, joiden tuotekehityssyklit olivat pitkiä ja testaus painottui loppusuoralle. Ensin tuli koodauksen monologi, sitten testauksen vuoro. Tuotekehitys oli ja pysyi tahmeana. Ratkaisuvaihtoehtoja ongelmaan keksimme kaksi:

1. Nopeutetaan palautesykliä pakottamalla kehitys ja testaus vuoropuheluun
2. Budjetoidaan aina projektille pitkästi korjausaikaa ja toivotaan parasta

Ei varmaan tarvitse olla hirmuinen ruudinkeksijä, että arvaa kumman vaihtoehdon tuotekehityksen johto valitsi.

Tuotekehitys on aina tiimipeliä. Laatu on myös aikatauluissa pysymistä. Vain nopea dialogi testauksen ja kehityksen kesken voi tuottaa nopeita tuloksia.