Fitimet:
- Aftësia për të kuptuar konceptin e MVP (produkti minimal i zbatueshëm) dhe logjikën e 'njësisë më të vogël mësimore' dhe për të përcaktuar qëllimin me inteligjencën artificiale
- Aftësia për të zbatuar prioritizimin e veçorive (MoSCoW, ndikim-përpjekje) dhe prodhimin e shpejtë të prototipit/faqes së uljes të mbështetur nga inteligjenca artificiale
- Të kuptuarit se qëllimi i MVP është të mësojë, jo të shesë, dhe se inxhinieria e tepërt është gabimi më i shtrenjtë i startup-it.
Gabimi më i shtrenjtë që bëjnë themeluesit është të shpenzojnë muaj për të përsosur një produkt që nuk janë të sigurt që dikush e dëshiron. Kur dalin në treg, mësojnë se ose problemi ishte i gabuar ose zgjidhja. Mënyra për të shmangur këtë fatkeqësi është MVP: produkti minimal i zbatueshëm - versioni më i vogël i produktit që do të sigurojë më shumë të mësuar me më pak përpjekje. Në këtë njësi, ne do të përdorim AI (inteligjencën artificiale) për të përcaktuar shtrirjen e MVP, për të dhënë përparësi veçorive dhe për të prodhuar prototipa/ngacmues të shpejtë. Fjalia më kritike: Qëllimi i MVP është të mësojë, jo të shesë; Gabimi më i shtrenjtë është mbi-inxhinierimi i supozimeve të pabazuara.
Çfarë është MVP dhe çfarë jo?
MVP është një koncept i keqkuptuar. Një MVP nuk është një "produkt i ngadaltë, i prishur"; Është përvoja më e vogël e plotë e nevojshme për të testuar një hipotezë të caktuar. Fjala kyçe është "të mësuarit". Pyete veten: "Cilës pyetje po përpiqem t'i përgjigjem?" MVP përmban mjaft veçori - jo më shumë, as më pak - për t'iu përgjigjur kësaj pyetjeje. Ndonjëherë një MVP mund të mos jetë as një aplikacion që funksionon: një faqe uljeje, një video, një shërbim manual (metoda "magjistari prapa" që duket të jetë automatike përpara ndërsa një njeri punon në sfond) mund të jetë gjithashtu një MVP.
E kundërta e MVP-së është inxhinieria e tepruar – përpjekjet e shpenzuara për veçori, shkallë dhe përsosmëri që nuk nevojiten ende – dhe lustrim me ar – lustrimi i detajeve që askush nuk dëshiron. Këta janë vrasësit më tinëzar të parave dhe kohës së startup-it; sepse ndihen sikur po “punojnë”, por e vonojnë mësimin.
Këshillë: Përpara se të shtoni një veçori, pyesni: "A mund të marr atë që dua të testoj pa këtë funksion?" Nëse përgjigja është "po", kjo veçori nuk do të hyjë në MVP. Çdo fjali "por ne kemi nevojë gjithashtu për këtë" që e bën MVP-në të rritet është një kosto që vonon të mësuarit.
Prioritetizimi i veçorive
Meqenëse nuk ka kohë dhe para të pakufizuar, është e nevojshme të vendosni se cila veçori do të ndërtohet së pari. Dy metoda praktike:
MosKëW: Ndan veçoritë në katër - Duhet, Duhet, Mund, Nuk do. MVP është thjesht një grup "Must".
Matrica ndikim-përpjekje: Vendos çdo veçori në boshtin e "ndikimit te klienti" dhe "përpjekjes për të bërë". Më parë bëhen ato me ndikim të lartë-përpjekje të ulët; Ato me ndikim të ulët dhe përpjekje të larta braktisen. Inteligjenca artificiale është një ndihmë e mirë për të futur shpejt një listë të veçorive në këtë matricë – por është e nevojshme të korrigjohet parashikimi i “ndikimit” me sinjalin e vërtetë të klientit.
Hap pas hapi: Dizajni MVP me AI
- Shkruani pyetjen mësimore. "Çfarë supozimi të vetëm do të testojë ky MVP?"
- Listoni veçoritë e kandidatit. Hidhni gjithçka në mendjen tuaj.
- Jepini përparësi me AI. Ekstrakt me MosCoW ose efekt-përpjekje; Gjeni grupin "Must".
- Zgjidhni formën më të lehtë. A kërkohet një kod apo është i mjaftueshëm një faqe ulje/video/shërbim manual?
- Prodhoni prototipin/faqen. Kërkoni nga AI për tekstin e bardhë, rrjedhën ose draftin e pseudokodit.
- Përcaktoni paraprakisht kriteret tuaja të suksesit. “Nëse e shoh këtë rezultat, supozimi konfirmohet”.
- Publikoni dhe mësoni. Mat sjelljen aktuale; Themeluesi merr vendimin.
tre mini kuti
Rasti 1 — MVP pa shkruar kod. Një themelues po mendonte për një aplikacion që lidhte fqinjët që shisnin ushqime të gatuara në shtëpi me klientët. Në vend që të kalonte muaj për të shkruar kodin, ai filloi me një faqe të vetme demo dhe një linjë WhatsApp; urdhrat e përputhura me dorë (metoda "magjistari prapa"). Ai mori 40 porosi aktuale në dy javë dhe mësoi se pengesa e vërtetë ishte logjistika e shpërndarjes. Nëse do të kishte shkruar kodin, do ta kishte mësuar këtë muaj më vonë. MVP solli të mësuarit përpara.
Rasti 2 - Kurthi i mbi-inxhinierisë. Një ekip kaloi 4 muaj duke ndërtuar një infrastrukturë që do të "shkallëzohej në miliona përdorues" kur nuk kishte ende një klient të vetëm. Kur produkti doli, askush nuk e donte; Problemi ishte i gabuar. Pothuajse e gjithë mundi i shpenzuar ishte kot. Mësimi: problemi i shkallës është një luks pas zgjidhjes së problemit të tërheqjes; Provoni atë që dikush dëshiron së pari.
Rasti 3 — Fuqia e prioritizimit. Një themelues kishte një listë me 30 veçori. Ai kërkoi që AI të krijonte një matricë ndikim-përpjekjeje dhe korrigjoi kolonën "ndikim" me sinjalin nga bisedat e vërteta të klientëve. Vetëm 4 nga 30 veçoritë rezultuan të jenë "Duhet". Lirohet MVP në 3 javë në vend të 6 muajve; Klienti tregoi se shumica e 26 veçorive të mbetura nuk ishin të nevojshme fare.
Katër shabllone të kopjueshëm
1) Pyetja mësimore + fushëveprimi MVP:
Roli juaj: trajner produkti i dobët. Supozimi që dua të testoj është:[p.sh. "Tregtarët paguajnë çdo muaj për koleksionet"]. (1) Përshkruani produktin MË I VOGËL që nevojitet për të verifikuar këtë supozim, (2) Tregoni nëse një version i këtij që nuk kërkon kod (faqe uljeje, video, shërbim manual) është i mundur, (3) Paralajmëroni për veçoritë "tërheqëse por të panevojshme" që nuk duhet të hyjnë në MVP.
2) Prioriteti i Moskës:
Ndani listën e mëposhtme të veçorive në MOSCOW: Duhet / Duhet / Mund / Nuk do. Duhet të përfshihen vetëm ato që janë "DUHET për supozimin që dua të testoj". Shkruani me një fjali pse çdo veçori është në atë grup. Lista: [veçoritë].
3) Matrica ndikim-përpjekje:
Shënoni tiparet e mëposhtme në akset "ndikimi tek klientët (1-5)" dhe "përpjekja për të bërë (1-5)" dhe vendosini ato në 4 kuadrate. Shënoni ato me ndikim të lartë-përpjekje të ulët si "bëj së pari", dhe ato me ndikim të ulët me përpjekje të lartë si "mos bëj". Më kujto se rezultatet e ndikimit duhet të vërtetohen kundrejt angazhimit tim aktual të klientit. Lista: [veçoritë].
4) Teksti i faqes së uljes:
Shkruani një tekst të faqes me spërkatje për MVP-në time. Seksionet: (1) titulli në gjuhën e klientit (propozimi i vlerës), (2) tregim për zgjidhjen e problemit, (3) 3 pikë përfitimi, (4) një telefonatë e qartë (regjistrimi paraprak / lista e pritjes). Përdorimi i premtimeve të ekzagjeruara; Vetëm pretendimet që mund t'i verifikoj. Turk, i thjeshtë, i sinqertë.
Prompt i dobët / Prompt i fortë
Njoftim i dobët:
Listoni të gjitha veçoritë për produktin tim.
Ky prompt shkon kundër logjikës MVP; Ai prodhon një listë të gjatë dëshirash që vonon të mësuarit dhe fton mbi-inxhinierimin.
Njoftim i fuqishëm:
I vetmi supozim që dua të testoj është: [x]. Përshkruani MVP-në më të VOGËL që do të verifikojë këtë supozim, propozoni një version që nuk kërkon kod, ndani veçoritë me MosCoW dhe lini vetëm vendosjen Must. Më ndihmo të mos shkruaj paraprakisht kriteret e mia të suksesit (i cili rezultat vërteton supozimin).
Qasje
Shkalla e të mësuarit
Kostoja
Rreziku
Bërja e produktit të plotë nga e para
shumë i ngadalshëm
lartë
Mos vendosni para në gjënë e gabuar
Inxhinieri ekstreme/artë
i ngadalshëm
shumë e lartë
Gabimi më i shtrenjtë
Vetëm MVP i domosdoshëm
shpejtë
të ulëta
i menaxhueshëm
MVP pa kod (ulje/elle)
më i shpejtë
më e ulëta
mësimi i hershëm
Gabimet e zakonshme
- Gabimi i MVP-së për një produkt të plotë. MVP është njësia më e vogël e të mësuarit, jo finalja e lëmuar.
- Mbi-inxhinieri. Kalimi i muajve në shkallë/përsosmëri kur nuk ka klientë aty pranë; Gabimi më i shtrenjtë.
- Nuk përcakton një pyetje mësimore. Një MVP që nuk e di se çfarë po teston është një humbje pa drejtim.
- Vendosja e kritereve për sukses më vonë. Nëse kriteret nuk janë shkruar paraprakisht, çdo rezultat do të interpretohet si "sukses".
- Duke anashkaluar opsionet pa kod. Faqja e uljes/video/kodi i shkrimit kur mund ta provoni manualisht me shërbimin.
Kujdes: AI mund të prodhojë një prototip ose draft kodi, por ju jeni përgjegjës për sigurinë, saktësinë dhe pajtueshmërinë ligjore të kodit të prodhuar. Sidomos në MVP-të që përfshijnë pagesa, të dhëna personale ose siguri, prodhimi i AI është një skicë fillestare; Është thelbësore që një zhvillues/ekspert kompetent ta rishikojë atë përpara se të dalë drejtpërdrejt.
Në përmbledhje
MVP është produkti më i vogël që ofron më shumë mësim me më pak përpjekje; Qëllimi i tij nuk është të shesë, por të testojë një supozim. Gabimi më i shtrenjtë është inxhinieria e tepërt dhe lyerja me flori të një produkti të paprovuar që askush nuk e dëshiron. Çdo MVP fillon me një pyetje mësimore; veçoritë nxirren nga MosCoW ose ndikim-përpjekje dhe krijohet vetëm grupi "Must". Shpesh MVP-ja më e mirë vjen para edhe kodit: faqja e uljes, video ose shërbimi manual. AI është një përshpejtues i fuqishëm në përcaktimin e fushëveprimit, prioritizimin dhe prodhimin e prototipeve/projekteve të faqeve; por vlerësimet e “ndikimit” duhet të korrigjohen nga sinjali aktual i klientit dhe rezultatet teknike/ligjore-kritike duhet të rishikohen me ekspertizë.
Detyra e aplikimit
Zgjidhni një supozim (shabllon "Pyetja e të mësuarit"). Pyetni AI për MVP-në më të vogël që do të testojë këtë supozim, dhe nëse është e mundur, një version pa kod. Ndani veçoritë e kandidatit tuaj me shabllonin "MoSCoW", duke lënë vetëm grupin Must. Së fundi, krijoni një draft të faqes së uljes pa ndryshime me shabllonin "Teksti i faqes së uljes" dhe shkruani kriteret tuaja të suksesit (p.sh. të paktën 5 regjistrime paraprake nga 20 vizitorë) përpara se ta publikoni.
listë kontrolli
- [ ] A e kam shkruar qartë pyetjen e vetme mësimore testet e mia MVP?
- [ ] A kam vlerësuar një version MVP pa kod?
- [ ] A i kam dhënë përparësi veçorive dhe a kam lënë vetëm grupin "Duhet"?
- [ ] A i kam përcaktuar kriteret e suksesit përpara publikimit?
- [ ] A e kam lënë rezultatin teknik/juridik-kritik në shqyrtimin e ekspertëve?