I veri tempi del web development

Ormai da più di un decennio Internet brulica di siti e servizi di ogni genere, esistono tool e portali per qualsiasi gusto e necessità, eppure molte persone sottovalutano ancora le dinamiche complesse che scandiscono la progettazione di un software web. Questo succede fra i privati ma anche fra le aziende.

I software sono un gioco da ragazzi: falso

Se è vero che oggi i computer sono più potenti di dieci anni fa e che abbiamo molte più risorse dalle quali attingere per strutturare progetti legati al web (framework, librerie di componenti, CMS, plugins, grafiche stock, ecc.), è altrettanto vero che questo ecosistema digitale ha sviluppato enormemente la sua complessità. Questa evoluzione è arrivato a tal punto da richiedere una significativa esperienza professionale da parte di un esperto per poter valutare con cognizione di causa quale strada percorrere per cimentarsi nella progettazione di un software, che sia destinato a un’azienda già avviata o a un neo imprenditore che desidera farne un core business.

La natura pervasiva della tecnologia, le app mobile, i social network con i loro influencers e le storie di successo di startup dai toni sensazionalistici hanno alimentato, in alcune persone, la convinzione che tutto sommato commissionare un software e attivare un’iniziativa imprenditoriale online ad esso correlata – e di successo – non sia così difficile. Pochi ci provano davvero, forse per semplice disinteresse ma, a prescindere da questo, tanti ne sottovalutano la difficoltà.
Per captare parte di questo sentire, in termini più ampi, è sufficiente seguire alcuni dei contenuti di Marco Montemagno (forse il più noto web guru italiano degli ultimi anni), il quale ha affrontato temi legati proprio al rapporto fra imprese, professionisti e tecnologia, portando a galla, fra gli altri, le criticità, le cattive abitudini dure a morire e le convinzioni errate che contraddistinguono il DNA lavorativo italiano.

Molte aziende che offrono soluzioni prefabbricate pronte all’uso (come il CMS Wordpress con i suoi plugin, per fare un esempio fra tanti) hanno contribuito a diffondere l’idea di un mercato del web accessibile a chiunque, in quanto il tool che ci occorre per monetizzare – e lasciare il lavoro che non ci piace poi così tanto – è a portata di mano, come un hamburger al fast food. Ed è così, ma solo in teoria…

Nella pratica, spesso i due temi rimossi da questo racconto ricorrente sono: uno, che l’accesso facile a questi strumenti pronti all’uso non garantisce le competenze per saperli adoperare con efficacia; due, quanto tempo e quanto impegno richiede davvero la progettazione e la calibrazione di un sistema che sia realmente tagliato su specifiche esigenze imprenditoriali, in termini tecnici e commerciali (quindi non solo in linea teorica, in potenza). E soprattutto, che funzioni concretamente.

Il quadro che ne emerge – quantomeno nell’esperienza di Dreamonkey – è una generalizzata percezione distorta di cosa comporti concretamente la strutturazione di uno strumento online – o di un vero e proprio business – in termini temporali.
Quindi affrontare lo sviluppo di una web app o di una app mobile cosa significa?

La realtà dietro allo sviluppo di un software

Dalla scelta delle tecnologie da utilizzare (hai già individuato il framework da utilizzare nel tuo progetto?), alla configurazione delle infrastrutture di rete che accoglieranno il software web, fino alle competenze di design per conferirgli un volto professionale, ogni progetto ha ben poco di banale o di rapida esecuzione.
Senza menzionare la costruzione del brand e delle strategie di marketing che, pur non essendo necessariamente collegate al workflow tecnico di progettazione, restano indispensabili per portare un buon servizio online all’attenzione dei suoi potenziali utenti (quando il software non è esclusivamente ad uso interno di un’azienda, s’intende).

C’è molta inconsapevolezza quanto alla progettazione del back end (le strutture che gestiscono i dati mostrati nelle interfacce) e delle infrastrutture (i server che accolgono e rendono disponibile il servizio online) delle quali il software non può quasi mai fare a meno.
Il problema è che la maggior parte delle persone non ha cognizione di queste strutture perché, quando interagisce con un software, non le vede materialmente – a differenza dell’interfaccia – e di conseguenza non è cosciente della loro importanza, di quanto tempo occorra per strutturarle e renderle operative, sicure e stabili.

Quello del web development – includendo anche analisi e prototipazione – è un processo fatto in gran parte di comunicazione e di scelte, oltre che delle ovvie mansioni tecniche sopracitate. Le scelte portano via molto tempo perché determinano la qualità dei risultati e comportano una buona dose di responsabilità. Nessuno desidera prendere decisioni sbagliate che influiranno negativamente sugli obiettivi di progetto, sui costi di manutenzione o sulla redditività del software.

Ma di che scelte stiamo parlando esattamente? Principalmente preliminari, riguardanti quella fase di progetto in cui cliente e progettisti si siedono a un tavolo per pianificare come funzionerà e che aspetto avrà il software, cercando di prevedere quanti più dettagli è possibile.
Quali funzionalità dovranno essere implementate, come verrà brandizzata l’interfaccia, come verrà gestito lo scambio dati tra client e server, chi redigerà la privacy policy per la GDPR, quali accordi verranno presi per il rilascio open source dei componenti, a chi verrà affidata la manutenzione e così via.
Disporre a monte la cosiddetta analisi dei requisiti e dare forma alle interfacce attraverso prototipi statici è un modo per prefigurare l’identità del servizio e arrivare alla programmazione con le idee chiare.
Questo metodo consente di contenere i costi di lungo periodo (es. la manutenzione della piattaforma) e di ridurre le incertezze che insorgono lanciandosi direttamente nello sviluppo, senza un’adeguata pianificazione.
Naturalmente non tutti i progetti condividono le stesse dinamiche decisionali: di solito, il livello di responsabilità assegnato alla software house dipende dalla competenza tecnica del cliente o dalla sua volontà di delegare incombenze (strategiche, di usabilità, ecc.) per le quali non ha tempo.

Il confronto con il cliente ha anche scopo informativo: il team deve sapergli presentare e motivare le proposte progettuali che precedono lo sviluppo vero e proprio e deve tenerlo aggiornato sui progressi fatti, ogni volta che è necessario.
A volte la comunicazione può richiedere più tempo, ad esempio quando il dialogo ha luogo fra committenti senza competenza diretta in ambito informatico e i tecnici.

La necessità di lavorare in team aggiunge un grado di complessità: più professionisti significa più competenza, ma queste capacità devono coordinarsi, con conseguente dilatazione dei tempi di progetto.

Perché i tempi effettivi sono lunghi

Progetti particolarmente complessi possono portare via anche parecchi mesi, se non addirittura un anno o più (è il caso di piattaforme davvero ramificate che ricevono integrazioni costanti, progressivamente).
A livello teorico, le mansioni del team di progettazione possono essere stimate in termini di ore o giorni di lavoro ma, di solito, questi non vengono mai condensati in una finestra temporale ristretta e senza interruzioni. I tempi si allungano per ragioni di ordinaria amministrazione che raramente è possibile arginare. Facciamo qualche esempio.

Per quanto riguarda la software house incaricata della progettazione:

• nonostante l’arrivo del nuovo progetto, deve comunque continuare a garantire una certa disponibilità settimanale agli altri clienti con i quali lavora, o ha lavorato;
• un membro del team potrebbe finire in malattia;
• potrebbe coinvolgere dei collaboratori esterni dei quali si avvale e che, a loro volta, devono fare i conti con il loro time management personale;
• in corso d’opera, potrebbe imbattersi in una release inattesa delle tecnologie adottate per lo sviluppo, vedendosi costretta ad aggiornare il codice ai nuovi requisiti, prima di proseguire.

Dal lato cliente invece, che ci siano uno o più project manager:

• potrebbero dedicare molti giorni alla riflessione prima di prendere decisioni importanti riguardanti aspetti del progetto portati alla loro attenzione dal team;
• potrebbero dilungarsi nel far consegnare al team i materiali che sono necessari per procedere con i lavori (testi, dati, immagini, documenti, file, ecc.);
• potrebbero coinvolgere nella progettazione anche il personale interno, che dovrà dialogare con il team della software house e gestire anche altre mansioni estranee al progetto;
• potrebbero compiere delle scelte e rimetterle in discussione tempo dopo, determinando significativi cambiamenti a catena;
• potrebbero non riuscire a partecipare alle sedute di revisione dei lavori, posticipandole, a causa di altri impegni aziendali più impellenti;
• potrebbero essere sollevati dall’incarico, a causa di riorganizzazioni aziendali, costringendo il team ad aggiornare il nuovo sostituto sui progressi fatti;
• potrebbero andare in ferie o in malattia, sospendendo la supervisione.

La deformazione delle aspettative ha delle conseguenze

In Dreamonkey siamo fermamente convinti che apprendere le dinamiche che reggono il settore dello sviluppo software sia un buon anticorpo contro l’idea che si possa fare tutto, semplicemente schioccando le dita. Convincersi di questa immediatezza non raggiungibile crea un’aspettativa che può spingere le aziende, credendo erroneamente di risparmiare tempo e budget, ad appoggiarsi alle promesse discutibili di certi “progettisti”. Maturare la consapevolezza che un buon software nasce dalle scelte di un’attenta pianificazione e da un paziente percorso di prototipazione è il primo passo per ottenere il massimo.

Se stai pensando di realizzare una web app o una app mobile e desideri saperne di più, scrivici, io e il resto del team siamo a disposizione.