Fabio Carucci's WebLogs

Interessante il post, ma deve fare riflettere, la colpa è solo dei clienti? io penso che a volte è anche colpa di qualche improvvisato programmatore, che visto il suo orgoglio pensa di sapere tutto.
Ti faccio un esempio pratico, prendi per esempio, un dottore? hai mai sentito dire un dottore, mi parli in modo chiaro e magari in termini medici?
Il mio, almeno, mi ascolta, ed altrettanto faccio così con i clienti, li ascolto, faccio vedere delle slide, ecc, in modo che il cliente ha molta chiarezza.
Una volta, sentivo un mio collega, parlare di un cliente, che non sapeva cosa vuol dire zippare, bene, ma se il cliente è un infermiere, o impiegato comunale, che del computer ne vuole sapere il meno possibile, mi sembra normale, che non conosca i termini informatici, mentre nel suo campo (flebbo o prescrizione, ecc) ne sappia più di noi.
Il problema invece sta in quei programmatori (che spesso fanno danni) che si improvvisano tecnici.
Sapessi quante volte ho preso il lavoro di "colleghi" informatici, pieni di inefficenza, bug, scarsa documentazione ed altro ancora.
Il tuo post è ottimo, ma per migliorare il nostro campo, devono cambiare prima i tecnici.
Te lo dice uno, che di software ne ha viste tante, dai ministeri alle società internazioni, dal piccolo sofware del negozio, ai crm di milioni di record.
Sapessi, quante nottate ho fatto (parlo oltre le 23) per sistemare gli errori di alcuni programmatori.
Certo, ci sono anche clienti, che se la tirano, ma io preferisco parlare non solo con i capi, ma anche con gli utilizzatori del software, e credimi, solo in questo modo ottieni i software migliore, quello che rispetta il suo compito, quale? quello di ottimizzare i processi lavorativi.
Che dirti, speriamo che tra qualche anno, ci siano programmatori più bravi e clienti più sapienti :-)))
Ciao Emanuele

mi viene da pensare che il cliente dovrebbe cambiare non la-ricetta-di-raccolta-dei-requisiti-di-nonna-papera ma semmai il suo atteggiamento/disposizione MENTALE nei confronti dei consulenti IT. Il cliente non ammetterà la sua ignoranza (d'altronde non può perchè non ne è consapevole) e non è tenuto ad imparare niente di nuovo. Forse esagero ma nella consulenza, qualunque essa sia, esiste una sottile e invisibile forma di "pago io, quindi comando io, che te ne piaccia o no". Se così fosse la parola "consulenza" o "consulente", visto il significato originario del termine latino, non è per nulla adatta.
Purtroppo oltre ai ciclo di sviluppo e alla scrittura del software dobbiamo preoccuparci di diffondere il vangelo e spiegare tutte le parabole. Ci tocca, non abbiamo scelta. Beati coloro che fanno software in-scatola che si vende negli iperstore. Forse guadagnano meno, ma possono evitare almeno certi sbattimenti

Scusate il ritardo nella risposta ai vostri commenti ma ho avuto un problema con il vecchio skin del blog che non permetteva di far apparire i feedback nei post.

Avete ragione entrambi, però da una parte ci sono diverse realtà aziendali che non sanno ciò che vogliono ma ti presentano un documento in cui pensano di aver scritto e spiegato tutto (e se ti basi solo su quello vai alla fine sicuramente a litigare) e tu, se hai buon senso ed esperienza, non ti fidi ciecamente e ti metti ad intervistarli; dall'altra ci sono realtà aziendali IT che fungono da cliente e che "dovrebbero" sapere come si redige un doc dei requisiti, te lo consegnano e ti dicono che quello è oro colato, tu ti fidi perchè pensi che chi te l'ha dato probabilmente ne sa più di te e invece...

Quello che volevo dire nel post, più che altro, era riferito anche alle modalità di analisi e design che vengono dopo il doc dei requisiti, voi che esperienza avete in proposito?

ciao Fabio, per me l'analisi come anche la documentazione, leggibilità del codice, e commenti, sono elementi di base, senza di essi non si può iniziare.
L'analisi a mio avviso, va fatta insieme al cliente e va fatta bene, perchè ne risentirà il progetto. Ho sempre detto, meglio spendere un giorno in più in analisi che 100 nello sviluppo del codice.
L'analisi oltre ad individuare le necessità del cliente, deve tener conto di diversi fattori, come gli eventuali problemi, e funzionalità che possono tornare utili in futuro, ossia anche eventuali migliorie che si potranno fare in futuro (copreso l'evolversi tecnologico).
Oggi, però, spesso, l'analisi, non si fa come si dovrebbe, si pensa che rispiarmando tempo, si ottengono benefici nello sviluppo, ma così poi non è.
La documentazione va fatta, sia tecnica che informativa, quella per l'uso dell'applicativo. Tengo a precisare che va redatto anche un documento di test, nella fase del rilascio.
Ciao Emanuele