Del två i min serie om oberoende produktutveckling
Den förra artikeln beskrev resurser för att definiera ett behov, utveckla en oberoende app och lansera den, ur en iOS-utvecklares perspektiv. Med begränsade resurser kunde jag bara färdigställa verktygsappar tillgängliga i Apples App Store.
Den här artikeln handlar om att utveckla en fullständig produkt för flera plattformar, problemen vi möter och deras lösningar. Jag berättar hur jag steg för steg byggde ett komplett produktekosystem med ett officiellt WeChat-konto, ett miniprogram och en app.
1. Produktmål
I stora drag är ett produktmål det värde produkten tillför. Även om det finns ett användningsfall har en produkt utan värde, som inte tjänar pengar och har mycket få användare, liten anledning att existera.
Eller så kan vi börja ännu bredare, med produktvisionen…
Stanna där. Tänk inte på allt det där än, annars kanske produkten aldrig kommer längre än dina ändlösa föreställningar.
När resurser, människor och investeringar är begränsade blir målet tydligt: vilka problem ska produkten lösa, eller vilka funktioner måste den erbjuda?
När jag till exempel byggde Filhanteraren hade MVP:n ett tydligt mål: överföra filer mellan en telefon och en dator.
När MVP:n var klar kom det naturligt fler krav. En del kom från mina produktplaner, men fler kom från användarnas återkoppling:
- 1.0.0 Överföra filer mellan telefon och dator
- 1.1.0 Förhandsvisa eller spela upp bild-, video- och ljudfiler
- 1.2.0 Gruppera, flytta, radera, komprimera och dela filer
- 1.3.0 Förbättra spelaren
- 1.4.0 Lägga till säkerhetsverifiering: mönsterkoder och biometri
- 2.0.0 Lägga till köp i appen
- 2.1.0 Lägga till dokumentskanning
- …
Välj ett mål. Det behöver inte vara stort, men det måste gå att genomföra. Fokusera på en sak i taget och fortsätt även om den verkar fel — hur kan du veta det utan att slutföra den ◔ ‸◔? Slutför och utvärdera sedan.
2. Produktprototyper
I den förra artikeln nämnde jag att jag provat många prototypverktyg och kommit fram till att jag kunde ha byggt skärmarna med xib på den tid det tog att utforma prototypen.
Låt mig säga emot mig själv här ,,Ծ‸Ծ,,
Det är begripligt att tänka så när man bygger en egen verktygsapp utan fortsatta planer och bara vill bli klar och lansera.
När produkten utvecklas kommer stegvis arbete utan prototyp eller plan att skapa stora problem för framtida utveckling. Att utforma en prototyp är egentligen att ordna produktens logik.
Här finns några prototypverktyg. Det jag använder mest just nu är MockingBot.
3. Projektledning
Efter att själv ha utvecklat och släppt en iOS-app upptäckte jag ett allvarligt problem: jag hade ingen förståelse för projektledning. Jag arbetade när jag hade tid eller kom ihåg det och gjorde ingenting när jag var lat.
Det var min egen produkt, designad och utvecklad av mig. MVP:n hade förmodligen inga betalande användare, så jag kände inget ansvar gentemot dem.
Det här bromsar ett projekt rejält. Att arbeta utan plan för länge kan till och med döda det.
Efter flera år med iterationsledning på jobbet upptäckte jag att projektledningsverktyg också fungerar bra för egna projekt. När produktmålen är tydliga och prototypens logik hänger ihop blir det naturligt att dela upp arbetet i uppgifter.
Jag använder coding.net för projektledning; tjänsten kan också lagra källkod.
Dela upp uppgifterna i enheter som mäts i timmar. Då blir de lättare att hantera och det blir enklare att skriva testfall. Min nuvarande vana är att skriva klart testfallen innan jag kodar. Det är nödvändigt.
En prototyp ordnar produktlogiken; testfall ordnar implementationsdetaljerna. Kompletta testfall hjälper oss att skapa korrekt affärslogik ✅ och förebygger många fel i den ❌.
4. Teknikval
Hittills har allt varit förberedelser; vi har inte börjat utveckla. Den avgörande svårigheten är att jag är ensam utvecklare, men vill bygga ett komplett ekosystem med ett officiellt WeChat-konto, ett miniprogram och en app.
Vi skulle behöva kunskaper om miniprogram, iOS och Android. Att lära sig ett programmeringsspråk är inte så svårt, men att implementera samma affärslogik tre gånger kräver tre gånger så mycket arbete. Det är uppenbart orealistiskt.
Normalt kan vi använda webben för flera plattformar, eller till och med avstå från appen och fokusera på ett officiellt konto plus ett miniprogram. Tidigt i utvecklingen, när produktbehoven måste valideras snabbt, är det ett mycket rimligt alternativ.
En kort sökning visar många plattformsöverskridande tekniker. För att bygga en app och ett miniprogram med en kodbas på tre plattformar kan vi använda Uni-App. Det använder frontendramverket Vue.js, med stöd för iOS och Android genom Weex.
Det räcker för egna produkter eller små kommersiella produkter.
5. Datahantering
När lösningen för miniprogrammet och appen är bestämd återstår en viktig fråga: var ska data lagras?
För ett verktyg räcker lokal lagring i appen. Men om målet är en informationsplattform med ett komplett användarsystem eller en ännu mer komplex gemenskap med användargenererat innehåll?
Uni-App erbjuder sin egen uniCloud-tjänst. Serverutvecklingen kan göras i JavaScript, och miniprogram och appar kan använda servern utan ett domännamn.
Jag valde en annan väg: att lagra data på den serverlösa plattformen LeanCloud. Miniprogrammet och appen kommer åt databasen via LeanClouds JavaScript-SDK.
Utvecklingsnivån stöder 30 000 gratis API-anrop per dag och erbjuder även SMS-tjänster. Det räcker för att bygga ett användarsystem, ladda upp användardata och hämta plattformsdata.
När anropen överskrider utvecklingskvoten har produkten fått en viss användarbas. Jag tror att intäkterna från trafiken då bör täcka den kommersiella nivån med betalning efter användning.
Ett finurligt sätt att få tag på data
Vad gör du om du vill bygga en väder- eller informationsapp men saknar väder- eller nyhetsdata?
Det finns många API-marknadsplatser i Kina, bland annat:
och andra.
Marknadsplatserna erbjuder både betalda och gratis API:er.
Om produkten har ett bra sätt att tjäna pengar på trafiken kan du överväga betalda API:er.
Annars kan du överväga gratiskvoterna. Men en provperiod med 100 anrop kan ta slut redan under testningen. Vad gör man då?
Du kan kombinera den serverlösa LeanCloud-databasen med en API-marknadsplats. För dagens väder frågar du till exempel databasen först. Om uppgifterna saknas hämtar du dem från marknadsplatsen och sparar dem sedan i databasen.
Men om 100 anrop fortfarande inte räcker till alla städer? Håll gratisandan vid liv och ansök hos flera plattformar.
6. Lansering och drift
Nu är utvecklingen av miniprogrammet, appen och servern klar. Hur lanserar vi?
Miniprogram är relativt enkla: på WeChats plattform för officiella konton följer du instruktionerna för att ansöka om ett miniprogram.
En iOS-lansering kräver ett betalt utvecklarkonto. Det är en tröskel, men för långsiktig drift rekommenderar jag att ansöka på Apples utvecklarwebbplats. Nu är det enkelt att ansöka: ladda ner Developer-appen på en iPhone och betala där.
För Android-distribution behövs upphovsrättsregistrering för programvaran. En vanlig ansökan kan ta 1–2 månader, eller så kan du betala en extern förmedlare för att sköta den.
Vi fortsätter i gratisandan: var kan vi lagra bilder, ljud och video för marknadsföringsytorna i appen och miniprogrammet?
Det officiella kontots mediebibliotek kan lösa problemet. Lagra bilder, ljud och video där, hämta deras ursprungliga webbadresser så kan appen och miniprogrammet komma åt dem.
7. Skapa intäkter
Ett enkelt sätt att tjäna pengar på trafik är reklam.
Plattformarnas behörighetskrav för publicister blir dock allt högre, vilket gör det svårt för oberoende utvecklare att integrera reklam.
Uni-App erbjuder integration med ett klick; se dokumentationen.
När ett officiellt konto har byggt upp en publik kan det aktivera annonsplatser i artiklar.
Ett miniprogram kan aktivera publicistintäkter efter att ha nått 1 000 unika besökare.
8. Avslutande tankar
Nu har vi färdigställt det ekosystem med ett officiellt WeChat-konto, ett miniprogram och en app som beskrevs i början.
Med de här stegen genomförde jag processen för tre produkter. Skanna koderna för att prova dem:
