Technology Experience

Contenuti gestiti da Igor Damiani
posts - 949, comments - 2741, trackbacks - 15120

My Links

News

  • Questo blog si propone di raccogliere riflessioni, teoriche e pratiche, su tutto quello che riguarda il world-computing che mi sta attorno: programmazione in .NET, software attuale e futuro, notizie provenienti dal web, tecnologia in generale, open-source.

    L'idea è quella di lasciare una sorta di patrimonio personale, una raccolta di idee che un giorno potrebbe farmi sorridere, al pensiero di dov'ero e cosa stavo facendo.

    10/05/2005,
    Milano

Archives

Post Categories

Generale

Lavorare e sviluppare per piccoli clienti

Non so chi di voi ha lavorato o lavora tuttora con piccoli clienti, ai quali bisogna sviluppare applicativi più o meno complessi e più o meno disegnati intorno a loro e alle loro esigenze. Ho lavorato per parecchi anni con questo tipo di clientela, quando ero dipendente (e più giovane ed inesperto). Oggi come libero professionista faccio le cose un po' diversamente: innanzitutto ormai non mi capita più che qualcuno mi chiami per farmi sviluppare un software (devo dirlo: per fortuna!). Lavorare per i piccoli clienti comporta una serie di svantaggi che sempre più spesso mi hanno disturbato e mi hanno fatto passare la voglia di sviluppare in questo ambito.

La prima cosa che mi viene in mente è che spesso ai clienti non gliene frega niente dall'interfaccia utente : o meglio, se aprono bocca su questo tema, è solo per far peggiorare la qualità della vostra applicazione. Noi sviluppatori andiamo matti se sentiamo parlare di ribbon, griglie sortabili, clic destri, drag'n'drop o altri controlli più o meno sofisticati. Al cliente non gliene frega nulla. Lui vi farebbe fare un'applicazione bianco e nero, con pulsanti grandi e con un font fuori standard.

In secondo luogo, il cliente tende sempre a farvi creare un'applicazione su misura per lui : questo è piuttosto pericoloso, perchè voi potreste in realtà creare un software da poter proporre e rivendere anche ad altri, ma se lasciamo carta bianca al cliente finale è finita. Mi capita sempre più spesso di avere clienti che non vogliono alcun campo obbligatorio nell'inserimento di un certo qualcosa: fatture senza il numero, anagrafica senza un nome oppure altre questioni più subdole che magari costringono a cablare nel codice un qualche concetto palesemente stringente. Questioni che magari fanno parte del dominio applicativo, e che di conseguenza possono sfuggire se non padroneggiate bene il contesto e il mondo del cliente. Non è da trascurare nemmeno il lato economico: non sempre un singolo cliente può sobbarcarsi il costo di un software completo, progettato esclusivamente su di lui. Per questo ritengo sempre davvero importante che durante tutte le fasi di realizzazione di un software è bene pensare a generalizzare sempre il problema, e non a cablare le cose in base a quello che ci viene detto. Se un cliente ci obbliga a fare qualcosa, piuttosto è bene prevedere una schermata di opzioni dove è possibile settare a piacimento determinati comportamenti. Se lavorate come liberi professionisti, questo assume un'importanza determinante: run once, deploy everywhere è il motto che mi sono inventato una volta. Scrivete una volta sola il programma, ma distribuitelo ovunque. Altrimenti, lo ripeto, siamo fottuti. Non so se capita anche a voi, però una delle prime cose che faccio quando installo un'applicazione (freeware/shareware/altro) è cercare una finestra Tools-->Options per vedere che grado di flessibilità offre. Alzi la mano chi di voi fa la stessa cosa nelle proprie applicazioni Windows Forms. Io a dir la verità un po' pochino, ma dove la implemento, la differenza si sente, e parecchio anche. Questo comporta il fatto che magari lavoriamo in perdita con il committente iniziale, ma potremo rifarci se sviluppiamo in modo intelligente.

Un altro fattore chiave è la confidenza che si ha nei confronti del cliente, nel senso di familiarità ed amicizia. Mi viene in mente la disavventura di Simone ed il suo vecchio provider: il fatto di avere un certo tipo di rapporto, induceva il provider a comportarsi in un certo modo, a discapito della qualità del servizio erogato. Inoltre, un cliente quasi amico telefona anche la sera, magari a casa, chiedendo di venire il sabato per sistemare questo o quello, con la scusa di "andiamo a berci una Coca-Cola", oppure di fare una chiaccherata. Difficile dire di no in questi casi. Il tutto molte volte condito con quella sensazione di cui ho già parlato in altre occasioni, dove "tanto fare programmi è semplice", o "click è bello". Pensiamoci. Anche perchè un conto è se lavoriamo a tempo pieno per i nostri clienti, un altro è (come nel mio caso) creare software dopo aver lavorato tutto il giorno su altre cose.

powered by IMHO 1.2

Print | posted on giovedì 6 luglio 2006 20:00 | Filed Under [ Sviluppo .NET ]

Feedback

Gravatar

# re: Lavorare e sviluppare per piccoli clienti

"La prima cosa che mi viene in mente è che spesso ai clienti non gliene frega niente dall'interfaccia utente ...", forse a volte non vogliamo ascoltare davvero il cliente e non vogliamo capire davvero le esigenze del cliente e ci sentiamo un pò archiettetti e un pò artisti. Sono fermamente convinto che il cliente non ha mai le idee chiare su qllo che vuole e sul come lo vuole ma è altrettando vero che il cliente nella maggior parte dei casi non gli frega nulla di opere d'arte che solo un occhio fino saprebbe valutare e stimare. La tendenza del dev a volte è quella di mettere in vetrina tutto il potenziale di una tecnologia, veri e propri esercizi di stile dove si vanno a realizzare tutte le figure che si conoscono... ma in realtà credo sia giusto sforzarsi e anche violentarsi nell'usare solo quello che all'utente davvero serve... my 2 cents
06/07/2006 20:50 | M.rkino
Gravatar

# re: Lavorare e sviluppare per piccoli clienti

"il cliente tende sempre a farvi creare un'applicazione su misura per lui ..." mi sembra normale; ti pago per farmi un software e quindi lo fai su misura per me. Le regole di business sono del committente e non del programmatore non ha senso impporsi su sue regole... al più gli si fanno notare i possibili problemi. Ha senso - a mio avviso - dire che mentre realizzi un sofware provi a vedere lungo e cerchi di realizzazione/astrarre un pacchetto tuo rivendibile/riusabile... ma la cosa non deve pesare sul committente.

Giudico che le cose cambiano se tu offri un tuo pacchetto già pronto che è customizzabile ma ovviamente entro certi limiti, sta al committente accettare i limiti imposti.
06/07/2006 21:00 | M.rkino
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET