Desenvolupament web: com definir un projecte pas a pas

La vostra empresa necessita una nova web, però quan prova d'explicar-la apareixen peticions barrejades: "que sigui moderna", "que sigui posicion", "que permeti contactar" o "que puguem actualitzar-la". El problema no és tenir moltes idees; és que encara no formen un projecte decidible.

Aquesta guia t'ajuda a preparar un desenvolupament web abans de triar tecnologia o demanar una proposta, i quan acabis, podràs distingir l'objectiu de la teva web, ordenar el que ha d'incloure i detectar les decisions que convé tancar amb les persones responsables.

Resultat esperat

El resultat no hauria de ser una llista de pàgines sense context. Hauríeu d'acabar amb una descripció breu i concreta de cinc elements:

• què ha de canviar gràcies a la web;
• a qui ha de servir i quina acció ha de poder realitzar aquesta persona;
• què inclou la primera versió i què pot esperar;
• quins continguts, dades i decisions ha d'aportar la teva empresa;
• com comprovaràs que les parts rellevants funcionen abans de publicar.

Amb aquesta base, el desenvolupament web deixa de ser una petició genèrica i esdevé un projecte que pots revisar, prioritzar i comparar amb més criteri.

Pas 1: defineix l'objectiu

Objectiu: expressar què ha d'aconseguir la web per al teu negoci i per a qui la visita.acció: completa una frase que relacioni una audiència, una acció i un canvi esperat. Per exemple: "La web ha d'ajudar les persones que busquen el nostre servei a entendre si encaixem i a enviar-nos una consulta amb la informació necessària".

Evita usar adjectius com a objectiu. "Professional", "ràpida" o "completa" poden ser qualitats desitjables, però no indiquen què ha de passar ni com sabràs si el web compleix la seva funció.

També cal escollir una acció principal. Pot ser demanar informació, reservar una cita, demanar un pressupost, comprar un producte o accedir a una àrea privada. Si totes les accions semblen igual d'importants, la web tindrà més difícil guiar a qui la visita.

C Comprovació: pots explicar en una o dues frases qui usarà la web, què hauria de fer i per què aquesta acció importa per a la teva empresa. Si no pots fer-ho, encara estàs definint la necessitat, no el desenvolupament.

Pas 2: delimita l'abast de la primera versió

Objectiu: decidir què ha d'estar llest perquè la web compleixi la seva funció inicial.acció: separa cada element en quatre grups:

• Imprescindible: sense això no es compleix l'objectiu definit.
• Desitjable: aporta valor, però es pot incorporar després.
• Futur: és una possibilitat d'evolució, no part del primer lliurament.
• Fora d'abast: no correspon a aquest projecte.

Aplica aquesta classificació a pàgines, formularis, idiomes, catàleg, migració de continguts, integració amb eines externes, analítica, formació i manteniment. Per evitar que una frase com "volem una web amb tot" oculti decisions diferents.

Un formulari, per exemple, no queda definit només per existir. Heu de concretar quins camps tindrà, qui rebrà els missatges, què veurà la persona en enviar- el i què passarà si falla l'enviament. El mateix succeeix amb una integració: nomenar una eina no explica quines dades es connecten, en quina adreça ni què ha de passar davant d'una incidència.

C Comprovació: cada funció inclosa té un motiu relacionat amb l'objectiu i una prioritat visible. El desitjable o futur no es presenta com a part de la primera versió.

Pas 3: reuneix dades i assigna responsables

Objectiu: evitar que el projecte es bloquegi per contingut pendent, accessos que no apareixen o decisions sense persona responsable.acció: identifica què necessita aportar la teva empresa i qui es fa càrrec de cada part. Com a mínim, aclareix:

• qui valida textos, imatges i missatges comercials;
• quins continguts ja existeixen i quins cal crear o revisar;
• si es traslladaran pàgines, documents, productes o dades des d'una web anterior;
• quins comptes i accessos calen per a domini, allotjament, correu, analítica o serveis connectats;
• qui pren decisions quan hi ha un dubte d'abast;
• qui actualitzarà la web després de la seva publicació.

No cal que el contingut arribi "quan toqui". Si una pàgina de servei, una fitxa de producte o una imatge és necessària per a publicar, forma part de la planificació encara que la prepari una altra persona.

Si el web recull dades personals, processa pagaments o té requisits sectorials específics, valida les obligacions aplicables amb els perfils jurídics, fiscals o de compliment que corresponguin. El desenvolupament s'ha d'adaptar a aquestes decisions, no substituir-les.

C Comprovació: cada dependència rellevant té un responsable i una data o condició de lliurament acordada. Si hi manca un accés, un contingut o una aprovació, queda assenyalat com una dependència oberta.

Pas 4: Tria la solució després de definir la necessitat

Objectiu: seleccionar una forma de construir i mantenir la web que encaix amb l'abast real.

Acció: compara opcions segons les necessitats ja definides. Una solució basada en una estructura estàndard pot encaixar quan les pàgines i funcions segueixen un patró conegut. Un desenvolupament més personalitzat pot tenir sentit quan hi ha recorreguts propis, regles específiques, dades que gestionar o integracions que una solució estàndard no cobreix de forma raonable.

La tecnologia no hauria de ser el punt de partida. Abans de decidir, revisa qüestions pràctiques:

• qui editarà els continguts i amb quina freqüència;
• si hi haurà diferents perfils d'usuari o permisos;
• quines eines externes s'han de connectar;
• quines dades s'han de conservar, migrar o exportar;
• quins canvis preveu ves després de la primera versió;
• qui assumirà actualitzacions, suport i evolució.

Aquesta conversa també serveix per separar la construcció inicial de les necessitats posteriors. Mantenir, actualitzar continguts o afegir noves funcions són decisions diferents i convé descriure-les separadament.

C Comprovació: pots justificar la solució escollida sense recórrer a preferències vagues. Haureu de quedar clar quins requisits cobreix, quins límits accepta la teva empresa i quines decisions es deixen per a una fase posterior.

Pas 5: vàlida abans de publicar

objectiu: comprovar que la web respon al que s'ha acordat i no només que "es veu bé".acció: defineix criteris d'acceptació per a les parts importants. Un criteri útil indica la situació inicial, l'acció i el resultat esperat.

Per exemple, un criteri per a un formulari podria ser: quan una persona completa els camps obligatoris correctament i envia la sol·licitud, veu una confirmació clara i el missatge arriba al destí definit. Si hi ha un error, rep una indicació comprensible per corregir- el.

Revisa també els recorreguts prioritaris des de diferents dispositius i amb els perfils que realment usen la web. Comprova enllaços, continguts, formularis, permisos, avisos i connexions amb serveis externs quan formin part de l'abast. La validació no elimina totes les incidències possibles, però permet detectar discrepàncies abans que la web estigui disponible per al públic.

C Comprovació: cada lliurament rellevant es pot avaluar amb una condició de manera Això és positiu. Les incidències, canvis i elements pendents queden registrats per a decidir si bloquegen la publicació o passen a una fase posterior.

Errors d'execució que convé evitar

• Elegir la tecnologia abans d'entendre el problema. Una plataforma pot condicionar el projecte si es converteix en la decisió principal massa aviat.
• Confondre abast amb desitjos. Les idees futures són útils, però barrejar-ho tot dificulta saber què s'espera de la primera versió.
• Deix el contingut sense responsable. Una web no queda preparada per a publicar perquè l'estructura estigui acabada si manquen missatges, imatges o informació essencial.
• parlar de funcions sense descriure el recorregut."Necessem reserves" o "volem una àrea de clients" no n'hi ha prou per definir usuaris, dades, regles i excepcions.
• accepta termes ambigus. Paraules com ara "intuïtiva", "completa" o "optimitzada" necessiten traduir-se a comportaments verificables.
• Validar només al final. Revisar objectius, abast i continguts durant el projecte redueix la probabilitat de descobrir desacords quan ja és més difícil corregir-los.

Definir bé un projecte no obliga a conèixer desenvolupament web en profunditat. Et permet aportar la informació que només coneix la teva empresa i demanar que les decisions tècniques s'expliquin en funció del seu efecte pràctic.

Si encara tens dubtes sobre l'abast, les integracions o la forma de plantejar una primera versió, pots explicar el teu projecte de desenvolupament web a AVSISTEC per valorar quina informació convé concretar abans d'avançar.