|
| Precedente :: Successivo |
| Autore |
Messaggio |
Dangerotto
Semidio
Registrato: 20/08/08 16:34
Messaggi: 407
|
 Inviato: 11 Giu 2009 12:14 Oggetto: |
 |
|
| madvero ha scritto: | | Citazione: | Ne prendo una a caso: l'esperto di ergonomia.
Questa è una figura mistica (non quanto quella del "vero programmatore") e di solito non si trova.
Questa persona dovrebbe essere in grado di capire come l'utente usa il pc e come vorrebbe usare il programma: l'interfaccia deve fare tutto con dei click, ci vuole la possiblità di dare dei comandi da tastiera?
Le informazioni come è meglio che vengano visualizzate? |
per soli 2.000 euro al mese, cambio città e lavoro. te lo faccio io sto mestiere qui !!! |
Mi associo, mi trasferisco anch'io  . Qual'è la città di destinazione 8)?
| madvero ha scritto: | | freemind ha scritto: | | qui si potrebbe splittare la discussione in: quando il cliente non sa come fare il suo lavoro e vuole spiegare a te come farlo, ma ora è tardi, tra poco nanna |
su questo, ahimè, concordo.
nel 50% dei casi è così. |
Purtroppo è vero  , e forse la percentuale è anche più alta  .
| freemind ha scritto: | | In realtà nel fantastico mondo dei programmatori le scadenze non esistono fino al giorno dopo la scadenza, la morale è: "Il lavoro deve essere pronto per ieri!" |
| madvero ha scritto: | | vale anche per un chilo di altri lavori, ahimè. |
Ahimè, è verissimo!  
| zeross ha scritto: | [...]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
 |
A mio parere, il giusto modo di procedere sta nel mezzo. Il programmatore deve essere capace di mettersi nei panni del cliente come il cliente deve essere in grado di spiegarsi per bene (leggasi mettere pace tra i 2 criceti che ha intesta). 
| marcOpera ha scritto: | 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.
[...] Lasciamo il capo dei capi a giocare con il suo gingillo tecnologico, e andiamo in officina a vedere da vicino cosa si vorrebbe gestire.
[...] 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, [...]
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. |
Santissime parole  ...............
| marcOpera ha scritto: | 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:
| Wikipedia ha scritto: | Dodici regole sono alla base di Extreme Programming:
- Progettare con il cliente;
- Test funzionali e unitari;
- Refactoring (riscrivere il codice senza alterarne le funzionalità esterne);
- Progettare al minimo;
- Descrivere il sistema con una metafora, anche per la descrizione formale;
- Proprietà del codice collettiva (contribuisce alla stesura chiunque sia coinvolto nel progetto);
- Scegliere ed utilizzare un preciso standard di scrittura del codice;
- Integrare continuamente i cambiamenti al codice;
- Il cliente deve essere presente e disponibile a verificare (sono consigliate riunioni settimanali);
- Open Workspace;
- 40 ore di lavoro settimanali;
- Pair Programming (due programmatori lavorano insieme su un solo computer).
|
Molto inconsapevolmente avevo cominciato ad applicare buona parte di quelli che sono i punti qui riassunti anni prima che venissero "codificati".
Ciaociao.
Marco |
..... e santissimi trucchi del mestiere  .
| zeross ha scritto: | [...] 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 niente 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.  |
Non è necessario realizzare il software dal cliente, spesso può bastare solo una relazione diretta tra lo sviluppatore (o l'analista programmatore che sia) con il "vero utente finale". In alcuni casi un approfondito e duraturo contatto telefonico (coadiuvato magari anche con software di amministrazione remota, come il santo VNC) mi è stato veramente di grande aiuto.
Ovviamente è assolutamente necessaria una seria e profonda cooperazione del committente, come anche che ci sia "la pace nei pochi neuroni che spesso sono presenti nella sua testa" . I miracoli, naturalmente, non è affatto facile farli  .
| marcOpera ha scritto: | 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.
[...]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 |
Concordo, anche se so che non è affatto semplice riuscire ad applicare sempre e per bene queste regole . C'è sempre un capo/socio/collega che sia  che rema contro per mancanza di una visione realmente globale delle cose. Spesso questi riescono ad avere solo una limitativa visione commerciale....ahimè 
| develop ha scritto: | 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. |
Sarebbe bello poterlo fare sempre, ma purtroppo non è sempre "commercialmente" possibile e coi tempi che corrono bisogna limitare al massimo la perdita di commesse. 
| freemind ha scritto: | | [...] Io sono sull'orlo dell'esaurimento! |
Moralmente hai tutta la mia comprensione ed il mio appoggio; fatti forza e pensa positivo, tempi migliori arriveranno.  |
|
| Top |
|
 |
Dangerotto
Semidio
Registrato: 20/08/08 16:34
Messaggi: 407
|
| Inviato: 11 Giu 2009 12:26 Oggetto: |
|
|
Aggiungo un'ulteriore mia riflessione (my 2 cent).
Tutto quello che è stato detto finora ritengo che sia giustissimo, ma c'è un aspetto che mi pare non sia ancora stato affrontato: dal punto di vista della programmazione la gestione degli errori spesso non è ben implementata, ci sono volte dove un programma sebbene sia strutturato per una "logica di utilizzo" ben precisa, allo stesso tempo non è sufficientemente "rigido" da obbligare l'utente a seguire la suddetta logica, permettendo quindi un utilizzo "fuori dalla programmazione progettata" con risultati a volte impredicibili e catastrofici.
Una maggiore attenzione alla progettazione, alla pulizia della programmazione e sopratutto alla fondamentale fase di test (assolutamente da effettuare in un ambiente parallelo) è veramente molto importante. |
|
| Top |
|
|
freemind
Supervisor sezione Programmazione
Registrato: 04/04/07 21:28
Messaggi: 4643
Residenza: Internet
|
| Inviato: 11 Giu 2009 16:48 Oggetto: |
|
|
| Dangerotto ha scritto: | Aggiungo un'ulteriore mia riflessione (my 2 cent).
Tutto quello che è stato detto finora ritengo che sia giustissimo, ma c'è un aspetto che mi pare non sia ancora stato affrontato: dal punto di vista della programmazione la gestione degli errori spesso non è ben implementata, ci sono volte dove un programma sebbene sia strutturato per una "logica di utilizzo" ben precisa, allo stesso tempo non è sufficientemente "rigido" da obbligare l'utente a seguire la suddetta logica, permettendo quindi un utilizzo "fuori dalla programmazione progettata" con risultati a volte impredicibili e catastrofici.
Una maggiore attenzione alla progettazione, alla pulizia della programmazione e sopratutto alla fondamentale fase di test (assolutamente da effettuare in un ambiente parallelo) è veramente molto importante. |
Vero, ma se ad un certo punto il cliente dice: "ehmmm, dovrei poter però fare quella cosa la quando succede quella lì ma il programma non me lo lascia fare perchè dice che prima devo caricare quello ma io quello potrei riceverlo dopo e quindi mi farebbe comodo poter inserire le cose nell'ordine che mi pare".
Ecco, a quel punto addio consistenza, perchè se sta cosa me la dici quando tutto è finito e fatto per lavorare sotto certe logiche (e qui diventerebbe difficilissimo scrivere codice astratto anche da quel lato), per forza che farò saltare via dei controlli a volte anche importanti. |
|
| Top |
|
|
Dangerotto
Semidio
Registrato: 20/08/08 16:34
Messaggi: 407
|
| Inviato: 12 Giu 2009 13:10 Oggetto: |
 |
|
| freemind ha scritto: | Vero, ma se ad un certo punto il cliente dice: "ehmmm, dovrei poter però fare quella cosa la quando succede quella lì ma il programma non me lo lascia fare perchè dice che prima devo caricare quello ma io quello potrei riceverlo dopo e quindi mi farebbe comodo poter inserire le cose nell'ordine che mi pare".
Ecco, a quel punto addio consistenza, perchè se sta cosa me la dici quando tutto è finito e fatto per lavorare sotto certe logiche (e qui diventerebbe difficilissimo scrivere codice astratto anche da quel lato), per forza che farò saltare via dei controlli a volte anche importanti. |
Hai ragione, è vero, ma una delle mie considerazioni fondamentali che ho posto in precedenza è stata:
| Dangerotto ha scritto: | | A mio parere, il giusto modo di procedere sta nel mezzo. Il programmatore deve essere capace di mettersi nei panni del cliente come il cliente deve essere in grado di spiegarsi per bene (leggasi mettere pace tra i 2 criceti che ha intesta). |
Vien da se che se le richieste del cliente sono "assurde e/o sconclusionate" in effetti non c'è santo che tenga..... purtroppo .
|
|
| Top |
|
|
|
|
Non puoi inserire nuovi argomenti
Non puoi rispondere a nessun argomento
Non puoi modificare i tuoi messaggi
Non puoi cancellare i tuoi messaggi
Non puoi votare nei sondaggi
|
|
FAQ
Cerca
Lista utenti
Gruppi
Registrati
Profilo
Messaggi privati
Log in
