Roma – Manca ormai un mese all’edizione 2011 del Pwn2Own , la celebre sfida di hacking ospitata dalla convention sulla sicurezza CanSecWest che mette sotto torchio i principali browser web. Lo scorso anno Safari, Internet Explorer e Firefox hanno tutti ceduto agli exploit degli esperti iscritti al contest. L’unico browser ad opporre resistenza ai colpi degli hacker è stato Chrome .
Per l’edizione di quest’anno la commissione del Pwn2Own aveva deciso di non scomodare il software di navigazione marchiato Google. La motivazione ufficiale dell’esclusione verteva sul fatto che la “cavia” Chrome, fondamentalmente, si basa sullo stesso motore Webkit utilizzato dal browser Apple. Ma il colosso di Mountain View non ci sta: in un modo o nell’altro Chrome deve partecipare.
Dopo aver chiesto agli organizzatori dell’evento di riconsiderare la lista dei software inclusi, Google ha anche messo in palio una cifra extra (20.000 dollari) per ogni esperto di sicurezza che riuscirà a trovare una vulnerabilità nella blindatissima sandbox di Chrome.
BigG ha tirato poi in ballo il suo fiammante netbook Cr-48 , equipaggiato con sistema operativo Chrome OS. Gli “exploit writer” che riusciranno a vincere le protezioni innalzate dagli ingegneri Google otterranno in premio anche questo laptop.
Roberto Pulito
leggi i 115 commenti
-
E nel privato ?
Sarà ma anche nel privato vedo molte delle cose citate nell'articolo e nei commenti ... -
Il difetto della semplicità
Nell'organizzazione della cosa pubblica ci sono montagne di adempimenti informatizzabili che ben si presterebbero a semplificare gestione e controllo.Molte volte sono cose semplici che lievitano in progetti faraonici.Ben vengano le cose semplici ed efficaci meno gli orpelli.Quindi si parte con un progetto per farle, ma il progetto lievita, diventa un megaprogetto per cui l'utile si porta dietro l'inutile, la relativa complessità i relativi costi e pericoli di insucXXXXX.Storiella esemplificativa:Dobbiamo comprare un armadietto, andiamo allo store, scegliamo quello che ci piace compatibile con il nostro portafoglio, lo portiamo a casa, ci mettiamo su i libri.Una pubblica amministrazione si fa fare i preventivi, dato che paga tardi non ci si stupusce se glieli raddoppiano.Poi non possiamo comprare il 'modello base', se poi non va ci danno degli incompetenti, per non sbagliare prendiamo l'ultimo modello al titanio.Per non avere poi il collega che ti critica perché non ne hai comprato uno in linea con le nuove disposizioni (puro esempio) che entreranno in vigore il prossimo decennio, lo prendi con queste caratteristiche.Devi trovare il trasportatore che lo va a prendere e ti devi far fare il preventivo.Non lo puoi mettere tu ma devi trovare il posatore di armadietti (per evitare critiche), ti fai fare il preventivo.Poi ci sarà sempre il dipendente che lamenterà che un armadietto così difficile da usare richiede un apposito corso, ti fai fare il preventivo.Alla fine esce una cifra stratosferica, ma hai dato da lavorare al venditore di armadietti, al trasportatore, al posatore, al formatore, al dipendente che riceverà la formazione.Risultati:Caso 1:paghi un XXXXXio di soldi dove con un armadietto più semplice trasportato con la tua macchina, avresti avuto gli stessi risultati in un ora spendendo dieci volte meno.Caso 2:non ci sono soldi per comprare l'armadietto come 'ci serve', appoggiamo i libri per terra.Caso 3:il trasportatore non ha tempo, si ammala il formatore, fallisce la ditta, insomma avrai l'armadietto quando te ne serviranno quattro o semplicemente non arriverà mai.Caso 4:finalmente hai l'armadietto ma nessuno lo usa perché agli utenti piaceva giallo ed un armadietto di quel colore non lo useranno mai. -
Grazie per la censura... rammentero
Avevo risposto a questo messaggio...http://punto-informatico.it/b.aspx?i=3082733&m=3083425#p3083425Tra le altre cose con toni molto neutrali nel giudizio della classe politica.Nel senso che non desinavo critiche ne all'attuale "governo" ne tanto meno all'"opposizione"accusando quello che a mio modo di vedere è il vero problema italiano ossia la mancanza del Senso dello Stato dei Cittadini.Il bello è che è stato cancellato giorni dopo... in modo che tutto non fosse notato.Potete adesso raccontarmi (o raccontarvi?) della censura randomica che c'è qui http://nonciclopedia.wikia.com/wiki/Punto_Informatico#Sistema_di_moderazionela verità è che invece è molto mirata e selettiva... persino retroattiva a quanto pare.Davvero bravi.Ma ditemi il vero, confidatevi, alcuni degli anonimi sono anche redattori e quando qualcuno li mette con le spalle al muro (dialetticamente parlando) se lo lega al dito e gli rimuovete il messaggio?Ecco spiegato perché sembrano solo messaggi di Troll ... quelli un pò più articolati li rimuovete.Non è la prima volta che mi capita, ma censurare una stupida questione sui sistemi operativi, mi interessa il giusto... Su argomenti un "tantinello" più seri... mi fa rabbrividire.Brrrr.Congratulazioni! -
Servizi che non servono
Se ad un servizio internet internet creato , corrispondesse ad un servizio fisico spento il giorno dell'avvio (esempio:tutti i servizi al banco del comune sul web = chiudo sportello fisico in comune)TUTTI si lamenterebbero del progetto fallito,PERCHE' ne avrebbero bisogno SUBITO , invece così il sito non funziona , i manager hanno preso le loro belle mazzette ,e quelli dello sportello se la ridono,noi vediamo un sito che non va e non possiamo fare niente,se non pagare ogni anno il 40% di tasse.Insomma :evviva il paese delle banane. -
... e le responsabilità penali ...?
dove le mettiamo?La procedura obbligatoria ad uso dei medici di famiglia per l'invio telematico dei certificati di malattia implica il trattamento di dati medici, coperti dal D.Lgs. 196/2003 (legge sulla privacy).La legge ha messo nelle mani di questo sistema (in realtà di chi è titolare del trattamento gestito attraverso di esso) la responsabilità penale inerente i dati trattati.E la legge non parla soltanto di diffusione non autorizzata: la legge copre gli aspetti di riservatezza, integrità e DISPONIBILITÀ.I dati devono essere disponibili ai portatori di interesse quando ne hanno bisogno.I medici rischiano denunce penali per colpa degli incompetenti che hanno progettato, realizzato e collaudato il sistema.E ci sarebbe anche da aggiungerem credo, la responsabilità penale per l'interruzione del pubblico servizio: ribadisco, se un cittadino rischia il penale per la disfunzione del sistema, qualcuno deve assumersi le relative responsabilità.Ma finirà come sempre a tarallucci e vino, e poi nel dimenticatoio ...In ogni caso il Garante per la Privacy dovrebbe muoversi: il sistema tratta dati sensibili, e deve essere dotato di un DPS che comprovi tutte le misure adeguate adottate per assicurare la disponibilità delle informazioni agli interessati. -
Complimenti a PI
L'unico ramo di discussione interessante è stato amputato per motivi sconosciuti. Fate pena. -
"obbiettivi inconfessabili"
Sono questi che fanno fallire i progetti. E il Paese. -
Stato = mucca da mungere
E questa affermazione siamo noi che la rendiamo valida, intendo noi cittadini italiani abituati a questo andazzo. Abbiamo un'arma, il voto, ma chi la usa?-
Re: Stato = mucca da mungere
il voto serve solo se hai qualcuno da scegliere ...-
Re: Stato = mucca da mungere
- Scritto da: abacab
il voto serve solo se hai qualcuno da scegliere
...non sono tutti uguali, solo che devi dare una priorità a quello che vuoi secondo me. ad esempio, ci sono quelli che faranno leggi a favore della legalità, quelli a favore delle fasce più deboli, quelli a favore dell'imprenditoria, quelli a favore del federalismo, quelli a favore dell'ecologia, eccdevi solo decidere da cosa vuoi iniziare, non importa se non sono capaci di fare tutto-
Re: Stato = mucca da mungere
http://www.youtube.com/watch?v=OqPArh99deE -
Re: Stato = mucca da mungere
Io ho solo visto gente che ruba soldi e NON fa leggi o quando le fa fa solo XXXXXXX... da tutti o poli/fazioni/schieramenti... -
Re: Stato = mucca da mungere
- Scritto da: Lemon
- Scritto da: abacab
il voto serve solo se hai qualcuno da scegliere
...
non sono tutti uguali,E' vero.Ci sono i criminali, gli inutili e gli incapaci.Ma una cosa li accomuna, non vivono nel nostro stesso mondo e non hanno i nostri stessi problemi.Pretendere soluzioni da gente come questa, anche se fosse onesta e animata dalle migliori intenzioni è pura follia.
ad esempio, ci sono quelli che faranno leggi a
favore della legalità, quelli a favore delle
fasce più deboli, quelli a favore
dell'imprenditoria, quelli a favore del
federalismo, quelli a favore dell'ecologia,
eccSei un romantico sognatore.
-
-
-
-
it != ITALIA --
IT === "Bunga bunga"
EMPTY!!!EMPTY!!!non aggiungo altro -
In Italia
Il video riassume come funzionano le cose da noi:http://www.youtube.com/watch?v=jLvpXVWXDK4-
Re: In Italia
ROTFL .. purtropppo è verissimo
-
-
ingegneri
La progettazione non dovrebbe essere di politici, operatori dell'informatica autodidatti e così via... ma di ingegneri progettisti..... del terzo settore!-
Re: ingegneri
- Scritto da: Fabio De Agostini
La progettazione non dovrebbe essere di politici,
operatori dell'informatica autodidatti e così
via... ma di ingegneri progettisti..... del terzo
settore!riusciamo a fare enormi XXXXXte anche senza il loro qualificato aiuto.
-
-
Marco, continua così
Ottimo Marco.Ti prego di continuare così, con inchieste "alla report" o "iene" sull'inefficienza informatica della macchina statale.Spesso il semplice cittadino si chiede "ma perché non fanno così?" e il "così" è in effetti la soluzione logica e semplice. A volte, lo ammetto, mentre quasi sempre non è così. Ma accade spesso. Mentre invece altre volte è evidente che qualsiasi scelta non è nata da chi mastica la tecnologia da tempo e conosce potenzialità, pregi e difetti.Quindi continua, fai indagini, fai test e reportage "alla Attivissimo" che sicuramente farai cosa buona e giusta.Ad esempio chiediamoci anche: perché tutte le procedure amministrative/contabili (vedi sito entrate) costringono all'uso di una certa versione di java quando alla maggioranza dell'utenza (anche aziendale, se il sysadmin ritiene necessario aggiornare) viene richiesto di aggiornare per motivi di sicurezza la VM?Perché in altre, mi dicono ad esempio ministero della sanità, sembra sia suportato solo un certo browser e la procedura per il riconoscimento della smart card o della firma digitale sia piuttosto complicato?In ogni caso anche se siamo amanti della tecnologia (e quindi ci aspettiamo in quell'ambito almeno una parziale tecnocrazia) bisogna ricordare: ma perché il cittadino non informatizzato non ha alternative?Ok, sto uscendo dal seminato perché parli di ciclo interno alla PA ... però... per i prossimi numeri... di ciccia ce n'è, Marco: continua a metterla sul girarrosto! :)-
Re: Marco, continua così
sulle smart card e la firma è un delirio... io con la mia banca ho il generatore di codici che se volessi potrei usare per la firma (pagando il servizio) ... se lo fanno le banche non credo sia insicuro... ed è indipendente da qualsiasi OS,Browser o hardware... bho...
-
-
Progettazione&Realizzazione in generale
Io abito in un'appartamento in un condominio ex-167 (popolare) realizzato a fine anni '70 in un paese di piccole dimensioni. Dopo 30 anni di uso, io ci abito da 5, il condominio ha avuto bisogno solo di manutenzione ordinaria. Per capirsi la caldaia condominiale per il riscaldamento ha avuto solo la sostituzione del bruciatore per passare da gasolio a metano. Questa è stata la manutenzione straordinaria più grande in 30 anni.I miei genitori dopo 50 anni di fatica hanno comprato la casa dei loro sogni 7 anni fa, villetta del valore di 300k in collina, nuova di zecca.Quella casa è un delirio, progettata male, realizzata con una scarsissima qualità di materiali. Dopo 2 anni in marciapiede che circonda la casa è letteralmente crollato perchè la terra di riporto sotto non era stata battuta e nessuno aveva pensato di mettere ferri dentro questo marciapiede per evitare questi inconvenienti.Parto da questi due esempi perchè i modelli con i quali sono stati costruite queste due abitazioni sono secondo me significativi:1- Modello anni '70: Scopi chiari, progettazione adeguata (anche nei costi), realizzazione delegata ad una ditta grande con pochissima delega a cottimisti.Risultato: non una casa da re ma appartamenti da 80 metri realizzati a dovere con la resistenza al tempo che ci si aspetta da una casa. La cosa più interessante è la lungimiranza: tutti i condomini gemelli al mio (5 blocchi da 8 appartamenti) non hanno l'ascensore per abbattere i costi, ma hanno la predisposizione (la tromba dell'ascensore).2- Modello nuovo millennio: scopo fare profitto molto chiaro, progettazione strapagata, materiali di scarsa qualità realizzazione di una singola villetta che ha compreso almeno 10-12 ditte diverse con molta fretta di finire il proprio lavoro e scarsissima attenzione alla qualità.Risultato non pessimo ma quasi, scale strette ed esterni già da rifare. Come risultato finale non hanno nemmeno asfaltato il vialetto che porta al garage (a carico dei miei genitori come extra) come il depuratore dell'acqua.Il secondo modello è quello applicato oggi per qualsiasi cosa venga progettata e realizzata, compreso i servizi web.Progettazione strapagata, strumenti di realizzazione inadeguati e cottimisti con molta fretta di finire il lavoro senza curarsi della qualità del prodotto. Pochi mesi uomo per lavori che ne richiederebbero almeno una volta e mezzo o due per le fasi di debug e di stress del sistema che non vengono mai ultimate. Tutto questo quando non ci sono grossi problemi sulla progettazione, comunque strapagata.Parlo da progettista ex-developer.-
Re: Progettazione&Realizzazione in generale
Già, così stanno le cose.
-
-
Esempi sbagliati
I megaprogetti informatici pubblici falliscono più o meno come falliscono quelli degli ospedali ipertecnologici mai aperti le strade che non vanno da nessuna parte e tutte le altre cattedrali nel deserto. Questi progetti pensati soprattutto per far girare i soldi e falliscono solo per mancanza di interesse. Una volta incassati i soldi nessuno alza un dito per completare il lavoro.Progetti di questo tipo non si possono paragonare con gli altri fallimentari progetti portati avanti sia nel settore pubblico che quello privato.-
Re: Esempi sbagliati
- Scritto da: guast[...]
Progetti di questo tipo non si possono paragonare
con gli altri fallimentari progetti portati
avanti sia nel settore pubblico che quello
privato.tipo?-
Re: Esempi sbagliati
- Scritto da: cittadino39 487
- Scritto da: guast
[...]
Progetti di questo tipo non si possono
paragonare
con gli altri fallimentari progetti
portati
avanti sia nel settore pubblico che quello
privato.
tipo?Tipo quelli per cui la grande azienda a caso spende un sacco di soldi, ma al solito giro di ricambio dei manager un'altra fazione prende il sopravvento e decide di ammazzare il progetto.Tipo quelli progettati tanto male che sono pieni di bugs.Gli sviluppatori ci lavorano su giorno e notte, ma ogni volta che si martella da una parte si scassa dall'altra, alla fine il cliente si stufa e abbandona il progetto.Tipo quelli in cui il markettero e il cliente non si capiscono e alla fine viene fuori qualcosa che non serve a niente e nessuno usa.
-
-
-
Non dimenticare ..
Non dimenticare quel bando di gara del ministero dell'innovazione (!!!), con obbligo di presentazione tramite PEC (la famosa posta elettronica certificata tanto obbligatoria quanto utile), che finiscono in un fallimento a causa di "mailbox full", un problema che solo in Italia è impossibile da prevedere.Oppure quel magnifico progetto SISTRI (in pratica un software applicativo per la registrazione dei trasporti dei rifiuti), nato con obbiettivi condividibili, con tecnologie all'avanguardia, ma con competenze applicative nulle (come se me e te ci mettessimo a scrivere da zero un software per registrare le spedizioni spaziali) e project managemnt ridicolo. A 2 anni dall'inizio finora solo rinvii dell'entrata in funzione.-
Re: Non dimenticare ..
- Scritto da: Alessandro Landi
Non dimenticare quel bando di gara del ministero
dell'innovazione (!!!), con obbligo di
presentazione tramite PEC (la famosa posta
elettronica certificata tanto obbligatoria quanto
utile), che finiscono in un fallimento a causa di
"mailbox full", un problema che solo in Italia è
impossibile da
prevedere.
Oppure quel magnifico progetto SISTRI (in pratica
un software applicativo per la registrazione dei
trasporti dei rifiuti), nato con obbiettivi
condividibili, con tecnologie all'avanguardia, ma
con competenze applicative nulle (come se me e te
ci mettessimo a scrivere da zero un software per
registrare le spedizioni spaziali) e project
managemnt ridicolo. A 2 anni dall'inizio finora
solo rinvii dell'entrata in
funzione.ottimo ottimo!ne si parla troppo pocoPochi hanno parlato anche dell'intrastat ... e dei casi in cui la legge prevedeva una scadenza e adeguamento a determinate direttive... che coinvolgono una trasformazione del protocollo e un aggiornamento del software... e il giorno stesso della scadenza il software non era pubblicato... ne sapevano di più i vari ragionieri e contabili (che giustamente da bravi fiscali e puntigliosi tritavano i tenerini ai vari ced ... i quali si trovavano senza controparti ufficiali ...)C'è anche da dire che oggi che l'informatica viene trattata come argomento da supermercato c'è mancanza di veri tecnici anche dentro le aziende... ma questo non toglie che da parte della PA la semplificazione sia spesso tale solo di nome, lo snellimento altrettanto.A questo punto i rinvii non possono che essere benvenuti. Almeno tutte quelle cose mezze dubbie ... restano in sospeso.
-
-
informazioni di prima mano...
Caro Marco, Non ho informazioni di prima mano. io invece, ahimé, ne ho eccome... e per diretta, vasta e pluriennale esperienza dall'INTERNO della PA... Ma la sensazione netta è che come al solito in Italia i mega-progetti ricchi di finanziamenti siano anche ricchissimi di figure manageriali, politiche, amministrative, e che gli esperti informatici e di organizzazione siano relegati in fondo alla piramide decisionale e realizzativa, a spendere gli spiccioli rimasti con risorse insufficienti, carenza di informazioni ed assenza di un reale coordinamento. posso assolutamente confermarti che questa tua senzazione è perfettamente aderente alla realtà...ma è "solo" parziale... perché però, se possibile, le cose stanno pure peggio: - quasi sempre i mega-progetti (=mega-appalti) vengono praticamente e letteralmente INVENTATI per gli "scopi" che hai giustamente immaginato (e ci credo che poi si tratta di cose inutili e/o con obiettivi non chiari...)- in qualche caso si fanno i progetti SAPENDO benissimo che sono sbagliati (sì, c'è proprio una precisa volontà nel fare così): se un progetto è ben fatto e tutto va bene, allora la cosa rischia di finire lì... ma se si fa un progetto sbagliati, allora poi si deve fare subito un altro bel progetto (=un altro finanziamento) per "correggere" il primo...- e il tutto viaggia secondo le ben note modalità (previste dalle leggi... mai fatte a caso...) con cui si effettuano gare d'appalto, esecuzione, collaudi ecc. - a tutti i livelli "tecnici" e "operativi": . idee, volontà e decisioni di politici e amministratori (dai più alti fino ai più oscuri consiglieri comunali). progetti (di progettisti tanto "capaci" e "brillanti" quanto meno esperianza dimostrano in materia). qualità e capacità tecnica degli affidatari (spesso riunioni estemporanee dei soliti più o meno grandi "soggetti" noti, ne hai citati alcuni nell'articolo, affiancati da qualche società creata apposta per l'occasione, tra i cui soci si trovano facilmente parenti e amici dei soliti personaggi noti...). soggetti esecutori (subappaltatori vari ed eventuali, piccoli e grandi...). manager e professionisti vari che dirigono, coordinano e conducono i "lavori".... "esperti" . ecc. ecc.bene, a tutti questi livelli, regnano sovrani incontrastati: stupidità, pressapochismo, presunzione, ignoranza (basta vedere i progetti, le offerte, i report, i verbali...: non sembrano neanche scritti in italiano... ci sono più errori che parole), incompetenza, inesperienza e via dicendo...e non ho più voglia di continuare... già basta e avanza...un caro saluto -
in italia assumono solo in base...
Al compenso (per questo assumono giovanissimi spesso alle prime armi) o al titolo di studio (magari laureati al cepu :D) sono poche le aziende che provano sul campo la conoscenza tecnica, spesso a fare colloqui non sono nemmeno dei tecnici, in reala è pure colpa delle amministrazioni io non firmerei mai un accordo multimilionario con una società che non mi da garanzie (anche economiche) in caso di fallimento o problemi simili, e ovviamente renderei illegale il subappalto, perchè ho visto lavori subappaltati 6 volte. Praticamente la società o PA commissiona un lavoro da 100.000 euro a B (spesso B è una società fatta apposta per rubare soldi pubblici). B che essendo pensata solo per rubare soldi non ha risorse informatiche per realizzare il lavoro e cerca una società a cui dare il lavoro in cambio di 60.000 se ti dice bene quella società fa il lavoro senno si continua fino ad arrivare a una società che fa il lavoro per 5000 euro un programmatore lo paghi si e no per 2 mesi quindi quel programmatore magari deve fare un lavoro biblico in 2 mesi. Basterebbe vietare il subappalto che in informatica è inutile e genera soltanto costi e qualità scarsa.-
Re: in italia assumono solo in base...
Il subappalto adrebbe vietato in tutti i settori, per me. Piuttosto Piuttosto riducano l'ampiezza del lotto in appalot, così da permettere a più aziende di parteciparvi.-
Re: in italia assumono solo in base...
Urg, mi scuso degli errori di battitura :P
-
-
Re: in italia assumono solo in base...
No no...Non è sempre così. Mettici pure i casi del:Metto sul piatto 100000 euro per avere la superXXXXXla (ma avere la superXXXXXla dovrei sborsare 1 milione) ma non ci capisco un bel niente.Ce ne sono diversi così ;)
-
-
D'accordo!
Niente da aggiungere all'ottima analisi, se non che in questa situazione la crisi ed il taglio dei finanziamenti ai mega progetti è paradossalmente una fortuna. -
sono un testimone della questione
Concordo, le posso dare io le notizie di prima mano, anche per progetti piccoli (2/3 Mln di euro) a cui la mia azienda ha partecipato, ed è andata esattamente come raccontate: una marea di consulenze per eGov e il 15% finito in vero sistema informativo -
il vero problema
il problema sono i committenti, lo stato sfacelo che abbiamo, con ammanicati e parenti e amici dei partiti/politici di turno, che pensa che nell'emettere una norma o un regolamento o un appalto si compia tutto il suo dovere, poi automagicamente le cose si fanno da sole, tanto non deve rendere conto dei risultati ma solo della sua obbedienza a un capò. -
...e il SISTRI?
Il sistema informatico di tracciabilita di rifiuti? questo dove lo mettiamo? provate a informarvi sui costi di gestione e utilizzazione dopo 2 anni di proroghe.. italia.it vi sembrera una bazzecola!Selex-
finmeccanica .. i soliti furbetti!-
Re: ...e il SISTRI?
- Scritto da: Persona informata sui fatti
Il sistema informatico di tracciabilita di
rifiuti? questo dove lo mettiamo? Il sistri è un delirio. Sto aiutando alcune aziende private ad implementarlo e ho i conati di vomito....password che non funzionano, asisstenza meno preparata di chi telefona per una assistenza, ecc, ecc -
Re: ...e il SISTRI?
Sembra che sia esattamente così, soprattutto ingestibile nel carico e scarico merci e pieno di buchi come la groviera per il tracciamento!
-
-
c'è un altro aspetto
c'è un altro aspetto da prendere in considerazione: ma siamo sicuri che il proponente sia interessato affinchè il progetto giunga a completamento o già dall'inizio era previsto l'impantanamento del prodotto?Quando un progetto finisce tutti i nodi vengono al pettine, se non finisce invece... -
Osservatorio prezzi carburante
A parte i mille ritardi e qualche piccolo intoppo sembrerebbe che con il monitoraggio dei prezzi del carburante siano riusciti a fare qualcosa di decente:http://carburanti.osservaprezzi.it/-
Re: Osservatorio prezzi carburante
- Scritto da: Stefano
A parte i mille ritardi e qualche piccolo intoppo
sembrerebbe che con il monitoraggio dei prezzi
del carburante siano riusciti a fare qualcosa di
decente:
http://carburanti.osservaprezzi.it/ma se neanche la ricerca per campi riporta dati corretti...chi l'ha fatto topo gigio ?
-
-
alcuni motivi del disastro...
Anch'io ho una certa qual esperienza del tipo di progetti citati nell'articolo. IMHO:1. si sopravvaluta troppo la fase progettuale: sono tutti progettisti raffinati e nessuno sa scrivere codice. Si spende tempo e denaro in complicati documenti pieni di UML e compagnia bella, ma il committente non e' in grado di capirli e approva cose di cui non si rende conto appieno2. nessuno, neanche gli Einstein della progettazione, sono in grado di prevedere con precisione le funzionalita' che il sistema dovra' avere davvero. Ci si puo' avvicinare, ma solo quando il committente comincia ad usare il prodotto si rendera' conto di cosa manca e di cosa invece c'e' ma non serve a nulla. Chi crede che si possa prevedere e i bravi ci riescono e' un illuso. L'unico modo di sviluppare sistemi funzionanti e' la "beta permanente": si fa una demo funzionante delle cose fondamentali nel giro di poche settimane, si fa vedere agli utenti e via via si aggiusta aggiungendo e correggendo le funzionalita' fino ad avere tutte e solo le funzioni necessarie. Un po' alla volta si costruisce il sistema in modo incrementale.3. quando i tempi totali di sviluppo superano i sei mesi/un anno si corre il serio rischio che le necessita' nel frattempo cambino, che i responsabili cambino, ecc. ecc. per cui se si vuole evitare la catastrofe e' fondamentale che il primo collaudo avvenga entro questo arco temporale4. gli sviluppi vengono fatti fare ai soliti giovanissimi nelaureati da 800 euro/mese attraverso una catena interminabile di subappalti: la qualita' del codice e' infima, le scelte architetturali ingenue (per una form di memorizzazione sul database da erogarsi a milioni di pagine al giorno si usano piattaforme java con catene di ereditarieta' infinite, quando un aspx o un php sarebbe due ordini di grandezza piu' performante e piu' corto da scrivere; Italia.it lo scrivono con Joomla e poi si meravigliano che non regge la botta degli accessi..ecc. ecc.)5. la catena infinita che dal primo vincitore della gara porta all'ultimo livello dei peones che veramente sviluppano obbliga a costi spaventosi, tutti devono fare un bel markup e poi con i soldi che restano ci si deve accontentare del programmatorino che l'unico programma che ha scritto prima e' la rubrica telefonica personale (e che neanche funziona)Per concludere: ho avuto qualche volta la netta sensazione che qualche societa' di consulenza di quelle davvero grosse sfrutti a proprio vantaggio questa situazione appositamente progetti sistemi software enormi che non potranno andare in esercizio. A quel punto non sviluppano proprio il sistema, oppure fanno finta mettendo insieme un po' di codice non funzionante e non testato, tanto non entrera' mai in esercizio e loro risparmiano tutti i costi di sviluppo.-
Re: alcuni motivi del disastro...
- Scritto da: ciliani
Anch'io ho una certa qual esperienza del tipo di
progetti citati nell'articolo.
IMHO:
1. si sopravvaluta troppo la fase progettuale:
sono tutti progettisti raffinati e nessuno sa
scrivere codice. Scrivere codice non è progettare, così come metter mattoni non è progettare un edificio.Credo invece che la progettazione sia considerato un optional inutile, in informatica.
Si spende tempo e denaro in
complicati documenti pieni di UML e compagnia
bella, ma il committente non e' in grado di
capirli e approva cose di cui non si rende conto
appienoNon è compito suo approvarli. Per comprare casa hai per caso approvato i calcoli strutturali?
2. nessuno, neanche gli Einstein della
progettazione, sono in grado di prevedere con
precisione le funzionalita' che il sistema dovra'
avere davvero. E le specifiche funzionali a cosa servono?
Ci si puo' avvicinare, ma solo
quando il committente comincia ad usare il
prodotto si rendera' conto di cosa manca e di
cosa invece c'e' ma non serve a nulla. Significa che la progettazione è stata fatta male.
L'unico modo di sviluppare sistemi
funzionanti e' la "beta permanente": si fa una
demo funzionante delle cose fondamentali nel giro
di poche settimane, si fa vedere agli utenti eQuesto è un paradigma vagamente simile all'agile, ma all'italiana. Butto giù qualcosa e vediamo come va. E' il motivo per cui poi i costi si moltiplicano, tanto nel pubblico qualcuno pagherà.
4. gli sviluppi vengono fatti fare ai soliti
giovanissimi nelaureati da 800 euro/mese
attraverso una catena interminabile di
subappalti: la qualita' del codice e' infima, leScrivere codice non è progettare.
5. la catena infinita che dal primo vincitore
della gara porta all'ultimo livello dei peones
che veramente sviluppano obbliga a costi
spaventosi, tutti devono fare un bel markup e poi
con i soldi che restano ci si deve accontentare
del programmatorino che l'unico programma che ha
scritto prima e' la rubrica telefonica personale
(e che neanche
funziona)
Perché scrivere codice non è progettare (e tre.)
Per concludere: ho avuto qualche volta la netta
sensazione che qualche societa' di consulenza di
quelle davvero grosse sfrutti a proprio vantaggio
questa situazione appositamente progetti sistemi
software enormi che non potranno andare in
esercizio. A quel punto non sviluppano proprio il
sistema, oppure fanno finta mettendo insieme un
po' di codice non funzionante e non testato,
tanto non entrera' mai in esercizio e loro
risparmiano tutti i costi di
sviluppo.Questo è semplicemente perché non c'è responsabilità, men che meno nel pubblico. Se una cosa non funziona è perché è colpa di qualcun altro.All'estero infatti, dove chi non lavora bene ne risponde con cause milionarie, la progettazione si fa dall'inizio, e chi scrive il codice non è chi progetta.-
Re: alcuni motivi del disastro...
E le specifiche funzionali a cosa servono?Non puoi buttare giu' le specifiche di una cosa che nessuno sa con precisione cosa deve fare. Tu presumi di essere in grado di saperlo, ma e' una battaglia persa: nessuno e' in grado di saperlo.
Significa che la progettazione è stata fatta male.Leggo spesso su questo forum gli interventi dei super esperti. Beato tu che sai fare la progettazione bene. Scommetto che sono sul mercato da almeno vent'anni piu' di te ed ho diretto progetti di sviluppo molto maggiori dei tuoi, ma pazienza. Non volevo entrare nel tecnico e nel filosofico ma questi sono temi dibattuti in maniera approfondita anche all'estero, e sono temi attuali di software engineering. Dubito che basti essere "un po' piu' bravi" per assicurare che i progetti software non falliscano. Capisco che sono passati molti anni dal "mythical man month" ma le soluzioni definitive non sono ancora state trovate. Ma forse tu mi puoi correggere.-
Re: alcuni motivi del disastro...
- Scritto da: ciliani
E le specifiche funzionali a cosa servono?
Non puoi buttare giu' le specifiche di una cosa
che nessuno sa con precisione cosa deve fare. Tu
presumi di essere in grado di saperlo, ma e' una
battaglia persa: nessuno e' in grado di
saperlo.Questa è una presa di posizione errata di principio.Se non sai a cosa serve (non che cosa deve far!) è inutile farla.Se sai a cosa serve, sai cosa deve fare. E da questo puoi immaginare come deve farlo.Ovviamente non è una condizione statica - può nascere una esigenza -, tuttavia la progettazione fatta come si deve è in grado di rispondere a questa problematica.
Significa che la progettazione è stata fatta
male.
Leggo spesso su questo forum gli interventi dei
super esperti. Beato tu che sai fare la
progettazione bene. Scommetto che sono sul
mercato da almeno vent'anni piu' di te ed ho
diretto progetti di sviluppo molto maggiori dei
tuoi, ma pazienza. Potrei dire lo stesso. E quindi?
Non volevo entrare nel tecnico
e nel filosofico ma questi sono temi dibattuti in
maniera approfondita anche all'estero, e sono
temi attuali di software engineering. Infatti, anni di teoria e studio sull'ingegneria, e sull'ingegneria del software nello specifico buttati nel XXXXX perché "non si può sapere a priori cosa deve fare un sistema". Balle. Il problema non è che non si sa cosa dovrà fare un sistema, ma come fare, date le specifiche di oggi, a progettare (di nuovo questa parola!) il sistema in modo da renderlo flessibile a successive evoluzioni.Questa necessità porta, a seconda di quanto oggi sono noti i requisiti, ad approcci "agili" (che non sono la filosofia del faccio qualcosa a caso da te proposta) oppure ad altri più rigidi.Ma di base c'è sempre progettazione.
Dubito che
basti essere "un po' piu' bravi" per assicurare
che i progetti software non falliscano. Mai pensato questo, non so da dove tu l'abbia tirato fuori.
Capisco
che sono passati molti anni dal "mythical man
month" ma le soluzioni definitive non sono ancora
state trovate. Ma forse tu mi puoi
correggere.E chi ha parlato di soluzioni definitive? Dico solo che liquidare tutto con "la progettazione è impossibile" è una fesseria. E' un modo per giustificare l'approccio "a XXXXX" tipico dei progetti IT citati dall'articolo.-
Re: alcuni motivi del disastro...
Giusto per dirti che la progettazione io la faccio e la superivisiono nei progetti piu' grossi; e l'universita' l'ho fatta molti anni prima di te. Ma poi ho anche lavorato sul mercato ed ho accumulato esperienza. La progettazione va fatta, ovviamente, ma credi a me e' impossibile prevedere all'atto della progettazione tutto quanto sarebbe necessario. Questo lo dice la mia esperienza ventennale e lo dicono anche i professori universitari seri. Sono sicuro che quando anche tu avrai sviluppato un certo numero di sistemi informativi complessi capirai quello che stavo dicendo. E' ovvio che una buona progettazione la devi fare prima, ma e' necessario che la progettazione sia poi modificata ed aggiustata in corso d'opera via via che si collaudano le funzionalita'.Inoltre ti potrei enumerare le mode informatiche che c'erano quando ho fatto l'universita' io (la programmazione strutturata, la structured systems analysis di Tom DeMarco, ecc.). Sono scomparse sostituite da altre mode, adesso c'e' UML, Agile Development, ecc.... fra dieci anni ce ne saranno altre. Il fatto e' che l'ingegneria software non ha ancora raggiunto la maturita' di altre ingegnerie (come ad esempio quella meccanica, puoi progettare un sottomarino prevedendo l'esatto numero di vitarelle necessarie, come sappiamo tutti noi "che abbiamo studiato").Comunque mi piacerebbe sapere quali grandi sistemi informatici hanno realizzato i professori universitari che ti hanno inculcato tutta questa sicurezza. -
Re: alcuni motivi del disastro...
- Scritto da: ciliani
Giusto per dirti che la progettazione io la
faccio e la superivisiono nei progetti piu'
grossi; e l'universita' l'ho fatta molti anni
prima di te. Ma poi ho anche lavorato sul mercato
ed ho accumulato esperienza. La progettazione va
fatta, ovviamente, ma credi a me e' impossibile
prevedere all'atto della progettazione tutto
quanto sarebbe necessario. ovviamente no, ma sarebbe gradito avere idee almeno a grandi linee di cosa dovrebbe fare il software, poi ovviamente il macro obiettivo lo esplodi in una serie di sotto obiettivi. Ma se non si hanno le idee chiare almeno sul macro obiettivo sicuramente ci si sta fiondando verso un fiasco colossale.
Questo lo dice la mia
esperienza ventennale e lo dicono anche i
professori universitari seri. Sono sicuro che
quando anche tu avrai sviluppato un certo numero
di sistemi informativi complessi capirai quello
che stavo dicendo. E' ovvio che una buona
progettazione la devi fare prima, ma e'
necessario che la progettazione sia poi
modificata ed aggiustata in corso d'opera via via
che si collaudano le
funzionalita'.
è stupido credere che fatta la progettazione questa possa essere incisa in lastre di granito e lasciata fissa per l'eternità ma parimenti è XXXXXXXXX andare avanti per tentativi stravolgendo tutto ad ogni piè sospinto. Il problema è che se il committente non capisce neppure lui cosa vuole e cosa deve farci è praticamente impossibile accontentarlo.
Comunque mi piacerebbe sapere quali grandi
sistemi informatici hanno realizzato i professori
universitari che ti hanno inculcato tutta questa
sicurezza. -
Re: alcuni motivi del disastro...
è stupido credere che fatta la progettazione
questa possa essere incisa in lastre di granito e
lasciata fissa per l'eternità ma parimenti è
XXXXXXXXX andare avanti per tentativi
stravolgendo tutto ad ogni piè sospinto. Il
problema è che se il committente non capisce
neppure lui cosa vuole e cosa deve farci è
praticamente impossibile
accontentarlo.In pratica siamo del tutto d'accordo, io esagero un po' per evidenziare il punto. Non dico di andare per tentativi, ma dico di far vedere da subito al committente quello che ha richiesto, in modo di poter chiarire da subito cosa vuole davvero. Se invece di fargli vedere un software funzionante (ovviamente un prototipo, ma che renda l'idea) gli fai vedere un documento cartaceo condito da una bella spiegazione con termini tecnici, la tranvata la prendi il giorno del collaudo.Poi con una bella progettazione il giorno del collaudo avrai ottime ragioni a dire che il software fa esattamente quello che era stato pattuito. Non c'e' dubbio... ma nel frattempo il collaudatore non e' piu' il committente originario (e' passato troppo tempo) e avra' buon gioco ad affermare che tu come progettista non avevi capito nulla e comunque le carte le ha firmate uno che magari non e' neanche piu' in azienda. Magari puoi intentare una bella causa ma con quel cliente hai chiuso. -
Re: alcuni motivi del disastro...
Poi con una bella progettazione il giorno del
collaudo avrai ottime ragioni a dire che il
software fa esattamente quello che era stato
pattuito. Non c'e' dubbio... ma nel frattempo il
collaudatore non e' piu' il committente
originario (e' passato troppo tempo) e avra' buon
gioco ad affermare che tu come progettista non
avevi capito nulla e comunque le carte le ha
firmate uno che magari non e' neanche piu' in
azienda. Magari puoi intentare una bella causa ma
con quel cliente hai
chiuso.è un doppio caso di malafede. Da parte della SH che cerca di ricorrere a cortine fumogene per mascherare il proprio deficit di analisi e da parte del committente per rimangiarsi quanto a suo tempo firmato. -
Re: alcuni motivi del disastro...
è un doppio caso di malafede. Da parte della SH
che cerca di ricorrere a cortine fumogene per
mascherare il proprio deficit di analisi e da
parte del committente per rimangiarsi quanto a
suo tempo
firmato.Tu cosi' parti dal presupposto che sono tutti dei cialtroni. In realta' purtroppo queste cose succedono in perfetta buona fede da una parte e dall'altra. Non puoi addebitare un deficit di analisi ad una SH che ha fatto approfonditi documenti progettuali dove magari ci sono anche i disegni delle schermate dei prodotti finiti; analisi che e' stata approvata e controfirmata con il sangue dal committente. Poi ricordati che il committente che collauda non e' in genere quello che ha firmato.Anche rischiare di inserire funzioni che il progettista sa perfettamente che ci vogliono ma che il committente non vuole e' in genere perdente. Se il progettista ci ha indovinato, buon per lui; se non ci ha indovinato verra' percosso duramente dal committente (e bisogna proprio essere tanto tanto presuntuosi per credere di sapere meglio del committente cosa voglia il committente "davvero")Ripeto, secondo me continuare a credere che sia possibile in assoluto e sempre fare analisi esaustive, e che se cio' non succede e' solo colpa dell'analista, e' un approccio ingenuo e giovanilistico. E che la storia ha dimostrato ampiamente come sbagliato. Bisogna escogitare altri metodi per ovviare a questo, altrimenti i sistemi informativi complessi continueranno ad essere sviluppati sforando i budget e i tempi e deludendo i committenti.Poi che ci siano tanti analisti incapaci e' vero: i progetti sbagliati ci sono e la colpa in quel caso e' dei progettisti. -
Re: alcuni motivi del disastro...
- Scritto da: shevathas
è un doppio caso di malafede. Da parte della SH
che cerca di ricorrere a cortine fumogene per
mascherare il proprio deficit di analisi e da
parte del committente per rimangiarsi quanto a
suo tempo
firmato.Tu e HappyCactus state ragionando da ingeneri, siete convinti che l'utente finale sappia cosa vuole e sappia esprimere i suoi desideri in maniera corretta.Questo in realtà è quasi sempre impossibile e persino io che ho sempre e solo progettato e programmicchiato per hobby sono arrivato a capirlo.In generale comunque adesso in università ti spiegano che progettare un sistema partendo dalle specifiche, progettando e realizzando tutto con un solo passaggio è abbastanza utopico. E io da parte mia sono abbastanza d'accordo. -
Re: alcuni motivi del disastro...
Tu e HappyCactus state ragionando da ingeneri,
siete convinti che l'utente finale sappia cosa
vuole e sappia esprimere i suoi desideri in
maniera
corretta.
Non è detto: il lavoro di un buon analista è anche il tirar fuori dal cliente quello che vorrebbe realmente. Ovviamente per fare ciò il cliente deve essere partecipativo e collaborare con il gruppo di sviluppo. Se il cliente non collabora allora è impossibile accontentarlo.Ci può essere malafede da parte della SH quando fa firmare cartaccia che convince il cliente che le sue esigenze sono soddisfatte da quello che la SH ha in pentola.Ci può essere malafede da parte del cliente quando dopo aver firmato a pera cerca di rimangiarsi tutto e scaricare su altri la responsabilità.Ho visto entrambi i casi, e spesso. -
Re: alcuni motivi del disastro...
Vorrei aggiungere una cosa.Va bene che in grandi progetti non si possono conoscere tutte le esigenze dall'inizio.Va bene che le esigenze (o altri fattori determinanti) nel tempo possono cambiare.Ma mi volete spiegare che cosa c'entra questo con il portale italia o quello dei certificati medici?In uno mancavano i contenuti, nel senso che il committente non sapeva cosa voleva metterci in termini di informazioni e funzionalita' (e' come se io andassi da un architetto per farmi progettare una casa e, alla sua domanda di come io la voglia, gli dicessi "ma, dentro ci vorrei vivere", poi quello la progetta, la fa costruire e io non ci metto i mobili e ci passo di tanto in tanto per leggere il giornale dal balcone perche' continuo a vivere nella mia baracca abusiva).Nell'altro mi volete dire quali esigenze imprevedibili c'erano? A oggi esiste una procedura di gestione dei certificati medici per malattia, andava informatizzata quella (lo so, sto ipersemplificando), non bisognava inventarsi un mondo nuovo o scoprire nuove esigenze, perche' le esigenze c'erano gia' ed erano gia' coperte (in parte almeno) dalla procedura attuale. -
Re: alcuni motivi del disastro...
Ma mi volete spiegare che cosa c'entra questo con
il portale italia o quello dei certificati
medici?sono d'accordo, questi sono due casi di nessunissima complicazione progettuale -
Re: alcuni motivi del disastro...
- Scritto da: ciliani
l'universita' l'ho fatta molti anni
prima di te. Questo non puoi saperlo.
La progettazione va
fatta, ovviamente, ma credi a me e' impossibile
prevedere all'atto della progettazione tutto
quanto sarebbe necessario. Ho scritto forse qualcosa di diverso?Ti invito a rileggere, con calma e meno supponenza, quello che ho scritto fino ad ora.Forse alla tua pluriennale e indimostrata esperienza sul campo non si accompagna una dovuta attenzione nel leggere quel che l'interlocutore scrive, e quindi, esprime soltanto quella prosopopea che tu gratuitamente affibbi agli altri.cheers ;-)
-
-
-
Re: alcuni motivi del disastro...
Mi spiace contraddirti, ma una progettazione accurata in campo informatico non da nessuna certezza sul sucXXXXX o sul fallimento di un progetto. Tanto tanto più si progetta a lungo termine, tanto più le previsioni si possono rivelare errate.La progettazione deve essere essenziale e comprensibile e se chi programma sa fare il suo mestiere non è necessario specificare ogni minimo particolare.E come sempre: "no silver bullet!"-
Re: alcuni motivi del disastro...
- Scritto da: Ichigo
Mi spiace contraddirti, ma una progettazione
accurata in campo informatico non da nessuna
certezza sul sucXXXXX o sul fallimento di un
progetto.Non mi stai affatto contraddicendo, leggi quanto detto. Un buon prodotto (informatico, elettronico o gastronomico) non è un prodotto bellissimo, è un prodotto che si vende, che è redditizio. Questo determina il sucXXXXX o fallimento di un progetto. Intendendo, per estensione, con "redditizio" nel senso del valore anche funzionale - come nel caso di Italia.it.Ma questo è vero non solo per il settore informatico, come detto!
Tanto tanto più si progetta a lungo termine,
tanto più le previsioni si possono rivelare
errate.
La progettazione deve essere essenziale e
comprensibile e se chi programma sa fare il suo
mestiere non è necessario specificare ogni minimo
particolare.
E come sempre: "no silver bullet!"Programmare non è progettare (e quattro!)Scrivere codice non è progettare! Scrivere codice è manovalanza, che deve rispettare certi criteri - leggibilità, riusabilità, aderenza alle specifiche, eccetera - ma pur sempre manovalanza! Certo se il codice è scritto con i piedi gli effetti si vedono - come un muratore che tira su il muro storto - ed infatti nello sviluppo di un progetto complesso come un progetto software non c'è solo la progettazione, c'è anche la direzione lavori, l'esecuzione, il collaudo, la QA e via discorrendo. Tutte cose che ahimè anche in questa discussione vedo snobbata parlando di "interminabile catena burocratica"...E più il progetto è a lungo termine (relativamente parlando, dipende dal settore di applicazione), più questi passaggi devono essere curati.-
Re: alcuni motivi del disastro...
PS: mi scuso per la pessima grammatica e gli errori... purtroppo avevo fretta ed ho scritto "a braccio" senza rileggere. Brrrrr.... che orrore. :-) scusate scusate -
Re: alcuni motivi del disastro...
- Scritto da: 1Informatic oComeAltri
PS: mi scuso per la pessima grammatica e gli
errori... purtroppo avevo fretta ed ho scritto "a
braccio" senza rileggere.
Brrrrr.... che orrore. :-) scusate scusatequoto "abbastanza" quello che hai scritto....(orrori grammaticali a parte eheh)Tieni conto pero' dell' effetto "storie da sala macchine"(*), presente ovunque. E TANTO anche in italia (nei succitati accenture, engineering) ma anche in bestie piu piccole... A me personalmente, d'istinto, mi vengono i brividi quando sento piu di 2 o 3 buzzwords... poi ,si, capisco, talvolta, tolto il terrore iniziale, effettivamente alcune di queste figure intermedie (tra il committente e il programmatore/sysadmin) servono...(*)http://www.soft-land.org/storie/index -
Re: alcuni motivi del disastro...
Scrivere codice
è manovalanzaSbagliatissimo. Vedi:http://punto-informatico.it/b.aspx?i=3082733&m=3083827#p3083827 -
Re: alcuni motivi del disastro...
- Scritto da: Enterprise Profession al
Scrivere codice
è manovalanza
Sbagliatissimo. Vedi:
http://punto-informatico.it/b.aspx?i=3082733&m=308Ti ho risposto là, spiegandoti il perché. Niente di più corretto, invece ;-)
-
-
-
Re: alcuni motivi del disastro...
Scrivere codice non è progettare, così come
metter mattoni non è progettare un
edificio.
Credo invece che la progettazione sia considerato
un optional inutile, in
informatica.Ecco il più grande errore della storia dell'informatica. Essendo una disciplina relativamente giovane si è cercato di adattare il paradigma delle altre ingegnerie tradizionali e si è detto:Progettista = ArchitettoProgrammatore = MuratoreChe è una cosa che non ha funzionato e che non sta ne in cielo ne in terra. L'analisi e la progettazione sicuramente ci vogliono, ma sono soggette a continui cambiamenti in corso d'opera e non devono essere delle fasi a "tenuta stagna" rispetto allo sviluppo, come invece si vuole far credere e come spesso insegnano i professori universitari, che magari non sono mai usciti dall'università.Il progettista e lo sviluppatore devono lavorare sempre a fianco e, spesso, alcuni di loro sono entrambe le cose.-
Re: alcuni motivi del disastro...
- Scritto da: Enterprise Profession al
Il progettista e lo sviluppatore devono lavorare
sempre a fianco e, spesso, alcuni di loro sono
entrambe le
cose.Ho detto qualcosa di diverso?E' una questione di ambiti. Si è abituati a pensare, e molte risposte qui lo confermano, che deve essere chi scrive codice a progettare, ma non è così. Sono ambiti diversi.Può anche essere che chi progetta scriva anche codice, e magari, sia anche il committente e/o il responsabile del progetto, perché no? ma, permettimi, sono ambiti diversi, in cui ciascuno deve "svestirsi" di un ruolo (per esempio del programmatore) quando serve un ruolo diverso (per esempio, dell'analista o del domain expert, o del project manager). -
Re: alcuni motivi del disastro...
Ecco il più grande errore della storia
dell'informatica. Essendo una disciplina
relativamente giovane si è cercato di adattare il
paradigma delle altre ingegnerie tradizionali e
si è
detto:
Progettista = Architetto
Programmatore = Muratore
Che è una cosa che non ha funzionato e che non
sta ne in cielo ne in terra. dissento.
L'analisi e la
progettazione sicuramente ci vogliono, ma sono
soggette a continui cambiamenti in corso d'opera
e non devono essere delle fasi a "tenuta stagna"
rispetto allo sviluppo, come invece si vuole far
credere e come spesso insegnano i professori
universitari, che magari non sono mai usciti
dall'università.allora il waterfall come tecnica di progettazione è stata mollata, come paradigma unico di progettazione, alla fine degli anni '80 almeno. Al giorno d'oggi ci sono diverse tecniche per l'ingegnerizzazione del software e sta all'architetto del sistema scegliere le più appropriate sulla base delle esigenze del committente. Spesso chi polemizza contro la progettazione e l'ingegnerizzazione del progetto pensa spesso ad applicazioni semplici che possono essere seguite facilmente da una sola persona, ovvero una sola persona si occupa sia dell'analisi che della realizzazione.
Il progettista e lo sviluppatore devono lavorare
sempre a fianco e, spesso, alcuni di loro sono
entrambe le
cose.nei progetti piccoli. In quelli medi e grossi è il progettista che da le specifiche agli sviluppatori. Ovviamente anche il progettista deve avere competenze sullo sviluppo, così da sapere cosa sta chiedendo.
-
-
-
Re: alcuni motivi del disastro...
- Scritto da: ciliani
Anch'io ho una certa qual esperienza del tipo di
progetti citati nell'articolo.
IMHO:
1. si sopravvaluta troppo la fase progettuale:
sono tutti progettisti raffinati e nessuno sa
scrivere codice. Si spende tempo e denaro in
complicati documenti pieni di UML e compagnia
bella, ma il committente non e' in grado di
capirli e approva cose di cui non si rende conto
appieno
2. nessuno, neanche gli Einstein della
progettazione, sono in grado di prevedere con
precisione le funzionalita' che il sistema dovra'
avere davvero. Ci si puo' avvicinare, ma solo
quando il committente comincia ad usare il
prodotto si rendera' conto di cosa manca e di
cosa invece c'e' ma non serve a nulla. Chi crede
che si possa prevedere e i bravi ci riescono e'
un illuso. L'unico modo di sviluppare sistemi
funzionanti e' la "beta permanente": si fa una
demo funzionante delle cose fondamentali nel giro
di poche settimane, si fa vedere agli utenti e
via via si aggiusta aggiungendo e correggendo le
funzionalita' fino ad avere tutte e solo le
funzioni necessarie. Un po' alla volta si
costruisce il sistema in modo
incrementale.
3. quando i tempi totali di sviluppo superano i
sei mesi/un anno si corre il serio rischio che le
necessita' nel frattempo cambino, che i
responsabili cambino, ecc. ecc. per cui se si
vuole evitare la catastrofe e' fondamentale che
il primo collaudo avvenga entro questo arco
temporale
4. gli sviluppi vengono fatti fare ai soliti
giovanissimi nelaureati da 800 euro/mese
attraverso una catena interminabile di
subappalti: la qualita' del codice e' infima, le
scelte architetturali ingenue (per una form di
memorizzazione sul database da erogarsi a milioni
di pagine al giorno si usano piattaforme java con
catene di ereditarieta' infinite, quando un aspx
o un php sarebbe due ordini di grandezza piu'
performante e piu' corto da scrivere; Italia.it
lo scrivono con Joomla e poi si meravigliano che
non regge la botta degli accessi..ecc.
ecc.)
5. la catena infinita che dal primo vincitore
della gara porta all'ultimo livello dei peones
che veramente sviluppano obbliga a costi
spaventosi, tutti devono fare un bel markup e poi
con i soldi che restano ci si deve accontentare
del programmatorino che l'unico programma che ha
scritto prima e' la rubrica telefonica personale
(e che neanche
funziona)
Per concludere: ho avuto qualche volta la netta
sensazione che qualche societa' di consulenza di
quelle davvero grosse sfrutti a proprio vantaggio
questa situazione appositamente progetti sistemi
software enormi che non potranno andare in
esercizio. A quel punto non sviluppano proprio il
sistema, oppure fanno finta mettendo insieme un
po' di codice non funzionante e non testato,
tanto non entrera' mai in esercizio e loro
risparmiano tutti i costi di
sviluppo.Giacchè ci sei metti pure i nomi... qualcuno ha detto Accenture? Qualcun altro ha detto Engineering?e qualcun altro il "sommo appaltatore" e principale responsabile del "carrozzonismo ipertrofico" ovvero SOGEI?E si... manca ancora qualcuno... ma il metodo è chiaro!Sarebbe chiara anche la soluzione se l'obiettivo non è raggiunto si va a casa!Ma è una soluzione molto difficile perchè presuppone che venga meno la "pappatoria" per la zia il cognato il fratello e tutta la corte dei miracoli che poi alle elezioni da il voto "a chi di dovere".È un ottimo sistema si chiama MAFIA! -
Re: alcuni motivi del disastro...
Sono d'accordo su tutto tranne che su questo.Fissati gli scopi di un progetto informatico un buon ingegnere deve riuscire a prevedere almeno l'80% di funzionalità e carichi applicativi e deve prevenire quelle che saranno le esigenze del committente.Altrimenti, davvero, è meglio affidare il tutto a neolaureati.La beta permanente è una follia.Un sito come Italia.it dovrebbe essere solido ed affidabile alla prima visita altrimenti non ce ne sarà una seconda ;)
2. nessuno, neanche gli Einstein della
progettazione, sono in grado di prevedere con
precisione le funzionalita' che il sistema dovra'
avere davvero. Ci si puo' avvicinare, ma solo
quando il committente comincia ad usare il
prodotto si rendera' conto di cosa manca e di
cosa invece c'e' ma non serve a nulla. Chi crede
che si possa prevedere e i bravi ci riescono e'
un illuso. L'unico modo di sviluppare sistemi
funzionanti e' la "beta permanente": si fa una
demo funzionante delle cose fondamentali nel giro
di poche settimane, si fa vedere agli utenti e
via via si aggiusta aggiungendo e correggendo le
funzionalita' fino ad avere tutte e solo le
funzioni necessarie. Un po' alla volta si
costruisce il sistema in modo
incrementale.-
Re: alcuni motivi del disastro...
- Scritto da: lui
Sono d'accordo su tutto tranne che su questo.
Fissati gli scopi di un progetto informatico un
buon ingegnere deve riuscire a prevedere almeno
l'80% di funzionalità e carichi applicativi e
deve prevenire quelle che saranno le esigenze del
committente.
Altrimenti, davvero, è meglio affidare il tutto a
neolaureati.
La beta permanente è una follia.
Un sito come Italia.it dovrebbe essere solido ed
affidabile alla prima visita altrimenti non ce ne
sarà una secondaHai ragione perfettamente. La beta permanente la dicevo per le cose complesse, e poi "permanente" fino ad un certo punto, diciamo per il primo anno di esercizio. L'80% sarebbe un bel traguardo, ma di certo hai ragione anche su questo, penso che una buona parte si possa capire fin dall'inizio. Molto dipende dagli interlocutori, capita anche sovente che un dirigente chieda un sistema che dovra' essere usato dai propri dipendenti senza aver chiaro cosa facciano i propri dipendenti. Quando poi capita che gli utilizzatori finali (opps) del sistema lo vedono per la prima volta al collaudo succede che si scopra che il sistema non fa quello che dovrebbe fare. Un dirigente in gamba ti permettera' di prevedere anche il 95% della applicazione, uno scarso invece... quando capisci di avere a che fare con un idiota e' meglio cominciare da subito a far vedere cose sul computer.Per un sito come Italia.it sono d'accordo con te, li' una analisi esaustiva si poteva fare molto semplicemente prima, e non c'era alcun problema serio di ingegneria software. Tra l'altro bastava dire "guarda france.fr o simili ed imitalo di sana pianta"-
Re: alcuni motivi del disastro...
- Scritto da: ciliani
- Scritto da: lui
Molto dipende dagli interlocutori, capita anche
sovente che un dirigente chieda un sistema che
dovra' essere usato dai propri dipendenti senza
aver chiaro cosa facciano i propri dipendenti.
Quando poi capita che gli utilizzatori finali
(opps) del sistema lo vedono per la prima volta
al collaudo succede che si scopra che il sistema
non fa quello che dovrebbe fare. Un dirigente in
gamba ti permettera' di prevedere anche il 95%
della applicazione, uno scarso invece...Ma sei TU l'analista, e capire cosa vuole DAVVERO il cliente e non quello che pensa gli possa servire, fa parte del TUO lavoro, non del suo.
Per un sito come Italia.it sono d'accordo con te,
li' una analisi esaustiva si poteva fare molto
semplicemente prima, e non c'era alcun problema
serio di ingegneria software. Tra l'altro bastava
dire "guarda france.fr o simili ed imitalo di
sana
pianta"Naaaa te lo avrebbero fatto in francese ;)-
Re: alcuni motivi del disastro...
Ma sei TU l'analista, e capire cosa vuole DAVVERO
il cliente e non quello che pensa gli possa
servire, fa parte del TUO lavoro, non del
suo.Guarda che non ci riescono neanche gli psicanalisti con trent'anni di esperienza a capire cosa voglia davvero un essere umano.Poi fammi un fischio quando il committente ti vidima il progetto che lui non ha chiesto, ma che tu DAVVERO sapevi che DAVVERO volesse nel segreto del suo cuore.;-) scherzo un po', mi raccomando non prendete subito tutti d'aceto, che diamine! -
Re: alcuni motivi del disastro...
- Scritto da: ciliani
Ma sei TU l'analista, e capire cosa vuole
DAVVERO
il cliente e non quello che pensa gli possa
servire, fa parte del TUO lavoro, non del
suo.
Guarda che non ci riescono neanche gli
psicanalisti con trent'anni di esperienza a
capire cosa voglia davvero un essere
umano.Vero, ma qui si (s)parlava di procedure ;) -
Re: alcuni motivi del disastro...
- Scritto da: ciliani
Poi fammi un fischio quando il committente ti
vidima il progetto che lui non ha chiesto, ma che
tu DAVVERO sapevi che DAVVERO volesse nel segreto
del suo
cuore.Ma guarda che il committente ti vidima sempre quello che vuole. E' solo che di solito quello che vuole non è quello che gli serve.comunque questa ci stà tutta: http://godaddy.infinitylimited.net/misc_media/Software_Treeswing.jpg
-
-
-
-
Re: alcuni motivi del disastro...
Mi sono reso conto che forse ho dato l'impressione di affermare che la progettazione non serva. Quello che intendevo dire:1. la progettazione va fatta, sulla base di quello che chiede il committente. Il committente pero' si sbaglia (come dice House che i pazienti mentono..."i committenti si sbagliano. I committenti non sanno quello che vogliono")2. il committente deve validare la proposta. Ma non e' in grado di capire dai documenti che riceve se la proposta e' valida oppure no. Pensa di vedere nell'analisi cartacea funzioni che non ci sono, ecc. Eventuali diagrammi confondono piu' che chiarire.3. l'unico modo affinche' il committente abbia chiaro in che consiste la proposta e' vedere il prodotto finito in funzione. Solo allora si rende conto che ha chiesto cose errate.4. per questo e' bene presentare un prototipo quanto prima possibile. Vedendo il prototipo il committente capira' se ha chiesto le cose giuste e se non si e' dimenticato nulla. Inoltre forse fara' vedere il prototipo a qualcuno degli utenti finali veri, cosa che non succede in genere mai per il cartaceo della progettazione formale5. ovviamente non si puo' prototipare tutto un sistema complesso: si comincera' con le cose piu' importanti o le prime in ordine di proXXXXX.6. in genere al secondo, massimo al terzo prototipo le idee sono veramente chiare per poter stilare la progettazione definitiva7. da qui in poi tutto va come nel modo tradizionale. Bisogna pero' essere dotati di tool di sviluppo, team in gamba e correttamente dimensionato, ecc. perche' il collaudo non deve tardare piu' di sei mesi/un anno.Ogni passo dovrebbe essere vidimato dai responsabili... cosa che spesso e' impossibile, nel pubblico ci sono settori in cui chiunque si rifiuta di mettere anche una minima firmetta (siamo in Italia). Per questo e' buona cosa uno scambio di email, in cui ci si finge anche un po' cretini per reiterare per iscritto le cose che sono uscite negli incontri relativi ai prototipi-
Re: alcuni motivi del disastro...
- Scritto da: ciliani
Ogni passo dovrebbe essere vidimato dai
responsabili... cosa che spesso e' impossibile,
nel pubblico ci sono settori in cui chiunque si
rifiuta di mettere anche una minima firmetta
(siamo in Italia). Per questo e' buona cosa uno
scambio di email, in cui ci si finge anche un po'
cretini per reiterare per iscritto le cose che
sono uscite negli incontri relativi ai
prototipiQuanta saggezza! ;) -
Re: alcuni motivi del disastro...
QUOTONE -
Re: alcuni motivi del disastro...
la progettazione va fatta, sulla base di
quello che chiede il committente. Il committente
pero' si sbaglia (come dice House che i pazienti
mentono..."i committenti si sbagliano. I
committenti non sanno quello che
vogliono")Purtroppo i committenti chiedono una cosa, ne vogliono un'altra (problema di sintassi)ed in realtà gliene serve un'altra ancora -che neanche immaginano- e che in futuro si lamenteranno di non avere.Su sistemi non troppo grandi io cerco di realizzare ciò che credo che gli servirà in futuro e lo nascondo.In tanti casi si è rivelata una strategia vincente anche da un punto di vista economico.Certo, ci si spreca un po di tempo in più, ma alla lunga paga.
-
-
Re: alcuni motivi del disastro...
- Scritto da: ciliani
Anch'io ho una certa qual esperienza del tipo di
progetti citati nell'articolo.
IMHO:
[...]
3. quando i tempi totali di sviluppo superano i
sei mesi/un anno si corre il serio rischio che le
necessita' nel frattempo cambino, che i
responsabili cambino, ecc. ecc. per cui se si
vuole evitare la catastrofe e' fondamentale che
il primo collaudo avvenga entro questo arco
temporale
4. gli sviluppi vengono fatti fare ai soliti
giovanissimi nelaureati da 800 euro/mese
attraverso una catena interminabile di
subappalti: la qualita' del codice e' infima, le
scelte architetturali ingenue (per una form di
memorizzazione sul database da erogarsi a milioni
di pagine al giorno si usano piattaforme java con
catene di ereditarieta' infinite, quando un aspx
o un php sarebbe due ordini di grandezza piu'
performante e piu' corto da scrivere; Italia.it
lo scrivono con Joomla e poi si meravigliano che
non regge la botta degli accessi..ecc.
ecc.)Mi ricorda tanto questo diagramma:http://xkcd.com/844/ -
Re: alcuni motivi del disastro...
Intervengo solo per darti ragione. Sei uno dei pochi che ha capito perfettamente come si lavora(in ambito IT) in Italia e quali sono le reali problematiche di grossi progetti. Insomma, intuisco che hai esperienza.Io credo che la vera ragione del perchè i progetti IT falliscono è che chi te lo commissiona non ha le idee chiare. -
Re: alcuni motivi del disastro...
- Scritto da: ciliani
Anch'io ho una certa qual esperienza del tipo di
progetti citati nell'articolo.
IMHO:
1. si sopravvaluta troppo la fase progettuale:
sono tutti progettisti raffinati e nessuno sa
scrivere codice. Si spende tempo e denaro in
complicati documenti pieni di UML e compagnia
bella, ma il committente non e' in grado di
capirli e approva cose di cui non si rende conto
appienoSemplicemente (e anch'io ho una certa esperienza in merito con enti centrali) il 99% della gente che lavora in tali enti centrali non capisce un bel niente di progettazione informatica. Aggiungici il fatto che vogliono il progetto completato in tempi minimi (perche i quadri e dirigenti ci prendono il premio - ebbene si! In alcune relatà della PA vengono valutati non per aver portato il progetto a compimento in modo corretto ma l'averlo portato nei tempi dovuti che sono sempre estremamente ristretti. Aggiungici il fatto che lo stato vuol pagare una figura di esperto (qualsiasi sia) 300 euro al giorno quando va bene, cosa si pretende allora?
2. nessuno, neanche gli Einstein della
progettazione, sono in grado di prevedere con
precisione le funzionalita' che il sistema dovra'
avere davvero. Ci si puo' avvicinare, ma solo
quando il committente comincia ad usare il
prodotto si rendera' conto di cosa manca e di
cosa invece c'e' ma non serve a nulla. Chi crede
che si possa prevedere e i bravi ci riescono e'
un illuso. L'unico modo di sviluppare sistemi
funzionanti e' la "beta permanente": si fa una
demo funzionante delle cose fondamentali nel giro
di poche settimane, si fa vedere agli utenti e
via via si aggiusta aggiungendo e correggendo le
funzionalita' fino ad avere tutte e solo le
funzioni necessarie. Un po' alla volta si
costruisce il sistema in modo
incrementale.
D'accordo con te ma come descritto sopra sono "i tempi di rilascio" quelli che non vanno. Soprattuto nel campo in cui lavoro io (DataWarehouse)
3. quando i tempi totali di sviluppo superano i
sei mesi/un anno si corre il serio rischio che le
necessita' nel frattempo cambino, che i
responsabili cambino, ecc. ecc. per cui se si
vuole evitare la catastrofe e' fondamentale che
il primo collaudo avvenga entro questo arco
temporale
Benissimo...sulla carta...
4. gli sviluppi vengono fatti fare ai soliti
giovanissimi nelaureati da 800 euro/mese
attraverso una catena interminabile di
subappalti: la qualita' del codice e' infima, le
scelte architetturali ingenue (per una form di
memorizzazione sul database da erogarsi a milioni
di pagine al giorno si usano piattaforme java con
catene di ereditarieta' infinite, quando un aspx
o un php sarebbe due ordini di grandezza piu'
performante e piu' corto da scrivere; Italia.it
lo scrivono con Joomla e poi si meravigliano che
non regge la botta degli accessi..ecc.
ecc.)
Con le tariffe che applicano ti meraviglieresti del contrario?
5. la catena infinita che dal primo vincitore
della gara porta all'ultimo livello dei peones
che veramente sviluppano obbliga a costi
spaventosi, tutti devono fare un bel markup e poi
con i soldi che restano ci si deve accontentare
del programmatorino che l'unico programma che ha
scritto prima e' la rubrica telefonica personale
(e che neanche
funziona)
Leggi alla voce: Tariffe
Per concludere: ho avuto qualche volta la netta
sensazione che qualche societa' di consulenza di
quelle davvero grosse sfrutti a proprio vantaggio
questa situazione appositamente progetti sistemi
software enormi che non potranno andare in
esercizio. A quel punto non sviluppano proprio il
sistema, oppure fanno finta mettendo insieme un
po' di codice non funzionante e non testato,
tanto non entrera' mai in esercizio e loro
risparmiano tutti i costi di
sviluppo.Può anche essere (qualche volta mi è capitato di vedere situazioni del genere) ma ricordiamo i due fattori che purtroppo i cari enti pubblici impongono a chi vince una gara (che ricordiamo sono al ribasso):1. Tempi al di fuori del ragionevole 2. Prezzi applicati alle figure previste in contratto. -
Re: alcuni motivi del disastro...
In 2 parole:http://dilbert.com/strips/comic/2011-02-03/
-
-
my 2 cents
Ho notato, anche nel privato, che spesso ci si focalizza solamente sull'obiettivo considerando secondario il mezzo attraverso il quale conseguire l'obiettivo. E questo porta alle solenni cantonate che abbiamo visto. Ricordo, circa 10 anni fa, che molti volevano lanciarsi nell'ecommerce ma tanti fra questi pensavano solo ad avere un sito luccicante con flash ed effetti stroboscopici ma non si fermavano un attimo a riflettere su cosa vendere, a chi e come gestire la logistica degli approvvigionamenti e della consegna della merce. Cercando soluzioni tanto immediate quanto campate per aria quando arrivavano le rogne, ovviamente molti dei progetti si risolvevano in paurosi buchi nell'acqua e buchi nel portafoglio dell'avventato di turno. Per i progetti italiani credo sia capitata la stessa cosa, si è pensato solamente agli obiettivi da raggiungere senza pensare al modo di perseguirli, e questo ha causato, eufemisticamente parlando, qualche piccolo problemuccio...-
Re: my 2 cents
- Scritto da: shevathas
[...]
Per i progetti italiani credo sia capitata la
stessa cosa, si è pensato solamente agli
obiettivi da raggiungere senza pensare al modo di
perseguirli, e questo ha causato,
eufemisticamente parlando, qualche piccolo
problemuccio...uhm... no...il punto centrale è che:- gli obiettivi da raggiungere per chi ha in mano le carte vincenti del gioco sono in realtà solo uno, facilissimo da definire e chiarissimo: il saccheggio dei finanziamenti - e questi "soggetti" hanno dimostrato, e dimostrano, di conoscere benissimo il modo di raggiungere l'obiettivo e di reiterarlo nei decenni...il tutto, ovviamente, alla faccia tua e mia
-
-
Contro domanda (maieutica)
Come mai per costruire un grattacielo occorre assegnare il progetto ad un professionista, mentre per progettare una struttura informatica no?-
Re: Contro domanda (maieutica)
Perché tanto è una XXXXXXXta, lo fai col computer due click e sei pronto, cosa ci sarà mai di difficile?Se lo sapevo Italia.it glielo facevo io in 15 minuti con iWeb-
Re: Contro domanda (maieutica)
- Scritto da: Andrea S
Perché tanto è una XXXXXXXta, lo fai col computer
due click e sei pronto, cosa ci sarà mai di
difficile?
Se lo sapevo Italia.it glielo facevo io in 15
minuti con
iWebMio cuggino lo faceva per 30 euro...-
Re: Contro domanda (maieutica)
Ero ironico...-
Re: Contro domanda (maieutica)
pure lui...
-
-
-
-
Re: Contro domanda (maieutica)
- Scritto da: HappyCactus
Come mai per costruire un grattacielo occorre
assegnare il progetto ad un professionista,
mentre per progettare una struttura informatica
no?da professionista del settore, ti dico che stai sbagliando bersaglio...il punto non è se a progettare sono dei professionisti... e peraltro le più grandi e peggiori porcherie sono progettate proprio da professionisti...-
Re: Contro domanda (maieutica)
- Scritto da: che pena
da professionista del settore, ti dico che staiQuale settore, per specificare. ICT oppure di progettazione (cioè sei un ingegnere edile/civile, architetto, ecc...?)
sbagliando
bersaglio...
il punto non è se a progettare sono dei
professionisti... Per "professionista" intendo una persona o società di persone che a) si occupano esclusivamente di progettazione (e non di realizzazione!) di sistemi informatici, b) applicano rigorosi criteri di ideazione, gestione e supervisione del progetto, c) concorrono a rispondere della mancata rispondenza del progetto ai requisiti rigorosamente stabiliti in partenza, d) rispondono al criterio di TERZIETA' rispetto il committente e chi realizza il progetto.
e peraltro le più grandi e
peggiori porcherie sono progettate proprio da
professionisti...Questa è una presa di posizione aprioristica, forte purtroppo del fatto che in Italia spesso non vi sono i criteri sopra proposti, tuttavia poco rispondente alla realtà dei fatti.-
Re: Contro domanda (maieutica)
Il problem è proprio questo. Il fatto che si pensi che la progettazione di un software sia paragonabile alla costruzione di una casa. Il fallimento di tantissimi progetti dimostra che non è affatto così. Anzi prendere tuttle le decisioni a priori è la ricetta per il sicuro fallimento. Ci sono fior di libri di ingengeria del software che ripetono questo concetto.Il fatto che poi a prendere le decisioni siano manager che hanno poca o nulla esperienza nella gestione un progetto sw sicuramnte non migliora la situazione.Se ci aggiungi il regolare magna-magna hai fatto tombola.
-
-
-
Re: Contro domanda (maieutica)
Perchè tutti hanno un computer, una macchina fotografica, una videocamera.Con cui sono in grado di sfornare prodotti "bassamente professionali".Invece pochi hanno un'impresa edile.
-
-
Obiettivi nulli?
Il fatto che i soldi siano stati spesi e fossero pubblici (cioè di nessuno) dovrebbe suggerire che gli obiettivi ci fossero e siano stati tutti perfettamente centrati.-
Re: Obiettivi nulli?
Purtroppo
-
-
Colpiti ed affondati...
Dove comandano gli incapaci i risultati sono pessimi... in Italia i governanti degli ultimi 20 anni hanno affondato la meritocrazia sostituendola con mignottocrazia e (quando va bene) calcinculandia ! Vedere che posti occupano ( e con quali stipendi) gente come la Minetti e la Carfagna fa passare qualsiasi voglia di impegno anche al più volenteroso degli onesti !-
Re: Colpiti ed affondati...
perche secondo te 30 o 40 anni fa c'era meritocrazia? l'italia è la patria della raccomandazione, find dai tempi dell'impero romano
-
-
gli obiettivi dichiarati non son quelli
Caro Calamari, lo vedo tutti i giorni: gli obiettivi dichiarati non corrispondo agli obiettivi reali. Non solo nel pubblico, anche nel privato.I veri obiettivi nel mondo del lavoro sono tre:1) coltivare il proprio orto di potere2) fare più soldi possibile nel minor tempo possibile3) salvarsi le chiappe facendo 1 e 2.Quando un progetto fallisce questi tre punti sono sempre nella parte alta delle priorità di qualcuno. E quel qualcuno, di solito, non è l'addetto alle pulizie.-
Re: gli obiettivi dichiarati non son quelli
parole sante!
-
-
centro
Cassandra, anche stavolta hai centrato il problema. La burocrazia ci soffoca, e chi ha idee (aka progetti) ma nessun santo in paradiso si deve arrendere. Ancora per poco?-
Re: centro
- Scritto da: gioca90
Cassandra, anche stavolta hai centrato il
problema. La burocrazia ci soffoca, e chi ha idee
(aka progetti) ma nessun santo in paradiso si
deve arrendere. Ancora per
poco?Perché poi cosa succede? Vai all'estero? ;)Perché se pensi che via il nano le cose possano volgere al meglio si vede che non hai ben chiara la storia di questa repubblica...Purtroppo lo stato italiano è totalmente in cancrena e l'unica soluzione è l'amputazione di tutti i suoi organi!-
Re: centro
no, non vado all'estero e non credo che "via il nano via i problemi". Anzi, quando andra' via forse ci accorgeremo che per anni non abbiamo fatto altro che accendere i riflettori sempre nello stesso posto, perdendo di vista gli altri problemi, altrettanto seri.Se avessi 20 anni di meno, comunque, emigrerei :)-
Re: centro
parole sante.se pensate che i veri problemi id cui dovrebbe occuparsi la gente siano quelle razzate di ruby & c. vedrete quando i riflettori si sposteranno dal nano e illumineranno tutte le altre cose ignorate per una caccia alle streghe...-
Re: centro
il punto è qui.non solo i riflettori ma anche l'attenzione della politica gira intorno a quest'uomo.quindi prima se ne va lui meglio è che i riflettori illuminano altra XXXXX e ce ne è tanta.poi arrivano gli altri.gli altri che sono al pari probabilmente, o meglio, statisticamente faranno lo stesso e via di riflettori anche su di loro.se invece fossimo in uno stato serie la gente si vergognerebbe in particolar modo i berlusconiani (chi lo ha votato) e senza accendere nemmeno una candela (altro che riflettori) tutti compatti li manderemmo a casa.i successivi poi starebbero molto più attenti, altrimenti tutti compatti li prenderemmo a calci in cu|o anche a loro....ma sai siamo in italia e la politica e tipo le guerre che si sviluppano qui su PI tra apple e Ms e linux.questo è il vero problema dell'italia... il senso dei cittadini verso lo stato.è l'unico _VERO_ problemagli altri sono solo questioni tecnicamente risolvibili in tempi più o meno lunghi... ma a noi piace pensare che i problemi dell'italia sono i politici... in modo che non è colpa nostra oppure al limite è colpo di chi vota il politico sotto i riflettori in quel momentoe ce ne vantiamo pure"figurati se gli altri sono meglio ... hihihi"tipico di"windows ha un bug""ma anche linux""ma anche mac"peccato che la politica è la vita reale un sistema operatico è uno strumento che alla fine più di tanto non ci condiziona -
Re: centro
perdonate gli errori... la foga fa brutti scherzi in oltre non vorrei si fraintendesse questa frasegli altri che sono al pari probabilmente, o meglio, statisticamente faranno lo stesso e via di riflettori anche su di loro.la riscrivogli altri che sono al pari probabilmente, o meglio, gli altri che statisticamente sono al pari faranno lo stesso e via di riflettori anche su di loro. -
Re: centro
- Scritto da: si fa per parlare
il punto è qui.
ma a noi piace pensare che i problemi dell'italia
sono i politici... in modo che non è colpa nostra
oppure al limite è colpo di chi vota il politico
sotto i riflettori in quel
momento
e ce ne vantiamo pure
"figurati se gli altri sono meglio ... hihihi"
tipico di
"windows ha un bug"
"ma anche linux"
"ma anche mac"
Quoto questa parte che condivido appieno.il problema NON sono i politici siamo noi e la nostra mentalità, pure la mia.Una mentalità volta a ritenere i problemi FUORI da noi :"è colpa dei politici", esattamente come hai detto "è colpa di microsoft" (o dei cantinari), come se non fossimo noi a votarli o non fossimo noi come utenti e clienti a non pretendere di + dai nostri fornitori da consumatori consapevoli.Ci piace dividerci e litigare tra di noi, quanndo l'unica vera contrapposizione dovrebbe essere tra noi e i nostri problemi.Ieri sentivo in radio uno "scherzo" in cui qualcuno diceva "ma se fanno la riforma della giustizia, io guadagno 1200 euro al mese invece che 900?". Analogamente se invece che Berlusconi, o Bersani o chi per loro, vanno a casa o al governo,per noi, che cambia?Non sono loro, d'altronde, che fanno il Paese, quello lo facciamo noi.Se qualcosa non va, e di cose che non vanno che ne sono un bel po', forse dovremmo guardarci allo specchio e chiederci dove stiamo sbagliando.
-
-
Re: centro
da quotare integralmente.
-
-
-
