analista funzionale.. questo sconosciuto
Andrea
ne ho sempre sentito parlare ma mi sono sempre chiesto una cosa.. ma che
minkia fa l'analista funzionale??
mah..
Luca Menegotto
> ne ho sempre sentito parlare ma mi sono sempre chiesto una cosa.. ma
> che minkia fa l'analista funzionale??
Analizza le funzioni??
:-DDDD
Buona Pasqua
--
Ciao!
Luca
Sinclair
>
> ne ho sempre sentito parlare ma mi sono sempre chiesto una cosa.. ma che
> minkia fa l'analista funzionale??
Fa funzionare l'ano, allargandolo con la minkia, o con tutti gli altri
strumenti (informatici o no) a disposizione.
FabMind
> Ciao a tutti,
>
> ne ho sempre sentito parlare ma mi sono sempre chiesto una cosa.. ma che
> minkia fa l'analista funzionale??
(premessa: ho semplificato molto)
fa analisi sulle funzionalità e sulle procdure aziendali in modo da
interagire con chi poi dovrà implementare quelle funzionalità in un
sistema informativo.
quindi deve avere competenze che riguardano i processi aziendali (se
siamo in una banca deve comprendere ad esempio le problematiche
dell'area finanza o dei sistemi di pagamento o dei titoli) che in
qualche modo che riguardano il sistema informativo di quell'azienda.
--
FabMind
Andrea
quindi per diventare una analista funz. devi essere laureato in economia
oppure in gestione aziendale o cose del genere?
FabMind
> quindi per diventare una analista funz. devi essere laureato in economia
> oppure in gestione aziendale o cose del genere?
certamente aiuta, ma non è detto.
io ti ho fatto un esempio nel mondo bancario dove i sistemi informativi
sono orientati al gestionale, ma in altre realtà le competenze dovranno
essere diverse.
--
FabMind
Mirko
> ma che minkia fa l'analista funzionale??
>
> mah..
E' quella figura che serve ad aumentare di volume i libri di software
engineering ;-)
ricca...@email.it
Si occupa principalmente di fuffaware
Andrea Francia
software. Un software super fico e super tecnologico che non fa quello
che serve č inutile.
--
Andrea Francia
http://www.andreafrancia.it/
fm
Un software super fico e super tecnologico che non fa quello
che serve
e che spesso non fa nemmeno quello che dice ....chiamasi, appunto,
fuffaware.
Sinonimi: vaporware, baracconware ... -)
ciao
fm
Andrea Francia
> CUT
> Un software super fico e super tecnologico che non fa quello
> che serve
> CUT
> e che spesso non fa nemmeno quello che dice ....chiamasi, appunto,
> fuffaware.
Quello ha a che fare con la politica scelta per promuovere il software
non con l'analisi funzionale.
Roberto C.
L'analista funzionale ti dice quello che devi fare.
Il fatto che tu e buona parte di quelli che hanno risposto, ignorano o
sottovalutano l'importanza di questo ruolo la dice lunga sulla maturità
dell'informatica in italia
Massimo
news:CQSFj.87$1x1...@nntpserver.swip.net...
> L'analista funzionale ti dice quello che devi fare.
> Il fatto che tu e buona parte di quelli che hanno risposto, ignorano o
> sottovalutano l'importanza di questo ruolo la dice lunga sulla maturità
> dell'informatica in italia
Non so perché, ma "il fatto che tu e buona parte di [...] ignorano o
sottovalutano" mi sembra dirla piuttosto lunga anche sulla maturità della
lingua italiana.
Comunque, nessuno nega che gli analisti funzionali siano importanti; il
problema è che, come al solito, spesso le figure non prettamente tecniche
vengono a tal punto nascoste in mezzo a vagonate di scempiaggini commerciali
che si tende a considerarli tutti dei buffoni incompetenti e mangiasoldi.
I project manager servono, gli analisti funzionali servono, persino i
commerciali (ebbene sì!) servono; quello che non serve è che tutte queste
figure a) sparino cazzate in malafede per fregare il cliente oppure b)
sparino cazzate in buonafede perché non sanno di cosa parlano, "tanto poi ci
sono i tecnici che risolvono tutto".
Massio
Roberto C.
> "Roberto C." <rober...@xxxtiscalinet.it> ha scritto nel messaggio
> news:CQSFj.87$1x1...@nntpserver.swip.net...
>
> I project manager servono, gli analisti funzionali servono, persino i
> commerciali (ebbene sì!) servono; quello che non serve è che tutte
> queste figure a) sparino cazzate in malafede per fregare il cliente
> oppure b) sparino cazzate in buonafede perché non sanno di cosa parlano,
> "tanto poi ci sono i tecnici che risolvono tutto".
Nella mia esperienza in azienda i tecnici sono sempre stati meri
esecutori di specifiche altrui. L'analista era la figura più importante
e a volte erano persone interne altre volte esterne. I tecnici
(programmatori) erano le figure meno pagate (se esterne) e sinceramente
avevano il compito più facile.
Poi per rendere la tua osservazione meno di parte avrei aggiunto anche
che non servono tecnici incompetenti che si spacciano per esperti.
FabMind
> L'analista funzionale ti dice quello che devi fare.
> Il fatto che tu e buona parte di quelli che hanno risposto, ignorano o
> sottovalutano l'importanza di questo ruolo la dice lunga sulla maturità
> dell'informatica in italia
in pratica è la stessa cosa che ha detto mia moglie quando gli ho
riassunto l'argomento di questa discussione e alcune delle risposte.
--
FabMind
PIPPO
> L'analista funzionale ti dice quello che devi fare.
si , ma non sa se è possibile farlo , perchè non conosce i linguaggi.
E' come il cliente finale , chiede cosa gli piacerebbe che il sw facesse ,
ma poi non sa se la tecnologia lo permette , cioè lui non sa di non sapere.
mentre un programmatore se si studia l'ambito di applicazione del sw , può
sostituire l'analista .
Andrea Francia
>> L'analista funzionale ti dice quello che devi fare.
>
> si , ma non sa se è possibile farlo , perchè non conosce i linguaggi.
valutano la fattibilità e ne stimano l'effort necessario per portarli a
termine.
In *pratica* in alcune aziende questo concetto non viene applicato.
In questo caso il problema non è che c'e' un analista funzionale
incompetente verso gli aspetti tecnici, ma è che il processo di
specifica dei requisiti non è organizzato bene.
> mentre un programmatore se si studia l'ambito di applicazione del sw , può
> sostituire l'analista .
Non sono d'accordo. Al programmatore mancherebbe sempre l'intima
conoscenza del dominio applicativo che invece ha l'esperto di dominio.
La soluzione è far collaborare un esperti di dominio con un tecnici
informatici.
Massimo
> Nella mia esperienza in azienda i tecnici sono sempre stati meri esecutori
> di specifiche altrui. L'analista era la figura più importante e a volte
> erano persone interne altre volte esterne. I tecnici (programmatori) erano
> le figure meno pagate (se esterne) e
> sinceramente avevano il compito più facile.
Mi dispiace, ma dissento radicalmente.
Commerciali, PM, analisti & compagnia cantante servono solo a fare da
*contorno* a chi fa il lavoro vero, ossia realizzare il software. È proprio
l'atteggiamento di considerare tutti impotantissimi tranne chi fa il lavoro
vero e proprio che sta portando alla rovina l'informatica.
Il programmatore non è semplicemente un muratore che mette i mattoni dove
l'architetto gli dice di metterli. Il paragone appropriato è quello con la
scrittura di un libro: l'editore è importante, la campagna promozionale è
importante, i correttori di bozze sono importanti, ma è lo scrittore a
scriverlo. E non potrà certo scrivere un buon libro se tutte le figure che
dovrebbero essere di contorno stanno lì a dirgli in continuazione cosa deve
fare secondo loro, e magari hanno già messo in prevendita un thriller
fantascientifico mentre lui sta scrivendo un fantasy medievale.
> Poi per rendere la tua osservazione meno di parte avrei aggiunto anche che
> non servono tecnici incompetenti che si spacciano per esperti.
Su questo non ci piove; ma bisognerebbe allora anche parlare di chi vende
"senior" raccattati al mercato delle pulci il giorno prima...
Massimo
Andrea Francia
> Commerciali, PM, analisti & compagnia cantante servono solo a fare da
> *contorno* a chi fa il lavoro vero, ossia realizzare il software. È
> proprio l'atteggiamento di considerare tutti impotantissimi tranne chi
> fa il lavoro vero e proprio che sta portando alla rovina l'informatica.
il lavoro del programmatore rispetto a quello delle altre figure
professionali.
Se questo fosse quello che pensassi ti farei notare che hai lo stesso
atteggiamento che accusi gli altri di avere.
> E non potrà certo scrivere un buon libro se
> tutte le figure che dovrebbero essere di contorno stanno lì a dirgli in
> continuazione cosa deve fare secondo loro,
Purtroppo il programmatore non puo' decidere da solo quali sono i
requisiti utente e deve interfacciarsi con altre persone.
> e magari hanno già messo in
> prevendita un thriller fantascientifico mentre lui sta scrivendo un
> fantasy medievale.
I cambiamenti vanno presi in considerazione e vanno gestiti.
Comunque questo dovrebbe essere un problema gestito dal project manager
e non direttamente dal programmatore.
Massimo
news:CJXFj.42877$FR.1...@twister1.libero.it...
> Pero' parlando di lavoro vero fai sembrare che consideri piu' importante
> il lavoro del programmatore rispetto a quello delle altre figure
> professionali.
È esattamente quello che penso. I programmatori scrivono i programmi, tutti
gli altri servono solo ad aiutarli a scriverli meglio e a venderli.
Un programmatore può benissimo realizzare un programma anche senza analisti,
PM e commerciali ("Linux" ti dice nulla?); viceversa, tutti gli analisti, i
PM e i commerciali del mondo non potranno mai realizzare nulla senza
programmatori (anche se poi magari riusciranno a guadagnarci lo stesso).
> Se questo fosse quello che pensassi ti farei notare che hai lo stesso
> atteggiamento che accusi gli altri di avere.
Potresti spiegarti meglio?
Massimo
n.n
> "Andrea Francia" <andrea....@gmx.it.invalid> ha scritto nel messaggio
> news:CJXFj.42877$FR.1...@twister1.libero.it...
> Un programmatore può benissimo realizzare un programma anche senza
analisti,
> PM e commerciali ("Linux" ti dice nulla?); viceversa, tutti gli analisti,
i
> PM e i commerciali del mondo non potranno mai realizzare nulla senza
> programmatori (anche se poi magari riusciranno a guadagnarci lo stesso).
Evvvai mo mi lancio con te !!!!
A. L'analista funzionale ( bravo, tralasciamo gli impostori ) analizza un
processo
B. L'analista funzionale spiega a al Tecnico ( bravo, tralasciamo gli
impostori ) il processo
C: Il tecnico capisce il processo e realizza il SW
Segue --->
1. Il tecnico ovviamente e' in grado di capire il processo e potrebbe fare
l'analisi funzionale
2. L'analista puro capisce di processi ma non conosce la tecnologia e quindi
non puo' fare il Prodotto
3. 1 analista + 1 tecnico possono essere sostituiti da 2 tecnici che faranno
anche l'analisi e poi lavorano entrambi, mentre l'analista finita l'analisi
spesso parassita
4. flameeeeee :-)))))) L'analista e' il segretario/account del tecnico !!
ciao a tutti Nicola
> Massimo
Nicola
--------------------------------
Inviato via http://arianna.libero.it/usenet/
Roberto C.
> Il 25 Mar 2008, 01:50, "Massimo" <bar...@mclink.it> ha scritto:
>> "Andrea Francia" <andrea....@gmx.it.invalid> ha scritto nel messaggio
>
> 1. Il tecnico ovviamente e' in grado di capire il processo e potrebbe fare
> l'analisi funzionale
e questo processo induttivo da dove è uscito?
Suarez (dall'ufficio)
> si , ma non sa se è possibile farlo , perchè non conosce i linguaggi.
mi sembra una boiata (e gratuita pergiunta)
>E' come il cliente finale , chiede cosa gli piacerebbe che il sw facesse ,
>ma poi non sa se la tecnologia lo permette , cioè lui non sa di non sapere.
il cliente in genere ti chiede delle funzioni (chesso': voglia avvisare i miei
clienti via sms dell'evasione dell'ordine) ed in genere qualsiasi funzione nuova
richiesta in una azienda (per rimanere nell'esempio) che esiste da piu' di 5
anni richiede di interfacciarsi con qualcosa di pre-esistente e quasi mai
espandibile/modificabile (ci dovrebbe essere una strip d dilber a riguardo)
>mentre un programmatore se si studia l'ambito di applicazione del sw , può
>sostituire l'analista .
per carita' io ho sempre conosciuto analisti funzionali (o esperti di processo)
che erano anche e soprattutto programmatori, ma di programmatori che
conoscessero a fondo le problematiche di gestione del magazzino, della
fatturazione e della contabilita' e della telefonia mobile ne ho conosciuti
pochini.
Andrea Francia
> Un programmatore può benissimo realizzare un programma anche senza
> analisti, PM e commerciali
Se il programma deve essere prodotto nel budget di costo e tempo ci
vuole un PM.
Se il programma deve essere venduto ci vuole un commerciale.
Se il programma deve servire a risolvere un problema specifico ci vuole
un'analista.
Se il programma deve solo fare cose utili al programmatore, non ci sono
limiti di tempo o di costo e non deve essere venduto allora sì, sono
d'accordo, il programmatore può farlo da solo.
>("Linux" ti dice nulla?);
Quale "Linux"?
Il kernel?
Il sistema GNU/Linux?
Una delle tante distribuzioni?
ispas
> Commerciali, PM, analisti & compagnia cantante servono solo a fare da
> contorno a chi fa il lavoro vero, ossia realizzare il software. È
> proprio l'atteggiamento di considerare tutti impotantissimi tranne
> chi fa il lavoro vero e proprio che sta portando alla rovina
> l'informatica.
Nei piccoli progetti da gruppi di 2-3 persone è evidente che hai
ragione. Nel senso che distinguere tra pm, analista, sistemista,
programmatore, ecc. è impossibile ed anche assurdo. Alla fine tutti
fanno tutto, e tutti si accontentano....
Ma nei grandi progetti la strutturazione del gruppo di lavoro è una
necessità, non una fissazione di qualcuno. Pertanto ci sarà sempre il
programmatore "senior" che parlerà con il cliente, e riferirà le
richieste ai programmatori junior. E siccome non ha tempo di fare
tutto, il programmatore senior via via programmerà meno e colloquierà
di più col cliente. E quindi si trasformerà in analista funzionale.
Quanto ai paragoni, stranamente la produzione software non viene mai
paragonata ad altre produzioni industriali, perchè evidentemente nel
confronto il sw ci perde molto. Allora si paragona il sw ad un'attività
artistica, come scrivere un romanzo. Può essere, ma sinceramente la
materia di gran parte del sw (gestionali, contabilità, ecc.) tutto ha
meno che l'aspetto artistico. Insomma ce ne vuole per confrontare
Camilleri con l'autore dell'ennesimo pacchetto Iva o gestione
personale...
ispas
> >
> > L'analista funzionale ti dice quello che devi fare.
>
> si , ma non sa se h possibile farlo , perchh non conosce i linguaggi.
>
Molti (non tutti) dei linguaggi che si usano di solito sono general
purpose. Ci puoi fare qualunque cosa. Quindi e un problema che non
esiste in assoluto.
Puo esistere nel ristretto ambito di un particolare ambiente
applicativo. Ma comunque e superabile investendo tempo e soldi, e
programmatori, in misura adeguata.
ispas
> Non sono d'accordo. Al programmatore mancherebbe sempre l'intima
> conoscenza del dominio applicativo che invece ha l'esperto di
> dominio. La soluzione è far collaborare un esperti di dominio con un
> tecnici informatici.
Aggiungo però che l'analista funzionale, esperto di dominio,
realisticamente non può collaborare con *tutti* i programmatori. Farà
quindi riferimento ad un "capo programmatore", "responsabile tecnico",
o come lo vogliamo chiamare. Il quale finisce per essere una figura in
pratica equivalente a quell'analista che si vorrebbe eliminare.
Quindi alla fine è solo una questione di nomenclatura.
n.n
scritto:
L'analista spiega ai tecnici l'analisi, i processi le funzioni. I tecnici
capiscono l'analisi e fanno il SW.
Scusa mi vuoi dire che dove lavori tu i tecnici scrivono SW e non sanno cosa
fa e come funziona ?
FAmmi sapere che azienda e' che me la segno ....
n.n
scritto:
> PIPPO wrote:
> Non sono d'accordo. Al programmatore mancherebbe sempre l'intima
> conoscenza del dominio applicativo che invece ha l'esperto di dominio.
> La soluzione è far collaborare un esperti di dominio con un tecnici
> informatici.
L'unico vero esperto di dominio e' il cliente finale o comunque una persona
che non partecipa alla produzione SW.
L'analista ( non sempre ma quasi ) e' un overhead fra il cliente finale e la
produzione che aumenta i costi e produce perdita di informazione.
Prendiamo un esempio classico, la banca.
L'unico vero analista che conta e' qualcuno che lavora in banca da dedcenni.
L'analista di una SW house sapra' sempre 1 centesimo di lui sui processi
delle banche e in particolare sui processi della speifica banca su cui si
sta lavorando.
La produione piu' e' vicina al cliente e meglio uscira' il SW.
Poi esistono figure intermedie che su progetti grossi fanno da ponte ma la
VERA analisi la ha il cliente e il VERO progetto lo devono fare gli
Architect. L'analista e' un mezzo segretario che sta in mezzo.
> Andrea Francia
> http://www.andreafrancia.it/
ispas
> L'unico vero esperto di dominio e' il cliente finale o comunque una
> persona che non partecipa alla produzione SW.
Si, ma a volte (molto spesso, direi) il cliente finale e assolutamente
incapace di spiegare in modo coerente e completo quello che fa
(per educazione inadeguata, per scarsa inclinazione, per disabitudine).
Figuriamoci a metterlo per iscritto....
L'intermediario (analista, o programmatore esperto, o come la vuoi
chiamare) deve quindi essere bravo a tirare fuori da questi soggetti
quella conoscenza, che da soli mai e poi mai saprebbero esprimere.
Cominciamo quindi a dire che il programmatore-intermediario deve saper
scrivere ottimamente in italiano. E qui cascano molti asini.... :-)
risikoo
> Si, ma a volte (molto spesso, direi) il cliente finale e assolutamente
> incapace di spiegare in modo coerente e completo quello che fa
> (per educazione inadeguata, per scarsa inclinazione, per disabitudine).
> Figuriamoci a metterlo per iscritto....
> L'intermediario (analista, o programmatore esperto, o come la vuoi
> chiamare) deve quindi essere bravo a tirare fuori da questi soggetti
> quella conoscenza, che da soli mai e poi mai saprebbero esprimere.
> Cominciamo quindi a dire che il programmatore-intermediario deve saper
> scrivere ottimamente in italiano. E qui cascano molti asini.... :-)
>
In alcuni progetti ho trovato assolutamente necessaria la figura dell'
"analista".
Vi sono ambiti complessi (es. banche, assicurazioni, tlc le prime realtà che
mi vengono in mente per esperienza diretta o indiretta), in cui un
"servizio" non sempre viene erogato da un singolo software, ma magari da una
"catena", da sistemi complessi che si interfacciano tra loro, ecc..
Al cliente queste cose non interessano, il cliente vuole l'erogazione di un
servizio, indipendentemente da come venga realizzato. Lo sviluppatore
conosce il suo sistema e si interfaccia con altri sistemi. L'analista
(ripeto, in alcuni progetti in cui sono stato) faceva da tramite tra cliente
e singoli PM, aveva uno conoscenza ad alto livello (non specifica per
singolo sistema, ma legata al servizio da fruire, alla catena di lavorazione
o come vogliamo chiamarla) delle funzionalità dei vari sistemi e il suo
compito era la stesura dei requisiti veri e propri. Poteva farlo il cliente?
Nei casi in questione non ne era in grado, in altri casi sicuramente sarà in
grado e non sarà necessario l'analista.
bye,
risikoo
risikoo
Straquoto.
Luca Menegotto
> Se il programma deve essere prodotto nel budget di costo e tempo ci
> vuole un PM. Se il programma deve essere venduto ci vuole un
> commerciale. Se il programma deve servire a risolvere un problema
> specifico ci vuole un'analista.
>
> Se il programma deve solo fare cose utili al programmatore, non ci
> sono limiti di tempo o di costo e non deve essere venduto allora sì,
> sono d'accordo, il programmatore può farlo da solo.
Non ho risposto io, perché lo trovavo inutile (chi scrive evidentemente
non ha idea di produzione di software a livello industriale). Lo hai
fatto tu e molto meglio di quanto avrei mai potuto fare io.
Aggiungo se posso che, nella mia esperienza, non esiste momento più
formativo del lavoro in un gruppo ben disciplinato e con compiti
chiaramente assegnati. Questo non annulla la personalità del singolo,
che anzi ha la doppia opportunità di concentrarsi molto nel suo lavoro
e do contribuire comunque alla riuscita del gruppo con le proprie idee
che il PM, se intelligente, terrà sempre in dovuta considerazione.
--
Ciao!
Luca
risikoo
> Mi dispiace, ma dissento radicalmente.
> Commerciali, PM, analisti & compagnia cantante servono solo a fare da
> *contorno* a chi fa il lavoro vero, ossia realizzare il software. Č
proprio
> l'atteggiamento di considerare tutti impotantissimi tranne chi fa il
lavoro
> vero e proprio che sta portando alla rovina l'informatica.
????
La produzione di software non č limitata certo alla stesura del codice.
Il lavoro "vero" lo fanno tutti, da chi gestisce il budget, a chi fa
analisi, a chi sviluppa, a chi testa, a chi fa manutenzione, a chi fa
supporto al cliente, ecc...
Che poi in progetti di 3 o 4 persone alcune figure coincidano con lo
sviluppatore non lo metto in dubbio.
bye,
risikoo
risikoo
scritto:
> >("Linux" ti dice nulla?);
> Quale "Linux"?
> Il kernel?
> Il sistema GNU/Linux?
> Una delle tante distribuzioni?
>
Aggiungo: in Italia č pieno zeppo di azienda che producono software "tipo
Linux", o sbaglio? :-)
Sinclair
> Il 24 Mar 2008, 21:11, FabMind <fab...@yahoo.com> ha scritto:
>> Roberto C. ha scritto:
>>
>> > L'analista funzionale ti dice quello che devi fare.
>> > Il fatto che tu e buona parte di quelli che hanno risposto, ignorano o
>> > sottovalutano l'importanza di questo ruolo la dice lunga sulla maturità
>> > dell'informatica in italia
>>
>> in pratica è la stessa cosa che ha detto mia moglie quando gli ho
>> riassunto l'argomento di questa discussione e alcune delle risposte.
>>
>> --
>
>
> Straquoto.
Straquoterei anch'io se non fosse che (per la mia personale esperienza,
- e limitata solo all'Italia - e che può essere diversa nel vostro caso) in
90% dei casi si tratta di una figura completamente inutile, incapace e
parassitaria che sta li piazzata dalla BR (e a volte è la stessa BR) per
succhiare altri soldi e per monitorare il lavoro degli schiavetti
guga-guga (per usare la terminologia del Duca) e alla fine l'analisi
funzionale la tocca fare all'analista tecnico o allo stesso programmatore.
Per i "residui" 10% (ma anche meno) tanto di capello...
ricca...@email.it
> >news:CQSFj.87$1x1...@nntpserver.swip.net...
>
> > I project manager servono, gli analisti funzionali servono, persino i
> > commerciali (ebbene sì!) servono; quello che non serve è che tutte
> > queste figure a) sparino cazzate in malafede per fregare il cliente
> > oppure b) sparino cazzate in buonafede perché non sanno di cosa parlano,
> > "tanto poi ci sono i tecnici che risolvono tutto".
>
> Nella mia esperienza in azienda i tecnici sono sempre stati meri
> esecutori di specifiche altrui. L'analista era la figura più importante
> e a volte erano persone interne altre volte esterne. I tecnici
> (programmatori) erano le figure meno pagate (se esterne) e sinceramente
> avevano il compito più facile.
E questa strategia tipicamente italiota (nata nel tentativo di
risparmiare forse?)
porta al disastro.
risikoo
> Straquoterei anch'io se non fosse che (per la mia personale esperienza,
> - e limitata solo all'Italia - e che può essere diversa nel vostro caso)
in
> 90% dei casi si tratta di una figura completamente inutile, incapace e
> parassitaria che sta li piazzata dalla BR (e a volte è la stessa BR) per
> succhiare altri soldi e per monitorare il lavoro degli schiavetti
> guga-guga (per usare la terminologia del Duca) e alla fine l'analisi
> funzionale la tocca fare all'analista tecnico o allo stesso programmatore.
> Per i "residui" 10% (ma anche meno) tanto di capello...
>
Aspetta, io parlavo di casi in cui la cosa funziona.
Se parli di BR e casi in cui le cose non funzionano, ti dico che ci sono
analisti inutili come programmatori inutili.
Altra cosa: se l'analisi la facesse uno sviluppatore, in quel caso sarebbe
lui l'analista, quindi ai fini del progetto la figura comunque serve.
ricca...@email.it
> L'unico vero esperto di dominio e' il cliente finale o comunque una persona
> che non partecipa alla produzione SW.
> L'analista ( non sempre ma quasi ) e' un overhead fra il cliente finale e la
> produzione che aumenta i costi e produce perdita di informazione.
Standing Ovation
Sinclair
>
> Altra cosa: se l'analisi la facesse uno sviluppatore, in quel caso sarebbe
> lui l'analista, quindi ai fini del progetto la figura comunque serve.
E chi ha mai sostenuto (o almeno, questo non sono stato io) che
l'analisi funzionale non serve? Stavo solo dicendo che (secondo la mia
personale esperienza) nella maggior parte di casi in Italia è solo un
titolo che suona bene da mettere sul biglietto di visita e per succhiare
altri soldi al cliente finale, ma che alla fine il lavoro lo devono fare
l'analista tecnico o (nel peggior dei casi) lo stesso programmatore.
ispas
> Vi sono ambiti complessi (es. banche, assicurazioni, tlc le prime
> realt` che mi vengono in mente per esperienza diretta o indiretta),
> in cui un "servizio" non sempre viene erogato da un singolo software,
> ma magari da una "catena", da sistemi complessi che si interfacciano
> tra loro, ecc..
>
> Al cliente queste cose non interessano, il cliente vuole l'erogazione
> di un servizio, indipendentemente da come venga realizzato. Lo
> sviluppatore conosce il suo sistema e si interfaccia con altri
> sistemi. L'analista (ripeto, in alcuni progetti in cui sono stato)
> faceva da tramite tra cliente e singoli PM, aveva uno conoscenza ad
> alto livello (non specifica per singolo sistema, ma legata al
> servizio da fruire, alla catena di lavorazione o come vogliamo
> chiamarla) delle funzionalit` dei vari sistemi e il suo compito era
> la stesura dei requisiti veri e propri. Poteva farlo il cliente? Nei
> casi in questione non ne era in grado, in altri casi sicuramente sar`
> in grado e non sar` necessario l'analista.
>
Certo, e verissimo. A volte non si fa solo l'analisi della richiesta
del cliente finale, quanto soprattutto l'analisi dell'interazione tra i
diversi sistemi informatici. E questa non la puo in nessun caso fare il
cliente, visto che non e il suo lavoro.
risikoo
> Certo, e verissimo. A volte non si fa solo l'analisi della richiesta
> del cliente finale, quanto soprattutto l'analisi dell'interazione tra i
> diversi sistemi informatici. E questa non la puo in nessun caso fare il
> cliente, visto che non e il suo lavoro.
>
>
Almeno uno che abbia avuto un'esperienza simile alla mia.
Mi sembrava di essere fuori dal mondo, leggendo tanti altri post!!!
risikoo
> E questa strategia tipicamente italiota (nata nel tentativo di
> risparmiare forse?)
> porta al disastro.
>
Analista funzionale + sviluppatori direi che è più costoso dei soli
sviluppatori.
Andrea Francia
> Ciao a tutti,
>
> ne ho sempre sentito parlare ma mi sono sempre chiesto una cosa.. ma che
> minkia fa l'analista funzionale??
>
> mah..
Ecco cosa ho trovato Googolando. Un articolo che spiega cosa fa un
Analista Funzionale.
http://www.programmazione.it/index.php?entity=eitem&idItem=30235
Roberto C.
>
> L'analista spiega ai tecnici l'analisi, i processi le funzioni. I tecnici
> capiscono l'analisi e fanno il SW.
>
> Scusa mi vuoi dire che dove lavori tu i tecnici scrivono SW e non sanno cosa
> fa e come funziona ?
> FAmmi sapere che azienda e' che me la segno ....
>
Mi spiace, il fatto di capire un'analisi non ti fa diventare analista.
Hole
> oppure in gestione aziendale o cose del genere?
Conta anche l'esperienza che si ha in quel determinato campo, IMO. Ad
esempio, se hai lavorato per 5 anni come sviluppatore in ambito
telefonia, potresti anche fare l'analista funzionale in quell'ambito.
L'analista funzionale si occupa della raccolta dei requisiti ed
effettua l'analisi del dominio del problema. Dai suoi documenti si
ricava l'analisi tecnica di dettaglio e la progettazione, di concerto
con l'architetto.
Non sempre però tale ruolo viene affidato ad una persona in
particolare. Di solito, l'architetto o analista/programmatore si
occupa dell'analisi. In campi di nicchia e delicati, come quello del
trading online ad esempio, c'è bisogno di un analista funzionale (ed è
auspicabile che abbia un buon background tecnico...).
Di solito è una persona che ha una esperienza specifica nel campo
oppure acquisisce velocemente i processi aziendali e tutto il
background necessario (in questi casi, gli ingegneri VO sono
adattissimi).
Marcoxxx
> n.n wrote:
> > L'unico vero esperto di dominio e' il cliente finale o comunque una
> > persona che non partecipa alla produzione SW.
[SNIP]
> quella conoscenza, che da soli mai e poi mai saprebbero esprimere.
> Cominciamo quindi a dire che il programmatore-intermediario deve saper
> scrivere ottimamente in italiano. E qui cascano molti asini.... :-)
L'italiano e' un "linguaggio contestuale" e come tale del tutto
inadeguato alla scrittura di specifiche tecniche informatiche.
Che poi ci si voglia ostinare a scrivere specifiche tecniche
in linguaggi non formali (cosa che in ambito
tecnico scientifico credo avvenga solo
nell'informatica, anche se non so di preciso) e' un altro discorso...
Ma e' su questo discorso e non sulla non conoscenza dell'italiano
che cascano i veri asini (anche perche' quello che scrivevo
ad esempio io fino all'anno scorso era all'80% in inglese).
Ciao,
Marco
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
tribalistas
> Ciao a tutti,
>
> ne ho sempre sentito parlare ma mi sono sempre chiesto una cosa.. ma che
> minkia fa l'analista funzionale??
>
> mah..
Partendo da un documento di TP o AF (Technical Proposal o Feasibilty)
scrive le specifiche funzionali (SF) che poi passeranno in mano agli
analisti tecnici e quindi allo sviluppo. L'analisi funzionale si
riduce a una serie di UC (Use Cases) che descrivano le nuove
funzionalità che il sistema dovrà fornire.
Ciao
Marcoxxx
> Il 24 Mar 2008, 23:45, Andrea Francia <andrea....@gmx.it.invalid> ha
> scritto:
> > PIPPO wrote:
> > Non sono d'accordo. Al programmatore mancherebbe sempre l'intima
> > conoscenza del dominio applicativo che invece ha l'esperto di dominio.
> > La soluzione è far collaborare un esperti di dominio con un tecnici
> > informatici.
> L'unico vero esperto di dominio e' il cliente finale o comunque una persona
> che non partecipa alla produzione SW.
Dipende cosa intendi per "esperto di dominio".
> L'analista ( non sempre ma quasi ) e' un overhead fra il cliente finale e la
> produzione che aumenta i costi e produce perdita di informazione.
> Prendiamo un esempio classico, la banca.
> L'unico vero analista che conta e' qualcuno che lavora in banca da dedcenni.
Secondo te uno che lavora in Tim/Telecom o presso H3G da decenni e' in
grado di fare analisi piu' di quanto non ne facciano i tecnici
(o analisti architect o quello che vuoi tu) di Ericsson che ha fornito
tutta la rete mobile a Tim/Telecom e che fornisce molto personale
(in una specie di bodyrentantalleria megagalattica) ad H3G ?
> L'analista di una SW house sapra' sempre 1 centesimo di lui sui processi
> delle banche e in particolare sui processi della speifica banca su cui si
> sta lavorando.
Infatti in genere l'analista non e' nella software house (la software
house dal mio punto di vista e' la vera entita' inesistente).
Chi fornisce software ad un operatore delle telecomunicazioni
e' spesso un'altra societa' di telecomunicazioni, non una software house.
Ericsson la puoi anche vedere come una software house ma di fatto
e' una societa' di telecomunicazioni che fornisce software
(e non solo)
per telecomunicazioni ad altre societa' di telecomunicazioni.
Lo stesso si puo' dire per Siemens.
Un'altra societa' che fornisce o forniva software a Telecom e'
ad esempio HP.
Forse HP la puoi considerare una software house, ma sia questa, sia
Ericsson sia qualsiasi altro fornitore di tali dimensioni, in genere si
presentano dicendo: "questa e' la nostra soluzione, se vi interessa ve la
vendiamo".
Ad esempio HP vende molto sistemi tipo HP OpenView e Ericsson
vende (o almeno vendeva)
molte centrali proprietarie. Quasi mai si mettono a sviluppare ex novo su
richiesta del cliente. Quello che fanno in genere e' customizzare
i loro prodotti sulla base della richiesta del cliente (HP OpenView sembra
essere pensato fin dalla nascita per soddisfare questo tipo di
esigenza di customizzazione)
La richiesta non parte quasi mai dal cliente e anche quando parte dal
cliente, nella soluzione ci viene infilato di tutto di piu' per ovvi
motivi.
Poi ci sara' anche qualche piccola software house che vende software
a Tim/Telecom, dietro richiesta specifica del cliente(sebbene io abbia
visto
con i miei occhi, nel 2002, una piccola societa' calabrese che ha venduto
software a Tim con le stesse modalita' sopra dette: ovvero, "noi abbiamo
questa soluzione, se vi interessa ve la vendiamo") ma secondo te sono piu'
o meno dell'1% anche considerando i soli HP ed Ericsson ?
Allo stesso modo ho avuto modo di assistere personalmente (anzi piu'
che assistere ho proprio "progettato" i test di accettazione,
anche se "progettato" e' una parola grossa...) alla'acquisto
di un sistema per la spedizione di SMS che Ericsson ha fatto da una
societa' credo inglese (chiamata Telsis). Non e' che Ericsson gli
ha detto "noi vogliamo un sistema con queste caratteristiche".
Questi sono venuti, hanno detto: "questo e' il nostro sistema, ha
le seguenti caratteristiche, spedisce un 450 milioni di miliardi di
SMS al microsecondo, ma se acquisti la licenza superpremium
che costa solo 27.000 miliardi di Euro puoi
arrivare a 850 miliardi di miliardi di SMS al nanosecondo "
Per la verita' spesso nemmeno se con "esperto di dominio" intendi
decidere quanti SMS al secondo ti servono, l'espeto e' il cliente
finale perche' in tutti questi passaggi, essendo i prodotti tutti
proprietari del fornitore finisce che chi compra chiede a chi vende:
"ma quali/quante licenze mi consigli" ?
Per la verita' poi Ericsson ha solo fatto hosting per questo
sistema che in realta'e era di H3G (o 3 o come cavolo si chiama).
Ma io persone di H3G non ne ho praticamente mai viste. Ho solo
parlato al telefono un paio di volte con una PM.
Poi, a loro volta questi avrebbero dovuto rivendere tale sistema
a dei content provider (all'epoca si era parlato di DADA, poi
non so se la cosa sia andata in porto)
> La produione piu' e' vicina al cliente e meglio uscira' il SW.
Vedi sopra. Nella catena sopra chi consideri il cliente finale ?
Dada ? In realta' quando e' stato acquistato tutto l'accrocco,
di service provider non ce ne erano proprio.
Allora forse H3G e' il cliente finale ? Io gente di H3G non ne ho vista.
Anche se io sono intervenuto solo per i test, non credo proprio che chi ha
fornito il sistema abbia creato il prodotto apposta per quel cliente
(anzi... io ricordo che chiamarono me perche' dissero che le persone
che erano "fornite" da Ericsson ad H3G c'erano molti sistemisti
ma nessuno che avesse mai progettato un test funzionale per un software!)
Fina al 2004 La rete di telefonia mobile, GSM e UMTS era stata fornita al
100% da Ericsson a Tim. Sulla parte di
telefonia fissa per Telecom invece Siemens aveva fornito
l'80% delle centrali. Secondo te ne sa piu' il personale di
Tim/Telecom o ne sanno di piu' i fornitori ?
> Poi esistono figure intermedie che su progetti grossi fanno da ponte ma la
> VERA analisi la ha il cliente e il VERO progetto lo devono fare gli
> Architect. L'analista e' un mezzo segretario che sta in mezzo.
Infatti negli ultimi anni l'analista non esiste praticamente
piu'. Esite quello che tu chiami architect ed esiste il programmatore.
Entrambi possono fare lavoro di analisi ma almeno nel caso delle
telecomunicazioni ognuno fa l'analista dei sistemi che vende, non
del problema specifico del cliente. Se il cliente ha un problema
specifico si cerca tra i prodotti a catalogo quale si avvicina di
piu' alla soluzione e, se il cliente chiede qualcosa di un po' diverso,
lo si customizza (facendo pagara una valanga di soldi)
Ciao,
Marco.
Marcoxxx
[SNIP]
> È esattamente quello che penso
Putroppo quello che pensiamo io e te non fa testo.
>. I programmatori scrivono i programmi, tutti
> gli altri servono solo ad aiutarli a scriverli meglio e a venderli.
Il problema e' che pare che la gente non abbia ancora compreso
come funzionano le cose dal 2003 in poi.
Per quanto riguarda le multinazionali (parlo di multinazionali
che acquistano software da altre multinazionali), in realta' tu i programmi
inizi a scriverli *solo dopo* che gli altri li hanno gia' venduti!
E nel 99.9% dei casi vendono prodotti a catalogo che tu dovrai
customizzare.
Poco importa se quello che scriverai funzionera' o meno.
L'importante e' che loro abbiano gia' venduto (e incassato).
Ed e' anche per questo che spesso capita che il cliente ti voglia in sede
da lui: lui ha gia' pagato per cui vuole controllare che tu stia
8 ore/giorno da lui e non vada a donne dai facili costumi. Poi non
gli interessa se il software che tu scrivi funziona o meno.
E anche qui potrei fare esempi presi dalla mia esperienza personale.
> Un programmatore può benissimo realizzare un programma anche senza analisti,
> PM e commerciali ("Linux" ti dice nulla?); viceversa, tutti gli analisti, i
> PM e i commerciali del mondo non potranno mai realizzare nulla senza
> programmatori (anche se poi magari riusciranno a guadagnarci lo stesso).
Il punto e' che a loro e alle aziende
non interessa "realizzare". Interessa "vendere".
n.n
> n.n ha scritto:
- CUT -
> Vedi sopra. Nella catena sopra chi consideri il cliente finale ?
Il tuo caso Ericcson , che hai spesso raccontato non mi pare possibile
prendrlo come esempio
non solo non si capisce chi e' il cliente finale ma sinceramente non si
capisce manco chi e' la SW house , visto che hai nominato 2 telco, una
azienda di elettronica e una web company
E' sostanzailmente un gran casino :-)
> Ciao,
> Marco.
ciao, Nicola
ispas
> Che poi ci si voglia ostinare a scrivere specifiche tecniche
> in linguaggi non formali (cosa che in ambito
> tecnico scientifico credo avvenga solo
> nell'informatica, anche se non so di preciso) e' un altro discorso...
>
Ti posso dar ragione, comunque documentazioni discorsive tipo gli use
case previsti, da metodi come RUP, non le ho inventate io. Resta il
fatto che a moltissimi clienti finali non presenterai diagrammi e
frammenti in linguaggio formale,ma relazioni scritte in italiano. E,
credimi, si vede la differenza tra una relazione scritta bene ed una
scritta male.
Massimo
news:BK3Gj.274346$%k.39...@twister2.libero.it...
> Se il programma deve essere prodotto nel budget di costo e tempo ci vuole
> un PM.
> Se il programma deve essere venduto ci vuole un commerciale.
> Se il programma deve servire a risolvere un problema specifico ci vuole
> un'analista.
Come ho già detto, non voglio assolutamente negare che tutte queste figure
abbiano un loro ruolo ed una loro importanza, anche notevole.
Ma il nocciolo della questione restano i programmatori: senza quelli, il
software non c'è.
Mi sembra una cosa talmente ovvia da non esserci nemmeno bisogno di
ribadirla...
Massimo
Andrea Francia
Se leggi bene il mio post ti accorgerai che il mio commento non
riguardava l'affermazione:
- "Il lavoro del programmatore è piu' importante degli altri".
Perché è una opinione, condivisibile o meno, su cui c'e' poco da discutere.
Il mio post riguardava l'affermazione :
- "Un programmatore può benissimo realizzare un programma anche senza
analisti, PM e commerciali."
n.n
scritto:
> Andrea Francia wrote:
> Aggiungo se posso che, nella mia esperienza, non esiste momento più
> formativo del lavoro in un gruppo ben disciplinato e con compiti
> chiaramente assegnati. Questo non annulla la personalità del singolo,
> che anzi ha la doppia opportunità di concentrarsi molto nel suo lavoro
> e do contribuire comunque alla riuscita del gruppo con le proprie idee
> che il PM, se intelligente, terrà sempre in dovuta considerazione.
Concordo appieno, che in un team di una certa dinmensione ( 10+) se non ci
sono dei ruoli e' la fine
e concordo che quando funzionano i ruoli e' il massimo sia del risultato che
della soddisfazione di ogni
singolo
e ovviamente uno o piu' che fa analisi e la porta a casa a tutto il resto
del team ci deve essere
Credo che l'OP, sia che sia in buona fede, sia che sia un trollone che si
diverte a vederci scannare, volesse piu' che altro capire e discutere della
fantomatica figura dell'analista funzionale a vita con formazione dubbia
magari ne' troppo tecnica ne' troppo specifica di un dominio..
Figura piuttosto frequente e giustamente discutibile.
> Ciao!
> Luca
ciao Nicola
Hole
> Ma il nocciolo della questione restano i programmatori: senza quelli, il
> software non c'è.
> Mi sembra una cosa talmente ovvia da non esserci nemmeno bisogno di
> ribadirla...
Falce, Martello e Tastiera!
Luca Menegotto
> Ma il nocciolo della questione restano i programmatori: senza quelli,
> il software non c'è. Mi sembra una cosa talmente ovvia da non
> esserci nemmeno bisogno di ribadirla...
Infatti, hai detto secondo me una ovvietà; il problema è che non sembri
renderti conto (e non solo tu, eh?) che i programmatori non sono che un
ingranaggio della macchina.
Come dire, è ovvio che senza i muratori le case non vengono su - e
prima che tu dica qualcosa, ne ho conosciuti alcuni di molto più in
gamba di taluni programmatori - , però ci vogliono loro, ci vogliono i
capimastri, ci vogliono gli ingegneri che le case le progettano, ci
vogliono gli impresari che ci mettono i soldi, ci vogliono gli agenti
immobiliari che le case le vendono.
E' un meccanismo complesso, in cui ciascuno gioca il suo ruolo.
--
Ciao!
Luca
risikoo
scritto:
> Infatti, hai detto secondo me una ovvietà; il problema è che non sembri
> renderti conto (e non solo tu, eh?) che i programmatori non sono che un
> ingranaggio della macchina.
>
> Come dire, è ovvio che senza i muratori le case non vengono su - e
> prima che tu dica qualcosa, ne ho conosciuti alcuni di molto più in
> gamba di taluni programmatori - , però ci vogliono loro, ci vogliono i
> capimastri, ci vogliono gli ingegneri che le case le progettano, ci
> vogliono gli impresari che ci mettono i soldi, ci vogliono gli agenti
> immobiliari che le case le vendono.
>
> E' un meccanismo complesso, in cui ciascuno gioca il suo ruolo.
>
Ti quoto in tutto, ma rimango allibito che escano delle frasi del tipo
"senza gli sviluppatori non si crea il software"!! Ovvio!!! Nessuno sta
sminuendo il nostro lavoro!!!!
Senza le persone che guidano i furgoncini per le consegne dei corrieri...la
merce non viene consegnata!!! Ovvio!!!! Oltre a questo ci sono ben altre
"figure" professionali. Se poi l'autista di una piccola azienda fa anche da
responsabile logistica, ecc.. beh, si parla di un caso molto particolare!!!
Concordo che il meccanismo sia complesso e che ciascuno giochi il proprio
ruolo, purtroppo invece si pongono sempre le mansioni a livelli diversi e
ciascuna figura professionale tende a denigrare le altre (proprio su questo
NG leggo che i PM non servono, gli analisti non servono, ecc... invece sono
i PM incapaci che non servono, così come non servono analisti incapaci e
sviluppatori incapaci, come in tutte le categorie di lavoratori).
Una volta spesso sorridevo quando di parlava di "lavoro di squadra" di "team
vincente", ecc.., li ritenevo concetti banali ed astratti, invece niente di
più falso, è vero che certe cose sono ancora lontanissime dalla mentalità di
tante persone.
Marcoxxx
> Il 25 Mar 2008, 16:04, aritop...@web.de (Marcoxxx) ha scritto:
> > n.n ha scritto:
> - CUT -
> > Vedi sopra. Nella catena sopra chi consideri il cliente finale ?
> Il tuo caso Ericcson , che hai spesso raccontato non mi pare possibile
> prendrlo come esempio
> non solo non si capisce chi e' il cliente finale ma sinceramente non si
> capisce manco chi e' la SW house , visto che hai nominato 2 telco, una
> azienda di elettronica e una web company
> E' sostanzailmente un gran casino :-)
Che sia un gran casino non lo metto in dubbio.
Pero' che non sia possibile prenderlo ad esempio secondo me non
e' vero:
in genere e' quello che accade nei casi in cui siano
coinvolte aziende molto grandi e multinazionali, ovvero quelle che
impiegano
gran parte dei lavoratori del settore IT.
Dove sono ora e' abbastanza simile, anche se un po' piu' in piccolo
e con modalita' un po' diverse (in ogni caso non c'e' quasi mai un
vero e proprio "cliente finale" che manifesta delle esigenze e per il
quale si costruisce il software "ad hoc". E' un continuo
adattamento/customizzazione di prodotti esistenti o sistemi comunque
gia' acquistati a prescindere dalle esigenze del cliente).
Puo' darsi che le cose in futuro evolvano in direzioni diverse,
anche perche' questi "elefanti" sono in fase di netta "contrazione",
pero' per ora mi pare che sia ancora cosi'.
Bisogna vedere se a seguito della suddetta contrazione il mondo cambiera'
come dici tu (piccole aziende, che vogliono avere
il ruolo di software house riusciranno ad avere tale ruolo, lasciate
un po' piu' libere dai suddetti "elefanti" che prima in pratica
le schiacciavano lasciando spazio solo alla bodyrentalleria) oppure
arriveranno altri elefanti al posto dei vecchi (oppure ci sara' una
ulteriore riduzione del settore informatico e basta).
Marcoxxx
> Marcoxxx wrote:
> Ti posso dar ragione, comunque documentazioni discorsive tipo gli use
> case previsti, da metodi come RUP, non le ho inventate io. Resta il
> fatto che a moltissimi clienti finali non presenterai diagrammi e
> frammenti in linguaggio formale,ma relazioni scritte in italiano. E,
> credimi, si vede la differenza tra una relazione scritta bene ed una
> scritta male.
Non lo metto in dubbio, pero' teoricamente un documento di analisi
e' un output che deriva da quello che il cliente
ti dice. E' vero che gli use case ecc. possono essere utili per
far capire meglio all'utente quello che si vuole fare ma anche qui, il
discorso e' abbastanza "strampalato":
Se produco ad esempio automobili non credo che i documenti di progetto e
i disegni derivino da quello che dico io che l'automobile poi la compro.
Non credo nemmeno che Microsoft scriva i documenti di analisi per
produrre Windows, sulla base di quello che gli dico io che poi
windows vado ad usarlo.
In ogni caso il documento "finale" di analisi dovresti presentarlo ai
programmatori piu' che al cliente (cosi' come i disegni meccanici
di una automobile dovrai presentarli a chi l'auto la costruisce piu'
che a chi la guida).
Ciao,
Marco.
Marcoxxx
> "Andrea Francia" <andrea....@gmx.it.invalid> ha scritto nel messaggio
> news:BK3Gj.274346$%k.39...@twister2.libero.it...
[]
> Ma il nocciolo della questione restano i programmatori: senza quelli, il
> software non c'č.
> Mi sembra una cosa talmente ovvia da non esserci nemmeno bisogno di
> ribadirla...
Quello che pare non essere ovvio per te e' che alle aziende
che il software ci sia o meno interessa ben poco. Interessa
molto di piu'
che ci siano le fatture e i soldi dei pagamenti.
E fino a quando non sono *gia'* state emesse le fatture, spesso la
produzione del software non parte nemmeno.
E anche quando la produzione e' partita se il software non c'e' o fa
schifo interessa ben poco (visto che le fatture sono gia' state emesse).
Interessa molto di piu' emettere altre fatture che non sviluppare il
software che dovrebbe essere stato venduto con le fattura precedente.
STeve
> Ti quoto in tutto, ma rimango allibito che escano delle frasi del tipo
> "senza gli sviluppatori non si crea il software"!! Ovvio!!! Nessuno sta
> sminuendo il nostro lavoro!!!!
Al contrario.
Ogni giorno il lavoro di chi sviluppa SW non solo e' sminuito, e'
annichilato, con contratti coccode', considerazione umana zero, con
concezioni ipersemplicistiche del nostro lavoro.
Per iniziare a guadagnare qualcosa, in Italia, DEVI diventare qualcun
altro e mettere su altri titoli, non certo quello di sviluppatore.
Da li' il commento che tu semplicisticamente giudichi assurdo.
Assurdo e' che si debba arrivare a dire una cosa cosi'.
> Senza le persone che guidano i furgoncini per le consegne dei corrieri...la
> merce non viene consegnata!!! Ovvio!!!! Oltre a questo ci sono ben altre
E infatti in genere queste persone guadagnano piu' del programmatore
medio e sono "piu' considerate" del programmatore medio.
La realta' sancisce senza mezzi termini che i programmatori sono al piu'
un fastidio necessario, da trattare con superiorita' e senza alcuna
considerazione.
Ovvio che il discorso e' alquanto complesso, a partire dal concetto di
"programmatore".
Io e altri lo intendiamo come una persona in grado di partire da zero
con un problema per arrivare ad avere un codice che risolve tale problema.
Altri vedono in quest ottica figure professionali diverse, dall'analista
funzionale, all'analista, al PM, al "programmatore" (concetto arcaico di
persona che si limita a codificare un'analisi fatta da altri), ecc.
Il punto e' che comunque la figura professionale IT in Italia e'
sminuita e non considerata, su livelli differenti.
Dalla posizione sociale, ai soldi che si possono guadagnare, ecc.
C'ya
STeve
risikoo
> Al contrario.
> Ogni giorno il lavoro di chi sviluppa SW non solo e' sminuito, e'
> annichilato, con contratti coccode', considerazione umana zero, con
> concezioni ipersemplicistiche del nostro lavoro.
> Per iniziare a guadagnare qualcosa, in Italia, DEVI diventare qualcun
> altro e mettere su altri titoli, non certo quello di sviluppatore.
> Da li' il commento che tu semplicisticamente giudichi assurdo.
> Assurdo e' che si debba arrivare a dire una cosa cosi'.
>
Io giudico assurdo che si pensi che se una persona dice che serve l'analista
funzionale debba necessariamente sminuire il lavoro dello sviluppatore!
Non stavo parlando del fatto che "al giorno d'oggi il lavoro dello
sviluppatore sia sminuito".
In ogni caso se è sminuito...perchè avviene ciò?
> > Senza le persone che guidano i furgoncini per le consegne dei
corrieri...la
> > merce non viene consegnata!!! Ovvio!!!! Oltre a questo ci sono ben altre
>
> E infatti in genere queste persone guadagnano piu' del programmatore
> medio e sono "piu' considerate" del programmatore medio.
>
Ci sarà un motivo non credi? Poi, mi fai qualche cifra per cortesia?
Il mercato deve per forza premiare il mio lavoro a prescindere?
Ci saranno pure delle logiche di mercato (domanda/offerta forse, anche se ci
credo poco, o altri motivi) per cui ciò avviene?
> La realta' sancisce senza mezzi termini che i programmatori sono al piu'
> un fastidio necessario, da trattare con superiorita' e senza alcuna
> considerazione.
>
Motivo?
> Ovvio che il discorso e' alquanto complesso, a partire dal concetto di
> "programmatore".
> Io e altri lo intendiamo come una persona in grado di partire da zero
> con un problema per arrivare ad avere un codice che risolve tale problema.
> Altri vedono in quest ottica figure professionali diverse, dall'analista
> funzionale, all'analista, al PM, al "programmatore" (concetto arcaico di
> persona che si limita a codificare un'analisi fatta da altri), ecc.
Concetto arcaico????
Hai idea di cosa succede in Italia???
Siamo tutti bravissimi, in fase di colloquio siamo tutti fenomeni, poi alla
prima emergenza o alla prima trasferta da soli ci mettiamo a piangere o
quasi.
> Il punto e' che comunque la figura professionale IT in Italia e'
> sminuita e non considerata, su livelli differenti.
> Dalla posizione sociale, ai soldi che si possono guadagnare, ecc.
>
Motivo?
Ci sarà pure un motivo o ce l'hanno tutti con noi per partito preso?
Davvero non capisco dove stiamo andando a parare.
Ti dico la mia considerazione: finchè questo lavoro mi dà da vivere in modo
semi-dignitoso (per la cronaca arrivo a fine mese con molti sacrifici) e mi
piace lo faccio, quando non sarà così l'informatica diventerà solo un hobby
(nemmeno il principale) e cercherò di dedicarmi ad altro, visto che in altri
settori a detta di tanti è così facile guadagnare, da quanto leggo sul NG.
bye,
risikoo
STeve
> In ogni caso se č sminuito...perchč avviene ciň?
Sono relativamente convinto che sia una cosa "che viene da lontano",
prevalentemente dall'assenza di una mentalita' orientata alla tecnologia
in Italia, per cui lavori estremamente tecnici non sono semplicemente
compresi dai piu' e quindi non considerati essenziali.
Semplificando la mentalita' dei piu' e' : "non capisco quindi e'
qualcosa che non serve".
Questa mentalita' diffusa, non solo all'ambito IT ma e' l'ambito IT dove
l'effetto finale si manifesta di piu', porta ad ignorare il nostro
lavoro ad ogni livello, anche aziendale, dato che spesso anche
"dirigenti e imprenditori" fanno parte della societa'.
Se vuoi riassumere il tutto in una parola direi "ignoranza".
Questa la mia teoria, ma se cerchi da me LA risposta .. beh, non la so.
> Ci sarŕ un motivo non credi?
Per definizione no, sono ateo, quindo "non credo".
Il motivo c'e' sempre, da li' a identificarlo pero' non e' facile.
Quale che sia non ritengo sia corretto sminuire il nostro lavoro.
> Poi, mi fai qualche cifra per cortesia?
No sorry. Google e' li' e non ho tempo di farti una relazione economica.
E' la mia percezione piu' qualche conto della serva.
> Il mercato deve per forza premiare il mio lavoro a prescindere?
Il mercato deve per forza considerare il tuo lavoro inutile a
prescindere tanto da fare offerte che nemmeno uno spazzino accetterebbe ?
Negli anni ci sono stati moltissimi esempi di molte offerte che erano
piu' basse del compenso IN NERO di donne di servizio.
Ti sembra una cosa normale ?
A me no.
> Ci saranno pure delle logiche di mercato (domanda/offerta forse, anche se ci
> credo poco, o altri motivi) per cui ciň avviene?
Indubbiamente.
>> La realta' sancisce senza mezzi termini che i programmatori sono al piu'
>> un fastidio necessario, da trattare con superiorita' e senza alcuna
>> considerazione.
> Motivo?
Ora, seriamente, ti sembra che se sapessi i motivi starei qui a
discutere con te ? :-)
Mi limito a prendere atto di una realta'. Posso provare a fare delle
teorie (vedi sopra) ma non so i motivi.
Tu ?
> Concetto arcaico????
> Hai idea di cosa succede in Italia???
Al di la' di quello che succede in Italia, per la mia esperienza e per
gli ambienti che ho sempre frequentato, ritengo che la suddivisione
fatta sopra derivi da concetti arcaici, nel senso che ritengo oggi come
oggi una persona nell'ambito IT dovrebbe essere in grado (aka avere una
cultura tale per) di ricoprire la maggior parte dei suddetti ruoli.
Non necessariamente per un solo lavoro.
> Siamo tutti bravissimi, in fase di colloquio siamo tutti fenomeni, poi alla
> prima emergenza o alla prima trasferta da soli ci mettiamo a piangere o
> quasi.
Mi puoi fare un esempio ?
Mi puoi dire il motivo ?
>> Dalla posizione sociale, ai soldi che si possono guadagnare, ecc.
> Motivo?
Vedi sopra.
> Davvero non capisco dove stiamo andando a parare.
Che si sta discutendo ? Dicendo quello che uno pensa ?
> Ti dico la mia considerazione: finchč questo lavoro mi dŕ da vivere in modo
> semi-dignitoso (per la cronaca arrivo a fine mese con molti sacrifici) e mi
Good, ma questo cosa centra con la discussione ?
C'ya
STeve
risikoo
> Good, ma questo cosa centra con la discussione ?
>
Hai ragione, non c'entra nulla, come sono OT rispetto al thread i motivi per
cui uno sviluppatore è poco considerato in Italia.
I motivi non li sappiamo, possiamo al limite lagnare e abbaiare alla luna su
un NG, ma anche in questo caso siamo OT rispetto al thread iniziale
sull'analista funzionale, che ha portato alla fine alle lamentele di noi
sviluppatori sottostimati, sottopagati, ecc.., ossia ha portato sempre al
solito punto morto.
Ci si legge in altro thread.
ispas
> Non lo metto in dubbio, pero' teoricamente un documento di analisi
> e' un output che deriva da quello che il cliente
> ti dice.
Il documento di analisi funzionale, come gli use cases, deve essere
sottoscritto dal cliente, non dal programmatore. Poichè in molti ambiti
il cliente non è un tecnico IT, anzi non è un tecnico tout-court, non
puoi che presentargli documenti scritti semplicemente in italiano,
altrimenti non è in grado di capire e, soprattutto, approvare.
A dire il vero neppure molti programmatori capiscono documenti più
formali, come i diagrammi UML. Per cui il discorso può valere anche per
loro.....
> Se produco ad esempio automobili non credo che i documenti di
> progetto e i disegni derivino da quello che dico io che l'automobile
> poi la compro. Non credo nemmeno che Microsoft scriva i documenti di
> analisi per produrre Windows, sulla base di quello che gli dico io
> che poi windows vado ad usarlo.
>
Qui parli di una tipologia diversa di produzione software: la
produzione "in serie", contrapposta a quella personalizzata, tagliata
su misura. Non ho esperienza diretta di questi casi, ma presumo che ci
siano appositi uffici (di marketing forse?) che fanno le "veci" del
cliente medio a cui si indirizzerà il prodotto.
> In ogni caso il documento "finale" di analisi dovresti presentarlo ai
> programmatori piu' che al cliente (cosi' come i disegni meccanici
> di una automobile dovrai presentarli a chi l'auto la costruisce piu'
> che a chi la guida).
>
Ai programmatori dai il documento di progettazione, che dovrebbe essere
preparato da un progettista a partire dall'analisi funzionale. In UML,
per esempio, la progettazione comprende i diagrammi delle classi,
sequence, state, ecc., partendo dagli use cases.
Quindi, in linea di principio, sono 2 documenti diversi.