Kun ohjelmistokehityshanke meni pieleen…ūü§Į

Tärkeä osa ohjelmistokehitysprojektia on sovelluksen elinkaaren ja jatkokehitettävyyden miettiminen.

Valitettavasti tämä vaihe saattaa joskus unohtua välistä.

Siitä esimerkkinä alla oleva tarina.

Eräs konsulteistamme meni hankkeeseen, johon tuotti palveluita myös ulkopuolinen yksikkö.

Vaikka hankkeessa oli aiemmin käytetty tiettyä teknologiavalikoimaa, ulkopuolinen yksikkö oli päättänyt, että uusi palvelu toteutetaan poikkeavilla teknologioilla. Myös tietokantakerros vaihdettiin.

Konsulttimme tehtävänä oli automatisoida palveluiden infraa. Hän ihmetteli, miksi ympäristöön tuotiin tietokantaratkaisu, joka ei sopinut nykymalliin ollenkaan.

Kun muu järjestelmä alkoi valmistua, uudesta tietokantakerroksesta nousi esiin pahoja suorituskykyongelmia.

Konsulttimme selvitti asiaa.

Kävi ilmi, että uuden palvelun toteuttaneella tiimillä ei ollut riittävää osaamista valitsemistaan teknologioista. He olivat halunneet kokeilla jotakin uutta, mutta unohtaneet ottaa huomioon yhteensopivuuden.

Samoin selvisi, ettei asiakkaalla ollut käsitystä teknisen velan määrästä eikä suunnitelmaa, mitä sille tulevaisuudessa tehdään.

Auts.

Ongelmien ratkominen jäi sisäisen tiimin harteille.

Osa palvelusta saatiin tuotua olemassa olevaan arkkitehtuuriin.

Mutta pahin pullonkaula, tietokanta, jäi palveluun kaikkien riesaksi. Se hankaloitti vielä pitkään jatkokehitystä ja kulutti huomattavan summan asiakkaan rahaa.

Mitä tästä voi oppia?

Ainakin sen, että jotta asiakas saisi teknisesti kestäviä ratkaisuja, pelkkä kehittäjien pinnallinen osaaminen ei riitä. Tarvitaan myös kokemusta.

Kokemusta vaikkapa siitä, että on itse yrittänyt ylläpitää huonolaatuista koodia.

NImittäin sitten ymmärtää omakohtaisesti miten tärkeää on, että koodi on jatkokehitettävissä senkin jälkeen, kun kehittäjä on siirtynyt pois hankkeesta.

Kokemus säästää asiakkaan resursseja pitkällä aikavälillä.

Se on kestävää ohjelmistokehitystä.

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.