Kun koemme ymmärtävämme riittävästi sekä yhteistyökumppaneitamme, ratkaistavaa ongelmaa että tuotteen käyttäjiä, olemme valmiita aloittamaan verkkosovelluksen kehittämisen. Pidämme lähestymistavasta, jossa rakennamme ohjelmistotuotteita asiakkaillemme iteratiivisesti.
Aiemmin olemme määritelleet asiat, jotka ovat tärkeimpiä tuotteen menestyksen kannalta, sekä kaikkein haastavimmat teknologiset ongelmat, jotka meidän täytyy ratkaista päästäksemme tavoitteeseemme. Emme kuitenkaan käy näiden kimppuun suoraan, vaan aloitamme tutkimuksen samalla, kun laadimme asiakkaalle rautalankamallia.
Oikeiden teknologioiden valinta
Otamme aina huomioon asiakkaan nykyisin käyttämät ohjelmistopalvelut, erityisesti jos olemme integroimassa uutta ratkaisua olemassa oleviin palveluihin. Kun kehitämme verkkopohjaisia tuotteita, erityisesti täysin alusta lähtien, pidämme tällä hetkellä Next.js:ää parhaana lähtökohtana.
Olemme yleensä melko teknologianeutraaleja. ”Valitse oikea teknologia oikeaan projektiin ja käyttötapaukseen” on ohjelmistosuunnittelussa yleinen mantra, jota mekin noudatamme mielellämme. Jopa täysin uuden tuotteen kehittämisessä on erikoistapauksia, joissa voi olla perusteltua valita jokin toinen vaihtoehto.
Next.js tarjoaa paljon valmiina sen laajan mallipohjakirjaston ansiosta, jota sen kehittäjä Vercel tukee. Kun rakennamme tuotteen alustavaa versiota, haluamme keskittyä toimittamaan kriittiset ominaisuudet, jotka tekevät tuotteestanne arvokkaan ja erittäin käyttökelpoisen jo julkaisuvaiheessa. Olemme työskennelleet Next.js:n kanssa useissa projekteissa saavuttaen erinomaisia tuloksia. Tämä mahdollistaa keskittymisen asiakkaiden ongelmien ratkaisemiseen sen sijaan, että käyttäisimme aikaa teknologian valintaan.
Muut tekniset valinnat
Useimmat merkittävät ohjelmistotuotteet vaativat tietokannan, jonka valitsemme liiketoimintavaatimustenne perusteella. Tavallisimmin suosittelemme SQL-tietokantaa, kuten PostgreSQL:ää sen monipuolisten ominaisuuksien ja erinomaisen toimintavarmuuden vuoksi. Vain harvoissa tapauksissa Postgres ei tarjoa tarvittavia ratkaisuja tuotteen alkuvaiheessa.
Vaihtoehdot Next.js:lle
Meillä on kokemusta myös SvelteKitin ja Remixin kanssa työskentelystä. Nämä tarjoavat yhtä houkuttelevia lähtökohtia hyvien mallipohjiensa ansiosta. Next.js:llä on kuitenkin yleensä laajempi valikoima valmiita mallipohjia, mikä antaa enemmän vaihtoehtoja.
Jotkut asiakkaat saattavat olla vahvasti mieltyneitä tiettyihin teknologioihin. On myös erityistapauksia, joissa muut teknologiat voivat tarjota paremman lähtökohdan kuten esimerkiksi paremman integraation nykyisiin ohjelmistojärjestelmiisi.
Rakastettavan sovelluksen kehittäminen
Rakastettava tuote on se lisäpanostus, joka erottaa tuotteesi kilpailijoista tai saa käyttäjät omaksumaan uuden tuotteen ilman valituksia. Siirtyminen MVP:sta (Minimum Viable Product) MLP:iin (Minimum Lovable Product) tarkoittaa käyttäjäpolkujen suunnittelua yksinkertaisiksi ja intuitiivisiksi. Ensimmäisen version tulisi olla yksinkertainen ja keskittynyt; lisäominaisuuksia voidaan lisätä myöhemmin.
Klassinen esimerkki MLP:sta ohjelmistomaailmassa on deittisovellus Tinder. Sen oikealle tai vasemmalle pyyhkäisyyn keskittyvä käyttöliittymä (UX) nähdään yleisesti ominaisuutena, joka nosti sen kilpailijoiden yläpuolelle ja josta on tullut jopa yleisesti käytetty tapa muissakin yhteyksissä ”tykätä” tai ”olla tykkäämättä”. Lisäominaisuudet, kuten Spotify- ja Instagram-yhteyksien lisääminen, olivat toki mukavia lisäyksiä, mutta eivät olleet sovelluksen alkuvaiheessa keskiössä. Tärkeintä on rakentaa toimiva ratkaisu käyttäjän tarpeeseen – ei vain teknisesti mahdollinen tapa toteuttaa se, vaan myös nautittava kokemus.
Voimme palata aiempaan selitykseemme Minimum Lovable Productista korostaaksemme tätä näkökulmaa.
Minimum Viable Product
- Alustava Proof of Concept -tasoinen runko.
- Yksinkertaiset ominaisuudet vaatimusten tyydyttämiseksi.
- Antaa käyttäjille mahdollisuuden testata ideaa, mutta ei tavallisesti ole tarpeeksi vetovoimainen.
Minimum Lovable Product
- Kaikki edellä mainitut.
- Käyttäjäkokemuksen kehittäminen ensisijaisten työnkulkujen osalta.
- Herättää käyttäjissä myönteisiä tunteita.
Miltä kehitysprosessi näyttää
Kun kehitys alkaa, tavoitteemme on pitää selkeä ja jatkuva keskusteluyhteys asiakkaan kanssa koko prosessin ajan. Tiimi sopii asiakkaan kanssa viikottaisista tai kahden viikon välein pidettävistä kokouksista, joiden aikana priorisoidaan kehitystyötä ja saadaan säännöllistä palautetta varmistaaksemme, että suunta on oikea.
Haluamme korostaa, kuinka tärkeää on saada asiakas mahdollisimman nopeasti käyttökelpoisen version äärelle. Tämä mahdollistaa käyttäjätestauksen aloittamisen projektin varhaisessa vaiheessa. Kun asiakkaalla ja käyttäjillä on konkreettinen tuote esikatseltavana, on todennäköisempää, että keskitymme oikeisiin ominaisuuksiin tässä tuotteen kehityksen kriittisessä alkuvaiheessa.
Kun rakennamme jotain käyttäjäkeskeisestä näkökulmasta, kuten aiemmin kuvailimme, palautteen merkitys korostuu entisestään. Vaikka käytämme tavanomaisia työkaluja, kuten Kanban-tauluja ja ketteriä menetelmiä, emme yleensä työskentele sprinttimuodossa, jotta voimme säilyttää mahdollisimman suuren joustavuuden.
Tämä ei tarkoita, että vältämme kokonaan backlogeja ja estimointeja, mutta nopeatahtinen iterointi hyötyy usein lyhyemmästä palautesyklistä asiakkaan ja käyttäjien kanssa.
Suunnan muuttaminen
Kehitysprosessin aikana saattaa joskus käydä ilmi, että jotkut asiat eivät ole toteutettavissa nykyisessä toimituslaajuudessa. Näissä tilanteissa on tärkeää tuoda esiin ongelmat varhain, jotta voimme tehdä tarvittavat muutokset tavalla, joka säilyttää tuotteen hengen ja mahdollistaa asiakkaan tavoitteiden saavuttamisen. Loppujen lopuksi rakennamme rakastettavia tuotteita, joten on yleensä hyödyllisempää lykätä ominaisuutta, jota ei voida toimittaa rakastettavassa muodossa, kuin heikentää tuotteen kokonaislaatua toteuttamalla keskeneräinen ja ei-kriittinen ominaisuus. Vaihtoehtoisesti voimme toteuttaa rakastettavan mutta väliaikaisen ratkaisun, edellyttäen että se voidaan myöhemmin korvata teknisesti kestävämmällä ratkaisulla ilman, että tuotteen rakastettavat ominaisuudet kärsivät.
Yhteenveto
Tässä toisessa osassa olemme käsitelleet tarkemmin teknologiavalintojamme ja konkreettista kehityssykliä, jonka avulla hyödynnämme tehokkaasti aikaa tuotteen toimittamisessa.
Mielestämme kaikki kiteytyy muutamaan asiaan:
- Avoimen viestintäkanavan ylläpitäminen kehitysvaiheen aikana.
- Oikeiden teknologioiden valitseminen oikeaan tehtävään.
- Konkreettisen tuotteen iterointi ja muutoksiin suhtautuminen avoimin mielin.
- Käyttäjien mukaan ottaminen jo varhaisessa vaiheessa.
Kolmannessa osassa tarkastelemme, mitä tapahtuu ja miten asiat voivat muuttua, kun MLP on julkaistu ja käytössä oikeassa maailmassa.
Osa 1: Näin rakennamme Minimum Lovable Productin vuonna 2025 – ymmärryksen saavuttaminen
Osa 2: Näin rakennamme Minimum Lovable Productin vuonna 2025 – sovelluksen kehittäminen
Osa 3: Näin rakennamme Minimum Lovable Productin vuonna 2025 (julkaistaan myöhemmin).
