Mantenere vivo un progetto con un "equipaggio scheletro"? Cattiva / buona idea?

Prendere gli sviluppatori di un progetto, che non ha urgenza, è sempre una buona idea. Nove madri non possono fare un bambino in un mese. In sostanza, le prestazioni del team si ridimensionano in modo insufficiente con le dimensioni del team. Vorresti scalare linearmente, ma è molto peggio di quello.
In alcuni casi, due persone saranno più di due volte più produttive di una persona (grazie al completamento di competenze e altre sinergie). Ma in generale, se si abbatte una squadra in una squadra di skeletton, l'efficienza dovrebbe aumentare.

Ora, se si fa tutto questo, solo per dare l'impressione al cliente, che il progetto non è semplicemente fermo, lasciando alcuni uomini paglia sul progetto, mentre si sta pianificando di riprendere il progetto con il pieno squadra più tardi, quindi questa non è una buona idea. Potresti avere qualche codice di merda prodotto e alcune funzionalità scadenti implementate (perché i programmatori junior non sono in grado di gestire il feedback dei clienti). E mentre riprendi lo sviluppo effettivo, il tuo cliente sarà frustrato, perché il progetto sembra bloccarsi o addirittura regredire, mentre ricostruisci / rimuovi ciò che è stato aggiunto durante i 6 mesi.

Domande che vorrei porre - Esiste un piano di progetto originale e stai rispettando tali scadenze (ad esempio le tempistiche del cliente) con questo ritardo di 6 mesi?

Posso prevedere che mgmt chiedesse perché avresti bisogno di sviluppatori senior dopo 6 mesi, dato che il junior sarebbe stato completamente aggiornato a quell'ora. Questa è una tipica mancata comprensione della gestione dei rischi del progetto. Ci sarebbe sempre un altro fuoco da far uscire per gli anziani - quindi è non garantito che torneranno.

Se questo progetto deve essere completamente consegnato secondo i requisiti del cliente, allora suppongo che tu abbia bisogno dei migliori per lavorarci sopra e completarlo. Se il cliente non è preoccupato per un ritardo, allora è una gestione interna del rischio.

C'è sempre la probabilità (ci è capitato una volta) che il junior dev annulli le cose - e crea un bel fuoco per gli anziani per tornare a

Sarei preoccupato di non rivedere mai più gli anziani. Gli anziani tendono ad essere più affascinati dalle prime decisioni in materia di tecnologia e design architettonico in un progetto e raramente sono desiderosi di fare un lavoro di coda su un progetto lungo. In altre parole combatterai sia con la direzione che con gli anziani sulla loro data di ritorno.

Se non sei in grado di determinare se i junior stanno effettivamente facendo buoni progressi , allora tenterei di prenotare una sessione di revisione del codice o del controllo con gli anziani su es. una base settimanale. L'inclusione incrementale lenta di nuove funzionalità non è necessariamente buon progresso . Se i tuoi junior stanno commettendo errori elementari nel processo (ad esempio duplicando il codice), probabilmente stai facendo progresso negativo

C'è un sovraccarico che si verifica spostando le persone e poi di nuovo su un progetto. Tuttavia, se un altro progetto è un compito con priorità più alta, non hai molte altre opzioni se questo progetto non può essere completato rapidamente.

Ignorando il lato politico, non ha alcun senso. In tali condizioni, il progetto rischia di evaporare (*) in ogni caso, quindi ogni centesimo speso su di esso viene sprecato. C'è solo il fatto che la data di completamento del progetto apparentemente non ha importanza, è una strong indicazione che l'intero progetto è probabilmente inutile.

(*) un progetto di evaporazione è uno che non fallisce esattamente, ma nel tempo semplicemente cessa di esistere

Supponendo che questo piano sia stato escogitato dalle parti interessate del progetto piuttosto che dai suoi nemici, avere un lavoro di Jr. dev su di esso senza una vera supervisione per 6 - 12 mesi è un'idea peggiore del semplice lasciare che il progetto giace dormiente per lo stesso quantità di tempo.

La ragione è che il Jr. dev probabilmente non conosce il sistema o il design abbastanza bene da implementare nessuna delle caratteristiche alle specifiche richieste dagli anziani e svolgerà un lavoro non ottimale. Gli anziani, al loro ritorno, avranno la sfida non solo di riacquistare se stessi con un sistema da tempo dimenticato, ma avranno anche un ostacolo in più nel fatto che il sistema sarà stato modificato in modo tale che non si comporti più come quando lasciato così il costo per "rimettersi in gioco" è aumentato sia dalla quantità di cambiamento sia dalla mancanza di qualità in quei cambiamenti. Nel migliore dei casi, lo sviluppatore farà progressi non ottimali ma accettabili su un progetto in cui non è adatto. Il caso medio è che il Jr. fa un lavoro scarso ma gli Anziani lo capiscono presto e buttano via tutte le modifiche apportate nei 6-12 mesi che erano via e prendono come se non fosse mai stato toccato. Il risultato peggiore è che Jr. fa un lavoro scarso e gli Anziani credono erroneamente di poter avanzare comunque e completare il lavoro così com'è, ma si trovano bloccati nelle sabbie mobili a causa della scarsa qualità del codice dello Jr Dev. In tutti i casi di cui sopra, il tempo di Jr. dev è probabilmente passato male, e il salario potrebbe essere meglio utilizzato su un progetto più produttivo. Per quanto riguarda il tempo e gli stipendi dello sviluppatore senior, ciò dipende interamente dal valore del progetto in cui sono stati spostati rispetto al valore del progetto dal quale sono stati spostati.

Se d'altra parte il piano è stato ordito dai nemici del progetto, hanno fatto un lavoro sbalorditivo di impostarlo fallendo mentre appariva segretamente a fare concessioni per supportarlo. Con quella misura è un piano stellare.