Kasu:
- Oskus mõista MVP (minimaalne elujõuline toode) kontseptsiooni ja "väikseima õppeüksuse" loogikat ning määrata tehisintellekti abil ulatust
- Võimalus rakendada funktsioonide prioritiseerimist (MoSCoW, mõju-pingutus) ja tehisintellekti toega kiiret prototüübi/sihtlehe tootmist
- Arusaamine, et MVP eesmärk on õppida, mitte müüa, ja et liigne projekteerimine on idufirma kõige kallim viga.
Kõige kallim viga, mida asutajad teevad, on kuude kaupa toote täiustamine, mida nad pole kindlad, et keegi seda soovib. Turule minnes saavad nad teada, et probleem oli vale või lahendus. Selle katastroofi vältimiseks on MVP: minimaalne elujõuline toode – väikseim tooteversioon, mis annab kõige rohkem õppimist kõige väiksema pingutusega. Selles üksuses kasutame tehisintellekti (AI) MVP ulatuse kindlaksmääramiseks, funktsioonide tähtsuse järjekorda seadmiseks ja kiirete prototüüpide/tiisrite tootmiseks. Kõige kriitilisem lause: MVP eesmärk on õppida, mitte müüa; Kõige kallim viga on põhjendamatute eelduste üleprojekteerimine.
Mis on MVP ja mis mitte?
MVP on valesti mõistetud mõiste. MVP ei ole "lohakas, katkine toode"; See on väikseim täielik kogemus, mis on vajalik konkreetse hüpoteesi kontrollimiseks. Võtmesõnaks on "õppimine". Küsige endalt: "Millele küsimusele ma püüan vastata?" MVP sisaldab sellele küsimusele vastamiseks piisavalt funktsioone - ei rohkem ega vähem. Mõnikord ei pruugi MVP olla isegi töötav rakendus: MVP võib olla ka sihtleht, video, käsitsi teenus (viisardi meetod, mis näib olevat ees automaatne, samal ajal kui inimene töötab taustal).
MVP vastand on liigne projekteerimine – jõupingutus, mis kulub veel mittevajalike funktsioonide, mastaabi ja täiuslikkuse nimel – ja ülekullamine – detailide lihvimine, mida keegi ei taha. Need on idufirma kõige salakavalamad raha ja aja tapjad; sest nad tunnevad, et nad "töötavad", kuid viivitavad õppimist.
Nõuanne. Enne funktsiooni lisamist küsige: "Kas ma saan ilma selle funktsioonita seda, mida tahan testida?" Kui vastus on "jah", ei pääse see funktsioon MVP-sse. Iga "aga me vajame ka seda" lause, mis paneb MVP kasvama, on kulu, mis lükkab õppimist edasi.
Funktsioonide prioritiseerimine
Kuna pole piiramatult aega ja raha, tuleb otsustada, milline funktsioon ehitatakse esimesena. Kaks praktilist meetodit:
MOSCOW: jagab funktsioonid neljaks – peab, peaks, võiks, ei tee. MVP on lihtsalt "peab" komplekt.
Mõju-jõupingutuse maatriks: asetab iga funktsiooni "mõju kliendile" ja "teha pingutuse" teljele. Esmalt tehakse suure mõju ja väikese pingutusega; Loobutakse madala mõju ja suure pingutusega. Tehisintellekt on hea abiline funktsioonide loendi kiireks sellesse maatriksisse sisestamiseks, kuid "mõju" ennustust on vaja korrigeerida tegeliku kliendi signaaliga.
Samm-sammult: MVP disain koos AI-ga
- Kirjutage õppeküsimus. "Millist eeldust see MVP testib?"
- Kandidaadi funktsioonide loend. Valage välja kõik, mis teie meelest on.
- Prioriteet AI abil. Väljavõte MOSCoW või efektiga; Leidke klaster "Peab".
- Valige kõige kergem vorm. Kas on vaja koodi või piisab sihtlehest/videost/käsiteenusest?
- Loo prototüüp/leht. Küsige tehisintellekti valge paberi teksti, voo või pseudokoodi mustandit.
- Määrake eelnevalt oma edukriteeriumid. "Kui ma seda tulemust näen, on oletus kinnitust leidnud."
- Avaldage ja õppige. Mõõtke tegelikku käitumist; Asutaja teeb otsuse.
kolm minikarpi
Juhtum 1 — MVP ilma koodi kirjutamata. Üks asutaja mõtles rakendusele, mis ühendas omavalmistatud toite müüvad naabrid klientidega. Selle asemel, et kulutada kuid koodi kirjutamisele, alustas ta ühe demolehe ja WhatsAppi liiniga; sobitas tellimused käsitsi (meetod "viisard taga"). Ta sai kahe nädala jooksul 40 tegelikku tellimust ja sai teada, et tegelik kitsaskoht oli tarnelogistika. Kui ta oleks koodi kirjutanud, oleks ta selle õppinud kuud hiljem. MVP viis õppimise edasi.
Juhtum 2 – ülemäärane lõks. Üks meeskond kulutas 4 kuud infrastruktuuri loomisele, mis ulatuks miljonite kasutajateni, kui tal polnud veel ühtegi klienti. Kui toode välja tuli, ei tahtnud seda keegi; Probleem oli vale. Peaaegu kogu kulutatud vaev läks raisku. Õppetund: mastaabiprobleem on luksus pärast veojõuprobleemi lahendamist; Tõestage kõigepealt, mida keegi tahab.
3. juhtum – prioriteetide seadmise jõud. Ühe asutaja loendis oli 30 funktsiooni. Ta lasi tehisintellektil luua mõju-pingutuste maatriksi ja korrigeeris veergu „mõju” tegelike klientide vestluste signaaliga. Ainult 4 30 funktsioonist osutusid "Peab". MVP vabastati 6 kuu asemel 3 nädalaga; Klient näitas, et enamikku ülejäänud 26 funktsioonist pole üldse vaja.
Neli kopeeritavat malli
1) Õppimisküsimus + MVP ulatus:
Sinu roll: lahja toote treener. Eeldus, mida ma testida tahan, on:[nt. "kaupmehed maksavad kogude eest igakuiselt"].(1) Kirjeldage selle eelduse kontrollimiseks vajalikku VÄIKEmat toodet. (2) Näidake, kas selle versioon, mis ei nõua koodi (sihtleht, video, käsitsi teenus), on võimalik. (3) Hoiatage "atraktiivsete, kuid mittevajalike" funktsioonide eest, mis ei tohiks MVP-sse jõuda.
2) Moskva prioriteedid:
Jagage järgmine funktsioonide loend Moskvasse: Peab / Peaks / Võiks / Ei. Kaasata tuleks ainult need, mis on "PEAB selle eelduse jaoks, mida ma tahan testida". Kirjutage ühe lausega, miks iga omadus selles klastris on. Loend: [omadused].
3) Mõju-pingutuse maatriks:
Hinda järgmisi funktsioone telgedel „mõju klientidele (1–5)“ ja „tegemisjõud (1–5)“ ning paigutage need 4 kvadranti. Märgistage suure löögi ja vähese pingutusega tüübid kui "tee kõigepealt" ja väikese löögi ja suure pingutusega tooted kui "ära tee". Tuletage mulle meelde, et mõjuskoore tuleb võrrelda minu tegeliku kliendiseotusega. Loend: [funktsioonid].
4) Sihtlehe tekst:
Kirjutage minu MVP-le splash-lehe tekst. Jaotised: (1) pealkiri kliendi keeles (väärtuspakkumine), (2) probleemilahenduse narratiiv, (3) 3 kasupunkti, (4) selge üleskutse (eelregistreerimine / ootenimekiri). Liialdatud lubaduste kasutamine; Ainult väited, mida saan kontrollida. Türgi, lihtne, siiras.
Nõrk viip / Tugev viip
Nõrk viip:
Loetlege kõik minu toote funktsioonid.
See viip läheb vastuollu MVP loogikaga; See loob pika soovide nimekirja, mis lükkab õppimist edasi ja kutsub üles tegelema liigselt.
Võimas viip:
Ainus eeldus, mida ma testida tahan, on: [x]. Kirjeldage VÄIKEIMA MVP-d, mis seda eeldust kontrollib, pakkuge välja versioon, mis ei nõua koodi, eraldage funktsioonid MOSCoW-ga ja jätke alles ainult Must set. Aidake mul oma edukriteeriume mitte ette kirjutada (mis tulemus kinnitab eeldust).
Lähenemine
Õppimise määr
Maksumus
Risk
Kogu toote valmistamine nullist
liiga aeglane
kõrge
Ärge pange raha valesse asja
Äärmuslik insenertehniline / kullatud
aeglane
väga kõrge
Kõige kallim viga
Ainult kohustuslik MVP
kiire
madal
juhitav
Koodita MVP (maandumine/elle)
kiireim
madalaim
varajane õppimine
Levinud vead
- Segib MVP-d tervikliku tootega. MVP on väikseim õppimisüksus, mitte lihvitud finaal.
- Üleinseneritöö. Kulutage kuid mastaapselt/täiuslikult, kui läheduses pole ühtegi klienti; Kõige kallim viga.
- Ei määratle õppimisküsimust. MVP, kes ei tea, mida ta testib, on suunatu raiskamine.
- Edu kriteeriumide seadmine hiljem. Kui kriteeriumid pole ette kirjutatud, tõlgendatakse iga tulemust kui "edu".
- Koodivabade valikutest möödahiilimine. Sihtleht/video/kirjutuskood, kui saate seda teenusega käsitsi testida.
Ettevaatust: tehisintellekt võib koostada prototüübi või koodikavandi, kuid teie vastutate toodetud koodi turvalisuse, täpsuse ja juriidilise vastavuse eest. Eriti maksete, isikuandmete või turvalisusega seotud MVP-de puhul on tehisintellekti väljund esialgne visand; On oluline, et pädev arendaja/ekspert selle enne avaldamist üle vaataks.
Kokkuvõttes
MVP on väikseim toode, mis annab kõige rohkem õppimist kõige väiksema pingutusega; Selle eesmärk ei ole müüa, vaid eeldust testida. Kõige kallim viga on liigne projekteerimine ja ülekullamine tõestamata tootele, mida keegi ei taha. Iga MVP algab õppimisküsimusega; funktsioonid ekstraheeritakse MOSCoW või löögijõu abil ja tehakse ainult klaster "Must". Sageli on parim MVP enne isegi koodi: sihtleht, video või käsitsi teenus. AI on võimas kiirendi ulatuse määramisel, prioriteetide määramisel ja prototüüpide/lehekavandite loomisel; kuid "mõju" hinnanguid tuleks korrigeerida tegeliku kliendi signaaliga ja tehnilised/juriidilised kriitilised väljundid tuleks asjatundlikult üle vaadata.
Rakenduse ülesanne
Valige eeldus (mall "Õpiküsimus"). Küsige tehisintellektilt väikseimat MVP-d, mis seda eeldust testib, ja võimalusel ka ilma koodita versiooni. Eraldage oma kandidaadi funktsioonid malliga "MoSCoW", jättes alles vaid Peab määrama. Lõpuks koostage lihtsa sihtlehe mustand koos malliga „Sihtlehe tekst” ja kirjutage enne avaldamist üles oma edukriteeriumid (nt vähemalt 5 eelregistreerimist 20 külastajast).
kontrollnimekiri
- [ ] Kas ma olen oma MVP-testide ühe õppeküsimuse selgelt kirjutanud?
- [ ] Kas ma olen hinnanud koodita MVP versiooni?
- [ ] Kas seadsin funktsioonid prioriteediks ja jätsin ainult klastri "Peab"?
- [ ] Kas olen edukriteeriumid enne avaldamist määratlenud?
- [ ] Kas ma olen jätnud tehnilise/õiguskriitilise väljundi ekspertide üle?