Ogni progetto di software è il frutto di un compromesso

Quando si avvia un nuovo progetto, i diversi attori che prendono parte al lavoro hanno un’idea personale di quale sarà l’output finale del software in cantiere, ma questa immagine mentale spesso è destinata a mutare, revisione dopo revisione. Scopriamo perché.

Dal momento in cui qualcuno decide di mettere in atto il pensiero desidero realizzare un software che si occupi di…, inizia un processo trasformativo che, proprio come l’Evoluzione ci insegna, riguarda più l’adattarsi alle condizioni circostanti contingenti che il concetto di perfezione in senso assoluto.

Questo accade perché tutte le figure professionali e i soggetti coinvolti nella realizzazione difendono le rispettive posizioni, talvolta incompatibili.
Presa da punti di vista differenti ciascuna posizione ha le sue ragioni: tutti desiderano semplicemente raggiungere un risultato qualitativamente alto secondo la loro particolare visione, che può riguardare prestazioni, marketing, ergonomia d’uso o altro.
Tuttavia questo incontro di necessità diverse deve necessariamente tendere a soluzioni di compromesso, pena l’impossibilità di raggiungere l’obiettivo, ovvero la realizzazione del software.

Queste posizioni possono confluire in una lunga lista di necessità, tecniche e strategiche, ripartite tra quattro figure principali: l’utente, il cliente, il programmatore e lo UX/UI designer.
Per suggerire una riflessione sulla complessità e sulla fondamentale mediazione insite nella progettazione del software, di seguito propongo una panoramica generale di alcune di queste necessità e dei conflitti nei quali possono incorrere.

L’utente

In linea teorica, le sue necessità dovrebbero essere il primo obiettivo di ogni designer e programmatore che affrontano la realizzazione di una web app, di una app mobile o di qualunque altro software.
Dopotutto il concetto di user experience (UX) ruota attorno alla figura dell’utente, ovvero l’individuo che dovrà utilizzare il software.

A condizione di budget e tempo illimitati sarebbe un traguardo già più verosimile; in presenza di deadline e limiti monetari invece, la software house che dirige la progettazione deve accettare che non è sempre possibile adottare le soluzioni più utili per l’utente in tutto e per tutto.
Questi due fattori significano meno tempo per ideare componenti e funzionalità ad hoc. Ne consegue un uso preponderante di componenti già disponibili (le cosiddette librerie), che molto spesso aiutano a snellire il lavoro, ma che non sono sempre adatti a gestire tutte le situazioni.

Altre volte, il committente esprime la volontà dichiarata di limitare o escludere determinati benefici all’utente del suo software, per ragioni strategiche, di ideologia aziendale o perché ci sono policy legali imposte, che impediscono ai progettisti di implementare certe funzionalità.

Paradossalmente – e per loro sfortuna – gli utenti sono la categoria che più facilmente vedrà ignorate parte delle sue necessità. Questo perché è abbastanza comune da parte di aziende e sviluppatori decidere di non coinvolgerli nella stesura dei requisiti con questionari e analisi adeguate, per tagliare i tempi e i costi di breve periodo. È una pratica non priva di conseguenze e che ci sentiamo di sconsigliare, siccome può nascondere esigenze determinanti le quali, se ignorate, possono comunque emergere durante le fasi avanzate di sviluppo con costi di implementazione che a quel punto risultano più alti.

Il cliente

Il primo obiettivo del cliente è vedere il software finito per poterne beneficiare.
Sul piano progettuale questo obiettivo implica necessità che possono toccare il branding delle interfacce, l’aggiunta di elementi propedeutici al marketing, vincoli imposti dalle scelte tecnologiche precedenti, collaborazioni del team con il personale interno e le già citate esigenze legali e ideologiche.
Ovviamente, corretto funzionamento e qualità del software si possono considerare come prerequisiti imprescindibili – per il cliente come per i progettisti – ma è importante sottolineare come questi aspetti, per certi versi, possano deteriorarsi lungo il corso della progettazione a causa di condizioni esterne non sempre arginabili, che possono agire sia sul breve che sul lungo periodo. Di seguito ne riportiamo qualche esempio.

Quando inizia la collaborazione, il cliente deve essere aperto alle nuove modalità lavorative per il management di progetto introdotte dalla software house.
Trovare un punto d’incontro con la nuova metodica, affidandosi alla competenza della software house e adottando una forma mentis ricettiva, eviterà che gli obiettivi di rinnovo vengano inibiti dal timore di stravolgere alcune abitudini aziendali sedimentate negli anni.
Dopotutto fare innovazione significa migliorare accogliendo e adattandosi a ciò che è nuovo.

Superate le eventuali frizioni di metodo, le aspettative del cliente devono subito allinearsi alle sue disponibilità economiche (ecco un altro articolo se vuoi sapere perché costa tanto sviluppare un software).
Come per gli utenti, il budget impone immediatamente delle limitazioni anche al cliente, determinando il livello di scrupolosità che verrà riservato al progetto.

Sul piano tecnico invece, il cliente potrebbe disporre di tecnologie che non consentono di sviluppare la migliore soluzione software possibile che lui – o la software house – aveva in mente. I motivi possono essere tanti: infrastrutture di rete particolari, tecnologie datate o hardware poco compatibili con le ultime innovazioni.
Problemi analoghi si presentano anche quando un nuovo progetto deve dialogare con un altro software già esistente. Oppure quando il cliente richiede uno stack tecnologico particolare, diverso da quello normalmente adottato dalla software house.

Se gli utenti sono i primi a essere ignorati, è altrettanto vero che quando non c’è più spazio per il compromesso – anche posti davanti a evidenti ragioni per fare altrimenti – i progettisti fanno ciò che chiede il cliente, perché lui paga.
Questi scenari comportano sempre delle conseguenze, ma di fronte a un diktat, designer e programmatori possono solo limitarsi a presentare le possibili complicazioni future e poi procedere.
È bene far presente che queste conseguenze talvolta precludono l’integrazione di nuove funzionalità in maniera parziale o totale e, più in generale, scavalcare il parere tecnico degli esperti può comportare l’insorgere di criticità che sottrarranno tempo al team e di conseguenza toccheranno il portafoglio del cliente.

Il programmatore

Che si tratti del front end o del back end, il codice non determina solamente l’aspetto del software ma letteralmente il suo comportamento e il modo in cui funziona, come un ingranaggio.

Le prime necessità dei programmatori sono assicurarsi che questo motore funzioni nel migliore dei modi e che la sua manutenzione futura risulti agevole con il minor dispendio di tempo possibile, per diminuire stress, malfunzionamenti e costi.
In realtà, parte di questi aspetti è perseguita anche dal cliente, ma è comune che le deadline e il budget conducano alla frizione tra committente e programmatore, che non si ritrovano nei metodi con i quali ottenere questi risultati.

Per garantire questi benefici il codice deve essere semplice, ben studiato, commentato e affrontato razionalmente, con una visione globale del progetto e di tutti i componenti che faranno parte del software.
Questo si traduce nell’adozione delle già citate librerie online. Le librerie sono pacchetti di svariati componenti dal look personalizzabile e adattabili a necessità diverse.
Purtroppo, per mantenere questo livello di qualità, la libertà di personalizzazione non è sempre abbastanza elevata da consentire l’integrazione di ogni singola richiesta dei clienti o degli UX/UI designer.

Il terreno di scontro è trovare un equilibrio tra la salvaguardia della qualità del codice e le necessità di utenti, cliente e designer che spesso comprendono personalizzazioni particolari, che deteriorano la chiarezza del codice a vantaggio però della user experience, del marketing, del branding e dell’armonia visiva.

Lo UX/UI designer

Un designer è sempre alla ricerca di una soluzione formale adeguata agli obiettivi di progetto. Non è solo una questione di dare forma a qualcosa di bello: chi si occupa di grafica – a prescindere dal settore di applicazione – si preoccupa anche della coerenza e della consistenza del suo prodotto creativo.

Per garantire un buon risultato, quando si parla di software, il designer segue una serie di regole, consuetudini, buone norme progettuali e accorgimenti logici.
Per lui è necessario assicurarsi che le interfacce e le interazioni siano tra loro coerenti, ordinate, comprensibili ed esteticamente conformi a quanto ci si aspetta da un servizio professionale.

Come accennato nella sezione precedente, può capitare che le sue soluzioni front end risultino in contrasto con i limiti imposti dai programmatori: certe minuzie (abbinamenti di colori, disposizione di testi, margini, animazioni, ecc.) a volte richiedono un livello di personalizzazione delle librerie di componenti tale da mettere a rischio la manutenibilità del codice, rendendo quelle scelte poco convenienti sul lungo periodo.

Altre volte le idee del designer necessitano la programmazione di componenti completamente nuovi e come si è già accennato, se il budget non è sufficiente, il team è costretto scegliere una strada alternativa.
Ed è così che le migliori soluzioni potenziali di UX/UI si trasformano, passando dall’essere ideali a reali.

Si presentano anche situazioni nelle quali la visione del designer non è condivisa dal cliente – in toto o parzialmente – e questo può portare a un confronto accanito in cui ogni parte motiva la propria posizione per convincere l’altra ad adottare la soluzione che ritiene migliore, si tratti di accostamenti di colore, forme, disposizioni, meccaniche di interazione, ecc.

Le necessità entrano in conflitto

È irrealistico pensare di poter far convivere tutte queste esigenze in un software senza sacrificarne alcune. Dalla fase di analisi, alla prototipazione, fino allo sviluppo, ogni giorno i progetti incontrano nuove restrizioni che si stratificano e che conducono il team di lavoro a mediare costantemente.
L’obiettivo è sempre ottenere il meglio: ogni volta che si presenta un nuovo limite occorre trovare la soluzione migliore che sia il meno possibile in contrasto con quanto già progettato.

In passato la tua azienda ha già affrontato una situazione di questo tipo? Sei certo che a lavoro finito il compromesso tra le necessità delle parti coinvolte sia stato equilibrato? Se vuoi scambiare due parole assieme a noi, contattaci e vieni a prendere un caffè presso il nostro ufficio.