Olimpo Informatico

[chemicalbit]

Ma questo cliente è cliente diretto del fornitore di hosting,
o il fornitore di hosting fornisce a voi, che a vostra volta fornite il cliente?

[freemind]

Il nostro cliente è cliente diretto del fornitore di hosting che è anche il nostro fornitore.
In pratica:
- noi ci appoggiamo a questo tizio per lo spazio web
- il cliente si appoggia a questo tizio per lo spazio web
- noi ovviamente facciamo da tramite tra lui e il tizio.
Dati tutti i problemi che ci sono stati però sia noi che il nostro cliente vogliamo cambiare...

[zeross]

Alla fine la morale è sempre quella:
Il buon programmatore deve essere capace di scrivere codice, pulito, efficiente, compatto e veloce.
Non può pensare di essere nella testa del suo cliente, non puo sapere quanto il suo cliente-committente sia incapace di fare il suo lavoro, sia incapace di esprimersi non in technichese, bensì anche solo in italiano.
Non può sapere se il suo committente abbia poche idee molte confuse nel suo cervello. Il committente addirittura potrebbe avere al posto del cervello, due criceti che si rincorrono su una ruota.
Per il programmatore sapere queste cose è assolutamente inutile.
Deve essere capace di tradurre concetti confusi in un progetto software usabile dal cliente finale.
Se poi il cliente finale vuole modifiche apre il portafoglio, paga il lavoro di modifica e sta zitto che non si lavora bene con questo baccano!
E il cliente utilizzatore che prima deve fare una pianificazione del suo lavoro e sapere cosa gli serve e come gli serve.

Parlo per esperienza diretta, essendo stato in servizio all'ospedale Grassi di Ostia tra il 2002 ed il 2004 presso il centro trasfusionale dove era in corso le procedure per ottenere la certificazione di qualità ISO 9000.

Ed ora vi chiederte cosa centra questo con tutto ciò?

Per gestire informaticamente la raccolta del sangue si usa un programma della INSIEL chiamato EMONET, sviluppato su oracle.
Questo programma prevede di ottenere i report, di effettuare gli inserimenti, le modifiche, gli accessi secondo delle particolari procedure.
Il programma e stato acquisito nel 1999. La certificazione ISO9000 nel 2003.
Ebbene quando si e trattato di stabilire a fini della certificazione ISO le procedure da applicare per una corretta ed efficiente gestione del Centro Trasfusionale, si e visto che tutta una serie di cose presenti in emonet non andavano bene, con tutti i giganteschi problemi di modifica che tutti voi avete fatto notare prima sono necessari per modificare un DB, le query, i report, come vengono presentati e dio solo vi lascia pensare a tutto il casino che seguiva.
E non stiamo parlando di piccoli sviluppatori per piccole aziende.

Domanda logica: ma non ci potevano pensare prima di fare il programma di chiedere quali soluzioni implementare? Si pero se tu prima non sai quali soluzioni decidi di usare non puoi dire qualcosa di preciso al programmatore non si può sognare quali procedure vanno seguite in un centro trasfusionale.

Se poi il capotecnico del reparto, crede di essere un esperto di informatica, perche sa fare una macro in access, e tu ti rifiuti ideologicamente di supportarlo perche ti diverti a vedere figure barbine, quando si esprime con gerghi tecnici che non conosce ed ancora meno comprende, ed il commerciale che parla con te deve fare la traduzione italiano-napoletano nel suo cerebro per comprendere quello che gli dici, e poi telefona ad udine alla sede della INSIEL senza inserire il traduttore napoletano-italiano dicendo: uee ueè guagliò a ca sta 'no problema!
Tengono la queri ke non gli entra, e quando gli entra non gli riporta quello che vonnò!
potete comprendere come il povero programmatore che risponde al telefono possa avere tutta la vostra umana e professionale comprensione.

La morale e una sola, se uno viene a chiedere qualcosa deve essere preciso altrimenti non possiamo ridurci alle scene di totò in trasferta a milano che scimmiotta un po il francese un pò l'italiano per farsi comprendere dal vigile.


Se si continua dire che bisogna mettersi nei panni dell'utente, si deresponsabilizza quest'ultimo che non si impegnera mai a fare uno sforzo per venire incontro alle esigenze del programmatore!


Se ho torto ditemelo

[madvero]

hai torto

[zeross]

[madvero]

io non ho detto niente...

[develop]

io faccio programmi direttamentamente per gli utenti.
ci sono tanti problemi:
L'utente non ha mai chiaro all'inizio quello che vuole (ammesso che riesca a spiegarlo), però tu devi progettare il database, e sono guai se è progettato male. Quindi con la tua esperienza devi capire cosa serve al tuo utente.
Una volta fatti i programmi l'utente comincia a chiarirsi le idee e quindi chiede altre cose che comportano sempre modifiche, oltre che ai programmi, anche al database. E questo comporta più lavoro che la costruzione del programma originale
Inoltre i programmi vanno testati e anche questo comporta più tempo che fare i programmi.
E poi le modifiche non finiscono mai.
A volte hai a che fare anche con persone con i loro limiti di comprensione e di carattere.
Poi hai da fare la documentazione che va conmtinuamente aggiornata con le modifiche.
Chi spiega all'utente quanto costa un programma?

[dany88]

Ho letto quasi tutti i reply, ma nessuno ha mai tirato in ballo le due paroline magiche: Ingegneria del software, un esperto o due in questo campo (che generalmente è anche programmatore) in un team di developer, risolve il 90% dei problemi

[marcOpera]

Io ho la fortuna di poter avere rapporti diretti con la clientela, senza la presenza di alcun filtro - serie di filtri, che normalmente non fanno altro che introdurre nuove variabili impazzite e di ardua gestione.

Ogni passaggio che implica la spiegazione di qualcosa a qualcun altro comporta la proliferazione di problemi di comprensione.

La cosa migliore è riuscire a parlare con chi fisicamente effettua il lavoro, lasciando per i colloqui con il boss dell'azienda per la quale si sta lavorando la sola parte economica.

Inutile tentare di farsi spiegare le procedure necessarie dall'AD, che di solito è già buono se conosce le dinamiche che governano il suo Blackberry tanto fico, ma con i tastini tanto piccolini, "e io che non sono più giovanissimo non vedo più una mazza da vicino"

Lasciamo il capo dei capi a giocare con il suo gingillo tecnologico, e andiamo in officina a vedere da vicino cosa si vorrebbe gestire.

Secondo me l'approccio ideale è quello che avrebbe un bambino di quattro anni: curiosare, curiosare e ancora curiosare, stare con il fiato sul collo degli addetti e fare tante domande che cominciano con "Perché questo, perché quello...".

A stare sul campo si vedono un sacco di cose che altrimenti nessuno si sarebbe ricordato di dirti, e ci si scontra con un sacco di problemi pratici di cui nessuno si sarebbe accorto, se non al momento della consegna di un accrocco che appena installato mostra subito il uso approccio troppo teorico al problema.

In officina si potrebbe scoprire che il personale addetto magari non ci vede tanto bene da vicino (un po' come il boss, ricordate?), quindi è inutile fornirgli un lettore di barcode portatile economico sì, ma con uno schermo grande come un francobollo e con i caratteri size 6.

Si scopre che la codifica utilizzata dal fornitore nei suoi documenti di consegna fa a pugni con quella gestibile dal programma aziendale.

Si scoprono decine di "casi particolari", vero incubo del programmatore, che anche con tutta la buona volontà è impossibile ricondurre ad una norma ferrea.

Si scopre che anche la più semplice procedura contabile è fatta in un modo che "piace tanto al nostro commercialista", ma che ovviamente comporta delle variazioni a ciò su cui l'altro 99,99% della clientela non ha mai avuto da dire.

Ci si scontra con procedure fiscali/amministrative di cui non si aveva la più pallida idea dell'esistenza.

Si comincia a pensare a come risolvere i problemi che via via prendono contorni più netti, avendo ben chiaro quali sono i mezzi di sviluppo a disposizione ed i loro eventuali limiti, lavoro che sicuramente non può fare un analista che son dieci anni che usa solo più Word e Excel

Si prendono appunti che poi si butteranno giù in bella copia, e con gli stessi si tornerà in loco per verificarli nuovamente con gli interlocutori che avevano esposto le metodologie da seguire.

Se poi si ha la fortuna di incappare in un utente che ha una forma mentis molto schematica, il lavoro del programmatore ne esce particolarmente avvantaggiato.

Poi ci sono i trucchetti "psicologici": entrare nelle grazie di chi userà i tuoi programmi è estremamente importante, eviterà un sacco di problemi futuri.

"Coprite" un errore che è stato commesso dall'utente, e vi sarete guadagnati un amico, che probabilmente vi permetterà a sua volta di rimediare a qualche vostra magagna senza fare troppo rumore

Mentre raccogliete informazioni, non dimenticate di complimentarvi con l'interlocutore per ogni cosa intelligente che dirà, o per ogni soluzione pratica che potrà aiutarvi a trovare.

Non entrate in contrasto con nessuno, per carità, anche se vi trovate di fronte un idiota!

Poi, quando il problema comincia a diventare chiaro e si comincia lo sviluppo, l'ideale sarebbe portare dal cliente qualcosa di quanto realizzato non appena abbia assunto una forma accettabilmente funzionante, in modo che eventuali variazioni all'interfaccia possano essere affrontate prima di avere una cinquantina di forms, e che si possa cominciare subito a provare qualcosa "dal vivo", tanto si sa che la richiesta di modifiche comincerà a partire dalla visione della prima videata

Non appena si prova la prima maschera, salterà fuori qualcos'altro, potete starne certi.

Ma se il lavoro è stato appena "imbastito", i bestemmioni saranno molti meno.

A me piace molto l'approccio del "extreme programming", che si può riassumere:

[zeross]

@dany88 il problema non è l'ingengere del software, ne puoi mettere anche 50, ma se il cliente finale che dovrà utilizzare il tuo prodotto cambia ogni volta idea e richieste sempre ti troverai a fare le fatiche doppie e se non ti fornisce informazioni vitali circa gli altri software di cooperazione aziendale, ti troverai con problemi inaspettati, proprio perche non conosciuti che nemmeno il miglior ingegnere del software può risolvere.

Alla fine resti cosi

@marcOpera giustissimo quello che hai detto, se la squadra di sviluppo riesce a lavorare presso la sede del cliente conoscendone i gusti, le aspettative, le obiezioni, instaurando un rapporto che alla fine aiuta.
8)
Ma e proprio qui il problema che il lavoro on site non è la norma bensì l'eccezione, visto che spesso solo i capi si incontrano per stabilire le linee di sviluppo, mentre il team di programmatori lavoro presso la propria azienda fornendo le alpha ed i beta al cliente finale che li valuta e presenta le proprie obiezioni e valutazioni.

Quindi avviene un continuo rimpallo tra sviluppo e cliente che non si mettono mai d'accordo sulle caratteristiche e sulle funzionalità.

Il problema e proprio a livello alto quando si discutono i costi.
Realizzare il software presso il cliente costa maggiormente ed al momento della stesura dei contratti tutti puntano al prezzo minimo e quindi ninete lavoro sul sito ma solo dentro la nostra azienda software.
Se poi il lavoro si trascina con ritardi ed i costi lievitano quello è un problema che non viene nemmeno preso in considerazione.

[freemind]

Quando in uno studio siete in due l'ingegneria del software non può essere applicata a meno di non dilatare di moltissimo i tempi.

[marcOpera]

Beh, io non intendevo parlare di sviluppo presso il Cliente, ma di sopralluogo prima che cominci la stesura del codice.

Ovviamente è anche opportuno che quando si vanno a mostrare i programmi sviluppati all'utente finale, la figura di riferimento della software house continui ad essere qualcuno coinvolto in prima persona nella stesura del codice, che sappia di cosa sta parlando, e che abbia ben presenti i vari problemi affrontati in fase di analisi e conosca le soluzioni adottate per risolverli.

Quello che voglio sottolineare io è che tra il committente, o meglio, tra l'utente finale ed il programmatore non ci debba essere nessuna figura intermedia.

I rispettivi capi devono parlare solo di sghei, senza interferire in altri campi dei quali, dopo anni di lontananza dai problemi pratici, hanno perso la percezione reale.

Dal cliente ci mandi il programmatore esperto, certo, mica il novellino appena assunto o il co.co.qualcosa di turno, ma ci deve andare qualcuno che tornato in sede non usi il computer solo per fare schemini e prospetti, ma per scrivere codice e coordinare il lavoro degli altri programmatori.

Questo comporta ovviamente che la software house "coltivi" al suo interno delle figure atte a coprire un ruolo simile, e che non pensi di poter puntare tutto sul metodo tradizionale analista/scribacchino -> stuolo di ragazzetti alle prime armi low-cost a pestare come forsennati sui tasti.

Ciaociao.

Marco

[develop]

concordo con zeross
e aggiungo
prima si fa un lavoro di analisi in cui si stabiliscano tutte le videate, le stampe, e le funzionalità. E va pagato.
Poi si fanno i programmi.
Altrimenti il cliente crede che l'analisi sia un lusso.
Questo l'ho capito adesso dopo trentacinque anni di programmazione.

[freemind]

[develop]

è già complicata la faccenda,
se ci si mette anche il capo, è finita.
In tutta la filiera, capi, venditori, clienti, analisti compresi (se non sono programmatori) dovrebbero avere l'umiltà di riconoscere che non sanno cosa vuol dire programmare,
altrimenti tutto si scarica sul programmatore di turno.
Programmare è un'arte e non si bastona il bue che ara.

[SverX]

[freemind]

[SverX]

[develop]

per Freemind

manifestare al capo come si è costretti a lavorare,
forse non ottiene niente subito,
ma il capo ormai sa che stà facendo qualcosa che danneggia qualcuno!
E' importante far sapere.

[freemind]