Hi ha una frase que tard o d’hora apareix en gairebé qualsevol projecte web: “només són uns canvis petits”. I sovint ve acompanyada d’una altra: “ho necessitem com més aviat millor”.

I la realitat és que un projecte web no s’espatlla per uns canvis petits, però sí que s’espatlla per la suma de petits canvis, retards i decisions que van arribant tard… fins que el calendari marcat es converteix en ficció.

I això no ho diem per teoria: per experiència del nostre dia a dia a Croma, els projectes que surten rodons solen tenir una cosa en comú: un calendari realista, fases clares i un respecte mínim pels temps pactats.

Un projecte web no és només una data: és una cadena

Un projecte web funciona com una cadena de fases connectades. Si una es retarda, la següent no “es queda igual”: s’improvisa, es comprimeix o avança amb suposicions. I aquí comencen els problemes.

Respectar timings no és un caprici: és protegir la qualitat del resultat i també la salut del projecte.

Quan no es defineix un calendari realista —o es defineix però després s’ignora— apareixen patrons molt reconeixibles.

Es dispara la “feina invisible”

Reunions extra, correus per aclarir coses que no estaven definides, revisions repetides, decisions que fan marxa enrere… tot això no es veu a la web final, però consumeix hores.

Es prenen decisions de pressa (i es paguen després)

Un timing ajustat força el clàssic: “ja ho canviarem després”, “ho deixem així per ara”, “publiquem i ajustem”. I de vegades aquest “després” no arriba mai.

La qualitat baixa just allà on més importa

Quan el calendari es trenca, el primer que se sol retallar és el que “ningú veu”, però després es nota:

  • Revisions

  • Rendiment (Core Web Vitals)

  • Accessibilitat

  • SEO

I sí: és just el que després acaba generant correccions i setmanes d’“ajustos”.

El projecte entra en l’espiral del “tot és urgent”

Si tot és urgent, res no ho és. I es normalitza el caos: es treballa a cop de WhatsApp, s’aprova de pressa, es publica amb dubtes. No és sostenible.

Timings: el millor sistema d’estalvi

Un bon calendari és un sistema d’estalvi. Estalvia:

  • Temps (menys voltes)

  • Diners (menys canvis d’última hora)

  • Energia (menys estrès)

  • Risc (menys errors en producció)

  • Oportunitats (més marge per millorar de debò)

I, sobretot, estalvia aquell moment final de: “això no era el que esperàvem”.

Com es construeixen timings realistes en un projecte web

Un timing realista no vol dir “anar lent”. Vol dir anar amb seny, tenint en compte l’abast del projecte… i la realitat del client (que també té reunions, campanyes, tancaments de mes i vida).

1) Definir l’abast amb precisió

Sense un abast clar no hi ha timing possible. El desenvolupament d’una web pot ser:

  • 5 pàgines simples

  • Un ecosistema amb idiomes, formularis, integracions, blog, migracions, etc.

Els timings surten de concretar: pàgines, funcionalitats, idiomes, continguts, SEO, integracions, disseny, etc.

2) Acordar qui decideix i quan

Molts retards venen d’un clàssic: “ho he de consultar”. Perfecte, però aleshores cal definir:

  • Qui valida cada fase

  • Quantes rondes de canvis hi ha

  • Quant temps té cada part per respondre

Per experiència nostra, quan això es pacta a l’inici, el projecte respira.

3) Bloquejar temps per als continguts (sí, bloquejar)

El contingut no és “l’últim”. És una peça central.

Si textos, imatges i estructura arriben tard, disseny i desenvolupament avancen amb suposicions. I després venen els “ajustos”.

Consell pràctic: calendaritzar els continguts com una entrega formal, amb data i format.

4) Deixar marge per a QA i ajustos

Una web sense una fase de test correcta és com inaugurar un restaurant sense provar la cuina.

Cal temps per:

  • provar formularis

  • revisar mòbil/tauleta/escriptori

  • validar enllaços, redireccions i SEO tècnic

  • revisar velocitat i rendiment

  • comprovar analítica i mesurament

I no, això no es fa “en una horeta abans de publicar” 🙂

5) Planificar el llançament com una fase

“Publicar” no és prémer un botó. Hi ha checklist: DNS, SSL, còpies de seguretat, indexació, Search Console, analítica, redireccions, monitorització…

Quan es planifica, el llançament és un pas més. Quan no, es converteix en un dia complicat…

Respectar timings no és rigidesa: és un pacte

Respectar el calendari no vol dir no canviar res. Els projectes canvien. Sempre. La clau és com es gestionen aquests canvis:

  • Apareix alguna cosa nova → s’avalua l’impacte (temps/cost)

  • Es decideix amb criteri

  • S’ajusta el pla

  • I es manté el control

El que destrossa un projecte no és el canvi: és el canvi sense mètode.

I si el client no arriba a temps?

Això passa. I no és “culpa” de ningú: empreses amb mil fronts, equips petits, campanyes, urgències…

L’important és tenir un sistema clar (i humà):

  • Quins entregables depenen del client

  • Què passa si es retarda (es replanifica)

  • Com es protegeixen les fases següents

  • I quines implicacions té (per exemple, moure la data de publicació)

Perquè el pitjor que es pot fer és fer veure que no passa res i seguir apretant per darrere: al final, el projecte explota igual… però més tard i més car.

Conclusió: un bon timing és una web millor (i un projecte més sa)

Per experiència del nostre dia a dia aquí a Croma, una gran part de l’èxit d’una web no és només el disseny o la tecnologia, sinó com s’organitza i es respecta el procés.

Quan els timings són clars i es compleixen:

  • El disseny es decideix amb calma

  • El desenvolupament es fa amb ordre

  • El contingut encaixa

  • El SEO es treballa bé

  • La web arriba a temps (de veritat)

  • I el projecte guanya

Al final, la millor web no és la que es publica abans.

És la que es publica bé.