Anden del af min serie om uafhængig produktudvikling
Den forrige artikel beskrev fra en iOS-udviklers perspektiv ressourcer til at definere et behov, udvikle en uafhængig app og udgive den. Med begrænsede ressourcer kunne jeg kun færdiggøre værktøjsapps, der var tilgængelige i Apples App Store.
Denne artikel handler om at udvikle et fuldt udbygget produkt på tværs af platforme, de problemer, vi møder, og deres løsninger. Jeg fortæller, hvordan jeg gradvist byggede et komplet produktøkosystem med en officiel WeChat-konto, et miniprogram og en app.
1. Produktmål
I bred forstand er et produktmål den værdi, et produkt skaber. Selv når der findes et anvendelsesscenarie, har et produkt uden værdi — et produkt, der ikke kan tjene penge og har meget få brugere — ikke megen grund til at eksistere.
Eller vi kunne begynde endnu bredere med produktvisionen…
Stop dér. Tænk ikke på alt det endnu, ellers kommer dit produkt måske aldrig videre end dine endeløse forestillinger.
Når ressourcer, mennesker og investeringer er begrænsede, bliver målet tydeligt: Hvilke problemer skal produktet løse, eller hvilke funktioner skal det have?
Da jeg for eksempel byggede File Manager, havde MVP'en et klart mål: at overføre filer mellem en telefon og en computer.
Da MVP'en var færdig, opstod der naturligt andre krav. Nogle kom fra mine produktplaner, men de fleste kom fra brugerfeedback:
- 1.0.0 Overfør filer mellem telefon og computer
- 1.1.0 Vis eller afspil billed-, video- og lydfiler
- 1.2.0 Gruppér, flyt, slet, komprimér og del filer
- 1.3.0 Forbedr afspilleren
- 1.4.0 Tilføj sikkerhedskontrol: bevægelsesadgangskoder og biometri
- 2.0.0 Tilføj køb i appen
- 2.1.0 Tilføj dokumentscanning
- …
Vælg et mål. Det behøver ikke være stort, men det skal kunne gennemføres. Fokuser på én ting ad gangen, og fortsæt, selv om det virker forkert — hvordan kan du vide det uden at gøre den færdig ◔ ‸◔? Gør den færdig, og evaluér bagefter.
2. Produktprototyper
I den forrige artikel nævnte jeg, at jeg havde prøvet mange prototypeværktøjer og konkluderet, at jeg kunne have bygget skærmbillederne med xib på den tid, det tog at designe prototypen.
Lad mig modsige mig selv her ,,Ծ‸Ծ,,
Det er forståeligt at tænke sådan, når man laver en personlig værktøjsapp uden nogen plan for det videre forløb og kun ønsker at færdiggøre og udgive den.
Efterhånden som produktet udvikler sig, vil det give alvorlige problemer for den fremtidige udvikling, hvis man går frem ét skridt ad gangen uden prototype eller plan. At designe en prototype er i virkeligheden en proces, hvor produktets logik organiseres.
Her er nogle prototypeværktøjer. Det, jeg bruger mest i øjeblikket, er MockingBot.
3. Projektstyring
Efter selvstændigt at have udviklet og udgivet en iOS-app opdagede jeg et alvorligt problem: Jeg havde ingen forståelse for projektstyring. Jeg arbejdede, når jeg havde tid eller kom i tanke om det, og lavede intet, når jeg var doven.
Det var mit eget produkt, designet og udviklet af mig. MVP'en havde sandsynligvis ingen betalende brugere, så jeg følte ikke, at jeg stod til ansvar over for dem.
Det forsinker et projekt alvorligt. Arbejde uden en plan i for lang tid kan ligefrem slå det ihjel.
Efter flere år med iterationsstyring på arbejdet fandt jeg ud af, at projektstyringsværktøjer også fungerer godt til personlige projekter. Når vi har klare produktmål og en logisk sammenhængende prototype, følger det naturligt at dele arbejdet op i opgaver.
Jeg bruger coding.net til projektstyring; tjenesten kan også hoste kildekode.
Del opgaverne op i enheder målt i timer. Det gør dem lettere at styre og hjælper med at skrive testcases. Min nuværende vane er at gøre testcasene færdige før kodningen. Det er afgørende.
En prototype organiserer produktlogikken; testcases organiserer implementeringsdetaljerne. Komplette testcases leder os mod den rigtige forretningslogik ✅ og forebygger mange forretningsfejl ❌.
4. Valg af teknologi
Indtil nu har alt dette været forberedelse; vi er endnu ikke begyndt at udvikle. Den afgørende udfordring er, at jeg er den eneste udvikler, men ønsker at bygge det komplette økosystem med en officiel WeChat-konto, et miniprogram og en app.
Vi ville have brug for kompetencer inden for miniprogrammer, iOS og Android. Det er ikke så svært at lære et programmeringssprog, men det koster tre gange så meget arbejde at implementere den samme forretningslogik tre gange. Det er tydeligvis urealistisk.
Normalt kunne vi bruge webbet til at betjene flere platforme eller ligefrem opgive appen og fokusere på en officiel konto plus et miniprogram. I produktets tidlige fase, hvor behovene skal valideres hurtigt, er dette en meget fornuftig løsning.
En kort søgning afslører mange teknologier på tværs af platforme. For at bygge en app og et miniprogram med én kodebase til tre platforme kan vi bruge Uni-App. Det bruger frontendframeworket Vue.js, mens iOS og Android understøttes gennem Weex.
Det er tilstrækkeligt til personlige produkter eller små kommercielle produkter.
5. Datastyring
Da løsningen med miniprogram og app er fastlagt, står endnu et vigtigt spørgsmål tilbage: Hvor skal dataene ligge?
For et værktøj er det nok at gemme data lokalt i appen. Men hvad hvis målet er en informationsplatform med et komplet brugersystem eller ligefrem et mere komplekst fællesskab med brugerskabt indhold?
Uni-App tilbyder sin egen uniCloud-tjeneste. Serverudvikling kan foretages i JavaScript, og miniprogrammer og apps kan bruge serveren uden et domænenavn.
Jeg valgte en anden tilgang: at hoste dataene på den serverløse platform LeanCloud. Miniprogrammet og appen tilgår den hostede database gennem LeanClouds JavaScript-SDK.
Udviklingsniveauet understøtter 30.000 gratis API-anmodninger om dagen og tilbyder også SMS-tjenester. Det er nok til at bygge et brugersystem, uploade brugerdata og hente platformdata.
Når antallet af anmodninger overstiger udviklingskvoten, har produktet opnået en vis brugerbase. Jeg tror, at indtægten fra trafikken på det tidspunkt vil kunne dække det kommercielle niveau med betaling efter forbrug.
En fræk måde at skaffe data på
Hvad hvis du vil bygge en vejr- eller informationsapp, men ikke har vejr- eller nyhedsdata?
Der findes mange API-markedspladser i Kina, blandt andet:
og andre.
Disse markedspladser tilbyder både betalte og gratis API'er.
Hvis dit produkt har en god måde at tjene penge på trafikken, kan du overveje betalte API'er.
Hvis ikke, kan du bruge gratiskvoterne. Men en prøveperiode med 100 anmodninger kan hurtigt blive brugt under test. Hvad så?
Du kan kombinere LeanClouds serverløse database med en API-markedsplads. For det daglige vejr kan du for eksempel først spørge databasen. Hvis dataene mangler, henter du dem fra markedspladsen og gemmer dem derefter i databasen.
Men hvad hvis 100 anmodninger stadig ikke kan dække alle byer? Hold gratistankegangen i live, og ansøg hos flere platforme.
6. Lancering og drift
Nu er vi færdige med at udvikle miniprogrammet, appen og serveren. Hvordan lancerer vi?
Miniprogrammer er forholdsvis ligetil: Følg anvisningerne på WeChat Official Accounts Platform for at ansøge om et miniprogram.
Udgivelse på iOS kræver en betalt udviklerkonto. Det er en barriere, men til langsigtet drift anbefaler jeg at ansøge på Apples udviklerwebsted. Ansøgningen er nu enkel: Hent Developer-appen på en iPhone, og betal der.
Distribution på Android kræver registrering af softwareophavsret. En normal ansøgning kan tage 1–2 måneder, eller du kan betale en tredjepartsagent for at håndtere den.
Vi fortsætter gratistankegangen: Hvor kan vi gemme billeder, lyd og video til kampagneplaceringerne i appen og miniprogrammet?
Den officielle kontos mediebibliotek kan løse problemet. Gem billeder, lyd og video der, hent deres oprindelige URL'er, og så kan appen og miniprogrammet tilgå dem.
7. Indtjening
En enkel måde at tjene penge på trafik er annoncering.
Platformenes adgangskrav til udgivere bliver dog stadig højere, så det er svært for uafhængige udviklere at integrere annoncer.
Uni-App tilbyder integration med ét klik; se dokumentationen.
Når en officiel konto har opbygget et publikum, kan den aktivere annoncepladser i artikler.
Et miniprogram kan aktivere udgiverindtjening, når det har nået 1.000 unikke besøgende.
8. Afsluttende tanker
Nu har vi færdiggjort økosystemet med en officiel WeChat-konto, et miniprogram og en app, som blev beskrevet i begyndelsen.
Ved at følge disse trin gennemførte jeg processen for tre produkter. Scan koderne for at prøve dem:
