ūüíį Mit√§ jos voisit kehitt√§√§ j√§rjestelm√§si 65 % halvemmalla?

 

Näin kävi.

Asiakkaamme oli aiemmin yritt√§nyt rakentaa j√§rjestelm√§√§ ja k√§ytt√§nyt siihen aikaa kolme vuotta ‚Äď turhaan. Viimein heid√§n oli ollut pakko vet√§√§ t√∂pseli sein√§st√§.

Yhtään osaa järjestelmästä ei tuona aikana saatu tuotantoon asti.

Edes tuotantoympäristöä ei pystytetty.

Kolme vuotta kehitysympäristössä pyörimistä.

Kaikkiaan rahaa paloi miljoonaa euroa.

Mikä meni pieleen?

Ensinnäkin projektin skooppi oli liian laaja. Järjestelmästä yritettiin tehdä kertaheitolla täydellinen.

Toisekseen työtä ei johdettu kunnolla.

Kolmanneksi tavoite ei ollut selkeä.

Neljänneksi aikataulu ei ohjannut tekemistä.

Viidenneksi laatu ei ollut riittävä koska tekijät olivat kokemattomia.

Mutta onneksi asiakkaalla oli uskallusta viheltää peli poikki. Se vaati kanttia niin pitkän kehitystyön jälkeen.

Silti järjestelmää tarvittiin yhä.

Kun pöly oli laskeutunut, asiakkaalla haluttiin ottaa opiksi virheistä ja tehdä asiat toisin.

Sitä varten he kääntyivät meidän puoleemme.

Meiltä palkattiin projektiin seniorikehittäjä tuomaan näkemystä siihen, miten toimivia kokonaisuuksia kannattaa rakentaa.

Seniori hahmotteli projektille selkeät suuntaviivat.

Tavoite oli kirkas: saada järjestelmä tuotantoon muutamissa kuukausissa, jotta kehittämiseen laitettu aika ja raha alkaisivat tuottaa arvoa mahdollisimman nopeasti.

Ei siis lähdetty tekemään täydellistä systeemiä vaan MVP:tä, minimum viable productia.

Ideana oli automatisoida mahdollisimman paljon.

Rakentaa erilaisia testejä.

Panostaa laatuun.

Ihan ensin pystytettiin sekä kehitysympäristö että tuotantoympäristö ja näiden välille automatisoitu putki.

Toimiva julkaisu-nappi oli olemassa alusta lähtien muistuttamassa tiimiä, mihin ollaan matkalla.

Kun set-up oli valmis, alettiin rakentaa softaa.

Ketterän kehityksen periaatteella palloteltiin asiakkaan kanssa rautalankaversioita viikoittain, jotta saatiin verifioitua asiakkaan datatarpeet ja -toiveet nopeasti.

Sitten datalle rakennettiin käyttöliittymä.

Järjestelmällä oli kaksi loppukäyttäjäryhmää, joista ensimmäinen sai version käyttöönsä 6 kuukaudessa.

Eli asiakas sai puolessa vuodessa projektin aloittamisesta 50 % arvoa.

9 kuukaudessa molemmilla käyttäjäryhmillä oli pääsy järjestelmään.

Rahaa oli kulunut miljoonan sijaan 350 000 euroa. Eli tällä kertaa asiakas sai järjestelmän 65 % halvemmalla.

Ja kaiken lisäksi tämä järjestelmä toimi.

Hienoinkin himmeli on arvoton ennen kuin se on julkaistu ja tuo asiakkaalle hyötyä.

Jos haluat kestävää ohjelmistokehitystä, ota yhteyttä.

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.