Quali sono i segnali premonitori dell'imminente destino a cui prestare attenzione per un progetto? [chiuso]

Codifica eroica

Codificare fino a tarda notte, lavorare a lungo e fare un sacco di straordinari sono un chiaro segnale che qualcosa è andato storto. Inoltre, la mia esperienza è che se vedi qualcuno che lavora fino a tardi in qualsiasi momento del progetto, peggiora sempre di più. Potrebbe farlo solo per riavere il suo unico film nei tempi previsti, e potrebbe avere successo; tuttavia, la codifica dei cowboy come quella è quasi sempre il risultato di un fallimento della pianificazione che inevitabilmente ne causerà presto una maggiore quantità. Quindi, prima ci si vede nel progetto, 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 capire meglio il problema, ma in realtà non lo fai. Oh, e tutte quelle brutte toppe? Sono soluzioni ai problemi del mondo reale che probabilmente si reintrodurranno nella riscrittura.

Inoltre, un giorno dovrai spiegare al responsabile del progetto perché dopo sei mesi di lavoro hai quasi l'85% delle capacità e il 150% dei bug che l'applicazione aveva quando avevi iniziato.

Un nuovo strumento come risolutore di problemi.

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

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

Le nuove tecnologie e le pratiche sono grandiose, ma non si ottiene quasi mai tutti i benefici dal gate.

Per me, il singolo problema più grande e quello che puoi individuare immediatamente è quando l'azienda considera i requisiti scritti come una perdita di tempo.

Quindi fondamentalmente; Nessun requisito scritto

È il bacio della morte.

Gestione disconnessione

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

• Caratteristica insidiosa quando il cliente parla con qualcuno che non comprende il costo della funzione
• Sindrome uomo-mese, dove i nuovi sviluppatori vengono lanciati in un progetto abbastanza tardi da essere più di un ostacolo che un aiuto
• Scadenze non realistiche, create da persone che devono affrontare le conseguenze aziendali delle decisioni di scadenza ma non le conseguenze dell'implementazione.
• Prodotti che non risolvono il problema, quando la comunicazione tra cliente e sviluppatore è ostacolata dalla gestione nel mezzo.
• Scarsa gestione del rischio, in cui potenziali problemi non vengono comunicati abbastanza presto tra gli sviluppatori e la gestione.

Quindi, quando sembra che la gestione non sia interessata al progetto, stia comunicando male, non stia ascoltando i clienti, o non stia ascoltando il team di sviluppo, corri per le colline.

1. Quando gli sviluppatori chiave escono e la gestione non gli interessa

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

Il numero uno è di solito indicativo di manager che sono molto sfortunati con le dinamiche del team (chi è la "super star 10x", chi 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 restanti.

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

Di solito precedono qualcosa a cui non abbiamo il tempo di non farlo, come la documentazione o le revisioni del codice (che statisticamente trovano e correggono più bug che qualsiasi altra cosa, incluse tutte le forme di test)

Lascia che il cliente, il marketing o il management scelgano una data e poi provi a tornare indietro a una pianificazione immaginaria

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

Porta a scadenze che non saranno mai soddisfatte, che porta a una mancanza di fiducia nel reparto IT che porta gli sviluppatori a creare hack (ad esempio, accedere 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 la direzione non è disposta a passare cattive notizie sulla catena o verso il cliente nella speranza che andrà via - cioè gestione con pio desiderio. Non riesco a pensare a quante volte, gli sviluppatori hanno dimostrato di non poter rispettare le scadenze di settimane o addirittura mesi prima e tuttavia nessuno vuole dire al cliente. Raramente ho visto un cliente che non avrebbe spinto una scadenza quando c'è una vera ragione per quando il bisogno è spiegato con largo anticipo; Ho visto spesso un cliente incazzato quando ha detto il giorno della scadenza che non sarebbe stato raggiunto e che non sarebbe stato raggiunto il giorno dopo neanche due mesi lungo la strada. A questo punto, giustamente, potrei aggiungere, mettere in discussione i tuoi processi - come mai non lo sapevi prima? (Vera risposta, ma quella che non abbiamo mai dato - lo sapevamo ma non avevamo paura di dirtelo.)

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

Un altro sicuro segno di fallimento è quando gli sviluppatori stanno lavorando a pezzi che dipendono da altre cose che sono state fatte prima e quelle cose non sono state fatte o nemmeno avviate. Se la direzione non può ottenere il lavoro assegnato nell'ordine corretto, stai andando giù per le valvole.

Ovviamente la funzionalità di creep senza spingere indietro la scadenza ogni volta è uno dei segni più comuni che le cose andranno male. Aggiungi 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 la direzione inizia a parlare di portare più corpi per recuperare tempo nel programma. Non ho mai visto più corpi su un aiuto per il progetto.

Quando i manager non tecnici iniziano a insistere per prendere decisioni tecniche che non sono in alcun modo qualificate per fare. Grande, grande bandiera rossa!

Il segno più ovvio è un alto ricambio 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. Questo accade specialmente quando i requisiti cambiano più velocemente di quanto tu possa implementarli.

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

• Ognuno è fisicamente e mentalmente esausto
• I clienti / utenti sono chiaramente infelici in termini di tempistiche o di ciò che stanno vedendo
• Il design originariamente bello ora si sente compromesso
• Ti sei rassegnato alle spedizioni con alcuni bug relativamente significativi che preferiresti davvero risolvere ma che non saranno in grado di
• Il tuo orgoglio è il fatto di essere spedito piuttosto che quello che stai spedendo, più vicino alla mentalità di un sopravvissuto che all'orgoglio professionale
• Il team ha paura che ci sono alcune cose che non funzionano e sono ignorando quelle sezioni e sperando per il meglio, perché hanno paura di quello che potrebbe essere lì
• Tutti sono convinti di essere andati oltre (e hanno ragione)
• Le persone mostrano segni di burnout (pessimismo generale, disinteresse, rabbia)

(cribbed da Dynamics di Jim McCarthy di Software Development ).

Codificatori da cowboy, grandi ego e accettazione della gestione

Se il piano del progetto richiede una singola iterazione di progettazione, sviluppo, test e implementazione - la classica cascata - per un progetto più lungo di 1 mese, farei un miglio.

Non è necessario essere completamente agili, ma avere cicli di sviluppo brevi consente di dimostrare progressi a tutti (cliente, management e sviluppatori stessi) e affrontare i requisiti modificati quando accade inevitabilmente.

Sviluppatori in esecuzione Wild nell'intervallo

Questo è successo quando ti rendi conto che altri sviluppatori (o, sfortunatamente, tu) hanno sviluppato un componente che varia in modo significativo dal progetto, e che questo non è stato raccolto fino al test di sistema / UAT. Non sto parlando di bug; Sto parlando di componenti di sistema significativi che mancano funzionalità o che non hanno richiesto funzionalità e che non passeranno mai in UAT senza una rilavorazione significativa. Questo problema indica che:

• Il tuo sistema di qualità è rotto; perché lo sviluppatore interessato non ha raccolto la questione nella fase di progettazione / implementazione. Il codice non è stato esaminato / ispezionato? Perché i test di unità e integrazione non sono stati ripresi? Se non hai una sorta di test unitario / integrazione coerente, sei fregato.
• Il tuo project manager / responsabile tecnico non ha il controllo del proprio team di sviluppo. Se non riescono a portare gli sviluppatori a fornire ciò che è richiesto, non saranno mai in grado di fornire una soluzione completa.

Quando uno sviluppatore principale di un progetto non ha effettuato il check in di alcun codice per settimane e una pietra miliare seria sta arrivando.

Era un lavoro di appalto e lo sviluppatore senior e il PM sul lavoro hanno deciso che volevano collaborare per cercare di ottenere un taglio più grande in modo che l'altro sviluppatore tenesse in ostaggio 3 settimane di codice critico. Alla fine, abbiamo licenziato l'incompetente PM (che stava trascorrendo 6 mesi mettendo il progetto in rovina) e ha parlato con lo sviluppatore.

Inutile dire che il resto del progetto è stato una marcia della morte masochista, il congelamento delle specifiche è stato ritardato, al cliente sono state date alcune caratteristiche di concessione per compensare la terribile programmazione che il PM ha lasciato al progetto e la qualità di il progetto ha sofferto tutto intorno a causa di esso.

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

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

Il mio primo segno su uno è stato quando hanno chiesto quante ore di straordinario ognuno avrebbe impegnato per le prossime dieci settimane e offerto ai lavoratori dipendenti un bonus per il lavoro straordinario, basato sul successo del progetto e rispettando le scadenze.

Altri segni importanti che ho visto: La definizione dei requisiti va oltre la pianificazione e la data di fine non viene spostata. Eravamo alle spalle prima ancora che potessimo iniziare. Hanno preso il tempo lontano dal design, quindi abbiamo iniziato senza design di database e design di siti, ma ci aspettavamo di arrivare in tempo, tra l'altro, facendo importazioni a tabelle non progettate e create ancora.

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 manager stanno scrivendo il codice sul Ringraziamento.

Quando inizi a ricevere e-mail con un timestamp che va oltre le 23:00 e prima delle 6 del mattino.

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

Quando stanno ancora apportando modifiche ai requisiti, il giorno in cui vai al QA o vivi dal vivo.

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

Quando il team del database e il team di applicazione 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 dati e hai bisogno di quei dati nel database per verificare come funziona il codice.

Quando pensi di installare una luce di stop all'esterno dell'ufficio di un manager per informarti se è sicuro avvicinarsi a lui quel giorno.

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

Tuttavia, la chiave è individuare in anticipo un progetto in errore. 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 destinati a fallire IMO.

Sono stato in tre marce della morte negli ultimi cinque anni. Ecco alcune cose che hanno contribuito al mio istinto di incombente destino.

• L'azienda decide di far progettare e sviluppare nuove funzionalità da parte di giovani sviluppatori e assegna agli sviluppatori senior più costosi di correggere i loro bug.
• La società esternalizza componenti software critici a società del terzo mondo che non dispongono delle competenze necessarie per il dominio.
• I cicli crunch-time sono così vicini che la salute delle persone si sta esaurendo.
• Le pillole che la tua squadra guida portano a drogarsi per dormire ogni notte smettono di funzionare.
• Il cliente invia gli ordini di modifica più rapidamente di quanto tu possa analizzarli.
• Dovresti consegnare diversi anni di lavoro in poche settimane, ma la direzione si rifiuta di bloccare le funzioni.
• I fornitori di hardware hanno chiaramente difficoltà a fornire un prodotto lavorabile nei tempi previsti e i responsabili decisionali della tua azienda non prenderanno in considerazione alcuna alternativa.
• Gli sviluppatori di dispositivi prototipo hanno bisogno di avere il fantasma di una possibilità di incontrare il programma probabilmente irrealistico e sono portati ai migliori dirigenti per farli sentire bene.
• Settimana uno: "Oh, schifo, il codice è bacato. Tutti smettono di fare nuove funzionalità e correggere i bug". Seconda settimana: "Oh, merda, non incontreremo il programma delle funzioni. Tutti smettono di correggere bug e scrivere nuove funzionalità". Ripeti all'infinito.
• Lo sviluppo è fatto in un paese e il QA è 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 complicati problemi tecnici in una lingua in cui non sono competenti.

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

Questo è successo per me quando un progetto in cui mi trovavo ha avuto il "cambiamento di direzione del cuore". Stavo facendo domande su come dovrebbe funzionare e all'improvviso nessuno ha avuto un'opinione reale.

Poco tempo dopo il progetto è stato cancellato e tutto il codice bello che avevo scritto è stato scartato.

Paul Vick ha scritto un eccellente post diversi anni fa a proposito di buco nero progetti . Penso che tutto il consiglio sia pertinente. (Ho modificato gli articoli e i riepiloghi per la lunghezza.)

• Obiettivi assurdamente grandiosi . Ad esempio "reimmagini radicalmente il modo in cui le persone lavorano con i computer".
• Termini assolutamente irrealistici . Di solito è perché credono di poter riscrivere la base di codice originale in molto, molto meno tempo di quanto originariamente richiesto.
• Credenze non realistiche sulla compatibilità . Come credere, puoi riscrivere e conservare tutti i piccoli capricci senza alcuno sforzo in più.
• 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 . Solitamente succhiando la linfa vitale da uno o più prodotti consolidati.
• Coinvolgere l'utilizzo di una tecnologia nuova di zecca che non è stata ancora dimostrata . In quanto 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 dalla direzione. Di solito, i dirigenti lo sentono incidentalmente in riunioni non correlate ("Oh, a proposito, tutto sta andando bene, non c'è motivo di preoccuparsi!"), Ma è una bandiera rossa ancora più grande avere un incontro chiamato appositamente per dirlo.

Devo ancora sentire un manager dire qualcosa in questo senso e far sì che not diventi una bugia.

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

• La gestione raddoppia la squadra per finire più velocemente.
• gli sviluppatori iniziano a "seppellire" bug per rispettare le scadenze e, sebbene sia ovvio, vengono ignorati durante la revisione del codice.

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

Una volta ero coinvolto in un progetto gestito da due ragazzi. O non parlavano tra loro o ognuno ha un ego da risolvere, ma stavano sequestrando il nostro lavoro in direzione opposta circa ogni settimana o giù di lì. Non ci è voluto molto per capire che non ci sarà mai alcun risultato. Fortunatamente la mia partecipazione è durata solo pochi mesi.

Vedi questo succinto articolo: Quando i progetti IT vanno bene .

L'assenza di uno qualsiasi degli elementi indicati nell'articolo dovrebbe impostare suonerie di allarme che squillino:

Quindi assicurati che il tuo progetto abbia tutto quanto segue, altrimenti non dovresti preoccuparti:

(per citare l'articolo precedente:)

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

2. "La seconda caratteristica riguarda il supporto e l'impegno delle diverse parti coinvolte in tutto il business, 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 un avvio di un progetto software è un chiaro segnale che fallirà, come una stragrande maggioranza di loro ...