Tyhmät kysymykset kannattaa kysyä ensin

Monessa järjestelmäprojektissa vaikeimmat ongelmat liittyvät asioihin, joita ei kysytty ajoissa.

Toimiiko järjestelmä oikeassa käyttötilanteessa kuten ajateltiin? Ovatko kaikki ymmärtäneet tavoitteen samalla tavalla? Mitä jos jokin muuttuu kesken projektin?

Siksi pyrimme nostamaan epävarmuudet näkyviin mahdollisimman varhain.

Nopeat ratkaisut löytyvät samassa huoneessa

Projektivastaavamme pitää kokonaisuuden liikkeessä, mutta ratkaisuja ei tehdä yksin. Projektiin varataan aikaa yhteiselle työskentelylle asiakkaan kanssa.

Usein aloitamme projektin intensiivijaksolla toimistollamme, fyysisesti samassa tilassa asiakkaan kanssa. Silloin tarkennukset ja kysymykset, jotka sähköpostina ehkä jäisivät lähettämättä, nousevat luontevasti esiin. Huomio ei myöskään hajaudu viestitulvaan. Oikeat ihmiset keskittyvät yhteen asiaan kasvotusten, joten päätökset syntyvät nopeasti.

Tämä on tärkeää erityisesti projektin alussa, kun vaatimukset ovat vielä auki. Näin voidaan yhdessä määritellä iso maali ja joustavat reitit sitä kohti. Silloin kymmenistä tehtävistä osataan priorisoida kullakin hetkellä juuri se, joka tuottaa eniten arvoa. Myös kesken toteutuksen tulevat muutokset on näin helpompi kohdata.

Kaksi kehittäjää huomaa ongelmat aikaisemmin

Kehitystiimissä luotamme ryhmäohjelmointiin. Pair programming ‑mallissa kaksi kehittäjää ratkoo ongelmaa yhdessä: toinen kirjoittaa ja toinen seuraa ja kommentoi, tai he työstävät koodia rinnakkain samassa tilassa. Käytännössä teemme tätä usein myös tuoteasiantuntijoiden, asiakaspalvelun ja toimitustiimin kanssa.

Yhdessä tekeminen synnyttää kulttuurin, jossa on helppo kysyä kun ei tiedä jotain, myöntää heti ongelmat ja oppia niistä nopeasti. Palaute tulee heti, ja virheet löytyvät ennen kuin ne ehtivät juurtua tai paisua. Uusiakin ajatuksia uskalletaan siksi kokeilla ja ratkaisut ovat usein laadukkaampia kuin yksin tehtynä. Samalla kaikkien ymmärrys järjestelmästä kasvaa.

Tuotanto paljastaa miten järjestelmä oikeasti toimii

NASA rakentaa yhtä rakettia pitkään, pyrkien tekemään sen täysin valmiiksi sitä yhtä laukaisua varten. SpaceX taas tunnetaan siitä, että edullisempia rakettitestejä tehdään jatkuvasti aidoissa olosuhteissa, jolloin jokainen testi tuottaa tietoa seuraavaa versiota varten.

Vaikka meillä mittakaava on eri, ohjelmistokehityksen varhainen testaus toimii samalla periaatteella. Testausympäristö ei koskaan täysin vastaa tuotantoa, joten viemme järjestelmiä käyttöön vaiheittain – esimerkiksi julkaisemme porrastetusti erityisen suosittuja taidekursseja. Oikeat käyttäjät ja oikea kuorma paljastavat nopeasti, jos jotain pitää vielä viilata. Samalla vahvistetaan liiketoiminta-arvo: näemme onko ominaisuus oikeasti hyödyllinen ja kannattaako sitä laajentaa.

Yhteinen tavoite vähentää epävarmuutta

Yhteinen nimittäjä näissä on se, että ongelmat halutaan esiin aikaisin: pienempi riski, nopeampi korjaus, enemmän luottamusta prosessiin. Tällä tavalla rakennettu järjestelmä kestää muutoksia paremmin ja pysyy helpompana ylläpitää myös käyttöönoton jälkeen.