Che cosa succede tra la decisione e la pubblicazione: i passi della realizzazione di un sito web

Il contratto è firmato, l’acconto è stato versato, e poi cala il silenzio. L’azienda aspetta che compaia il sito web, lo sviluppatore aspetta i testi e le fotografie, e nessuno dei due pensa di stare aspettando proprio la stessa settimana, quindi un mese dopo entrambe le parti sono insoddisfatte e nessuna delle due ha sbagliato nulla; semplicemente nessuno aveva scritto chi consegna che cosa, e entro quale data.

Questo articolo riguarda che cosa succede tra la decisione e la pubblicazione, e soprattutto la divisione del lavoro tra le due parti, perché è quella a decidere il termine molto più spesso della velocità dello sviluppo o della tecnologia scelta. Degli errori dei committenti abbiamo già scritto a parte, nell’articolo sui dieci errori da evitare nella realizzazione di un sito web, e qui non li ripetiamo. Non ci sono neppure prezzi, né un confronto tra il fai-da-te e la commissione, perché entrambi appartengono ad altri articoli: qui si parla soltanto della sequenza e di che cosa, a ogni passo, va preparato.

La fase di discovery non è l’inizio della costruzione

Quasi ogni processo di sviluppo comincia con una fase chiamata di discovery o di analisi, ed è proprio questa la fase che si capisce più spesso male, perché il committente la tratta come una formalità prima del lavoro vero. Nielsen Norman Group, che usa il concetto in senso professionale, la definisce come una fase preparatoria in cui si indaga il problema stesso e il suo contesto, si formula che cosa è risolvibile e si raccolgono prove sufficienti per sapere che cosa fare dopo, e sottolinea proprio che nella discovery non si verificano le soluzioni.

Nel settore pubblico questa idea è formalizzata in modo ancora più rigido, perché il Service Manual del Government Digital Service britannico distingue cinque fasi, cioè discovery, alpha, beta, esercizio e ritiro, e della discovery scrive in modo semplice: in questa fase non si comincia a costruire il servizio. Alla fine della fase il team decide se andare avanti o fermarsi, e il manuale stesso non impone una durata fissa, anche se indica che in pratica questa fase dura di solito da quattro a otto settimane.

Qui va fatta subito una precisazione, altrimenti nasce un’immagine sbagliata: quel manuale descrive il ciclo di vita di un servizio digitale dello Stato, non il sito aziendale di dieci pagine, e trasferirne i tempi a un progetto di realizzazione ordinario sarebbe fuorviante. Ciò che conta è il principio, non il calendario: prima della costruzione c’è una fase il cui scopo è capire il compito, e l’esito di questa fase può essere anche la decisione di non costruire affatto.

In un progetto concreto questa fase prende di solito la forma di una conversazione su processi, ruoli degli utenti e perimetro, e il risultato è un piano scritto, non uno schizzo di design, anche se il committente spesso vorrebbe vedere proprio il secondo. Per il committente ne seguono due conseguenze dirette, e la prima è che senza un esito scritto della discovery più tardi non c’è semplicemente nulla con cui confrontare ciò che è stato costruito, quindi una disputa sul perimetro resta senza prova per entrambe le parti. La seconda è che proprio in questa fase cambiare idea costa poco, mentre dopo l’inizio della costruzione ogni modifica costa anche ciò che è già stato costruito e che andrà rifatto.

Il prototipo è il punto più economico in cui cambiare idea

Tra il piano e la costruzione c’è una fase che i committenti a volte ritengono una spesa superflua, ed è proprio la fase che più spesso fa risparmiare. Il prototipo è una versione cliccabile del sito senza il codice vero, in cui si possono percorrere i cammini principali e vedere dove manca qualcosa, e il suo unico scopo è permettere di cambiare idea finché cambiare idea è ancora economico.

Il manuale del governo britannico lo dice senza giri di parole, scrivendo della fase alpha che bisogna mettere in conto che tutto il codice scritto in questa fase e gran parte delle idee verificate, alla fine della fase, verranno scartati, e ciò non contraddice un buon lavoro, ma ne è il senso: scartare un prototipo è economico, scartare un sistema già costruito no. Alla scala di un sito aziendale lo stesso principio opera in misura minore, ed è proprio per questo che prepariamo il prototipo prima della prima riga di codice di produzione.

Per il committente ne segue un requisito pratico, che conviene dire ad alta voce: l’approvazione del prototipo non è una crocetta formale, ma l’unico momento in cui le modifiche costano soltanto tempo, quindi è proprio allora che conviene chiamare al tavolo le persone che più tardi diranno che nessuno ha chiesto loro nulla. Dopo l’approvazione del prototipo ogni conversazione di quel tipo costa già ciò che è stato costruito.

L’altra cosa che in questa fase conviene è il contenuto in bozza, perché un prototipo con testo segnaposto si approva facilmente e poi si scopre che i testi veri non ci stanno, o che a una sezione cui era destinato un paragrafo in realtà ne servono tre. Se i testi non sono ancora pronti, nel prototipo conviene mettere almeno bozze di lunghezza all’incirca giusta, perché la lunghezza cambia l’impaginazione più di qualunque colore.

La maggior parte dell’attesa sta dalla parte del cliente

Il termine di un progetto lo decide il più delle volte non la velocità dello sviluppo, ma quanto in fretta il committente consegna i contenuti, e nella nostra esperienza è la causa più frequente di ritardo. Nel settore non esiste su questo un’indagine indipendente con una metodologia e una data, quindi lo diciamo come nostra esperienza e non fingiamo che dietro ci siano delle percentuali.

Qui conviene fare un’altra precisazione, altrimenti questa sezione suonerebbe come uno scarico di colpe: nel settore pubblico la produzione di contenuti è una professione distinta e un ruolo di squadra, e nel manuale del governo il progettista di contenuti figura tra le competenze necessarie, ma da ciò non segue che in un progetto di realizzazione ordinario i testi li scriva lo sviluppatore. Chi li scrive è una questione di accordo, e l’unica risposta sbagliata è che nessuno l’abbia chiarito prima dell’inizio del lavoro.

In concreto, dalla parte del committente ci sono di solito cinque consegne, e a ciascuna conviene già nel contratto assegnare una data precisa, invece di lasciarla al livello della conversazione. La prima è quella dei testi, ed è la più pesante di tutte, perché non si scrivono in una sera e di solito li scrive una persona per la quale scrivere non fa parte del lavoro principale e che deve farli entrare tra gli altri doveri. La seconda sono le fotografie e i logotipi in formato vettoriale, la terza gli accessi ai sistemi esistenti, se da quelli va spostato qualcosa, la quarta le approvazioni in punti definiti del progetto, e la quinta, che non è un documento ma una persona, è un solo approvatore che a nome dell’azienda può dire di sì.

Questa quinta è quella che manca più spesso, e la sua assenza costa più di qualunque complicazione tecnica: un progetto in cui l’approvazione la dà un comitato si allunga non perché qualcuno lavori male, ma perché ogni approvazione chiede una riunione, le riunioni si tengono una volta ogni due settimane, e tra l’una e l’altra il lavoro sta semplicemente fermo. Se in azienda ci sono più parti interessate, la soluzione giusta non è tentare di escluderle, ma accordarsi su chi di loro è il decisore finale e in quale termine si attende una risposta.

In Italia non esiste una norma equivalente che nomini il capo dell’istituzione come responsabile dei contenuti del sito ufficiale. A un’azienda privata comunque non è vincolante, ma l’idea è la stessa e si può adottare volontariamente: la responsabilità dei contenuti appartiene al committente, e va messa in capo a una persona concreta, con nome e cognome.

Le immagini sono una questione di diritti, non di file

Le fotografie sono il punto in cui i committenti agiscono con le migliori intenzioni e tuttavia creano un rischio, perché si dà per scontato che il file che sta sul computer sia anche un file che si può usare. Nella legge 22 aprile 1941, n. 633, le opere fotografiche sono opere protette, il diritto d’autore sorge con la creazione dell’opera senza alcuna registrazione, e l’autore è la persona che ha scattato l’immagine.

Ne segue una conclusione che sorprende quasi ogni azienda: il pagamento di un servizio fotografico, da solo, non significa che il committente abbia acquisito i diritti patrimoniali. Il fotografo resta l’autore, i diritti morali, tra cui il diritto di essere nominato, sono inalienabili, e i diritti patrimoniali passano soltanto con una licenza o una cessione, che va provata per iscritto; per un’azienda che intende usare le fotografie sul sito, sui social e in stampa, ciò significa che nella licenza o nella cessione vanno elencati proprio questi modi d’uso.

Con le banche di immagini è esattamente lo stesso, soltanto che lì le condizioni sono scritte in modo chiaro e pubblico, quindi si possono leggere prima dell’acquisto: la licenza Standard di Shutterstock concede un diritto non esclusivo e non trasferibile di usare l’immagine, anche sui siti web, e nella stessa pagina è detto che il cliente non ottiene né la proprietà né diritti esclusivi. Lì stanno anche i limiti che si finisce per violare per sbaglio: l’immagine non si può girare ad altri, non si può usare come logotipo o marchio, e le immagini contrassegnate per solo uso editoriale non si possono usare in modo commerciale. Un’azienda che ha comprato una licenza Standard ha ottenuto il diritto di usare l’immagine sul sito, non un file da consegnare allo sviluppatore come cosa propria.

C’è un altro caso che si capisce quasi sempre male. La legge sul diritto d’autore non contiene una libertà di panorama che copra l’uso commerciale: l’articolo 70 consente il riassunto, la citazione o la riproduzione per critica, discussione, insegnamento o ricerca, non per un sito aziendale. Un sito web di un’azienda è un uso commerciale, quindi quella norma non lo copre, e per un’immagine con l’edificio o la scultura di altri serve ancora l’autorizzazione.

Infine, le persone nelle immagini sono una questione di dati personali, non soltanto di cortesia: ai sensi del regolamento (UE) 2016/679 la fotografia di una persona identificabile è un dato personale, e la base giuridica può essere il consenso o il contratto; il consenso deve essere libero, specifico, informato e inequivocabile. Il punto pratico più importante è che il consenso si può revocare in qualsiasi momento, e dopo la revoca le immagini vanno rimosse dall’ambiente pubblico, quindi le fotografie del team sul sito vanno organizzate in modo che un dipendente che se ne va non diventi un problema.

L’ambiente di staging e l’errore che si fa con le migliori intenzioni

Prima della pubblicazione il lavoro avviene in un ambiente separato, e serve per un motivo semplice: il committente deve vedere una pagina vera in un browser vero, non un’immagine da uno strumento di design, e gli errori vanno presi in un luogo in cui i clienti non li vedono. La domanda è soltanto come chiudere questo ambiente, ed è proprio qui che si fa un errore che sembra corretto.

La soluzione diffusa è inserire un divieto nel file robots.txt, e non fa ciò che la gente crede, perché la documentazione di Google lo scrive in modo diretto: questo file indica ai crawler a quali indirizzi possono accedere, e serve principalmente a non sovraccaricare il sito di richieste, ma non è un meccanismo per tenere una pagina fuori da Google. Perché una pagina non compaia nei risultati di ricerca, va usata la regola noindex oppure l’ambiente va protetto con una password.

Poi viene il dettaglio per cui i due metodi insieme funzionano peggio di ciascuno da solo. La regola noindex opera soltanto se la pagina è accessibile al crawler, perché il crawler deve leggerla; se la pagina è vietata nel file robots.txt, il crawler quella regola non la vedrà mai, e la pagina può comunque comparire nei risultati, per esempio se vi portano link da altrove; inoltre Google non supporta affatto una regola noindex nel file robots.txt.

C’è anche un secondo motivo per cui questo non è un problema teorico, cioè se l’ambiente di staging contiene gli stessi contenuti del sito finito, il motore di ricerca può ritenere proprio quello la versione principale e mostrarlo nei risultati al posto del Suo sito, il che significa che il visitatore atterra su una pagina incompiuta con dati di prova. Questo errore è difficile da notare, perché il sito stesso funziona in modo impeccabile e il problema si vede soltanto nei risultati di ricerca.

La risposta pratica è quindi semplice, e conviene chiederla in modo diretto: l’ambiente di staging si protegge con una password. È l’unica soluzione che, indipendentemente dal comportamento dei crawler, assicura che un sito incompiuto non compaia da nessuna parte, e allo stesso tempo toglie il secondo rischio, a cui si pensa più di rado, cioè che un ambiente di staging con gli stessi contenuti possa essere ritenuto la versione principale e cominciare a competere con il sito vero.

Quali scelte dopo la pubblicazione costano di più

La maggior parte delle decisioni in un progetto di sito web si può cambiare anche dopo la pubblicazione, e conviene dirlo con chiarezza, perché i committenti spesso si preoccupano proprio delle cose che più tardi si cambiano con più facilità. Colori, impaginazione, modello, testi e persino la posizione delle pagine nel menu si possono cambiare praticamente in qualsiasi momento, e ciò costa soltanto ore di lavoro, non una ricostruzione, ma due cose sono diverse, ed è proprio su quelle che conviene pensare prima della pubblicazione, finché il cambiamento non costa ancora nulla.

La prima è la struttura degli indirizzi, e diventa una decisione proprio nel momento in cui le pagine sono indicizzate e vi portano link esterni, perché da quel momento cambiare gli indirizzi non è più una scelta visiva, ma uno spostamento del sito, che Google descrive come una procedura distinta, con requisiti propri. Vanno usati reindirizzamenti permanenti lato server e vanno conservati almeno un anno; Google avverte anche di non cambiare in un colpo solo gli indirizzi, il sistema di gestione dei contenuti e l’impaginazione, e per un sito aziendale ordinario consiglia di spostare tutti gli indirizzi in una volta sola, non a pezzi; nella stessa pagina c’è una nota utile che riduce la paura: i reindirizzamenti permanenti, di per sé, non causano una perdita di PageRank, anche se le posizioni per un po’ possono oscillare.

La seconda è il dominio stesso, perché il cambio di dominio è lo stesso spostamento del sito con tutti i suoi requisiti, soltanto su scala più grande, e vi si aggiunge tutto ciò che è già stampato su biglietti da visita e carta intestata. A nome di chi va intestato il dominio abbiamo scritto nell’articolo sui dieci errori da evitare nella realizzazione di un sito web, e qui non lo ripetiamo; qui vale soltanto dire che la scelta del dominio è una delle poche decisioni che più tardi costa più cambiarla che farla giusta subito.

C’è un dettaglio di procedura che conviene conoscere per non chiederlo senza bisogno: la notifica di cambio di indirizzo negli strumenti del motore di ricerca si presenta soltanto se cambia il dominio o il sottodominio; per il passaggio da una connessione non sicura a una sicura, o per la scelta tra un indirizzo con e senza il prefisso www sullo stesso dominio, non è prevista, e lì bastano i reindirizzamenti corretti. Per un’azienda ciò significa che la maggior parte delle modifiche si sistema lato server, non in un modulo.

In pratica ne segue un consiglio prima della pubblicazione: se il sito vecchio esiste già e ha visitatori dai motori di ricerca, l’elenco degli indirizzi con i reindirizzamenti verso i nuovi va preparato prima della pubblicazione, non dopo che qualcuno nota il calo delle visite. Questo elenco è anche uno di quei lavori che il committente può preparare da sé, e che, se nessuno lo prepara, dopo la pubblicazione diventa una settimana di lavoro di ricerca.

Accessibilità: per chi è un obbligo e per chi no

Per le amministrazioni pubbliche l’accessibilità è un obbligo già da diversi anni; per un’azienda privata — soltanto se fornisce un servizio elencato dalla legge, il più delle volte il commercio elettronico, e non è una microimpresa. Un sito vetrina che non vende nulla non entra in quell’elenco; un’azienda con un fatturato medio, negli ultimi tre anni, superiore a cinquecento milioni di euro è però già vincolata, anche se il sito non vende nulla. Sul mercato questi due atti si confondono spesso, ed è un errore che costa.

Il primo riguarda il settore pubblico, ed è in vigore già da diversi anni, quindi per le amministrazioni non è una novità. La direttiva dell’Unione europea sull’accessibilità dei siti delle pubbliche amministrazioni è recepita in Italia dalla legge 9 gennaio 2004, n. 4, come modificata dal decreto legislativo 10 agosto 2018, n. 106, che chiede di rispettare quattro principi, cioè che i siti siano percepibili, utilizzabili, comprensibili e solidi, e di pubblicare una dichiarazione di accessibilità distinta. Questo regime vincola le amministrazioni e, dal 15 settembre 2020, anche i soggetti privati che offrono servizi al pubblico tramite siti web o applicazioni con un fatturato medio, negli ultimi tre anni di attività, superiore a cinquecento milioni di euro; un’azienda privata ordinaria sotto quella soglia resta fuori, anche se sul mercato a volte lo si propone come un requisito generale.

Il secondo è più recente, ed è proprio quello che genera la maggior parte dei malintesi, perché la data di applicazione è stata ampiamente annunciata, il perimetro no: l’atto europeo sull’accessibilità è recepito in Italia dal decreto legislativo 27 maggio 2022, n. 82, che si applica ai prodotti immessi sul mercato e ai servizi forniti a far data dal 28 giugno 2025. Ciò non significa che da quella data ogni sito aziendale debba rispettare uno standard di accessibilità, ed è proprio questa affermazione troppo larga quella che il mercato ripete più spesso, a volte insieme all’offerta di rimediare.

Il decreto riguarda un elenco preciso di servizi, non qualunque sito, e vi rientrano i servizi di comunicazione elettronica, i servizi che danno accesso ai servizi di media audiovisivi, determinati elementi del trasporto passeggeri aereo, con autobus, ferroviario e per vie navigabili, i servizi bancari per i consumatori, i libri elettronici e i servizi di commercio elettronico. Un sito vetrina aziendale che non vende nulla e non è una banca, un operatore di trasporto o una piattaforma di libri, in questo elenco non entra.

C’è anche un’esenzione per le imprese piccole, e va formulata con precisione, perché spesso la si racconta troppo larga. L’impresa che occupa meno di dieci persone e realizza un fatturato annuo non superiore a due milioni di euro oppure un totale di bilancio annuo non superiore a due milioni di euro, e che fornisce un servizio rientrante nel perimetro del decreto, è esentata dall’obbligo di rispettare i requisiti di accessibilità dei servizi. L’esenzione riguarda i servizi; gli obblighi legati ai prodotti, per le microimprese, sono più leggeri ma non cancellati, quindi la frase secondo cui le microimprese sono esentate dalla legge non è corretta.

La conclusione pratica per il committente è breve: se sta realizzando un e-commerce e non è una microimpresa, i requisiti di accessibilità vanno scritti già nel capitolato, perché più tardi significano una rielaborazione. Se sta realizzando un sito vetrina, un obbligo giuridico da quel decreto, di regola, non c’è — salvo il caso, raro in questo mercato, dell’azienda sopra la soglia di cinquecento milioni della legge n. 4 — ma resta comunque un argomento perché la pagina sia usabile con la tastiera e leggibile con un lettore di schermo, perché una parte dei Suoi clienti li usa indipendentemente dalla legge.

Quanto tempo richiede tutto questo

La domanda sul termine è quella a cui il committente vuole una risposta per prima, ed è anche quella a cui una risposta onesta è più difficile da dare. I termini pubblicati nel settore vengono quasi sempre dalle pagine degli sviluppatori stessi, dove servono da promessa di velocità, quindi non si possono usare come un dato indipendente, e un’indagine indipendente con una metodologia non l’abbiamo trovata.

Perciò è più corretto parlare di che cosa decide il termine, piuttosto che cercare un numero medio che comunque non andrebbe bene per nessun progetto concreto: il termine lo decidono il perimetro, la velocità delle approvazioni e la prontezza dei contenuti, e negli ultimi due di questi tre l’influenza decisiva sta dalla parte del committente. Un progetto in cui i testi sono pronti prima dell’inizio e le decisioni le prende una sola persona procede in modo sensibilmente più rapido di un progetto dello stesso perimetro senza queste due condizioni, ed è una differenza che si misura in settimane.

Il termine che pubblichiamo noi sulla pagina della realizzazione di siti WordPress è da quattro a dieci settimane, e riguarda un sito aziendale ordinario, mentre per i progetti più complessi è più lungo, e per l’e-commerce ancora più lungo, ma per un progetto concreto l’unico termine utile è quello che segue dal perimetro, non da un indicatore medio.

C’è un altro modo di guardare a questa domanda, e per il committente di solito è più utile di qualunque cifra: chieda allo sviluppatore non quanto ci vorrà, ma quali settimane dipendono da Lei e quali da lui. La risposta a questa domanda è verificabile, e mostra subito quanto del termine controlla Lei.

E un’altra cosa che sul termine pesa più di quanto sembra è l’aumento del perimetro in corso d’opera: ogni nuovo suggerimento, da solo, è piccolo e fondato, ma insieme spostano la data di consegna, e succede senza che si noti, perché nessuno di essi sembra mai una decisione di allungare il progetto. L’unica cosa che serve è l’accordo che le modifiche fuori dal perimetro iniziale si annotano a parte, insieme al loro effetto sul termine, invece di includerle in silenzio.

Che cosa concordare prima che il lavoro cominci

Prima della prima riga di fattura conviene discutere e mettere per iscritto un calendario dei contenuti con le date: chi scrive i testi, entro quale data sono nelle mani dello sviluppatore e che cosa succede se arrivano in ritardo, perché senza questo punto il ritardo sembra sempre colpa dello sviluppatore.

Il secondo è l’origine delle immagini e i diritti, cioè da dove vengono le fotografie, quale licenza hanno, se nella licenza è citato l’uso proprio sul sito e se le persone nelle immagini hanno dato un consenso che più tardi possono revocare. Il terzo è un solo approvatore con nome e cognome, e un accordo su in quanti giorni lavorativi si attende la risposta a una richiesta di approvazione, perché senza un termine l’approvazione non è una grandezza pianificabile.

Il quarto è un ambiente di staging protetto con una password, non con un divieto nel file robots.txt, e il quinto è l’elenco dei reindirizzamenti dai vecchi indirizzi ai nuovi, se il sito vecchio esiste già e ha visitatori. Il sesto è la domanda sull’accessibilità, la cui risposta dipende da che cosa fa il Suo sito, e che è molto più economico porre nel momento in cui si scrive il capitolato che dopo la consegna.

Questo elenco conviene esaminarlo in una sola conversazione, non a pezzi, perché proprio insieme mostra quanto del progetto dipende dal committente, e di solito è più di quanto il committente si aspettasse. Nessuno di questi requisiti è costoso, e nessuno chiede competenze tecniche; chiedono soltanto che qualcuno li ponga prima dell’inizio del lavoro.

E il settimo, che non è tecnico ma decide più degli altri sei: l’accordo su quale sia il perimetro minimo con cui il sito si può pubblicare. Un progetto in cui si pubblica soltanto quando è pronto tutto tende a non pubblicarsi mai, mentre un progetto con un perimetro minimo chiaro si pubblica in tempo e poi cresce. Se vuole che facciamo questa conversazione insieme a Lei, Ci scriva.