Come gestire progetti di programmazione che falliscono?

12

Non è raro che i progetti falliscano.

Come programmatore, come gestisci progetti che falliscono?

Alcune definizioni di errore:

  • Manca la scadenza.
  • Il codice e la funzionalità non fanno quello che dovrebbero.
  • Il software diventa vapore o numero infinito di fasi, essenzialmente non recapitabili.

O forse hai le tue definizioni di fallimento.

Inizi a puntare le dita? Ti dai la colpa a te stesso, ai requisiti, alla tecnologia, alla gestione, al cliente, ecc.? Fai una lezione imparata come una squadra?

    
posta spong 22.09.2010 - 20:20
fonte

4 risposte

8

Dovresti fare lezioni apprese per tutti i progetti, falliti o riusciti. C'è molto da imparare da un buon progetto.

I veri progetti falliti sono stati per me molto rari. Oltre a capire cosa è successo, faccio la domanda "chiedi perché 5 volte" per cercare di arrivare alle cause sottostanti. C'è anche il motivo per cui non ho notato cosa stava succedendo e faccio qualcosa al riguardo o almeno ne esco.

Penso che la prima posizione di tutti sia la colpa di tutto: il cliente, la tecnologia, il problema aziendale affrontato, la metodologia, i membri del team, la lingua, la piattaforma, diamine persino il modo in cui prendiamo il caffè al mattino. La cosa bella di una retrospettiva (anche se capita solo nella tua testa) è la possibilità di riconciliarsi con alcuni o tutti questi fattori e capire che non erano il problema.

Nel mio unico vero fallimento degli ultimi 30 anni, il progetto aveva richiesto requisiti per letteralmente anni quando siamo arrivati. Abbiamo stabilito i requisiti. Uno proveniva dalla gestione e centinaia dagli utenti finali. Abbiamo scritto codice, molto codice, un po 'di brillante. Ci sono stati test e test di accettazione e cambiamenti e argomenti e richieste di cambiamento e lavoro non retribuito e lavoro retribuito e bulloni all'ultimo minuto e umorismo surreale e escalation ai VP e tutto il resto. Alla fine tutto si è inciampato. Il motivo del fallimento era che l'unico requisito di gestione era inaccettabile per gli utenti finali. E non importa quante cose abbiano ottenuto, non potevano superare quella e non avrebbero mai accettato il sistema. Ma la direzione non l'avrebbe in nessun altro modo. Questo era quello e, sebbene avessimo avuto un sacco di soldi, alla fine era tutto orribile.

Lavoro ancora con quella tecnologia, continuo a utilizzare quei processi e continuo a lavorare con le stesse persone. Farei anche un altro progetto per quel cliente. Ma quando gli utenti finali dicono che a loro non piace qualcosa che la loro gestione ha iniettato nei requisiti, ricorderò che scrivere un buon codice che funzioni non ti protegge da un progetto fallito. E farò qualcosa al riguardo, non un anno o due dopo.

    
risposta data 22.09.2010 - 20:33
fonte
3

Vai via, cagna per alcuni giorni a una settimana, mentre evito di fare cose importanti, quindi cerca di capire cosa è andato storto e come non farlo accadere di nuovo.

    
risposta data 22.09.2010 - 21:58
fonte
3

C'è un grande libro sull'argomento chiamato Death March: link

Ti consiglio caldamente di leggerlo. Puoi riconoscere i tuoi progetti in molte descrizioni.

Non esiste una risposta unica in quanto dipende molto da molte componenti complesse della tua organizzazione, compresa la politica ...

    
risposta data 23.09.2010 - 00:13
fonte
1

Ho incolpato tutti tranne me ... haha, sto scherzando. Quello che faccio è scrivere un doc di "Mea Culpa", con tutte le cose che "ho fatto" di sbagliato. forse non aiuta a quel progetto, ma è un buon modo per non ripetere gli stessi errori

    
risposta data 22.09.2010 - 22:02
fonte

Leggi altre domande sui tag