Com comparar els pressupostos de pàgina web: abast, partides i extres

Dues propostes per a una web poden mostrar xifres diferents encara que ambdues parlin de "disseny i desenvolupament". Per comparar-les de manera útil cal revisar quin abast, partides, exclusions i responsabilitats representa cadascuna: qui prepara els textos, quantes pàgines hi ha realment, què passa quan algú envia un formulari, quines eines han de connectar-se o qui s'ocuparà de la web després de publicar-la.

Aquesta guia se centra a comparar pressupostos amb el mateix criteri, no en oferir una xifra orientativa. Si abans necessites identificar els factors que formen el cost, consulta quant costa fer una pàgina web. En acabar de llegir podràs separar les partides d'un projecte, detectar diferències d'abast i preparar una sol·licitud comparable.

El preu representa un abast, no una etiqueta

Una pàgina web pot ser una presentació senzilla d'una empresa, una estructura de serveis amb recorreguts de contacte, una botiga online o un sistema amb àrees privades, dades i integracions. Trucar "web" a tots aquests casos no els converteix en el mateix projecte.

Per interpretar una proposta cal separar tres capes:

Per exemple, "Necessite una web per a rebre sol·licituds" expressa un objectiu inicial. Encara faltaria concretar quins serveis es presenten, quina informació necessita la persona interessada, quins camps tindrà el formulari, qui rep les dades i què ha de passar sí la tramesa falla. Cada resposta converteix una idea general en abast comprovable.

Com es construeix un pressupost web

Un pressupost útil tradueix necessitats de negoci en tasques i lliurables. No s'hauria de limitar a un llistat genèric de conceptes, perquè això dificulta saber què reps i què queda fora.

El procés sovint comença a definir l'acció principal que ha de facilitar la web: demanar informació, reservar, comprar, consultar un catàleg, accedir a una àrea privada o realitzar una altra gestió. A partir d'aquí es delimita el recorregut necessari per completar aquesta acció.

Després es revisen les condicions que canvien el treball: continguts disponibles, pàgines amb estructures diferents, idiomes, integracions, migració des d'una web anterior, responsables de revisió i necessitats de manteniment. Amb aquesta informació es pot distingir entre l'imprescindible per a la primera versió i el que pot quedar per a una evolució posterior.

Aquesta separació evita un error habitual: incloure totes les idees en el primer lliurament encara que no tinguin la mateixa prioritat. Una funció futura pot ser valuosa, però no té per què formar part de l'abast inicial.

Components que poden formar part del preu d'una pàgina web

No tots els projectes necessiten les mateixes partides. El rellevant és identificar quines apliquen al teu cas i com s'han definit.

Definició i arquitectura

Inclou aclarir l'objectiu, els usuaris, les seccions i la relació entre pàgines. L'arquitectura d'informació organitza el contingut perquè una persona trobi el que busca i entengui quin és el següent pas.

Aquí també convé decidir quines pàgines comparteixen estructura i quines requereixen un disseny o comportament propi. No és igual repetir una mateixa plantilla de contingut que crear recorreguts amb necessitats diferents.

Disseny i adaptació a dispositius

El disseny afecta com es presenta la informació, com es prioritzen les accions i com es comporta el web en pantalles diferents. L'adaptació a mòbil no s'hauria d'interpretar com una caixa genèrica: cal comprovar que textos, formularis, menús i accions continuen sent utilitzables en el context previst.

La personalització visual també s'ha de concretar. Podeu partir d'una estructura estàndard o requerir components i recorreguts específics. Les dues opcions poden encaixar segons l'objectiu; la decisió depèn de les necessitats reals i de les restriccions que acceptis.

Continguts

Els textos, imatges, documents, fitxes de serveis i traduccions influeixen en l'abast. Una proposta ha de deixar clar si el contingut ja existeix, qui el revisa, qui el carrega i si cal reorganitzar- el o traslladar- el des d'un altre lloc.

La migració mereix una atenció especial. No consisteix només a copiar pàgines: podeu implicar inventariar continguts, revisar URL, traslladar dades, conservar formularis o replantejar una estructura anterior.

Funcions i interaccions

Un formulari, un cercador, una àrea d'accés, una reserva o un catàleg no són blocs equivalents. Per estimar-los cal descriure què fa l'usuari, quines dades introdueix, quines validacions existeixen i quin resultat rep.

En el cas d'un formulari, per exemple, no n'hi ha prou amb indicar que «hi haurà contacte». Cal concretar camps, destinatari, missatge de confirmació, tractament d'errors i accés a les sol·licituds. Així es pot verificar que el flux funciona com s'esperava.

Integracions i dades

Una integració connecta el web amb una altra eina, com ara un sistema de gestió, un servei de correu, una passarel·la de pagament o una plataforma de reserves. El seu cost no depèn només d'activar una connexió: importa quines dades viatgen, a quina adreça, amb quines regles i què succeeix si el servei extern no respon.

Quan hi ha dades de clients, comandes o usuaris, també s'han de definir els permisos. És a dir, qui pot veure, modificar o administrar cada informació. Aquesta part sol diferenciar una web informativa d'un sistema amb lògica de negoci.

Proves, llançament i continuïtat

Abans de publicar, cal comprovar accions concretes: navegar des de diversos dispositius, enviar formularis, accedir a zones privades, revisar enllaços i validar els fluxos acordats. Els criteris d'acceptació ajuden a evitar un lliurament basat només en les característiques generals com ara "apareix acabada".

El llançament tampoc no esgota el cost d'una web. Domini, allotjament, llicències, serveis externs, manteniment tècnic, actualitzacions de contingut i evolucions funcionals són conceptes que poden existir després. S'han de separar de la construcció inicial per no confondre pagaments puntuals i recurrents.

El flux que converteix els requisits en treball

Una manera clara d'entendre el pressupost és seguir el recorregut d'una acció i de les seves dades.

Imagineu un cas hipotètic: una persona entra en una pàgina de servei, consulta una explicació, omple un formulari i espera resposta. Perquè aquest recorregut existeixi, cal definir i construir diversos elements:

1. La pàgina ha d'explicar el servei i permetre arribar al formulari.
2. El formulari ha de recollir els camps acordats i comprovar que la informació necessària està completa.
3. El web ha de mostrar una confirmació o un avís si alguna cosa no ha funcionat.
4. La sol·licitud ha d'arribar al destí definit, com un compte de correu o una eina externa.
5. L'empresa ha de poder accedir a la informació i gestionar la següent acció.

Cada pas introdueix decisions de contingut, disseny, desenvolupament, dades, proves i operació. Si un pressupost només esmenta "formulari de contacte", no permet saber quina part d'aquest flux està inclosa.

El mateix raonament serveix per a una botiga, un sistema de reserves o una àrea privada. totes les regles, estats, usuaris, excepcions i integracions intervenen, més important és descriure el comportament abans de comparar propostes.

Límits que convé detectar abans d'acceptar una xifra

Un import sense abast detallat pot ser difícil de comparar, però una llista extensa tampoc n'hi ha prou amb els termes ambigus.

• Pàgines sense estructura definida. Saber quantes n'hi ha no aclareix si comparteixen plantilla, si inclouen continguts o si requereixen diferents funcionalitats.
• Continguts assumits. Si ningú és responsable d'aportar, redactar, aprovar o carregar la informació, el projecte pot quedar bloquejat o requerit treball addicional.
• Integracions nomenades sense flux. Indicar una eina externa no explica què es connecta, quines dades es transfereixen ni com es gestionen incidències.
• SEO, analítica o rendiment descrits genèricament. Demana tasques concretes i criteris de comprovació, no només etiquetes.
• Manteniment sense límits. Aclari si cobreix actualitzacions tècniques, suport, continguts, correccions o noves funcions.
• Canvis posteriors no previstos. Una revisió de textos no equival necessàriament a incorporar pàgines, regles o integracions noves.

També convé confirmar quins elements s'exclouen: identitat visual, fotografia, traduccions, llicències, hosting, domini, migració, càrrega de catàleg, serveis de tercers o manteniment, que alguna cosa estigui exclosa no vol dir que no sigui necessària; vol dir que requereix una decisió a part.

Quan té sentit demanar una estimació detallada

Una estimació més detallada és especialment útil quan la web ha de fer quelcom més que presentar informació, quan substitueixes un lloc existent o quan hi ha diverses persones prenent decisions.

Prepara-la amb una descripció breu però concreta:

• què ha d'aconseguir la web;
• a qui es dirigeix;
• quina acció principal ha de completar aquesta persona;
• quins continguts ja tens i quins falten;
• quines funcions o connexions amb altres eines necessites;
• què ha de quedar fora de la primera versió;
• qui revisarà i aprovarà el treball;
• quins costos posteriors vols tenir identificats.

No necessites conèixer la solució tècnica per respondre a aquestes preguntes. De fet, definir primer l'objectiu i l'abast ajuda a valorar si una solució estàndard és suficient o si el projecte requereix una implementació més personalitzada.

Una decisió més útil per cercar una xifra aïllada

El preu d'una pàgina web només es pot interpretar juntament amb el que inclou, el que exclou i les condicions que segueixen obertes. Una proposta clara et permet avaluar si resol la teva necessitat, quines dependències assumeixes i quina feina seguirà existint després del llançament.

Si necessites convertir una idea encara imprecisa en un abast entenedor, pots explicar el teu projecte de desenvolupament web a AVSISTEC per revisar objectiu, continguts, funcions i punts que convé definir abans de demanar pressupost.