Qual è il modo più produttivo per gestire i guasti relativi allo sviluppo? [chiuso]

Siamo stati tutti lì:

• Il tuo progetto ha avuto esito negativo o è stato annullato.
• Il codice su cui hai passato giorni a lavorare è stato rifiutato dal tuo team.
• Il modello di design che hai presentato al team ha creato il caos.
• Tutti ignorano le tue idee.

La mia domanda è: qual è il modo più produttivo per un programmatore di gestire fallimenti legati allo sviluppo come questi?

Il tuo progetto è fallito.

Lo sviluppo del software è molto incline a fallimenti del progetto e, a seconda della gravità, è meglio gestito dalla direzione.

Molti progetti hanno fallito e molti altri falliranno, quindi prendi nota! Scopri perché il tuo progetto è fallito, in modo da non commettere gli stessi errori la prossima volta. Impari molto di più dai tuoi fallimenti che dai tuoi successi.

Ciò che hai trascorso giorni in programmazione è stato rifiutato dal tuo team.

Salva il tuo lavoro (per dopo). Ci sono due possibilità: (a) Fa schifo, e il fatto che più persone abbiano risposto allo stesso modo è un'indicazione di questo (b) È veramente un lavoro geniale, ma molto più avanti di ciò a cui le persone sono abituate o possono capire. Alla gente generalmente non piace ciò che non capisce. Forse è meglio mostrarlo quando è il momento giusto O in un posto diverso con una "cultura" diversa

Nessuno ascolta le tue idee nella tua azienda.

Probabilmente è una cattiva idea, O la cultura non è allineata con il tuo pensiero. O spostati in un luogo che supporta la tua cultura o valuta nuovamente la tua idea in modo critico (obiettivamente senza il tuo pregiudizio) -> la mia idea è davvero così buona? <- Uccidi il tuo ego

Il modello di progettazione che hai introdotto con forza nel tuo team ha creato un pasticcio.

Sinceramente, hai fatto del tuo meglio ma non è venuto fuori come lo avevi pianificato. Potrebbe essere meglio ricominciare o imparare dagli errori commessi nel progetto come una squadra e andare avanti.

Non sono fallimenti, sono esperienze

Impara e cresci dalle tue esperienze riflettendo su come ti hanno fatto sentire e se vuoi più di quella sensazione.

Se è una brutta esperienza (come quella lista che hai offerto), probabilmente la brutta sensazione di accompagnamento è qualcosa che vorrai evitare (supponendo che tu non sia così spessa che non ti importava dell'impatto delle tue azioni).

Nel complesso, non essere troppo coinvolto nel paragonarti agli altri, stanno avendo altrettanti problemi a superarlo come te .

• Mantieni la calma - non farti prendere dal panico, non migliorerà nulla
• Controllo dei danni - salva ciò che può ancora essere salvato
• Impara dai tuoi errori: probabilmente fare di nuovo la cosa sbagliata non funzionerà
• Pensa a un nuovo inizio: inizia il tuo prossimo tentativo senza uno zaino di delusioni e sentimenti colpevoli
• Guarda i fallimenti più grandi: rispetto al primo volo di Ariane 5 , il tuo fallimento è trascurabile
• Consulta uno psicoterapeuta se non puoi gestirlo da solo

Costruisci qualcosa.

Per me (non penso che sia giusto per tutti), costruire qualcosa (fumetti, disegni, piccoli giochi, qualsiasi cosa) è come costruire un po 'di fiducia per tornare a combattere i fallimenti. Potrebbe anche essere un buon modo per esprimere la tua rabbia o amarezza o qualsiasi sentimento relativo al fallimento, ma in modo "costruttivo".

Funziona comunque per me.

Bene, hai chiesto :) Uno per uno:

* Your project failed.

Non è certo nuovo. Tutti abbiamo fallito privatamente e tutti abbiamo fallito in piena vista dei nostri pari. Chiunque abbia attraversato l'istruzione primaria e secondaria ha sperimentato questo.

Se non riesco a commettere errori e mi aspetto un impiego stabile, dovresti considerare di inviare un promemoria alle risorse umane per far loro sapere che gli esseri umani saranno banditi da future considerazioni.

Numerosi fallimenti di seguito indicano che hai esigenze e specifiche irragionevoli o che non impari dai tuoi errori. Entrambi gli scenari richiedono un'azione immediata.

È concepibile che molte persone firmino qualcosa solo per ottenere un impiego, quindi escogitano un modo per far sì che i requisiti accadano.

* What you have spent days coding was rejected by your team.

Capita. Come altri hanno notato, salvalo. Fallo ancora. Questo è il motivo per cui lo chiamiamo lavoro. Penso che, in questo caso, probabilmente non hai coinvolto molto la squadra in quello che stavi facendo.

Potrebbe anche essere che i requisiti siano cambiati ieri o un'ora fa. Questa dovrebbe essere un'eccezione, non una norma, comunque. La revisione tra pari è tanto brutale quanto utile. Se il tuo codice viene costantemente respinto come "inadeguato" (o qualcosa del genere), dovresti dedicare più tempo a raccogliere il cervello e coinvolgere gli altri. Credo che questa domanda sia un errore nella maggior parte delle impostazioni del team, a meno che il "team" sia tutt'altro che auto-descrittivo.

* Nobody listens to your ideas in your company.

Ancora una volta, questo ha bisogno di un contesto. Quanto tempo sei stato lì? Quanto si fidano dei tuoi colleghi hacker nelle tue capacità? Hai considerato che le idee che portano a un maggior lavoro per molte persone potrebbero invitare QUALSIASI motivo per respingerlo? Una volta mi è stato licenziato qualcosa perché non era pronto per IPV6, ma utilizzava un semplice socket di dominio sul dispositivo di loopback (esclusivamente). La persona che l'ha affondato semplicemente non poteva richiedere altro lavoro da fare.

Inoltre, quanto ti articoli bene? Puoi fare amicizia e influenzare le persone?

* The design pattern you introduced with force in your team created a mess.

Ecco perché la forza avrebbe dovuto essere evitata. Essere in grado di parlare non è un prerequisito per poter ascoltare. Nessun altro commento

Oh ragazzo, è molto se intendevi davvero tutto quello che ti è successo!

ATTENZIONE : In molti dei punti seguenti potresti pensare che ti critico e che voglio renderti responsabile delle sventure e non considerare fattori esterni. Io non. È solo che non fornisci molti dettagli e fornisco solo liste di controllo delle azioni da intraprendere per garantire che le cose non vadano male. So di aver commesso molti errori da solo (tutti lo fanno) e miglioriamo solo se impariamo da loro. E per imparare da loro, dobbiamo iniziare a vederli come errori in primo luogo e accettare la responsabilità di ciò che è andato storto da parte nostra. Cavolo, accetta la responsabilità di ciò che è andato storto nelle parti di altre persone, puoi imparare anche da quello.

Il tuo progetto è fallito

Non puoi fare molto per mitigarlo ora.

Tuttavia puoi fare molto per evitare che si riproduca in futuro. Suggerirei di provare a migliorare il tuo progetto e le tue capacità di gestione del tempo.

Uno dei libri con il miglior rapporto ((consigli validi) / pagine) che ho letto sull'argomento, anche se forse non il migliore, è il Radical Project Management di Rob Thomsett .

Non specifichi davvero quale sia stato il fallimento del tuo progetto, ma presumo una combinazione di cose che ha portato uno squilibrio nel solito triangolo costo / tempo / qualiy . Il fattore più importante ai miei occhi è quello di guidare il progetto e lo sviluppo rimanendo sempre in contatto sia con i tuoi attori tecnici (sviluppatori e tester), sia con i tuoi stakeholder. Troppi progetti falliscono perché non ascoltano gli sponsor o le parti interessate e non li spingono a partecipare al processo.

Se non sono coinvolti, non puoi sapere cosa vogliono. Se non puoi sapere cosa vogliono, non puoi consegnarlo. Se non lo consegni, saranno infelici. Questo è un fallimento. Inoltre, se non coinvolgi i tuoi stakeholder, questi sono disconnessi dalla realtà dell'ingegneria del software, il che significa che non comprendono i tuoi problemi. Se sono spesso in contatto con te, ottengono una migliore comprensione di ciò che devi affrontare. Saranno più in grado di capire quando dici loro che una "piccola" funzione [risate] richiederà mesi. Possono fidarsi meglio della tua pianificazione perché ti hanno aiutato a costruirla. Un progetto non può avere successo solo con "specifiche all'inizio, sviluppo, test, consegna alla fine". Semplicemente non lo fa mai. Potresti fornire ciò che è stato richiesto nelle specifiche,

Ancora più importante, fai una retrospettiva e assicurati che sia privo di ego e non un gioco di colpa. Basta identificare i problemi.

Quello che hai passato giorni a scrivere codice è stato rifiutato dal tuo team

Sono stato in quella situazione. Ancora una volta, non puoi fare molto per mitigarlo tranne:

• Conservalo in SCM per dopo.
• Forse prova a spingere progressivamente piccoli frammenti nella base di codice principale invece di un enorme refactoring.

Ma ci sono ancora cose che puoi fare per prevenire questo tipo di situazione:

• Perchè è successo? Qual è la ragione del rifiuto?
• Il più delle volte quando vedo che ciò accade (e lo è stato anche per me), significa che lo sviluppatore è andato da solo o in modalità di codifica cow-boy e ha prodotto cose che non erano mai state richieste. Il codice che non deriva dalle esigenze aziendali potrebbe essere elegante e "migliore", ma spesso una perdita di tempo e denaro. Inoltre, avrà un costo ancora maggiore se lo integrerai in quanto dovrà essere testato di nuovo. Pensa come le persone che ti danno i soldi: devi essere efficiente anche a quel livello.
• La qualità del software prodotta è stata soddisfacente? È conforme agli standard e alle convenzioni in attività presso la tua azienda?
• Hai riferito periodicamente (e spesso!) Ai direttori diretti al riguardo? Ti sei scambiato occasionalmente con altri sviluppatori del team? In caso contrario, non ne sanno nulla, sarà un enorme costo per loro valutarlo e rivederlo ora. Alla fine NON tiene conto della stessa ora. È come cercare sempre di rimandare la pulizia del tuo appartamento in affitto e poi provare a pulirlo solo quando ti trasferisci: è un lavoro schifoso, è faticoso, è più difficile di quanto sarebbe stato se fosse stato fatto regolarmente e spesso non lo sarà giusto.
• Hai prodotto test di produzione? Test unitari? Test di integrazione?
• Il tuo codice è stato controllato regolarmente in SCM? Era in un altro ramo? Aveva bisogno di un ramo diverso o avrebbe potuto essere fatto nel bagagliaio? La disattivazione del codice di commit è di solito un brutto segno. Ovviamente a volte sei tentato di farlo, ma ti spari sul piede.

Nessuno ascolta le tue idee nella tua azienda

Bene, ci sono 2 opzioni qui e vedremo entrambe:

• Le tue idee erano cattive.
• Le tue idee erano buone.

Cominciamo supponendo che fossero cattivi (di nuovo, riflettendo su questo e accettare la tua idea era semplicemente un male potrebbe essere difficile, lo so). Cosa fai per cambiarlo?

• Perché ti è venuta l'idea? Qual è la logica ? C'è davvero bisogno di ciò che la tua idea cerca di portare in tavola?
• Come ti è venuta l'idea? L'hai fatto da solo? Hai condiviso? Brainstorm? Piano? Prototipo? (fai queste cose nel giusto ordine. Se fallisce sulla strada, quindi scarta l'idea, non andare avanti. O almeno non nel tuo programma di lavoro.)

Le idee sono solo idee. Se le suggerisci solo come idee e vengono respinte, non vedo perché ti sentiresti male per questo. Se tuttavia ti comporti senza avvisare nessuno e POI solo inviare le tue idee e vengono respinte, ovviamente sento la frustrazione per il momento sprecata. E i tuoi manager lo fanno!

Supponendo che le tue idee fossero buone:

• La tua presentazione è stata buona?
• Il tuo modo di consegnare la presentazione è stato buono? (Sono uno sviluppatore, so di cosa sto parlando: siamo PITA scontrosi, arroganti e pedanti che hanno sempre ragione e con cui è difficile lavorare a causa spesso dei nostri ego sproporzionati ).
• Hai un piano per implementarlo? Hai pensato al costo e al tempo? Hai pensato ai vantaggi per utenti / clienti? Hai pensato come influisce sulle vendite? Pensavi che il lavoro su quell'idea potesse avere un impatto su altri progetti e priorità? Mi dirai "perché dovrei fare tutto questo, sono il lavoro del mio manager e dei team di marketing o di vendita ?!" Tranne ora, stai provando a fare parte di tutti i loro lavori.

Il modello di progettazione che hai introdotto con forza nel tuo team ha creato un pasticcio

• Perché hai introdotto il modello?
• Se ha creato un pasticcio, probabilmente anche:
  • non era il modello giusto,
  • non è stato implementato correttamente,
  • non era integrato correttamente.
• Come lo hai introdotto? Come si definisce esattamente lo stato "pasticcio"?
  • codice meno leggibile?
  • meno gestibile?
  • le build sono rotte?
  • Esistono diversi tipi di "pasticcio". Conoscere ciò che il caos si potrebbe aiutare a conoscere ciò che il fallimento in c'era, e se fosse colpa del modello di progettazione.

Inoltre, sono un po 'sorpreso dall'approccio stesso. Dovevi davvero spingere per introdurre un modello di progettazione? Sembra piuttosto strano. Uno schema è già presente oppure è necessario riformattare una parte della soluzione in base allo schema. Non lo spingi come faresti con l'adozione di un framework o tecnologia (come le persone hanno spinto molto per avere XML ovunque, e ora come le persone iniziano a spingere per essere in grado di scrivere HTML5 sulla copertina del loro prodotto in grandi lettere luminose).

Perché hai dovuto spingere? Perché c'era resistenza? Forse era giustificato.

Sei stato in grado di fornire esempi che questo particolare modello avrebbe aiutato a migliorare la tua base di codice in modi significativi (ad esempio, abbinandolo a un esempio di refactoring ai modelli ).

Nota completamente fuori tema, ma è quello che ho pensato per la prima volta quando ho letto il titolo della domanda poiché pensavo che si riferisse a guasti del software ... Avevo un software che implementava una classe BlackHole per gestire un tipo molto speciale di eccezioni in una delle componenti. Può sembrare (ed è davvero) un trucco ovviamente strano e sporco, ma la denominazione stessa è stata così superba che tutti l'abbiamo apprezzata per un modo abbastanza interessante di gestire un fallimento! :)

Step 1: Va bene arrabbiarsi!

Innanzitutto, è comprensibile essere arrabbiati o arrabbiati quando si incontrano fallimenti. Se danno consigli a qualcuno in una situazione del genere, molto probabilmente non vorranno sentire "Superalo e vai avanti" o "Pensalo come un'opportunità di apprendimento".

In effetti, penso che possa essere sano e produttivo arrabbiarsi e sfogare le tue frustrazioni, a condizione che tu lo faccia privatamente o con un amico. Le persone hanno diversi modi per farlo, ma penso che uno dei modi più produttivi sia scrivere una lettera falsa arrabbiata (Importante! Non inviare questa lettera a nessuno ). Spiega i tuoi sentimenti, ad esempio perché ritieni che qualsiasi cosa sia accaduta fosse ingiustificata.

Passaggio 2: prenditi del tempo per calmarti.

Assicurati di aver espresso tutto ciò che senti e, dopo aver sfogato la tua rabbia, prenditi del tempo per calmarti. Forse ti bastano pochi minuti o forse poche ore.

Passaggio 3: rivedere cosa è successo nel passaggio 1

A questo punto si spera che si possa pensare in modo più obiettivo alla situazione. Se hai scritto una lettera, allora leggila da te. Se ti sei confidato con qualcuno, prova a ricordare cosa hai detto. Se hai solo immaginato di gridare a qualcuno, allora ripassalo mentalmente.

Scrivo spesso una lettera quando sono arrabbiato e poi, dopo essermi calmato, lavorerò sul perfezionamento della lettera per comunicare più chiaramente ciò che stavo originariamente cercando di dire fino a quando non sono soddisfatto che qualcuno leggendolo capirà ciò che ero sentimento al momento.

Il punto è provare oggettivamente a capire quali fossero i tuoi punti. Avevano senso? Forse hanno bisogno di chiarimenti o ulteriori dettagli. Sono infondati? Se dovessi metterti oggettivamente nei panni di qualcun altro, comprenderesti i punti che hai fatto? Sei d'accordo con questi punti? Puoi sfruttare questa opportunità per valutare te stesso. Cosa hai fatto bene? Quali erano alcune cose che avresti potuto fare di meglio?

Passaggio 4: decidere una linea di condotta

C'è qualcosa che può essere fatto per porre rimedio alla situazione o almeno per migliorarla? Prenditi un momento per considerare se c'è realisticamente qualcosa che può essere fatto per risolvere o migliorare la situazione. Spesso non c'è, ma a volte c'è.

Se sei in colpa per qualcosa, allora potrebbe essere semplice come una scusa formale a qualcuno, spiegando chiaramente cosa è andato storto, cosa hai fatto, perché l'hai fatto e cosa farai per risolverlo o impedire che accada il futuro.

Successivamente, considera cosa puoi fare per migliorare il futuro. Cosa puoi fare per impedire che accada di nuovo la stessa cosa? Decidi cosa vuoi ottenere e usa ciò che hai imparato dal passaggio 3 per creare un piano per te stesso.

Se tutto il resto fallisce, prova a riavviare:

        try
        {
            // ...
        }
        catch (OhNoes111Exception)
        {
            // reboot fixes everything!
            System.Diagnostics.Process.Start("ShutDown", "/r");
        }