Vienība 6 / 11

MVP un produktu izstrāde: mazākais pārbaudāmais produkts

Ieguvumi:

  • Spēja izprast MVP (minimālā dzīvotspējīgā produkta) jēdzienu un "mazākās mācību vienības" loģiku un noteikt tvērumu ar mākslīgo intelektu
  • Spēja ieviest funkciju prioritāšu noteikšanu (MoSCoW, ietekmes piepūle) un mākslīgā intelekta atbalstītu ātru prototipu/galvenās lapas izveidi
  • Saprotot, ka MVP mērķis ir mācīties, nevis pārdot, un ka pārmērīga inženierija ir visdārgākā starta kļūda.

Dārgākā kļūda, ko pieļauj dibinātāji, ir mēnešiem ilgi, lai pilnveidotu produktu, kuru viņi nav pārliecināti, ka kāds to vēlas. Kad viņi dodas uz tirgu, viņi uzzina, ka problēma bija nepareiza vai risinājums. Veids, kā izvairīties no šīs katastrofas, ir MVP: minimālais dzīvotspējīgais produkts — mazākā produkta versija, kas nodrošinās vislielāko apmācību ar vismazāko piepūli. Šajā vienībā mēs izmantosim AI (mākslīgo intelektu), lai noteiktu MVP darbības jomu, piešķirtu prioritāti funkcijām un izveidotu ātrus prototipus/paziņojumus. Kritiskākais teikums: MVP mērķis ir mācīties, nevis pārdot; Visdārgākā kļūda ir pārmērīga nepamatotu pieņēmumu izstrāde.

Kas ir MVP un kas nav?

MVP ir pārprasts jēdziens. MVP nav “apliets, bojāts produkts”; Tā ir mazākā pilnīga pieredze, kas nepieciešama, lai pārbaudītu konkrētu hipotēzi. Atslēgas vārds ir "mācīšanās". Pajautājiet sev: "Uz kādu jautājumu es cenšos atbildēt?" MVP satur pietiekami daudz funkciju - ne vairāk, ne mazāk -, lai atbildētu uz šo jautājumu. Dažreiz MVP var pat nebūt strādājoša lietojumprogramma: galvenā lapa, videoklips, manuāls pakalpojums (“vedņa aizmugures” metode, kas šķiet automātiska priekšā, bet cilvēks strādā fonā) var būt arī MVP.

MVP pretstats ir pārlieku liela inženierija — pūles, kas tiek tērētas vēl nevajadzīgām funkcijām, mērogiem un pilnībai — un zelta pārklājums — nevienam nevēlamu detaļu pulēšana. Šie ir vismānīgākie starta naudas un laika slepkavas; jo viņiem šķiet, ka viņi "strādā", bet kavē mācības.

Padoms. Pirms funkcijas pievienošanas jautājiet: "Vai varu iegūt to, ko vēlos pārbaudīt, neizmantojot šo līdzekli?" Ja atbilde ir "jā", šī funkcija neietilpst MVP. Katrs teikums "bet mums vajag arī šo", kas liek MVP augt, ir izmaksas, kas aizkavē mācīšanos.

Funkciju prioritāšu noteikšana

Tā kā nav neierobežota laika un naudas, ir jāizlemj, kura funkcija tiks uzbūvēta vispirms. Divas praktiskas metodes:

Maskava: funkcijas sadala četrās daļās — jābūt, vajadzētu, nevajadzētu, nevajadzētu. MVP ir tikai "obligāts" komplekts.

Ietekmes un piepūles matrica: novieto katru līdzekli uz "ietekmes uz klientu" un "piepūles veikt" ass. Vispirms tiek veiktas lielas ietekmes un mazas piepūles; Tiek atmesti tie, kuriem ir zema ietekme un liela piepūle. AI ir labs palīgs, lai šajā matricā ātri ievietotu funkciju sarakstu, taču ir nepieciešams labot “ietekmes” prognozi ar reālo klienta signālu.

Soli pa solim: MVP dizains ar AI

  1. Uzrakstiet mācību jautājumu. “Kādu pieņēmumu pārbaudīs šis MVP?”
  2. Norādiet kandidātu funkcijas. Izlejiet visu, kas jums ir prātā.
  3. Nosakiet prioritāti ar AI. Ekstrakts ar MoSCoW vai efekts-piepūle; Atrodiet kopu “Must”.
  4. Izvēlieties vieglāko formu. Vai ir nepieciešams kods vai pietiek ar galveno lapu/videoklipu/manuālo pakalpojumu?
  5. Izveidojiet prototipu/lapu. Lūdziet AI, lai iegūtu baltā papīra tekstu, plūsmu vai pseidokoda melnrakstu.
  6. Iepriekš definējiet savus veiksmes kritērijus. "Ja es redzu šo rezultātu, pieņēmums apstiprinās."
  7. Publicējiet un mācieties. Izmērīt faktisko uzvedību; Lēmumu pieņem dibinātājs.

trīs mini futrāļi

1. gadījums — MVP bez koda ierakstīšanas. Kāds dibinātājs domāja par lietotni, kas savienoja kaimiņus, kas pārdod mājās gatavotus ēdienus, ar klientiem. Tā vietā, lai pavadītu mēnešus, rakstot kodu, viņš sāka ar vienu demonstrācijas lapu un WhatsApp līniju; saskaņoti pasūtījumi manuāli ("vedņa aiz muguras" metode). Divu nedēļu laikā viņš saņēma 40 reālus pasūtījumus un uzzināja, ka īstā vājā vieta ir piegādes loģistika. Ja viņš būtu uzrakstījis kodu, viņš to būtu iemācījies mēnešus vēlāk. MVP virzīja mācīšanos uz priekšu.

2. gadījums — pārmērīgi izstrādāts slazds. Viena komanda pavadīja 4 mēnešus, veidojot infrastruktūru, kas "līdzētu miljoniem lietotāju", kad tai vēl nebija neviena klienta. Kad produkts iznāca, neviens to negribēja; Problēma bija nepareiza. Gandrīz visas iztērētās pūles tika izniekotas. Nodarbība: mēroga problēma ir greznība pēc vilces problēmas atrisināšanas; Vispirms pierādiet, ko kāds vēlas.

3. gadījums — prioritāšu noteikšanas spēja. Vienam dibinātājam bija 30 funkciju saraksts. Viņš lika AI izveidot ietekmes un piepūles matricu un koriģēt kolonnu “ietekme” ar signālu no reālām klientu sarunām. Tikai 4 no 30 iezīmēm izrādījās "obligāti". Atbrīvots MVP pēc 3 nedēļām, nevis pēc 6 mēnešiem; Klients parādīja, ka lielākā daļa no atlikušajām 26 funkcijām vispār nav vajadzīgas.

Četras kopējamas veidnes

1) Mācību jautājums + MVP darbības joma:

Jūsu loma: liesa produkta treneris. Pieņēmums, ko vēlos pārbaudīt, ir: [piem. "tirgoņi maksā katru mēnesi par kolekcijām"].(1) Aprakstiet MAZĀKO produktu, kas nepieciešams, lai pārbaudītu šo pieņēmumu. (2) Norādiet, vai ir iespējama šī produkta versija, kurai nav nepieciešams kods (galvenā lapa, video, manuālā apkalpošana). (3) Brīdiniet par "pievilcīgām, bet nevajadzīgām" funkcijām, kurām nevajadzētu iekļūt MVP.

2) Maskavas prioritāšu noteikšana:

Sadaliet šādu funkciju sarakstu Maskavā: Jā / Vajadzētu / Nevarētu / Nevajadzētu. Jāiekļauj tikai tie, kas ir OBLIGĀTI, lai pieņemtu, ko vēlos pārbaudīt. Vienā teikumā uzrakstiet, kāpēc katrs līdzeklis atrodas šajā klasterī.Saraksts: [funkcijas].

3) Ietekmes un piepūles matrica:

Novērtējiet tālāk norādītos līdzekļus uz asīm "ietekme uz klientiem (1-5)" un "piepūle izdarīt (1-5)" un ievietojiet tos 4 kvadrantos. Atzīmējiet tos, kuriem ir liela ietekme un neliela piepūle, kā "darīt vispirms" un zema trieciena un lielas piepūles piepūli kā "nedariet". Atgādiniet man, ka ietekmes rādītāji ir jāapstiprina attiecībā pret manu faktisko klientu iesaisti. Saraksts: [funkcijas].

4) Galvenās lapas teksts:

Uzrakstiet uzplaiksnījuma lapas tekstu manam MVP. Sadaļas: (1) nosaukums klienta valodā (vērtības piedāvājums), (2) problēmas risinājuma stāstījums, (3) 3 ieguvumu punkti, (4) skaidrs aicinājums (iepriekšēja reģistrācija / gaidīšanas saraksts). Pārspīlētu solījumu izmantošana; Tikai apgalvojumi, kurus varu pārbaudīt. Turkiski, vienkārši, sirsnīgi.

Vāja uzvedne / spēcīga uzvedne

Vāja uzvedne:

Uzskaitiet visas mana produkta funkcijas.

Šī uzvedne ir pretrunā MVP loģikai; Tas veido garu vēlmju sarakstu, kas aizkavē mācīšanos un aicina pārlieku konstruēt.

Spēcīga uzvedne:

Vienīgais pieņēmums, ko vēlos pārbaudīt, ir: [x]. Aprakstiet MAZĀKO MVP, kas pārbaudīs šo pieņēmumu, piedāvājiet versiju, kurai nav nepieciešams kods, atdaliet līdzekļus ar MOSCoW un atstājiet tikai Jāiestata. Palīdziet man iepriekš neuzrakstīt savus veiksmes kritērijus (kurš rezultāts apstiprina pieņēmumu).

Pieeja

Mācību līmenis

Izmaksas

Risks

Visa produkta izgatavošana no nulles

pārāk lēni

augsts

Nelieciet naudu nepareizā lietā

Ekstrēma inženierija/apzeltīšana

lēns

ļoti augsts

Dārgākā kļūda

Tikai obligātais MVP

ātri

zems

pārvaldāms

MVP bez koda (nosēšanās/elle)

ātrākais

zemākais

agrīna mācīšanās

Biežas kļūdas

  • MVP sajaukt ar pilnu produktu. MVP ir mazākā mācīšanās vienība, nevis slīpētais fināls.
  • Pārmērīga inženierija. Mēnešu pavadīšana mērogā/pilnībā, kad tuvumā nav neviena klienta; Dārgākā kļūda.
  • Nedefinē mācību jautājumu. MVP, kas nezina, ko pārbauda, ​​ir bezvirziena izšķiešana.
  • Veiksmes kritēriju noteikšana vēlāk. Ja kritēriji nav uzrakstīti iepriekš, katrs rezultāts tiks interpretēts kā "veiksmīgs".
  • Bezkoda opciju apiešana. Galvenā lapa/video/rakstīšanas kods, ja varat to pārbaudīt manuāli, izmantojot pakalpojumu.
Uzmanību: AI var izveidot prototipu vai koda uzmetumu, taču jūs esat atbildīgs par izveidotā koda drošību, precizitāti un juridisko atbilstību. Īpaši MVP, kas saistīti ar maksājumiem, personas datiem vai drošību, AI izvade ir sākotnējā skice; Ir svarīgi, lai kompetents izstrādātājs/eksperts to pārskatītu pirms tiešraides.

Rezumējot

MVP ir mazākais produkts, kas nodrošina visvairāk mācīšanās ar vismazāko piepūli; Tās mērķis nav pārdot, bet gan pārbaudīt pieņēmumu. Dārgākā kļūda ir pārmērīga inženierija un nepārbaudīta produkta apzeltīšana, ko neviens nevēlas. Katrs MVP sākas ar mācību jautājumu; funkcijas tiek iegūtas ar MOSCoW vai trieciena piepūli, un tiek izveidots tikai klasteris “Must”. Bieži vien labākais MVP tiek rādīts pat pirms koda: galvenā lapa, video vai manuālā apkalpošana. AI ir spēcīgs paātrinātājs tvēruma noteikšanā, prioritāšu noteikšanā un prototipu/lapu melnrakstu izveidē; bet “ietekmes” aplēses ir jākoriģē pēc faktiskā klienta signāla, un tehniski/juridiski kritiskie rezultāti ir profesionāli jāpārskata.

Lietojumprogrammas uzdevums

Izvēlieties pieņēmumu (veidne "Mācību jautājums"). Jautājiet AI par mazāko MVP, kas pārbaudīs šo pieņēmumu, un, ja iespējams, versiju bez koda. Atdaliet kandidātu funkcijas, izmantojot veidni "MoSCoW", atstājot tikai opciju Jāiestata. Visbeidzot, izveidojiet vienkāršu galvenās lapas uzmetumu, izmantojot veidni “Galvenās lapas teksts”, un pirms publicēšanas pierakstiet veiksmes kritērijus (piemēram, vismaz 5 iepriekšējās reģistrācijas no 20 apmeklētājiem).

kontrolsaraksts

  • [ ] Vai esmu skaidri uzrakstījis vienu mācību jautājumu savos MVP testos?
  • [ ] Vai esmu novērtējis bezkoda MVP versiju?
  • [ ] Vai es noteicu funkcijām prioritāti un atstāju tikai kopu Obligāti?
  • [ ] Vai pirms publicēšanas esmu definējis panākumu kritērijus?
  • [ ] Vai tehnisko/juridiski kritisko rezultātu esmu atstājis ekspertu pārbaudē?