Desenvolupament backend: com decidir què necessita la teva empresa

Un client omple un formulari, el teu equip rep un correu i després comença una cadena de tasques manuals: copiar dades a un full de càlcul, comprovar la disponibilitat, assignar una persona responsable i respondre. Si es perd una dada o es modifica dues vegades, el problema no sol ser a la pantalla que veu el client, sinó en allò que passa al darrere.

El desenvolupament backend serveix per construir aquesta part no visible: la lògica que processa accions, desa informació, aplica regles i connecta eines. En acabar aquest cas hipotètic podràs decidir si la teva necessitat requereix backend, què hauries de definir abans de demanar-lo i com comprovar que la solució respon al procés real de la teva empresa.

Situació inicial hipotètica

Imagina una petita empresa de serveis que rep sol·licituds des del seu web. Cada petició s’ha de revisar, assignar a una persona de l’equip i fer passar per diversos estats: rebuda, pendent d’informació, acceptada o tancada.

Al principi, el volum permet resoldre-ho amb correus i un full compartit. Tanmateix, l’equip necessita saber quines sol·licituds continuen obertes, qui treballa en cadascuna i quina informació ha rebut el client. També vol evitar que una mateixa petició es gestioni dues vegades.

L’empresa planteja una petició tècnica: «Necessitem un backend». És una hipòtesi raonable, però encara no defineix el projecte. Abans cal convertir aquesta etiqueta en una decisió operativa.

Problema observable: dades disperses i regles sense un lloc clar

En aquest escenari, el problema no és que falti una tecnologia concreta. El que s’observa és que el procés depèn d’accions manuals i d’informació repartida entre correus, documents i converses internes.

El backend pot assumir tasques com aquestes:

• rebre la informació enviada des d’un formulari o una àrea privada;
• desar cada sol·licitud en una base de dades, és a dir, en una estructura preparada per consultar i actualitzar informació;
• comprovar regles, per exemple, impedir que es tanqui una sol·licitud sense indicar-ne un motiu;
• identificar quina persona pot consultar o modificar cada dada;
• enviar informació a una altra eina quan calgui una integració;
• registrar els canvis rellevants perquè l’equip conegui l’estat de cada cas.

La pantalla, els botons i els formularis pertanyen al frontend: la part que utilitza una persona. El backend treballa darrere d’aquesta interfície. Totes dues parts han d’encaixar, però un web informatiu senzill no necessita el mateix nivell de lògica que un sistema en què diverses persones actualitzen dades i segueixen un procés.

Anàlisi de l’objectiu abans de triar la solució

En el cas hipotètic, la decisió útil no és «fer un backend complet». És concretar què ha de canviar en l’operativa.

L’objectiu es podria formular així: centralitzar les sol·licituds i permetre que l’equip en consulti, n’assigni i n’actualitzi l’estat amb regles clares.

Amb aquest objectiu, ja pots plantejar preguntes que afecten el desenvolupament:

• Quines dades ha d’aportar el client i quines completa l’equip?
• Quins estats pot tenir una sol·licitud i qui els pot canviar?
• Què ha de passar si falten dades o una persona intenta repetir una acció?
• Quins usuaris accediran al sistema i quins permisos necessita cada perfil?
• Quina informació s’ha de conservar i durant quant de temps?
• Hi ha eines externes que hagin de rebre o aportar dades?

Aquestes preguntes separen tres capes que convé no barrejar:

La solució tècnica es decideix després. Pot ser una aplicació amb backend propi, una ampliació d’una eina existent o una combinació de sistemes. Depèn de les regles, les dades, les integracions i del manteniment que puguis assumir.

Abast proposat: una primera versió que es pugui comprovar

Per a l’empresa hipotètica, una primera versió es pot centrar en el recorregut complet d’una sol·licitud, sense afegir des de l’inici totes les idees de futur.

L’abast mínim hauria de descriure comportaments verificables. Per exemple:

1. El client envia una sol·licitud mitjançant un formulari amb els camps acordats.
2. El sistema crea un registre únic i el deixa inicialment com a «rebuda».
3. Una persona autoritzada pot consultar la sol·licitud i assignar-la a un membre de l’equip.
4. La persona assignada pot actualitzar l’estat segons les regles definides.
5. L’equip pot localitzar sol·licituds per estat, responsable o dades rellevants.
6. Si falta una dada necessària o es produeix un error, el sistema mostra una resposta comprensible i no deixa el registre en una situació ambigua.

Allò desitjable —per exemple, informes més complexos, automatitzacions addicionals o noves integracions— pot quedar preparat per a una fase posterior. Posposar-ho no vol dir descartar-ho; evita que una primera entrega barregi necessitats diferents sense saber quina s’ha de resoldre primer.

També convé deixar explícit què no s’hi inclou. La migració d’informació antiga, la redacció de textos, les llicències de serveis externs, el manteniment o una integració no descrita poden modificar la feina necessària. Si formen part de la necessitat, s’han d’analitzar com a part de l’abast, no donar-los per fets.

Solució i comprovació: el backend ha de respondre a accions reals

En l’aplicació del cas, el backend connecta el formulari amb les dades i amb les regles de gestió. No n’hi ha prou que la informació arribi: ha d’arribar al lloc correcte, ha de poder ser consultada per qui correspongui i s’ha de mantenir coherent quan diverses persones hi treballen.

Una comprovació útil s’expressa des de l’acció de l’usuari, no només des del component tècnic. Per exemple:

Quan un client completa correctament el formulari, el sistema crea una sol·licitud amb l’estat «rebuda» i mostra una confirmació visible. Una persona amb permís de gestió la pot veure, assignar-la i canviar-ne l’estat. Si el formulari no conté una dada obligatòria, s’informa del camp que cal corregir i no es crea una sol·licitud incompleta.

Aquest tipus de criteri permet revisar la solució abans de donar-la per vàlida. També revela preguntes que convé resoldre: què passa si falla un servei extern, qui pot esborrar informació, com es recupera un accés o quins canvis ha de registrar el sistema.

La seguretat, el tractament de dades i les obligacions aplicables a la teva activitat requereixen validació humana i, quan correspongui, assessorament especialitzat. No convé resoldre’ls amb una frase genèrica en el projecte ni assumir que una funció estàndard cobreix tots els requisits de la teva empresa.

El backend tampoc no s’acaba necessàriament amb la posada en marxa. Si canvien els estats, els usuaris, els serveis connectats o les regles comercials, pot ser necessari revisar la lògica i les proves. Per això és important acordar qui mantindrà el sistema, quins accessos conservarà l’empresa i com es documentaran les decisions rellevants.

Aprenentatges transferibles

El cas és hipotètic, però la decisió és aplicable a molts negocis: necessites desenvolupament backend quan el valor de la solució depèn de processar dades, aplicar regles, coordinar usuaris o connectar sistemes, i no només de mostrar informació.

Abans d’escollir eines, defineix el resultat operatiu que busques, les dades que hi intervenen, les persones que faran servir el sistema i les excepcions que no poden quedar sense resposta. Després delimita una primera versió que puguis provar amb situacions reals de feina.

Si has detectat que el teu web o procés necessita una lògica pròpia darrere de la interfície, pots explicar el teu projecte de desenvolupament web per valorar quin objectiu, abast i solució encaixen amb la necessitat que vols resoldre.