Itsenäisen tuotekehityssarjani toinen osa
Edellinen artikkeli kuvasi iOS-kehittäjän näkökulmasta resursseja tarpeen määrittelyyn, itsenäisen sovelluksen kehittämiseen ja julkaisuun. Rajallisilla resursseilla pystyin tekemään vain Applen App Storessa julkaistuja apusovelluksia.
Tämä artikkeli käsittelee täysipainoisen monialustaisen tuotteen kehittämistä, kohtaamiamme ongelmia ja niiden ratkaisuja. Kerron, miten rakensin vähitellen WeChatin virallisen tilin, minisovelluksen ja sovelluksen muodostaman täydellisen tuote-ekosysteemin.
1. Tuotetavoitteet
Laajasti ajatellen tuotetavoite on tuotteen tuottama arvo. Vaikka käyttötapaus on olemassa, arvottomalla tuotteella — joka ei tuota rahaa ja jolla on hyvin vähän käyttäjiä — ei juuri ole syytä olla olemassa.
Voisimme aloittaa vielä laajemmin tuotevisiosta…
Pysähdy siihen. Älä ajattele vielä kaikkea tätä, tai tuotteesi ei ehkä koskaan pääse loputtomia kuvitelmiasi pidemmälle.
Kun resurssit, ihmiset ja investoinnit ovat rajallisia, tavoite selkiytyy: mitä ongelmia tuotteen pitää ratkaista tai mitä toimintoja sen on tarjottava?
Kun esimerkiksi rakensin File Managerin, MVP:llä oli selkeä tavoite: siirtää tiedostoja puhelimen ja tietokoneen välillä.
MVP:n valmistuminen toi luontevasti uusia vaatimuksia. Osa tuli tuotesuunnitelmistani, mutta useammat käyttäjäpalautteesta:
- 1.0.0 Tiedostojen siirto puhelimen ja tietokoneen välillä
- 1.1.0 Kuva-, video- ja äänitiedostojen esikatselu tai toisto
- 1.2.0 Tiedostojen ryhmittely, siirto, poistaminen, pakkaaminen ja jakaminen
- 1.3.0 Soittimen parantaminen
- 1.4.0 Turvallisuustarkistus: elekoodeja ja biometria
- 2.0.0 Sovelluksen sisäiset ostot
- 2.1.0 Asiakirjojen skannaus
- …
Valitse tavoite. Sen ei tarvitse olla suuri, mutta sen on oltava toteutettavissa. Keskity yhteen asiaan kerrallaan ja jatka, vaikka se vaikuttaisi väärältä — mistä voit tietää ennen kuin saat sen valmiiksi ◔ ‸◔? Viimeistele ja arvioi sitten.
2. Tuoteprototyypit
Edellisessä artikkelissa kerroin kokeilleeni monia prototyyppityökaluja ja päätelleeni, että olisin rakentanut näkymät xibillä siinä ajassa, joka kului prototyypin suunnitteluun.
Perunpa puheeni tässä ,,Ծ‸Ծ,,
Näin on ymmärrettävää ajatella, kun tekee henkilökohtaista apusovellusta ilman jatkosuunnitelmaa ja tavoitteena on vain saada se valmiiksi ja julkaistua.
Tuotteen kehittyessä eteneminen askel kerrallaan ilman prototyyppiä tai suunnitelmaa aiheuttaa vakavia ongelmia tulevalle kehitykselle. Prototyypin suunnittelu on oikeastaan tuotteen logiikan järjestämistä.
Tässä joitakin prototyyppityökaluja. Käytän tällä hetkellä eniten MockingBotia.
3. Projektinhallinta
Kehitettyäni ja julkaistuani iOS-sovelluksen itsenäisesti huomasin vakavan ongelman: minulla ei ollut käsitystä projektinhallinnasta. Työskentelin, kun ehdin tai muistin, enkä tehnyt mitään laiskottaessani.
Se oli oma tuotteeni, jonka suunnittelin ja kehitin itse. MVP:llä ei luultavasti ollut maksavia käyttäjiä, joten en tuntenut vastuuta heille.
Tämä hidastaa projektia vakavasti. Pitkään ilman suunnitelmaa työskentely voi jopa tappaa sen.
Hallittuani työssäni iteraatioita useita vuosia huomasin projektinhallintatyökalujen toimivan myös omissa projekteissa. Kun tuotetavoite ja loogisesti yhtenäinen prototyyppi ovat selvät, työ on luontevaa jakaa tehtäviin.
Käytän projektinhallintaan coding.netiä; siellä voi myös säilyttää lähdekoodia.
Jaa tehtävät tunneissa mitattaviin osiin. Se helpottaa hallintaa ja testitapausten kirjoittamista. Nykyinen tapani on kirjoittaa testitapaukset valmiiksi ennen koodausta. Tämä on olennaista.
Prototyyppi järjestää tuotteen logiikan, testitapaukset toteutuksen yksityiskohdat. Täydelliset testitapaukset ohjaavat oikeaan liiketoimintalogiikkaan ✅ ja estävät monia liiketoimintavirheitä ❌.
4. Teknologian valinta
Tähän asti kaikki on ollut valmistelua; kehitys ei ole alkanut. Keskeinen vaikeus on, että olen ainoa kehittäjä, mutta haluan rakentaa WeChatin virallisen tilin, minisovelluksen ja sovelluksen täydellisen ekosysteemin.
Tarvitsisimme minisovellus-, iOS- ja Android-osaamista. Ohjelmointikielen oppiminen ei ole kovin vaikeaa, mutta saman liiketoimintalogiikan toteuttaminen kolmesti maksaa kolminkertaisen työn. Se on selvästi epärealistista.
Tavallisesti voisimme palvella useita alustoja webillä tai jopa hylätä sovelluksen ja keskittyä viralliseen tiliin sekä minisovellukseen. Alkuvaiheessa, kun tuotetarpeet on validoitava nopeasti, tämä on erittäin varteenotettava ratkaisu.
Pieni haku paljastaa monia monialustatekniikoita. Sovelluksen ja minisovelluksen voi rakentaa yhdellä koodipohjalla kolmelle alustalle Uni-Appilla. Se käyttää Vue.js-käyttöliittymäkehystä, ja iOS- ja Android-tuki toteutetaan Weexillä.
Se riittää henkilökohtaisiin tai pieniin kaupallisiin tuotteisiin.
5. Tiedonhallinta
Kun minisovelluksen ja sovelluksen ratkaisu on valittu, jäljellä on tärkeä kysymys: missä tiedot säilytetään?
Apusovellukselle paikallinen tallennus riittää. Entä jos tavoitteena on tietopalvelu täydellä käyttäjäjärjestelmällä tai jopa monimutkaisempi käyttäjien tuottaman sisällön yhteisö?
Uni-App tarjoaa oman uniCloud-palvelunsa. Palvelinkehitys onnistuu JavaScriptillä, ja minisovellukset sekä sovellukset voivat käyttää palvelinta ilman verkkotunnusta.
Valitsin toisen tavan: tallensin tiedot palvelimettomalle LeanCloud-alustalle. Minisovellus ja sovellus käyttävät ylläpidettyä tietokantaa LeanCloudin JavaScript SDK:n kautta.
Kehitystaso tarjoaa 30 000 ilmaista API-pyyntöä päivässä sekä SMS-palveluja. Se riittää käyttäjäjärjestelmän rakentamiseen, käyttäjätietojen lataamiseen ja alustatietojen hakemiseen.
Kun pyynnöt ylittävät kehitystason kiintiön, tuotteella on jo jonkin verran käyttäjiä. Uskon liikenteen tulojen silloin kattavan kaupallisen käytön mukaan laskutettavan tason.
Röyhkeä tapa hankkia dataa
Entä jos haluat tehdä sää- tai tietosovelluksen, mutta sinulla ei ole sää- tai uutisdataa?
Kiinassa on monia API-markkinapaikkoja, esimerkiksi:
ja muita.
Markkinapaikat tarjoavat maksullisia ja ilmaisia API-rajapintoja.
Jos tuotteesi ansaitsee hyvin liikenteellä, harkitse maksullisia API-rajapintoja.
Muussa tapauksessa hyödynnä ilmaiskiintiöitä. Sadankin pyynnön kokeilu voi kuitenkin kulua testauksessa. Mitä sitten?
Voit yhdistää LeanCloudin palvelimettoman tietokannan API-markkinapaikkaan. Päivittäisen sään kohdalla kysy ensin tietokannasta. Jos data puuttuu, hae se markkinapaikalta ja tallenna tietokantaan.
Entä jos 100 pyyntöä ei vieläkään kata kaikkia kaupunkeja? Säilytä ilmaishenki ja hae useille alustoille.
6. Julkaisu ja ylläpito
Nyt minisovellus, sovellus ja palvelin on kehitetty. Miten ne julkaistaan?
Minisovellukset ovat melko suoraviivaisia: hae minisovellusta seuraamalla WeChat Official Accounts Platformin ohjeita.
iOS-julkaisu vaatii maksullisen kehittäjätilin. Se on kynnys, mutta pitkäaikaiseen ylläpitoon suosittelen hakemista Applen kehittäjäsivustolla. Hakeminen on nykyään helppoa: lataa Developer-sovellus iPhoneen ja maksa siinä.
Android-jakelu vaatii ohjelmiston tekijänoikeusrekisteröinnin. Tavallinen hakemus voi kestää 1–2 kuukautta, tai voit maksaa kolmannen osapuolen välittäjälle sen hoitamisesta.
Jatketaan ilmaishenkeä: mihin sovelluksen ja minisovelluksen mainospaikkojen kuvat, äänet ja videot tallennetaan?
Virallisen tilin mediakirjasto ratkaisee ongelman. Tallenna kuvat, äänet ja videot sinne, hae niiden alkuperäiset URL-osoitteet, ja sovellus sekä minisovellus voivat käyttää niitä.
7. Tulojen hankkiminen
Yksinkertainen tapa ansaita liikenteellä on mainonta.
Alustojen julkaisijoille asettamat kelpoisuusvaatimukset kuitenkin kasvavat, joten itsenäisen kehittäjän on vaikea ottaa mainontaa käyttöön.
Uni-App tarjoaa yhden napsautuksen integroinnin; katso sen ohjeet.
Kun virallinen tili on kerännyt yleisöä, se voi ottaa käyttöön mainospaikkoja artikkeleissa.
Minisovellus voi ottaa julkaisijan ansainnan käyttöön saavutettuaan 1 000 yksittäistä kävijää.
8. Lopuksi
Olemme nyt rakentaneet alussa kuvatun WeChatin virallisen tilin, minisovelluksen ja sovelluksen ekosysteemin.
Näitä vaiheita noudattamalla toteutin prosessin kolmelle tuotteelle. Kokeile niitä skannaamalla koodit:
