Skip to content

Kehitysprojektin 5 heikkoa kohtaa

Olen vuosien varrella ollut mukana monessa kehitysprojektissa. Niiden koko on vaihdellut parin koodarin tuottamasta verkkopalvelusta satojen asiantuntijoiden tuotekehityshankkeisiin. Työtä on tehty enemmän tai vähemmän ketterästi erilaisia menetelmiä ja projektimalleja noudattaen.

Kaikille on ollut yhteistä luonnonlain tapaiset piirteet, joita alkaa löytyä projektin miesvahvuuden kasvaessa yli 10 henkeen tai organisaation jakautuessa useampaan tiimiin. Seuraavassa käydään läpi viisi yleisintä ominaisuutta.

project_cloud

1. Valitaan muodikas mutta epäsopiva menetelmä

Kaikki ohjelmistoprojektit noudattavat jotain kehitysmallia, vesiputouksesta ketteriin malleihin (esim. Scrum, Kanban, SAFe, XP). Jälkimmäiset ovat saaneet suosiota myös suuremmissa yrityksissä ja organisaatioissa. Kukapa ei haluaisi olla ketterä? Silti merkittävä osa varsinaisesta työstä tehdään vesiputousmallilla, koska organisaation rakenne, siiloutuminen ja yrityskulttuuri ei taivu ketteräksi.

Tässä ei ole mitään väärää, mikäli menetelmien yhdistely tehdään tietoisesti ja hallitusti. Ongelmat alkavat silloin, kun eri yksiköt ja toimijat käyttävät eri menetelmiä samassa hankkeessa. Julkaisuaikataulut vaihtelevat, versiot eivät sovi yhteen, tiimit tekevät omiaan ja lopulta kaikki odottavat toisiaan.

2. Tiedon jakaminen kangertelee

Tiedon kulku hidastuu ja pätkii ryhmän koon kasvaessa ja organisaation jakautuessa. Oman porukan asiat ja aikataulut ovat tiedossa, koska tieto kulkee kehitystiimin sisällä. Työskennellään samassa tilassa tai vähintään samassa tiedotuskanavassa. Muun organisaation tekemiset kuullaan viikko- tai kuukausikatsauksissa, jolloin ollaan jo auttamatta myöhässä.

Tiedotuksen tärkeyttä ei voi kylliksi korostaa, sillä mikään raportti tai tiedotussuunnitelma ei korvaa päivittäistä yhteydenpitoa. Tähän löytyy apu ryhmätyökaluista: wiki, pikaviestimet, jaetut kalenterit ja muut työtilat. Kuulostaa ilmeiseltä, mutta lähes kaikissa projekteissa joku jää jakelun ulkopuolelle, jollei asiaa mietitä ja ratkaista jo etukäteen.

3. Tuoteomistaja puuttuu

Kollegani Tuija Riekkinen kirjoitti omistajuudesta kaiken oleellisen. Tiivistän tässä, mitä omistajan puuttuminen tarkoittaa kehityshankkeessa. Tuotteen omistajuus ei ole asemasta juontuva kunniatehtävä, sillä siitä lankeaa aina myös vastuu. Omistajana ja tuotepäällikkönä sinä olet tuotteesi paras asiantuntija, joka tietää ja päättää, mitä sille tehdään ja milloin.

Liian usein tuotteen omistajaksi valitaan tyyppi, joka on sopivalla hierarkian tasolla – ja lähes aina liian kaukana kehityksen kohteesta. Omistajaksi ei muka kelpaa alempiarvoinen, vaikka juuri hän voisi olla paras valinta nimenomaan siihen tehtävään. Tästä pääsemme seuraavaan havaintoon.

4. Kehitysjono tai roadmap elää omaa elämäänsä

Yleensä projekteissa on jonkinlainen lista halutuista asioista. Ketterässä kehityksessä se on usein kehitysjono (backlog), jossa asiat ovat tärkeys- ja toteutusjärjestyksessä. Jonosta valitaan sopiva siivu jokaiseen kehitysjaksoon.

En liene ainoa, joka jatkuvasti joutuu painimaan ovista ja ikkunoista tunkevien pyytäjien kanssa. ”Ei ole teidän listalla, mutta olisi todella tärkeä bisneksen kannalta, ehtiikö vielä tälle viikolle?” Näin käy, kun hankkeella ei ole omistajaa, joka jämäkästi määrittelee, mitä tehdään kunakin kehitysjaksona (esimerkiksi sprint). Sovitusta pidetään kiinni.

Hövelisti lupaileva tai liian etäällä istuva omistaja voi aiheuttaa sen, että kaikki jonossa olevat asiat ovat yhtä tärkeitä. Mitään ei uskalleta siirtää seuraaviin julkaisuihin tai panna jonon pohjalle, koska hahmoton ”liiketoiminta” haluaa ne heti.

5. Resurssit ja tiimin tuottavuus arvioidaan väärin

Hullu mies Huittisista syö enemmän kuin tienaa. Sanonta pätee mainiosti ohjelmisto- ja palvelukehitykseen, jossa tuottavuuden arviointi perustuu aiempaan kokemuksen ja asianosaisten näkemykseen vaaditusta työpanoksesta suhteessa omaan tekemiseen ja annettuun aikarajaan. Tuottavuus arvioidaan aina liian myönteisessä valossa.

Työpanostaan miettivä ei usein ole riittävän rehellinen itselleen, eikä ota huomioon kaikkia työhön ja ajankäyttöön liittyviä tekijöitä. Esimerkki: jos tehtävä vaatii vaikkapa 2 työpäivää, työpanos lasketaan 8+8 tuntia ja luvataan valmista ylihuomiseksi. Välissä on kokouksia, paperitöitä, virheiden korjauksia ja syömässäkin pitäisi käydä.

Toinen helposti unohtuva asia on kehitysvaiheiden vaatima aika. Esimerkki: taitava koodari tekee valmiin komponentin päivässä. Tuoteomistaja ottaa tämän annettuna, mutta itse asiassa tuotantoon kelpaavan komponentin testaaminen, korjaaminen ja integrointi vaatii useita päiviä. Kun tähän lisätään vaikkapa käyttöliittymän kuvien ja tekstin viilaaminen sekä mahdollinen lokalisointi, alkuperäinen aikatauluarvio on mennyt syvälle metsään.

Yksikään edellä mainituista pulmista ei liity johonkin tiettyyn menetelmään, mutta silti kaikki kehitysprojektit törmäävät niihin. Jokainen viidestä ongelmasta olisi helppo välttää, kunhan niihin valmistautuu etukäteen ja pitää ne mielessä koko projektin ajan.

Henrik Hyyppä (kirjoittaja työskenteli Loihde Advancella syksyyn 2017)