X
Loading...
Ei hakutuloksia
Sisältö
Henkilöt
{ page.post_title }
{ page.titteli }
{ page.sahkoposti }
{ page.puhelinnumero }

Mistä on onnistuneet ohjelmistoprojektit tehty?

Lyhyen projektipäällikön urani (2009-), aikana olen päässyt vetämään sekä erittäin onnistuneita että vähemmän onnistuneita (ohjelmistokehitys)projekteja. Seuraavassa muutama havainto, joita olen jäänyt pohtimaan.

Onnistuneen ohjelmistoprojektin mittarit

Tietenkään ei ole yksinkertaista sanoa mikä on onnistunut ohjelmistoprojekti. Mittareina voidaan käyttää esimerkiksi aikataulua, työmäärää, toteutettuja ominaisuuksia tai viime kädessä asiakastyytyväisyyttä. Lienee selvää, että vaikka asiakas saisi täydellisesti aikataulussa kaikki tilatut ominaisuudet vieläpä alle arvioidun työmäärän, ei se ole tyytyväisyyden tae. Monesti projektia aloitettaessa ei asiakas, saati toimittaja, osaa kuvata toimitettavaa järjestelmää. Molempien osapuolien pitäisi pyrkiä määrittelemään projektin kuluessa oikea asiakastarve, sillä ilman sitä, ei todellista tyytyväisyyttä voida saavuttaa.

Osana asiakastarpeen määrittämistä vastuullisen toimittajan velvollisuus on tuoda ilmi itsensä kannalta myös epäedulliset havainnot. Projektin lähtökohdat voivat perustua väärille olettamuksille. Esimerkiksi markkinoilla saattaa olla valmiita ratkaisuja, jotka eivät ole asiakkaan tiedossa, mutta niiden avulla projektin kokonaiskustannus olisi huomattavasti pienempi. Mikä ei luonnollisesti ole lyhyellä tähtäimellä toimittajan etu.

Muutostenhallinta on tärkeä osa ohjelmistoprojektia

Sopimuksia tarvitaan vain epäonnistumisia varten. Käytännössä, koska etukäteen ei voida tietää mikä projekti epäonnistuu, toimittaja ja asiakas joutuvat turvaamaan omat etunsa mahdollisen riitatilanteen varalta. Projektin lähtökohtana omien etujen tiukka valvominen ja varautuminen mahdolliseen epäonnistumiseen on väärä, kuin maalaisi piruja seinille. Koska kuitenkin joudumme elämään sopimuksien ja liitteiden kanssa, joihin määrittely myös luetaan, tarvitsemme onnistuaksemme muutostenhallintaa. Kiinteä ohjelmistoprojekti ilman toimivaa muutostenhallintaa on tuomittu epäonnistumaan. Sopimus on yhdessä tehty, joten sitä voidaan myös yhdessä muuttaa.

Määrittelytyöllä on merkitystä

Asiakkaan merkitystä projektin onnistumiseksi ei voi vähätellä. Toteutettavaa ohjelmistoa tehdään asiakkaalle ja ratkaisemaan asiakkaan ongelmaa. Ilman asiakkaan aktiivista osallistumista tarpeen selvittämiseksi on projektilla suuri riski epäonnistua. Asiakas voi olla hyvinkin kokematon ohjelmistojen tilaaja, vaikka edustaa huippuosaamista omalla alallaan. Vaikka sopimuksessa asiakkaana on yritys, taustalla on aina eläviä ihmisiä. Määrittelytyö ei ole kaikkien vahvuus.

Asiantunteva toimittaja pystyy auttamaan asiakasta kannustamalla kertomaan arjen työstä, esittämällä oikeat kysymykset ja suhtautumalla kriittisesti asiakkaan esittämiin väittämiin. Toimittaja ei saa ottaa kaikkia vaatimuksia ylhäältä annettuna.

Monesti kysymykset eivät edes vaadi toimittajalta erityistä toimialaosaamista, vaan voivat olla esimerkiksi yleisiä lukumääriin liittyviä ongelmia. Esimerkiksi montako matkustajaa liittyy kulkuneuvoon? Vaihtoehtoja voi olla vaikkapa A) ei ketään tai yksi, B) tasan yksi, C) yhdestä viiteen, D) rajoittamattomasti. Ja kun tähän liitetään esimerkiksi reitti tai roolit, kuten kuljettaja, apukuljettaja, lapsi turvaistuimessa, lemmikki tai voiko matkatavara varata paikan, syntyy helposti yllättävän monimutkainen kertomus, missä jokainen määrittelyn sana voi merkitä viikkojen työtä.

Kun tavallista reaalimaailman ongelmaa kirjoitetaan määrittelyn muotoon, vaaditaan toimittajalta pelisilmää nähdä asiakkaan tarinan takaa oikea tarve ja muotoilla se määrittelyyn niin, että kaikki ymmärtävät sen oikein.

Avoimuus ja luottamus kantavat pitkälle myös ohjelmistokehitysprojekteissa

Olen aina pitänyt avoimuutta keskeisenä periaatteena. Jostain lukemastani on mieleen jäänyt seuraava: Jos et muuta keksi, kerro totuus. Pimittämisen tie ei ole pitkä. Vilpitön keskustelu vaikeistakin asioista saa parhaimmillaan aikaan yhdessä tekemisen hengen. Mitä vaikeampi projekti on aikataulullisesti tai teknisesti, sitä tärkeämpää on käydä haasteet avoimesti läpi asiakkaan kanssa ja pohtia yhdessä mahdollisia ratkaisuja. Kerran menetettyä luottamusta on vaikea ansaita uudelleen ja tämä koskee tasapuolisesti molempia osapuolia.

Onnistuneen projektin tiellä on paljon haasteita ja lyhyellä tähtäimellä jopa vaikeasti hyväksyttäviä toimintatapoja. Esitänkin siis kysymyksen: Onko sittenkin niin, että ajatus projektista onkin asiakastyytyväisyyden kannalta väärä tapa toimia?

Keskiössä kumppanuus

Itse kuvailisin useaa asiakassuhdetta, missä olen ollut vaikuttamassa, enemmän kumppanuutena. Tasavertaisessa asiakas-toimittaja-suhteessa molemmat hyötyvät toisistaan symbioosin tavoin. Pitkään kumppanuuteen mahtuu aktiivisia aikoja, joita myös projekteiksi kutsutaan, sekä rauhallisia jaksoja, jolloin hengähdetään ja pidetään valmiutta yllä. Parhaimmassa tapauksessa jopa tekemisen riskiä voidaan kantaa yhdessä.

Molempien osapuolien pitää pystyä elämään ja siihen ei sovi toisen osapuolen uhanalaisen aseman hyväksikäyttö. Toimittaja voi tiedostaa keskeisen aseman asiakkaan prosessissa ja hinnoitella itsensä törkeästi tai asiakas voi vaatia noudattamaan toimitusehtoja kirjaimellisesti, vaikka se vaarantaa toimittajan taloudellisen selviytymisen. Sitä vastoin aidossa kumppanuudessa pidämme toisistamme huolta.

Ja jos asia jäi epäselväksi kannatan kumppanimallia sekä pitkää ja reilua yhteistyötä.

Markku Valkealahti

KIRJOITTANUT

Markku Valkealahti

Director, Software Development

etunimi.sukunimi@eatech.fi
+358 50 550 1547

Markku Valkealahti toimii Eatechilla kehityspäällikkönä. Hänellä on pitkä tausta erilaisten ohjelmistoprojektien läpiviennistä ja hän on työskennellyt alalla yli 10 vuotta. Markku on parhaimmillaan suunnittelu- ja projektinhallintatehtävissä kun asiakastarpeista luodaan projektille vaatimukset, määrittely ja toteutus.

Markku Valkealahti