Startupa izstrāde: no idejas līdz pirmajiem lietotājiem

Tev ir ideja par digitālu projektu. Varbūt tā ir lietotne, platforma, marketplace, AI rīks vai jauns pakalpojums. Galvā jau redzi, kā tam vajadzētu darboties, bet nav skaidrs, ko darīt vispirms.

Vai uzreiz meklēt programmētāju? Rakstīt tehnisko specifikāciju? Zīmēt dizainu? Reģistrēt uzņēmumu? Piesaistīt investoru? Vispirms izveidot landing page vai uzreiz visu sistēmu?

Pareizā atbilde gandrīz nekad nav “sāksim ar visu funkciju programmēšanu”.

Startupa izstrāde sākas ar problēmas, klienta un svarīgāko pieņēmumu definēšanu. Tikai pēc tam jāizlemj, ko būvēt. Labs pirmais projekts nav tas, kurā ir visvairāk funkciju. Tas ir mazākais risinājums, kas spēj dot reālu vērtību un pārbaudīt, vai biznesa ideja darbojas.

Šajā rakstā iziesim cauri visam procesam:

1. ideja un sākotnējā definēšana;
2. pirmā saruna ar izstrādes partneri;
3. problēmas, auditorijas un biznesa modeļa precizēšana;
4. prototips un MVP;
5. izstrāde īsos ciklos;
6. testēšana un pirmie lietotāji;
7. iterācijas pēc reāliem datiem;
8. growth un scale, ja projekts sāk augt.

Atsevišķi apskatīsim arī izstrādes partnera izvēli, biežākos riskus un to, kāpēc startupam bieži nepietiek ar cilvēku, kurš tikai uzraksta kodu pēc dotā uzdevuma.

1. Sāc nevis ar funkciju sarakstu, bet ar problēmu

Pirmajā sarunā dibinātāji bieži sāk šādi:

Vajag reģistrāciju, lietotāju profilus, čatu, maksājumus, paziņojumus, administrācijas paneli un mobilo lietotni.

Taču tas vēl nepasaka, kāpēc projektam vajadzētu eksistēt.

Daudz vērtīgāk ir sākt ar pieciem jautājumiem:

1. Kam ir problēma?
2. Kāda tieši ir problēma?
3. Kā cilvēks to risina šobrīd?
4. Kāpēc esošais risinājums nav pietiekams?
5. Kādu izmērāmu ieguvumu dos jaunais projekts?

Piemēram, “vajag platformu skolotājiem” ir pārāk plaši.

Labāks sākums:

Sākumskolas matemātikas skolotāji katru nedēļu pavada vairākas stundas, gatavojot dažāda grūtības līmeņa uzdevumus. Gribam dot iespēju dažu minūšu laikā izveidot interaktīvu spēli konkrētai tēmai un uzreiz nosūtīt to klasei.

Tagad jau var apspriest:

• kurš ir pirmais lietotājs;
• kāds ir svarīgākais rezultāts;
• ko nevajag būvēt sākumā;
• kā izmērīt, vai projekts palīdz;
• kāds varētu būt biznesa modelis.

Ko sagatavot pirms pirmās tikšanās?

Nav vajadzīga 80 lapu tehniskā specifikācija. Pietiek ar vienu vai divām lapām.

Pieraksti:

• ideju vienā teikumā;
• mērķa lietotāju;
• problēmu;
• pašreizējo alternatīvu;
• vēlamo rezultātu;
• svarīgākās funkcijas;
• līdzīgus projektus;
• ko jau esi pārbaudījis;
• pieejamo budžetu vai diapazonu;
• vēlamo pirmās versijas termiņu;
• lielākās neskaidrības.

Ja nezini atbildes, tas nav šķērslis tikšanās sarunai. Tieši šīs neskaidrības ir jāatklāj un jāsakārto.

Ideju drīkst izstāstīt arī tad, ja tā vēl nav perfekta

Daži dibinātāji mēnešiem slīpē ideju vienatnē, jo baidās, ka tā vēl nav gatava vai kāds to nozags.

Parasti lielākais risks nav idejas nozagšana. Lielākais risks ir uzbūvēt projektu, kuru neviens negrib.

Profesionālam partnerim nav jāgaida gatavs uzdevums. Viņa vērtība sākas tieši tajā brīdī, kad ideja vēl ir neskaidra un jāpieņem svarīgākie projekta lēmumi.

Ja ideja ietver sensitīvu tehnoloģiju, partnerību vai komercnoslēpumu, pirms detalizētas informācijas atklāšanas var noslēgt konfidencialitātes vienošanos. Taču NDA neaizvieto uzticama partnera izvēli un praktisku izpildi.

2. Pirmā tikšanās nav pārdošanas prezentācija - tā ir discovery

Pirmās tikšanās mērķis nav uzreiz nosaukt cenu visam projektam. Vispirms jāsaprot, ko vispār ir vērts būvēt.

Labā discovery jeb izpētes sarunā apspriež:

• problēmu un tās nozīmīgumu;
• pirmo lietotāju segmentu;
• lietotāja pašreizējo procesu;
• konkurentus un alternatīvas;
• biznesa modeli;
• cenu hipotēzi;
• pirmo klientu piesaisti;
• tehniskos riskus;
• juridiskos vai datu riskus;
• svarīgāko pieņēmumu, kas jāpārbauda;
• MVP robežas.

Izstrādes partnerim šajā sarunā vajadzētu ne tikai klausīties, bet arī uzdot neērtus jautājumus:

• Kāpēc cilvēks par šo maksās?
• Vai to pašu jau nevar izdarīt ar ChatGPT vai esošu rīku?
• Kāpēc vajag mobilo lietotni, nevis sākumā responsīvu mājaslapu?
• Vai marketplace sākumā būs pietiekami daudz pircēju un pārdevēju?
• Vai tiešām vajag automatizēt procesu, kuru vēl neviens nav izmēģinājis manuāli?
• Kur atradīsies pirmie desmit lietotāji?
• Kas notiks, ja galvenā ārējā API mainīs cenu?

Tas nav pesimisms. Šādi tiek pasargāts budžets.

Kas jāiegūst pēc discovery?

Pēc sākotnējās izpētes vajadzētu būt skaidram vismaz:

1. kam projekts paredzēts;
2. kādu galveno problēmu tas atrisina;
3. kāds ir pirmais vērtīgais lietotāja rezultāts;
4. kādi pieņēmumi vēl nav pierādīti;
5. ko testēt ar prototipu;
6. kas ietilpst MVP;
7. kas apzināti tiek atlikts;
8. kā tiks iegūti pirmie lietotāji;
9. kādi dati parādīs, vai projekts virzās pareizi;
10. kāds ir aptuvenais budžeta un termiņa diapazons.

Ne visam jābūt zināmam precīzi. Taču abām pusēm jāredz viens un tas pats nākamais solis.

3. Definējam projektu pirms izstrādes

Definēšana nenozīmē, ka mēģinām iepriekš aprakstīt katru pogu. Tās mērķis ir novērst lielākos pārpratumus un noteikt prioritātes.

Projekta definīcijas pamats

Lietotājs

Nevis “visi uzņēmumi”, bet, piemēram:

Nelielas personāla atlases aģentūras ar 3-15 darbiniekiem, kas katru nedēļu manuāli apkopo kandidātu informāciju no vairākiem avotiem.

Problēma

Ko lietotājs nevar izdarīt pietiekami ātri, lēti, droši vai kvalitatīvi?

Vērtības solījums

Kāds būs uzlabojums?

No divām stundām līdz desmit minūtēm. No pieciem rīkiem līdz vienai darba plūsmai. No minējuma līdz izmērāmam rezultātam.

Galvenā lietotāja darbība

Kura ir viena darbība, bez kuras projekts zaudē jēgu?

Biznesa modelis

Kurš maksā, par ko maksā un kā cena aug kopā ar vērtību?

Veiksmes metrika

Nevis tikai “projekts ir gatavs”, bet:

• cik lietotāju sasniedz pirmo rezultātu;
• cik atgriežas;
• cik samaksā;
• cik ilgu laiku projekts ietaupa;
• cik bieži tiek izpildīta galvenā darbība.

User journey jeb lietotāja ceļš

Pirms ekrānu zīmēšanas apraksta svarīgāko lietotāja ceļu:

1. kā viņš uzzina par projektu;
2. kā saprot piedāvājumu;
3. kā reģistrējas;
4. kā ievada vai pievieno nepieciešamo informāciju;
5. kā saņem pirmo rezultātu;
6. kā saprot, ko darīt tālāk;
7. kā un kad maksā;
8. kā atgriežas nākamajā reizē.

Ja galveno ceļu nevar skaidri izstāstīt, funkciju saraksts vēl ir par agru.

Prioritātes: must, should, could, later

Funkcijas var sadalīt četrās grupās:

• Must: bez tā nevar pārbaudīt galveno vērtību.
• Should: svarīgi, bet pirmo testu iespējams veikt arī bez tā.
• Could: patīkami uzlabojumi.
• Later: vajadzēs, ja projekts pierādīs pieprasījumu.

Lielākā daļa sākotnēji “obligāto” funkciju pēc godīgas sarunas nonāk kategorijā “vēlāk”. Tas nav projekta noplicinājums. Tā ir riska samazināšana.

4. Prototips pirms pilnas izstrādes

Prototips ļauj lēti pārbaudīt projekta loģiku, pirms tiek ieguldīts laiks pilnā programmēšanā.

Tas var būt:

• ekrānu skice;
• klikšķināms dizains;
• landing page;
• video demonstrācija;
• tehnisks eksperiments;
• manuāli izpildīts pakalpojums;
• no-code versija.

Ko var pārbaudīt ar prototipu?

• Vai lietotājs saprot, ko projekts dara?
• Vai viņš atrod galveno darbību?
• Vai soļu ir par daudz?
• Kādas funkcijas viņš sagaida?
• Vai rezultāts šķiet pietiekami vērtīgs?
• Vai viņš piekrīt izmēģināt vai maksāt?

Dizaina prototips neatrisina tehnisko risku

Ja idejas centrā ir sarežģīta attēlu atpazīšana, AI precizitāte, liels datu apjoms vai integrācija ar vecu sistēmu, vajag atsevišķu tehnisko prototipu.

Skaists Figma ekrāns var pierādīt, ka cilvēks saprot ideju. Tas nepierāda, ka tehnoloģija spēs dot vajadzīgo rezultātu par pieņemamu cenu.

Tāpēc prototips jāizvēlas pēc lielākā riska:

• tirgus risks → landing page vai intervijas;
• lietojamības risks → klikšķināms prototips;
• tehniskais risks → proof of concept;
• cenas risks → reāls piedāvājums vai priekšpasūtījums;
• rezultāta risks → manuāli izpildīts pilotprojekts.

5. MVP: mazākais projekts, kas spēj kaut ko pierādīt

MVP nav lēta un nekvalitatīva gala projekta kopija. Tas ir mazākais funkcionējošais risinājums, ar kuru iespējams iegūt ticamus datus.

Y Combinator agrīniem startupiem iesaka palaist projektu ātri, iedot to lietotājiem un iterēt. Kamēr projekts nav lietotāja rokās, lielākā daļa diskusiju balstās pieņēmumos.

Labs MVP

• atrisina vienu svarīgu problēmu;
• ļauj lietotājam sasniegt vienu pilnu rezultātu;
• ir pietiekami uzticams reālai lietošanai;
• ļauj savākt analītiku un atsauksmes;
• ir uzbūvēts tā, lai pēc testa varētu pieņemt lēmumu;
• apzināti neietver visu nākotnes vīziju.

Piemērs: marketplace

Pilnā vīzija var ietvert:

• pircēju un pārdevēju profilus;
• maksājumus;
• iekšējo čatu;
• atsauksmes;
• rekomendācijas;
• strīdu sistēmu;
• abonementus;
• mobilo lietotni.

MVP var būt daudz šaurāks:

• viena konkrēta preču vai pakalpojumu kategorija;
• viena pilsēta;
• vienkāršs piedāvājumu katalogs;
• pieprasījuma forma;
• darījumu sākumā koordinē dibinātājs manuāli.

Vispirms jāpierāda, ka pircēji un pārdevēji grib satikties. Sarežģīta automātiska strīdu sistēma nav vērtīga platformai bez darījumiem.

Piemērs: AI dokuments

Pilnā vīzija ir platforma, kas importē uzņēmuma dokumentus, analizē riskus, sadarbojas ar komandu un veido atskaites.

MVP var būt:

• viena dokumenta augšupielāde;
• viens konkrēts dokumenta tips;
• piecu būtiskāko risku noteikšana;
• rezultāta pārbaude no cilvēka puses;
• lejupielādējams pārskats.

Tādā veidā pārbauda, vai rezultāts klientam ir vērtīgs, pirms būvē veselu dokumentu pārvaldības sistēmu.

6. Kā izvēlēties izstrādes partneri?

Startupam ir vairāki ceļi:

• būvēt pašam;
• nolīgt freelanceru;
• izveidot savu komandu;
• izvēlēties lielu izstrādes uzņēmumu;
• sadarboties ar projektu un startupu izstrādes partneri.

Katram modelim ir situācijas, kurās tas ir pareizs.

Freelancers

Labs freelancers var būt ļoti spēcīgs risinājums konkrētam un skaidri definētam uzdevumam. Viņš var būt ātrs, elastīgs un izmaksāt mazāk nekā aģentūra.

Galvenie riski

• visa kritiskā informācija atrodas pie viena cilvēka;
• cilvēks var kļūt nepieejams vai pāriet uz citu projektu;
• dokumentācija un nodošana var būt nepietiekama;
• viņš var izpildīt uzdevumu tehniski, bet neiedziļināties biznesā;
• var nebūt visu nepieciešamo kompetenču dizainā, drošībā, izaugsmē un infrastruktūrā;
• pēc palaišanas nav skaidras uzturēšanas atbildības.

Tas nenozīmē, ka freelanceri pazūd vai nedomā par biznesu. Daudzi ir izcili partneri. Taču sadarbībā ar vienu cilvēku jānovērš viena punkta risks: kodam, serveriem, domēnam, datiem un dokumentācijai jāpaliek pieejamai klientam.

Liels izstrādes uzņēmums

Lielai komandai ir procesu, kompetenču un aizvietojamības priekšrocības. Tā var būt pareizā izvēle bankai, valsts projektam vai lielai sistēmai ar sarežģītu iepirkumu un augstām atbilstības prasībām.

Startupa riski

• augstas izmaksas;
• daudz projektu vadības un procesu;
• lēnāka lēmumu pieņemšana;
• startupam jāfinansē plaša komandas struktūra;
• līgums var būt orientēts uz funkciju piegādi, nevis biznesa rezultātu;
• katra jauna funkcija palielina projekta apjomu un rēķinu;
• piegādātājam var nebūt finansiālas motivācijas pateikt: “Šo nevajag būvēt.”

Labs liels izstrādātājs, protams, var būt stratēģisks un godīgs. Taču klientam jāsaprot konkrētā sadarbības modeļa stimuli: vai partneris pelna no tava rezultāta vai galvenokārt no pārdoto darba stundu skaita?

Sava komanda

Sava komanda dod lielāku kontroli un uzkrāj zināšanas uzņēmumā. Tā ir īpaši vērtīga, kad projekts jau pierādīts un tehnoloģija ir uzņēmuma galvenā priekšrocība.

Taču sākumā tā nozīmē:

• atlasi;
• algas un nodokļus;
• vadību;
• darba aprīkojumu;
• kompetenču nepilnības;
• risku algot pirms skaidra projekta virziena.

MVP stadijā pilna komanda var būt pāragrs fiksēto izmaksu slogs.

Startup izstrādes partneris

Šis modelis atrodas starp freelanceru un tradicionālu lielu aģentūru.

Ideja ir apvienot:

• projekta definēšanu;
• tehnisko izstrādi;
• startupu un biznesa modeļu izpratni;
• validāciju;
• lietotāju pieredzi;
• analītiku;
• pirmo growth mehānismu domāšanu.

Partnera uzdevums nav automātiski piekrist funkciju sarakstam. Viņam vajadzētu palīdzēt saprast, kura funkcija rada vērtību un kuru var atlikt.

7. Ko piedāvāju es?

Es nepiedāvāju tikai “uzprogrammēt pēc specifikācijas”. Mani interesē, vai pašam projektam ir iespēja strādāt kā biznesam.

Izstrādes procesā skatos uz projektu no vairākām pusēm:

• kādu problēmu tas risina;
• kurš būs pirmais lietotājs;
• kā projekts pelnīs;
• kā pārbaudīt pieprasījumu pirms lielām izmaksām;
• kādu MVP patiešām vajag;
• kā cilvēks projektu sapratīs un lietos;
• kur iegūt pirmos lietotājus;
• ko mērīt pēc palaišanas;
• kā projekts varētu augt;
• kas nākotnē veidos tā MOAT.

Man ir svarīgi pateikt arī:

“Šo pagaidām nebūvēsim.” “Šo vispirms pārbaudīsim manuāli.” “Tehniski to var izdarīt, bet biznesam tas šobrīd nepalīdz.” “Ja nezinām, kur būs pirmie lietotāji, pirms izstrādes jāatrisina tas.”

Tas dažkārt samazina sākotnējo izstrādes apjomu, bet palielina iespēju, ka nauda tiek ieguldīta pareizajā projektā.

Izstrāde + startup pieredze

Praktiski sadarbība var ietvert:

• idejas strukturēšanu;
• tirgus un konkurentu analīzi;
• biznesa modeļa izvēli;
• funkciju prioritizēšanu;
• prototipu;
• dizainu;
• tehnisko arhitektūru;
• MVP izstrādi;
• analītikas uzstādīšanu;
• testēšanu;
• palaišanu;
• pirmo lietotāju rezultātu analīzi;
• nākamo iterāciju plānu;
• growth un scale sagatavošanu.

Tas nenozīmē, ka viens cilvēks vienmēr dara visu vai ka katram projektam vajag visus posmus. Vajadzības gadījumā tiek piesaistītas papildu kompetences. Taču projekta virziens paliek vienots - tehnoloģija netiek atrauta no biznesa.

“Es” vai “mēs”?

Šajā sadarbības modelī godīgi ir teikt “es”, jo klients zina, ar ko tieši runā un kurš personīgi iedziļinās projektā. Vienlaikus projekts tiek īstenots caur uzņēmumu, un vajadzības gadījumā iespējams piesaistīt citus speciālistus.

Tas nav anonīms “mēs”, aiz kura nav skaidrs atbildīgais. Un tas nav arī gadījuma cilvēks bez uzņēmuma un ilgtermiņa atbildības.

Klientam svarīgāk par vietniekvārdu ir skaidri zināt:

• kurš vada projektu;
• kam pieder kods un konti;
• kas notiek pēc palaišanas;
• kā tiek nodrošināta uzturēšana;
• ko darīt, ja nepieciešama lielāka komanda.

Iespējama sadarbība par nelielu uzņēmuma daļu

Atsevišķos projektos iespējams vienoties, ka daļa atlīdzības tiek aizstāta ar nelielu līdzdalību uzņēmumā.

Klientam tas var nozīmēt:

• mazākas sākotnējās naudas izmaksas;
• partneri ar lielāku interesi par ilgtermiņa rezultātu;
• ciešāku iesaisti projekta un biznesa attīstībā.

Man tas nozīmē:

• daļu riska uzņemos kopā ar dibinātāju;
• mans ieguvums rodas tikai tad, ja uzņēmums kļūst vērtīgāks;
• ir lielāka motivācija domāt tālāk par sākotnējo izstrādi.

Taču daļas nav “bezmaksas izstrāde”. Tām var nebūt nekādas vērtības, un izstrāde prasa reālu laiku. Tāpēc šāds modelis ir piemērots tikai dažiem projektiem, kuriem ir:

• spēcīga problēma un tirgus potenciāls;
• iesaistīts dibinātājs;
• skaidra lomu sadale;
• reālistisks ceļš līdz klientiem;
• savstarpēja uzticība;
• juridiski sakārtota vienošanās.

Vienošanās jānosaka rakstiski: daļu apmērs, iegūšanas nosacījumi, lēmumu tiesības, intelektuālais īpašums, abu pušu ieguldījums, izstāšanās scenāriji un tas, kas notiek, ja projekts tiek apturēts.

Bieži veselīgāks ir hibrīds:

samazināta naudas samaksa + neliela līdzdalība,

nevis visa darba finansēšana tikai ar cerību uz nākotnes vērtību.

8. Kāpēc visu nevar izplānot pirms izstrādes?

Programmatūras izstrādē ir lietas, kuras iespējams paredzēt, un lietas, kuras atklājas tikai strādājot.

Izstrādes laikā var noskaidroties:

• ārējā API nedod gaidīto rezultātu;
• lietotājs nesaprot sākotnēji iecerēto plūsmu;
• viena funkcija atrisina daudz lielāku problēmu nekā pārējās;
• datu kvalitāte ir zemāka, nekā gaidīts;
• maksājumu vai juridiskais process ir sarežģītāks;
• lietotājs vēlas citu rezultātu;
• vienkāršāks risinājums strādā labāk;
• sākotnējais biznesa modelis nav piemērots.

Tas nenozīmē, ka plānošana nav vajadzīga. Plāns palīdz koordinēt darbu un budžetu. Taču startupa plānam jābūt hipotēzei, kuru drīkst mainīt, nevis reliģiskam tekstam.

Agile programmatūras izstrādes pamatideja ir dot priekšroku strādājošam projektam, sadarbībai ar klientu un spējai reaģēt uz pārmaiņām, nevis aklai sākotnējā plāna izpildei.

Klasiskā “izpildām specifikāciju” problēma

Ja sadarbības modelis ir tikai:

klients uzraksta → izstrādātājs uzprogrammē,

var rasties absurda situācija. Izstrādātājs redz, ka funkcija lietotājam neko nedod vai ka ir daudz vienkāršāks risinājums, taču turpina darbu, jo tas ir pasūtīts.

Formāli uzdevums ir izpildīts. Praktiski nauda ir iztērēta nevajadzīgai funkcijai.

Labs partneris nedrīkst patvaļīgi mainīt klienta projektu. Taču viņam ir pienākums pamanīt risku, argumentēti to izskaidrot un piedāvāt alternatīvu.

Kā saglabāt elastību, nezaudējot kontroli?

• Fiksē skaidru MVP mērķi.
• Sadali darbu īsos posmos.
• Katram posmam nosaki rezultātu un budžetu.
• Uzturi prioritizētu backlog.
• Pirms izmaiņas novērtē ietekmi uz termiņu un cenu.
• Regulāri demonstrē strādājošu versiju.
• Nošķir kļūdu no jaunas prasības.
• Saglabā lēmumu vēsturi.
• Atstāj daļu budžeta atklājumiem un neparedzētajam.

Elastība nenozīmē haosu. Tā nozīmē kontrolētu spēju mainīt virzienu, kad parādās jauni pierādījumi.

9. Izstrāde notiek ciklā: taisām, testējam, mācāmies

Praktisks iterācijas cikls:

1. definējam konkrētu problēmu vai hipotēzi;
2. izvēlamies mazāko izmaiņu, kas to pārbauda;
3. uzbūvējam;
4. notestējam tehniski;
5. parādām lietotājiem;
6. izmērām rezultātu;
7. pieņemam lēmumu - turpināt, mainīt vai atmest.

Ne katrs cikls rada jaunu funkciju. Dažreiz pareizais rezultāts ir:

• noņemt lieku soli;
• pārrakstīt piedāvājumu;
• mainīt cenu;
• automatizēt vienu manuālu procesu;
• atteikties no funkcijas;
• fokusēties uz citu lietotāju segmentu.

Tehniskā testēšana

Jāpārbauda:

• galvenās funkcijas;
• dažādas ierīces un pārlūki;
• kļūdaini ievades dati;
• maksājumi;
• piekļuves tiesības;
• datu drošība;
• rezerves kopijas;
• veiktspēja;
• ārējo servisu kļūmes.

Lietojamības testēšana

Iedod projektu mērķa lietotājam un vēro, nepalīdzot katrā solī.

Skaties:

• vai viņš saprot pirmo ekrānu;
• kur apstājas;
• ko mēģina nospiest;
• kādus vārdus nesaprot;
• vai sasniedz galveno rezultātu;
• cik ilgi tas prasa;
• vai vēlas turpināt.

Lietotājs nav “muļķis”, ja nesaprot interfeisu. Projekts vēl nav pietiekami skaidrs.

Biznesa testēšana

Tehniski strādājošs projekts vēl nav strādājošs bizness.

Jāpārbauda:

• vai cilvēks reģistrējas;
• vai aktivizējas;
• vai maksā;
• vai atgriežas;
• cik maksā viņu iegūt;
• kāpēc viņš atsakās;
• vai vienu pārdošanu iespējams atkārtot.

10. Pirmā palaišana

Launch nav projekta beigas. Tā ir brīdis, kad beidzot sākas darbs ar realitāti.

Pirmajai palaišanai nav jābūt milzīgai publiskai kampaņai. Bieži labāk sākt ar:

• 5-20 personīgi atlasītiem lietotājiem;
• vienu uzņēmumu pilotprojektā;
• vienu skolu;
• vienu pilsētu;
• vienu profesionālo nišu;
• slēgtu beta versiju.

Neliela grupa ļauj ātri sazināties ar katru cilvēku un salabot būtiskāko, pirms projektā ienāk lielāks trafiks.

Pirms launch vajag

• strādājošu galveno lietotāja ceļu;
• analītiku;
• kļūdu uzraudzību;
• rezerves kopijas;
• privātuma un lietošanas noteikumus, ja tie nepieciešami;
• atbalsta kontaktu;
• maksājumu pārbaudi;
• skaidru ziņu pirmajiem lietotājiem;
• plānu, kā saņemt atsauksmes.

Pēc launch skaties ne tikai uz trafiku

Svarīgāk par apmeklējumu skaitu ir:

• aktivizācija;
• galvenās darbības izpilde;
• laiks līdz pirmajai vērtībai;
• atkārtota lietošana;
• maksājums;
• churn;
• lietotāju teiktais un faktiskā rīcība.

11. Riski un pārpratumi - kā tos samazināt?

Risks: atšķirīga izpratne par “gatavs”

Klients ar “gatavs” var domāt pilnībā noslīpētu projektu. Izstrādātājs - tehniski funkcionējošu MVP.

Risinājums

Katram posmam definē pieņemšanas kritērijus un konkrētu demonstrējamu rezultātu.

Risks: scope creep

Izstrādes laikā rodas arvien jaunas idejas, un projekts nekad nebeidzas.

Risinājums

Jaunas idejas nonāk backlog, nevis automātiski pašreizējā darba apjomā. Apstiprinot izmaiņu, skaidri pasaka, ko tā maina cenā un termiņā.

Risks: neskaidrs budžets

Klients sagaida fiksētu gala cenu, lai gan prasības vēl mainās.

Risinājums

Var fiksēt discovery un MVP posma robežas, bet attīstību plānot pa iterācijām. Der arī budžeta griesti un regulārs atlikuma pārskats.

Risks: visas pieejas ir pie izstrādātāja

Domēns, serveris, kods, analītika un maksājumi atrodas svešos kontos.

Risinājums

Kritiskajiem kontiem jābūt uzņēmuma īpašumā vai uzņēmumam jābūt administratora pieejai. Jāvienojas par koda repozitoriju, parolēm, dokumentāciju un nodošanas procesu.

Risks: nav skaidrs, kam pieder intelektuālais īpašums

Risinājums

Līgumā norāda:

• kam pieder speciāli projektam radītais kods un dizains;
• kā drīkst izmantot trešo pušu un open-source komponentes;
• kad īpašumtiesības pāriet;
• ko partneris drīkst izmantot kā vispārīgu pieredzi vai portfolio.

Risks: trešās puses maina noteikumus

Projekts var būt atkarīgs no AI API, maksājumiem, sociālā tīkla vai datu piegādātāja.

Risinājums

• identificēt kritiskās atkarības;
• aprēķināt cenu izmaiņu scenārijus;
• saglabāt iespēju nomainīt piegādātāju;
• nepārkāpt platformas noteikumus;
• nebalstīt visu biznesu uz vienu trauslu integrāciju.

Risks: projekts tiek uzbūvēts, bet nav lietotāju

Risinājums

Par auditoriju, pre-launch un pirmajiem testētājiem jādomā paralēli izstrādei. Izplatīšana nav darbs, ko sāk dienu pēc launch.

Risks: dibinātājs un izstrādātājs gaida viens uz otru

Risinājums

Vienojas par:

• atbildīgajiem;
• atbilžu termiņiem;
• regulāru statusa ritmu;
• lēmumu pieņēmēju;
• vietu, kur glabā uzdevumus un lēmumus;
• to, kas notiek, ja atgriezeniskā saite kavējas.

Risks: tehniskais parāds

MVP tiek būvēts ātri, un pagaidu risinājumi paliek gadiem.

Risinājums

Apzināti dokumentē kompromisus. Pirms lielāka scale pārskata arhitektūru, drošību, testus un infrastruktūru. Ne viss jāpārbūvē, bet jāzina, kur atrodas vājās vietas.

12. Kas notiek, ja projekts sāk strādāt?

Ja cilvēki projektu lieto, atgriežas un maksā, sākas jauns posms.

Tagad var domāt par:

• jaunām funkcijām;
• onboarding uzlabošanu;
• A/B testiem;
• konversijas palielināšanu;
• rekomendāciju mehānismiem;
• maksas reklāmu;
• SEO un saturu;
• jauniem cenu plāniem;
• komandas funkcijām;
• integrācijām;
• jauniem tirgiem.

Taču katrai jaunai funkcijai joprojām jāatbild uz jautājumu:

Kuru būtisku lietotāja vai biznesa rādītāju tā uzlabos?

No MVP uz stabilu projektu

Pirms liela trafika var būt vajadzīgs:

• pārskatīt arhitektūru;
• optimizēt datubāzi;
• ieviest automātiskos testus;
• uzlabot drošību;
• izveidot monitoringu;
• samazināt AI un infrastruktūras izmaksas;
• automatizēt manuālos procesus;
• izveidot klientu atbalsta sistēmu;
• dokumentēt projektu un kodu.

MVP uzdevums bija pārbaudīt biznesu. Scale sistēmas uzdevums ir uzticami apkalpot augošu biznesu. Tā var būt tā pati koda bāze ar uzlabojumiem vai daļēja pārbūve - to nosaka reālais tehniskais stāvoklis, nevis automātisks noteikums.

Kad vajag paplašināt komandu?

Kad ir pierādīts pieprasījums un darba apjoms kļūst lielāks, var piesaistīt:

• papildu izstrādātājus;
• UX/UI dizaineru;
• QA;
• DevOps un drošības kompetenci;
• datu vai AI speciālistu;
• projektu vadītāju;
• growth un pārdošanas cilvēkus;
• klientu atbalstu.

Komandu vajag palielināt ap pierādītu vajadzību, nevis lai izskatītos pēc “īsta startupa”.

Praktiska sadarbības secība

1. Īsa idejas saruna

Saprotam problēmu, auditoriju, pašreizējo stadiju un to, vai sadarbībai ir jēga.

2. Discovery

Precizējam biznesa un projekta hipotēzes, konkurentus, riskus un MVP mērķi.

3. Prototips vai tehniskais eksperiments

Pārbaudām neskaidrāko un dārgāko pieņēmumu.

4. MVP plāns

Funkcijas, lietotāja ceļš, tehnoloģija, analītika, posmi, budžets un termiņa diapazons.

5. Līgums un projekta pamati

Atbildība, maksājumi, intelektuālais īpašums, konti, uzturēšana un izmaiņu kārtība.

6. Izstrāde īsās iterācijās

Regulāri pieejama demonstrējama, strādājoša versija.

7. Testēšana ar lietotājiem

Tehniskie testi, lietojamība un biznesa hipotēzes.

8. Launch

Sākumā nelielai, konkrētai auditorijai.

9. Mērījumi un prioritātes

Skatāmies, kas strādā, kas nestrādā un ko būvēt tālāk.

10. Growth un scale

Tikai pēc tam, kad projektam ir reālas pieprasījuma un noturēšanas pazīmes.

Ko sagatavot, ja vēlies pārrunāt savu ideju?

Pirms sarunas vari atsūtīt:

• idejas aprakstu dažos teikumos;
• kam projekts domāts;
• kādu problēmu tas risina;
• līdzīgus projektus;
• funkcijas, kuras šķiet svarīgas;
• ko jau esi pārbaudījis;
• vēlamo termiņu;
• aptuveno budžeta diapazonu;
• galvenos jautājumus un bažas.

Ja tev vēl nav tehniskās specifikācijas, tas ir pilnīgi normāli. To nevajag izdomāt vienatnē, pirms ir sakārtota projekta būtība.

Noslēgumā

Startupa izstrāde nav pasūtījums “uztaisiet man aplikāciju”. Tas ir process, kurā ideja tiek pārvērsta pārbaudāmā projektā un pēc tam - cerams - strādājošā biznesā.

Labā izstrādes procesā:

• vispirms definē problēmu;
• pārbauda riskantākos pieņēmumus;
• uzbūvē šauru MVP;
• regulāri rāda strādājošu rezultātu;
• testē ar reāliem lietotājiem;
• maina plānu, ja dati rāda ko citu;
• neiztērē budžetu funkcijām bez skaidras vērtības;
• jau laikus domā par biznesa modeli un auditoriju;
• pēc pieprasījuma pierādīšanas gatavo projektu izaugsmei.

Es varu palīdzēt ne tikai projektu uzbūvēt, bet arī saprast, ko tieši ir vērts būvēt, kam tas būs vajadzīgs un kā no pirmās versijas nonākt līdz reālam biznesam.

Jo startupam nevajag vairāk funkciju. Tam vajag vairāk pierādījumu, ka tas iet pareizajā virzienā.

Avoti un tālāka lasīšana

• Agile Manifesto - sadarbība, strādājošs projekts un spēja reaģēt uz pārmaiņām: https://agilemanifesto.org/
• Y Combinator - How to Build an MVP: https://www.ycombinator.com/library/Io-how-to-build-an-mvp
• Y Combinator - How to Plan an MVP: https://www.ycombinator.com/library/6f-how-to-plan-an-mvp
• Y Combinator - Guide to Product Development: https://www.ycombinator.com/library/4e-guide-to-product-development
• UK Government Service Manual - discovery, alpha, beta un live posmi: https://www.gov.uk/service-manual/agile-delivery