Guia per preparar el teu projecte · Aplicacions
PALSEC AGCY ·
Què ha d’incloure un pressupost de desenvolupament d’una app
Un pressupost d’app ha de permetre entendre què es construirà, què haurà d’aportar el teu equip i com es comprovarà l’entrega. Si només enumera pantalles i una data, queden decisions importants sense resoldre. Revisa’l seguint un recorregut complet del producte, des de l’accés de l’usuari fins a la gestió de les dades i el suport posterior.
Abast funcional amb exemples d’ús
Demana que les funcions descriguin què pot fer cada tipus d’usuari. Un apartat anomenat reserves pot incloure consultar disponibilitat, crear una petició, confirmar-la, modificar-la o cancel·lar-la. Cada acció té regles i situacions particulars. La proposta ha d’indicar quines cobreix i qui intervé quan la petició necessita revisió manual.
Anota les exclusions amb la mateixa claredat. Si la primera versió té un sol idioma o no permet editar un registre després d’enviar-lo, aquesta decisió ha de ser visible. Identifica què es dona per suposat i què continua pendent de definició. Les propostes es poden comparar quan descriuen un producte equivalent i deixen a la vista les diferències.
Disseny de pantalles i de situacions
El disseny inclou el recorregut, la jerarquia i els estats de la interfície. Cal preveure una llista buida, una càrrega lenta, un error de formulari i una acció que encara no s’ha confirmat. Demana en quins dispositius es revisarà el disseny i com es tractaran textos llargs, controls accessibles i missatges que l’usuari ha d’entendre per continuar.
Comprova si la proposta inclou recerca, prototip, proves de comprensió, identitat visual o només l’aplicació d’una marca existent. També ha de quedar clar qui redacta els textos i qui prepara imatges i traduccions. Un prototip pot servir per validar el recorregut, però cal especificar quines parts es convertiran en una aplicació funcional i amb quins comportaments.
Dades, panell de gestió i sistemes externs
Pregunta on es gestionaran els registres i qui els podrà consultar o corregir. Si el teu equip necessita aprovar contingut, atendre incidències o administrar usuaris, aquestes tasques han de tenir una solució prevista. Un panell de gestió té els seus recorreguts i permisos; no s’ha de donar per inclòs només perquè la proposta parla d’una app.
Per a cada integració, identifica el sistema extern, la informació que s’intercanvia i la persona que facilitarà l’accés. Acorda què passarà si el servei no respon o envia dades incompletes. Si encara no s’ha comprovat la connexió, la proposta ha de reflectir aquest dubte i la feina necessària per aclarir-lo. Inclou també qualsevol migració de dades que el llançament requereixi.
Proves i acceptació de l’entrega
Defineix com sabreu que cada recorregut està complet. Per exemple, una reserva pot considerar-se validada quan l’usuari rep confirmació, el registre apareix al panell i un canvi es reflecteix als dos llocs. Aquests criteris permeten revisar el funcionament amb casos concrets. Afegeix les situacions d’error i les combinacions de dispositius que siguin rellevants.
La proposta ha d’assignar temps i responsables per preparar dades de prova, revisar resultats i corregir incidències. Distingeix un error respecte del comportament acordat d’una funció nova que apareix durant la revisió. Defineix com es documentarà la petició i com es decidirà si entra en aquesta entrega o en una fase posterior.
Publicació, accessos i continuïtat
Revisa qui crearà i gestionarà els comptes necessaris, prepararà els materials de publicació i atendrà les comprovacions del canal escollit. En una distribució mitjançant botigues, separa la preparació de l’enviament i la disponibilitat final. La proposta ha d’explicar les tasques de l’equip sense presentar com a controlable una decisió que correspon a tercers.
L’entrega també ha d’especificar repositori, arxius de disseny, documentació i procediment per continuar el treball. Acorda com es gestionaran incidències, actualitzacions, còpies de seguretat i dependències externes després del llançament. Identifica qui tindrà cada responsabilitat. Poder accedir als arxius és útil, però l’equip que els rep també ha de saber com posar el sistema en funcionament.
Preguntes per revisar dues propostes
Envia els mateixos dubtes a cada proveïdor i demana que les respostes s’incorporin a la proposta. Repassa especialment les parts que depenen del teu equip: continguts, accessos, validacions i disponibilitat per provar. Una data de lliurament ha de tenir aquestes dependències associades.
- Quins recorreguts i excepcions inclou la primera versió?
- Qui prepara continguts i qui administra el producte?
- Quines integracions estan comprovades i quines no?
- Amb quines proves s’acceptarà l’entrega?
- Quins comptes, arxius i documents rebré?
- Qui s’ocuparà de les incidències després de publicar?
Definim què hauria d’incloure la teva app
Comparteix la idea, els recorreguts previstos i els sistemes que ha de connectar. Podem parlar d’un abast concret i de les decisions que encara falten.