MVP Szoftverfejlesztés: Hatókör, Költség, Ütemterv

Az MVP szoftverfejlesztés a hatókört tisztázó megbeszélésen romlik el, nem a fejlesztés közben. Valaki kimondja, hogy „minimum viable product", mindenki bólint, aztán megérkezik a funkciólista, amelyen ott van a felhasználói fiók, az adminfelület, a számlázás, az értesítések, egy irányítópult és egy mobilalkalmazás. Ez nem minimálisan életképes termék. Ez egy kész termék, és háromszor annyi ideig fog tartani, mint a fejünkben lévő szám.

A kárt az „életképes" szó okozza. A legtöbb csapat úgy olvassa, hogy „elég jó ahhoz, hogy bárkinek eladjuk", pedig azt jelenti, hogy „épp csak annyi, amiből megtudjuk, akarja-e ezt egyáltalán valaki".

A hatóköri teszt, amely a legtöbb pénzt spórolja: minden egyes funkciónál kérdezzük meg, mit csinálnánk másképp a válasz függvényében. Ha egy funkció nem képes megváltoztatni egyetlen döntést sem, akkor nincs helye az MVP-ben. Az adminfelület nem árulja el, hogy akarják-e az emberek a terméket; azt árulja el, hogy a termék könnyebben adminisztrálható lesz, amint akarják. Ezt építsük másodjára.

Mire való valójában az MVP szoftverfejlesztés

Az MVP azért létezik, hogy egyetlen kérdésre valódi felhasználókkal válaszoljon, ne vélemények alapján. Ez a kérdés általában így hangzik: fizet ezért bárki, vagy használja bárki elég gyakran ahhoz, hogy számítson?

Ez átértelmezi, mi tartozik bele. Az az egyetlen útvonal kell, amely bemutatja az értéket, végponttól végpontig működik, és annyira kész, hogy egy valódi ember végig tudja csinálni anélkül, hogy mellette ülnénk. Minden más opcionális marad addig, amíg ez az útvonal be nem bizonyította magát.

Ez magyarázza a prototípustól való eltérést is. A prototípus eldobható, és egy tervezési kérdésre válaszol, gyakran működő háttérrendszer nélkül. Az MVP éles kód valódi felhasználókkal és valódi adatokkal, azzal a szándékkal építve, hogy bővíthető legyen, ha a válasz igen. A kettő összekeverése mindkét irányban drága: vagy eldobunk olyan kódot, amelyre szükségünk volt, vagy gondosan megtervezünk valamit, amit hamarosan kidobunk.

Mi kerül bele és mi vár

Bekerül: az értéket hordozó fő útvonal, az a minimális hitelesítés, amit ez az útvonal megkövetel, a fizetés lehetősége, ha a kérdés az, hogy fizetnek-e az emberek, és annyi mérés, amennyiből látszik, mit csinálnak valójában a felhasználók.

Vár: az adminfelületek, a szerep- és jogosultságrendszerek egy vagy két szerepkörön túl, az értesítési beállítások, a bevezető folyamatok, azok az integrációk, amelyeket senki nem kért, és minden, ami úgy kezdődik, hogy „ha már úgyis ott vagyunk".

Két dolgot szoktak kivágni, amit nem kellene. A mérést, mert az az MVP, amely analitika nélkül indul el, egyetlen kérdésre sem válaszol, és a pénzt hiába költöttük el. És az adatok törlésének vagy javításának lehetőségét, mert a valódi felhasználók már az első napon hibáznak, a kézi adatbázissebészet pedig gyorsan fárasztóvá válik.

A leggyakoribb hatókörnövekedés az adminfelület, és ez szinte mindig elkerülhető. Az első hetekben a lekérdezések kézi futtatása gyorsabban összerakható, és tíz felhasználónál tökéletesen elegendő. Az adminfelületet akkor építsük meg, amikor a felhasználók kézi kiszolgálása szűk keresztmetszetté válik, ami egyébként jó probléma.

Reális brit költségek

Az MVP árát az szabja meg, hány különböző dolgot csinál, nem a mögötte álló ötlet. Az általunk látott brit sávok:

A napi £100 vagy £200 áron dolgozó offshore csapat átírja ezt a számtant, és magával hozza azt a koordinációs költséget, amelyet a szoftverfejlesztés kiszervezése cikkünkben tárgyalunk. Az egyedi szoftverfejlesztés költségeinek bontása végigveszi, mi mozgatja az egyes sávokat.

Két költség szinte minden MVP-költségvetésből kimarad. Valakinek üzemeltetnie kell, amint élesben fut, és ez valódi havi összeg, nem kerekítési hiba. És a második verzió, mert ha az MVP jól megválaszolja a saját kérdését, a közvetlen következő lépés az, hogy építünk rá, egy indulásnál véget érő költségvetés pedig pontosan akkor fogy el, amikor megtudjuk, mit kell csinálni.

A hiba, amely három hónapból kilencet csinál

Olyan méretre építeni, amekkora még nincs.

Az ösztön érthető. Senki nem szeret olyan kódot írni, amelyet le fog cserélni. Így az MVP kap egy üzenetsort, egy gyorsítótár-réteget, vízszintes skálázást és egy mikroszolgáltatás-határt, amelyek közül ötven felhasználónál egyik sem tart semmit, viszont mindegyiket meg kell építeni, tesztelni és üzemeltetni, mielőtt az első ember egyáltalán meglátná a terméket.

Az őszinte álláspont az, hogy egy MVP lehet építészetileg unalmas. Egy adatbázis, egy alkalmazás, egyszerű telepítés. Ha sikeres lesz, egyes részeit úgy írjuk majd újra, hogy már valóban tudjuk, hol van a terhelés, és ez az újraírás olcsóbb és sokkal pontosabban célzott lesz, mint az indulás előtti tippelés.

A kivétel minden olyan döntés, amelyet később drága megváltoztatni: az adatmodell, a hitelesítés megközelítése és bármi, ami személyes adatot érint. Ezeket nagyjából jól eltalálni már az elején megéri a plusz hetet, mert éppen ezek kibogozása kerül a legtöbbe.

Hogyan határozzuk meg a hatókört egy délután alatt

Írjuk le azt az egyetlen mondatot, amely leírja, mit ér el a felhasználó. Ezután soroljuk fel azokat a képernyőket, amelyeket ez a mondat megkövetel, és semmi mást. Minden megmaradt funkcióra alkalmazzuk a cikk elején szereplő döntési tesztet.

Aztán vágjuk le a lista harmadát mindenképp. Minden csapat túlméretezi az első körben, és az a harmad, amelyet most eltávolítunk, szinte mindig ugyanaz a harmad, amelyet indulás után távolítottunk volna el.

Dátumot tűzzünk ki funkciólista helyett. Egy három hónapos MVP, amely elindul, többet ér egy öt hónaposnál, amely a hetedik hónapban is még két hétre van a kiadástól, a rögzített dátum pedig kikényszeríti, hogy a hatókörről szóló beszélgetések korán történjenek meg, amikor még olcsók.

A Mecanik a szoftverfejlesztési csapatával határozza meg és építi meg az MVP-ket, beleértve azt a részt is, amikor valaki lebeszéli önöket az adminfelületről. Ha van funkciólistájuk, de nincs dátumuk, akkor itt érdemes kezdeni.

Kapcsolódó bejegyzések: Egyedi szoftverfejlesztés az Egyesült Királyságban , Fintech szoftverfejlesztés az Egyesült Királyságban: FCA, rails és költségek , Hogyan fejlesszünk webalkalmazást 2026-ban , White label webfejlesztés ügynökségeknek .

Gyakran ismételt kérdések

Mit tartalmazzon egy MVP? Az értéket hordozó fő útvonalat végponttól végpontig működve, azt a minimális hitelesítést, amit ez az útvonal igényel, a fizetést, ha a kérdés az, hogy fizetnek-e az emberek, és annyi mérést, amennyiből látszik, mit csinálnak valójában a felhasználók. Az adminfelületek, a szerepkörrendszerek, az értesítési beállítások és a senki által nem kért integrációk mind várnak addig, amíg az MVP meg nem válaszolta a saját kérdését.

Mennyibe kerül az MVP szoftverfejlesztés az Egyesült Királyságban? Egy egyutas webalkalmazás egyféle felhasználóval jellemzően £15 000 és £35 000 között kerül, hat és tíz hét alatt. Kétféle felhasználó fizetéssel és alap adminisztrációval £35 000 és £75 000 között kerül, három és öt hónap alatt. A többszereplős termékek integrációkkal vagy megfelelési követelményekkel nagyjából £75 000 összegtől indulnak, és öt hónapot vagy többet vesznek igénybe.

Mi a különbség a prototípus és az MVP között? A prototípus eldobható, és egy tervezési kérdésre válaszol, gyakran működő háttérrendszer nélkül. Az MVP éles kód valódi felhasználókkal és valódi adatokkal, azzal a szándékkal építve, hogy bővíthető legyen, ha a válasz igen. Összekeverni őket mindkét irányban drága: eldobjuk a kódot, amire szükségünk volt, vagy túltervezünk valamit, amit hamarosan kidobunk.

Mennyi ideig tart egy MVP megépítése? Hat és tíz hét között egy egyutas alkalmazásnál, három és öt hónap között, amint belép egy második felhasználótípus és a fizetés. Ha a becslés öt hónapnál hosszabb, a hatókör szinte biztosan nagyobb egy MVP-nél, és érdemes megvágni, mielőtt bármi elkészülne, nem utána.

Mi a leggyakoribb MVP-hiba? Olyan méretre építeni, amely még nem létezik. Az üzenetsorok, a gyorsítótár-rétegek és a mikroszolgáltatás-határok ötven felhasználónál semmit nem tartanak, de mindet meg kell építeni, tesztelni és üzemeltetni az indulás előtt. Egy MVP lehet építészetileg unalmas. A kivétel az adatmodell, a hitelesítés és minden, ami személyes adatot érint, mert ezeket később drága megváltoztatni.