Väitän, että jokainen asiakaskohtainen ohjelmistoprojekti tulisi suunnitella ja rakentaa kuten se tehtäisiin aloittavalle startup-yritykselle (oli kyseessä startup, kasvuyritys tai maailmanlaajuinen “korporaatio”). Tarkoitan suhtautumista, että projektissa tehdään kaikki voitava, jotta tuote kasvaa, saa asiakkaita ja tuottaa arvoa yritykselle (useimmiten siis rahaa) tai ratkaisee jonkun olemassa olevan ongelman. Suhtautumista, että jos tavoitteissa ei onnistuta asiakasyritys menee nurin (tai vähintäänkin olemme epäonnistuneet siinä mitä teemme).
Ohjelmistoprojekteissa on aina haasteita ja tekevälle sattuu. Ei ole yhtään niin merkityksellistä tehdä silloin tällöin virhe, kuin se, että ollaan tehty viikko, kuukausia tai jopa vuosia väärää asiaa. Mikään ei ole niin kallista kuin käyttää olemassa olevat rajalliset resurssimme väärän ongelman ratkaisemiseen.
Mikä sitten on “väärä asia”?
Kun toimintansa vakiinnuttanut yritys suorittaa toimivaa bisnesmallia, startup vasta etsii sitä. On hyvin yleistä, että uusissa räätälöidyissä sovelluksissa (jopa yritysten sisäisissä) tehdään ominaisuuksia ja asioita, joita kukaan ei käytä. Meillä saattaa olla jopa “todisteita” sille, että “kyllä tätä mobiiliversiota on kyselty” mutta karu totuus lopulta on, että eipä mobiiliversiota sitten lopulta oikeastaan kukaan käyttänyt, kun se lopulta saatiin valmiiksi ja työnnettiin tuotantoon.
Tässä vaiheessa on toki helppo sanoa, että mentiin vikaan mutta voimmeko tehdä jotain asioita toisin, että voisimme estää tämän hulluuden?
Opi nopeasti ja rakenna vain minimi (MVP)
Toteuta kaikki asiat mahdollisimman pienissä osissa, jotta pääset kiinni nopeaan oppimiseen ja nopeaan palautteeseen. Kuinka nopeasti laitatte uutta versiota sovelluksestanne maailmalle? Muutaman viikon välein? Kuukausien kehitysjaksojen jälkeen? Sitten kun projekti on valmis? Lopeta! Aloita julkaisusyklin nopeuttaminen, aloita nopeampi oppiminen.
Keskustelkaa tiimissä seuraavista “mitä voisimme julkaista jo tänään”, “voimmeko ottaa sisäisessä testikäytössä olevan version jo nyt koekäyttäjille”, “millaisiin osiin te jakaisitte sovelluksen jos julkaisu pitäisi tehdä kahden viikon päästä”.
Vastuuta ei voi jalkauttaa toimittajalle. Kun sovelluksesta on versio koekäyttäjillä, kuuntele asiakasta! Kysy mitä mieltä asiakas on, toimiiko softa, ostaisitko sovelluksen tälläisenä, mitä pitäisi olla, jotta maksaisit tästä ja niin edelleen. Asiakas tulee aina yllättämään positiivisesti.
Minimum Viable Product (MVP) ajattelussa pyritään löytämään vain ja ainoastaan ne pakollisimmat ominaisuudet, jotka tuotteeseen tai palveluun pitää rakentaa, että se voidaan tuoda markkinoille tai julkaista käyttäjille.
Kun ongelma on määritelty ja MVP on löytynyt olemme turvassa?
Kun MVP on löytynyt, hio sitä käyttäjäpalautteen perusteella mahdollisimman nopein iteraatioin ja julkaise nopeassa tahdissa päivityksiä! Onko sovelluksessa bugi tai hajoaako leiska? Korjaa bugi ja fiksaa leiska! Onko napeissa väärä fontti? Vaihda se! Tee asioita ja tee ne nopeasti. Kun olet saanut sovelluksen tuotantoon, kiihdytä vauhtia. Pieniä askeleita jatkuvalla tahdilla.
Teitkö väärän korjauksen? Ei hätää, askeleet ovat olleet niin pieniä, että taaksepäin on helppo mennä eikä tehdä enää kuukausia väärää asiaa.
Jos toimit ja reagoit palautteeseen nopeasti käyttäjät antavat anteeksi: “Vau, toi oikeesti reagoi palautteeseen ja korjasi leiskan”.
The only way to win is to learn faster than anyone else. – Eric Ries
