Newsgroup: it.lavoro.informatica
Titolo: Il risultato di un progetto

 garanzie sul conseguimento del risultato
 
allora io mi chiedo, quale è il risultato atteso di un progetto IT ?
 
definire risultato :
 
risultato = è bello
risultato = costa poco
risultato = funziona
risultato = funziona ed è bello
risultato = funziona e costa poco
risultato = funziona è bello e costa poco
 
( dove per bello si intende formalmente ed strutturalmente fatto bene,
manutenibilità compresa )
 
Per me è fondamentale che funzioni e che costi poco . Ovvero se non
funziona o se costa troppo in entrambi i casi è un fallimento
completo.
è meglio se è bello
 
senza alcun dubbio.

 risultato = funziona è bello e costa poco
 
Il risultato è definito dall'obiettivo.
se deve essere bello, ottenere il risultato significa raggiungere lo 
status "bello", termine però improprio, visto che si parla di un lavoro 
proposto ad altri è più appropriato ottenere "piace", che sia bello per 
me o solo per chi lo ha creato è ininfluente.
 
Costa poco non può essere un obiettivo o un risultato perchè può essere 
un pesante freno al raggiungimento dell'obiettivo stesso.
Si tratta poi di un termine difficilmente inquadrabile, poco per me, 
molto per te...
 
Il miglior risultato penso che sia "non costa poco, ma vale i soldi 
spesi", per via della relazione che esiste tra caro=buono, 
economico=mediocre
 
Si associa caro=buono (e di valore)
Si associa funziona e costa poco (ma vale anche poco)
 
 

 completo.
 
Anche se costa poco, funziona, ma produce qualcosa che non serve a 
nessuno non lo definirei proprio un successo.  :)
 
Questo in estrema sintesi e per la mia "visibilita'" del mercato.  ;)
 
Ciao
 
M.
-- 
Credo che l'unica cosa da fare sia non prendersi troppo sul serio,
ridersi addosso, e sorridere spesso, così le rughe andranno nei posti 
giusti....
(A. Vincenzi)

 se deve essere bello, ottenere il risultato significa raggiungere lo
 
l'obbiettivo è sempre soddisfare un'esigenza.
 
Semplifichiamo e diciamo che l'esigenza è vendere cetrioli online.
 
L'esigenza manifesta dal committente non include la tecnologia con cui
dovrà essere realizzato, ne la qualità, ne il costo.
 
come lo giudichi un risultato positivo ?
 
Per me è positivo solo se l'ecommerce funziona (vende cetrioli) e
costa poco.
 
 
 
 
 
PS: bello lo uso in una eccezione tecnica, non estetica. Bello =
progettato e realizzato secondo le convenzioni di buona programmazione
attuali. L'aspetto estetico del sito tralasciamolo.


 
Sai che scoperta... :-)
Come si fa a capire se costa poco o troppo?
Sceglie il cliente?
Per confronto tra progetti "funzionalmente identici"?
Altro?
 
 
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 

 nessuno non lo definirei proprio un successo.  :)
 
Beh, darei per scontato l'esistenza di una esigenza (per semplificare
direi una nuova) e la soddisfazione della stessa.
 
 > Questo in estrema sintesi e per la mia "visibilita'" del mercato.
 ;)
 
la sensazione mia è che "noi fornitori" o comunque molti di noi non
mettono il giusto peso nella variabile "costo".
 
Che invece ha un'importanza pari al "funziona".

 senza alcun dubbio.
 
Non funziona -> fallimento, siamo tutti daccordo.
 
Per i costi, vedi sopra. Non tutto è risolvibile a bassi costi.
 
Il problema di queste tue metriche è che, senza definire l'obiettivo
al quale si punta, assumono significato universale. E la cosa è
decisamente impraticabile.

 Altro?
 
bella domanda !
 
Ci devo riflettere. Sicuro non decide il cliente.
 
Mi verrebbe da dire che basta il fattore mercato (progetti con
funzionalità identici), ma mi sembra parziale.

 Che invece ha un'importanza pari al "funziona".
 
A volte viene anche prima.
"costa troppo, adesso abbiamo altre priorita'" (cit.).
 
M.
-- 
Credo che l'unica cosa da fare sia non prendersi troppo sul serio,
ridersi addosso, e sorridere spesso, cosě le rughe andranno nei posti 
giusti....
(A. Vincenzi)

 costa poco.
 
Ma se poni il costo come un non-problema fin dall'inizio, perchè poi
sei soddisfatto "se e solo se" funziona *e costa poco*? Banalmente,
date le precondizioni la risposta è: funziona.
 
Logica (matematica o meno) : quale amabile materia :-)
 
Questa cosa mi suggerisce che tu sei, consciamente o meno, ostaggio
dell'idea che la soluzione "debba costare poco". Inutile farti notare
che è oltremodo castrante questo modo di pensare (oltre che non essere
universalmente applicabile come dicevo prima).

 apportando dei cambiamenti si ottenga una minor spesa.
 
Cioè sostengono che cambiare e manutenere il vecchio costi meno che
fare il nuovo ?


Credo sia praticamente impossibile riuscire a confrontare progetti con
funzionalità identiche, così alla buona magari può anche essere possibile
(con stile alla commerciale per intenderci), invece scendendo nel
dettaglio, che poi è quello che serve, direi che non ce la si fa. E prima
di tutto perchè di prodotti con funzionalità identiche non credo ce ne
siano.
E si finisce in un ginepraio... :-)


 Ci devo riflettere. Sicuro non decide il cliente.
 
Sbagliato.
Decide proprio il cliente.
Se non ti accetta il preventivo ... ...
 
Il ragionamento e' semplificabile:
Il cliente si chiede "quanto guadagno/risparmio adottando questo 
cambiamento?"
In questo caso stiamo volutamente escludendo il filone dell'adeguamento 
normativo, tipo cambiamenti dell'iva, passaggio dalla lira all'euro, 
cavallette ed altre cose simili.
Il "poco" o "troppo" diventa relativo al volume di affari del cliente.
Prendi l'esempio di un programma, lo scrivi una volta, e poi lo puoi 
utilizzare su N computer di N clienti.
Un conto decidere di adottare quel SW per 5 client, un conto per 1000, 
nel primo caso il costo puo' essere troppo, nel secondo poco.
 
Ciao.
 
M.
-- 
Credo che l'unica cosa da fare sia non prendersi troppo sul serio,
ridersi addosso, e sorridere spesso, così le rughe andranno nei posti 
giusti....
(A. Vincenzi)

 E si finisce in un ginepraio... :-)
 
no, ci scendi solo se fai il tecnico.
 
Ok, non esistono prodotti con funzionalità uguali. Però esistono
diverse soluzioni che soddisfano l'esigenza.
 
Prendiamo un software per la gestione della produzione di cetrioli :
 
IBM, SAP, ed una SRL fanno l'offerta.
 
software diversi, funzionalità diverse, stessa esigenza risolta : la
gestione della produzione dei cetrioli. Per il cliente sono
comparabili al netto delle differenze, che però nel caso dei cetrioli
sono irrilevanti (la loro produzione è troppo semplice, tutti i
software fanno tutto quello che è richiesto).
 
 
 

 attuali. L'aspetto estetico del sito tralasciamolo.
 
nel caso in esame, da qualsiasi prospettiva bello = ininfluente.
 
conta solo "funziona", perchè il bello è soggettivo, se fosse brutto (ma 
poi brutto per chi?) e funzionante cambierebbe qualcosa?
 

 fare il nuovo ?
 
Credevo di aver scritto l'opposto, colpa dei corsi di management che ti 
inculcano il concetto del progetto per "gestire" il cambiamento.  ;)
In maNnagerese il progetto e' uno strumento che utilizzi per dare una 
risposta ad una nuova esigenza, che poi lo strumento sia composto di 
flussi, processi, task, etc. e' un altro discorso, cosi' come il fatto 
che per andare avanti "consumi" risorse, economiche, temporali, "umane", 
et. et.
Ci si riferisce al progetto come un monoblocco, poi e' il PM che tiene 
d'occhio le varie componenti, tramite i riferimenti per le specifiche 
attivita'.
Esempio pratico, sei un manager, vai dal boss e gli dici "adesso 
spendiamo 1000 per fare [quello_che_facciamo], investendo nel progetto 
200 riusciamo a fare [quello_che_facciamo] con 500, quindi con un 
risparmio netto di 300", se lo convinci pacche sulle spalle e via, 
altrimenti non si fa nulla.
 
Ciao


 nel caso in esame, da qualsiasi prospettiva bello = ininfluente.
 
Ni, quando il "bello" semplifica le spese di "manutenzione evolutiva" 
torna ad influire, e torniamo al tuo discorso (imho corretto) di valore 
"attribuito".
 
Ciao
 
M.
-- 
Credo che l'unica cosa da fare sia non prendersi troppo sul serio,
ridersi addosso, e sorridere spesso, così le rughe andranno nei posti 
giusti....
(A. Vincenzi)

 Per me è fondamentale che funzioni e che costi poco .
 
"che funzioni" non vuol dire nulla.
 
se io ti chiedo un software per fare una certa cosa tu non puoi
presentarti con uno che ne fa un'altra secondo il principio che
secondo te la cosa fondamentale è che funzioni. la cosa fondamentale è
che funzioni nel fare quello che deve fare e *come* lo deve fare,
forse la ritieni un sottinteso ma dentro a quel distinguo ci stanno le
scelte tecnologiche.
 
inoltre caratteristiche come:
 
- scalabilità
- modularità/espandibilità
- performance
 
che nell'immediato non ti vengono richieste, dove le cataloghi? in
quello che chiami "bello"?
 
giusto per capire.

 risultato = si riesce a vendere
 
ah ah! Ecco un parere interessante.
 
Quindi venderesti anche la cacca dipinta per cioccolata se tu trovassi
qualcuno che te la compra ?
 

 quello che chiami "bello"?
 
Si, per semplificare moltissimo. Chiamiamole bello e buttiamoci dentro
tutto.


L'hanno già fatto e c'hanno fatto pure un sacco di soldi.
 
M,

 "attribuito".
 
Ok, mi piace il concetto di valore "attribuito".
 
E' ovvio che io posso scrivere un e-commerce in un super linguaggio
super controllato e super sicuro ed attribuirgli un grosso valore.
 
Ovvio anche che il mio valore attribuito è solo mio, il cliente mi
dice di darmelo in faccia. Quindi torniamo alla domanda quando è che
costa poco ?
 
Proviamo a dire che "costa poco" quando in ogni fase ed in ogni scelta
del processo di formazione dell'offerta il costo è stato messo allo
stesso piano del funziona.
 
Ovvero costa poco se non ho mai sacrificato il costo per il bello,
ovvero se ho fatto tutte le scelte in una funzione economica di
efficienza ed efficacia.
 
Con questa definizione un e-commerce dedicato ai piccoli clienti
potrebbe costare poco se costa 100 euro ed uno dedicato ai grandi
potrebbe costare poco anche costando 1 milione di euro. L'importante è
che tutte le scelte siano fatte in un'ottica economica.
 
 
 
 
 

 costa poco ?
 
Quando la cifra da sborsare e' tale che il cliente la accetta e ti fa 
fare il lavoro.  ;)


 Se non ti accetta il preventivo ... ...
 
no, il suo è un parere ininfluente, per lui costerà sempre troppo. Se
non accetta i preventivo o è perché il tuo concorrente lo fa meno
(quindi decide il mercato non il cliente )  oppure perché l'esigenza
non vale i soldi investiti o perché una soluzione manuale è più
conveniente.
 
In qualunque caso non decide lui, usa ma fattori esterni che lui
interpreta.

 interpreta.
 
Nein, decide lui, sulla base di considerazioni che coinvolgono "fattori 
esterni che lui interpreta".
 
Ciao


 l'obbiettivo è sempre soddisfare un'esigenza.
 
Diciamo che se nella vita si seguisse sempre e comunque il criterio
economico-ingegneristico del minimo costo per soddisfare l'esigenza
oggi invece del Colosseo avremmo un bel prato con qualche pietra qua e
là.... :-)

 deve. Non includo il come. Lo fa, come non si sa.
 
"L'esigenza" in genere non e' "una".
 
In genere nei corsi per PM dicono che un progetto e' "di successo" se
soddisfa "tutti i requisiti", i quali requisiti non e' detto che siano
solo tecnici (anzi). Qualcuno dice che e' 'di successo' se soddisfa "il
completamento delle attività entro i vincoli di tempo, costi e
qualità/prestazioni".
Pero' non e' detto che tra i requisiti iniziali ci siano solo tempo, costi
qualita' e prestazioni.
 
In ogni caso il successo o meno del progetto dipende da quali erano i
requisiti iniziali che chi lo ha pensato si proponeva di soddifare con
tale progetto (NB: non solo i requisiti tecnico funzionali, ma anche il
costo, il guadagno, il tempo che si volevi perdere in quel progetto,
ecc.)".
 
Se tu ad esempio inizialmente dici: "mi serve un software che sia in grado
di spedire SMS e mi serve che sia realizzato in 6 mesi da oggi con un
costo inferiore ai 50.000 Euro e che sia rivendibile ad almeno 100.000
Euro entro un mese dalla data di realizzazione", il tuo progetto avra'
avuto successo se:
 
a- riesci ad avere il software che spedisce sms entro i 6 mesi  (se li
spedisce "tecnicamente bene" o "tecnicamente male" poco importa [ad
esempio alcuni potrebbero considerare sufficiente un software che non
spedisce sms verso operatori virtuali, altri potrebbero considerarlo non
sufficiente. Dipende cosa avevi specificato nei requisiti iniziali) 
 
b- spendi meno di 50.000 Euro per realizzarlo
 
c- lo rivendi entro un mese da quando e' pronto e lo rivendi ad almeno
100.000 Euro
 
a, b e c devono essere in "and".
 
NB: per come e' formulato il terzo requisito potrebbe accadere che tu il
software lo riesci a realizzare in 3 mesi, ma poi devi aspettare 2 mesi
per venderlo (quindi complessivamente 5 mesi). Per come e' formulato il
terzo requisito questa situazione potrebbe far diventare il progetto "un
insuccesso" a differenza del caso in cui tu il software lo riesci ad avere
entro 5 mesi e lo vendi esattamente dopo 1 mese che ce lo hai (dipende se
il terzo requisito  e' formulato male oppure e' proprio intenzionalmente
in quel modo. Cioe' se proprio non voglio aspettare piu' di 1 mese per
vendere il software da quando ce l'ho pronto => se devo aspettare 2 mesi,
c'e' almeno un requisito che non e' stato rispettato).
 
Non e' importante se la situazione possa essere ritenuta "stupida" o meno
(cioe' non e' importante se il fatto di avere il software in 5 mesi e
venderlo dopo un mese sia piu' o meno stupido che non avere il software in
3 mesi e venderlo dopo 2 mesi: se chi ha scritto i requisiti intendeva
proprio che il software non deve stare fermo piu' di un mese allora la
seconda situazione rende il progetto "non di successo", perche' uno degli
obiettivi non e' stato rispettato)
 
Probabilmente e' anche per questo che si vedono in giro delle schifezze:
nel senso che spesso i requisiti tecnici non fanno parte dei requisiti che
il progetto deve rispettare, quelli economici invece fanno sempre parte
dei requisiti da rispettare => se tecnicamente e' una schifezza ma rientra
nei costi => ok. Viceversa => non ok.
 
Ciao,
Marco.


Per me è fondamentale che funzioni e che costi poco .
 
 
 
OLD.
 
1) posso farlo velocemente
2) posso farlo bene
3) posso farlo che costi poco
 
Scegliene due fra queste tre.
 
 
ciao
fm 
 
 


 
Nel senso che nel 2012 tutti i sw dovrebbero nascere strutturati per 
soddisfare se non tutte e 3 quelle caratteristiche almeno le prime 2? (anche 
se la terza è pareccio collegata alla prima).
Ma tutti i sw, tutti tutti.
 


ed e' capitato piu' spesso di quanto si immagini. 
 
 

 risultato = funziona
 
visto che altri hanno risposto, proviamo a concentrarci su questo. Cosa vuol 
dire 'funziona' ? perche' le aspettative possono essere moooolto diverse. Il 
comparto IT dice che funziona se non ci sono errori, se le specifiche 
'tecniche' sono rispettate, se le transazioni sono scritte bene, se ... ecc 
ecc ecc ... Ma attenzione: il management potrebbe vedere la cosa in modo 
molto diverso: non e' una novita' (e non vi scrivo niente di nuovo) che il 
comparto <> da IT veda il software come qualcosa per ridurre i costi, per 
organizzare (o riorganizzare) una struttura o un dipartimento, ecc ecc ...
Non e' detto che un software 'funzioni' per il comprato IT ma non funzioni 
per chi l'ha commissionato.
 
my 2 cents
 
Andrea
 
 

 tutti tutti.
 
ma non è questione di 2012 o non 2012. in tutti quei casi si tratta di 
*investire* parte dei margini dello sviluppo a favore dell'azienda. è 
chiaro che se non investi lo sviluppo ti costa meno ma è altrettanto 
chiaro che la penalizzazione che ne ricavi nel medio periodo è molto 
maggiore di quanto hai risparmiato.
 
prendi ad esempio la modularità: tu puoi anche sviluppare un software 
fregandotene di renderlo da subito facilmente espandibile, ma è evidente 
che se il software non potrà avere evoluzioni non le avrà. e se non avrai 
evoluzioni tu con quel software (e probabilmente anche con quel cliente) 
ci guadagni zero tondo. 
 
ma quella di equinozio non è mica una idea granché originale, anzi, quasi 
tutti i piccoli fanno così. io li chiamo "produttori di abandonware" cioè 
tutta quella selva di programmi che hanno un ciclo di vita di tre, 
quattro, sei mesi al massimo dopodiché il produttore ne perde totalmente 
le tracce (salvo ovviamente correzioni bug, su cui magari spendono la 
faccia nel vano tentativo di farsele pagare).

 tutto.
 
ok, ma di preciso la differenza fra questo e la peracottaggine in cosa 
consisterebbe?
 


Giochetti per telefoni e poco altro?
Perché a me verrebbe da dire che sono di nicchia, ma nicchia forte.
Mai visto, non che abbia girato chissà quante realtà per carità, sw che non 
debba evolvere oltre la semplice manutenzione fatta magari più per bug 
fixing che altro.
Anzi, par tanto che proprio sull'approccio di nuove funzionalità si combatta 
anche lato commerciale per cercare di piazzare le soluzioni a nuovi clienti.
 

 "rootkit" ha scritto nel messaggionews:pan.2012.04...@email.it...

Dipende dalle realta', nelle startup scrivere software per scopi
prettamente esplorativi e' particolarmente comune.
Per esempio: 
http://en.wikipedia.org/wiki/Minimum_viable_product
 
 
  ngw


 
Leggesi prototipi?
Ma dipende da cosa devi prototipare.
In ogni caso, per i prototipi che hanno fatto centro, quanto è frequente 
considerare il prototipo come praticatemente il prodotto finito? O comunque 
come base reale da far evolvere, non certo come; ok, possiamo ripartire da 
zero con lo svilulppo e lo rifacciamo strutturandolo meglio.
 

 consisterebbe?
 
sul fatto che funziona, che soddisfa l'esigenza. La peracottaggine no,
per definizione.
 

 là.... :-)
 
non vero.
 
Se i requisiti prevedono :
 
-deve essere imponente ed impressionare
-deve contenere x spettatori e tutti vedere bene
-deve essere in centro a Roma
 
avresti il Colosseo pieno di statue.

 faccia nel vano tentativo di farsele pagare).
 
I miei veramente hanno un ciclo di vita di tre, quattro, sei anni. Ed
ovviamente hanno pochissimi bug, altrimenti andrei fallito visto che
poi li manutengo quasi a gratis....
 
 

 sotto una certa cifra.  ;)
 
No, il cliente non decide proprio niente. Se lui propone x/2 io il
lavoro non lo faccio e neppure nessun concorrente. Se un concorrente
accettasse il prezzo lo farebbe il concorrente e quindi il mercato !

 molto diverso: non e' una novita' (e non vi scrivo niente di nuovo) che il
 
Bella questa !
 
Cioè te dici, non siamo d'accordo neppure sul "funziona", perché
funziona per l' IT  e funziona con il Management sono due funziona
diversi. E le esigenze dell'uno non sono quelle dell'altro.
 
Ok, per me funziona è funziona per il Management.... per l'IT mi basta
che segua e rispetti le regole minime di qualità (installazione
standard, esecuzione senza privilegi, transazioni chiuse).

 Scegliene due fra queste tre.
 
si c'ho pensato, però le tre grazie sono diverse.

 Giochetti per telefoni e poco altro?
 
ma quando mai? sto parlando di una bella fetta di software sviluppato nel 
corso di "consulenze" e che gira in aziende italiane.
 
potrei raccontarne a decine ma ti racconto la più recente: la scorsa 
settimana un cliente mi fa vedere che ha in linea da circa tre anni un 
"jar" come java stored procedure di oracle (no comment) che viene 
richiamato per fare periodiche operazioni batch, doveva fare una corposa 
modifica. contattato il fornitore, che nel frattempo ha fatto diversi 
altri lavoretti essendo considerato un riferimento per un certo tipo di 
procedure, gli ha risposto prima brocciolando qualcosa a riguardo di un 
programmatore che se n'era andato, poi ha detto che non era sicuro che i 
sorgenti fossero allineati alla produzione, infine tagliato corto dicendo 
che lui quelle modifiche a quel programma "fuori manutenzione" non 
l'avrebbe fatte. così il cliente ha chiesto a me cosa si poteva fare. io 
gli ho decompilato il jar e gli ho mostrato in tutta la sua evidenza il 
motivo per cui il fornitore si è rifiutato di metterci le mani, ovvero un 
gran merdaio. ora non so come andrà a finire (abbiamo una riunione 
martedì) ma l'unica certezza è che hanno già cominciato a scaricare quel 
fornitore e a giugno con quel cliente non avrà più niente da fare. 
 
ah per la cronaca quel programma ha *sempre* funzionato, eppure non ho 
mai visto in vita mia un fornitore trattato in quel modo da un cliente.  

 mai visto in vita mia un fornitore trattato in quel modo da un cliente.
 
Io ho visto di tutto e di piu'...
 
Trovo la risposta del fornitore perfettamente allineata ad una
logica commerciale.
Se il suo business e' "non voglio 100 da 1 ma 1 da 100 ",
allora gli puo' capitare di dover rispondere
"non sono interessato a queste modifiche, quindi  non le faccio ".
 
Cliente perso?...avanti il prossimo.
 
E non e' nemmeno che sia finito il tempo delle vacche grasse,
un minimo di selezione fra le richieste della clientela e' sempre stato 
fatto,
anche da quelli che di manovalanza ne avevano parecchia...
 
ciao
fm
 
 


Si vede che si fida di voi, chiaroto che la modifica gli serve e gli altri 
non possono farla, allora vi sta facendo vedere che succede se non gli fate 
il lavoro fatto bene... :-)
 


che sul lavoro si seguano logiche commerciali è fuori discussione.
 
premesso che quello è un cliente che quasi mai discute i preventivi che 
chiede e quello che è ragionevole pagare lo paga senza fiatare, di questo 
mi spiace ma ti devi fidare della parola (se un giorno ci incontreremo in 
un contesto dove è opportuno fare nomi e cognomi te li farò volentieri). 
 
detto questo: se tu fornitore non sei in grado di formulare un'offerta 
per una evoluzione ad un tuo programma perché già presupponi di non 
rientrare nei costi si tratta ovviamente di un *tuo* problema. io dico 
che sei tu, fornitore, a gestire i tuoi progetti ancora come ai tempi 
delle vacche grasse, quando la questione l'avrebbe risolta affittando una 
o più persone al cliente per il tempo necessario senza dover preventivare 
quanto.
che poi di questi tempi a perdere un cliente fidelizzato si possa dire 
allegramente "avanti il prossimo" permettimi di sollevare qualche dubbio, 
almeno qui in toscana. poi dove sei te non lo so.
 

 gli fate il lavoro fatto bene... :-)
 
senza falsa modestia da questo punto di vista siamo abbastanza 
tranquilli. poi per carità i rapporti di fiducia si possono rompere per 
mille altri motivi.
 

 quanto.
 
Infatti e' un problema *del fornitore*.
Come era un problema anche il "merdaio" che avevano scritto...
solo che finche' c'era la persona che in qualche modo sapeva
cavarne le gambe, per il Cliente questo problema non esisteva,
pagava e basta.
 
Ma prima o poi i nodi arrivano  al pettine ...
 
E' giunto il momento di riscrivere quel programma ...:-)
 
ciao
fm
 
 
 
 

 avresti il Colosseo pieno di statue.
 
Non è tanto questo. Strutturalmente il Colosseo è probabilmente molto
più massiccio di quanto richiesto perchè stia in piedi abbastanza bene
per un normale numero di anni, soddisfacendo pienamente i "requisiti"
che dicevi. In altri termini nei calcoli hanno usato il coefficiente
di sicurezza 100x, tanto per essere sicuri :-)
 


Infatti il prezzo lo fa il mercato!  :)
 
E nel nostro settore di concorrenti che facciano il prezzo piu' basso e' 
pieno...



Il fatto che sia arrivato fino ad oggi, e che all'epoca ci fosse anche 
una copertura mobile dice che l'ingegneria fosse tenuta in maggiore 
considerazione all'epoca che oggi.
Per la manodopera il costo era abbastanza basso, grazie agli schiavi, un 
po' di materie prime si potevano saccheggiare qua e la come bottino di 
guerra, "alimentando" lo show con delinquenti e prigionieri di guerra si 
risparmiava anche sulle carceri.
Alla fine non credo che sia costato tanto.
Gli antichi romani non erano stupidi, ci siamo rovinati con il tempo.
Oggi ci si guadagnerebbe anche con i diritti televisivi e le 
pubblicita'.  :)


 pieno...
 
... ok, allora il prezzo lo fa il mercato. Ma non basta, il mercato
non basta, non è solo lui farlo. Io lo vivo come un entità astratta
esterna ed i miei clienti pure, non esiste un mercato perfetto del
software. Il prezzo non lo fa solo il mercato.

 accettasse il prezzo lo farebbe il concorrente e quindi il mercato !
 
Scusa, ma nella frase precedente, quando dici "se lui propone x/2...", il
pronome "lui" quale sostantivo sostituisce ?
 
Perche' se sostituisce "il cliente" allora non saprei quale possa essere
un prezzo piu' fatto dal cliente di questo.
 
Ciao,
Marco
 
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 

 software. Il prezzo non lo fa solo il mercato.
 
Anche se  tu lo vivi come entità astratta tu stesso sei parte integrante 
di quel mercato nel momento in cui offri qualcosa ad un certo prezzo e 
non lo fai sicurametne in astratto.


la peracottaggine, per definizione, lucra sui costi di sviluppo
esattamente come vai dicendo te.
 
quanto al funzionare tu m'insegni che ci sono tanti modi per far
funzionare un software agli occhi del committente, si può farlo
funzionare affrontando le problematiche con lo stato dell'arte e si
può farlo funzionare nascondendo le problematiche sotto il tappeto.
gli esempi nelle applicazioni web si sprecano te ne faccio uno a caso,
la sicurezza: il tipico approccio del peracottaio è che se non serve
(vedi intranet) non si implementa o (peggio) si implementa alla
carlona giusto per far vedere che c'è una login, col risultato che si
innesca la classica bomba ad orologeria. ma è giusto un esempio a
caso, perché il concetto è che il programmatore quando realizza un
software oltre a quelle del dominio applicativo ha delle criticità che
sono di *sua* competenza e che è *tenuto* in taluni casi a sollevare
al cliente e in altri casi implicitamente a risolverle. chi non lo fa
è un peracottaio e basta.

 non lo fai sicurametne in astratto.
 
questo è ovvio.
 
ma non è l'unica cosa. C'è anche un concetto dei "prezzo onesto" che
prescinde il mercato.

 (vedi intranet) non si implementa o (peggio) si implementa alla
 
si però il fatto che sia implementata la sicurezza e che questa
funzioni rispettando  gli standard minimi  lo mettiamo nel funziona.
Lo so che gli "standard minimi" sono già spesso fantascienza per i
software che girano in alcune aziende Italiane ma qui almeno diamolo
per scontato.
 
Sicurezza, strumentazione, log, e consistenza transazionale devono
essere scontate, altrimenti siamo davanti a una roba che non funziona
(nel 2012 lo si può dire).

 Alla fine non credo che sia costato tanto.
 
Ma certo, è costato solo qualche guerra vittoriosa per catturare i
prigionieri necessari :-))

 software. Il prezzo non lo fa solo il mercato.
 
Ma come, ti ribelli al mitico mercato?? Questa entità suprema ed
ineffabile che decide tutto lui. Ormai anche il pizzicarolo, di fronte
alla tua protesta per l'aumento del 100% del prosciutto cotto, ti
risponde: eh, ma sa, il mercato... :-))
 
 

 è un peracottaio e basta.
 
Questo che dici è un esempio di professionalità più completa,
superiore se vuoi, che come tale e come è giusto ha un prezzo
superiore. Dove per prezzo intendo in senso lato lo sforzo di
realizzazione, con maggiori tempi, migliori strumenti hardware e
software, ecc.
Tutto questo però deve essere recepito ed apprezzato dal cliente, il
quale non è un automa fatto in serie. Ci può essere quello che per
qualche legittima ragione speciale non ha bisogno di tutta questa
professionalità, e pertanto non intende pagarne i costi (nel senso
lato che si diceva).
Negare che questo possa, ripeto, legittimamente accadere è sbagliato.
Poi chiaramente tutti noi abbiamo piacere a situarci nella fascia alta
della clientela, che apprezza e richiede certe soluzioni di qualità
elevata.
 


Se tu consideri un prezzo onesto X ma quello che e' disposto attualemtne 
a pagare chi domanda e' X-100 a parita' di prestazione e qualità 
percepità e' poco probabile che tu riesca a incontrare la domanda.


Come dicevi prima, siamo tutti parte del mercato. Ma tu lo intendi
solo in modo passivo, cosa errata. Il mercato non lo subiamo
solamente, siamo anche attori. E possiamo cambiarlo, anche
profondamente, in modo inaspettato.
Nel momento in cui io programmatore-individuo parlo col tale cliente-
individuo l'astratto mercato non esiste più, conta ciò che riesco ad
ottenere in questo rapporto diretto, personale.
Ecco perchè sostanzialmente il mercato non esiste. E' un comodo alibi.
 
 


 
e' il concetto di "costa poco" che non condivido, meglio sarebbe dire "costa il
giusto", perche effettivamente anche in economia si studia il giusto prezzo, non
il poco prezzo.
 
Ci metto pure un piccolo anedotto personale (che con l'informatica c'entra una
sega ma rende l'idea sul giusto prezzo), i miei genitori poco tempo fa hanno
dovuto rifare il top della loro cucina.
Si sono rivolti ad un rivenditore della marca di cucine vicino casa (non lo
stesos da cui avevano acquistato a suo tempo la cucina). 
Preventivo del top: X euro a metro lineare + Y euro manodopera + Z euro
smaltimento materiale (in soldoni si parlava di circa 4k euro).
 
4 cucuzze sono un po' troppe, il babbo va da famosa catena di fai da te), il
preventivo e' il seguente:
Costo top (stesso tipo di materiale e finitura beninteso): X/4
Manodopera = 150 euro
Smaltimento materiale= non previsto a totale carico del committente. (totale
1.650,00 euri)
 
Poi il babbo s'attacca al telefono e chiama la sede della ditta produttrice
chiedendo semplicemente i nomi di 3 o 4 rivenditori su Roma, glieli danno, va
dal primo, questo il preventivo:
Costo top X/3
Manodopera 250 euro
Smaltimento materiale 130,00 (il costo del conferimento in discarica)
(totale preventivo sui 2k euro), poi pero' il venditore gli offre pure un nuovo
lavandino, un nuovo forno ed un nuovo piano cottura per altri 1k euro circa)
totale mio padre ha speso 3k euro e spicci ha comprato quello che voleva e
qualcosa in piu'. Dove sta il giusto e dove sta' lo sbagliato a voi giudicarlo.


Appunto, non esiste prezzo giusto o sbagliato, "di mercato" o "fuori
mercato". E' una magari utile semplificazione per dare una qualche
base agli studi "scientifici" dell'economia. Poi tuo padre aveva tempo
ed ha fatto la sua indagine "di mercato" ed ha scelto quello che per
lui è il meglio (che non è neppure il costo più basso a parità di
lavoro, a quanto ho capito). Un'altro non aveva tempo e voglia e si
prendeva quello a 4000 euro, un'altro prendeva quello al prezzo più
basso. Avrebbe sbagliato? Non è detto.
 

 potranno durare anche solo 2-300 anni?
 
L'Aquila dice di no.  :(
 
Ciao
 
M.
-- 
Credo che l'unica cosa da fare sia non prendersi troppo sul serio,
ridersi addosso, e sorridere spesso, cosě le rughe andranno nei posti 
giusti....
(A. Vincenzi)

 L'Aquila dice di no.  :(
 
A quale edificio "ambizioso" crollato a L'Aquila ti riferisci?
(intendo con ambizioni tipo Colosseo, settima meraviglia del mondo :-)


Ah, ambiziosi in quel senso non c'erano.
Credo che le ultime ambizioni in tal senso siano quelle del castello, 
che se ricordo bene era del '500 o giu' di li'.
Ne e' uscito provato anche lui, ma costruzioni recenti (anche se meno 
ambiziose) se la sono cavata peggio.
 
Ciao
 
M.
-- 
Credo che l'unica cosa da fare sia non prendersi troppo sul serio,
ridersi addosso, e sorridere spesso, così le rughe andranno nei posti 
giusti....
(A. Vincenzi)

 Ecco perchè sostanzialmente il mercato non esiste. E' un comodo alibi.
 
Io non lo intendo affatto in maniera passiva  ma e' un dato di fatto che 
se c'e' troppa offerta a parità di qualità chi offre ha un minore potere 
contrattuale che poi possa essere bilanciato da una fidelizzazione del 
cliente e' un altro discorso ma dipende appunto da cliente a cliente.Ci 
sara' quello che ti dirà continuo con te perche' mi fido e quello che ti 
dirà che costi troppo. Solo che il numero dei primi e' probabilmente di 
gran lunga inferiore ai secondi viste le regole economiche in cui si 
muovono i soggetti. Le situazioni particolari ci possono essere ma il 
livellamento dei prezzi   verso il basso per eccesso di offerta c'e'.

 elevata.
 
permettimi di dire che non è vero e per più ragioni.
primo, l'ho già detto, in un progetto ci sono delle criticità che è di
competenza di chi realizza il software farle emergere all'attenzione
del committente quando non è tenuto implicitamente a risolverle.
secondo, ci sono anche delle criticità che riguardano me come
programmatore e non il committente perché non hanno impatto diretto
con la funzionalità, vedi ad esempio la modularità e la manutenibilità
del prodotto.
 
e poi permettimi di discutere anche di questa presunta "fascia alta
della clientela". quello di cui io sto parlando è per lo più know-how
del produttore di software che una volta acquisito non è un costo che
ricade drammaticamente sul singolo progetto, per dirla in altre parole
non si sta parlando di features per clientela d'alto bordo. per fare
sempre un esempio personale: io lavoro per lo più in java e per quanto
riguarda la sicurezza ho già scelto il framework che mi serve, motivo
per cui se vedessi il cliente che ha bisogno (ipotesi) di integrare in
un sso non ho problemi a proporlo senza aggiungere 100 giornate al
progetto. lo stesso dicasi della modularità, le mie applicazioni sono
osgi-based per cui mi costa *zero* fornire il supporto per una
architettura a plugin o addirittura un sistema di aggiornamenti
automatici. poi è chiaro, il commerciale queste cose giustamente mica
le regala (anche perché contrariamente a quello che si dice chi ha il
braccino corto preferisce spendere meglio, non meno), però non ha
bisogno di sparare chissà che cifre e soprattutto sono pressoché puro
guadagno per l'azienda.
 
 

 ambiziose) se la sono cavata peggio.
 
Molto bello il castello, che è proprio del '500. Molto triste che
abbia avuto anch'esso dei crolli (un pò più giustificati delle case
moderne). Dentro c'era un'ottimo museo dell'arte abruzzese e non solo.
 

 livellamento dei prezzi   verso il basso per eccesso di offerta c'e'.
 
Ma certamente c'è influenza della situazione esterna su ognuno di noi.
Però volevo dire che tutti noi abbiamo una possibilità di mutare le
cose, magari piccola.
L'aneddoto di Suarez te lo dice, ognuno di noi ne può raccontare
qualcuno, in ambito IT e non.
 


Io penso che un certo grado di qualità e rifinitura (sicurezza,
modularità,..), come dici, è disponibile praticamente a costo zero in
aziende che questo background se lo sono sudato. Cioè è un costo
incluso nella tariffa generale, (come nel tuo caso, immagino) che sarà
inevitabilmente più alta dell'azienda meno organizzata.
Poi alla fine la decisione spetta al cliente, francamente non mi
sembra automaticamente delittuoso che talvolta si voglia rinunciare a
qualche cosa in cambio di prezzo minore.
 
 

 manutenibilità compresa )
 
scrivo qui, non saprei a quale post attaccarmi. Proprio in questi giorni 
hanno consegnato un software. Tra le varie cose ... ha una certa 
'trascodifica' in ragione di una certa 'classificazione' IVA (perdonatemi se 
sto sul vago, visto mai che gli autori leggano ILI) . Hanno scritto la 
trascodifica 'a codice': non una tabella, non un file .ini, niente di 
niente. Per cambiare una trascodifica si devono modificare i sorgenti e 
ricompilarli.
 
Mentre noi discutiamo di commenti vs documentazione, ancora oggi (nel 2012) 
c'e' chi fa i lavori a questo modo :-)
 
Andrea
 
 
 
 

 ricompilarli.
 
Allora, nel 2012 secondo me bisogna che adeguino il programma gratis o
che rinuncio a parte del compenso. In caso contrario bisogna
chiedergli i danni per manifesta inadeguatezza del software fornito.
 
Cioè è l'ora di passare alle vie legai per una cosa del genere, non
sono più tollerabili se non a fronte di una accettabile
giustificazione (ad esempio per software che devono durare 6 mesi)
cose del genere. Ci perdiamo TUTTI con questi peracottari in giro.

 2012) c'e' chi fa i lavori a questo modo :-)
 
questi sono dei geni, altro che. geni del male ma sempre dei geni. 
nell'anno in cui ci sono due cambi aliquote di cui uno previsto 
presentarsi con i codici hard-coded ci vuole un fegato ammirevole...
 

 presentarsi con i codici hard-coded ci vuole un fegato ammirevole...
 
Vedi, il cliente di solito percepisce le proprie richieste come delle
"cazzate", che "premi un pulsante" ed è tutto pronto.
Per cui lo sviluppatore ha due strade:
 
1) scrivere una cagata hard-coded che costa X
2) scrivere un file di configurazione / tabella di configurazione /
classe di configurazione che costa X * n, con n grande a piacere
 
e alla fine dei conti il cliente non pagherà mai più di X.
 
Poi succede che, ovviamente, se avesse speso X * n fin da subito avrebbe
speso 0 dopo; e invece... per ogni modifica richiesta, gli toccherà di
nuovo spendere X (e s'incazzerà).
 
 
 
Se vuoi seguire la seconda strada devi essere mooolto bravo a far
percepire al cliente che quella cosa non è così banale, che spende di
più all'inizio e poi di meno dopo (anzi, nulla), e che se sceglie la
prima poi sono cazzi suoi se ogni volta che cambia la virgola deve
spendere X ....
 
Insomma, ci vuole un buon supporto commerciale / manageriale e scrivere
tanto supercazzole nero su bianco che ti parano il culo.
 
M.

 tanto supercazzole nero su bianco che ti parano il culo.
 
beh a me risulta che se tu tentassi di far percepire ad un ragionier
filini qualsiasi che per cambiare la codifica delle aliquote iva
bisogna farlo fare a pagamento alla software house puoi stare certo
che il tuo bel gestionale te lo tira (giustamente) dietro un byte
dietro l'altro.
queste sono peciottate che le software house pagano in prima persona,
eccome se pagano. non escludo che qualche commerciale abbia la faccia
di bronzo di provarci a far percepire che queste sono features a
pagamento, ma il fatto di riuscirci più che alla bravura lo legherei
alla capacità di inc...re il prossimo.


Vedilo come un investimento per il futuro (il _loro_, non quello del
cliente).

 cliente).
 
non lo so, c'è da prendere anche qualche macete sulla schiena andando
per clienti a venderle come feature a pagamento :P
 


This one screams: "On Site Customer"!


Nei paesi in cui ho lavorato io, Italia compresa, i clienti sono
troppo civili per tenere dei machete in ufficio. Tocca sperare nelle
asce antincendio.

 Ci perdiamo TUTTI con questi peracottari in giro.
 
questi (assieme ad altri) lavorano con l'azienda da ANNI ! La cosa che mi ha 
'spaventato' e' che non hanno battuto ciglio: e' bastato dirglielo e hanno 
detto 'ok'. Noi non siamo piu' una azienda con cui fare il bello e il 
cattivo tempo (e fatturare di conseguenza) , oramai l'hanno capito. E quel 
che mi sembra di capire e' che un cliente da -non spennare- non gli 
interessa nemmeno ...
 
 

 per clienti a venderle come feature a pagamento :P
 
no dai, a quello non ci sono ancora arrivato :-) al massimo gli riduco il 
fatturato da X a X/10 
 
 

 M.
 
Andrea
 
 

 questi (assieme ad altri) lavorano con l'azienda da ANNI !
 
come dice il detto? dio li fa e poi li accopp(i)a.