Segona part de la meva sèrie sobre el desenvolupament de productes independents
L’article anterior descrivia, des de la perspectiva d’un desenvolupador d’iOS, recursos per definir una necessitat, desenvolupar una aplicació independent i publicar-la. Amb recursos limitats, només podia completar aplicacions d’utilitat disponibles a l’App Store d’Apple.
Aquest article tracta el desenvolupament d’un producte complet per a diverses plataformes, els problemes que hi trobem i les seves solucions. Compartiré com vaig construir gradualment un ecosistema de producte complet format per un compte oficial de WeChat, un miniprograma i una aplicació.
1. Objectius del producte
En un sentit ampli, l’objectiu d’un producte és el valor que aporta. Fins i tot quan hi ha un cas d’ús, un producte sense valor, que no pot generar ingressos i té molt pocs usuaris, té pocs motius per existir.
O podríem començar encara més àmpliament, amb la visió del producte…
Atura’t aquí. Encara no pensis en tot això, o potser el teu producte no arribarà mai més enllà de la teva imaginació interminable.
Quan els recursos, les persones i la inversió són limitats, el nostre objectiu queda clar: quins problemes ha de resoldre el producte o quines funcions ha de proporcionar?
Per exemple, quan vaig crear File Manager, l’MVP tenia un objectiu clar: transferir fitxers entre un telèfon i un ordinador.
Completar l’MVP va donar lloc de manera natural a altres requisits. Alguns provenien dels meus plans de producte, però encara més provenien dels comentaris dels usuaris:
- 1.0.0 Transferir fitxers entre el telèfon i l’ordinador
- 1.1.0 Previsualitzar o reproduir fitxers d’imatge, vídeo i àudio
- 1.2.0 Agrupar, moure, eliminar, comprimir i compartir fitxers
- 1.3.0 Millorar el reproductor
- 1.4.0 Afegir verificació de seguretat: codis gestuals i biometria
- 2.0.0 Afegir compres integrades
- 2.1.0 Afegir escaneig de documents
- …
Tria un objectiu. No cal que sigui gran, però ha de ser viable. Centra’t en una cosa cada vegada i continua encara que sembli equivocada: com ho pots saber sense acabar-la ◔ ‸◔? Acaba-la i després revisa-la.
2. Prototips de producte
A l’article anterior vaig explicar que havia provat moltes eines de prototipatge i havia conclòs que podria haver construït les pantalles amb xib en el temps que vaig trigar a dissenyar el prototip.
Deixeu-me contradir-me aquí ,,Ծ‸Ծ,,
És comprensible pensar així quan es crea una aplicació d’utilitat personal, sense cap pla posterior i amb l’únic objectiu d’acabar-la i publicar-la.
A mesura que el producte evoluciona, avançar pas a pas sense prototip ni pla provocarà problemes greus per al desenvolupament futur. Dissenyar un prototip és, en realitat, un procés per ordenar la lògica del producte.
Aquí hi ha algunes eines de prototipatge. La que utilitzo més actualment és MockingBot.
3. Gestió de projectes
Després de desenvolupar i publicar una aplicació per a iOS de manera independent, vaig detectar un problema greu: no tenia cap noció de gestió de projectes. Treballava quan tenia temps o me’n recordava, i no feia res quan em sentia mandrós.
Era el meu propi producte, dissenyat i desenvolupat per mi. Probablement l’MVP no tenia usuaris de pagament, de manera que no em sentia responsable davant d’ells.
Això alenteix seriosament un projecte. Treballar massa temps sense cap pla fins i tot pot matar-lo.
Després de diversos anys gestionant iteracions a la feina, vaig descobrir que les eines de gestió de projectes també funcionen bé per als projectes personals. Quan tenim objectius de producte clars i un prototip lògicament coherent, dividir la feina en tasques és el pas natural.
Utilitzo coding.net per gestionar el projecte; també pot allotjar el codi font.
Divideix les tasques en unitats mesurades en hores. Això les fa més fàcils de gestionar i ajuda a redactar casos de prova. El meu hàbit actual és acabar els casos de prova abans de programar. Això és essencial.
Un prototip ordena la lògica del producte; els casos de prova ordenen els detalls de la implementació. Uns casos de prova complets ens guien cap a una lògica de negoci correcta ✅ i eviten molts errors de negoci ❌.
4. Triar la tecnologia
Fins ara, tot això ha estat preparació; encara no hem començat a desenvolupar. La dificultat principal és que soc l’únic desenvolupador, però vull construir l’ecosistema complet d’un compte oficial de WeChat, un miniprograma i una aplicació.
Necessitaríem coneixements de miniprogrames, iOS i Android. Aprendre un llenguatge de programació no és tan difícil, però implementar tres vegades la mateixa lògica de negoci costa tres vegades més esforç. Això no és gens realista.
Normalment podríem utilitzar el web per servir diverses plataformes, o fins i tot abandonar l’aplicació i centrar-nos en un compte oficial i un miniprograma. A la fase inicial, quan les necessitats del producte exigeixen una validació ràpida, és un enfocament molt raonable.
Una cerca ràpida revela moltes tecnologies multiplataforma. Per crear una aplicació i un miniprograma amb una sola base de codi per a tres plataformes, podem utilitzar Uni-App. Utilitza el marc d’interfície Vue.js, amb compatibilitat per a iOS i Android mitjançant Weex.
És suficient per a productes personals o petits productes comercials.
5. Gestió de dades
Un cop decidit l’enfocament del miniprograma i de l’aplicació, queda una altra pregunta crucial: on han de viure les dades?
Per a una utilitat, n’hi ha prou d’emmagatzemar les dades localment a l’aplicació. Però què passa si l’objectiu és una plataforma d’informació amb un sistema d’usuaris complet, o fins i tot una comunitat més complexa de contingut generat pels usuaris?
Uni-App ofereix el seu propi servei uniCloud. El desenvolupament del servidor es pot fer amb JavaScript, i els miniprogrames i les aplicacions poden utilitzar el servidor sense nom de domini.
Vaig triar un altre enfocament: allotjar les dades a la plataforma sense servidor LeanCloud. El miniprograma i l’aplicació accedeixen a la base de dades allotjada mitjançant l’SDK de JavaScript de LeanCloud.
El seu nivell de desenvolupament admet 30.000 sol·licituds API gratuïtes al dia i també ofereix serveis d'SMS. Això és suficient per construir un sistema d’usuaris, pujar dades d’usuari i recuperar dades de la plataforma.
Quan les sol·licituds superen la quota de desenvolupament, el producte ja ha aconseguit una certa escala d’usuaris. Crec que els ingressos d’aquest trànsit haurien de cobrir aleshores el nivell comercial de pagament per ús.
Una manera múrria d’obtenir dades
Què passa si vols crear una aplicació meteorològica o d’informació, però no tens dades meteorològiques ni notícies?
A la Xina hi ha molts mercats d’API, entre els quals:
i d’altres.
Aquests mercats ofereixen API tant de pagament com gratuïtes.
Si el teu producte té una bona manera de monetitzar el trànsit, considera les API de pagament.
Si no en té, considera aprofitar les quotes gratuïtes. Però una prova de 100 sol·licituds pot esgotar-se durant les proves. Què fem aleshores?
Pots combinar la base de dades sense servidor de LeanCloud amb un mercat d’API. Per a la meteorologia diària, per exemple, consulta primer la base de dades. Si no hi ha les dades, demana-les al mercat i després desa-les a la base de dades.
Però què passa si 100 sol·licituds encara no cobreixen totes les ciutats? Mantén viu l’esperit d’aprofitar el que és gratuït i sol·licita accés a diverses plataformes.
6. Llançament i operacions
En aquest punt, hem acabat de desenvolupar el miniprograma, l’aplicació i el servidor. Com ho publiquem?
Els miniprogrames són relativament senzills: a la Plataforma de Comptes Oficials de WeChat, segueix les instruccions per sol·licitar un miniprograma.
Publicar a iOS requereix un compte de desenvolupador de pagament. Això és una barrera, però per a una explotació a llarg termini recomano sol·licitar-lo al lloc web per a desenvolupadors d’Apple. Ara sol·licitar-lo és senzill: descarrega l’aplicació Developer en un iPhone i paga-hi.
Per distribuir a Android, cal el registre dels drets d’autor del programari. Una sol·licitud normal pot trigar d’1 a 2 mesos, o pots pagar un agent extern perquè se n’encarregui.
Continuant amb l’esperit d’aprofitar el que és gratuït: on podem emmagatzemar imatges, àudio i vídeo per als espais promocionals de l’aplicació i el miniprograma?
La biblioteca multimèdia del compte oficial pot resoldre aquest problema. Emmagatzema-hi les imatges, l’àudio i el vídeo, obtén-ne els URL originals i l’aplicació i el miniprograma hi podran accedir.
7. Obtenir ingressos
Una manera senzilla de monetitzar el trànsit és la publicitat.
Tanmateix, els requisits d’admissió de les plataformes per als editors són cada vegada més exigents, cosa que dificulta la integració d’anuncis per als desenvolupadors independents.
Uni-App ofereix integració amb un sol clic; consulta’n la documentació.
Quan un compte oficial ha creat una audiència, pot activar espais publicitaris dins dels articles.
Un miniprograma pot activar la monetització de l’editor després d’arribar a 1.000 visitants únics.
8. Reflexions finals
Ara ja hem completat l’ecosistema d’un compte oficial de WeChat, un miniprograma i una aplicació descrit al principi.
Seguint aquests passos, vaig completar aquest procés per a tres productes. Escaneja els codis per provar-los:
