Newsgroup: it.lavoro.informatica
Titolo: Professioni Informatiche Redditizie

Salve a tutti
lo scopo di questo messaggio è appunto capire quali sono le
professioni redditizie ( per redditizia intendo almeno da 40000 annui
euro in su )  nell informatica che un povero programmattore può
aspirare.
Naturalmente escluso il PM che ,a quanto vedo in giro, è una figura
che non ha niente di tecnico ( conosce solo il significato delle
sigle) e in genere un programmatore non lo diventera mai (che peccato)
ma a fine mese ha tanti soldini sul conto.
Qualcuno mi aiuti!! NN so + in che direzione guardare!! help help

Nel mezzo del cammin di nostra vita, mi ritrovai con The Jackal che
diceva:

Prova fare lo spammer o il phisher
-- 
"Le opinioni dei fanatici prescindono dai fatti"
python -c "print 'bG9ybWF5bmFAZ21haWwuY29t'.decode('base64')"
Linux Registered User: 461615
http://lmainardi.blogspot.com

 sigle)
Tu sei convinto di questo, vero? Del resto l'informatica e' l'ambiente
ideale per il celolunghismo.
Bah....
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Qualcuno mi aiuti!! NN so + in che direzione guardare!! help help
non ci son misteri, se vuoi far carriera c'e' da farsi il c*lo.
punto.

 Inviato viahttp://
arianna.libero.it/usenet/
La mia è semplicemente una opinione che non vuole essere verità
assoluta,
sicuramente  ci saranno in giro PM che profonde conoscenze tecniche
pero dalla mia piccola esperienza ho dei PM mi risulta che, a loro
dire, è importante sapere solo le sigle non tutto quello che c'è sotto
Nn voglio dire che il programmattore sia + difficile del pm o
viceversa
ogni lavoro ha degli aspetti facili e difficili
Inoltre ho notato che, almeno dove sn io, la carriera PM è vietata ai
programmatori
solo questo.
PS Io celolungo circa come la media di qualsiasi programmatore ; )

 certamente gli mancano bagaglio culturale e/o esperienza da PM
Cosi', tanto per capirsi, mi definisci la figura del "programmatore" ?
Cosa discussa molte altre volte ma ritorna sempre come un boomerang, la 
mia sensazione e' che molti usino il termine "programmatore" indicando 
una figura sbagliata.
O forse sono io che chiamo "programmatore" un qualcosa di diverso.
Per me e' una persona in grado di progettare da zero, avendo delle 
specifiche, un software.
Questo, per me, implica che tale persona deve essere tutto meno uno 
sprovveduto e/o ignorante.
Quindi ... di che "bagaglio culturale" stai parlando ?
C'ya
	Steve

 - specializzarsi
perfect, queste è  quello che mi chiedevo nel mio post.
specializzarsi:
in cosa? J2EE? nn ho esempi intorno a  me di persone specializzate in
j2ee cn uno stipendio mezzo decente ( > = 40 000)
responsabilità:
che tipo di responsabilità? gestire il progetto? come detto sopra
questo è il compito del PM, almeno per quello che vedo
Io nn so se sbaglio ma ho come l impressione che la figura tecnica sia
considerata "inferiore" a livello economico di una figura che gestisce

 Quindi ... di che "bagaglio culturale" stai parlando ?
Per quello che ne so io, base PM BOK metodo PMI:
1)Definire un progetto
2)Definre una VBS
3)Definire le precedenze nei task del progetto
4)Gestire il rischio
5)Effettuare il controllo nell'avanzare il progetto
6)Relazionarsi con gli MPM
E' una figura fondamentale in progetti medio gradi e secondo me deve
avere anche dicrete skill tecniche. Purtroppo per moltissimi
sviluppatore quanto sopra sempra solo paccottiglia o follia. C'è anche
da dire che PM competenti in Italia ce ne sonopochi e si vede.
Ciao
  Francesco

 deve essere tutto meno uno sprovveduto e/o ignorante.  
Sarebbe bello, ma dubito che sia così. Il software è sostanzialmente
immateriale, per cui *anche* gli sprovveduti/ignoranti riescono a tirar
fuori un qualcosa di funzionante, a furia di test. L'unico costo è
quello delle notti che deve fare lo sprovveduto ed altri come lui, un
costo modesto per le aziende.
Perfino un semplice falegname non si può permettere di fare i test per
vedere se tutto funziona, sennò butta quintali di legno. Le misure del
mobile o della finestra *devono* essere prefissate, non ci stanno santi.
L'immaterialità del software è bella, ma ha questo risvolto negativo.
In fondo certi metodi di progettazione (eufemismo) non formalizzano
proprio questo modo di procedere per prototipi, cioè a tentativi?

 da dire che PM competenti in Italia ce ne sonopochi e si vede.
Forse anche perche' non c'e' questo gran bisogno, non essendoci progetti 
grandi e seri.
C'ya
	STeve

 Bah....
Nei cosi di PM hanno una nutrita serie di statistiche a comprovare come 
la percentuale di risultati conseguiti piu' alta non la abbiano 
assolutamente i "bravi tecnici" (anzi), ma i "bravi comunicatori".
Sembra che primi si focalizzino piu' sugli aspetti tecnici, non 
riuscendo a coinvolgere tutti gli interessati, anzi, causando spesso una 
sorta di competizione [e' meglio come dico io!], mentre i secondi non 
corrono questo rischio e le risorse coinvolte, non sentendosi "sotto 
esame", lavorino piu' serenamente.
Io non sono un "bravo comunicatore", per fortuna non sono neanche un 
"bravo tecnico", cio' mi permette di tenermi a galla come "manager".  :D
Anche se nel mio caso la dicitura esatta sarebbe "managerotfl".
Ciao
M.
-- 
"Ho perso le parole" (Ligabue)
"Mi restano un po' di parolacce" (Smith)

     STeve


 proprio questo modo di procedere per prototipi, cioč a tentativi?
Io sono della vecchia scuola, non ho mai creduto si potesse 
"formalizzare" o meglio "normalizzare" lo sviluppo SW anche se il lavoro 
degli ultimi 30 anni e' stato proprio quello di spersonalizzare lo 
sviluppo del SW, di cercare di ridurlo ad un processo meccanico.
Il perche' e' ovvio, l'industria non ama lo sviluppatore perche', 
secondo i canoni aziendali, e' improduttivo, non riconducibile in una 
statistica, non catalogabile.
Credo anzi che molti dei nostri problemi derivano da questa cosa, siamo 
considerati male e quindi sminuiti per il bisogno delle aziende di 
ricondurre il nostro lavoro e sforzo in qualche tabella, per poter 
quantificare meglio i costi.
E anche dal punto di vista del sig. Rossi, vista la diffusione del PC, 
scatta la molla del "e che ci vuole a scrivere un programma" ?
Molla che ha generato un intero mercato dedicato ad incoraggiare queste 
persone cosi' che comprano strumenti/PC/SW/ecc.
Ma tutto questo ai miei occhi non rende un ignorante pari ad un 
professionista.
Sviluppare SW "buono" implica avere persone capaci di vedere piu' in 
la', di saper leggere tra le righe, di intuire conseguenze imprevedibili 
ai piu' su una modifica.
Devi avere esperienza, conoscenze ma sopratutto essere "portato" a 
questa attivita'.
Programmatori "poveri" sono IMHO sostituibili da un qualche SW e quindi 
non possono apportare nessun valore alla professione.
Ho sempre considerato sviluppare SW piu' un'arte che una cosa meccanica, 
nel senso che lo sviluppo SW e' un processo molto intimo, appartenente 
alla persona.
Nella mia esperienza un SW funziona davvero bene quando e' anche 
"bello", ovvero strutturato bene, ovvero ben capito da chi lo ha 
sviluppato (immagino che molti lettori di questo gruppo non avranno la 
piu' pallida idea di che sto parlando).
Un SW e' per me niente altro che una trasposizione del pensiero umano in 
un codice macchina.
Chi ha poche idee non puo' che fare un SW scadente, dozzinale.
Tutti possono prendere in mano una matita o un pennello, non tutti pero' 
possono diventare un Picasso, anche conoscendo la tecnica.
I tentativi di formalizzazione sono appunto quelli, tentativi di 
sminuire il lavoro di progettazione SW, di normalizzare il lavoro di 
sviluppo cosi' da poter attribuire voti allo sviluppatore, ignorando che 
non ci sono due persone su questo pianeta che pensano nello stesso modo.
I piu' grandi prodotti SW sono sempre usciti dalla mente di chi pensa 
"out of the box", non dal primo sig. Rossi di turno.
Guarda oggi ... ci sono migliaia e migliaia di programmi, ma non sbaglio 
di molto dicendo che il 90% e' del tutto inutile/fatto male/incompleto.
Questo e' il lavoro di sprovveduti.
C'ya
	Steve

 aspirare.
Project Leader o Team Leader o Software Architect, il nome dipende
dalle aziende. In sostanza è quello che in un progetto, invece di
creare i problemi li risolve. Carriera non facile, l'alternativa è il
classico posto giusto al momento giusto.

 Qualcuno mi aiuti!! NN so + in che direzione guardare!! help help
Di fianco, un pelo in alto.
Vedi se ce' qualcuno a fare coordinamento dalle tue parti e studialo.
Nell'esercito farei il paragone con il caporale, o con un sergente che 
non strilli troppo.


enricoe ha scritto:

Project Leader e Team Leader sono due cose abbastanza diverse.
In questo caso credo che il minimo cui aspirare per quelle cifre sia il 
"Team Leader".


 linguaggi che non conosce e quelli in linguaggi che conosce?
La domanda giusta è : un PM dovrebbe dirigere progetti in ambienti che
non conosce ? Io credo di no.
Non deve certo conoscere il linguaggio approfonditamente, ma il
framework e la tecnologia che sta usando la deve conoscere benissimo.

 conoscenze ma sopratutto essere "portato" a questa attivita'.
Osservo che il progettista esperto può lavorare spesso in modo più
rilassato, proprio perchè vede più in là. Ma qui, malignamente, dico
che uno sviluppatore/progettista che non suda 7 camice facendo le notti
non è visto di buon occhio.... ;-)

enricoe ha scritto:
 >> Ad esempio un PM programmatore tratterebbe ugualmente progetti in
 >> linguaggi che non conosce e quelli in linguaggi che conosce?
 >
 > La domanda giusta è : un PM dovrebbe dirigere progetti in ambienti che
 > non conosce ? Io credo di no.
Da quello che vedo in giro ti rispondo di si.
 > Non deve certo conoscere il linguaggio approfonditamente, ma il
 > framework e la tecnologia che sta usando la deve conoscere benissimo.
Quello e' gia' piu' compito del Project Leader, che pero' puo' averne 
una buona "infarinatura" senza pregiudicare i risultati, la padronanza 
della tecnologia la deve avere il Team Leader.
M.

 "sotto esame", lavorino piu' serenamente.  
Sì, ma quando c'è da decidere tra due proproste tecniche discordanti,
che fa? Tira a sorte?
Mi è capitato di avere un PM molto "comunicativo", che non diceva mai
di no a nessuno: tecnico esperto, cliente, collega di altra società....
Però, nei casi di conflitti irrisolvibili.... non risolveva niente,
continuava a girare a vuoto cercando di mediare. Il progetto era in
Java/Jsp(Ejb, lui non sapeva assolutamente nulla di questo, quindi era
incapace di scegliere da solo, si doveva affidare al giudizio di altri
semplici progettisti, a simpatia. Tu mi piaci, la tua soluzione si fa;
tu non mi piaci, allora la tua soluzione non si fa...
Perciò un PM deve avere conoscenze tecniche, ed anche notevoli, direi.
 

 Qualcuno mi aiuti!! NN so + in che direzione guardare!! help help
Oramai lo dico sempre di meno, perché mi sembra che non interessi a
nessuno... ma fare il programmatore va benissimo.
Vedi ad es.
http://tinyurl.com/22mjj7
-- 
Mopo
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 della tecnologia la deve avere il Team Leader.
Perchè il PM non è in grado, oppure e troppo pigro per conoscere la
tecnologia. Qui alle riunioni sembra di fare pasticcini, ma la realtà
è che si fanno sistemi complessi ed il capo dovrebbe per primo
conoscere tutti gli aspetti della tecnologia.
Se in ambito gestionale non sai cosa è una transazione dovresti essere
licenziato in tronco a qualunque livello, anche l'AD; così se in
ambito web non sai cosa è il wc3 ecc..
Ovvio, non deve saperla implementare, ma deve conoscerla bene, anzi,
benissimo, per evitare che tutti ti raccontino balle o di promuovere
il più incapace le cose le devi sapere ed i corsi sono fatti apposta.
Peccato che quando uno ha un distintivo cerca tutti i modo per
mettersi al riparo dal dover esprimere delle opinioni verificabili.

 aspirare.
Netti o lordi?

 terra terra, č in grado di tradurre in codice nel linguaggio di 
Domanda ... ma esiste davvero richiesta per "code-monkey" ?
Ditte grandi e piccole ne ho girate e non ho mai, dico mai, visto la 
richiesta di tale figura (se escludiamo il primo lavoro che ho fatto 
ormai 30 anni fa in un CED :-) )
Ho sempre lavorato in realta' dove dovevo prendere in carico un 
problema, capirlo, sviluppare il codice, documentarlo e collaudarlo ed 
installarlo eventualmente all'utente finale (quale esso sia).
Spesso ho lavorato in team, ma ognuno del team era in grado di prendere 
il lavoro ad un qualsiasi punto e portarlo a termine se necessario.
Ovvero erano team collaborativi, non strutturati in via gerarchica e 
ogni membro del team doveva essere autonomo se necessario.
Per quello che per me "programmatore" ha solo il significato di una 
persona in grado di fare qualsiasi cosa sia necessaria, dall'acquisire 
specifiche, a crearle, a sviluppare il sistema e 
scrivere/testare/documentare il codice.
L'unica distinzione che ho sempre fatto/visto e' "l'anzianita'" e 
l'esperienza.
C'ya
	Steve

> Domanda ... ma esiste davvero richiesta per "code-monkey" ?
[cut]
Si, esiste. Dipende dal framework che adotti, se è abbastanza
faraginoso, vincolante ed inefficente c'è bisogno di qualcuno che
svolga i compiti più semplici.
Comunque non credere, in Italia è molto difficile trovare una persona
in grado di analizzare un problema, scrivere il codice e rilasciare
una applicazione che lo risolva. Anche in caso di problemi semplici.

 una applicazione che lo risolva. Anche in caso di problemi semplici.
Mah, ho sempre lavorato in realta' di quel tipo in Italia ... in effetti 
si progettava anche parte dell'HW, non solo software.
Vero che qualche ditta dove ho lavorato non esiste piu' ma di gente che 
sa il fatto suo ne conosco parecchia.
C'ya
	Steve

 sa il fatto suo ne conosco parecchia.
Settore e tempi diversi.
Nel tuo settore sono necessarie delle competenze mediamente più alte
del gestionale tipo :  fatturazione società di telecomunicazioni
scritto in java ...
In oltre parli di tempi diversi, adesso, con l'ingresso delle nuove
leve e la sostanziale estinzione delle softwarehouse vecchia maniera,
le persone che "sanno lavorare" non sono facili da trovare. Le persone
escono dall'università e le mettono a lavorare ad ore su progettoni
dove vedono solo una piccola parte dell'insieme. Il vecchio
programmatore, mi dicono, qui non esiste quasi più.
Ricorda che qui lo stipendio in ingresso è più basso di quello di un
operaio.

 sigle) 
Ma queste cagate te le hanno insegnate a ingegneria informatica????

 Però, nei casi di conflitti irrisolvibili.... non risolveva niente,
La differenza fondamentale tra un project manager e un cazzaro di quarta 
categoria. In particolare ti accorgi dell'esistenza del cazzaro quando 
le cifre del progetto vanno sopra i 3M di euro.

 affiancato da un software architect o da un team leader.
Beh questa e' una delle tante 'visioni' dello sviluppo software,
peccato trascuri il fatto che creare software non e' come assemblare
un ' automobile o costruire un edificio, per cui il passaggio dal
design alla costruzione non e' mai una semplice traduzione. e per
questo motivo non puo' essere affidato a figure junior (che non
sarebbero in grado di realizzare il design) a meno di non volersi
accontentare di realizzare un carrozzone che sta a in piedi con lo
sputo.

 ha scritto nel messaggio 
news:f78dbf2f-00d1-4212...@h11g2000prf.googlegroups.com...
Salve a tutti
lo scopo di questo messaggio è appunto capire quali sono le
professioni redditizie ( per redditizia intendo almeno da 40000 annui
euro in su )  nell informatica che un povero programmattore può
aspirare.
IMHO....con grande semplicita' e crudezza:
programmatore=tecnico=operaio
se vuoi fare soldi devi fare il  venditore, il quale non lavora con le dita 
ma con la lingua....
ovvero piu' che la logica usa la furbizia.
Auguri...:-)
ciao
fm

 Qualcuno mi aiuti!! NN so + in che direzione guardare!! help help
Purtroppo c'e' poco da guardare, se non all'estero. In Italia possibilita'
non ce ne sono. I lavori tecnici in futur verranno sempre piu' considerati
lavori "di bassa qualifica" e si andranno spostando in paesi a basso 
costo (India ad esempio).
Ciao,
Marco.


Roberto Gibin ha scritto:


Tu conosci qualche PM che quando gli fanno notare che l'equazione
"ore uomo assegnate al progetto/numero di persone che lavorano al
progetto=tempo di consegna" (*)
e' una immane cazzata (come ogni libro di ingegneria del software riporta)
fa notare ai dirigenti che appunto tale equazione e' una immane cazzata ?
Conosci qualche grande azienda che non usa la suddetta equazione ?
Io conosco qualcuno (aspirante dirigente di multinazionale)che quando gli
ho proposto:
per fare stime dei tempi del progetto, usiamo il modello 
co.co.mo
 II
(che non sara' il massimo, ma sempre meglio di una stima delle ore
uomo assegnate al progetto fatta "ad occhio e croce" da gente
che l'informatica l'ha vista in cartolina, seguita da (*)) ha risposto:
"ma tale modello assegna troppo tempo allo sviluppo di codice!".


 linguaggi che non conosce e quelli in linguaggi che conosce?
Un PM *non deve* fare il programmatore. E non lo fa! Stanne certo.
Piuttosto si mette a giocare al solitario.
Ciononostante un PM che sia in grado di fare il programmatore e'
tranquillamente in grado di comprendere i problemi del programmatore e 
trovare le soluzioni che favoriscono la tranquillita' dello stesso,
specialmente se il progetto utilizza linguaggi e tecnologie ben note
al PM stesso. A differenza di quanto fa uno che di programmazione
non ne sa una mazza. E qui dove lavoro ora questa cosa si nota in
maniera inverosimile (dove ero prima molti PM erano ex tecnici. Qui
molti sono ex "assicuratori" o cose simili). Certo... poi ci sono i
programmatori che dichiarano esplicitamente (sentiti con le mie orecchie!)
che loro per lavorare hanno bisogno di essere "sotto stress".
Contenti loro...


 Da quello che vedo in giro ti rispondo di si.
Scusa... ma tu cosa vedi in giro ?
Perche' quello che vedo io direi che porta ad una risposta opposta
senza dubbio alcuno.
Ciao,
Marco


 il piů incapace le cose le devi sapere ed i corsi sono fatti apposta.
No. Nei corsi per PM in genere ti spiegano che se ti hanno
fatto una stima di 200 ore/uomo per il progetto => tu metti 200 persone
a lavorare su quel progetto e in 1 ora hai il tuo progetto pronto
da consegnare al cliente!
Ciao,
Marco.


 Bah....
Io ti posso fare il seguente esempio (tratto da esperienze molteplici,
in ambito multinazionali/grandi aziende).
Richiesta (fatta da una specie di PM a me):
- stimami i tempi necessari per realizzare questo progetto
Risposta (eravamo in 2 a lavorarci e il PM lo sapeva. E lo sapevo anch'io):
- Servono 30 giorni.
dopo 15 giorni arriva il suddetto PM e mi dice:
"allora... dov'e' il progetto"....
indovina perche' e' venuto dopo 15 giorni.
Poi spiegami...


 esame", lavorino piu' serenamente.
Io vorrei capire dove hanno lavorato questi.
Perche' in *tutti* i posti in cui ho lavorato io, quando c'e' stato un PM
che aveva competenze tecniche pari o superiori a quelle degli sviluppatori
le cose sono andate sicuramente meglio che quando c'era uno che pensava:
"prendo il primo che passa, pagandolo tonnellate di euro, purche' questo
mi prometta di risolvermi il problema in 2 giorni".
Tutti i "non tecnici" che ho trovato io ragionavano cosi'.
Quelli meno peggio si limitavano ad applicare l'equazione di
proporzionalita' tra le ore uomo ed il tempo di consegna 
(altro errore da licenziamento in tronco per manifesta incompetenza).


 Project Leader o Team Leader o Software Architect, 
Dove lavoravo prima il team leader ero solo il primo passo
per tentare di intraprendere una carriera di tipo manageriale.
Ma fino a quando eri Team leader in pratica eri un programmatore
senior che aveva compiti anche logistici (tipo rimediare
un PC a chi non lo aveva, ecc.)
Il software architect in realta' non c'era. Al limite c'era
una distinzione tra programmatore senior e programmatore junior.
Quello che in genere puo' essere inteso come software architect lo
facevo io, con ruolo pero' da programmatore senior (per altro esterno).
C'era poi il cosiddetto "solution architect" che era piu' o meno
un analista funzionale che stava un po' a meta' tra i tecnici e 
il marketing, anche se molto piu' orientato verso quest'ultimo.


 punto.
Questa e' una immane cazzata.


 mi prometta di risolvermi il problema in 2 giorni".
Oveero i lavori redditizi per programmatori sono quelli dove ci si trova 
a che fare con PM senza competenze tecniche. :)
ciao, U.

 l'esperienza.
In realta' c'e' una spiegazione ben precisa:
 poiche' c'e' una legge ben precisa (legge 30 o Marconi,
volgarmente detta legge Biagi) che dice che un lavoratore "esterno" (ovvero
un "bodyrentallato") *non puo'* avere un trattamento economico
inferiore ad un dipendente del cliente finale di pari qualifica,
allora dal 2003, ovvero da quando esiste tale legge (di merda),
*tutte* le grandi aziende hanno cominciato ad assegnare ai propri
dipendenti qualifiche "superiori" a quella di "programmatore" (in genere
appunto qualifiche tipo "team leader", "solution architect", "software
architect", "technical coordinator", ecc.) in modo da poter abbassare le
tariffe dei "programmatori", qualifica per lavoro ritenuto
ormai di bassa qualifica, da pagare poco, con il quale termine ormai
si indicano soltanto i "bodyrentallati", almeno in aziende di grandi
dimensioni che ricorrono a personale esterno.
Quello che e' incredibile e' che *i piu' contenti* di tale situazione
sono proprio i programmatori esterni! che magari hanno visto il
loro contratto trasformarsi da co.co... a t.i., magari con abbassamento
di stipendio, magari al terzo livello metalmeccanico, ma poiche' ora sono 
lavoratori a t.i. e poiche' e' "in voga" la mentalita' "solo t.i. e' vero
lavoro" sono tutti contenti.
Ciao,
Marco


 linguaggi che non conosce e quelli in linguaggi che conosce?
Quindi decondo te il PM deve giusto scassarsi le balle 40h/week coi 
diagrammi di Gantt? E come fa a assegnare le risorse se non capisce una 
mazza di quello che sanno fare? E come fa a valutare gli step del 
processo se non capisce una mazza di quello che è stato fatto?
ciao, U.

 Poi spiegami...
Dai, la mia risposta e' scontata ;-) Solo che non mi piace l'equazione
PM=tutto chiacchiere e distintivo [cit.]. Anche per me un PM deve avere
delle buone conoscenze tecniche, una panoramica concreta di come gira un
impianto. Questo fa si che in fase di presales ci sia già un'impostazione
piu' o meno precisa di come verrà realizzato quanto richiesto senza perdere
tempo e disperdere energie inutilmente, indirizzando da subito i tecnici
necessari.
 IMHO un buon PM e' stato anche un buon tecnico.
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 proprio questo modo di procedere per prototipi, cioè a tentativi?
E, guarda caso, sono i metodi che funzionano meglio!
Se ritrovo i riferimenti agli articoli/libri sul fallimento del modello
watrerfall (pubblicazioniì scientifiche, ovvero praticamente
*dimostrazioni matematiche*  del fallimento di tale modello! Che continua
ad imperversare nelle grandi aziende!) li posto, anche se da quando
li ho letti sono passati circa  10 anni per cui non so se li ritrovo.
Ciao,
Marco.


 considerata "inferiore" a livello economico di una figura che gestisce
Dipende dalla composizione dell'azienda.
Il PM, deve avere una conoscenza media di tutto quello che gira
attorno ai progetti con una eventuale area specialistica ed eventuale
background tecnico, deve saper comunicare al meglio con un linguaggio
spesso business oriented, rispettare deadline, step vari e tutto. Ha
maggiori responsabilita' sugli aspetti decisionali che portano i
progetti a decollare o fallire (far incazzare o meno i piani alti :D),
e nel mondo del business, piu' responsabilita', piu' grane, piu'
soldi :)
I programmatori scrivono il codice dai documenti creati dagli
architect/sviluppatori senior, che trasformano l'idea del progetto in
concetti base da dare in pasto a chi poi stara' ore a scrivere nel
linguaggio scelto, per poi amalgamare il tutto nelle fasi successive
di development/testing con altre figure (dipende dalla complessita'
dei progetti).
Nyo

 Qualcuno mi aiuti!! NN so + in che direzione guardare!! help help
Per professioni tecniche penso che le uniche possibilita' sono quelle di
trovare quelle poche aziende che valutano le figure tecniche oppure di
avere una specializzazione molto richiesta. Nel mercato italiano solo gli
ERP consentono uno stipendio superiore (SAP, jdewards, ecc.) per il
semplice fatto che hanno barriere all'entrata per l'apprendimento per cui
non c'e' la competenza dei gugaguga. Se fai una ricerca italy su jobserve
vedrai solo annunci su SAP e questo ti sta a dimostrare che sono le uniche
offerte in cui la domanda non riesce ad essere colmata dalle risorse
locali.
Altrimenti le classiche figure meno tecniche, come hai gia' citato il
project manager ma anche il presale se si entra nell'azienda giusta che
vende bene e paga buone commissioni. In entrambi i mestieri l'essere
tecnico e' una dote importante ma occorrono anche altre doti. C'e' anche
chi se la cava solo con altre doti passando da un disastro all'altro ma
non e' una vita facile. :-) Comunque comprendo il discorso perche' vale
anche per me. Se a me non piace questo tipo di mestiere non vedo perche'
mi devo trasformare in un burocrate per guadagnare il giusto. E non si
tratta di responsabilita' come qualcuno ha notato perche' ci si puo'
prendere responsabilita' anche di milioni di euro pur in un ruolo tecnico.
Lo stesso team leader ha grosse responsabilita' (spesso non riconosciute)
perche' e' lui che deve saper valorizzare e gestire le risorse umane che
ha a disposizione e che spesso hanno un valore economico potenziale
altissimo. Eppure spesso il project manager solo perche' ha visibilita'
con il cliente, sebbene si limiti a qualche visita con i capelli
ingelatinati ma di fatto la gestione e' affidata ad altre persone, agli
occhi dei dirigenti puo' aver un maggior valore di chi di fatto gestisce
il progetto e le risorse. Questione di scarsa cultura di project
management purtroppo, non solo tecnica, di molti dirigenti.



mmm quindi diciamo che se ho ben capito in un "mondo IT perfetto" il
percorso completo è
developer -> analist -> architet -> team leader -> PM
in Italia  (dico in Italia perche all estero non so come funziona)
diciamo che l'ultimo gradino ( il PM )  è ricoperto da persone che non
hanno mai scritto una riga di codice e che di tecnico hanno ben poco
ma sn + persone esperte dal punto di vista "gestionale"


Mi sa che abbiamo lavorato nello stesso posto ; )

 management purtroppo, non solo tecnica, di molti dirigenti.
corrisponde perfettamente a quello che sto vedendo anche io

 processo se non capisce una mazza di quello che è stato fatto?
Eh gia' e' quello che mi chiedo sempre io, come diavolo fa?

 grandi e seri.
Qui il punto non e' che progetto "grandi e seri" di per se non possano
esserci (anche se la maggior parte dei progetti sicuramente non e' ne
grande ne' seria).
Il punto e' che progetti "grandi e seri" richiedono investimenti.
Investimenti seri, specialmente sulle persone. Soldi. Soldi da spendere e
che, se va bene, danno i loro frutti dopo qualche anno.
Nessuno qui e' disponibile ad investire niente che non ti dia un ritorno
immediato, dopo 3 mesi, nemmeno di fronte a possibili ritorni con cifre
da capogiro. Salvo poi lamentarsi che pagano troppe tasse.
Mi spiego con un esempio:
l'ultimo anno che ho lavorato in Ericsson c'era un progetto potenzialmente
"molto grande" per l'acquisizione a distanza di dati dai contatori
elettrici
vedere ad esempio qui:
http://www.lineaedp.agepe.it/01NET/HP/0,1254,1_ART_76709,00.html?lw=10001;CHL
Praticamente l'articolo risale a 2 giorni prima che io me ne
andassi da Ericsson.
Ericsson aveva pensato di utilizzare il progetto per Acea come un
"progetto pilota" per realizzae un sofware di controllo di quel tipo da
vendere in vari posti del mondo (Grecia, Svezia, Portogallo, Serbia,
Ungheria, Australia, Nuova Zelanda ecc).
Erano venute a Roma un paio di PM direttamente dalla Svezia perche'
c'era interesse non solo da parte di Ericsson Italia ma da parte di
Ericsson corporate, ovvero di quella parte di Ericsson che coordina
le attivita' della multinazionale a livello mondiale.
Ora, ti pare che un'azienda che che ha queste pretese non possa fare
investimenti per realizzare un software ?
Tieni presente che il fornitore del software avrebbe anche dovuto
fornire i contatori elettrici che, avendo un costo di 100-200
Euro/contatore, se forniti *ad una nazione intera*, danno origine
ad un giro d'affari assurdo (un milione di contatori per 100 Euro a
contatore => 100 milioni di Euro! Se anche per realizzare il software
spendi 10 Milioni di Euro, questo incide minimamente su tutta
l'operazione!)
Ti spiego io alcune cose:
a) il software *non lo hanno progettato in Ericsson*. Ericsson Italia
ha banalmente comprato il codice del software e i diritti di proprieta'
intellettuale da un piccola societa'
fornitrice di Acea. Questa societa' aveva messo in piedi in qualche modo
un software per fare la cosa suddetta.
b) l'architettura di tale software (scritto in j2ee) era incasinatissima!
E non lo dico io che, fino ad allora di j2ee avevo visto niente, ma lo
diceva gente che da 10 anni lavorava con tale tecnologia.
c) riscrivere da capo il software sarebbe costato sicuramente meno che
tentare di adattare il software esistente alle esigenze. In realta'
il tentativo e' stato quello di modificare il meno possibile, ma dato
l'incasinamento del sitema (e dati anche alcuni evidenti errori di
progettazione) le modifiche sono comunque state necessarie ed ogni modifica
ha implicato un bagno di sangue
d) Di cosa ci sarebbe stato bisogno: gente competente ? Forse, ma
soprattutto: gente determinata! Gente che non
aveva problemi a fare tutti i giorni le 2 di notte per far funzionare il
sistema e rialzarsi il giorno dopo alle 6 per rimettere le mani
sul codice, sabato e domenica compresi! Al limite anche riprogettare
e riscrivere tutto da capo (e garantisco che sarebbe stata la soluzione
migliore! Quando a qualche collega ho mostrato le circa 20 code JMS piu'
i circa 40 EJB, tra MDB, Session Bean e Entity bean, utilizzati per andare
a prendere un file in ftp e mettere i dati nel DB la domanda tipica e'
stata: "tutto questo casino per prelevare un file in ftp ?". Ed
effettivamente e' una domanda che ci sta tutta). In pratica c'era bisogno
di gente come sarei stato io fino a 5/6 anni prima, ovvero fino a prima
che si diffondesse la mentalita': "tu  programmatore
"code-monkey", io grande capo, "dirigente" o aspirante tale! Tu fare
quello che io dire! Tu non fare straordinari! Dopo 8 ore tu andare! Tu
subordinato!
No straordinari! Straordinari=costo per l'azienda! Noi dovere limitare
costi!".
In altre parole ci sarebbe stato bisogno di *investire sulle persone* che
si fossero impegnate nel progetto. Ma "investire" e' una parola
sconosciuta,
Meglio "prendere roba gia' fatta e modificarla". Non importa se "fatta
male". L'importante e' che si modifichi roba gia' fatta e non si progetti
niente. E molto meglio "code-monkey" che "progettisti". In altre
parole: molto meglio giustificare il contenimento dei costi piuttosto che
investire. Non importa niente se i progetti vanno o buon fine o meno.
Visto il trattamento riservatomi dopo che 5-6 anni prima
facevo appunto quanto sopra(lavorare fino a tardi, alzarmi presto e, se
necessario, lavorare anche il fine settimana) anche
se non esplicitamente richiesto e anche se non totalmente retribuito (ma
almeno *parzialmente* retribuito)  nel 2006 ho deciso di fare le mie 8 ore
e poi andarmene, come per altro  *esplicitamente* richiestomi.
e) Cosa e' accaduto: 
e.1) ad inizio 2006 Sono stati presi alcuni "esperti" j2ee/struts, ecc.,
uno per altro fatto *appositamente venire in Italia* dall'Ungheria!
Pagando un anno di spese di trasferta!
Questo (un ragazzo di 20 anni, ma comunque piuttosto bravo. A differenza
di 
quanto si dice su questo NG, a me non sono capitati mai principianti "che 
fanno disastri". Viceversa ho visto molti PM e dirigenti, specialmente 
provenienti da cultura "non tecnica" fare enormi disastri) tra l'altro ha
piu' volte chiesto e ripetuto al PM italiano una cosa del tipo: "I know
that my presence here is a high cost for Ericsson: why can't I work from
Hungary, so that you don't have to pay high costs". Risposta: il silenzio
assoluto.
e.2) sempre ad inizio 2006 sono state persone prese qua e la all'interno di
Ericsson che non erano "allocate" su altri progetti (tra cui io ed un mio
collega) per fare cose piu' disparate (io e il mio collega inizialmente
abbiamo realizzato un simulatore del sistema di generazione dei dati
provenienti dai contatori, in modo da poter testare l'acquisizione di tali
dati da parte del software di acquisizione vero e proprio, visto che
inizialmente il collegamento con i contatori veri e propri non c'era: un
lavoro che tra l'altro anche noi avremmo tranquillamente potuto fare
ognuno da casa propria senza problemi!)
e.3) Il progetto e' andato avanti "in qualche modo" tra un bagno di sangue
e l'altro ad ogni minima modifica del software. 
e.4)Il progetto di vendere quel software (e anche tutto l'hardware) nelle
varie nazioni del mondo e' miseramente fallito.
Alla gara in Grecia per l'aggiudicazione della fornitura del sistema per
la lettura a distanza dei contatori (dicembre 2006) Ericsson e' arrivata
settima su nove partecipanti. Acea ormai il software lo aveva comprato
(dalla piccola azienda fornitrice. Poi aveva accettato che fosse Ericsson
a subentrare a tale piccola fornitrice, anche perche' Ericsson puo'
permettersi di fargli l'hosting dei sistemi) ma gia' le modifiche fatte da
Ericsson piacevano quasi meno della versione originale => Acea il software
se lo e' tenuto, probabilmente controvoglia (mi risulta che a fine 2006
anche Acea fosse in ristrutturazione)
f)
nel frattempo (giugno/luglio 2006) la mia body rental aveva perso la gara
=>
fino alla fine del progetto i contratti sono stati prorogati (per
la verita' erano prorogati fino a fine marzo 2007, ma visto che avevo
trovato un altro lavoro a fine febbraio me ne sono andato allora),
 poi a casa...
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 


 tua frase. Assumo "la tecnologia") non la conosce bene!
;-) ho usato "implementare" al modo del PM di bassa lega.
Comunque non è vero, non è necessario saper scrivere un programma
usando una tecnologia per saperne discutere.
Basta parlare con uno bravo, che la usa da tempo e che ti spiega punti
di forza, di debolezza, componenti, utilizzo, tecniche di sviluppo con
pregi e difetti ecc..
O Magari si può leggere qualche libro.
Un PM che lavora in una tecnologia può perdere qualche ora per leggere
dei libri, ce ne sono di discorsivi semplici semplici che ti spiegano
tutto del framework di riferimento. Solo che spesso manca la modestia,
quel titolo, quella posizione e gli anni del dirigente fanno diventare
presuntuosi, salvo poi miserabili cadute alla prima ristrutturazione
aziendale.

 li ho letti sono passati circa  10 anni per cui non so se li ritrovo.
Mi spieghi perché in ogni campo dove si progetta e costruisce qualcosa
il modello waterfall funziona, solo con il software (a tuo dire) no.
Perché la costruzione dei palazzi, ponti, impianti elettrici, navi,
aerei, ecc. seguendo il metodo waterfall si ottiene ottimi risultati e
con il software (sempre a tuo dire) no?
Ti dico io DOVE non funziona: lì dove il metodo waterfall è implementato
alla cazzo di cane, esattamente come è il metodo di sviluppare il
codice. Oppure dove lo sviluppo del codice lo chiamano "scrivere
codice", e lo considerano una spesa e non un investimento ("Specifiche?
Documentazione? Scherzi!?!?! Non abbiamo tempo per queste cose! Dobbiamo
produrre!") e di conseguenza scrivono qualche scarabocchio su come
dovrebbe funzionare un programma che poi continuamente viene fuori che
quello scarabocchio era incompleto e lo modificano.
Leggendo queste opinioni diventa chiaro anche al cieco perché essere
programmatore da molti viene concepito come un "mestiere", meno
aprezzato di altre discipline ingegneristiche, come per esempio
ingegneria edile, navale, ecc. Meno apprezzato anche di quanto lo sono i
lavori manuali.

 per tentare di intraprendere una carriera di tipo manageriale.
Se sei team leader in un team di 15 persone, in un progetto
importante, e tui sei quello che lo manda avanti, puoi raggiungere e
superare i 40K.
Se sei un pomposo solution architect in un progetto da 3 persone per
una srl mezza fallita forse te ne danno 30K.
Dipende.

 Questa e' una immane cazzata.
praticamente parlando, nella realta' italiana, ci son modi diversi di
fare carriera; in tempi rapidi e in maniera piu' o meno indolore.
ma il bel paese non fa statistica.

 lavori manuali.
Vedi sopra.
Visto che dell'ingegneria meccanica qualcosina so, anche se poco,
ti pare comparabile progettare qualcosa che puoi verificare *con metodi
scientifici* se funzionera' o meno con qualcosa che decidi tu come ti passa
per la mente e poi speri che funzioni ?
Se devo progettare anche una banalita' come una libreria o comunque degli
scaffali per i libri io ho a disposizione delle teorie scientifiche vecchie
di secoli che, dato il peso dei libri, data la distribuizione dei libri
sullo scaffale, date le caratteristiche di resistenza meccanica
dei materiali che compongono lo scaffale, data la forma dei materiali
utilizzati per lo scaffale, mi consentono di calcolare quasi esattamente
se lo scaffale reggera' il peso dei libri o si spezzera' (e anche questo
non e' un esempio inventato: a meno di 20 anni c'era un mio compagno di
scuola i cui genitori avevano un'azienda di "scaffalature metalliche" e ci
spiegavano che il calcolo avviene esattamente come sopra. E quelle
tecniche si studiano gia' a partire dagli istituti tecnici).
Nell'informatica non esiste nulla di nemmeno lontanamente paragonabile.
Forse (e dico forse perche' sinceramente non lo so) qualcosa di molto
vagamente  simile potrebbe essere qualche metodo basato sulla scrittura
delle specifiche in linguaggi formali, anziche' in linguaggi naturali (ma
solo molto vagamente, in quanto comunque non credo che sarebbe basato su
leggi fisiche piuttosto che su invenzioni strampalate dell'inventore del
linguaggio formale)
In ogni caso il riassunto di quanto sopra e' banale:
tutte le altre discipline si basano su leggi fisiche ben studiate o
studiabili: l'informatica no! Si basa solo su quello che passa per la
testa al progettista di turno.
Ciao,
Marco


 ma il bel paese non fa statistica.
Ok, posso anche concordare. Basta specificare.
Ciao,
Marco.


 Perciò un PM deve avere conoscenze tecniche, ed anche notevoli, direi.
Sei in "leggero disaccordo" con i modelli adottati da IMB, HP e altri 
piccoletti del settore......   ;)
Ciao
M.
-- 
"Ho perso le parole" (Ligabue)
"Mi restano un po' di parolacce" (Smith)

 Marco.
Ciao
Massimo


 Marco


 
Perchè, per esempio HP ci mette i contabili a fare i PM? :-)

 "intravedere".  ;)
Beh... dipende questo lo diceva anche un aspirante dirigente dove lavoravo
prima. Ma poi il marketing usava quello come metodo e volente o nolente
a quello dovevi sottostare (e per la verita' mi
sa che dove lavoro ora sono solo alle prime armi, ma la direzione in
cui si muovono mi pare decisamente quella, anche sotto
il negativissimo influsso di molti provenienti, come me,
dalle telecomunicazioni dove i metodi sopra citati sono molto "in").
Ciao,
Marco


UC ha scritto:


Si, puo' essere un punto di vista.
Il problema e' stabilire se tu sei quelli che si spaccia
per "risolvitore di problemi in 2 giorni" o sei uno degli altri.
Ciao,
Marco.



PM e' generico :)
in certe aziende, ci sono differenze varie, e figure come assistant
project manager, technical project manager, senior project manager
fino ad arrivare al chief technology officer, che praticamente manda
avanti una o piu' divisioni dell'azienda gestendo gli aspetti
tecnologici e strategici del business, deve essere carismatico e
guidare tutto come un mezzo dio (assorbire i consigli dei dipendenti
migliori, focalizzare l'attenzione verso gli sviluppi con alta
priorita', rispettare le deadline richieste dai tipi tutto-business
considerando le problematiche di budget e tutto, affidare i sub-
compiti ai project manager vari, a loro volta loro affideranno i vari
task ai developer, designer, architect vari :D, quando nei progetti
sono coinvolte centinaia di persone funziona cosi piu' o meno alla
buona. A sua volta sara' coadiuvato dai direttori di marketing,
vendite, accounting, managing, information technology, development...e
tutta la schiera di dipendenti, decine e decine di figure... potrei
farti un quadro completo ma non serve ;D
Ad ogni modo i pm devono gestire non creare, sono le figure diciamo
orologio della situazione.
A PM ci puoi arrivare da un percorso tecnico e manageriale misto
direttamente dopo gli opportuni studi, oppure dal salto di una
precedente carriera come tecnico, allo stesso modo dei grafici che
diventano art director. Servono qualita' che vanno oltre il lato
puramente tecnico, e molti tecnici non hanno o non hanno voglia di
svilupparle, per tutta una serie di motivazioni spesso caratteriali.
Il discorso e' piuttosto complesso, googla bene e troverai tante
risposte ;D
Nyo

 *dimostrazioni matematiche*  del fallimento di tale modello! 
Il problema sta nel dire che waterfall è un modello/metodo...
Come dire che nella progettazione meccanica il metodo consiste nel fare
i disegni, non nel fare i calcoli di dimensionamento.
Ma al posto di waterfall ci puoi mettere qualunque altro nome di
"metodo" informatico, oggi come oggi.

 con il software (sempre a tuo dire) no?
Posso rispondere come "Geometra"?
1) In quei casi i materiali e le tecnologie sono "stabili", conosciute e 
collaudate.
2) Poi c'e' l'inerzia che deriva dalla diffusione delle competenze.
Del tipo, la maggior parte dei muratori usano mattone e cemento, se vuoi 
entrare in produzione "subito" e a costi competitivi progetti tenendo a 
mente mattoni e cemento [Progettazione "bottom up"].
2a) si fanno anche cose "innovative", ma su tempi comunque piu' lunghi e 
con costi diversi.
3) Altra considerazione, la "moda" influisce su tempi lunghi.
4) la "responsabilizazione".
Uno che ti fa' i casini in cantiere rischia di essere "contestato" 
[eufemismo] dagli operai e di essere realisticamente licenziato in tempi 
"solleciti".
Per tacere degli aspetti legali.
Vedi qualche differenza con il campo informatico?
Lascia stare quella volta che un architetto del Comune mi chiese 
l'asfalto bianco!  :D
Ciao
M.


 Occhio, che qualcuno qui' direbbe "Guga Guga" (cit)!
Finche' mi pagano (pagavano)
a) una "cifra base" mensile che mi permette di pagarmi senza
grossi problemi l'affitto di 100 mq
b) una buona parte degli straordinari  (quando lavoravo
anche sabato e domenica mi pagavano fino a circa
60 ore/mese di straordinario. Anche se qualche volta ne avro' fatte
64-65/mese non mi pare questo gran regalo. In genere comunque di ore me ne
pagavano 20/mese o poco meno. In quei casi in genere non lavoravo sabato e
domenica e, se per caso lo facevo o me la pagavano perche' rientrava in
quelle 20 ore oppure, se magari facevo 10 ore per 4 giorni, magari poi il
venerdi' non andavo al lavoro)
non e' un problema se dicono "guga guga".
Il problema e' quando con la paga base non ci si paga piu' nemmeno
un monolocale
Ciao,
Marco.


 molto ma molto lontano.
Ogggesù.
Toh, piglia:
http://en.wikipedia.org/wiki/List_of_important_publications_in_computer_science
se non ti bastano, spendendo più di quei 5 secondi di trottata che ho
appena fatto te ne trovo anche di più, eh.
bye!

 "tu hai visto la luce!" (cit)
Dimenticavo la cosa piu' importante.
Io avro' anche visto la luce, ma questo progetto, a differenza
dei precendenti, la luce non l'ha vista! O meglio... l'ha vista
limitatamente allo "scope" iniziale (la vendita a Roma), ma l'obiettivo
vero non e' stato centrato.
Per alcuni progetti precedenti paragonabili a questo come "complessita'
tecnia" anzi  forse, dal punto di vista strettamente tecnico erano anche
piu' complicati (anche se sicuramente meno accattivanti come "giro
d'affari") le cose sono andate diversamente.
Il perche' a me e' chiaro: non serve "principalmente" un bravo PM,
dirigenti e altra gente che ruota attorno al progetto senza apportare
contributi
fondamentali alla realizzazione. Servono tecnici *determinati*
a far funzionare le cose, anche quando non hanno il 100% delle competenze
necessarie, gente che sia disposta a farsi il mazzo per imparare cio' che
gli manca e metterlo in pratica. 
Ovviamente per avere questo tipo di persone, queste devono
essere incentivate ...
Certo il progetto lo devi anche vendere e per questa attivita' i tecnici
di cui sopra non li vedo bene. Pero' se pensi di vendere "fumo"... secondo
me duri poco.


 costi competitivi progetti tenendo a mente mattoni e cemento
 
Quindi tu pensi, per esempio, che la gestione di un'anagrafica non
potrebbe essere vista come un mattone sempre uguale, o quasi?
Eppure si rifà ogni volta da capo, tanto ci metti (qui si) il
code-monkey che non costa niente..... :-)
Quanto alla stabilità, l'informatica è in giro da quasi 50 anni. Come i
jet, per esempio. Eppure ci vedo una "leggera" differenza di rigore
nella progettazione e realizzazione.

 Marco
Ciao
Massimo


 Marco.
Ciao
M.


 ciao, U.


 ma sn + persone esperte dal punto di vista "gestionale"
Ciao,
Marco.


 Mi sa che abbiamo lavorato nello stesso posto ; )
Via Anagnina ?


 Eh gia' e' quello che mi chiedo sempre io, come diavolo fa?
Si prendono le tabelle stilate dalla societa' "apposita".
Hai presente, per tornare agli esempi "concreti" dell'edilizia, i 
prezziari ufficiali che ti dicono quanto costa un metroquadro finito di 
pavimento di un certo tipo?
Oppure la barzelletta degli avvocati.
"Bene, il mio cliente secondo la legge e' colpevole, adesso vediamo cosa 
dice la giurisprudenza".


 appena fatto te ne trovo anche di piů, eh.
Si, tutta roba che puoi usare per scrivere le specifiche...
va beh... lasciamo stare va...
Ciao,
Marco.


 fm


 Perchè, per esempio HP ci mette i contabili a fare i PM? :-)
I tecnici in gamba li mette a fare i Team Lider e' li' che devi 
stroncare le rogne prima che diventino "guai".
Il PM puo' essere un ex-tecnico, ma piu' probabilmente e' qualcuno con 
una formazione manageriale e non tecnica.
Il tecnico per "salire" deve smettere di fare il tecnico.
Ah, da un po' mi pago il mutuo facendo l'Operation Manager.  :)


 Marco.
Anzi... visto che la mail che aspettavo non e' arrivata...
Mi spieghi una cosa:
se io devo progettare un codice che traduce dall'italiano all'inglese
e/o viceversa, come applico i teoremi di Shannon, tutta
la teoria dei RDBMS o quello che ti pare a te per dimostrare che alla
fine le specifiche che io ho scritto *effettivamente* corrispondono
ad un codicce che esegue una corretta traduzione dall'italiano all'inglese
?
Se vuoi ti posso spiegare io invece, come, partendo da un disegno
meccanico di una scaffalatura metallica adibita a contenere libri
(ovvero dalle *specifiche di un sistema meccanico, non certo scritte
in linguaggio naturale!),  si applicano  alcune banali
conoscenze di teoria meccanica (conoscenze aquisibili in una scuola
secondaria superiore) per calcolare se lo scaffale si rompe
sotto il peso dei libri oppure no.
Un traduttore per linguaggi naturali e' piu' complicato di uno scaffale
metallico ?
Si, puo' essere 
Allora io non te lo posso spiegare perche' non lo so fare, ma se vuoi
ti faccio conoscere alcuni che ti sapranno spiegare come si puo'
*studiare nei minimi dettagli* il movimento un sistema meccanico
intrinsecamente instabile, pesante circa una tonnellata,
costituito da due piattaforme meccaniche
una sull'altra a circa 1.5-2 metri di distanza che sono collegate da 6
pistoni oleodinamici e con una specie di moto sopra la piattaforma
in alto.
E ti posso far conoscere quelli che hanno fatto i calcoli partendo
dai disegni e poco altro (ovvero partendo dalle specifiche iniziali del
sistema, quando il sistema non esisteva).
Anche questo e' un sistema piu' semplice del traduttore ?
Puo' essere ma
a) allora significa che nelle aziende meccaniche il metodo funziona meglio
perche' sono piu' semplici
b) di tutta la teoria che hai postato non c'e' *niente* che mi possa
aiutare a risolvere il problema del traduttore (viceversa nella teoria
meccanica che impari all'universita' c'e' tutto o quasi quello che serve
per studiare la piattaforma di cui sopra)


 Marco


 Marco
Ciao
M.


 nella progettazione e realizzazione.
Il ferro e' ferro da millenni.
Quanti anni hanno .net e java?
Questo per la realizzazione.
La progettazione risente (IMHO) del fatto che l'informatica viene 
venduta come "di facile realizzazione".
Sommando le due cose.....


 Marco.


 
Infatti, tutte teorie matematiche che ti dicono *esattamente* come fare
certe cose. Per esempio come fare un compilatore.
Infatti i compilatori non li fanno le aziendine dentro ai ministeri o
banche... :-)

 
Appunto, deve smettere. Nel senso che prima ha lavorato a lungo come
tecnico, e di tecnica ne mastica (magari non l'ultimissima tecnologia).

 nella progettazione e realizzazione.
i jet sono forse confrontabili con i "sistemi in cluster" che esistono da
qualche anno ma l'aeronautica (e la meccanica dalla quale sostanzialmente
deriva l'areonautica) esistono da ben piu' di 10 anni. 


 Quanti anni hanno .net e java?
Pure troppi ;-)

 anni.
Qui fai un torto grosso come una casa agli inventori dei jet, motori ed
aerei. Tu pensi che la fisica aveva già detto tutto quello che succede
andando a 900 km/h e 10000 m di quota, prima che si facessero i
relativi test sul campo?

 Pure troppi ;-)
Nel senso che non dovevano nascere o che e' gia' pronto il sostituto 
"piu' moderno, piu' veloce, etc. etc."?  :)


ispas ha scritto:

Teoricamente corri il rischio che tenda a fare riferimento a vecchi 
paradigmi.
Per me una spruzzata di tecnica ci deve sempre essere, anche se devo 
dirti che a lavorare su progetti "moderni" con PL che ragionano in 
termini di DB2 puo' essere "faticoso".
Sopratutto perche' il seppur valido DB2 e' per ambienti completamente 
diversi da quello cui verteva il progetto (che per inciso era un Fleet 
Management).
Ciao.



mmm vicino Eur-Tintoretto cmq l ambiente è molto simile.
Ciao
PS mi sembra che stiate facendo una discussione molto interessante ; )

 va beh... lasciamo stare va...
Ma come? Non era roba che non esisteva neppure? Adesso vien fuori che
pero' non va bene per scrivere le specifiche...
Il parallelismo con la meccanica è piuttosto tirato per i capelli, ma
comunque cerco di seguirlo. Il fatto è che tu usi - tanto per cambiare
- due pesi e due misure.
Nel caso dell'informatica dici che non esistono basi teoriche per
"scrivere le specifiche". Nel caso della meccanica dici che *date le
specifiche*, puoi calcolare la stabilità statica del sistema, o
qualsiasi altra caratteristica fisica, utilizzando le nozioni di
calcolo vettoriale, ecc. ecc... e ti pare la stessa cosa?
Facendo il paragone della libreria, partire dal disegno di montanti e
ripiani e dimensionarne gli spessori perchè stiano in piedi NON è la
stessa cosa che progettare un sistema informatico. Per essere nelle
stesse condizioni dovresti partire dal concetto "mi serve qualcosa per
tenere dei libri" e da lì tirare fuori il disegno. E non mi pare che
il fatto che una libreria debba essere fatta per forza con ritti e
ripiani sia stabilito da qualche teorema, per cui non vedo perchè tu
pretenda di trovare un simile parallelo nell'ambito della teoria
dell'informazione. Semplicemente, la struttura classica con ritti e
ripiani è una "best practice" assodata ormai da centinaia di anni, in
quanto soluzione sufficientemente ottimale ad un problema comune.
La scienza dell'informazione è ancora troppo giovane per avere
soluzioni altrettanto sperimentate e radicate da apparire come
"naturali" anche ad un osservatore non tecnico (chiunque, anche chi
non sa una cippa di come dimensionare una scaffalatura, la riconosce
come soluzione ovvia al problema "un posto dove tenere i libri"). In
entrambi i domini, quello delle costruzioni meccaniche e quello della
scienza dell'informazione, arrivare dalla definizione di una esigenza
alla definizione del sistema che si vuole costruire per affrontarla è
una cosa a monte: quando hai definito il sistema puoi poi applicarci
tutta la teoria che vuoi per verificare se è solido, se è efficiente,
e ancora prima se è realizzabile. E in nessuno dei domini c'e' una
teoria che ti guida; la differenza fondamentale tra i due domini è che
in un caso hai una serie di esperienze che risalgono in pratica
all'invenzione della ruota e delle macchine semplici, nell'altro caso
hai qualcosa si e no dall'altro ieri.
bye!

 
Per il più anziano Java mi sembra che c'è molto meno entusiasmo di
qualche anno fa.
Net segue a ruota.
Il sostituto, a mio parere, c'è dal 1960: Lisp. Ed i suoi fratelli. Ah,
l'epoca dei jet!! :-))

 testa al progettista di turno.
Va be'...me la sto prendendo per niente. Anzi, devo ringraziarti per essere
così come sei, tu a migliaia di altri wannabe-coders, code-monkeys e
project-monkeys (PM). Se non ci fosse per quelli che dicono che "andare
a tentativi sono i metodi che funzionano meglio!" non avrei tutto quel
lavoro che ho ora, ovvero di sistemare e di ridisegnare le porcate
pseudoinformatiche con le quali le aziende hanno la sfiga di aver a che
fare (per colpa dei PM e CM sopra menzionati), ne guadagnerei quello che
guadagno ora. Continuate pure così.

 mmm vicino Eur-Tintoretto cmq l ambiente è molto simile.
Di fianco all'Enel e alle spalle di Wind?
Ciao


 "naturali" anche ad un osservatore non tecnico 
Scusa, ma questa è la foglia di fico per coprire tanti indubbi
fallimenti nella creazione di una teoria generale di progettazione del
software.
Ci sono tante discipline e tecnologie non più vecchie dell'informatica
(penso ai transistor, ai laser, i jet che dicevo prima, ecc. ecc.) le
quali hanno dietro teorie e metodologie con i controfagotti. E non sono
tecnologie "naturali" proprio per nessuno.