Per què els projectes de software acaben allargant-se

No sempre passa, però quan passa gairebé mai és per una sola raó. T'expliquem què hi ha al darrere, sense culpar ningú.
04.08.2026 — Liquid Team — 4 min lectura

Hi ha projectes que van rodats. Es planifiquen, es construeixen i s'entreguen més o menys quan es va dir, sense ensurts. Passa, i passa més sovint del que la fama del sector faria pensar.

Però també passa l'altre. Projectes que comencen amb una data clara i, pel camí, es van estirant. No per cap catàstrofe, sinó per una suma de coses petites que, una rere l'altra, mouen el final una mica més enllà. Després de força anys fent això, hem vist repetir-se els mateixos motius. I gairebé cap té a veure amb que algú ho hagi fet malament.

L'abast canvia pel camí

És el més habitual. Comences un projecte amb una idea del que ha de fer i, a mesura que el veus prendre forma, apareixen idees noves. «Ja que hi som, podríem afegir…?» «Ara que ho veig, això tindria més sentit així.»

No està malament voler millorar el producte sobre la marxa; moltes vegades aquests canvis són encertats. Però cadascun té un cost en temps, i la suma de diversos «petits afegits» pot moure l'entrega setmanes sense que ningú ho hagi decidit conscientment. El problema no és canviar d'opinió, és no explicar el que aquest canvi costa.

Hi ha decisions que s'aplacen

De vegades el desenvolupament es queda esperant. Falta confirmar un text, aprovar un disseny, triar entre dues opcions, aconseguir un accés. Coses que semblen menors i que, mentre no es resolen, deixen una part de la feina en pausa.

Una decisió aplaçada tres dies no passa res. Deu decisions aplaçades tres dies cadascuna, al llarg d'un projecte, són setmanes. I normalment no es veuen, perquè no apareixen enlloc: simplement el projecte avança més a poc a poc del que podria.

Time development project

No sempre hi ha un interlocutor clar

Els projectes que millor funcionen solen tenir una cosa en comú: algú a l'altre costat que decideix. Una persona que coneix el negoci, que pot respondre ràpid i que té l'última paraula quan cal triar.

Quan aquest paper no està clar, perquè les decisions passen per molta gent, o perquè ningú se sent del tot amo del projecte, cada pregunta triga més a resoldre's. No és culpa de ningú en concret; és una manca d'estructura que es nota directament al calendari.

Estimar bé és difícil (i qui digui el contrari menteix una mica)

Al principi d'un projecte és quan menys se'n sap. I, paradoxalment, és quan toca donar una estimació. Es fa amb la informació disponible, amb experiència i amb sentit comú, però segueix sent una previsió sobre una cosa que encara no existeix.

Hi ha complexitats que només apareixen quan ja ets a dins: una integració que sobre el paper era senzilla i resulta que no, un cas que ningú havia previst, un sistema antic que es comporta de manera estranya. No és que l'estimació estigués mal feta; és que estimar és, per naturalesa, aproximar.

Llavors, es pot evitar?

En part sí, i per això ho expliquem. Molts d'aquests factors es poden limitar: tancant bé l'abast al principi, deixant clar qui decideix, marcant quins canvis entren ara i quins van a una segona fase, i sent honestos amb les estimacions en lloc de prometre dates impossibles.

No sempre s'elimina del tot, perquè un projecte és una cosa viva i de vegades toca adaptar-se. Però si haguéssim de resumir-ho en una idea: els projectes no s'allarguen per falta de ganes ni de capacitat, sinó per falta de converses a temps. Les que es tenen al principi, quan encara es pot decidir amb calma, i les que es tenen durant, quan alguna cosa canvia i convé posar-la sobre la taula de seguida.

Ho hem après fent projectes, no llegint-ho en cap tutorial o post. I és, probablement, el més útil que podem oferir: no la promesa que mai hi haurà un imprevist, sinó el costum de veure'ls venir i explicar-los a temps.