Quali sono i segnali di avvertimento del destino imminente a cui prestare attenzione in un progetto? [chiuso]

Avere lavorato su un progetto fallito è una delle poche cose che la maggior parte dei programmatori ha in comune, indipendentemente dal linguaggio utilizzato, dall'industria o dall'esperienza.

Questi progetti possono essere grandi esperienze di apprendimento, disastri che schiacciano l'anima (o entrambi!) E possono verificarsi per una moltitudine di ragioni:

• cambiamento di cuore della direzione superiore
• squadra con scarse competenze / risorse insufficienti
• comparsa di un concorrente superiore durante il ciclo di sviluppo
• sopra / sotto gestione

Una volta che hai lavorato su un paio di progetti del genere, è possibile riconoscere in una fase iniziale esattamente quando un progetto è destinato a fallire?

Per me, un grande segno sta avendo una scadenza esterna dura e veloce combinata con il creep di funzionalità . Ho visto progetti che erano stati ben pianificati e che procedevano come da programma, andando orribilmente fuori dai binari una volta che le richieste di funzionalità in ritardo hanno iniziato ad arrivare e sono state aggiunte al "risultato finale" finale. I proponenti di queste richieste hanno guadagnato il soprannome di Columbo , a causa della rarità di lasciare la stanza senza chiedere "solo un'altra cosa".

Quali sono i segnali di avvertimento che stai cercando per far scattare le campane d'allarme di un destino imminente nella tua testa?

Codifica eroica

Codificare fino a notte fonda, lavorare per lunghe ore e fare un sacco di straordinari è un segno sicuro che qualcosa è andato storto. Inoltre, la mia esperienza è che se vedi qualcuno che lavora fino a tardi in qualsiasi momento del progetto, non fa che peggiorare. Potrebbe farlo solo per riportare la sua unica funzionalità nei tempi previsti e potrebbe avere successo; tuttavia, una codifica da cowboy del genere è quasi sempre il risultato di un fallimento della pianificazione che ne causerà inevitabilmente presto altre. Quindi, prima nel progetto lo vedi, peggio diventerà.

Quando i programmatori iniziano a vincere l'argomento "Il codice è orribile, dobbiamo ricominciare da capo". su qualsiasi applicazione matura.

Potresti pensare di poterlo costruire meglio o di comprendere il problema in modo più completo, ma in realtà non lo fai. Oh, e tutte quelle brutte patch? Sono soluzioni ai problemi del mondo reale che probabilmente dovrai reintrodurre nella riscrittura.

Inoltre, un giorno dovrai spiegare al project manager perché dopo 6 mesi di lavoro hai quasi l'85% delle capacità e il 150% dei bug che l'applicazione ha avuto quando hai iniziato.

Un nuovo strumento come risolutore di problemi.

Quando le persone iniziano a pianificare l'uso di strumenti sconosciuti, non mi dispiace, ma lo tengo d'occhio. Quando iniziano a pianificare tutti i vantaggi pubblicizzati di quegli strumenti nel programma, mi preoccupo. Esempi divertenti:

• Possiamo radere un mese del programma perché proveremo a usare un linguaggio orientato agli oggetti (anche se tutto ciò che abbiamo sono sviluppatori c).
• Proveremo questa nuova cosa di mischia che risolverà tutti i nostri problemi di processo!
• So che è a metà del progetto, ma se cambiassimo gli ORM con qualcosa di nuovo?

Le nuove tecnologie e pratiche sono eccezionali, ma non si ottengono quasi mai tutti i vantaggi.

Per me il problema più grande, e che puoi individuare immediatamente, è quando le aziende considerano i requisiti scritti una perdita di tempo.

Quindi in poche parole; Nessun requisito scritto

È il bacio della morte.

Disconnessione della gestione

Quando i responsabili di scadenze, caratteristiche, personale, ecc. Vengono disconnessi dalle persone responsabili della consegna del progetto. Questo può portare a:

• La funzionalità si insinua quando il cliente sta parlando con qualcuno che non comprende il costo della funzione
• Sindrome del mese-uomo, in cui i nuovi sviluppatori vengono lanciati in un progetto abbastanza tardi da essere più un ostacolo che un aiuto
• Scadenze non realistiche, create da persone che devono affrontare le conseguenze economiche delle decisioni sulle scadenze ma non le conseguenze sull'attuazione.
• Prodotti che non risolvono il problema, quando la comunicazione cliente-sviluppo è ostacolata dalla gestione nel mezzo.
• Cattiva gestione del rischio, in cui i potenziali problemi non vengono comunicati abbastanza presto tra gli sviluppatori e la gestione.

Quindi, quando sembra che la direzione non sia interessata al progetto, comunichi male, non ascolti i clienti o non ascolti il ​​team di sviluppo, corri per le colline.

1. Quando gli sviluppatori chiave se ne vanno e alla gestione non importa

2. Quando gli sviluppatori chiave se ne vanno e nessuno degli altri sviluppatori se ne interessa

Il numero uno è di solito indicativo di manager che sono gravemente in contatto con le dinamiche del team (chi è la "10x super star", che sono i programmatori decenti e come interagiscono tra loro ecc.).

Il numero due di solito indica una grave mancanza di interesse da parte degli sviluppatori rimanenti.

La prima volta che qualcuno, di solito il management dice "non abbiamo tempo di ..."

Di solito precede qualcosa a cui non abbiamo tempo, come la documentazione o le revisioni del codice (che trovano statisticamente e correggono più bug che altro, comprese tutte le forme di test)

Consentire al cliente, al marketing o al management di scegliere una data e quindi provare a lavorare all'indietro secondo un programma immaginario

Quando la direzione è troppo debole per dire "No" al business.

Porta a scadenze che non saranno mai rispettate, il che porta a una mancanza di fiducia nel dipartimento IT che porta gli sviluppatori a creare hack (ovvero l'accesso a db in esecuzione sulla macchina di qualcuno ... da qualche parte) che porta a un incubo per l'IT quando il ' sistema critico "deve essere migrato che porta a ...

Il primo brutto segno a cui riesco a pensare è quando il management non è disposto a trasmettere cattive notizie alla catena o al cliente nella speranza che scompaia, vale a dire la gestione attraverso un pio desiderio. Non riesco a pensare a quante volte gli sviluppatori abbiano dimostrato di non riuscire a rispettare la scadenza settimane o addirittura mesi prima e tuttavia nessuno vuole dirlo al cliente. Raramente ho visto un cliente che non avrebbe rispettato una scadenza quando c'è una vera ragione per spiegare la necessità con largo anticipo; Ho visto spesso un cliente incazzato quando mi è stato detto il giorno della scadenza che non sarebbe stato rispettato e che non sarebbe stato incontrato neanche il giorno successivo, ma due mesi lungo la strada. A questo punto, giustamente potrei aggiungere, mettono in discussione i tuoi processi - come mai non lo sapevi prima.

Un altro segno sicuro che sta arrivando il fallimento è quello di assegnare nuovi sviluppatori alla parte più difficile e complicata del processo piuttosto che alle persone che già comprendono il sistema attuale. Quindi non osservarli attentamente per vedere se stanno davvero completando il lavoro correttamente o se hanno domande (BIG BIG RED FLAG se non ci sono domande). I nuovi dipendenti devono essere monitorati fino a quando non sai di avere davvero le competenze che hanno affermato di avere. Ricordo ancora di aver trascorso un'estate dolorosa a rifare il lavoro (già scaduto quando l'ho preso) di un nuovo dipendente che ha ottenuto un pezzo critico di un progetto e ha detto a tutti che tutto andava bene per mesi e poi ha lasciato senza preavviso una settimana dalla scadenza e nulla di ciò che faceva era utilizzabile.

Un altro segno sicuro di fallimento è quando gli sviluppatori stanno lavorando su pezzi che dipendono da altre cose che vengono fatte per prime e che queste cose non vengono fatte o addirittura avviate. Se la direzione non riesce a ottenere il lavoro assegnato nel giusto ordine, stai andando giù per i tubi.

Ovviamente la funzionalità di scorrimento senza rinviare la scadenza ogni volta è uno dei segni più comuni che le cose andranno male. Aggiungete 20 ore di lavoro al mio piatto, la scadenza viene spostata di 20 ore. In caso contrario, il progetto fallirà, garantito.

Un segno sicuro che ho visto nella mia carriera è quando il management inizia a parlare di come coinvolgere più corpi per recuperare tempo nel programma. In realtà non ho mai visto più corpi su un aiuto di progetto.

Quando i gestori non tecnici iniziano a insistere nel prendere decisioni tecniche che non sono in alcun modo qualificati per prendere. Grande, grande bandiera rossa!

Il segno più evidente è un elevato turnover del personale. Quando tutti sono alla ricerca di un nuovo lavoro, probabilmente dovresti farlo anche tu.

L'altro segno molto evidente è la mancanza di progressi. Se è passato un anno e non sembra che tu sia più vicino all'obiettivo, sei condannato. Ciò accade soprattutto quando i requisiti cambiano più velocemente di quanto tu possa implementarli.

Membri del team annoiati.

Sei "90% fatto", la consegna è la prossima settimana, ma va bene perché tutto ciò che ti rimane è "test".

• Ognuno è esaurito fisicamente e mentalmente
• I clienti / utenti sono chiaramente insoddisfatti delle tempistiche o di ciò che stanno vedendo
• Il bellissimo design originale ora sembra compromesso
• Ti sei dimesso per la spedizione con alcuni bug relativamente significativi che preferiresti correggere, ma che non riuscirai a risolvere
• Rimanete orgogliosi dell'atto della spedizione piuttosto che di quello che state spedendo - più vicini alla mentalità di un sopravvissuto che all'orgoglio professionale
• Il team ha paura che ci siano alcune cose che non funzionano e stanno ignorando quelle sezioni e sperando nel meglio perché hanno paura di ciò che potrebbe esserci
• Tutti sono convinti di essere andati ben oltre (e hanno ragione)
• Le persone mostrano segni di esaurimento (pessimismo generale, disinteresse, rabbia)

(Paralizzato dalla dinamica dello sviluppo software di Jim McCarthy ).

Codificatori da cowboy, grandi ego e accettazione da parte della direzione

Se il piano di progetto prevede un'unica iterazione di progettazione, sviluppo, test e implementazione - la classica cascata - per un progetto di durata superiore a 1 mese, farei un miglio.

Non è necessario essere completamente agili, ma avere brevi cicli di sviluppo consente di dimostrare i progressi a tutti (clienti, dirigenti e sviluppatori stessi) e di far fronte ai mutati requisiti quando si verifica l'inevitabile.

Sviluppatori che corrono selvaggi sulla gamma

Ciò è accaduto quando ti sei reso conto che altri sviluppatori (o, sfortunatamente, tu) hanno sviluppato un componente che varia in modo significativo dal design e che questo non viene raccolto fino a quando non viene eseguito il testing del sistema / UAT. Non sto parlando di bug; Sto parlando di componenti di sistema significativi che mancano di funzionalità o che non sono stati richiesti per funzionalità e non passeranno mai UAT senza rilavorazioni significative. Questo problema indica che:

• Il tuo sistema di qualità è rotto; perché lo sviluppatore interessato non ha riscontrato il problema in fase di progettazione / implementazione. Il codice non è stato revisionato / ispezionato? Perché l'unità e i test di integrazione non hanno ripreso questo aspetto? Se non si dispone di una sorta di test unitario / di integrazione coerenti, si è fregati.
• Il responsabile del progetto / responsabile tecnico non ha il controllo del proprio team di sviluppo. Se non riescono a convincere gli sviluppatori a fornire ciò che è richiesto, non saranno mai in grado di fornire una soluzione completa.

Quando uno sviluppatore chiave di un progetto non ha registrato alcun codice per settimane e sta arrivando un traguardo serio.

Era un lavoro in appalto e più lo sviluppatore senior e il PM avevano deciso di voler unirsi per cercare di ottenere un taglio più grande, così l'altro sviluppatore ha tenuto in ostaggio di 3 settimane il codice critico. Alla fine, abbiamo licenziato il PM incompetente (che aveva trascorso 6 mesi a mettere il progetto in rotta per la rovina) e abbiamo discusso con lo sviluppatore.

Basti dire che il resto del progetto è stato una marcia masochistica della morte, il congelamento delle specifiche è stato ritardato, al cliente sono state fornite molte funzionalità di concessione per compensare la terribile programmazione che il PM ha lasciato il progetto e la qualità del progetto ha sofferto tutto intorno a causa sua.

Il PM ha persino avuto il coraggio di volare giù per il CDR (Critical Design Review) solo per abbandonare l'incontro con il cliente e lanciare un fischio. Quando ha chiesto che le sue spese di viaggio fossero pagate nell'ambito del progetto, gli è stato educatamente detto di andare a fornicare con se stesso.

Posso facilmente identificarmi con almeno 5 delle altre risposte trovate qui che hanno interessato quel progetto. In breve, ho imparato molte lezioni difficili sul mio primo serio progetto di programmazione.

Il mio primo segnale è stato quando mi hanno chiesto a quante ore di straordinario ci saremmo impegnati per le prossime dieci settimane e hanno offerto ai lavoratori stipendiati un bonus per il lavoro straordinario, in base al successo del progetto e al rispetto delle scadenze.

Altri segni importanti che ho visto: la definizione dei requisiti va oltre la pianificazione e la data di fine non viene spostata. Eravamo indietro prima ancora di poter iniziare. Ci sono voluti un po 'di tempo dalla progettazione, quindi abbiamo iniziato senza la progettazione di database e la progettazione del sito ma ci aspettavamo di consegnare in tempo, tra l'altro, effettuando importazioni in tabelle non ancora progettate e create.

Quando gli elementi sul percorso critico vengono eseguiti contemporaneamente anziché in ordine. (Se mi viene richiesto di usare lo strumento X e il programmatore A sta appena iniziando a costruirlo, ritarderà il mio compito.)

Quando i gestori commettono il codice per il Ringraziamento.

Quando inizi a ricevere e-mail con un timbro datetime tra le 23:00 e le 6:00 precedenti.

Quando ogni domanda su come gestire una certa complessità viene soddisfatta con la stessa risposta, "Non preoccuparti ancora di quello".

Quando stanno ancora apportando modifiche ai requisiti il ​​giorno in cui vai al QA o vai in diretta.

Quando inizi ad avere riunioni giornaliere che richiedono diverse ore per discutere della tua mancanza di progressi. Oh, sarebbe perché sono in riunione tutto il giorno. Riunione giornaliera di 5 minuti, riunione quotidiana che dura più di un'ora, non va bene.

Quando il team del database e il team delle applicazioni non parlano tra loro.

Quando il cliente non è in grado di fornire le informazioni promesse in tempo. Soprattutto quando si tratta di file di importazione dei dati e sono necessari quei dati nel database per verificare come funziona il codice.

Quando pensi di installare un semaforo fuori dall'ufficio di un manager per farti sapere se è sicuro avvicinarsi a lui quel giorno.

Penso che sia generalmente facile individuare un progetto fallito quando si avvicina la scadenza. Come hai detto, il creep in combinazione con una scadenza prestabilita è un modo sicuro per uccidere un progetto.

La chiave tuttavia è individuare in anticipo un progetto fallito. Penso che l'unico vero "segno di sventura" in questo caso sarebbe una completa mancanza della definizione di "quando abbiamo finito". A meno che non lo sappiamo all'offset, siamo condannati per fallimento IMO.

Sono stato in tre marce della morte negli ultimi cinque anni. Ecco alcune cose che hanno contribuito alla mia sensazione di imminente destino.

• La società decide di progettare e sviluppare nuove funzionalità per sviluppatori junior e assegna a sviluppatori senior più costosi la correzione dei loro bug.
• L'azienda esternalizza componenti software critici a società del terzo mondo che non dispongono delle competenze di dominio richieste.
• I cicli crunch-time si avvicinano così tanto che la salute delle persone sta crollando.
• Le pillole che la tua squadra prende per drogarsi per dormire ogni notte smettono di funzionare.
• Il cliente invia gli ordini di modifica più velocemente di quanto tu possa analizzarli.
• Dovresti consegnare il lavoro di diversi anni in poche settimane, ma la direzione si rifiuta di bloccare le funzionalità.
• I vostri fornitori di hardware hanno chiaramente problemi a consegnare un prodotto funzionante nei tempi previsti e i decisori della vostra azienda non prenderanno in considerazione alternative.
• I prototipi di dispositivi di cui gli sviluppatori hanno bisogno in modo che abbiano la possibilità di incontrare il programma probabilmente irrealistico vengono portati via e consegnati ai migliori dirigenti per farli stare bene.
• Prima settimana: "Oh, merda, il codice è difettoso. Tutti hanno smesso di fare nuove funzionalità e correggere bug." Settimana due: "Oh, merda, non stiamo andando a rispettare il programma delle funzionalità. Tutti hanno smesso di correggere i bug e scrivere nuove funzionalità." Ripeti all'infinito.
• Lo sviluppo avviene in un paese e il controllo qualità viene fatto in un altro paese a metà del mondo, quindi una comunicazione di andata e ritorno su un bug richiede sempre 24 ore e almeno una delle persone coinvolte sta discutendo di problemi tecnici complicati in una lingua in cui non sono competenti.

Per me, è quando quelli che sono responsabili del set di funzionalità (ovvero gestori, proprietari di prodotti, clienti ...) smettono di preoccuparsi o sembrano avere un'aria senza speranza sulle loro risposte. Le domande sulle funzionalità si incontrano con apatia e scoraggiamento. È chiaro che hanno perso investimenti o fiducia nel progetto.

Questo è successo per me quando un progetto a cui stavo partecipando è stato colpito dal "cambiamento del cuore del management". Stavo facendo domande su come dovrebbe funzionare e all'improvviso nessuno ha avuto un'opinione reale.

Poco dopo il progetto è stato cancellato e tutto il bellissimo codice che avevo scritto è stato demolito.

Paul Vick ha scritto un eccellente post diversi anni fa sui progetti del buco nero . Penso che tutti i consigli siano rilevanti. (Ho modificato le voci e i riepiloghi per lunghezza.)

• Obiettivi assurdamente grandiosi . Come "fondamentalmente reinventare il modo in cui le persone lavorano con i computer".
• Scadenze completamente non realistiche . Di solito questo è perché credono di poter riscrivere la base di codice originale in molto, molto meno tempo di quanto originariamente impiegato.
• Credenze non realistiche sulla compatibilità . Come credere di poter riscrivere e conservare tutte le piccole stranezze senza alcuno sforzo aggiuntivo.
• Sempre "sei mesi" dalla scadenza principale che non sembra mai arrivare . Oppure, se arriva, un'altra pietra miliare viene aggiunta alla fine del progetto per compensare.
• Deve consumare enormi quantità di risorse . Di solito succhiando la linfa vitale da uno o più prodotti affermati.
• Coinvolgere utilizzando una tecnologia nuova di zecca che non è stata ancora dimostrata . Come tali, riescono a eliminare tutti i problemi di scalabilità con la nuova tecnologia.

Traduco mentalmente "Va tutto bene. Non abbiamo nulla di cui preoccuparci." a "Siamo tutti fregati" ogni volta che lo sento dire dal management. Di solito senti i manager lanciarlo per inciso in riunioni non correlate ("Oh, a proposito, tutto sta andando bene. Non c'è motivo di preoccuparsi!"), Ma è una bandiera rossa ancora più grande avere una riunione specificamente chiamata per dirlo.

Devo ancora sentire un manager dire qualcosa in questo senso e non diventare una bugia.

un paio di punti da un progetto morto di cui facevo parte:

• Il management raddoppia il team per finire più velocemente.
• gli sviluppatori iniziano a "seppellire" i bug per rispettare le scadenze e, sebbene sia ovvio, vengono ignorati durante la revisione del codice.

Quando la direzione tira contemporaneamente il progetto in diverse direzioni e il carrello rimane fermo.

Una volta sono stato coinvolto in un progetto gestito da due ragazzi. O non parlavano tra loro o ognuno ha un qualche ego da risolvere, ma stavano guidando il nostro lavoro in direzione opposta circa ogni settimana circa. Non ci è voluto molto per capire che non ci sarebbe mai stato alcun risultato. Volentieri la mia partecipazione è durata solo pochi mesi.

Leggi questo breve articolo: Quando i progetti IT vanno bene .

L'assenza di uno qualsiasi degli elementi indicati nell'articolo dovrebbe far suonare le campane di allarme:

Quindi assicurati che il tuo progetto abbia tutto quanto segue, in caso contrario dovresti preoccuparti:

(per citare l'articolo sopra :)

1. "Il primo è che si basano su una visione chiara di ciò che deve essere raggiunto."

2. "La seconda caratteristica riguarda il supporto e l'impegno delle diverse parti coinvolte nell'azienda, in particolare il senior management".

3. "Terzo è la comprensione dei problemi da affrontare."

4. "L'ultima caratteristica comune è che sono state rese disponibili risorse e competenze sufficienti".

Statisticamente l'avvio di un progetto software è un chiaro segno che fallirà, come la stragrande maggioranza di loro ...