Qualche info
Un lettore del blog, che mi ha chiesto di non essere citato, mi scrive un commento molto interessante:
Una collega qualifica come banale un’applicazione interna, custom, che fornisce soluzione completa alla gestione (devo rimanere sul vago).
Tecnicamente parliamo di un’applicazione web a 3 livelli, con interfacciamenti e ramificazioni estese, costati 8 anni a 15-20 persone tra consulenti esterni e staff interno. Costo running ad oggi: sulla milionata di euro all’anno.
Poi mi sono reso conto che lei si riferiva all’utilizzo dell’applicazione. Il che nobilita la qualità del prodotto. Ma allo stesso tempo crea un problema di banalizzazione. Non sarà che i criteri di usabilità del software, se perseguiti con troppo successo creano una falsa percezione di facilità dell’informatica tout court?
Alla fine non era forse meglio (per chi ci lavora) quando l’informatica era una cosa per pochi, difficile anche da usare?
Il tema e la provocazione finale sono molto intriganti. Spesso la facilità d’uso e la semplicità non fanno percepire all’utente lo sforzo fatto per ottenere quelle qualità.
E forse, l’ignoranza delle tecnologie che abbiamo in Italia, non fa che accrescere questo problema, facendole passare sempre come dei prodotti di massa e di consumo, senza coglierne invece la complessità e il valore.
If you enjoyed this article, please consider sharing it!
Prof,
credo che nell’informatica come nello sport o nell’arte si diventa veramente bravi nel momento in cui si fanno cose difficilissime e gli altri le vedono come semplici. Vale per l’O di Giotto, per i gol di Romario, per la “mano lenta” di Eric Clapton e pure per il software. Percio’ io se fossi il suo lettore sarei orgoglioso: ha ricevuto il miglior complimento.
Se la collega non è del settore non c’è da stupirsi. Non è facile per l’utente comprendere cosa c’è dietro ad un semplice click del mouse. Aggiungo che, nonostante i software sono sempre più usabili, la loro complessità in termini di funzioni fornite cresce col passare del tempo e questo non li rende molto pù semplici da usare rispetto ai loro equivalenti di 10 anni fa.
nunzio, il punto è che sono complimenti solo per noi, ma non per gli altri: se fai una cosa percepita come banale, non ti pagano.
gli utenti di turno magari fanno bene il proprio lavoro e si mettono in bella vista grazie all’applicazione fatta bene. Chi l’ha fatta no.
solo una curiosità 8 sono gli anni uomo? in caso contrario (inizio del lifecycle nel 2001 per intenderci) si potrebbe capire la perplessità dell’utente finale.
Non so dirti. Ho riportato quello che mi ha scritto. Se leggendo la tua domanda mi riscrive, lo posto.
Il tema, a mio avviso, rappresenta il classico problema della realizzazione di uno strumento (o servizio): affinché sia fatto bene e sia utile (in tutti i sensi) deve essere semplice ed intuitivo. Essendo il suo scopo quello di coadiuvare in una attività, la sua complessità deve essere quanto più trasparente e nascosta.
Ovviamente questo comporta che l’utente non percepisca lo sforzo implementativo richiesto (ciò che “ci sta dietro”).
Il punto é: chi realizza un sistema di questo genere deve esserne contento o no?
Personalmente ritengo di sì, indipendentemente dal riconoscimento che gli viene dato, in quanto non riuscirei a concepire di progettare un sistema di uso complesso solo per far vedere quanto sia grande il mio sforzo. D’altro canto capisco anche lo scoramento di chi si vede banalizzato il proprio lavoro (e, magari, sottopagato il che è più grave).
Sicuramente, come dice Alfonso nell’ultima riga, una maggiore cultura in campo tecnologico potrebbe aiutare, ma, personalmente, spero in un mondo in cui il valore di qualcosa sia valutato per i benefici che ne si traggono e non dalla percezione della complessità che vi sta dietro o davanti. Anche perché, nella storia, ci sono invenzioni realmente banali che hanno cambiato il mondo ma che non hanno richiesto immani sforzi, se non quello, a mio avviso immenso, di averci pensato.
Putroppo è ben nota la legge che una applicazione più è semplice per l’utente, più è complesso il lavoro degli sviluppatori.
I commerciali devono lottare sempre con i clienti contro questo equivoco. Chiedono una cosa per loro semplice, ovvia, ma non tale per il computer. E si sbalordiscono davanti al preventivo.
Volendo continuare il discorso, anche i capi progetti devono lottare contro i commerciali che vogliono prezzi più bassi per non perdere l’affare.
[...] alfonsofuggetta.org » Blog Archive » Semplice vuol dire banale? (tags: società) [...]
Il problema dal mio punto di vista è da un lato il time to market (non possiamo progettare oggi e andare in produzione dopo 4 anni) e dall’altro il rispetto di tre requisiti di base: funzionalità, prestazioni e sicurezza.
Come sempre il lavoro ingegneristico è quello di trovare il migliore compromesso tra questi fattori.
Dal punto di vista commerciale l’offerta dovrebbe enfatizzare meglio
questi aspetti.
Gianca,
non a caso i veri artisti spesso muoiono in miseria, mentre non ho mai sentito di un direttore commerciale morto in miseria
C’est la vie!
Non condivido la visione romantica del progettista che lavora per la gloria. Un progetto di successo richiede risorse adeguate.
Una scorretta valutazione della complessità di un progetto è un grosso problema non solo per chi il progetto l’ha creato ma anche per chi l’ha commissionato.
Se un progetto è sottovalutato il committente tendenzialmente gli assegnerà poche risorse fino a farlo magari morire.
Questo causa un impoverimento di tutto il sistema.
Se un buongustaio pretende di pagare un tartufo come fosse una patata scompariranno tutti i cercatori di tartufi. E allora non gli resterà che mangiare patate per il resto della vita.
sono d’accordissimo con Matteo Rota e il paragone dei tartufi.
guardate che in fondo lo stipendio è anche status, cioè consenso sociale. Nessuno cerca la vana gloria.
Sulla provocazione finale, devo dire che è ciò su cui gioca molto Oracle (e a quanto dicono anche SAP, ma io conosco bene solo la prima). A mio avviso i loro prodotti sono molto più complessi da usare di quello che potrebbero essere, oppure sono mal documentati. Sostiene una collega: “non sono i prodotti Oracle ad essere bacati, sono le guide che sono incomplete, e se non lo fossero tu non lavoreresti”.
Il motivo di questa scelta è che più un software è difficile da usare/configurare, più consulenza ci gira intorno e la consulenza si vende bene. Inoltre la consulenza stessa vende il prodotto: io lavoro come consulente e i nostri clienti comprano quello che noi proponiamo. Oracle è ciò che proponiamo perché una volta che lo hai vendito ti dà da mangiare a lungo, perché il cliente ha sempre bisogno di modifiche, customizzazioni, attività di gestione, monitoraggio, etc. Tutte attività per nulla semplici. Se i prodotti fossero user friendly, facili da configurare e usare, noi non lavoreremmo e quindi non li proporremmo.