Perché molti progetti software falliscono oggi?

Question

Finché ci sono progetti software, il mondo si chiede perché falliscono così spesso.

Vorrei sapere se c'è una lista o qualcosa di equivalente che mostra quanti progetti software falliscono oggi. Sarebbe bello se ci fosse un confronto negli ultimi 20 - 30 anni.

È inoltre possibile aggiungere il motivo principale per cui un progetto software non riesce. Il mio è "I requisiti sono poveri o addirittura inesistenti". che include anche "Nessun (reale) cliente/utente coinvolto".

MODIFICA: È quasi impossibile definire chiaramente il termine "errore". Diciamo che fail significa: il progetto era superiore al 10% rispetto al budget e al tempo. A mio parere il 10% +/- è un buon intervallo per un'offerta/gara.

MODIFICA: Fino ad ora (11 febbraio) sembra che la maggior parte dei manifesti concorda sul fatto che un fallimento del progetto è fondamentalmente un fallimento della gestione del progetto (qualunque sia il fallimento). Ma IMHO viene fuori, che molti sviluppatori non sono contenti di questa situazione. Forse perché il manager non viene penalizzato quando un progetto non ha avuto successo, ma i team di sviluppatori pigri e incompetenti?

Quando ho letto i messaggi, posso anche sentire che c'è un grande "spazio" tra il lato sviluppatore e il lato gestione. Le aspettative (forse anche i requisiti) sembrano essere così diverse, che un progetto non può avere successo alla fine (nel tempo/budget, gli utenti non sono contenti, non tutte le caratteristiche del primo prio implementate, troppi bug perché gli sviluppatori sono stati costretti a implementare in tempi troppo brevi ...)

Mi chiedo: come possiamo migliorarlo? O abbiamo la possibilità di migliorarlo? Sembra che tutti siano insoddisfatti di come vanno ora. Possiamo colmare il divario tra questi due mondi? Dovremmo (gli sviluppatori) scioperare e lottare per "richieste di alta qualità" e "shedules temporali basati su realismo/iterazione"?

EDIT: Ralph Westphal e Stefan Lieser hanno fondato una nuova "comunità" chiamato: Clean-Codice-Developer. Lo scopo del gruppo è portare più professionalità nell'ingegneria del software. Indipendentemente se uno sviluppatore ha una laurea o un sacco di anni di esperienza puoi far parte di questo movimento.

Clean Code Gli sviluppatori sviluppano i principi come SOLID ogni giorno. Uno sviluppatore professionista è il più grande recensore di il proprio lavoro. E ha un sistema di valori interno che lo aiuta a migliorare e migliorare.

Check it out on: Clean Code Developer

EDIT: La nostra società sta facendo in questo momento una cosa chiamata "Application Development e manutenzione Benchmarking". Questo è un servizio offerto da IBM per ottenere un feedback da qualcuno esterno sulla qualità del processo di ingegneria del software ecc. Quando otterremo i risultati, vi dirò di più a riguardo.

Answer 1

L'ultima statistica che ho sentito è che il 90% dei progetti è nel tempo o oltre il budget. Quindi se consideri che fallendo, lascia un po '.

Il motivo per cui non riesce si basa principalmente sul processo.Noi come ingegneri del software non facciamo un buon lavoro nel raccogliere i requisiti e nel controllare il cliente. Poiché il software di costruzione è un lavoro "misterioso" per le persone esterne all'IT, è difficile per loro capire perché i cambiamenti dell'ultimo minuto sono difficili. Non è come costruire una casa e mostrare chiaramente perché non è possibile aggiungere rapidamente un'altra porta sul retro della casa fatta di mattoni.

Answer 2

Non è una risposta diretta, ma ho trovato lo Virtual Case File un caso di studio affascinante su come un grande progetto finanziato da un governo ben finanziato possa ancora accumulare.

È inoltre possibile aggiungere il motivo principale per cui un progetto software non riesce.

Un altro IEEE Spectrum Online articolo "Why Software Fails" esamina proprio questa domanda. Essa riassume i punti principali come segue:

• Obiettivi irrealistici o progetto inarticolato
• stime imprecise di risorse necessarie
• requisiti di sistema Badly definiti
• Poor segnalazione dello stato del progetto
• gestito Rischi
• Scarsa comunicazione tra clienti, sviluppatori e utenti
• Utilizzo di tecnologia immatura
• incapacità di gestire la complessità del progetto
• Sporchi pratiche di sviluppo
• cattiva gestione del progetto
• politica delle parti interessate
• pressioni commerciali

Answer 3

Onestamente, penso che sia perché la maggior parte dei programmatori non sono molto bravo a cosa fanno (e non intendo solo il codice di avviamento). Le persone sullo stackoverflow sono probabilmente l'eccezione. Non so voi, ma come consulente/programmatore di contratti ho lavorato in o intorno a molti luoghi, e il rapporto tra programmatori mediocri o poveri è buono da 10 a 1.

Uno dei miei i punti di forza sono sempre stati stimati in modo accurato e quindi sono stati consegnati in tempo e con o senza budget: ho sempre l'obiettivo di arrivare al 10% sotto costo e in tempo. Poi mi piace dire al mio cliente che, dato che ho fatto le cose per meno $$ del previsto, quale degli "extra" ti piacerebbe aggiungere?

Anche un prodotto perfettamente funzionante che è in ritardo e/o oltre il budget sarà considerato un fallimento da molti dirigenti aziendali. I programmatori spesso si concentrano solo sugli aspetti tecnici di ciò che fanno, con scarso rispetto per il costo o la scadenza. Hai davvero bisogno di fare tutti e tre bene per essere considerato un progetto di successo. Ci sono molti altri programmatori che potrebbero codificare circoli attorno a me senza dubbio, ma per la persona che paga per il progetto, questo è abbastanza raro.

Answer 4

Le persone/aziende non gridano con orgoglio per i loro fallimenti, così tanti casi non saranno mai ascoltati.

Answer 5

Non solo i progetti software superano il budget o richiedono più del previsto per il completamento. Basta aprire il giornale e guardare progetti pubblici come ponti.

Ma per un progetto software è molto più facile annullare tutto. Se un ponte o un edificio sono finiti a metà, non c'è modo di tornare indietro. Metà delle infrastrutture è a posto. È molto visibile e richiede denaro per rimuoverlo.

Per un progetto software, è possibile premere Maiusc-Canc e nessun avviso.

È solo un lavoro molto difficile eseguire un'analisi accurata dei costi.

Answer 6

Scarsa pianificazione.

Answer 7

Hofstadter's Law

Ci vuole sempre più tempo del previsto, anche quando si prende la legge di Hofstadter in considerazione.

Answer 8

Un errore comune è che gli addetti alle vendite e il personale tecnico non comunicano sufficientemente. Quindi i venditori vendono cose che non sono tecnicamente fattibili nel budget. (E poi corrono con il loro bonus :))

Answer 9

L'utilizzo del sistema di file di casi virtuali dell'FBI si riduce a una cattiva gestione del programma. Il programma aveva requisiti pre-9/11 e aspettative post-9/11. Se la gestione del governo avesse fatto il loro lavoro, ci sarebbero state mod di contratto.

http://government.zdnet.com/?p=2518

"A causa di un contratto a tempo indeterminato con poche garanzie, SAIC raccolto più di $ 100 milioni come il progetto è diventato più grande e più complicata, anche se il suo software non ha mai funzionato correttamente. La società ha continuato a incontrare il le richieste dell'ufficio di presidenza, accettando pagamenti nonostante i chiari segni che l'approccio dell'FBI al progetto fosse gravemente errato, secondo le persone che erano coinvolte nel progetto o in seguito lo avevano rivisto per il governo ".

Sebbene $ 105.000.000 per 700.000 righe di codice arrivino a $ 150 per riga di codice. Non male.

Answer 10

(Dal punto di vista dei programmatori - Non sono un gestore di progetti, ma sono stato spesso coinvolto nel processo).

Un numero di persone ha menzionato che i cattivi programmatori sono endemici. Ma penso che questo sia vero anche in un altro senso - siamo tutti cattivi programmatori in quanto troviamo difficile anticipare la complessità, un problema inevitabile che 50 anni di stime e schemi di pianificazione dei proiettili magici non sono riusciti a risolvere.

Anticipare gli effetti collaterali di grandi progetti diventa esponenzialmente più difficile con la crescita dei progetti. Questo è certamente un truismo noioso, ma per me significa che in ogni progetto a cui ho lavorato in cui sono stato coinvolto nel processo di stima, mi sono imbattuto in qualche caso in cui c'è una conseguenza imprevista di una decisione di progettazione che fa sì che tutto si fermi o almeno qualche giorno di correzione del bug - solo qualcosa che nessuno ha previsto, nessuna sorta di malasanità o stupidità. È solo la natura di un sistema abbastanza complesso.

A parte l'incertezza intrinseca, c'è anche la tendenza a sottovalutare le cose il cui profilo è noto, perché il fatto che abbiano meno incertezza le rende più semplici da implementare.

Quindi le cose incerte vengono ingrandite, le cose chiare vengono ridotte al minimo e ciò che realmente ti uccide è la cosa che non pensavi sarebbe stata incerta.

Answer 11

Cattiva gestione.

Il progetto SW viene avviato lanciando sviluppatori contro un problema percepito. I requisiti aziendali si cristallizzano mentre il progetto progredisce. Nuove funzionalità vengono aggiunte mentre le scadenze rimangono. Vengono lanciati altri sviluppatori. I membri del progetto originale si sono licenziati o licenziati. A questo punto, troppo tempo, denaro e risorse vengono investiti nel progetto, quindi non possono essere cancellati. Alla scadenza del termine, il progetto viene dichiarato terminato e superato nonostante l'evidente mancanza di prodotto finito.

Vieni a pensarci bene - ho jet di vedere un progetto SW fallire ...

Answer 12

cattiva gestione.

I progetti non sono successi o guasti basati su alcune funzioni di base del progetto, ma sul fatto che soddisfino le esigenze degli utenti. (Possono fallire del tutto, nel qual caso c'era un grossissimo errore di ciò che era possibile). È soprattutto nel processo di valutazione della fattibilità e del rapporto costi-benefici del progetto, e nella definizione degli obiettivi, che i progetti software tendono a fallire o avere successo.

C'è una disconnessione tra le persone che si occupano di fatti e cose (come i programmatori) e le persone che si occupano di altre persone (come tipi di vendita e gestori). Per un programmatore, i fatti sono fatti e devono essere affrontati. Per un venditore, i fatti sono ciò che pensano gli altri e sono mutevoli.

Ci sono anche differenze tra fatti tangibili e intangibili. Nessuno pensa che i lavoratori possano costruire un grande ponte in un mese se fossero davvero motivati; possono vedere tutto l'acciaio, il cemento e altri oggetti che devono essere spostati e fissati in posizione. Il software è molto meno tangibile e non ha le restrizioni fisiche: mentre non è nemmeno teoricamente possibile costruire il bridge entro un mese, è concepibile che un team possa creare un grande progetto entro un mese, come "tutti" che devono fare è tutto perfetto la prima volta È fisicamente possibile digitare migliaia di righe di codice al giorno; è solo che la possibilità che siano utilizzabili così com'è è così vicino allo zero non importa. La produttività effettiva di uno sviluppatore principale è in realtà piuttosto insignificante nel conteggio delle parole, rispetto a (diciamo) la produttività di un giornalista.

Pertanto, coloro che sono abituati a fatti flessibili non hanno gli imponenti limiti fisici per ricordare loro che le cose possono essere spinte solo fino a quel momento, nessun apprezzamento per ciò che la programmazione effettivamente richiede e nessuna sensazione positiva per quanto la produttività è realisticamente possibile. Inoltre, sanno come farsi strada nelle negoziazioni, molto più dello sviluppatore medio, quindi nelle negoziazioni su ciò che è possibile tendono ad assumere più di quello che possono, nel mondo reale, ottenere.

Nel frattempo, lo sviluppo del software è intrinsecamente sfocato, perché la produzione del prodotto fisico è banale. Posso produrre una copia del software in modo rapido ed economico, una volta che è stato sviluppato. Lo sviluppo del software è un lavoro di progettazione, puro e semplice. Qualsiasi cosa corrisponda alla produzione viene eliminata senza pietà con cose come compilatori e procedure guidate e generazione di codice. Lo sviluppatore, di fronte al manager che vuole l'impossibile, trova difficile dire che l'impossibile è in realtà impossibile, perché non c'è modo di dire che è effettivamente impossibile. Dati i fatti che sono abbastanza sconosciuti per sentirsi flessibili, la persona con forti capacità e determinazione negoziale otterrà in genere la risposta che desidera.

Data questa disconnessione, ci si potrebbe chiedere di chi è la responsabilità di collegarlo. La risposta è, a mio parere, chiara. La responsabilità di comprendere come le diverse persone pensano appartenga alle persone che si specializzano nel trattare con altre persone. La responsabilità di coordinare diversi tipi di persone appartiene alle persone il cui compito è coordinare queste cose. Pertanto, i gestori.

I manager che capiscono lo sviluppo e gli sviluppatori di software e che riescono a gestire bene altri manager, faranno bene, ei loro progetti avranno generalmente successo. Ce ne sono ancora troppi dell'altro tipo al mondo.

Answer 13

Scarso utilizzo di pratiche e metodi di sviluppo software. Nella mia esperienza, uno dei motivi principali per cui un progetto ha fallito è che il team di sviluppo utilizza un metodo sbagliato per affrontare il processo di sviluppo del software. La scelta di una metodologia senza una buona comprensione di come funziona e di ciò che serve può portare a problemi di un progetto che richiedono molto tempo, come una pianificazione scadente.

Anche un problema comune è anche l'uso di tecnologie senza una precedente valutazione di esso per capire come può essere applicato e se porta qualsiasi valore al progetto.

Answer 14

Il motivo numero uno: un errore di gestione del progetto.

La ragion d'essere di un PM è di far sì che un progetto abbia successo, ergo un fallimento del progetto è il loro fallimento. Certamente ci sono fattori al di fuori del loro controllo, ma è ancora nella descrizione del lavoro del PM di gestire quel rischio, e le uniche clausole di uscita dovrebbero essere qualcuno più in alto nella catena alimentare che prende il controllo delle decisioni (che è una cosa terribile da fare a un PM) o atti di dio.

Nella mia esperienza, i guasti si verificano soprattutto quando il lavoro di PM è stato veloce, lento o inesistente, anche quando le decisioni iniziano a fluire da personale di vendita e quando il cliente inizia a decretare il controllo delle modifiche. Un buon PM è impagabile.

Answer 15

È perché nessuno sembra più leggere. Ogni singolo motivo per cui i progetti falliscono è stato analizzato più e più volte. Basta leggere tre libri di sapere il motivo per cui l'80% dei progetti falliscono:

La scadenza: un romanzo su Project Management (Tom Demarco, pubblicato 1997) E 'una grande introduzione ed è abbastanza divertente. Peopleware: progetti produttivi e Squadre (Tom Demarco, pubblicato 1987) The Mythical Man-Month: Essays on Software Engineering (Fred Brooks, pubblicato 1975)

Noi come professione sembrano semplicemente di dimenticare tutto ogni 3-5 anni (vedi "l'elaborazione centralizzata è inefficiente, lascia che siano i client a gestirla" vs cloud computing).

Answer 16

Il fallimento è un giudizio - più di un'accusa, davvero.

"Il progetto superava del 10% il budget e il tempo."

Quale budget? Quale programma?

6 mesi fa, ho scritto un piano dicendo che ci sarebbero voluti 6 mesi.

3 mesi fa, gli utenti hanno richiesto più materiale. Ho dato loro un piano che diceva che ci sarebbero voluti altri 9 mesi.

Il mese scorso mi è stato detto che il progetto era di 6 mesi sul budget e quindi un "fallimento".

Ma aspetta. Ha consegnato ciò che gli utenti volevano. Era oltre la stima "originale". Era sotto la stima rivista. Gli utenti vogliono di più. Vuole di meno.

Answer 17

Per valutare veramente se un progetto ha davvero successo, la stima/il budget originale è probabilmente un parametro errato. La maggior parte degli ingegneri tende a sottovalutare quanto tempo ci vorrà a causa della pressione politica, e non sanno come stimare comunque. Molti manager sono dei pessimi pianificatori perché vogliono scadenze irrealistiche per compiacere il loro capo, spesso non capiscono cosa è implicato, e in più è qualcosa che possono guardare, capire e usare come bastone nelle riunioni, piuttosto che aiutare a risolvere i problemi. Praticamente, aiuta le aziende a fare previsioni approssimative di spesa per scopi di budget, almeno dà loro qualcosa da fare.

Una misurazione migliore del successo del progetto sarebbe: gli utenti sono felici? Aiuta l'azienda a fare soldi? Quanto velocemente i soldi guadagnati aiuteranno a recuperare il costo del sistema? Questi sono più difficili da valutare rispetto a un semplice piano, però.

Alla fine, ho trovato che è meglio consegnare alla scadenza, anche se ciò significa lavorare un po 'di straordinario. Fa schifo, ma questa è la realtà.

Answer 18

Come affermato in precedenza la stragrande maggioranza delle persone coinvolte nello sviluppo di software di realtà non capire come

• porre le domande giuste per conoscere il problema
• apprezzare gli utenti della porta e giudicare le aspettative
• capire la tecnologia disponibile e la relativa struttura Eco
• la maggior parte dei team direttamente/indirettamente coinvolti sono scarsamente qualificati.
• non apprezzare o sapere quando hanno torto possono agire.

Anche con requisiti perfetti e definizioni correlate, molti sviluppatori non sanno cosa stanno facendo.

Basta dare un'occhiata ai tipi di domande poste qui. Andresti da un dottore che ha fatto la stessa domanda equivalente. La cosa spaventosa è che chiedono e non sanno come imparare o ragionare.

Answer 19

Mi avvicinerò da un aspetto diverso rispetto al resto del resto.

Ho notato che un progetto si guasta lentamente per un periodo di tempo. Certo, è migliorato anche in quel momento - ma non è ancora redditizio. In questo mercato la redditività e l'essere nel nero significano successo.

Perché non funziona? Penso che sia semplice: ottieni quello per cui paghi.

Il software è come un conto bancario, non una melma primordiale. Se non ci metti delle risorse (tempo, denaro, concentrazione, sforzo), allora non otterrai niente da fuori, tranne il fallimento e il costo. Quindi devi investire le cose nel tuo progetto, ea volte il primo lavoro prepara il terreno per gli anni a venire. Non puoi buttare del fango sul tuo computer e aspettarti un nuovo topo in due anni e $ 10 milioni di dollari dopo, quindi anche lo sforzo deve essere speso.

Uno dei maggiori problemi oggi sono gli "sviluppatori di budget" in un paese del terzo mondo. Non li rimprovero alla loro parte del mercato, ma per una startup della Silicon Valley, ben finanziata, cercarli e ottenere una base di budget (framework o persino prototipo) significa fare uno scarso investimento in futuro. Questa stessa struttura di bilancio è ciò che sta causando problemi ai miei amici oggi. Ora funziona; ha funzionato quando è stato scritto, ma non è stato scritto bene e pochi hanno anche il tempo di mantenerlo.Se la compagnia dovesse fermarsi e riscrivere il software nel modo in cui avrebbe dovuto essere scritto in primo luogo, non avrebbero avuto tutti questi problemi. Possono permettersi il tempo? No. Devono renderlo redditizio prima che possano persino farlo.

Come dice il proverbio, "Posso farlo: economico, veloce o buono. Ora, sceglierne due." Tutti vogliono tutti e tre, me compreso. Ma se non investi tempo, pianificazione e lavoro necessario per rendere il tuo progetto un successo fin dall'inizio ... quindi non aspettarti nulla di cui andare fiero in seguito. Si sentirà come una Mona Lisa falsa, in cui tu e tutti gli altri ingegneri come te, potete vedere un difetto qua e là che non avrebbe dovuto esserci fin dall'inizio.

Quindi:

• Non si impegnano ciò che non si può permettere in: tempo, denaro, fatica, messa a fuoco, ecc
• non saltare la pianificazione!
• Non abbiate paura di riscrivere all'inizio del quando conta di più. (Più tardi sarà peggio di un viaggio dal dentista, credimi.)
• Non sottovalutare il potere della burocrazia per impedirti di farlo nel modo giusto.
• E non essere economico dove dovresti passare la maggior parte del tuo tempo. Ti costerà dopo, garantito. E se non tu, allora qualcun altro ti prenderà il proiettile.

Answer 20

Ci sono stati buoni studi su questo. Raccomando this link dal sito Web di Construx (società Steve McConnells).

Answer 21

Il collegamento di Construx sopra è veramente buono!

Molti progetti sono gestiti su un quadro roseo della realtà. I manager tendono a dare potere agli sviluppatori di parlare in stime ottimistiche. Ma diciamo che un progetto di 20 settimane viene "discusso" a 10 settimane. La fase dei requisiti sarà ora di 1 settimana anziché di 2. Dopo 1 settimana, i requisiti non sono terminati, ma il progetto prosegue. Ora stai lavorando su un terreno tremolante ... e su un programma allungato!

Questo può essere divertente. Una volta c'era questo vecchio ragazzo in una stanza di fronte alla mia. Il suo titolo di lavoro era amministratore di sistema. Ma il sistema che avrebbe dovuto ammettere non era lì. Non era mai stato finito, anche se la direzione pensava che fosse stato. Il ragazzo ha giocato a giochi per circa un anno prima di annoiarsi e andare avanti.

La parte più divertente? La direzione ha aperto un nuovo posto di lavoro dopo che se n'è andato!

Answer 22

diversi ordini del giorno

gestione non capisco quello che uno sviluppatore fa, come si producono codice e le difficoltà incontrate. Tutto ciò a cui tengono è il prodotto finale consegnato in tempo. Ma per uno sviluppatore si preoccupano degli aspetti tecnici, del codice ben prodotto in una soluzione di cui siamo orgogliosi.

Scadenze

Ho sentito spesso gli sviluppatori dicono che vorrebbero poter produrre codice migliore, e che le scadenze spesso li spingono a produrre qualcosa che funziona, invece di buon codice. Quando queste scadenze non sono ottimistiche, i problemi sono esacerbati.

Answer 23

IT Project Failures è un blog sui fallimenti del progetto che potrebbe avere alcune risposte qui se si vuole leggerlo.

Io stesso, penso che una buona parte di questo argomento si ponga sulla questione di poter indicare esattamente cosa ci si aspetta in x mesi a $ y quando la risposta è davvero molto più aperta. Ad esempio, se un'azienda sostituisce un sistema ERP o CRM, ci sono buone possibilità che uno non soddisfi esattamente tutti i requisiti e quindi ci saranno alcune modifiche, correzioni di bug ed extra che derivano dall'assunzione di tali un grande progetto. Per un'analogia, considera quanti studenti che frequentano la scuola superiore o l'università potrebbero dichiarare il loro programma preciso per tutti i 4 anni senza prendere lezioni e in realtà si attengono a ciò alla fine. La mia ipotesi sarebbe pochissima, dato che alcune persone cambiano le major oi corsi che volevano prendere non vengono offerti o succedono altre cose che cambiano il risultato previsto, ma come viene catturato in un piano di progetto che abbiamo iniziato qui e mentre noi pensato che stessimo andando lì, siamo finiti al punto 3.

Answer 24

Essere oltre budget e tempo non è una buona definizione di insuccesso (e in realtà essere nel budget e tempo non significa sempre successo). Prendere i seguenti esempi forniti da Hugh Woodward, PMP, in Expert Project Management - Project Success: Looking Beyond Traditional Project Metrics:

• Sydney Opera House: Con le sue vele aggraziati che dominano Sydney Harbour, la Sydney Opera House è senza dubbio uno degli edifici più conosciuti nel il mondo. Eppure, dal punto di vista del project management, è stato un fallimento spettacolare. Quando la costruzione iniziò nel 1959, si stima che costasse $ 7 milioni e ci volessero quattro anni per costruire. È stato finalmente completato nel 1973 per oltre $ 100 milioni.

  [...]

• Progetto Orion: Questo massiccio sforzo per sviluppare nuovi sistema fotografico Advantix di Kodak è stato reputato molto ben gestito dal punto di vista di gestione del progetto. La PMI lo ha riconosciuto come Progetto Internazionale dell'anno 1997 e Business Week ha scelto il sistema come uno dei migliori nuovi prodotti del 1996 (Adams, 1998). Ma il prezzo delle azioni di Kodak è sceso del 67% dall'introduzione del sistema Advantix, in parte perché non è riuscito ad anticipare l'accelerazione del passaggio alla fotografia digitale.

• Intranet aziendale: Finch descrive un progetto che ha coinvolto l'implementazione di una intranet aziendale per globalizzare e migliorare le comunicazioni. Da una prospettiva di progetto tradizionale, non è riuscito a soddisfare i suoi criteri di successo, ma non in modo significativo. Era in ritardo di un mese e si credeva che fosse stato realizzato con un budget limitato. Ma sia il project manager che i dirigenti hanno considerato il progetto un successo. L'hardware e il software sono stati installati con successo con un minimo di interruzione, fornendo così a tutti i membri del personale l'accesso alla intranet aziendale. Dopo l'implementazione, tuttavia, i dipendenti hanno fatto solo un uso limitato delle strutture della intranet. Pertanto, l'obiettivo principale del progetto non è stato raggiunto. In questo caso, sia il project manager che il senior management si sono concentrati su un obiettivo troppo ristretto.

  [...]

• Manufacturing Plant Optimization: Una società di produzione di carta con cinque stabilimenti in Nord America ha deciso di aumentare la sua capacità produttiva per intraprendere un programma di de-strozzature. È stato formato un team di progetto per installare l'attrezzatura necessaria e incaricato di completare il lavoro in 18 mesi al costo di $ 26 milioni.Ma quasi immediatamente, al team del progetto è stato chiesto di rinviare maggiori spese fino a quando non è stato risolto un problema di flusso di cassa non correlato. Invece di interrompere completamente il lavoro, il team ha adottato una strategia di prototipazione delle tecnologie su cui si basava il programma di riduzione della quantità di colli, e in realtà ha sviluppato alcune soluzioni più economiche e più efficaci. Anche quando il progetto è stato autorizzato a procedere, il team ha continuato lo stesso approccio. Il progetto ha avuto una durata di cinque anni, ma il conseguente aumento della capacità è stato tre volte l'impegno iniziale. Non sorprende che la società abbia immediatamente stanziato altri $ 40 milioni per continuare il programma.

  [...]

Quindi, in questi esempi, quelli che erano veramente successo? Esempi come le Olimpiadi Invernali del 2002 e il Concentratore di rame Batu Hijau suggeriscono che questi sono veramente di successo perché non solo hanno soddisfatto la definizione di successo dei project manager tradizionali, ma hanno anche incontrato la percezione del successo degli sponsor dei progetti.

Come iniziamo a guardare gli esempi come progetto Orion, il Corporate Intranet e l'Aggiornamento computer portatile, abbiamo avviso che le metriche tradizionali iniziano a fallire. Questi progetti sono considerati successi nella definizione di successo del progetto , ma non è riuscito a soddisfare i criteri di successo degli sponsor . L'esempio del progetto Orion è piuttosto sbalorditivo in quanto questo progetto è stato riconosciuto da PMI (Progetto Management International) nel 1997 come il progetto internazionale dell'anno. Eppure non ha aumentato le entrate di Kodak , perché non prevedevano l'adozione di fotocamere digitali .

I più interessanti sono gli esempi di l'Ottimizzazione dell'impianto di produzione e la Sydney Opera House. Entrambi, , non erano in grado di soddisfare le tradizionali metriche di successo dei gestori , ma erano considerati positivi in ​​ . Questo è particolarmente scioccante quando vedi che il Teatro dell'Opera di Sydney aveva un superamento del 1300% " " e un superamento del programma del "del 250%".

Una volta che ci rendiamo conto che i progetti possono fallire per soddisfare le metriche tradizionali di successo, ma ancora avere successo per le parti interessate, questo crea un dilemma per il responsabile del progetto. In che modo lo definisce il successo? È possibile che un progetto "Challenged" potrebbe essere annullato che avrebbe incontrato esigenze degli sponsor? È anche possibile identificare un progetto che deve essere annullato che è attualmente in tempo, nel budget e nel soddisfare le esigenze definite ?

Cosa ne pensi di questa conclusione? Come definisci davvero il successo?

Answer 25

La mia risposta è piuttosto insolita dal resto di questo, ma abbastanza comune da queste parti: insetti killer. Ho avuto un progetto per un extra di due settimane (50% di tempo in più) a causa di uno switch in source che non conoscevo fino a quando non ho scavato il codice sorgente (non c'era nulla di documentato in help o sul web).

Answer 26

Penso che questo thread sia riuscito a riunire il più grande gruppo di sviluppatori di software infelici, ingegneri, project manager, ecc. Che è possibile riunire in un unico posto.

I condivido il punto di vista con la maggior parte dei post bloccati qui e penso che escano da molte sofferenze vedendo i colleghi non fare un buon lavoro quando lavoro (programmazione) e il successo è la parte più importante di le nostre vite.

http://www.clean-code-developer.de/ Hanno una causa incredibile! e la loro filosofia, se portata avanti, potrebbe riuscire a creare un nuovo livello di eroi, in quanto il flusso principale di sviluppatori e professionisti IT è così ROT in questi giorni.

Sto lavorando a qualcosa di simile qui in Brasile, "perché amo la nostra professione di portare il software vivo sia come sviluppatore di PM e software (.NET) e non sopporto le persone che affrontano la programmazione come nient'altro via d'uscita per fare big soldi con quasi nessuno sforzo.

... certo che non considero il passare la notte di fronte alla genialità del computer. ma i pochi che contano lo hanno fatto più di una volta.