Ketterää ohjelmistotutkimusta?

Vastaus otsikon kysymykseen riippunee paljon siitä, miten ”tutkimus” määritellään. Jospa tässä yhteydessä tarkoittaisin tutkimuksella yritysmaailman jokapäiväisten, ohjelmistokehitykseen liittyvien haasteiden ratkaisemista tutkimuksen keinoin.

Emme siis olisi luomassa uutta tietoa (kansallisella, kansainvälisellä tai globaalilla tasolla), vaan etsisimme määriteltyyn tarpeeseen kohdennettuja, olemassaolevia ratkaisuja.

Etsi. Kartoita vaihtoehtoja.

Tutkimuksen keinoja ovat perinteisesti olleet esimerkiksi kirjallisuustutkimus, haastattelututkimus, kyselytutkimus tai vertaileva analyysi. Näitä voisi mielestäni merkittävästi keventää ja ketteröittää siten, että kirjallisuusanalyysissä voisi käyttää materiaalina myös nk. ei-tieteellistä materiaalia, kuten blogeja, mikäli niistä tarvittavaa tietoa löytyy. Nythän materiaalin ei tarvitsisi olla tieteellisen seulan läpäissyttä katselmoitua tutkimusdataa, koska tärkeintä olisi löytää ratkaisu.

Haastattelututkimuksenkaan ei tarvitsisi kattaa koko eurooppaa tai tuottaa luotettavaa tilastotietoa, vaan kevennetysti – toki tapauksesta riippuen – riittäisikö oman yrityksen asiantuntijoiden mielipiteiden kartoitus?

Uuden tiedon tuottamisessa puoli vuotta on lyhyt aika, mutta harjaantunut lukija (jollainen itse väitän tietysti olevani:) lukee viikossa paljon ja pystyy ehkä jo siinä ajassa muodostamaan käsityksen suosituimmista, olemassaolevista ratkaisuista. Tämä väite ei ole sitten mikään lupaus, ongelman laajuus täytyy tietenkin ottaa huomioon:) Lähinnä tarkoitan, että viikon mittainen sprintti ei olisi mielestäni mitenkään mahdotonta!

Vertaa. Käytä systemaattisia kriteereitä.

Seuraavassa vaiheessa päästäisiinkin jo tekemään (tietenkin jälleen kevennetty) vertailu parhaista ratkaisuvaihtoehdoista – käyttäen yrityksen määrittelemiä kriteereitä kuten esimerkiksi hinta, käyttöönoton helppous tai odotettu vaikutus. Vertailussa otettaisiin huomioon kokonaisuus, eikä osaoptimoitaisi vertailua johonkin tiettyyn attribuuttiin, johon väitöskirjatutkimuksissa (kyllä, minunkin aikoinaan) usein sorrutaan.

Sopivimman tai sopivimpien ratkaisujen valinnan jälkeen voitaisiin siirtyä pilotointivaiheeseen, joka aloitettaisiin pienellä otoksella: yksittäinen tiimi tai komponentti ja sitten iteratiivisesti – mikäli positiivista vastetta saadaan – laajennettaisiin vähitellen ja tarpeen mukaan. Näin riski pysyisi pienenä ja ratkaisua voitaisiin koko ajan kehittää ja parantaa kokemusten karttuessa.

Pilotoi. Mittaa tuloksia ja iteroi.

Olemassaolevasta ratkaisusta tulisi näin lopulta yrityksen tarpeisiin räätälöity oma, ehkä ainutlaatuinenkin tuoterakenne, menetelmä/prosessi, työkaluketju tai metriikkasetti. Mikä ohjelmistokehityksen tarve sitten olisikaan kyseessä.