Sono uno sviluppatore in un team di 5 membri e credo che il nostro progetto sia destinato al disastro. Descriverò perché tra un momento, ma la mia domanda è: come dovrei comportarmi?

La scadenza è tra 1,5 mesi e non mi sento in alcun modo responsabile, questo progetto fallirà. Sono dell'opinione che dovremmo semplicemente terminare il progetto e smettere di perdere tempo, ma politicamente penso che sia impossibile per il nostro manager farlo.

Cosa devo fare in questo caso? Dovrei impegnarmi di più o dovrei semplicemente rilassarmi? E cosa dovrei dire al manager?

Ragioni per cui questo progetto è destinato al fallimento:

• Con l'avvicinarsi della scadenza molte delle funzionalità indispensabili non sono state completate
• L'applicazione è instabile e molto difficile da usare
• Il sistema è molto complicato, il codice è molto difficile da capire, molto difficile da modificare - Il modello di dati è troppo guidato da un database relazionale complesso (oltre 100 tabelle)
• Leadership poco chiara; il gestore risponde a nuove informazioni con importanti cambiamenti
• Quasi nessun test automatizzato o unit test
• Dipende fortemente da altri sistemi, ma non esistono ancora test di integrazione

In realtà, abbiamo appena ereditato questo progetto (insieme al pasticcio) circa 1-2 mesi fa da un altro team di sviluppo sotto lo stesso manager, che ci ha lavorato per alcuni mesi.

Comunica le tue preoccupazioni nel modo più conciso e non conflittuale possibile nella scala di gestione. Riassumi i rischi, ma non imporre loro le tue conclusioni.

La direzione deve sempre scegliere cosa fare, ma è il tuo compito valutare e comunicare la situazione. Usa la posta elettronica, in modo da lasciare una scia di carta quando le cose vanno a sud.

Fatto ciò, continua a lavorare sul progetto in buona fede.

Tieni presente che potresti non sapere tutto quello che c'è da sapere sul progetto, i suoi sostenitori e le decisioni finanziarie che stanno dietro. Le decisioni di gestione che ti sembrano stupide potrebbero in realtà basarsi su un ragionamento intelligente che non ti è visibile.

Tenere una traccia cartacea (ad es. Diario, e-mail salvate, ecc.). Includere solo fatti e osservazioni oggettive . Lascia tutte le conclusioni a chi (se qualcuno) legge ciò che hai scritto.

Come sviluppatore, se non sei visto come un ostacolo al progetto, probabilmente uscirai bene dal dito puntato che senza dubbio accadrà. Il tuo manager potrebbe non essere così fortunato, ma non è rilevante qui.

Solo su principi generali, aggiorna il tuo curriculum e assicurati di incontrare occasionalmente altri sviluppatori esterni alla tua azienda. Se non fai parte di nessun gruppo di sviluppatori locale, iscriviti alla sezione 2 o 3. Ci vogliono anni per costruire una rete di amici e conoscenti, ma alla lunga ne vale la pena. Assicurati di vederlo come una strada a doppio senso: se puoi aiutare a riempire un'apertura nella tua azienda con qualcuno in grado, è altrettanto buono come qualcuno che ti aiuta a trovare un lavoro.

Ti consiglierò di prenderti un po 'di tempo per leggere 2 libri.

Death March è il libro canonico che descrive uno stile di gestione del progetto patologico molto diffuso nello sviluppo del software. A causa della compressione programmata, del gonfiore delle funzioni o della cattiva gestione, molti progetti finiscono in cattivo stato; aiuta a capire che non sei solo e che il tuo progetto non è l'unica marcia della morte. L'autore Edward Yourdon classifica i progetti senza uscita in 4 quadranti, ognuno dei quali ha diverse strategie di coping. A volte l'unica strategia di coping è di andarsene. Penso che questo libro ti aiuterà a capire qual è la tua gamma di opzioni e restringere ciò che puoi e non puoi fare.

Catastrophe Disentanglement è scritto di più per i project manager. Ha lo scopo di capire come valutare un progetto interrotto: cosa deve essere tagliato, cosa può essere tagliato e come presentarlo ai clienti? La gestione di progetti software "convenzionali" ci porta in progetti disordinati e non sfuggiremo ai nostri problemi usando lo stesso pensiero che ci ha portato in primo luogo. Questo libro è un po 'più difficile da leggere rispetto a Death March , ma è buono da avere nella tua libreria.

3 strategie semplici e ciniche per mantenere carriera / sanità mentale.

1. Guarda un disastro ferroviario in corso - scendi dal treno: i progetti falliti sono terribili per il morale e, a meno che tu non abbia abilità di gestione ascendente ninja, avrà un impatto negativo sulla tua carriera. Salta ora se riesci a vedere un atterraggio morbido.

2. Se non funziona, tieni la testa bassa: le persone inizieranno a cercare persone da incolpare, non renderle facili per loro! Mentre le crescenti preoccupazioni nella catena di gestione potrebbero essere la cosa giusta da fare, è sia inefficace che rischioso. È improbabile che il tuo manager riesca a sollevare le tue preoccupazioni e bypassarlo non solo ti farà sembrare entrambi male, ma potrebbe marchiarti come un "piantagrane", cioè il tipo di persona che può essere incolpata per aver indebolito il progetto in primo luogo ecc. Questo ovviamente significa anche essere professionali, mettiti nei tuoi orari ma non eroici.

3. Pianifica un'uscita di emergenza su T + 1: concediti alcune opzioni e fai subito le basi per un potenziale trasferimento interno o esterno. Parlare alle persone; non c'è motivo di aspettare che gli altri decidano cosa fare con te quando il finanziamento del progetto viene tagliato o per essere sommerso dall'inevitabile "fuga" di persone che migrano via in un paio di mesi.

Ci scusiamo se sembra eccessivamente cinico, ma se l'hai chiamato correttamente, non c'è vantaggio di soffrire lo spiacevolezza che ti viene incontro. Sii professionale, sii ottimista ma sii sempre realistico.

Che impatto avrà questo progetto che presto fallirà sulla tua carriera in azienda e oltre? Nella mia esperienza, il semplice fatto di essere associati a progetti di successo non è un indicatore della tua eccellenza personale.

Le qualità che mostri di fronte alle avversità e talvolta ciò che sembra essere un certo fallimento, spesso vengono notate dai superiori, più di quanto pensi. E sto parlando al di là del tuo diretto manager.

Personalmente ho provato a vedere il mio diretto manager licenziato per incompetenza, e poi mi sono ritrovato nella sua posizione lo stesso giorno. Non è piacevole, ma ha dimostrato che la gente mi stava osservando e mi è piaciuto quello che ho fatto.

Spesso, lo stesso caos e la stessa disorganizzazione che derivano da un progetto fallito, ti offrono l'opportunità di brillare.

Quindi guarda il progetto in questo modo: quale opportunità offre questo progetto fallito, affinché la luce risplenda su tutti i miei punti di forza e le mie migliori qualità? Quali lezioni sto imparando da questa esperienza, che mi renderà un professionista migliore e una persona migliore?

In sostanza, la somma delle esperienze tratte dai fallimenti è ciò che alimenta il vero successo.

Nota: Thomas Owens ha chiesto, quali cose specifiche una persona può fare in un progetto come questo. Ho alcuni suggerimenti generali, che ho usato come linee guida personali in queste situazioni. Aiuterà un progetto di soccorso ad avere miracolosamente successo? No, ma ho scoperto che mi ha aiutato a mantenere una prospettiva adeguata sulle cose e a trovare il successo personale nonostante la brutta situazione.

1) Concentrati sull'eccellenza personale - cerca di scrivere codice sempre migliore, rispetta standard sempre più elevati di qualità e funzionalità.

2) Concentrati sulle metriche personali: quanto codice scrivi, che genera bug successivi? Riduci quel rapporto al minimo possibile. Quando ti viene chiesto di fornire un preventivo per un'attività che ti è stata assegnata, sei generalmente accurato o ritieni che tu abbia sovra / sotto bufferizzato troppo la sequenza temporale? Quando viene effettivamente assegnato un compito, fornisci un buon livello di feedback sull'avanzamento del lavoro, incluso un avviso anticipato sui problemi relativi alla cronologia delle consegne?

3) Concentrarsi sulle metriche del team - Queste sono solo alcune cose fuori dalla mia testa: gli altri membri del team sono in ritardo a causa di una dipendenza da un'attività su cui stai lavorando? Sei bravo a delegare o dividere il tuo compito / sottoattività ad altri nel team? Trovi difficile comunicare con uno o più membri del team? Tutte le aree su cui lavoro per migliorare regolarmente.

In una situazione come questa, come il gradino più basso della scala, c'è solo così tanto che puoi fare per aiutare il progetto.

• Assicurati che il tuo lavoro sia immacolato
• aiutare a identificare le maggiori aree problematiche
• Cerca di fornire risposte, non solo problemi. Sembra che tu stia cercando di risolverli.

A parte questo, devi davvero occuparti del numero 1.

• Documenta tutto
• conserva tutte le email, le conversazioni di messaggistica istantanea
• Prova a trovare una via d'uscita dal progetto, se possibile

I progetti falliti possono essere tossici per l'anima, causare depressione, lavoro eccessivo e scarsa autostima.

È tutto relativo alla prospettiva.

Ho lavorato su progetti orribili mentre ero seduto di fronte a un altro ragazzo che aveva un sorriso sul suo volto ogni singolo giorno. Oh, come volevo schiaffeggiare quel sorriso dalla sua faccia.

Alcune persone non sono infastidite dallo stato attuale di un progetto. Godono del loro contributo, dei loro compiti e stanno lavorando nel dominio dei loro interessi. Mentre altri, hanno una forte reazione negativa allo stato attuale delle cose. Riguarda le nostre aspettative percepite per i nostri lavori quotidiani.

Mentre potresti fare un po 'del lavoro che ti piace. Ci sono chiaramente elementi nel progetto attuale che non ti piacciono.

Devi identificare quali sono questi elementi problematici e affrontarli.

• pressione di scadenza
• controllo di qualità
• professionismo
• guida da parte della direzione

Esistono molti team e aziende che non ritengono importanti gli aspetti di sviluppo di cui sopra. Quello che ho scoperto è che spesso pensano quanto segue.

• La pressione nei termini è percepita come un modo per motivare le persone.
• La qualità costa di più e il limite di restituzione.
• La professionalità si applica ad altre aree dell'azienda.
• Un manager è un cronometrista e non una persona che contribuisce allo sviluppo.

Questi problemi non sono tuoi. È loro e non dovresti sprecare energia per il loro comportamento. Se non sei uno dei ragazzi che sorride e gode del suo lavoro anche mentre si dirige verso una scogliera, allora dovresti pensare a trovare un posto di like mindedsviluppatori.

Sarai molto più felice.

Cerca di essere proattivo nel trovare un nuovo modo per raggiungere il successo del progetto. Pensa a come proporre alcune alternative. In questo momento il tuo capo sta probabilmente venendo maltrattato sul fatto che il progetto sia un fallimento, non apprezzerebbe qualcuno che arriva con soluzioni invece di problemi?

Forse c'è un modo per dividere le funzionalità in risultati sfalsati? Ci sono spesso gradi di "must have", quindi vedi se riesci a ottenere quelle prioritarie e raggruppale in pietre miliari. Meglio avere un prodotto alla fine della cronologia che niente. Oppure considera la divisione del team tra persone che lavorano su nuove funzionalità e altre che lavorano sulla stabilità, in questo modo puoi mostrare alcuni progressi su entrambi i fronti.

Se questi sforzi hanno successo, avrai dimostrato di essere un membro del team che può trovare un modo per avere successo, in caso contrario, avrai comunque dimostrato che non ti arrendi e lavorerai per trovare una soluzione.

Sembra che la maggior parte dei progetti a cui abbia partecipato. Probabilmente non finirà male come pensi, tuttavia:

1) Fai il tuo lavoro. Non preoccuparti troppo del progetto complessivo, purché completi le tue responsabilità.

2) CYA. Se il progetto fallisce e sospetti che il manager inizi a incolpare tutti tranne lui, assicurati di avere prove sufficienti di aver fatto tutto il necessario per te (vedi il punto 1).

3) Fornire alcuni suggerimenti educati per il miglioramento. Non suonare le campane di avvertimento, non essere cupo e cupo, sii solo educato e sottile.

Ad esempio, se il team non sta scrivendo test unitari efficaci (o qualsiasi test), scrivi alcuni unit test più vicini a ciò che vorresti vedere e menziona causalmente come farlo ti ha aiutato a risolvere un particolare problema o ti ha fatto risparmiare tempo.

Qualunque cosa finisca per essere, se vuoi influenzare, cambia la concentrazione sui passaggi positivi che hanno risultati concreti. Questo progetto potrebbe non rivelarsi mai un vincitore, ma forse il team può imparare per il prossimo.

Anche:

4) Il refactoring opportunistico è tuo amico.

1. Lavorare duramente; ma non a spese della tua famiglia o della tua salute.
2. Tenere un registro di tutte le decisioni di progettazione critiche; soprattutto per quanto riguarda il tuo lavoro.
3. Mantenere la rete e mantenere aperte le opzioni se la situazione diventa troppo difficile o si diventa vittime di un licenziamento di massa.
4. Cerca di non pensare al tuo progetto come a un "progetto fallito". A tutti piacciono le persone che rimangono positive e combattono duramente di fronte alle avversità. Quindi il più a lungo possibile, cerca di essere quella persona. Una prospettiva positiva, grinta e determinazione fanno sempre bene al posto di lavoro.
5. Se stai anticipando un progetto fallito, allora stai anticipando una riunione post mortem. Alla riunione post mortem, tutti saranno tenuti in conto. Preparati a difendere tutto il tuo codice. [Nota: come regola generale, dovresti sempre scrivere un codice pulito in modo che sia facile difenderlo in seguito.] Se hai un documento di posta elettronica o di progettazione che ha ispirato le tue decisioni, allora è ancora meglio.
6. In quella riunione post-mortem, cerca di rimanere positivo; e solo presentare il vostro e-mail e il design prove documento se il vostro giudizio, lo sforzo, o di lavorazione è chiamato in causa.

Quello che ho trovato più efficace è la raccomandazione di Robert L. Read su come combattere la pressione del programma . Ecco cosa scrive Read:

La chiave per combattere la pressione del programma è semplicemente trasformarla in pressione del time-to-market. Il modo per farlo per dare visibilità al rapporto tra lavoro disponibile e prodotto. Produrre una stima onesta, dettagliata e soprattutto comprensibile di tutto il lavoro coinvolto è il modo migliore per farlo. Ha l'ulteriore vantaggio di consentire di prendere decisioni di buona gestione in merito a possibili compromessi di funzionalità.

L'intuizione chiave che la stima deve chiarire è che il lavoro è un fluido quasi incomprimibile. Non puoi impacchettare più in un arco di tempo più di quanto puoi mettere più acqua in un contenitore oltre il volume di quel contenitore. In un certo senso, un programmatore non dovrebbe mai dire "no", ma piuttosto dire "A cosa rinuncerai per ottenere quella cosa che vuoi?" L'effetto di produrre stime chiare sarà quello di aumentare il rispetto per i programmatori. Ecco come si comportano gli altri professionisti. Il duro lavoro dei programmatori sarà visibile. Stabilire un programma non realistico sarà anche dolorosamente ovvio per tutti. I programmatori non possono essere ingannati. È irrispettoso e demoralizzante chiedere loro di fare qualcosa di irrealistico.

Quando si afferma che il progetto è "destinato al fallimento", si basa sulla valutazione di quali compiti devono essere svolti e di quanti sforzi ciascuno di essi richiederà. Rendere tale valutazione esplicita , comprensibile e dettagliata . Separare le attività nelle loro parti componenti; Spiega nel modo più dettagliato possibile come trascorrere il tempo di sviluppo.

Una volta che lo fai, hai una solida base per discutere delle preoccupazioni con il management. Con ogni probabilità, una volta suddivisa la valutazione in tutte le attività specifiche che devono essere completate, sarai in grado di dimostrare che il lavoro richiede più tempo di quello che hai, probabilmente molto, molto di più.

Dopo aver discusso questo programma dettagliato con il tuo manager, preparati a essere flessibile. Il tuo manager potrebbe dire "L'attività X non richiederà un mese; ci vorrà una settimana al massimo" o "L'attività Y è del tutto superflua, tagliala dal programma". Puoi certamente discutere questi punti, ma ciò che è molto più importante è raggiungere un'intesa tra te e il tuo manager su una versione realistica di un programma. In questo modo, se non ti viene assegnato il tempo per, diciamo, i test, allora hai una direttiva esplicita per non testare, piuttosto che perdere il tempo "inaspettatamente". Ed è sicuramente possibile che il tuo manager sia legittimamente disposto a tagliare esplicitamente alcuni angoli per spedire in tempo - ci sono molti casi in cui "

Il preventivo ti dà sostanza concreta per discutere e discutere. Ti mette sulla stessa pagina; ti aiuta a sentirti sicuro che il tuo manager ha tenuto conto delle tue preoccupazioni. E ti porta al punto in cui se il tuo manager chiede chiaramente l'impossibile, sarà perfettamente evidente per entrambi. Se il progetto è ben condannato, l'avrai chiarito e spetterà al tuo manager decidere con precisione come vuole che tu trascorra il tuo tempo.

Poiché il tuo manager sa che probabilmente fallirà, stai meglio della maggior parte. Vorrei prendere in considerazione la possibilità di lavorare con il gestore e vedere se ci sono parti / funzionalità dell'app che possono essere escluse.

Troppo spesso pensiamo che ogni richiesta del cliente sia un "affare killer" e facciamo di tutto per promettere la consegna. Fino a quando qualcuno non lavora con il cliente e approfondisce i sondaggi, potresti non essere in grado di prendere queste decisioni. Se non sei in grado di farlo, prova comunque a fornire ciò che ritieni più importante. A volte è più facile chiedere perdono che permesso.

Ho partecipato a tre progetti che erano chiaramente un fallimento. Questi sono stati abbastanza dolorosi ma guardando indietro, due su tre non hanno avuto conseguenze negative sulla mia carriera, e anche il terzo non era la fine del mondo.

Ecco alcune osservazioni che ricordo.

Gli sviluppatori nelle posizioni junior ("codice per specifica", "correggi il bug", cose del genere) non ne risentono molto, a meno che non si rilassino a causa del morale basso nella squadra. In posizioni come queste, una strategia di sopravvivenza ragionevole e talvolta talvolta vincente potrebbe fare il meglio che puoi.

• ^{Ad esempio, uno dei fallimenti che ho riscontrato è stato superato da una semplice e metodica correzione di oltre cento bug noti che (abbinati a un approccio particolarmente intelligente nel promuovere questi progressi da parte del capo della tecnologia) alla fine hanno portato i vertici aziendali a decidere di recuperare il progetto e dare ancora un'altra possibilità con una nuova versione, che a sua volta ha avuto un discreto successo.}

I programmatori in posizioni più senior e influenti sarebbero meglio preparati a condividere le conseguenze negative del fallimento del progetto. Un architetto, un capo tecnico e uno sviluppatore senior dovrebbero in genere avere un impatto abbastanza grande da essere considerati responsabili del successo o dell'insuccesso del progetto.

In posizione di alto livello, sarebbe meglio essere preparati a trarre vantaggio dal fallimento "indirettamente", analizzando cosa è andato storto e cosa avrebbe potuto essere fatto meglio.

Queste conoscenze, le lezioni post mortem possono essere preziose se apprese nel modo giusto, la carriera di grande successo in posizioni senior può dipendere da quanto bene vengono appresi, come spiegato in questa brillante risposta al WP :

Il giudizio non viene dal successo, ma dai fallimenti. La maggior parte delle aziende vuole assumere persone che hanno avuto i loro fallimenti pagati da società precedenti ...

Su una nota più pratica, si può considerare l'approccio "next / update release" come una possibile via d'uscita dal fallimento. Per coincidenza o no (penso di no ), ma entrambi i fallimenti che non hanno danneggiato la mia carriera sono passati da scenari molto simili: il rilascio è Nstato un disastro totale, il rilascio è N+1stato tollerabile, i rilasci N+2e in seguito sono stati un vero successo.

Camminando nei tuoi panni, molto probabilmente mi impegnerei a preparare / promuovere l'idea della "prossima uscita". Crea (e comunica !) Qualcosa come un elenco provvisorio di problemi noti che vorresti risolvere dopo il rilascio pianificato. Elaborare una road map informale e approssimativa per le prossime versioni.

Pensa a come potresti comunicare queste idee alle persone intorno a te, a come potresti influenzare il management a considerare questo piano. Se il progetto ha qualcuno con buone capacità di marketing, prova a coinvolgerli nell'ammortamento del danno da fallimento, concludendo la prossima versione in termini più fluidi, come "accesso anticipato", "beta", "anteprima cliente", "versione introduttiva", cose come quello.

Pensa a un piano di backup nel caso in cui i piani superiori sembrino sordi a questa idea. Ricordi sopra la storia di "correzione di oltre cento bug noti"? c'è davvero la possibilità che le cose cambino.

Il management può sembrare sordo alle idee della prossima versione, ma c'è una buona possibilità per loro di riconsiderarle di fronte a prove convincenti e convincenti dei progressi della qualità del progetto.

• ^{È abbastanza probabile che tra il blocco del codice per il rilascio pianificato e la decisione della gestione ci sarà un tempo piuttosto lungo per eliminarlo completamente. Quella volta è la tua occasione: se concentri gli sforzi per risolvere problemi noti e "evangelizzare" correttamente i progressi, questo potrebbe fare la differenza (come una volta mi ha fatto).}

Ci sono già molti consigli pratici (e non) di consulenza, ma per me le chiavi di questo mistero sono i seguenti due punti (enfasi sulla mia):

La scadenza è tra 1,5 mesi

e

... abbiamo appena ereditato questo progetto (insieme al pasticcio) circa 1-2 mesi fa da un altro team di sviluppo sotto lo stesso manager ...

Così....

Benvenuti nel Team Patsy The Avengers

Il team precedente aveva cose migliori da fare ... che fallire. E in qualche modo il manager ha accettato. Cambiare team così vicino alla scadenza non è la mossa migliore per la gestione dei progetti, quindi ... che succede?

Correzione: la squadra precedente è stata sostituita, ~ 3 mesi prima della scadenza.

-> Scopri come il precedente team di sviluppo è riuscito a fuggire e fallo. <-

3 mesi sono a malapena il tempo di accelerare su un sistema di queste dimensioni apparenti, tanto meno correggere la sua architettura, aggiungere test e finirlo. Hai bisogno di più tempo

E se non puoi farlo, a meno che tu non sia assolutamente certo che il progetto sarà esteso indefinitamente, o aiutato da elfi magici o qualcosa del genere, non vuoi essere l'ultimo uomo rimasto a tenere la borsa.

Harsh? Sì. Ma mentre scarsa pianificazione (almeno!) Dalle squadre precedenti / manager non è colpa tua, 'mancata consegna' sarà .

La squadra precedente è stata salvata . La squadra precedente è stata presa a calci sul marciapiede. Che cosa vi dice? Mi dice che sei il team di turnaround ... e il tuo manager conta sul tuo eroismo per salvare la giornata.

Una squadra di 5 persone e 1,5 mesi alla fine. Il nuovo team ha avuto il progetto solo per 1-2 mesi, quindi il nuovo team non è nemmeno oltre la curva di apprendimento . Considerando approssimativamente le dimensioni di questo progetto, mi sembra che il nuovo team non avrebbe mai superato la curva di apprendimento anche se il progetto non avesse avuto alcun problema.

Quindi, (ancora) penso che tu sia stato ingannato.

Se questo è il caso - e solo tu puoi decidere cosa è vero, o cosa vuoi credere - non devi a nessuno una spiegazione o delle scuse per esserti allontanato da questo disastro ferroviario. Tuttavia, devi essere discreto al riguardo.

Dubito seriamente che il manager non sia a conoscenza del fatto che il progetto sia a rischio, il che significa che delle spiegazioni delicate non attireranno altro che l'attenzione negativa. A meno che il tuo manager non sia Mr. Rogers , il tuo futuro è a rischio.

Ma ricorda sempre : non prendere consigli sulla carriera da estranei su Internet.

Questa è un'incredibile opportunità per te! Diamo un punto di vista imprenditoriale su questo.

Supponendo che la direzione desideri che questo progetto abbia successo, sei in un'ottima posizione per aiutarlo a farlo. Il motivo per cui questa realizzazione è così importante è perché devi sviluppare la convinzione e la fiducia che i segnali di avvertimento che stai vedendo in realtà porteranno al fallimento di questo progetto [1].

Questa è la tua occasione per esercitare importanti abilità nel pensiero sistematico e nella comunicazione interpersonale. Comprendi e visualizza i problemi e le potenziali opportunità che ci mancano in modo da poter sviluppare una strategia per comunicarli nel modo più chiaro e semplice possibile.

Riconosci la tua opportunità qui per migliorare le tue abilità.

[1] L'annullamento del progetto sarebbe effettivamente un successo. Il fallimento sarebbe spendere soldi buoni dopo cattivi.

Cosa sai fare

• Trattalo secondo i tuoi stessi termini di autoeccellenza, è il "loro" progetto, ma anche il tuo, prendi la proprietà anche se sai che fallirà. Perché? perché a) potresti aiutarlo a fallire un po 'meno, b) in tempo di sfida, è qui che impari di più c) dovresti misurarti attraverso le tue metriche di eccellenza, facendo del tuo meglio potresti non salvare il progetto, ma tu potrebbe finire per essere ancora orgoglioso di te stesso

• Parla con altri colleghi sviluppatori e vedi cosa ne pensano, probabilmente scoprirai che molti condividono la stessa frustrazione, se fatti con attenzione (non far pensare alle persone che vuoi iniziare un ammutinamento o qualcosa del genere), questo può aiutare non solo te ma anche altri

• Ignorare il problema non lo farà andare via, parlando di come, contro ogni previsione ancora farcela, ad esempio almeno ottenere alcuni must have decenti, o il principale caso d'uso "wow factor" fatto bene, potrebbe rendere questo il progetto fallisce meno miseramente. Come farlo? beh, poche idee su "quando andare duro diventa difficile" o "tempi disperati giustificano misure disperate" e altri cliché, ad esempio: uso massiccio di OSS, metodologie di programmazione / agilità estreme, hackathon del fine settimana (solo volontari, non costringere le persone a fine settimana di lavoro). Questo è il momento in cui puoi mostrare la leadership (attentamente se non sei in una posizione di leadership / senior) ma puoi sfruttare questo vantaggio e diventare il loro beffardo, fai solo capire alle persone che potrebbero ottenere questo progetto solo un po 'meno tutti sanno che lo farà.

• Assicurati che il tuo management lo sappia, ma molto, molto attentamente, se lo sapranno, apprezzeranno che tu glielo dica in modo non conflittuale e calmo, se non lo apprezzeranno ancora di più, e si chiederanno perché nessuno lo abbia detto su di esso prima. Dovresti dirgli questo come un servizio, senza alcun lato emotivo, solo fatti concreti e senza un ordine del giorno. Se ti chiederanno cosa pensi che dovrebbero fare (il che è un ottimo segno, ma raro), consulta la sezione successiva

Cosa non puoi fare, ma probabilmente la tua gestione dovrebbe

• Non dovrebbero aggiungere più persone al progetto "per aiutare" a vedere questo

• Chiama immediatamente il cliente e comunica loro le cattive notizie. Perché questa è una buona idea? bene, lascerò citando il manifesto per lo sviluppo di software agile, ma anche senza di esso, anche gli amanti della caduta dell'acqua odiano le brutte sorprese. Se il cliente sa in anticipo che questo progetto è destinato a fallire, sarà infelice, ma sarà molto più felice di dirgli che ci sono problemi prima che gli si faccia male e che tu ci sia, e che faccia del tuo meglio per accogliere esso. Il cliente può fare molte cose, ma la maggior parte di loro non è peggio che scoprire all'ultimo minuto che non hanno un deliverable (o lo fanno ma è di qualità non utilizzabile). Il cliente lo apprezzerà poiché sarà in grado di ritardare l'assunzione di personale addetto ai test, personale IT offshore, modificare i propri piani di formazione interna e tutto solo perché si è onesti con loro.

• con il cliente, pensa a modi per ottenere qualcosa dal progetto, il più comune è la decopitazione delle cose. ad esempio, potrebbero esserci alcune funzionalità che sono troppo difficili da sviluppare nel modo in cui sono state progettate, e se il cliente accetterà alcune piccole modifiche e semplificazioni, allora alcune funzionalità diventeranno più semplici.

• Aggiorna la loro gestione superiore, li aiuterà anche a mantenere il loro lavoro ...

Cosa NON dovresti fare

• Chiedi di aggiungere più persone al progetto (vedi questo )

• Esci / cerca un altro lavoro (almeno non ancora), questo è qualcosa da cui puoi imparare e che cosa ti renderà un giorno uno sviluppatore o un manager migliore. Imparerai ad apprezzare molte cose meglio, gestire meglio il tempo, progettare meglio, scrivere codice meglio e lavorare meglio con colleghi e gestione. Cerca un lavoro dopo questi 2 mesi se non ti piace lavorare lì, non per altri motivi.

• Lamentare, lamentarsi o essere negativi riguardo al progetto, alla gestione, alla cattiva progettazione che hai ereditato, agli sviluppatori principianti che hai avuto modo di farti mentire che ti ci vogliono 3 ore per spiegare loro di fare qualcosa che ti richiede 1 ora, sii positivo tanto quanto te può.

• Critica la gestione e diventa un bersaglio come piantagrane, sono nella stessa barca e potrebbero sapere cose che non conosci, tutto ciò che puoi fare è aggiornarle (aggiorna sempre il tuo manager diretto, non aggirarlo mai)

• Incolpare le persone (o te stesso), non aiuta, mai

• Prendilo troppo sul serio, a meno che non si tratti di attrezzature mediche, nessuno probabilmente morirà se manchi le scadenze, è un software, ci mancano le scadenze per vivere, rilassarti.

Sono solo i miei due centesimi, YMMV

Trova i problemi in cui si trova il tuo progetto e prova a quantificare chiaramente il più oggettivamente possibile. Con ogni "metrica" ​​quantificata, assicurati di definire il motivo per cui ritieni che questa metrica sia importante. Volete dare al vostro manager una visione di quali sarebbero le conseguenze se una determinata metrica non rientrasse in un "intervallo accettabile". Dovrai fornire alcune linee guida per ciascuna metrica per indicare quali valori sono "Buono", "Accettabile", "Problematico" o "Cattivo". Definire in anticipo tutti i criteri. Se possibile, potresti descrivere ciò che sarebbe minimamente necessario per il successo di un progetto e contrastarlo con il progetto attuale.

• La qualità del codice statico può essere quantificata da numerosi strumenti di analisi statica. Puoi mantenerlo semplice o dettagliato come ritieni opportuno. Le metriche che ti suggerisco di iniziare con:
  • Complessità ciclomatica
  • Dimensione del codice (ad es. Numero di righe per funzione / classe, numero di file, numero di tabelle ...)
  • Identifica quali moduli sono troppo grandi
  • Duplicazione.
  • Adesione allo stile del codice
• Tasso di difetto
  • per KLOC per modulo e / o sottosistema (identificare le parti problematiche del sistema)
  • potresti calcolare quanto per membro del team, ma penso che dovresti tenerlo per te
  • risolto vs trovato
  • tempo necessario per risolvere un bug (forse se questo è incline fare un grafico di questo)
  • forse fare una stima di quanto tempo è necessario se questo continua ad andare al ritmo attuale
• Pianificazione
  • Tempo estrapolato utilizzato per le funzionalità create. Prendi in considerazione la complessità della funzione. Questo non deve essere molto preciso. Quello che vuoi comunicare con questo sarebbe sulla falsariga di "La caratteristica A, B e C sono circa la stessa complessità di D, E e F. Con le caratteristiche ABC ha usato il 170% se il tempo pianificato. Se nulla cambia, ci aspettiamo lo stesso tempo necessario per DEF "o sulla falsariga di" La funzione media impiega il X% di tempo in più rispetto al calcolo. Non abbiamo motivo di presumere che il resto della funzionalità sia più facile da costruire, quindi dovremmo compensare questo nella pianificazione futura È inutile avere una pianificazione se non è realistica.
  • Prova ad avere un programma di rilascio mensile o preferibilmente anche più breve. Se solo interno. Questo potrebbe aiutarti ulteriormente estrapolando il tempo necessario per il progetto. Questo potrebbe anche salvarti dal prendere impegni non realistici (se non ti impegni a nuovi lavori prima che venga fatta una liberatoria). Prepara una pianificazione per ogni cilindro e assicurati che le nuove funzionalità entrino solo nel ciclo successivo (cioè non possono mai essere aggiunte al ciclo corrente).
• Copertura del test: spiega i valori "normali" della copertura del test e mostra come è la tua copertura attuale
• Documentazione: quanto% è effettivamente documentata? Quanto è buono?
• modularità:
  • Basato sulla classe (accoppiamento e coesione)
  • Basato sul pacchetto
  • Basato su sottosistema (quanti percorsi di comunicazione ci sono?)

Dovresti andare a lavorare e fare quello che faresti su qualsiasi progetto, che abbia avuto successo o meno. Vieni pagato per svolgere il tuo lavoro. Fallo al meglio delle tue capacità. Supponendo che non sei il project manager / lead, non è tua responsabilità decidere che un programma debba essere annullato o meno. Decidere di rallentare è lo stesso che prendere la decisione di annullare il progetto. Non fa parte della descrizione del tuo lavoro.

Tuttavia, nel quadro più ampio, ciò non significa che dovresti lavorare 50, 60 o più ore alla settimana per cercare di rispettare il programma. Ancora una volta, è compito della direzione capire come raggiungere gli obiettivi del progetto. Le settimane di lavoro di oltre 50 ore non sono un'opzione ragionevole a meno che non siano disposte a pagare gli straordinari e non si desideri mettere in pausa la propria vita familiare. Ancora una volta, è stato compito del management mettere insieme un programma realizzabile. Non possono presumere di poter forzare i dipendenti a ignorare la loro vita familiare al fine di rispettare programmi non realistici.

Inoltre, mentre il programma potrebbe indicare 1 1/2 mesi rimanenti. Questa probabilmente non è la data "drop dead". Alcuni clienti potrebbero prendere quello che hai entro quella data, anche se non è tutto. Alcuni clienti potrebbero ottenere finanziamenti extra, poiché hanno già investito molti soldi nel progetto. A volte la società stessa può sostenere costi aggiuntivi per garantire un cliente soddisfatto. Tutto ciò è fuori dal tuo controllo. Fai il tuo lavoro al meglio delle tue capacità. Ciò fornirà opzioni di gestione con cui lavorare che potrebbero trasformare un progetto di disastro in una grande storia di successo. L'ho visto succedere molte volte.

Posso solo ribadire ciò che hanno detto gli altri, ma sottolineo con enfasi: cercare sempre il tuo miglior lavoro e mantenere una traccia cartacea. per motivi tecnici e di CYA.

Qualsiasi caduta che si presenta sulla tua strada dipende dal carattere personale dei dirigenti; ma lascia che ti dica che è l'inferno di essere a capo di una gestione bugiarda incompetente. Ma il peggio che lascerai con te stesso (e il tuo pari) rispetto intatto.

Tieni buone note sugli aspetti tecnici della tua Marcia della morte. Quando hai ricevuto l'inevitabile domanda del colloquio sei stato su un progetto fallito; perché ha fallito e cosa hai fatto per cercare di prevenirlo? La gestione di Bonehead non è una risposta, anche se è la ragione.

Potrebbe essere una via d'uscita semplice supporre che si tratti di un inevitabile e totale fallimento e rinunciare al progetto. Come consulente sono spesso invitato ad aiutare con i progetti che sono in varie fasi di degenerazione, falliti o falliti e parte di ciò che mi viene pagato è il rilancio e il completamento di tali progetti.

Ciò che vedi come un fallimento completo, potrebbe non essere percepito come tale da tutti, a seconda della prospettiva. In un mondo ideale, ogni funzionalità sarebbe completa, codificata in modo elegante e indipendente da altri sistemi e ogni linea di codice testata. Non ho visto un singolo progetto simile al Rev. 1. Nel mondo reale, spedire un progetto significa prendere alcuni compromessi, forse anche perdere alcune funzionalità chiave ma il prodotto può essere spedito e anche se sarà al meglio la qualità beta , almeno riceverai il feedback su quali cose risolvere per prime. Il vantaggio di questo è che può informare il management che il software non viene mai eseguito e piuttosto che cercare di sviluppare una certa v 1.0 nel vuoto è meglio iterare e rispondere ai cambiamenti in modo agile. Finalmente per te come sviluppatore in questa posizione, Penso che la cosa chiave sia sviluppare il miglior codice possibile in queste condizioni: documentarlo, scrivere test da soli, se è necessario (specialmente per le dipendenze esterne) e utilizzare la propria conoscenza del sistema per comunicare quali funzionalità sono veramente cruciali e devono -have e quali possono attendere una settimana o un mese. Renditi vocale delle tue preoccupazioni e giustificale come hai fatto con noi. Invece di prepararti per il piano B, preparati al fatto che tu e altre povere anime probabilmente risolverete tutto quel codice difettoso e non ancora fatto DOPO che il prodotto è stato spedito - come detto sopra questo significa scrivere il codice in modo disaccoppiato modulare - se pensi che il codice del livello di persistenza sia cattivo, si spera che tu sia in grado di sostituirlo completamente nella prossima revisione. Infine, non disperare: affrontare questa situazione fa parte di ciò che viene pagato ed è un processo di apprendimento. Indipendentemente dal risultato di questo particolare progetto, ciò sarà considerato un'esperienza preziosa in futuro.