Claudio Brotto

Quello che il cliente percepisce

Un paio di giorni fa ho avuto una discussione interessante con un mio amico (nonchè sviluppatore), durante un breve viaggio in treno.
Discussione piuttosto di ampia portata, di cui però riporto un estratto specifico.
Contesto: lui sta sviluppando un'applicazione, abbastanza complessa, sia dal punto di vista architetturale che da quello puramente "algoritmico": multi-tier, calcoli matematici piuttosto pesanti, ecc...
L'osservazione sulla quale ci siamo trovati d'accordo è che l'utente finale (e di conseguenza il cliente, che può coincidere con l'utente o essere un suo fornitore) ha una percezione completamente diversa della complessità di un sistema software rispetto alla nostra (noi == "i programmatori-analisti-blablabla").
Innanzitutto difficilmente l'utente è in grado di differenziare i componenti di un'applicazione: un client-server monolitico e la UI di un sistema ultra-stratificato si avviano sempre con un doppio click su di un'icona del desktop. Scusate l'estrema banalizzazione ma penso che rappresenti bene il concetto per cui l'utente ha, generalmente, conoscenze informatiche basse, o comunque non sufficientemente raffinate per riuscire a riconoscere le interazioni fra i tier del sistema che abbiamo disegnato ed implementato. (E non è tenuto ad averle, sia chiaro).
Corollario: il programma E' la sua interfaccia utente.
Corollario del corollario: modificare un algoritmo matematico complicatissimo ha un peso paragonabile all'aggiunta di una combo-box di lookup in una maschera.
Sto estremizzando.
Però seguitemi nel ragionamento ...
Ponendo sullo stesso livello attività così diverse, sia come difficoltà che, di conseguenza, come tempi necessari ad implementarle, si pongono sullo stesso livello gli sviluppatori che le realizzano.
Mi spiego meglio: il mio amico si lamentava del fatto che per realizzare gli algoritmi di cui sopra fossero necessarie conoscenze matematiche avanzate, ma che queste non fossero percepite dal cliente nel momento in cui questo compra il prodotto (e paga chi lo realizza).
Che, detta in altri termini, è: "Perchè io, che mi sono fatto il **** 5 anni all'università per imparare i misteri della matematica più avanzata, trovo un caso in cui senza queste conoscenze il problema è irrisolvibile, applico le mie conoscenze e lo risolvo, alla fine vengo valutato e pagato come uno che si legge in 2 settimane un libro su C#, si inventa programmatore riempiendo l'interfaccia utente di controlli colorati e disomogenei e mette qualche effetto speciale nel suo programma (tipo gli ErrorProvider controls, x esempio) ?
La risposta che gli ho dato io (che per inciso non ho neanche un decimo delle sue competenze in campo matematico e fisico) è che dipende tutto dalla percezione che il cliente ha del prodotto che gli si propone e che lui paga.
Credo che questo sia vero, ma se qualcuno avesse qualche obiezione per smentirmi, vi giuro, ne sarei veramente contento !!!
Posted: ott 06 2006, 07:53 by devlizard | with 1 comment(s)
Filed under:

Comments

marco said:

Faccio un parallelo generale.
Se pensi a un prodotto "per le masse", il ragionamento è vero. Se pensi a un prodotto "per intenditori", il ragionamento è falso.
Se in quel prodotto la parte matematica è indispensabile, difficilmente un prodotto bellissimo che ne fosse privo si potrebbe vendere.
Insomma: è inevitabile che sia così. Hai chiesto al tuo amico se quando compra un qualsiasi prodotto (dal latte a un mobile a un cavatappi) si chiede se ha idea del valore che c'è dietro?
Il tuo ragionamento, però, svela un particolare importante: così come oggi nessuno comprerebbe più un telefonino che non abbia anche un minimo di design, così nessuno ormai pensa di valutare un programma a prescindere dalla sua interfaccia utente. Avere persone specializzate in grafica e usabilità dell'interfaccia sarà sempre più una necessità. Questo l'hanno capito sul web, ma su Windows nessuno l'ha ancora compreso appieno, soprattutto in Italia.

Marco
# ottobre 7, 2006 12:44