Palju \u00f5nne, su MVP on elus. Kasutajad registreeruvad. Toode t\u00f6\u00f6tab. Oled valideerinud oma h\u00fcpoteesi ning ehk isegi sulgenud oma esimesed maksvad kliendid. <\/p>\n
Mis n\u00fc\u00fcd?<\/p>\n
Periood MVP k\u00e4ivitamise ja skaleeritud toote vahel on koht, kus paljud idufirmad komistavad. Kood, mis oli “piisavalt hea” 100 kasutajale, l\u00e4heb katki 10 000 juures. Funktsioonid, mille k\u00e4ivitamiseks v\u00e4lja l\u00f5ikasid, on n\u00fc\u00fcd need funktsioonid, mida su kasutajad n\u00f5uavad. Arhitektuur, mis lasi sul kiiresti liikuda, hakkab sind aeglustama. <\/p>\n
Oleme juhtinud mitmeid tooteid l\u00e4bi selle \u00fclemineku \u2014 kontseptsiooni t\u00f5estusest kuni tootmisvalmiduse s\u00fcsteemideni, mis k\u00e4sitlevad p\u00e4ris raha, p\u00e4ris kasutajaid ja p\u00e4ris vastavusn\u00f5udeid. Siin on see, mida oleme \u00f5ppinud selle kohta, mis tuleb p\u00e4rast k\u00e4ivitusp\u00e4eva. <\/p>\n
K\u00f5ige levinum viga, mida asutajad p\u00e4rast k\u00e4ivitamist teevad, on kohe hakata ehitama j\u00e4rgmist funktsiooni. Vastupane sellele kiusatusele. <\/p>\n
Su esimesed 30 p\u00e4eva p\u00e4ris kasutajatega on informatsiooni kullaauk. Vaata, kuidas nad toodet tegelikult kasutavad \u2014 mitte kuidas sa ette kujutasid, et nad seda teevad. Kus nad kinni j\u00e4\u00e4vad? Mida nad \u00fcritavad teha, mida sa ei osanud ennustada? Milliseid funktsioone nad ignoreerivad? <\/p>\n
Soovitame klientidel esimesel kuul k\u00f5ike instrumenteerida. Anal\u00fc\u00fctika, sessioonisalvestused, veaj\u00e4lgimine, tugivestlused \u2014 k\u00f5ik see toidab su k\u00e4ivitusj\u00e4rgset teekonda. Funktsioonid, mida enne k\u00e4ivitamist planeerisid, ei ole peaaegu kindlasti need funktsioonid, mida su kasutajad k\u00f5ige rohkem vajavad. <\/p>\n
Kui m\u00f5istad, kuhu toode peab minema, on siin tehniline t\u00f6\u00f6, mis tavaliselt peab toimuma:<\/p>\n
MVP andmebaasid on disainitud arendaja kiiruse, mitte p\u00e4ringute j\u00f5udluse jaoks. Kasutajate arvu kasvades p\u00f5rkud aeglaste p\u00e4ringute, puuduvate indeksite ning skeemiotsustega, mis olid m\u00f5istlikud protot\u00fc\u00fcpimisel, kuid mitte tootmises. <\/p>\n
Lahendus ei ole alati suurem andmebaas. Sageli on see \u00f5igete indeksite lisamine, sageli loetavate andmete denormaliseerimine ning vahem\u00e4lu rakendamine kulukate p\u00e4ringute jaoks. Oleme n\u00e4inud 10-kordset j\u00f5udluse paranemist \u00fchest fokusseeritud andmebaasi optimeerimise n\u00e4dalast \u2014 ilma infrastruktuurimuudatusteta. <\/p>\n
Su MVP-l on t\u00f5en\u00e4oliselt p\u00f5hiline autentimine, kuid piiratud kiiruspiirangud, sisendi valideerimine ning kuritarvituse ennetamine. Kasutajaskonna kasvades kasvab ka su r\u00fcndepind. <\/p>\n
Enne turunduse skaleerimist veendu, et su API l\u00f5pp-punktid on kiiruspiiratud, su sisendi valideerimine on p\u00f5hjalik ning su autentimist ei saa kergesti m\u00f6\u00f6da hiilida. FinTech toodete puhul ei ole see valikuline \u2014 see on regulatiivne n\u00f5ue. <\/p>\n
MVP arhitektuurid k\u00e4sitlevad sageli k\u00f5ike p\u00e4ring-vastus ts\u00fcklis. E-kirja saatmine? Tee seda otse. Maksete webhooki t\u00f6\u00f6tlemine? K\u00e4sitle seda s\u00fcnkroonselt. Aruande genereerimine? Lase kasutajal oodata. <\/p>\n
Skaleerudes l\u00e4heb see katki. Pikalt jooksvad \u00fclesanded blokeerivad su veebiservereid. Eba\u00f5nnestunud toimingutel ei ole korduskatse mehhanismi. Kasutajad n\u00e4evad tippkoormuse ajal aegumisi. <\/p>\n
Liikumine taustap\u00f5histe t\u00f6\u00f6de t\u00f6\u00f6tlemisele \u2014 korraliku j\u00e4rjekorra, korduskatse loogika ja j\u00e4lgimisega \u2014 on \u00fcks k\u00f5ige m\u00f5jukamaid skaleerimisinvesteeringuid, mida saad teha.<\/p>\n
MVP arenduse ajal t\u00e4hendab silumine tavaliselt logide lugemist serveris. Skaleerudes vajad struktureeritud logimist, veaj\u00e4lgimist, j\u00f5udluse j\u00e4lgimist ja hoiatamist. <\/p>\n
Eesm\u00e4rk on lihtne: tea probleemidest enne, kui su kasutajad sulle nendest r\u00e4\u00e4givad. Kui su makset\u00f6\u00f6tlus aeglustub kell 2 \u00f6\u00f6sel, tahad hoiatust \u2014 mitte vihast e-kirja kell 9 hommikul. <\/p>\n
Siin on muster, mida n\u00e4eme korduvalt: MVP \u00f5nnestub, asutaja kaasab investeeringuvooru ning j\u00e4rsku on teekaardil 50 funktsiooni, mis “peavad” j\u00e4rgmises kvartalis v\u00e4lja tulema.<\/p>\n
See on funktsioonide skaleerimise l\u00f5ks. Rohkem funktsioone t\u00e4hendab rohkem koodi, rohkem vigu, rohkem tugikoormust ja rohkem pinda, mida hooldada. Meeskonnad, kes skaleeruvad edukalt, on ei \u00fctlemises distsiplineeritud. <\/p>\n
Meie soovitus: iga uue funktsiooni puhul k\u00fcsi kolm k\u00fcsimust:<\/p>\n
Mingil hetkel skaleerimise ajal soovitab keegi meeskonnast rakenduse nullist \u00fcmberkirjutamist. See on peaaegu alati vale valik. <\/p>\n
\u00dcmberkirjutamine t\u00e4hendab:<\/p>\n
Selle asemel soovitame astmelist refaktoreerimist. Tuvasta moodulid, mis p\u00f5hjustavad k\u00f5ige rohkem valu. Kirjuta need \u00fcmber \u2014 \u00fcks korraga, funktsioonilippude taga, olemasoleva s\u00fcsteemiga varuvariandina. See on alguses aeglasem, kuid dramaatiliselt turvalisem. <\/p>\n
\u00dcks erand: kui MVP ehitati tehnoloogias, mis t\u00f5eliselt ei suuda su vajadustele skaleeruda (n\u00e4iteks no-code t\u00f6\u00f6riist tootele, mis vajab kohandatud infrastruktuuri), v\u00f5ib \u00fcmberkirjutamine olla \u00f5igustatud. Kuid isegi siis tee seda mooduli kaupa, mitte korraga. <\/p>\n
MVP arendus toimub sageli v\u00e4ikese, nutika meeskonnaga \u2014 ehk kahe v\u00f5i kolme arendajaga. Toote skaleerimine t\u00e4hendab tavaliselt meeskonna skaleerimist ning see toob kaasa omad v\u00e4ljakutsed. <\/p>\n
Uued arendajad peavad m\u00f5istma koodibaasi. Koodibaas peab toetama paralleelset arendust ilma pidevate \u00fchendamiskonfliktideta. Arhitektuur peab v\u00f5imaldama erinevate komponentide s\u00f5ltumatut kasutuselev\u00f5ttu. <\/p>\n
Siin vajab MVP faasi strateegiline tehniline v\u00f5lg t\u00e4helepanu. Kood, mis oli kolmele arendajale sobiv, muutub kaheksale kitsaskohaks. Investeerimine dokumentatsiooni, j\u00e4rjekindlatesse mustritesse, automaattestimisesse ning selgetesse moodulipiiridesse tasub end \u00e4ra meeskonna kasvades. <\/p>\n
Asutajad k\u00fcsivad alati: “Kui kaua v\u00f5tab aega minna MVP-st tootmisvalmiduseni?”<\/p>\n
Aus vastus: see s\u00f5ltub t\u00e4ielikult l\u00f5hest sinu praeguse ja vajaliku asukoha vahel. Kuid siin on umbkaudsed v\u00f5rdlusalused meie kogemusest: <\/p>\n