Kaaos. Kiire. Paniikki. Siinä muutamia sanoja, joita kuulee liian usein ohjelmistoprojekteissa. Kaaoksessa sinänsä ei ole mitään pahaa, kunhan se johtaa luoviin ratkaisuihin. Mutta siinä vaiheessa, kun kaaoksen keskellä syntyy kiire ja lopulta paniikki, toimintateho murenee väistämättä ja koko tiimi saattaa lopulta lamaantua. Jos projektissa on turhaa kiireen tuntua, kannattaa pysähtyä hetkeksi selvittämään sen syitä—hyvissä ajoin ennen paniikin syntymistä.

Epävarmuus johtaa paniikkiin ja katkaisee ketteryyden

Ohjelmistoprojektien luonnollinen kehityskaari on mielenkiintoinen: Lähtöpisteessä kaikki näyttää kovin yksinkertaiselta ja suuntaviivat ovat selkeät. Onhan projekti päätetty käynnistää, joten lähtökohdan on oltava selvä. Projektin alkumetreillä illuusio yksinkertaisuudesta karisee nopeasti, kun liiketoimintaympäristö ja siihen liittyvät ongelmat alkavat hahmottua kunnolla. Yksinkertaisilta tuntuneet alkuperäiset vaatimukset monimutkaistuvat väistämättä.

Mutta tämähän on luonnollista ohjelmistoprojekteissa! Muuttuvien vaatimusten pitäisi olla tervetulleita, sillä eihän etukäteen aina voida tietää, mistä on eniten arvoa asiakkaalle. Ratkaisumahdollisuuksia ei kannata tietoisesti rajoittaa etukäteen vain kaaosta tai epävarmuutta hallitakseen. Jos oppimiselle annetaan tilaa ja aikaa projektin alussa, sen edetessä ongelmat ja ympäristö hahmotetaan yhä paremmin ja lopulta projektitiimille syntyy kokonaisvaltainen ymmärrys. Silloin kyetään tekemään järkeviä, faktoihin perustuvia päätöksiä ja tehokkaita ratkaisuja.

Usein ymmärryksen syntyminen uudessa projektissa ei kuitenkaan ole kivutonta. Alkumetrit saattavat tuntua kaoottisilta ja hallitsemattomilta varsinkin silloin, jos viesti ei kulje tarpeeksi hyvin joka suuntaan. Pahimmassa tapauksessa turvaudutaan vesiputousmallin aikaisiin jäykkiin toimintatapoihin, jotta projekti ei tuntuisi tai näyttäisi hallitsemattomalta. Se puolestaan on omiaan huonontamaan viestin kulkua entisestään.

Reistaileva kommunikaatio johtaa siihen, että ei tiedetä, mitä tehdään ja missä mennään, vaan joudutaan aina vain reagoimaan ja poukkoilemaan. Tällöin syntyy helposti kiireen tuntua, kun yritetään mukautua muutoksiin ja samalla pitää kiinni tiukoiksi tehdyistä määrittelyistä ja aikatauluista. Se ei ole ketteryyttä vaan panikointia.

Neljä nyrkkisääntöä paniikin välttämiseksi

Olemme oppineet projekteissamme, että vääränlaisen kiireen ja vahingollisen paniikin syntymistä voidaan välttää näillä neljällä nyrkkisäännöllä:

  • Kommunikaation täytyy olla avointa
  • Kommunikoinnin apuvälineitä pitää käyttää rohkeasti
  • Määrittelyiden on oltava testattavissa
  • Edistymistä täytyy mitata eikä arvioida tai arvailla

Hyvin usein se on kommunikaatio, mikä mättää. Vajavaisen kommunikaation takia ei ymmärretä asiakkaan tarvetta eikä löydetä eniten arvoa tuottavaa toiminnallisuutta. Vaikka avoimella tiedon jakamisella päästään hyvinkin pitkälle, ohjelmistoprojekteissa on usein hankalasti hahmotettavia asioita, kuten monimutkaisia liiketoimintaprosesseja. Tällöin kannattaa hyödyntää erilaisia apuvälineitä, vaikkapa visualisointia, jolloin piilevät ongelmakohdat saadaan näkyviksi sekä itselle että asiakkaalle. Kommunikointiin saa ja pitää panostaa ajoissa.

Huono kommunikaatio johtaa usein myös siihen, että ei tiedetä, ollaanko projektissa lähellä ratkaisua vai vasta alkutekijöissä. Monissa hankkeissa unohdetaan kokonaan testien ja varsinkin automaattisen testauksen toinen ulottuvuus: niillä voidaan mitata edistymistä ja viestiä yksiselitteisesti projektin tilasta, tavoitteista ja etenemisestä. Kaikista hedelmällisintä on, jos määrittelyt sidotaan testeihin alusta alkaen. Tällöin varmistetaan yhteisymmärrys kaikkien kolmen osapuolen kesken: tilaajan, toimittajan ja testaajan.

Liian usein kuitenkin ajatellaan, että kehittäjien ja testaajien ei kuuluisi istua samalla puolella pöytää vaan pelata vastakkain hyvän laadun varmistamiseksi. Testauksen päämäärä on tällöin yksiulotteinen, eikä sen koko potentiaalia päästä hyödyntämään. Sen sijaan ajaudutaan tekemään byrokraattista ja kallista dokumentointia viestinnän parantamiseksi, vaikka testauksesta syntyvää ajantasaista tietoa olisi nokan alla valmiiksi tarjolla.

Jatkuvaa oppimista ja kehittymistä

Leanissa tai ketterässä projektissa voi ratkoa myös projektin sisäisiä ongelmia leanisti. Tehdään, mitataan, opitaan, ja tehdään jatkossa yhä paremmin. Projektia itseään voi kehittää askel askeleelta, kunhan motivaatiota kehittämiseen löytyy. Voidaan vaikka aloittaa siitä, että hyväksymistestit kirjoitetaan yhdessä. Vaikka ne eivät automaattisia olisikaan, ollaan silti askelta lähempänä parempaa ohjelmistoprojektia.

Tiimi toimii kuin oppiva kone: päivä päivältä paremmin, asiakkaalle arvoa naksutellen. Kokemuksesta tiedämme, että tällaisessa luovan kaaoksen tiimissä on kertaluokkaa mukavampi olla kuin kiireessä ja paniikissa. Ja mikä tärkeintä, ilman kiirettä ja paniikkia päädytään aina asiakkaan kannalta huomattavasti parempaan lopputulokseen.

Toukokuussa syvennymme ohjelmistoprojektien ongelmiin Mystesin järjestämässä workshopissa Chaos Theory in Software Projects. Tervetuloa mukaan!

Jaa tämä sivu