Drugi del moje serije o razvoju neodvisnih izdelkov
Prejšnji članek je z vidika razvijalca iOS opisal vire za opredelitev potrebe, razvoj neodvisne aplikacije in njeno izdajo. Zaradi omejenih virov sem lahko dokončal le pripomočke, ki so bili na voljo v Applovi trgovini App Store.
Ta članek obravnava razvoj celovitega izdelka za več platform, težave, na katere naletimo, in njihove rešitve. Opisal bom, kako sem postopoma zgradil celoten ekosistem izdelka z uradnim računom WeChat, mini programom in aplikacijo.
1. Cilji izdelka
V širšem smislu je cilj izdelka vrednost, ki jo prinaša. Tudi če obstaja primer uporabe, izdelek brez vrednosti, ki ne more zaslužiti in ima zelo malo uporabnikov, nima pravega razloga za obstoj.
Lahko pa začnemo še širše, z vizijo izdelka…
Ustavite se. O vsem tem še ne razmišljajte, sicer vaš izdelek morda nikoli ne bo presegel neskončnega zamišljanja.
Ko so viri, ljudje in naložbe omejeni, postane cilj jasen: katere težave mora izdelek rešiti oziroma katere funkcije mora ponuditi?
Ko sem na primer ustvarjal Upravitelja datotek, je imel MVP jasen cilj: prenašati datoteke med telefonom in računalnikom.
Dokončanje MVP je naravno prineslo nove zahteve. Nekatere so izhajale iz mojih načrtov, še več pa iz povratnih informacij uporabnikov:
- 1.0.0 Prenos datotek med telefonom in računalnikom
- 1.1.0 Predogled ali predvajanje slikovnih, video in zvočnih datotek
- 1.2.0 Združevanje, premikanje, brisanje, stiskanje in deljenje datotek
- 1.3.0 Izboljšava predvajalnika
- 1.4.0 Dodajanje varnostnega preverjanja: gesla z vzorcem in biometrija
- 2.0.0 Dodajanje nakupov v aplikaciji
- 2.1.0 Dodajanje skeniranja dokumentov
- …
Izberite cilj. Ni treba, da je velik, mora pa biti izvedljiv. Osredotočite se na eno stvar naenkrat in vztrajajte, tudi če se zdi napačna — kako lahko veste, preden jo končate ◔ ‸◔? Končajte, nato presodite.
2. Prototipi izdelka
V prejšnjem članku sem omenil preizkušanje številnih orodij za prototipiranje in ugotovitev, da bi v času za oblikovanje prototipa zaslone že lahko izdelal z xib.
Naj tukaj nasprotujem samemu sebi ,,Ծ‸Ծ,,
Takšno razmišljanje je razumljivo pri osebnem pripomočku brez nadaljnjih načrtov, ko je edini cilj dokončanje in izdaja.
Ko se izdelek razvija, bo sprotno delo brez prototipa ali načrta povzročalo resne težave pri prihodnjem razvoju. Oblikovanje prototipa je pravzaprav proces urejanja logike izdelka.
Tukaj je nekaj orodij za prototipiranje. Trenutno največ uporabljam MockingBot.
3. Vodenje projekta
Po samostojnem razvoju in izdaji aplikacije iOS sem opazil resen problem: nisem imel nobene predstave o vodenju projekta. Delal sem, ko sem imel čas ali sem se spomnil, ob lenobi pa nisem naredil ničesar.
To je bil moj izdelek, ki sem ga sam zasnoval in razvil. MVP verjetno ni imel uporabnikov, ki bi plačevali, zato do njih nisem čutil odgovornosti.
To resno upočasni projekt. Predolgo delo brez načrta ga lahko celo uniči.
Po več letih vodenja iteracij v službi sem ugotovil, da orodja za vodenje projektov dobro delujejo tudi pri osebnih projektih. Ko imamo jasne cilje in logično skladen prototip, razčlenitev dela v naloge pride naravno.
Za vodenje projekta uporabljam coding.net; tam lahko gostuje tudi izvorna koda.
Naloge razdelite v enote, merjene v urah. Tako jih lažje upravljate in pišete preizkusne primere. Moja trenutna navada je dokončati preizkusne primere pred programiranjem. To je nujno.
Prototip ureja logiko izdelka; preizkusni primeri urejajo izvedbene podrobnosti. Celoviti preizkusni primeri nas vodijo do pravilne poslovne logike ✅ in preprečujejo številne poslovne napake ❌.
4. Izbira tehnologije
Doslej je šlo le za priprave; razvoja še nismo začeli. Glavna težava je, da sem edini razvijalec, a želim zgraditi celoten ekosistem uradnega računa WeChat, mini programa in aplikacije.
Potrebovali bi znanje mini programov, iOS in Androida. Naučiti se programskega jezika ni tako težko, toda trikratna izvedba iste poslovne logike pomeni trikrat več dela. To očitno ni realistično.
Običajno bi lahko za več platform uporabili splet ali celo opustili aplikacijo in se osredotočili na uradni račun ter mini program. V zgodnji fazi, ko potrebe izdelka zahtevajo hitro preverjanje, je to zelo smiseln pristop.
Že kratko iskanje razkrije številne večplatformne tehnologije. Za aplikacijo in mini program z eno kodno osnovo na treh platformah lahko uporabimo Uni-App. Uporablja ogrodje za uporabniški del Vue.js, podporo za iOS in Android pa zagotavlja Weex.
To zadostuje za osebne ali manjše komercialne izdelke.
5. Upravljanje podatkov
Ko je pristop za mini program in aplikacijo določen, ostane še ključno vprašanje: kje naj bodo podatki?
Za pripomoček zadostuje lokalno shranjevanje v aplikaciji. Kaj pa, če je cilj informacijska platforma s celovitim uporabniškim sistemom ali celo zahtevnejša skupnost z uporabniško ustvarjeno vsebino?
Uni-App ponuja lastno storitev uniCloud. Strežnik lahko razvijamo v JavaScriptu, mini programi in aplikacije pa ga lahko uporabljajo brez domenskega imena.
Izbral sem drug pristop: gostovanje podatkov na brezstrežniški platformi LeanCloud. Mini program in aplikacija dostopata do gostovane baze prek LeanCloudovega SDK za JavaScript.
Razvojni paket podpira 30.000 brezplačnih zahtev API dnevno in ponuja tudi storitve SMS. To zadostuje za uporabniški sistem, nalaganje uporabniških podatkov in pridobivanje podatkov platforme.
Ko zahteve presežejo razvojno kvoto, je izdelek že pridobil določeno število uporabnikov. Verjamem, da bi prihodki iz tega obiska tedaj morali pokriti komercialni paket s plačilom po porabi.
Prebrisan način pridobivanja podatkov
Kaj če želite ustvariti vremensko ali informacijsko aplikacijo, pa nimate vremenskih podatkov ali novic?
Na Kitajskem je veliko tržnic API, med drugim:
in druge.
Te tržnice ponujajo plačljive in brezplačne API-je.
Če ima vaš izdelek dober način monetizacije obiska, razmislite o plačljivih API-jih.
Če ga nima, razmislite o brezplačnih kvotah. Toda preizkusnih 100 zahtev lahko porabite že med preizkušanjem. Kaj potem?
Lahko združite brezstrežniško bazo LeanCloud in tržnico API. Za dnevno vreme na primer najprej preverite bazo. Če podatkov ni, jih zahtevajte na tržnici in nato shranite v bazo.
Kaj pa, če 100 zahtev še vedno ne pokrije vseh mest? Ohranite duh brezplačnih rešitev in zaprosite za dostop pri več platformah.
6. Izdaja in delovanje
Zdaj smo končali razvoj mini programa, aplikacije in strežnika. Kako jih izdamo?
Mini programi so razmeroma preprosti: na platformi uradnih računov WeChat sledite navodilom za prijavo mini programa.
Izdaja za iOS zahteva plačljiv razvijalski račun. To je ovira, toda za dolgoročno delovanje priporočam prijavo na Applovem razvijalskem spletnem mestu. Prijava je zdaj preprosta: v iPhone prenesite aplikacijo Developer in plačajte v njej.
Za distribucijo za Android potrebujete registracijo avtorskih pravic za programsko opremo. Običajna prijava lahko traja 1–2 meseca, lahko pa plačate zunanjemu posredniku, da jo uredi.
Nadaljujmo z brezplačnimi rešitvami: kje lahko shranimo slike, zvok in video za promocijska mesta v aplikaciji in mini programu?
Medijska knjižnica uradnega računa lahko reši težavo. Tja shranite slike, zvok in video, pridobite njihove izvirne URL-je in aplikacija ter mini program lahko dostopata do njih.
7. Pridobivanje prihodkov
En preprost način monetizacije obiska je oglaševanje.
Zahteve platform za vključitev založnikov pa se nenehno zvišujejo, zato neodvisni razvijalci težko vključijo oglase.
Uni-App ponuja vključitev z enim klikom; oglejte si dokumentacijo.
Ko uradni račun pridobi občinstvo, lahko omogoči oglasna mesta v člankih.
Mini program lahko omogoči monetizacijo za založnike, ko doseže 1.000 edinstvenih obiskovalcev.
8. Sklepne misli
Zdaj smo dokončali ekosistem uradnega računa WeChat, mini programa in aplikacije, opisan na začetku.
Po teh korakih sem ta postopek opravil za tri izdelke. Skenirajte kode in jih preizkusite:
