Älä ota turhia riskejä – ”Siirtymä vanhasta taustajärjestelmästä uuteen on kuin vaihtaisi renkaat liikkuvaan autoon”

Full stack -kehittäjä Juho Juurinen on alkujaan kiinan kieltä ja kulttuuria tunteva humanisti, joka ennen devaajan uraansa teki töitä liikkeenjohdon konsulttina.

Juho, miten taustasi auttaa ohjelmistokehitystyössä?

”Liikkeenjohdon konsulttina laadukkaallakaan pohjatyöllä ei ole merkitystä ellei osaa tehdä vakuuttavia presentaatiota. Siitä taidosta on ollut hyötyä. Annan esimerkin.

Nykyisessä hankkeessa vakuutusyhtiön ikivanhaa taustajärjestelmää ollaan laskemassa haudanlepoon. Se on tarkoitus korvata kahdella täysin uudella järjestelmällä.

Kun siirtymää ruvettiin hahmottelemaan reilu vuosi sitten, huomio luonnollisesti kääntyi heti siihen, että mitä kaikkia uusia toiminnallisuuksia päästään vihdoinkin tekemään. Kuitenkin samanaikaisesti oli vaatimuksena, että vanhan järjestelmän helmaan on kyettävä palaamaan välittömästi jos jotakin odottamatonta tapahtuu, nykyisestä palvelutasosta tinkimättä.

Hahmottelin kokonaisuutta paperille, mutta en kerta kaikkiaan nähnyt, miten onnistuisimme tekemään molemmat yhtä aikaa – sekä uudistetut palvelut, että aukottoman taaksepäin yhteensopivuuden. Riskit olisivat liian suuret.

Puskaradiosta kuulee aika ajoin, miten tällaiset järjestelmävaihdokset ovat epäonnistuneet katastrofaalisesti. Yleinen vertauskuva on, että vaihdetaan renkaat liikkuvaan autoon. Yritäpä siinä samalla vaihtaa korimallikin.

Onnistuin vakuuttamaan ainakin itseni, että ensi alkuun on vain selvittävä siirtymän yli hengissä. Ja kun korvaavat järjestelmät on ajettu sisään, ja vanha painolasti on lopullisesti pois kuvioista, sitten voidaan ruveta laajentamaan toiminnallisuuksia.

Suunnittelin vaiheistetun toteutustavan, mutta kysymys oli, miten saisin vedettyä muut mukaan pessimismiini. Pahanilmanlintuna voi olla haastavaa saada äänensä kuuluviin. Ammensin vanhoja biz dev -oppeja ja kokosin havaintoni ja ratkaisuehdotukseni yhteen presikseen riskienhallinnan näkökulmalla ja sanastolla – ja sain lähestymistavan myytyä.

Nyt on vuosi tehty hommia ja sovelluspalettimme on yhteensopiva kahden eri taustajärjestelmäkokoonpanon kanssa. Jos jokin menee mönkään, voimme lennossa palata vanhaan järjestelmään. Tämä laiva ei huonossakaan skenaariossa uppoa.”

Seuraa meitä Linkedinissä niin tiedät aina, mitkä ovat ohjelmistokehityksen toimivimmat käytännöt juuri nyt.

eNPS-mittaus perustuu Fred Reichheldin kehittämään Net Promoter Score -mittariin, jolla alunperin tutkittiin yritysten asiakaskokemusta ja asiakastyytyväisyyttä. Myöhemmin sitä on alettu käyttää myös työntekijätyytyväisyyden tutkimiseen (e niin kuin employee + NPS).

Näin mittaus tehdään.

Kysymme työntekijöiltämme kerran kertaa vuodessa, että “kuinka todennäköisesti suosittelisit työpaikkaasi ystäville tai tutuille asteikolla 0-10?”. Sen jälkeen pyydämme tarkennusta avoimella kysymyksellä: ”mistä syystä annoit tämän tuloksen?”.

Niitä, jotka antavat luvuksi 9 tai 10, kutsutaan suosittelijoiksi. Niitä, jotka antavat luvuksi 0-6, kutsutaan kriitikoiksi.

eNPS-tulos lasketaan vähentämällä suosittelijoiden suhteellisesta prosenttiosuudesta kriitikoiden suhteellinen prosenttiosuus. Muut vastaukset saavat arvon 0.

Mittarin tulokset voivat olla mitä vain -100 ja +100 väliltä. Yli nollan nousevat tulokset ovat tyydyttäviä. +10 ja +30 välillä olevia tuloksia pidetään hyvänä, ja yli +50 olevia tuloksia pidetään erinomaisena.