(luKa)

A parole, sembra un'ottimo metodo, eppure per esperienza personale non funziona.
Per quanto mi impegni a suddividere in task piccoli e apparentemente facili da stimare, quando passi a realizzarli ti accorgi sistematicamente di aver tralasciato qualcosa di importante.
Le uniche volte che questo non è accaduto è stato con progetti medio / piccoli di cui conoscevo bene il dominio applicativo.
L'unica strada che vedo percorribile in questi casi è di instaurare un rapporto di fiducia con il cliente, cercando di fargli capire che non vuoi "fregarlo" cercando di gonfiare i costi, ma che nel software questo accade regolarmente e tu farai di tutto per limitarlo.

Luca, sarebbe molto bello. Peccato però che poi tutte le volte io mi svegli tutto sudato...
il vero problema è che la stragrande maggioranza delle volte il cliente ha un budget preciso in quel preciso momento (esempio classico e ricorrente, il finanziamento dell'Unione Europea) e deve spenderlo entro una certa data (in genere entro qualche settimana), quindi comuinque il software nella sua interezza alla fine deve costare quella cifra (a volte anche diverse migliaia di euro) con _tutte_ quelle funzionalità.
Sarò stato molto sfortunato io, ma ad oggi un cliente come tu lo descrivi non l'ho davvero ancora incontrato...
saluti

sono d'accordo con Antonio. In genere, con i miei clienti ho un buon rapporto, e questo li ha portati pian piano a fidarsi di me. Quando invece ho a che fare con un nuovo cliente, l'importante secondo me è frenarlo, perchè lui vorrebbe sempre riempire il sw di features che poi non utilizzerà mai. Non è raro il caso in cui si fa l'analisi, si implementa il sw, si torna dal cliente e saltano fuori un sacco di cose non previste. Preventivare i costi è davvero impossibile, perchè il cliente non sa MAI cosa vuole. E con MAI intendo proprio MAI. Io personalmente sono giunto alla conclusione che è errato dare un costo al sw in base al tempo richiesto per la sua creazione, per il numero di features presenti, etc. etc.

Teoria perfetta .. pratica dubbia, o meglio raramente realizzabile. Questo succede perchè spesso il Cliente "parte" con la fantasia credendo che con i "Compiuter" si possa fare tutto .. con pochi "clicchi di mauser" .. [la dura realtà]

Luca, quando dici che la metodologia che suggerisci è in qualche modo slegata dal come si tratta la contrattualizzazione col cliente, sono perfettamente d'accordo con te, ma il punto (purtroppo) sta proprio qui!
nella mia esperienza di sviluppatore ma anche collegamento tipo PM col cliente, ciò che davvero risulta tedioso, stressante e spesso problematico _non_ è la gestione del processo di sviluppo, quanto proprio mla contrattualistica. Il vero problema è che il cliente dal punto di vista della gestione day by day del progetto lo si riesce a gestire anche, ed è anche possibile (cosa che faccio in genere) "taskettizzare" il sw da produrre, ma proprio perchè "change happens" ed inevitabilmente il cliente cambia idea, nascono i problemi di discontinuità fra gestione del processo di sviluppo/release e gestione del contratto.
Il vero problema è che chi da parte del cliente segue il progetto non è in genere chi detiene i cordoni della borsa e cioè colui che ha inizialmente contrattualizzato tempi e costi (e nero su bianco features dell'applicativo). Troppo spesso capita che colui che chiede i cambiamenti in corso d'opera non abbia alcuna autorità interna. da qui nasce il fatto che quest'ultimo si rende conto che ciò che è stato contrattualizzato come feature non è proprio ciò che gli serve (con danno per il cliente stesso), lo comunica al referente che alla fine indice una riunione con il fornitore (io...) in cui volano velate accuse di aver fatto male l'analisi ed ovviamente di non rispettare i tempi previsti. Il fornitore a questo punto si impunta sul documento di offerta tecnico/economica e ribadisce che quelle sono le feature controfirmate da entrambi e quelle verranno alla fine sviluppate. ovviamente le posizioni diventano inconciliabili e i poveri sviluppatori ci vanno di mezzo.
Ora non voglio fare la vittima, ma situazioni di questo tipo mi sono accadute, troppo spesso a mio avviso i clienti non hanno minimamente la cultura dello stakeholder per cui si nomina un vero responsabile di progetto che abbia una certa autorità anche sul budget e sul suo utilizzo (distribuzione nell'arco dell'intero progetto).
Quello che ho imparato in questi anni è riconoscere un cliente di questo tipo, in genere è quello che dopo il primo incontro dove ci sono tutti (dal capo supremo fino all'ultima segretaria), dal secondo si presenta solo una sorta di tecnico/tuttofare che sarà il vero referente di progetto. In questi casi però sono perfettamente d'accordo con Igor per cui è strettamente necessario limitare le richieste (e ci sono diversi modi per dissuadere un clientem alcuni diretti, ed alcuni in diretti) in modo che per forza di cose il progetto diventi di diemensioni ed obiettivi verosimili.
saluti

Luca, quello che volevo far capire nel mio post non è tanto l'impossibilità di gestire le richieste di cambiamento, cosa che alla fine si riesce sempre a fare (anche con il suggerimento che mi hai dato, ma ce ne sono decine di modi di mettersi d'accordo), quanto l'impossibilità di gestire in maniera concordata e senza stress problematiche di questo tipo (ed enormi perdite di tempo..).
é una questione di cultura, che fa ancora fatica a passare. Ma stai sicuro Luca che da settembre, quando diventerò padrone di me stesso, le cose potrò impostarle io fin dall'inizio, e credo sinceramente che per me sarà un bel salto nella qualità della mia vita professionale.
saluti