Home / Blog / Gestione dei progetti
Gestione dei progetti Tempo di lettura stimato: 22 min · 31.07.2026

10 errori da evitare nella realizzazione di un sito web

Soltanto il 31% circa dei progetti tecnologici rispetta tempi, budget e perimetro concordati. La maggior parte delle cause nasce prima della prima riga di codice: i dieci errori più frequenti e come evitarli.

Illustrazione: in una finestra del browser un elenco di crocette si trasforma in un elenco di segni di spunta — gli errori del committente e la loro correzione.

Soltanto il 31% circa dei progetti tecnologici rispetta tempi, budget e perimetro concordati. La maggior parte delle cause nasce prima della prima riga di codice: i dieci errori più frequenti e come evitarli.

La realizzazione di un sito web è uno di quegli investimenti che può accelerare sensibilmente la crescita di un’azienda oppure trasformarsi in un’esperienza costosa e frustrante, con un risultato lontano dalle aspettative, un budget sforato e la necessità di rifare tutto dopo pochi mesi; e gli errori da evitare nella realizzazione di un sito web — quelli che portano al secondo esito — le aziende li commettono quasi tutti prima della prima riga di codice. Le statistiche di settore sono preoccupanti: soltanto il 31% circa dei progetti tecnologici viene completato nei tempi, dentro il budget e secondo il perimetro fissato all’inizio, e i progetti web non fanno eccezione, perché lo sviluppo web rientra in quella stessa statistica: gli altri, circa due terzi, vengono classificati come «a rischio» (budget o scadenza sforati, perimetro ridotto) oppure come falliti. La maggior parte di questi insuccessi non dipende però da limiti della tecnologia o dall’incompetenza di chi sviluppa: sono la conseguenza di fattori umani e organizzativi, e sono del tutto evitabili se il committente sa in anticipo quali errori si commettono più spesso e come starne alla larga.

In questo articolo esaminiamo i dieci errori più frequenti che aziende e organizzazioni commettono quando commissionano un sito web e, per ciascuno, spieghiamo perché nasce, quali conseguenze produce e che cosa può fare Lei per evitarlo.

1. Decidere guardando soltanto il prezzo

È forse l’errore più diffuso e più caro di tutti: si mettono a confronto più preventivi e si sceglie il più economico, convinti che un sito sia un sito a prescindere da chi lo realizza e che la differenza tra un’offerta da 500 euro e una da 5.000 euro sia soltanto il margine di chi sviluppa. In realtà quella differenza riflette quasi sempre divari sostanziali nella qualità dello sviluppo, nella pulizia del codice, nel livello di sicurezza, nella possibilità di crescere e nell’assistenza dopo la consegna, e l’offerta più economica diventa spesso, sul lungo periodo, la soluzione più cara, perché il codice di scarsa qualità genera il cosiddetto «debito tecnico»: un accumulo di problemi che richiede correzioni continue, limita l’evoluzione del sito e alla fine porta alla necessità di ricostruire tutto da zero.

Le offerte a basso prezzo nascondono spesso rischi rilevanti: chi sviluppa può usare temi gratuiti o piratati che contengono vulnerabilità di sicurezza o codice malevolo nascosto; il codice può essere non ottimizzato e non strutturato, il che rende la manutenzione e le aggiunte successive complicate e costose; i test possono essere insufficienti, e in quel caso gli errori si scoprono soltanto dopo il lancio; e l’assistenza dopo la consegna può essere minima o inesistente, lasciandola senza aiuto proprio quando serve di più. L’approccio giusto è valutare le offerte non in base al prezzo ma in base al valore: studiare il portfolio di chi sviluppa, parlare con i clienti precedenti, verificare la qualità tecnica dei siti che ha realizzato e capire con chiarezza che cosa è incluso nel prezzo e che cosa no, perché spesso l’offerta «economica» non comprende elementi che in quella «cara» sono standard, per esempio il design responsive, l’ottimizzazione SEO di base, la configurazione di sicurezza o la formazione dei redattori che dovranno usare il sito.

Vale la pena fare quel conto fino in fondo, perché l’offerta economica non crolla nel preventivo, ma nella fattura che arriva un anno e mezzo dopo. Mettiamo che il sito economico duri appunto tanto e poi vada rifatto: per la seconda realizzazione paga il prezzo pieno — la nostra realizzazione in WordPress parte da 2.500 € — e a quello si aggiungono la migrazione dei contenuti, un nuovo giro di testi e immagini e i reindirizzamenti 301 dai vecchi URL, senza i quali le posizioni accumulate in un anno nei risultati di Google se ne vanno insieme alla vecchia struttura degli indirizzi. Il risparmio, quindi, non era uno sconto ma un pagamento rimandato, con gli interessi. E se nel frattempo il sito viene violato attraverso un tema preconfezionato o un plugin non aggiornato, il ripristino secondo il nostro listino costa 90 € l’ora IVA esclusa, con un minimo di otto ore: da solo si mangia la maggior parte di quanto era stato risparmiato all’inizio. Questo non significa che un sito economico sia sempre la scelta sbagliata: per tre pagine il cui unico compito è mostrare i contatti e gli orari, un tema pronto è una decisione razionale, e lo diciamo. L’errore comincia dove il sito è un canale di vendita ma viene comprato come un biglietto da visita.

2. Requisiti e obiettivi definiti male

Il secondo errore più frequente è avviare il progetto senza requisiti, obiettivi e risultati attesi definiti con chiarezza: il committente contatta chi sviluppa e dice qualcosa come «mi serve un sito moderno e professionale», senza saper indicare quali funzioni servano, chi sia il pubblico di riferimento, quali azioni i visitatori dovrebbero compiere sul sito e come si misureranno i risultati. Questa vaghezza costringe chi sviluppa a fare le proprie ipotesi su ciò che il cliente vuole, e quelle ipotesi si rivelano spesso sbagliate, il che porta a delusione da entrambe le parti e alla necessità di rifare lavoro già fatto, bruciando tempo e denaro in più. È anche il motore principale dell’«espansione del perimetro» (scope creep), un fenomeno che riguarda più della metà dei progetti del settore e che significa che durante il progetto vengono aggiunte di continuo funzioni e richieste non previste nel piano iniziale, con costi che crescono dal 10% al 25% e tempi di sviluppo che spesso si allungano in modo sensibile.

La soluzione è investire tempo ed energie nella fase di analisi (discovery phase) prima di cominciare a sviluppare qualsiasi cosa: in quel momento si definiscono obiettivi di business concreti (per esempio aumentare del 30% il numero di richieste, portare la frequenza di rimbalzo sotto il 40%, tenere la durata media della sessione sopra i 3 minuti), si costruiscono le personas, si mappano i percorsi degli utenti, si stabiliscono la struttura del sito e i requisiti funzionali e si redige un capitolato dettagliato che fa da documento di riferimento per tutto il progetto. Avere quel documento protegge entrambe le parti: il committente sa che cosa riceverà per i propri soldi, chi sviluppa sa che cosa ci si aspetta da lui, e qualsiasi modifica che ecceda il perimetro fissato viene formalizzata come lavoro aggiuntivo, con budget e tempi propri.

3. Sopravvalutare il design e sottovalutare la parte tecnica

Il terzo errore, particolarmente diffuso tra gli imprenditori, è concentrarsi troppo sul design visivo ignorando o sottovalutando del tutto il lato tecnico: si sceglie chi sviluppa soltanto in base a quanto sono belli i siti del suo portfolio, senza fare domande sulla qualità del codice, sulla velocità del sito, sulle pratiche di sicurezza, sulla scalabilità o sull’ottimizzazione per i motori di ricerca. Il design visivo e lo sviluppo tecnico sono due discipline diverse, e un bel sito che si carica in dieci secondi, è vulnerabile agli attacchi e non si trova sui motori di ricerca vale molto meno di un sito visivamente più semplice ma veloce, sicuro e ben ottimizzato.

Le ricerche mostrano con costanza che il 53% degli utenti da dispositivo mobile abbandona un sito se impiega più di tre secondi a caricarsi, e che un secondo di ritardo nel caricamento può ridurre sensibilmente le conversioni: come rileva lo studio di Akamai e SOASTA, già 100 millisecondi di ritardo abbassano i tassi di conversione fino al 7%. Questi numeri dicono che le prestazioni del sito incidono direttamente sui Suoi ricavi, e nessun design bello lo compenserà se nell’esecuzione tecnica sono stati commessi errori. L’approccio giusto è valutare chi sviluppa non soltanto dall’aspetto dei suoi lavori, ma anche da come sa spiegare il proprio approccio tecnico: quale architettura usa, come garantisce la velocità del sito, come affronta le questioni di sicurezza e come pensa di far crescere il sito se l’azienda cresce e le esigenze cambiano.

4. La SEO rimandata a dopo

L’ottimizzazione per i motori di ricerca viene percepita molto spesso come qualcosa da aggiungere al sito dopo averlo costruito, come si dà la vernice a un muro a casa finita, ma in realtà la SEO tecnica è una parte fondamentale dell’architettura del sito, e inserirla dopo il lancio è sensibilmente più costoso, più complicato e meno efficace che includerla nel processo di sviluppo fin dall’inizio. La struttura degli URL, la gerarchia delle pagine, l’architettura dei link interni, la struttura dei titoli, i dati strutturati (schema markup), l’ottimizzazione delle immagini, le metriche dei Core Web Vitals e l’esperienza su dispositivo mobile sono tutti elementi molto più facili ed economici da impostare bene durante lo sviluppo che da rifare su un sito finito.

Google usa l’indicizzazione mobile-first, il che significa che è la versione mobile del Suo sito quella su cui Google valuta e posiziona i contenuti: se l’esperienza mobile è scadente, il posizionamento ne risentirà indipendentemente da quanto è buona la versione desktop. Secondo i dati di Statista, nel 2024 il commercio da dispositivo mobile ha raggiunto circa 2.070 miliardi di dollari, e i dati di Google mostrano che tra il 2015 e il 2017 le ricerche da dispositivo mobile con intento di acquisto e la formula «vicino a me» (near me) sono cresciute più di cinque volte: l’ottimizzazione mobile non è un accessorio gradevole ma una necessità di business, soprattutto per le aziende locali che vogliono clienti nella propria zona. L’approccio giusto è indicare i requisiti SEO già nella richiesta di offerta (RFP) come parte obbligatoria dello sviluppo e non come servizio separato da pagare a parte. In concreto significa che chi sviluppa deve pianificare fin dall’inizio una struttura di URL adatta alla SEO, garantire una gerarchia corretta dei titoli (H1, H2, H3), implementare i dati strutturati (schema markup), ottimizzare le immagini con testi alternativi e formati moderni, configurare la sitemap XML e il file robots.txt e assicurare che la velocità del sito rispetti i Core Web Vitals: su un sito finito le stesse modifiche possono richiedere una ricostruzione sostanziale dell’architettura.

5. Ignorare i contenuti o rimandarli all’ultimo momento

Il quinto errore è una delle cause più frequenti di ritardo nei progetti web: si pensa che i contenuti siano qualcosa da «buttare giù» all’ultimo e si concentra tutta l’attenzione su design e funzionalità, mentre testi, immagini e gli altri elementi restano da fare fino alla fine del progetto. Il problema è che il design si costruisce attorno ai contenuti e non il contrario: se i contenuti non ci sono, chi disegna è costretto a lavorare con testo segnaposto (lorem ipsum), il design non corrisponde alla quantità e alla struttura dei contenuti reali e, quando finalmente si inserisce il testo vero, l’aspetto visivo può cambiare in modo drastico, e non in meglio.

Il ritardo nella preparazione dei contenuti è una delle cause di slittamento più citate nel settore, ed è logico, perché produrre contenuti di qualità richiede tempo: i testi vanno scritti, allineati al tono e al messaggio dell’azienda e ottimizzati per la SEO, e le immagini vanno scelte o realizzate in modo che rispettino l’identità di marca e le esigenze del design. L’approccio giusto è trattare la produzione dei contenuti come una fase critica del progetto, con scadenze e responsabili propri, che parte in parallelo al design o addirittura prima, non come un compito accessorio da svolgere «quando ci sarà tempo». Se l’azienda non ha risorse interne per i contenuti, la voce va messa a budget e affidata a un copywriter o a uno specialista di contenuti.

6. Nessuna pianificazione della manutenzione dopo la consegna

Il sesto errore è legato direttamente al tema della manutenzione, di cui abbiamo già parlato nell’articolo sul ripristino dei siti hackerati: molti imprenditori considerano il sito un prodotto una tantum che dopo la consegna semplicemente «funziona» e non pensano a che cosa succederà dopo il lancio, quando serviranno aggiornamenti di sicurezza, modifiche ai contenuti, correzioni di errori, ottimizzazione delle prestazioni e compatibilità con le nuove versioni dei browser e con i nuovi dispositivi. È un approccio pericoloso, perché un sito senza manutenzione è un sito senza difese: secondo i dati di Sucuri più della metà dei siti CMS violati girava, al momento dell’infezione, con una versione di software obsoleta, e la stima Sophos molto citata, che ha più di dieci anni, parla di circa 30.000 nuovi siti al giorno in cui viene rilevato codice malevolo.

La manutenzione va affrontata già in fase di pianificazione del progetto e non dopo il lancio, perché incide sulla scelta della tecnologia (alcune piattaforme si mantengono più facilmente di altre), sulla pianificazione del budget (i costi di manutenzione vanno inclusi nel budget dell’intero ciclo di vita del sito) e anche sulla scelta di chi sviluppa (occorre chiarire se offre anche servizi di manutenzione e a quali condizioni). Nel caso ideale già nel contratto si include un accordo di assistenza (SLA, Service Level Agreement) che definisce quali interventi di manutenzione verranno svolti, con quale frequenza, quali sono i tempi di risposta in caso di problema e quanto costa il servizio.

7. Lasciare a chi sviluppa il controllo di dominio e hosting

Il settimo errore è tra quelli che possono avere le conseguenze peggiori nel lungo periodo, eppure viene commesso sorprendentemente spesso: il committente lascia che sia chi sviluppa a registrare il nome a dominio e ad acquistare l’hosting a proprio nome invece che a nome dell’azienda, e così perde il controllo su asset digitali critici. Se la collaborazione finisce per qualsiasi motivo — in modo amichevole o in seguito a un conflitto — il committente può ritrovarsi a non poter accedere al proprio dominio, a non poter spostare il sito su un altro server o perfino a perdere il nome a dominio, se chi sviluppa non rinnova la registrazione.

Il nome a dominio e l’account di hosting sono asset digitali della Sua azienda e devono essere di Sua proprietà e sotto il Suo controllo, esattamente come la sede legale o il marchio: non lascerebbe che il Suo commercialista registrasse a proprio nome la sede legale dell’azienda, e allo stesso modo non dovrebbe lasciare a chi sviluppa il controllo della Sua identità digitale. L’approccio giusto è registrare il dominio di persona presso un registrar affidabile, acquistare l’hosting a nome della propria azienda oppure affittarlo da un partner che su richiesta consegna configurazione e dati, e dare a chi sviluppa soltanto l’accesso tecnico necessario a realizzare e pubblicare il sito, non il controllo amministrativo su quelle risorse. Lo stesso vale per Google Search Console, Google Analytics e gli altri account di analisi e marketing: vanno creati a nome dell’azienda, e a chi sviluppa si concede un accesso con permessi limitati.

8. Trascurare i test e il controllo qualità

L’ottavo errore è che molti committenti non dedicano attenzione sufficiente ai test e accettano il sito senza una verifica accurata, fidandosi dell’affermazione di chi lo ha realizzato che «funziona tutto»; in realtà un collaudo serio è un processo complesso e lungo, che comprende molto più di una navigazione veloce e di qualche pulsante premuto. Un controllo qualità insufficiente è una delle ragioni più frequenti per cui i siti, dopo il lancio, mostrano errori che pesano sull’esperienza degli utenti, sulle conversioni e perfino sulla sicurezza, e correggerli su un sito finito è sempre più caro e più complicato che scoprirli e risolverli durante lo sviluppo.

I test dovrebbero coprire più dimensioni: i test funzionali verificano che tutte le funzioni del sito lavorino correttamente — moduli, ricerca, navigazione, registrazione degli utenti, carrello e processo di pagamento, filtri e ordinamento dei contenuti; i test di compatibilità verificano che il sito funzioni correttamente su browser diversi (Chrome, Firefox, Safari, Edge), su sistemi operativi diversi e su dispositivi diversi (computer, tablet, smartphone con schermi di dimensioni diverse); i test di prestazione misurano la velocità di caricamento, i tempi di risposta e il comportamento sotto carico; i test di sicurezza individuano le vulnerabilità potenziali, per esempio la SQL injection, le possibilità di attacco XSS e i controlli di accesso impostati male; e i test di accessibilità verificano che il sito sia utilizzabile da persone con disabilità diverse, secondo gli standard WCAG.

L’approccio giusto è prevedere già nel contratto una fase di test con criteri di accettazione definiti con chiarezza: mettere cioè per iscritto che cosa verrà testato, quali risultati sono accettabili e quale procedura si applica se i test fanno emergere dei problemi. È consigliabile inoltre che il committente svolga, da solo o con l’aiuto di uno specialista indipendente, i test di accettazione, invece di affidarsi completamente all’autovalutazione di chi ha sviluppato, perché chi collauda il proprio lavoro è come lo studente che si corregge l’esame da sé.

9. Decidere in comitato senza un unico responsabile

Il nono errore è organizzativo ed è particolarmente tipico delle aziende e delle organizzazioni più grandi, dove nel progetto sono coinvolti più decisori — il marketing, le vendite, la direzione, il reparto IT e talvolta perfino i legali — e ciascuno partecipa all’approvazione di design e contenuti con lo stesso diritto di voto. Questo «design per comitato» porta quasi sempre a un risultato fatto di compromessi che non soddisfa nessuno, perché ogni decisore cerca di far entrare nel sito le proprie priorità e i propri desideri, e il risultato finale diventa sovraccarico, incoerente e slegato dagli obiettivi di business.

Gli studi e l’esperienza del settore mostrano con costanza che i progetti con un unico decisore chiaramente individuato, con l’autorità di approvare design, contenuti e funzionalità, si concludono più in fretta, rispettano il budget più spesso e ottengono risultati migliori di quelli in cui decide un gruppo. Questo non significa che il parere delle altre parti coinvolte non conti: significa che serve un processo chiaro in cui tutti possano esprimersi e dare un riscontro, ma in cui la decisione finale la prende una sola persona, autorizzata e responsabile del risultato. La matrice RACI (Responsible, Accountable, Consulted, Informed) è uno strumento efficace per strutturare questo processo, perché definisce con chiarezza chi esegue il lavoro, chi è il decisore finale, chi va consultato e chi va informato delle decisioni.

10. Ignorare la proprietà intellettuale e gli aspetti contrattuali

Il decimo errore riguarda il lato giuridico, che molti imprenditori — soprattutto i titolari delle aziende più piccole — tendono a ignorare o a considerare burocrazia inutile: si avvia la collaborazione senza un contratto formale, senza diritti di proprietà intellettuale definiti con chiarezza e senza un accordo di riservatezza (NDA), il che può creare problemi seri sia durante il progetto sia dopo la sua conclusione. Senza diritti di proprietà intellettuale definiti, il committente può ritrovarsi a non possedere di fatto il codice sorgente che ha pagato, e chi ha sviluppato può riutilizzare lo stesso codice per altri clienti o perfino rifiutarsi di consegnare il sorgente se la collaborazione si interrompe prima del previsto.

Il contratto dovrebbe stabilire con chiarezza che tutta la proprietà intellettuale prodotta durante lo sviluppo — codice sorgente, file di design, grafica, strutture dati e documentazione — appartiene al committente al saldo del pagamento, e che chi ha sviluppato non ha diritto di usarla per altri scopi senza il consenso del committente. Il contratto deve inoltre contenere la definizione del perimetro del progetto, le scadenze, il piano dei pagamenti (preferibilmente legato al raggiungimento di milestone e non al tempo), il periodo di garanzia, le clausole di riservatezza e le modalità di risoluzione delle controversie. Una struttura di pagamento legata a milestone concrete e approvate (milestone-based payments), e non semplicemente a periodi di tempo, spinge chi sviluppa a rispettare le scadenze e garantisce che il committente paghi soltanto per il lavoro effettivamente svolto e non per un consumo di tempo indefinito; per progetti più grandi e non standard è adatto anche il modello a tempo e materiali con un tetto settimanale, purché perimetro e tetto siano fissati per iscritto.

L’accordo di riservatezza (NDA) è particolarmente importante se durante lo sviluppo vengono comunicate informazioni aziendali sensibili — dati dei clienti, processi di business, politica dei prezzi o altre informazioni riservate che, finite in mano ai concorrenti, possono danneggiare la Sua attività. A molti imprenditori l’NDA sembra uno strumento da grande azienda, ma in realtà è altrettanto importante per qualsiasi impresa che condivida informazioni sensibili con partner esterni. Un contratto ben strutturato, con milestone e criteri di accettazione chiari, funziona per giunta anche come strumento di gestione del progetto: garantisce che entrambe le parti siano d’accordo su che cosa si sta facendo, quando sarà finito e quale risultato ci si aspetta a ogni fase, e riduce sensibilmente il rischio di incomprensioni e conflitti lungo il percorso.

Altri errori da evitare nella realizzazione di un sito web

Anche se abbiamo descritto i dieci errori principali, ci sono altre mancanze frequenti che meritano una menzione a parte, perché possono incidere in modo sostanziale sull’esito del progetto. Una di queste è affidarsi troppo al parere di chi sviluppa su qualsiasi questione, strategia di business compresa: chi sviluppa è un esperto di tecnologia, ma raramente conosce le specificità della Sua attività, il Suo pubblico e le dinamiche del Suo mercato bene quanto Lei, e se gli delega tutte le decisioni rischia di ottenere un sito tecnicamente buono ma inefficace sul piano commerciale.

Un secondo errore frequente è ignorare l’accessibilità: molti imprenditori non sanno nemmeno che il proprio sito deve essere accessibile alle persone con disabilità e che in molte giurisdizioni è un obbligo di legge e non semplicemente una buona pratica. Garantire l’accessibilità già durante lo sviluppo è sensibilmente più semplice ed economico che aggiungerla a un sito finito, e amplia il pubblico potenziale, visto che circa il 16% della popolazione mondiale — 1,3 miliardi di persone — vive con una disabilità significativa.

Il terzo errore aggiuntivo è non implementare l’analisi dei dati e il tracciamento delle conversioni: molti siti vengono lanciati senza configurare Google Analytics, Google Search Console o altri strumenti di analisi, il che significa che il committente non può valutare l’efficacia del sito, individuare i problemi e prendere decisioni basate sui dati per le ottimizzazioni successive. L’implementazione dell’analisi va inclusa nel perimetro del progetto come requisito obbligatorio e non come qualcosa che «si farà dopo». Senza dati Lei si muove di fatto alla cieca: non sa quanti visitatori attira il Suo sito, da dove arrivano, quali pagine visitano, dove abbandonano e se il sito stia svolgendo o meno la sua funzione commerciale.

Il quarto errore aggiuntivo che merita una menzione è non curare la conformità normativa del sito: molti siti nuovi vengono lanciati senza informativa sulla privacy, senza informativa sui cookie, senza condizioni d’uso o senza altri documenti obbligatori ai sensi del GDPR e delle altre norme applicabili, e questa disattenzione può avere conseguenze legali serie, comprese sanzioni fino a 20 milioni di euro o al 4% del fatturato annuo mondiale complessivo dell’azienda — a seconda di quale sia l’importo più alto. La conformità non è soltanto un requisito formale: è anche un segnale di affidabilità per i Suoi visitatori, perché mostra quanto prende sul serio la protezione dei loro dati e la loro riservatezza, e i consumatori di oggi guardano sempre più spesso a come le aziende trattano i loro dati personali.

ES
Edijs Stikuts
Titolare · Webmasters
Contatti →
FAQ

Domande frequenti.

Quanto dura di solito un progetto di realizzazione di un sito web?

Da 4 a 8 settimane per un sito vetrina semplice di 5–10 pagine, da 2 a 4 mesi per un sito aziendale di media complessità con funzionalità su misura. Una piattaforma di e-commerce complessa o un’applicazione web richiede dai 4 agli 8 mesi. La scadenza la fissano il perimetro e la complessità, non la velocità di chi sviluppa. In quei mesi rientrano anche la fase di analisi e pianificazione, la preparazione dei contenuti e i test, e non soltanto design e programmazione: gli errori nella realizzazione di un sito web che fanno slittare il calendario si commettono quasi tutti qui, mentre si aspettano testi e immagini, e non nella programmazione. Le scadenze troppo strette non si guadagnano lavorando più in fretta, si comprano a scapito della qualità, di solito saltando i test, le basi della SEO o la revisione dei contenuti.

Come faccio a valutare la qualità del lavoro di chi sviluppa se non sono tecnicamente competente?

Controlli quattro cose che non richiedono competenze tecniche: la velocità dei lavori precedenti, come si comportano sul telefono, l’esperienza dei clienti passati e con quanta chiarezza chi sviluppa risponde alle domande su sicurezza e SEO. La velocità la misura gratis Google PageSpeed Insights: il punteggio dovrebbe superare gli 80 punti sia sulla versione mobile sia su quella desktop. La resa responsive la verifica da sé, aprendo sul telefono e sul tablet i siti che ha realizzato. Ai clienti precedenti chieda del rispetto delle scadenze, di come è andata la collaborazione e dell’assistenza dopo la consegna: è lì che le differenze emergono più in fretta. E alla fine ponga domande concrete sulle pratiche di sicurezza, sull’approccio alla SEO e sulle condizioni di manutenzione: chi è competente le spiega in un linguaggio comprensibile, invece di rispondere con termini che chiudono la conversazione.

Mi serve uno sviluppo su misura o una soluzione pronta su una piattaforma CMS?

Dipende dalle esigenze specifiche della Sua attività, dal budget e dai piani a lungo termine. Le piattaforme CMS come WordPress sono un’ottima scelta per la maggior parte delle piccole e medie imprese, perché offrono un ampio ecosistema di plugin, costi di sviluppo e manutenzione relativamente bassi e molta flessibilità nella gestione dei contenuti, e circa il 40% di tutti i siti del mondo usa WordPress. Lo sviluppo su misura è giustificato nei casi in cui i Suoi processi aziendali richiedono funzionalità uniche non ottenibili con gli strumenti standard di un CMS, oppure quando ha requisiti molto elevati di prestazioni, sicurezza o scalabilità, ma di norma è sensibilmente più caro sia in sviluppo sia in manutenzione.

Quali sono i segnali di allarme di un fornitore inaffidabile?

Tre segnali bastano per fermarsi: chi sviluppa evita il contratto scritto, si rifiuta di dare i contatti di clienti precedenti oppure insiste perché il dominio venga registrato a proprio nome. Altrettanto chiara è l’offerta troppo bella per essere vera: un prezzo estremamente basso o una scadenza irrealisticamente breve significano che qualcosa non è incluso, e lo scoprirà più tardi. Diffidi anche di chi parla soltanto di design e non sa rispondere alle domande su sicurezza, prestazioni e SEO, di chi non sa spiegare quale tecnologia userà e perché, o di chi si rifiuta di confermare che consegnerà infrastruttura e dati su richiesta. Infine valuti la comunicazione prima del contratto: se già in fase di preventivo le risposte alle email si fanno attendere giorni, durante il progetto peggiorerà quasi di sicuro.

Quanto devo essere coinvolto nel processo di sviluppo?

Il coinvolgimento del committente è di importanza critica per la riuscita del progetto, ma deve essere strutturato e mirato, non caotico e continuo. Nel caso ideale partecipa attivamente alla fase di analisi e pianificazione, portando informazioni sulla Sua attività, sul pubblico di riferimento e sugli obiettivi; partecipa con regolarità alle riunioni di avanzamento, in cui chi sviluppa mostra il lavoro svolto e riceve i Suoi riscontri; prepara e consegna in tempo i contenuti e i materiali necessari; e svolge test di accettazione accurati prima del lancio. Allo stesso tempo è importante fidarsi della competenza professionale di chi sviluppa sulle questioni tecniche e non intervenire a livello di microgestione negli ambiti in cui non ha conoscenze sufficienti. In quelle riunioni (consigliabile una volta a settimana o una volta ogni due settimane) fornisce riscontri consolidati, invece di mandare commenti e correzioni frammentari ogni ora, cosa che rompe il flusso di lavoro di chi sviluppa e rallenta il progetto. Ricordi che il Suo ruolo di committente è assicurare che il sito risponda alle esigenze della Sua attività e alle aspettative del Suo pubblico, mentre il ruolo di chi sviluppa è trovare la soluzione tecnica migliore per realizzarle: questa divisione dei compiti è la base di una collaborazione sana e produttiva.

SERVIZIO CORRELATO
Realizzazione di siti WordPress

WordPress che i redattori amano e gli sviluppatori non maledicono. Blocchi Gutenberg, ACF Pro, WPML e Wordfence — per oltre 50 clienti. Lavoriamo con WordPress da più di 20 anni: blocchi e campi su misura, migrazioni da Drupal, Joomla o da versioni precedenti, hardening dei sistemi secondo OWASP e ricerca interna migliorata.

Scopra di più →