Come gestire i progetti di programmazione che falliscono?

Non è raro che i progetti falliscano.

Come programmatore, come gestisci i progetti che falliscono?

Alcune definizioni di fallimento:

• Termine mancante.
• Codice e funzionalità non fanno ciò che dovrebbe.
• Il software diventa vapore o numero infinito di fasi, essenzialmente non consegnabili.

O forse hai le tue definizioni di fallimento.

Inizi a puntare le dita? Dai la colpa a te stesso, ai requisiti, alla tecnologia, alla gestione, al cliente, ecc.? Fai una sessione di lezioni apprese in gruppo?

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 molto rari per me. Oltre a capire cosa è successo, faccio la cosa "chiedi perché 5 volte" per cercare di arrivare alle cause sottostanti. C'è anche il motivo per cui non ho notato cosa stesse succedendo e o ho fatto qualcosa al riguardo o almeno ne sono uscito.

Penso che la prima posizione di tutti sia quella di incolpare tutto: il cliente, la tecnologia, il problema aziendale da affrontare, la metodologia, i membri del team, la lingua, la piattaforma, diavolo anche il modo in cui prendiamo il caffè al mattino. La cosa bella di una retrospettiva (anche se succede solo nella tua testa) è la possibilità di riconciliarsi con alcuni o tutti quei fattori e rendersi conto che non erano il problema.

Nel mio unico vero fallimento degli ultimi 30+ anni, il progetto era stato richiesto per letteralmente anni quando siamo arrivati. Abbiamo sistemato i requisiti. Uno proveniva dalla direzione e centinaia dagli utenti finali. Abbiamo scritto codice, molto codice, in parte 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 dell'ultimo minuto e umorismo surreale e escalation ai vicepresidenti e tutto il resto. Alla fine tutto si fermò. La ragione del fallimento era che il requisito di gestione unico era inaccettabile per gli utenti finali. E indipendentemente da quante cose si facessero strada, non potevano superare quella e non avrebbero mai accettato il sistema. Ma la direzione non vorrebbe diversamente. Quindi era quello e sebbene avessimo un sacco di soldi, alla fine era

Lavoro ancora in quella tecnologia, uso ancora quei processi e lavoro ancora con le stesse persone. Farei anche un altro progetto per quel cliente. Ma quando gli utenti finali dichiarano di non gradire qualcosa che la propria gestione ha inserito nei requisiti, ricorderò che scrivere un buon codice che funziona non ti protegge da un progetto fallito. E poi farò qualcosa al riguardo, non un anno o due dopo.

Vattene, puttana da qualche giorno a una settimana mentre evito di fare cose significative, quindi provo a capire cosa è andato storto e come non lasciare che accada di nuovo.

C'è un grande libro sull'argomento chiamato La Marcia della Morte: http://www.amazon.com/Death-March-2nd-Edward-Yourdon/dp/013143635X

Consiglio vivamente di leggerlo. Puoi riconoscere i tuoi progetti in molte descrizioni.

Non esiste una risposta unica in quanto dipende fortemente da molti componenti complessi della tua organizzazione, compresa la politica ...

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