Newsgroup: it.lavoro.informatica
Titolo: [OT] Riprendo il post "Come ritagliarsi una carriera"

costato, nel frattempo navigate a vista.
Quali sono le tecniche che usate per determinare a priori i tempi ed i costi
di un progetto come quello in discussione (2 mesi e 8 mesi di lavoro)?
Su tutti i progetti lunghi (dai 6 mesi ai 2 anni) su cui ho lavorato io mi
sono "sempre" trovato col cliente che cambia le specifiche in corsa.
Sempre.
Per cui mi chiedo: come si fa a lavorare "tanto" sull'analisi se poi quasi
sempre si rivela una analisi basata su fandamenta fragili?
Di conseguenza come si fa a non viaggiare a vista quando le carte cambiano
sul tavolo?
E soprattutto: come vi ponete di fronte al cliente che obietta i costi 
superiori
al pattuito (ovviamente senza ringraziare delle migliorie fatte in corsa)???
Su progetti piccoli è diverso.
Il ciclo di produzione è più veloce e più difficilmente soggetto a 
variazioni
non previste.
Ciao e grazie, Sboffo. 

 al pattuito (ovviamente senza ringraziare delle migliorie fatte in corsa)???
Se arrivi a discuterne a fine progetto è tardi :D
E' ovvio che "piccole" modifiche vengono fatte senza formalità, ma se
il PM vede che si sta sforando con tempi e costi, deve agire per tempo.
 
bye!

 sul tavolo?
Insomma, non sono cose che si imparano in 2 giorni, e neppure che
*tutti* imparano
a fare pure provandoci vent'anni.....
Campioni e brocchi, tutto qui.

 non previste
E' evidente. Ma ricordati un progetto "grande" non va visto come un "blocco
di granito" ed è scomponibile "sempre". Sta alle capacità di chi stende i
piani, ad individuare bene chi, cosa, e come.
--
Black Future

 E soprattutto: come vi ponete di fronte al cliente che obietta i costi  superiori  al pattuito (ovviamente senza ringraziare delle migliorie fatte in corsa)???
Discutendoli prima ovvio. Scrivendo, trattando, firmando.
PS: Per progetti più piccoli basta l'esperienza e una chiaccherara.

 al pattuito (ovviamente senza ringraziare delle migliorie fatte in corsa)???
Vedi sopra. La gestione dei costi di progetto è a carico suo.

 di un progetto come quello in discussione (2 mesi e 8 mesi di lavoro)?
Su questo sono stati scritti piu libri e si e fatta piu' ricerca che
per la programmazione
in se... mai sentito parlare di metodologie di sviluppo? Unified
Process? Modelli di sviluupo iterativo? Modelli agili? Xtreme
programming?
Naturalmente nella nostra italietta queste cose si fanno invece " a
occhio"...
Se vuoi un consigio prova a leggere:
Extreme Programming Explained: Embrace Change di Kent Beck
oppure
Agile  and Iterative Development: A Manager's Guide di Craig Larman

 occhio"...
Attenzione a non fare confusione. Quelli che tu citi sono comunque
modelli di sviluppo, non modelli di gestione.
E non credere che nella nostra italietta non vengano applicati, eh...

Vincent Vega ha scritto:
[CUT]


Credo che intenda RUP (il Rational Unified Processing), che e' un modello
di gestione.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 programming?
Io ho trovato due problemi/limiti nel modello agile :
- Non riesci a stimare il costo finale, quindi è applicabile solo su
prezzo a consumo o da interni.
- E' necessario il coinvolgimento del cliente e che non sempre è
disponibile.
Se c'è la possibilità di flessibilitàè economica e impegno da parte
del cliente è sicuramente un bel modo di lavorare, ma devi trovare il
cliente giusto.

 corretto individuarlo in un responsabile del cliente.
vedi che alla fine se ci si spiega le cose vanno al loro posto ?
Se tu mi dici che il PM e' un uomo del cliente a questo punto io concordo in
pieno sia con questa affermazione e mi ritrovo d'accordo anche con Grubs.
In pratica il cliente crea una figura di Project manager sua, che ovviamente
non deve saper programmare ma conosce bene i processi del cliente e
interfaccia il cliente stesso con la SW house.
lato SW house e' naturale che il team di sviluppo avra' poi un suo Project
Manager , che conosce bene la tecnologia e segue lo sviluppo, in grado di
prendere autonomamente anche decisioni di tipo tecnico, e che faccia anche
la gestione del budget lato SW house, gestione che ovviamente e'
completamente differente, e molto piu' semplice dalla gestione del budget
del cliente, ma che va fatta.
Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 interfaccia il cliente stesso con la SW house.
Sicuramente questa e' la soluzione migliore con un Business Project
Manager e un Technical Project Manager, meglio ancora se affiancate da un
Solution Architect che si occupa esclusivamente dell'aspetto tecnico.
Resta da vedere quante aziende sono disposte a spendere i soldi per tre
figure di livello piuttosto elevato. :-) Probabilmente preferiranno un
disgraziato PM che si fara' il mazzo per diversi mesi e 5 programmatori
junior. :-)


occhio"...
Esistono però anche aziende che seguono la "filosofia" XP e con ottimi 
risultati a quanto pare.
La difficoltà nel far emergere alcune metodologia come XP,  a mio avviso, è 
un certo retaggio culturale di una classe dirigente tradizionalista 
nell'approccio ai problemi e poco propensa al rischio in tal senso.  Se a 
ciò aggiungiamo il fatto che XP di per sè non pone come obiettivo lo 
stabilire esattamente il costo di un progetto e che si basi su valori e 
principi spesso assenti in molti team., figuriamoci la paura di chi non sa 
parlare altro che di date di consegna, aldilà del "cosa" e del "come" :-(
bye,
risikoo

 programming?
In genere questi cosiddetti "metodi" ti dicono cose ovvie, come ad
esempio
che devi raccogliere i requisiti dall'utente. O che, poniamo, i tempi
di
realizzazione dipendono dalla capacità degli sviluppatori!
Ovviamente le dicono ammantandosi di una bella "confezione", tanti
bei grafici e disegni.
Ma non ti dicono come fare le stime quando il cliente non sa, o non sa
dire,
cosa vuole effettivamente. Che poi è la normale quotidianità. Quindi
molti
di questi "metodi" sono solo una moda. Passerà.

 di questi "metodi" sono solo una moda. Passerà.
In termini quantitativi lo standard piu' efficace diffuso ad oggi e' il
prince2. Il problema e' che prince2 e' molto sterile in progetti in cui
l'input qualitativo fa una differenza determinante come in IT(non per
altro prince2 e' adottata come una generica strategia di project
management in diversi settori). Rup e tutte le altre discipline pongono
l'accento piu' sui metodi qualitativi (che non sono certamente di minore
importanza). Non e' affatto impossibile comunque integrare prince2 e rup
per ottenere un approccio ancora piu' flessibile.
http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/apr03/Prince2RUP_TheRationalEdge_Apr2003.pdf


 di questi "metodi" sono solo una moda. Passerà.
E dopo che si fa si gioca a briscola ?



No, dopo qualcun'altro tirerà fuori un altro metodo, che so.... il
metodo N.N. ;-)