MVP

Ohjelmistoalalla asiakkaat usein lähestyvät toimittajaa kymmenien, jopa satojen sivujen määrittelyillä, joissa on yritetty ajatella valmiiksi kaikki tarvittava toiminnallisuus – ja paljon lisääkin.

Blogissa on kirjoitettu runsaasti yksinkertaistamisen ja karsimisen tärkeydestä. Suosittelemme usein asiakkaita toteuttamaan aluksi Minimum Viable Productin eli MVP:n. MVP:llä tarkoitetaan ohjelmistoa, joka sisältää vain välttämättömän toiminnallisuuden, jolla voidaan varmistua siitä että projekti kannattaa toteuttaa.

Esimerkiksi monet web-palvelut on toteutettu aluksi MVP-vaiheeseen, usein beta-maininnan kera, jotta on saatu selvitettyä löytyykö kyseiselle palvelulle markkinoita.

MVP:stä kertyneen kokemuksen pohjalta on helppo suunnitella tarvittaessa jatkokehitystarpeet. Yleensä tällöin myös huomataan, kuinka paljon turhaa kehitystyötä olisi tapahtunut, jos olisi suoraan tilattu alkuperäisten suunnitelmien mukainen ”täydellinen” palvelu.

Pasi Kovanen

Pasi Kovanen
Software with Passion.

7 kommenttia

Projektipäällikkö sanoo:

Eikös julkisensektorinprojektit ole opettaneet, että ensin tehdään kahdella miljoonalla sutta ja sitten korjataan viidellä. Lopuksi viimeistellään tuote tuotantokäyttöön kahdeksalla miljoonalla. Tuonkin jälkeen käyttäjät ovat tyytymättömiä, mutta ei näin kallista projektia enää voi hyllyttää.

Jarkko Järvenpää sanoo:

Asiakkaalla tietysti on paras näkemys tuotteen ominaisuuksista ja niiden merkityksestä. Ja kyllä mekin viime kädessä uskomme asiakasta, jos hän on 100% varma, että kyseessä oleva toiminnallisuus tarvitaan.

Sitä en ymmärrä, miksi kukaan tilaaja haluaisi ehdoin tahdoin ostaa turhia ominaisuuksia.

Kuten Pasi jo sanoikin me sovimme asiakkaan kanssa usein minimitoiminnallisuuden toteuttamisesta, jonka jälkeen projektia tehdään sprintti ja ominaisuus kerrallaan. Asiakas voi näin miettiä jatkokehityksen järkevyyttä paremman tiedon pohjalta.

Pasi Kovanen sanoo:

Vincitissä usein ehdotamme asiakkaalle ensin minimitoiminnallisuuden toteuttamista, jotta palvelusta saadaan mahdollisimman aikaisessa vaiheessa palautetta käyttäjiltä. Mielestäni vastuullisen ohjelmistotoimittajan velvollisuus on opastaa asiakasta tähän, vaikka se lyhyellä tähtäimellä voikin vähentää laskutusta.

Turhan toiminnallisuuden toteuttaminen laskee asiakkaiden lisäksi softakehittäjien tyytyväisyyttä.

Jukkis sanoo:

Toisaalta tämä luo bisnestä ohjelmistoyrittäjille. 🙂

Kannattaako siis tehdä minimiä jos huomataankin että palvelu on täysi susi. Jos asiakas haluaa tehdä koko palvelun, niin haluan nähdä toimittajan joka sanoo että meille ei kelpaa koko projekti vaan kannattaa tehdä vain tämä 1/30, koska tämä muu ei tule toimimaan.

Nimetän sanoo:

Teen moneen paikkaan pieniä hommia.

Hankalimpia ovat tietysti ne jotka eivät tiedä mitä tahtovat. Mutta melkein yhtä hankalia ovat ne joilla on aivan valtava määrä pilkkutasoisia vaatimuksia joista sitten ei oikein olla halukkaita luopumaankaan vaikka työkalulla tulisi rajat vastaan tms. Aikaa kuluu tolkuttomasti. Mutta kanta-asiakkaalle on pakko tehdä.

Paras on taas sellainen jolla on selkeä kuva mitä haluaa, kompakti tarve, ja joka on valmis luopumaan sekundäärisistä vaatimuksistaan kunhan heille selittää miksi se on vaikeaa.

En oikein tajua miten tämä ongelma ratkeaa.

Liity keskusteluun