Pressupost web: errors freqüents en demanar-lo i revisar-lo

Reps dues propostes per a una web i els imports són molt diferents. Una sembla incloure-ho tot; l'altra detalla moltes tasques que no havies considerat. Abans de triar la més baixa o la més extensa, convé resoldre un dubte més important: estàs comparant el mateix projecte?

Un pressupost web serveix per convertir una necessitat de negoci en un abast entenedor: quin objectiu persegueix la web, què es lliurarà, què depèn de tu i què en queda exclòs. En acabar aquesta guia podràs detectar les mancances que dificulten comparar propostes i preparar una sol·licitud més clara.

Què es vol aconseguir amb un pressupost web

L'objectiu no és fixar una xifra sense context. És acordar quin problema ha d'ajudar a resoldre la web i quina feina forma part del primer lliurament.

Per evitar confusions, separa tres nivells:

• Objectiu: què hauria de poder fer l'empresa o la persona que visita la web. Per exemple, explicar millor un servei i facilitar que se sol·liciti informació.
• Abast: pàgines, continguts, formularis, idiomes, migració, integracions, proves, formació o altres elements necessaris per assolir aquest objectiu.
• Solució: la manera de construir-ho, com ara una estructura basada en components existents o un desenvolupament amb funcionalitats específiques.

Dos pressupostos poden fer servir tecnologies diferents i respondre al mateix objectiu. També poden semblar similars i amagar abasts molt diferents. Per això, la comparació comença per l'abast, no pel total.

Errors freqüents en demanar o revisar un pressupost web

1. Demanar «una web completa» sense descriure què ha d'aconseguir

Símptoma: la teva sol·licitud utilitza expressions com ara «web moderna», «professional» o «completa», però no indica quina acció ha de fer el visitant ni quina necessitat de negoci ha de cobrir.

Causa: es parteix d'una idea visual o d'una etiqueta tècnica abans de definir el problema. Una web per presentar serveis, rebre sol·licituds, gestionar reserves o vendre productes no requereix necessàriament el mateix plantejament.

Conseqüència: cada proveïdor interpreta l'encàrrec a la seva manera. Les propostes resultants poden incloure feines diferents encara que facin servir paraules semblants, i comparar imports deixa de ser útil.

Correcció: escriu una frase concreta sobre el resultat esperat. Després, identifica qui visitarà la web i quina és l'acció principal que hauria de poder completar. Si hi ha diversos objectius, ordena'ls per prioritat.

2. Confondre una llista de pàgines amb l'abast real

Símptoma: el pressupost esmenta Inici, Serveis, Sobre nosaltres i Contacte, però no explica quin contingut hi haurà a cada pàgina ni quines parts tindran un comportament propi.

Causa: se suposa que una pàgina és una unitat de treball idèntica a una altra. Tanmateix, una pàgina informativa, un catàleg, una pàgina amb filtres o una àrea privada impliquen necessitats diferents.

Conseqüència: durant el projecte apareixen dubtes sobre textos, recursos visuals, blocs reutilitzables, formularis o gestió posterior. Si no s'aclareixen, aquestes decisions poden modificar la feina prevista.

Correcció: per a cada pàgina o tipus de pàgina, concreta'n el propòsit, el contingut disponible, els elements necessaris i la persona responsable d'aprovar-la. No cal dissenyar cada detall abans de demanar pressupost, però sí distingir el que és senzill del que requereix regles, dades o interacció.

3. Donar per fet que els continguts estan inclosos

Símptoma: es parla de «renovar la web», però no se sap qui redactarà els textos, aportarà imatges, revisarà les fitxes de servei o carregarà el material final.

Causa: el contingut es tracta com un material que apareixerà al final, quan condiciona l'estructura, les revisions i la publicació.

Conseqüència: la web pot quedar bloquejada a l'espera d'informació, o publicar-se amb textos provisionals que no representen bé el negoci. També és difícil saber si una proposta contempla redacció, càrrega, edició o només l'estructura on anirà el contingut.

Correcció: prepara un inventari senzill: quin contingut existeix, què cal crear, què s'ha d'actualitzar i qui ho valida. Si migraràs informació des d'una altra web, indica quin volum aproximat hi ha i si cal mantenir o redirigir les URL actuals.

4. Esmentar funcionalitats sense definir el recorregut

Símptoma: l'encàrrec inclou «un formulari», «reserves», «una àrea de clients» o «connexió amb una eina», però no descriu què passa abans i després de l'acció.

Causa: s'anomena la funcionalitat, però no les seves regles. Un formulari necessita camps, destinatari, confirmació i tractament d'errors. Una integració requereix saber quines dades s'envien, quan s'envien i què passa si el servei extern no respon.

Conseqüència: una mateixa etiqueta pot amagar nivells de complexitat molt diferents. A més, es fa difícil comprovar si el lliurament respon al que esperaves.

Correcció: descriu cada funcionalitat amb quatre preguntes: qui la fa servir, quina acció duu a terme, quin resultat espera i quines excepcions són rellevants. Per exemple, en un cas hipotètic, no n'hi ha prou amb demanar «un formulari de contacte»; convé indicar quines dades sol·licita, a quin correu o sistema ha d'arribar la consulta i quina confirmació veurà la persona que l'ompli.

5. No separar el que és imprescindible del que és desitjable

Símptoma: totes les idees es presenten com a necessàries per publicar la primera versió: noves seccions, idiomes, integracions, continguts pendents i funcionalitats futures.

Causa: no s'ha decidit quins elements sostenen l'objectiu inicial i quins poden esperar. Això passa fàcilment quan el projecte reuneix necessitats de diversos departaments o persones.

Conseqüència: el pressupost web es fa més difícil d'entendre i el projecte queda exposat a canvis continus. Posposar alguna cosa pot semblar una retallada arbitrària quan, en realitat, és una decisió de prioritat.

Correcció: classifica cada element com a imprescindible, desitjable, futur o fora d'abast. Demana que la proposta reflecteixi aquesta distinció. Així podràs valorar un primer lliurament viable sense perdre les millores que vulguis abordar més endavant.

6. Comparar propostes només per l'import final

Símptoma: tries una proposta perquè té un total més baix o en descartes una altra perquè sembla més cara, sense revisar partides, supòsits i exclusions.

Causa: l'import és més fàcil de comparar que l'abast. Però una xifra aïllada no explica si contempla disseny, continguts, migració, proves, configuració d'eines, formació, manteniment o dependències de tercers.

Conseqüència: pots acceptar una proposta que no cobreix una necessitat rellevant per al teu cas, o pagar per elements que no aporten res a l'objectiu de la primera versió.

Correcció: compara cada proposta amb una mateixa llista de necessitats. Assenyala què inclou, què exclou, què queda pendent de confirmar i quins costos o serveis recurrents podrien existir al marge de la construcció inicial. Si dues propostes no responen al mateix abast, encara no són comparables.

7. Deixar les exclusions i el manteniment en segon pla

Símptoma: la proposta detalla el lliurament inicial, però no aclareix qui gestionarà actualitzacions, accessos, incidències, còpies de seguretat, llicències o canvis posteriors.

Causa: es considera la publicació com el final del projecte, quan la web continuarà necessitant responsables, comptes i decisions de manteniment.

Conseqüència: poden aparèixer tasques sense responsable o costos recurrents que no s'havien tingut en compte. També augmenta la dependència si no queda clar qui controla els accessos, el domini, l'allotjament o els serveis connectats.

Correcció: demana una separació clara entre construcció inicial, serveis recurrents i evolució posterior. Confirma quins comptes existeixen, qui en serà el titular, qui hi podrà accedir i quin suport s'espera després de publicar.

8. Acceptar terminis sense revisar dependències i aprovacions

Símptoma: hi ha una data desitjada, però no s'han identificat continguts pendents, accessos a eines, revisions internes ni la persona responsable de decidir.

Causa: el calendari es formula com una data fixa en lloc de relacionar-lo amb lliuraments i dependències concretes.

Conseqüència: s'acumulen esperes que afecten el projecte i resulta difícil saber quina decisió o material cal per continuar.

Correcció: identifica quina data té un motiu real i què ha de passar abans per complir-la. Defineix qui revisa cada lliurament, quant temps necessita per fer-ho i quina informació ha d'estar disponible abans de començar cada fase.

Com prevenir aquests errors abans de sol·licitar propostes

No cal que resolguis tota la solució tècnica pel teu compte. Sí que cal fer visibles les decisions que canvien l'abast. Un briefing breu i ordenat sol ser més útil que una petició genèrica amb moltes referències visuals.

Inclou, com a mínim:

1. L'objectiu de la web i l'acció principal esperada del visitant.
2. Els perfils de públic als quals ha de respondre.
3. Les pàgines, seccions o tipus de contingut previstos.
4. L'estat dels textos, imatges, documents i catàleg, si n'hi ha.
5. Les funcionalitats necessàries i el recorregut de cadascuna.
6. Les eines que s'han de connectar amb la web i els accessos disponibles.
7. El que ha d'estar a la primera versió i el que es pot posposar.
8. Les restriccions reals: data, responsables de revisió, idiomes, migració o requisits interns.
9. El que esperes gestionar un cop publicada la web.

Els dubtes que no puguis resoldre no invaliden la sol·licitud. Indica'ls com a oberts. És preferible que una incertesa sigui visible que no pas que es converteixi en una suposició diferent per a cada proposta.

Checklist per revisar un pressupost web

Abans d'acceptar o comparar una proposta, comprova aquests punts:

• L'objectiu està escrit en termes d'una acció o necessitat concreta.
• Les pàgines i els continguts estan descrits amb prou detall per entendre'n la funció.
• S'identifica quins continguts ja existeixen, quins falten i qui els aprovarà.
• Cada formulari, àrea privada, reserva o integració té un recorregut definit.
• Els elements imprescindibles estan separats de les millores futures.
• S'indiquen supòsits, tasques incloses i exclusions rellevants.
• La migració de continguts, dades o URL es confirma expressament si escau.
• Es diferencien la construcció inicial, els serveis recurrents i els canvis posteriors.
• Queda clar qui controla els comptes, els accessos i les eines externes.
• Hi ha una manera de comprovar cada lliurament rellevant abans de donar-lo per acceptat.
• El calendari té en compte continguts, revisions i decisions pendents.

Pas següent: convertir una idea en un abast revisable

Un bon pressupost web no elimina totes les decisions futures, però deixa clar quines estan preses, quines són supòsits i quines cal validar abans d'avançar. Aquesta claredat et permet comparar propostes amb criteri i reduir malentesos sobre allò que rebràs.

Si tens una idea de projecte però l'abast encara barreja pàgines, continguts, funcionalitats o integracions, pots explicar el teu projecte de desenvolupament web a AVSISTEC per revisar quina informació convé definir abans de sol·licitar una proposta.