Quali sono i segnali premonitori dell'imminente destino a cui prestare attenzione per un progetto? [chiuso]

Having worked on a failed project is one of the few things that most programmers have in common, regardless of language used, industry or experience.

Bene, questo è un sollievo!

Penso che non avere la supervisione della gestione utile quotidiana è la chiave per individuare lo scorrimento. Credo che se hai le informazioni giuste, se ottieni i tuoi sviluppatori per inserire le informazioni giuste, puoi individuare lo slittamento abbastanza rapidamente. Quello che fai dopo questo - beh, è più politica e meno dev ...

L'ultimo progetto professionale su cui ho lavorato è fallito. Uno dei motivi per cui penso che abbia fallito è una combinazione di tutte le altre risposte (specialmente nessuna specifica scritta). Ma penso che la causa principale sia la mancanza di decisioni.

Ero uno sviluppatore principale e chiedevo al mio manager come voleva che funzionassero alcune funzionalità. La sua risposta è "abbiamo bisogno di raccogliere più informazioni dai potenziali clienti". Quindi ho lavorato su un'area diversa del progetto. Alla fine è arrivato il punto in cui stavo riscrivendo i componenti per essere più pulito perché ogni altra area del progetto si basava su decisioni non prese. Verso la fine ho iniziato a prendere decisioni da solo. Sono stato licenziato a causa del trashed del progetto circa un mese dopo aver iniziato a prendere decisioni.

Riassumo alcune cose a cui prestare attenzione:

1. Nessuna specifica scritta
2. Non sono state prese decisioni, o se sono state fatte sono state formulate solo come "lo faremo in questo modo e reimplementarlo in un secondo momento nel modo corretto"
3. Diverse scadenze mancate
4. Squadra inesperta o con carenza di personale (questo progetto è stato la prima volta che ho usato .Net, eppure ero uno sviluppatore principale!)
5. Dover lavorare in aree già complete perché altre aree richiedono decisioni prese prima che il lavoro possa iniziare. (Naturalmente, sto parlando di refactoring per settimane solo per rimanere occupato)
6. L'idea che qualche nuovo strumento possa radere mesi di tempo di sviluppo

Ci sono molti sintomi (burn out, straordinari, frustrazione, silenzio ...) ma alla fine sai che questo sta accadendo quando le date di rilascio stanno iniziando a scivolare e non sei più in grado di consegnare il prodotto tutte le volte che sei supposto.

Bene, il modo migliore per rispondere è con un esempio:

Bob starts a project by coming up with a genius idea. He begins by creating a plan for the software project that begins with specific steps that need to be completed. However, the steps do not lead to the end-result, but only go a portion of the way there.

Alla fine, il progetto fallisce perché i piani erano incompleti. Non è tanto la mancanza di pianificazione quanto la pianificazione insufficiente

Un progetto e i progetti futuri sono condannati quando l'azienda decide di scrivere un "framework" interno perché tutti i framework disponibili non si adattano perfettamente alle loro esigenze.

Progetti pronti per la produzione, ma le funzionalità continuano ad essere aggiunte.

Tempi di sviluppo lunghi senza un chiaro impegno per il rilascio.

Quando la direzione ha deciso e non fornisce spazio per la rettifica, in tutti i seguenti aspetti:

• Scadenza
• Ambito di applicazione
• Risorse allocate

Tra gli altri segnali, c'è un avvertimento importante per me (forse ho sbagliato, e non è comune): doppie cifre nella versione secondaria come "superproject version 3.16 "