Lyhenteet PoC (Proof of Concept) ja MVP (Minimum Viable Product) ovat juurtuneet osaksi IT-alan perussanastoa viimeisen 10 vuoden aikana. Käsitteiden yleistymisestä huolimatta olemme kuitenkin huomanneet, että ihmiset saattavat puhua aivan eri asioista näitä sanoja käyttäessään.

Tällä tekstillä haluamme kertoa, mitä “PoC” ja “MVP” tarkoittavat Kodanin kielenkäytössä. Tekstin ovat kirjoittaneet palvelumuotoilija Ville Yli-Knuutila ja arkkitehti Herkko Virolainen.

Proof of Concept, “pokki”

Sanayhdistelmä “Proof of Concept” koostuu sanoista proof (todiste) ja concept (konsepti). Suomenkielisen version mukaan Proof of Concept kääntyykin sanayhdistelmäksi konseptitodistus.

Todistaminen on selkeää suomea, mutta mitä tarkoitetaan konseptilla? Tässä tapauksessa se tarkoittaa väitettä, oletusta, ideaa tai hypoteesia, jonka toimivuudesta ei olla varmoja. Konseptin ja sen todistamisen voi myös tiivistää yksinkertaiseksi “jos X, niin Y” -tyyppiseksi ehtolauseeksi.

Sisältönsä mukaan konseptitodistuksen olemassaolon tarkoitus on siis nimenomaan todistaa todeksi yksi tai useampia tulevan järjestelmän tai palvelun sisältämiä konsepteja.

Esimerkki. MyyntiFirma Oy:llä on oletus: jos myyjillä on käytössään tietynlaista dataa (jos X), niin he voivat kontaktoida useampaa asiakasta päivässä (niin Y). Tässä kohtaa ajatukset kääntyvät helposti dashboardiin tai muuhun käyttöliittymään, mutta helpoin tapa todistaa tämä konsepti saattaa olla kerätä tieto manuaalisesti ja lähettää se myyjille kerran päivässä sähköpostilla. Jos kontaktien määrä lähtee tämän jälkeen kasvuun, on konsepti todistettu ja sitä kannattaa jatkokehittää.

On tärkeää ymmärtää, että konseptitodistus ei ole toimiva järjestelmä, josta on “riisuttu vähän toimintoja”. Sen ainoa syy olla olemassa on testata jonkin tietyn konseptin elinvoimaisuus. Konseptitodistuksen toteuttaminen ei välttämättä vaadi myöskään riviäkään koodia.

Konseptin testaamisen jälkeen konseptitodistuksen paikka onkin yleensä roskakorissa. Se on hyvin usein toteutettu nopeasti ja halvalla, joten sen päälle ei ole järkevää lähteä rakentamaan uusia toimintoja tai muutakaan kestäväksi tarkoitettua toimintaa.

Minimum Viable Product, MVP

Sanayhdistelmä Minimum Viable Product taas koostuu sanoista minimum (pieni), viable (elinvoimainen) ja product (tuote). Myös tässä tapauksessa on syytä avata, mitä nuo kolme suomenkielistä sanaa meille tarkoittavat.

Mimimum, pieni. Tuote tuottaa jo arvoa ja ratkaisee ongelmaa tai ongelmia, mutta siinä on kuitenkin vielä lukuisia rajoituksia ja jatkokehitystä kaivataan. Rajoitukset voivat olla esimerkiksi saatavuus erilaisille alustoille, erilaisten toimintojen puuttuminen, tai automaation ja integraatioiden puuttuminen. Kulissien takana saatetaan vaatia vielä paljon manuaalista työtä. Rajoituksista johtuen tuote on vielä “pieni”, koska se ei kata kaikkia mahdollisia käyttötapauksia.

Viable, elinkelpoinen. Järjestelmä tuottaa selkeää arvoa ainakin yhdelle kohderyhmälle. Sen jatkokehitystä kannattaa jatkaa eikä se syö liikaa resursseja tuottamaansa hyötyyn verrattuna.

Tuote, product. Järjestelmä on selkeä kokonaisuus, jonka perustukset ovat huolella toteutettu, ja ne mahdollistavat skaalauksen ja jatkokehityksen. Jos kyseessä on myytävä tuote, sitä voi jo myydä.

Ylläolevat määritelmät eivät ole täysin ristiriidattomia keskenään. MVP:tä rakennettaessa vaikeinta onkin taiteilla termien minimum ja viable välillä. Mitä aidosti tarvitaan - ja mitä ei? Missä kohtaa jatkokehityksen vaatimat investoinnit ylittävät järjestelmän tuottamat hyödyt?

Esimerkki (jatkuu). MyyntiFirma Oy:n tekemä konseptitodistus osoitti, että myyjille toimitettu lisädata nostaa päivittäisten kontaktien määrää. Koska tietojen kerääminen ja lähettäminen manuaalisesti ei ole pidemmän päälle järkevää, niin MyyntiFirma Oy päättää toteuttaa digitaalisen palvelun, josta myyjät löytävät aina ajantasaisen datan. MVP-versio toteutetaan toimivana, mutta riisuttuna: käyttäjähallinta (mm. uudet tunnukset, unohtuneet salasanat) hoidetaan manuaalisesti, tukea mobiililaitteille ei vielä ole ja käyttöliittymä toteutetaan valmiilla komponenteilla. Tuote palvelee alussa vain n. 50% kaikista myyjistä. Mikäli palvelu tuottaa lisäarvoa odotetusti, sen kehittämistä jatketaan.

MVP:n tärkein tehtävä on testata konseptitodistuksen todeksi osoittaman idean toimivuutta käytännössä: aitojen käyttäjien käsissä, aidossa maailmassa. MVP:n avulla saadaan käyttäjiltä palautetta siitä, onko järjestelmän tuottama arvo tarpeeksi arvokasta ja mihin suuntaan tuotetta kannattaa lähteä kehittämään.

Kohti häpeää!

Joskus digitaalista palvelua tuottava organisaatio näkee mielessään erittäin tarkasti, miltä järjestelmän “pitäisi” näyttää ja miten sen “pitäisi” toimia. Vision ja todellisuuden ero saattaa jossain vaiheessa projektia tuottaa pahanlaatuista kognitiivista dissonanssia. Syntyy pelko, että jos tuote menee tämän näköisenä käyttäjille, niin johan sille nauravat kulkukoiratkin. Tämän seurauksena järkevät päätöksenteko lentää helposti ikkunasta pellolle, ja kehitystiimin aika ja energia ohjataan vääriin kohteisiin.

Palvelun loppukäyttäjillä ei kuitenkaan ole päässään tuota samaa visiota. He eivät tiedä, mitä palvelusta vielä puuttuu tai miten sen “pitäisi” toimia. He ovat kiinnostuneet vain ja ainoastaan siitä, helpottaako palvelu heidän elämäänsä. Ja jos se sen tekee, hieman kulmikkaampikin tuote löytää uskolliset käyttäjänsä.

Kun tuote on siinä kunnossa, että se oletettavasti luo arvoa ainakin yhdelle käyttäjäryhmälle, eikä hajoa käsiin, se kannattaa julkaista. Jos tuotteen toimivuus tai ulkonäkö hävettää, hyvä! Se tarkoittaa, että sitä ei ole hinkattu liian pitkään.

--

p.s. Kirjoitimme tälle tekstille myös jatkoa: Vinkit PoC:n ja MVP:n toteuttamiseen