Verkkokehitys
Ideasta ensimmäiseen versioon: näin rajaat MVP:n
Rakennatko sovellusta, järjestelmää tai verkkopalvelua? Opi rajaamaan MVP yhden tärkeän käyttäjätehtävän, selkeiden integraatioiden ja ensimmäisen julkaisun kriteerien avulla.
MVP on tuotteen ensimmäinen, rajattu versio, jonka avulla voitte testata tärkeintä arvoa käytännössä. Sen tulee olla käyttökelpoinen siihen tehtävään, jonka se lupaa ratkaista, vaikka monet mahdolliset ominaisuudet tulisivat myöhemmin.
MA Appsilla tarpeiden ja laajuuden määrittely on tärkeä osa matkaa kohti verkkosivuja, sovelluksia ja järjestelmiä. Tämä opas näyttää, miten suosittelemme ajattelua silloin, kun ideasta tehdään konkreettinen kehitysprojekti.
Aloita tehtävästä, jonka käyttäjä haluaa ratkaista
Kirjatkaa ylös, kuka ratkaisua käyttää, mitä hän yrittää saavuttaa ja miten tehtävä hoidetaan nykyisin. Hyvä ongelmamäärittely on riittävän konkreettinen, jotta voitte tutkia, auttaako uusi ratkaisu.
Kuvittele palveluyritys, jossa työntekijät lähettävät kuvia ja muistiinpanoja sähköpostitse asiakaskäynnin jälkeen. Ensimmäinen versio voi mahdollistaa toimeksiannon valinnan, työn kirjaamisen ja koontiraportin lähettämisen. Laaja asiakasportaali voi odottaa, jos sitä ei tarvita tämän työnkulun testaamiseen.
Erottele välttämätön toiminnallisuus hyvistä ideoista
Käykää koko käyttäjätehtävä läpi ja merkitkää, mitkä vaiheet on pakko sisällyttää. Ominaisuus kuuluu ensimmäiseen versioon silloin, kun tehtävää ei voi suorittaa asianmukaisesti ilman sitä. Muuta voidaan arvioida, kun teillä on käyttökokemusta.
Vältä karsimasta pois tärkeitä laatutekijöitä vain lyhentääksesi listaa. Käyttöoikeuksien hallinta, ymmärrettävät virheilmoitukset ja datan käsittely voivat olla ensimmäisen ratkaisun välttämättömiä osia. Pienempi laajuus tarkoittaa vähemmän tuettavia tehtäviä, ei sitä, että tärkeimpien tehtävien pitäisi toimia huonosti.
Harkitkaa web-sovellusta ennen kuin päätätte mobiilisovelluksesta
Valinnan verkkosivun, web-sovelluksen ja mobiilisovelluksen välillä tulisi perustua tarpeeseen. Selvittäkää, missä käyttäjät työskentelevät, mitä laitteita he käyttävät ja edellyttääkö tehtävä puhelimen toimintoja tai käyttöä ilman vakaata verkkoyhteyttä. Sopikaa myös, miten ratkaisu jaellaan ja päivitetään.
MA Apps työskentelee sekä webin että mobiilin parissa. Tämä mahdollistaa vaihtoehtojen arvioinnin ennen kuin teknologiavalinta lukitaan. Lyhyt kuvaus käyttötilanteesta on keskustelulle parempi lähtökohta kuin alustan päättäminen vain siksi, että se on tuttu.
Kartoittakaa datavirta ennen integraatioiden tilaamista
Toimintolistasta käy huonosti ilmi, mistä data tulee. Kirjatkaa ylös, missä järjestelmissä asiakkaat, tilaukset tai tuotteet jo ovat, ja mikä järjestelmä vastaa tiedosta jatkossa. Selvittäkää käyttöoikeudet ja yhteyshenkilöt ennen aikataulun laatimista.
MA Apps kuvaa integraatioita muun muassa CRM:n, taloushallinnon ja sisäisten työkalujen välisinä yhteyksinä painottaen virheenkäsittelyä ja dokumentaatiota. Projektissanne on hyvä määritellä myös selkeästi, mitä käyttäjä näkee siirron epäonnistuessa ja kuka reagoi poikkeamaan.
Lähde: MA Apps: API-integraatiot
Määrittäkää, mikä on oltava kunnossa ennen julkaisua
Laatikaa muutama konkreettinen hyväksymiskriteeri päätehtävälle. Palveluesimerkissä se voi tarkoittaa, että oikea työntekijä saa pääsyn toimeksiantoon, voi lähettää raportin ja saa siitä selkeän vahvistuksen. Antakaa oikeiden käyttäjien kokeilla työnkulkua edustavalla datalla.
Sopikaa samalla, kuka vastaanottaa kysymykset, korjaa virheet ja tilaa muutokset. Dokumentaatio ja ylläpito ovat osa käyttökelpoista tuotetta. Ratkaisun käyttöönotto helpottuu, kun vastuut ja yhteydenottokanavat ovat selkeät.
Hyödyntäkää kokemuksia ennen kuin toimintolista kasvaa
Sopikaa, mitä haluatte selvittää ensimmäisen julkaisun jälkeen. Pystyykö käyttäjä suorittamaan tehtävän loppuun? Missä kohtaa kysymyksiä syntyy? Mitkä manuaaliset vaiheet ovat vielä jäljellä? Yhdistäkää havainnot ratkaisua käyttävien palautteeseen.
Priorisoikaa seuraava versio sen tärkeimmän esteen perusteella, jonka olette todella havainneet. Joskus se on uusi toiminto. Toisinaan kyse on selkeämmästä tekstistä, paremmasta koulutuksesta tai luotettavammasta integraatiosta. Hyvä MVP antaa paremman pohjan tälle päätökselle.
Kysymykset ja vastaukset
Onko MVP sama asia kuin prototyyppi?
Prototyyppiä käytetään usein konseptin tutkimiseen ja kokeilemiseen ennen varsinaista kehitystä. MVP on rajattu ratkaisu, jota voidaan käyttää valittuun tehtävään. Sopimuksessa kannattaa kuvata selkeästi, mitä käytännössä toimitetaan.
Voimmeko saada kiinteän hinnan ensimmäiselle versiolle?
Konkreettinen laajuus ja selkiytetyt riippuvuudet luovat paremman pohjan hinnoittelulle. Integraatioiden, epävarmojen vaatimusten ja muutosten on oltava näkyvissä tarjouksessa ennen toimitusmallista päättämistä.
Lähteet ja lisälukemista
Oivalluksista toimiviin ratkaisuihin.
Keskustele kanssamme siitä, mitä yrityksesi tarvitsee ja mistä on järkevää aloittaa.
Tutustu kehityspalveluihin MA Appsin kanssa