App multiplataforma: com preparar el projecte pas a pas

El teu equip consulta informació des del mòbil, mentre que l'administració necessita treballar des d'un ordinador. O potser els teus clients esperen resoldre una gestió des del seu telèfon, però el procés intern depèn de diverses eines desconnectades. En aquest punt sorgeix un dubte raonable: necessites una app multiplataforma o una solució més senzilla?

Una app multiplataforma pot ser adequada quan un mateix servei ha de funcionar en diversos sistemes operatius o dispositius, mantenint una experiència i unes regles de negoci coherents. Però aquesta etiqueta no decideix el projecte per si sola. En acabar aquesta guia podràs definir què ha de resoldre l'aplicació, què cal incloure en una primera versió i quines preguntes has d'aclarir abans d'escollir la solució tècnica.

Resultat esperat

El resultat no hauria de ser «tenir una app», sinó disposar d'una proposta clara que respongui aquestes qüestions:

• Quin problema concret ha de resoldre per a la teva empresa, equip o clients.
• Qui la farà servir i des de quins dispositius.
• Quines accions ha de permetre en una primera versió.
• Quines dades, eines i persones hi intervenen.
• Com comprovaràs que funciona abans d'ampliar-la.

Amb aquesta base podràs valorar si convé una app multiplataforma, una aplicació web accessible des del navegador o una solució diferent. La tecnologia ve després: primer cal definir la feina que ha de fer.

Pas 1: defineix l'objectiu

Objectiu: expressar el canvi que esperes aconseguir amb una acció observable.

Acció: descriu una situació actual i l'acció que hauria de ser més clara, ràpida o controlable. Evita objectius amplis com «modernitzar el negoci» o «millorar la gestió» si no els pots traduir en un ús concret.

Per exemple, en un escenari hipotètic, una empresa de manteniment podria necessitar que el personal tècnic consulti una ordre, registri la feina feta i adjunti informació des del mòbil. L'objectiu no seria crear una aplicació mòbil per si mateixa, sinó permetre que aquestes tasques es registrin en el moment i quedin disponibles per a qui les revisa.

També convé separar els grups d'usuaris. Un client, una persona d'administració i un tècnic poden necessitar recorreguts, permisos i informació diferents, encara que entrin al mateix sistema.

Comprovació: completa aquesta frase sense fer servir termes tècnics: «L'aplicació permetrà que [tipus d'usuari] faci [acció] perquè [resultat operatiu]». Si la frase continua sent ambigua, encara falta concretar l'objectiu.

Pas 2: delimita l'abast de la primera versió

Objectiu: decidir què ha d'estar enllestit al principi i què pot esperar.

Acció: reuneix les funcions que imagines i classifica-les segons la prioritat:

• Imprescindibles: sense aquestes no es compleix l'objectiu inicial.
• Desitjables: aporten valor, però la seva absència no bloqueja l'ús principal.
• Futures: es conserven com a possibles millores, sense considerar-les incloses.
• Fora d'abast: no formen part d'aquest projecte.

No n'hi ha prou d'anomenar una funció. Defineix què fa i en quines condicions. «Gestió de comandes», per exemple, pot significar consultar comandes, crear-ne una de nova, canviar-ne els estats, cancel·lar-les, assignar responsables o enviar avisos. Cada possibilitat implica regles i pantalles diferents.

Inclou en aquesta revisió elements que sovint es deixen per al final: accés d'usuaris, rols i permisos, notificacions, treball sense connexió si calgués, tauler d'administració, idiomes, càrrega inicial de dades, formació i manteniment posterior.

Comprovació: cada funció imprescindible ha de tenir un usuari, una acció i un resultat esperat. Si no pots explicar què passa quan no està disponible, probablement encara no saps si ha de formar part de la primera versió.

Pas 3: identifica dades, responsables i dependències

Objectiu: evitar que l'aplicació es dissenyi sense saber d'on obté la informació ni qui pren decisions.

Acció: dibuixa el recorregut bàsic de les dades. Indica què es consulta, qui pot crear o modificar informació i quines altres eines hi intervenen. Si l'aplicació necessita connectar-se amb un programa de facturació, un sistema d'inventari o una base de dades existent, aclareix quina informació s'intercanvia i què hauria de passar si aquesta connexió falla.

Assigna també responsables per a aquestes tasques:

• Decidir prioritats i aprovar canvis.
• Aportar i revisar continguts, textos o documents.
• Facilitar els accessos necessaris a serveis externs.
• Revisar les proves abans de posar la solució en ús.
• Mantenir dades, usuaris i continguts després del lliurament.

Una app multiplataforma no elimina aquestes decisions. Compartir part de la lògica entre plataformes pot simplificar el desenvolupament de determinats projectes, però les regles de negoci, les dades i els usos reals s'han de definir igualment.

Comprovació: pots respondre, per a cada dada rellevant, qui la introdueix, qui la consulta, qui la pot modificar i quina n'és la font. Si una resposta depèn d'una eina externa, deixa visible aquesta dependència abans de tancar l'abast.

Pas 4: escull la solució després d'entendre l'ús

Objectiu: seleccionar una opció tècnica compatible amb el problema, no escollir una etiqueta abans d'hora.

Acció: compara les alternatives a partir de l'ús previst. Una app multiplataforma sol tenir sentit quan necessites oferir el mateix servei en diferents dispositius i l'accés des del mòbil és rellevant per a la tasca. Tanmateix, no tots els processos requereixen instal·lació des d'una botiga d'aplicacions ni capacitats específiques del dispositiu.

Planteja aquestes preguntes abans de decidir:

• Les persones usuàries treballaran principalment des del mòbil, l'ordinador o tots dos?
• Necessiten utilitzar la càmera, la ubicació, les notificacions o altres funcions del dispositiu?
• Es requereix accés quan la connexió és inestable o inexistent?
• El servei ha de ser públic per a clients, intern per a l'equip o totes dues coses?
• Quines diferències reals hi haurà entre l'experiència en cada dispositiu?
• Qui mantindrà l'aplicació i els comptes associats després?

Una aplicació web pot encaixar si la feina es fa sobretot des del navegador i no necessita determinades capacitats del telèfon. Una aplicació específica per a mòbil pot justificar-se quan l'experiència, el context d'ús o les funcions del dispositiu ho exigeixen. La decisió necessita validació tècnica un cop es coneixen els requisits, les integracions i les restriccions del projecte.

Comprovació: has de poder explicar per què cada plataforma és necessària per a l'usuari final. «Perquè volem ser a tot arreu» no és un criteri suficient; «perquè l'equip fa aquesta tasca des del mòbil i administració la revisa des de l'ordinador» sí que aporta una base per analitzar-ho.

Pas 5: valida el flux abans d'ampliar funcions

Objectiu: comprovar que les tasques importants s'entenen i es resolen tal com esperes.

Acció: converteix cada funció prioritària en una prova concreta. Descriu la situació inicial, què fa la persona i el resultat que ha de veure. Afegeix què ha de passar davant d'errors previsibles, com ara dades incompletes, manca de permisos o una connexió no disponible.

Seguint l'exemple hipotètic de l'equip tècnic, un criteri podria ser: una persona autoritzada obre una ordre assignada, registra la tasca feta i desa el part; després, la persona responsable pot consultar aquest part des de la seva àrea de gestió. Si falta un camp obligatori, l'aplicació ho ha d'indicar abans de completar el registre.

La validació no consisteix només a comprovar que una pantalla es carrega. Revisa els recorreguts reals de cada perfil, els permisos, les dades mostrades i els casos en què alguna cosa no surt com estava previst. Les persones que faran la feina diàriament han de participar en aquesta revisió, perquè són les que poden detectar friccions que no apareixen en una descripció general.

Comprovació: cada funció imprescindible disposa d'un criteri d'acceptació que algú pot revisar sense interpretacions: qui fa quina acció, en quin context i quin resultat ha d'obtenir.

Errors d'execució que convé evitar

El problema habitual no sol ser escollir una tecnologia equivocada per desconèixer-ne un nom, sinó tancar decisions importants massa aviat. Para atenció a aquests riscos:

• Confondre el canal amb l'objectiu. Demanar una app mòbil no explica quina tasca s'ha de resoldre ni per a qui.
• Convertir cada idea en una funció inicial. Una primera versió sobrecarregada dificulta prioritzar i validar l'ús principal.
• Definir integracions només pel seu nom. Indica quines dades circulen, en quina direcció i què passa davant d'un error.
• Oblidar els permisos. Si diferents perfils veuen o modifiquen informació diferent, aquesta regla s'ha de definir des del principi.
• No assignar responsables. Els continguts, les aprovacions i els accessos a eines externes requereixen una persona responsable.
• Donar per fet que el mòbil i l'ordinador funcionen igual. L'objectiu pot ser comú, però el context d'ús i la interfície poden requerir decisions específiques.
• Deixar la validació per al final. Els criteris d'acceptació ajuden a detectar malentesos abans que una funció es consideri acabada.

Una app multiplataforma té sentit quan respon a una necessitat clara en més d'un dispositiu i el seu abast es pot mantenir sota control. Si ja has identificat l'objectiu, els usuaris i les dependències però encara tens dubtes sobre la solució més adequada, pots explicar el teu projecte d'aplicació a AVSISTEC per valorar l'encaix tècnic i funcional abans de comprometre'n el desenvolupament.