La rotazione degli sviluppatori di un progetto è una buona o cattiva idea?


38

Sto lavorando a un piccolo team che inizierà a lavorare su un nuovo grande progetto con un altro piccolo team. L'altro team sta attualmente lavorando su un sistema legacy su cui hanno lavorato per anni.

Il manager ha deciso che gli sviluppatori del mio team ruoteranno ogni pochi mesi per sostituire gli sviluppatori che lavorano sul sistema legacy. In questo modo l'altro team avrà la possibilità di lavorare sul nuovo progetto e avere una migliore comprensione del nuovo sistema.

Voglio conoscere i vantaggi e gli svantaggi (se presenti) della rotazione degli sviluppatori dal progetto ogni 2-3 mesi.

So che questa è una domanda simile a "Ruotare lo sviluppatore principale è una buona o cattiva idea?" , ma questa domanda si concentra su uno sviluppatore principale. Questa domanda riguarda la rotazione di tutto il team all'interno e all'esterno del progetto (il lead tecnico per il nuovo progetto può o non può essere ruotato - non lo so ancora).


2
C'è una domanda a riguardo in ProjectManagement StackExchange: conosci qualche azienda che ruota regolarmente gli sviluppatori tra diversi progetti?
Spoike,

2
Non volevo trasformare questo in una domanda soggettiva / argomentativa dando la mia opinione personale sulla domanda. La mia sensazione è che questo non sia un buon ide, ma forse c'è qualcosa che non conosco :)
Christian P

1
Quale motivo ha dato il manager quando gli hai chiesto perché? È nel migliore interesse di un'azienda avere una conoscenza condivisa di un prodotto nel caso in cui gli sviluppatori se ne vadano.
dcaswell,

1
Questo é un problema. Se la tua gestione non è già completamente trasparente su questo, probabilmente è un segno che non ci hanno pensato affatto.
Aaronaught,

1
Quello che vorrei suggerire è che tu crei il team iniziale che avvia il progetto composto da alcuni devlopers legacy attuali e da alcuni devlopers del progetto attuale. Tienili attraverso il porject. Alla fine i devlopers lagacy supportano il nuovo prodotto e i nuovi devlopers si uniscono ad altri sviluppatori legacy per fare il prossimo progetto. In questo modo il team è lo stesso attraverso il progetto (o la versione principale) ma le persone legacy si aggiornano su ciò che supporteranno in seguito. Le nuove assunzioni generalmente iniziano con la lega, a meno che non abbiano qualche abilità speciale che il tuo team non ha bisogno del progetto.
HLGEM,

Risposte:


76

Sono sorpreso che tutti pensino che sia una cosa così buona. Gli autori di Peopleware (che, IMO, è ancora uno dei pochi preziosi libri sulla gestione di progetti software che vale davvero la pena di leggere) sono fortemente in disaccordo. Quasi l'intera parte IV del libro è dedicata proprio a questo problema.

Il team del software è un'unità funzionale incredibilmente importante. Le squadre devono gelarsi per diventare veramente produttive. Ci vuole tempo ( molto tempo) per i membri del team per guadagnarsi il rispetto reciproco, per imparare le reciproche abitudini e stranezze e punti di forza e di debolezza.

Certamente, per esperienza personale, posso dire che dopo un anno di lavoro con alcune persone, ho imparato a ridere di alcune cose che mi legavano, le mie stime come capo squadra sono molto migliori, e non è troppo difficile distribuire il lavoro in modo da rendere tutti felici. All'inizio non era così.

Ora potresti dire: "Oh, ma non stiamo facendo a pezzi l'intera squadra, spostando solo poche persone". Ma considera (a) quanto ciecamente improduttivi saranno i loro sostituti all'inizio, e (b) quante volte troverai te stesso o altre squadre che dicono, senza nemmeno pensare, "Mi è davvero piaciuta X" o "Questo avrebbe è stato più facile con Y ancora in circolazione " , offensivo sottilmente e inconsciamente i nuovi membri e creando scismi all'interno della squadra esistente, seminando persino malcontento tra i" vecchi "membri.

Le persone non lo fanno apposta , ovviamente, ma succede quasi ogni volta. Le persone lo fanno senza pensare. E se si sforzano di non farlo, finiscono per concentrarsi ancora di più sulla questione e sono frustrati dal silenzio forzato. Squadre e persino sotto-team svilupperanno sinergie che si perdono quando si fa il giro della struttura. Gli autori di Peopleware lo definiscono una forma di "teamicidio".

Detto questo, anche se i membri del team di rotazione sono una pratica orribile, i team di rotazione stessi vanno benissimo. Sebbene le società di software ben gestite debbano avere un concetto di proprietà del prodotto, non è altrettanto dirompente per un team spostare l'intero team in un progetto diverso, purché il team riesca effettivamente a finire il vecchio progetto o almeno portarlo a un livello di cui sono contenti.

Avendo restrizioni di squadra invece di restrizioni di sviluppatore , ottieni tutti gli stessi benefici che ti aspetteresti di ottenere con gli sviluppatori a rotazione (documentazione, "impollinazione incrociata", ecc.) Senza effetti collaterali negativi su ogni squadra come unità. A coloro che non capiscono veramente la gestione, può sembrare meno produttivo, ma state certi che la produttività persa dividendo il team riduce completamente la produttività persa spostando quel team in un altro progetto.

PS Nella tua nota a piè di pagina menzioni che il capo tecnico potrebbe essere l' unica persona a non essere ruotata. Questo è praticamente garantito per incasinare entrambe le squadre. Il responsabile della tecnologia è un leader, non un manager, deve guadagnarsi il rispetto della squadra e non è semplicemente concesso l'autorità da livelli più alti di gestione. Mettere un intero team sotto la direzione di un nuovo lead con cui non hanno mai lavorato e con cui è molto probabile che abbiano idee diverse su cose come architettura, usabilità, organizzazione del codice, stima ... beh, sarà stressante da morire per il vantaggio cercando di costruire credibilità e molto improduttivo per i membri del team che iniziano a perdere coesione in assenza del loro vecchio vantaggio. A volte le aziende hannoper fare questo, cioè se il lead si chiude o viene promosso, ma farlo per scelta sembra folle.


2
Non essere completamente in disaccordo - tuttavia non è privo di difetti - Le squadre possono e fanno imperi costruiti, a volte questi sbriciolarsi La produttività non è sempre l'obiettivo più importante di una mangiatoia, che (se del caso), guarda più verso la fine del gioco che altro potrebbe essere.
Mattnz,

4
@mattnz: quale "fine gioco" esiste per un manager diverso dall'alta produttività, dalla fidelizzazione dei dipendenti e dalla possibilità di spedire in tempo / budget? Sto parlando di manager etici qui, ovviamente, che vogliono davvero fare ciò che è meglio per l'azienda e non stanno usando la squadra o il progetto come veicolo per promuovere i propri obiettivi di carriera personali. Un'organizzazione software vuole imperi - gli imperi sono stabili e fanno soldi - e sì, gli imperi possono cadere, ma hanno molte meno probabilità di cadere di un castello di carte.
Aaronaught il

2
la rotazione è migliore della gente che lascia completamente l'azienda
warren

4
@warren: se queste due opzioni sono le tue uniche, quest'ultima è quasi inevitabile.
Aaronaught,

3
Seriamente non capisco affatto questa risposta. Tutti in una squadra dovrebbero essere professionisti e lavorare bene con gli altri supponendo che tutti i membri della squadra siano effettivamente competenti, il che è un problema diverso. I membri del team in rotazione sono spesso l'unica scelta per un manager cronicamente a corto di personale in entrambi i prodotti o in cui l'attrito rappresenta una grave minaccia. Spesso è molto difficile trovare un buon talento in primo luogo. I membri del team in rotazione sono un modo per coprire le scommesse contro la partenza degli sviluppatori. È anche più equo per gli sviluppatori che lavorano su software legacy quando vorrebbero imparare qualcosa di nuovo.
maple_shaft

18

Non vedo un aspetto negativo di me stesso qui. La rotazione ti dà:

  • Impollinazione incrociata di conoscenza istituzionale: tutti conosceranno il progetto legacy e quello nuovo, almeno in teoria.
  • Cross training - progetti diversi richiedono spesso cose diverse. Cresci molto di più come sviluppatore che lavora in brutti progetti legacy che in bei progetti greenfield puliti.
  • Progetti sostanzialmente migliori - niente come avere un nuovo team in arrivo per farti finire la documentazione e ripulire i brutti processi con cui sei disposto a convivere ma che non ammetti pubblicamente.
  • Codice migliore: più teste sono migliori nella maggior parte dei casi.
  • Probabili miglioramenti del morale: la varietà è il sale della vita. E chi vuole rimanere bloccato nella modalità di correzione dei bug del sistema legacy / taping permanentemente. Tieni anche presente che il tuo "nuovo" progetto diventerà eredità ad un certo punto, vuoi rimanere bloccato lì per sempre?

Probabilmente l'unico aspetto negativo è il calo di produttività che si ottiene dal passaggio da un luogo all'altro, ma ciò dovrebbe ferire gravemente solo il primo turno. Successivamente entrambe le parti avranno un po 'di tempo per sedersi in entrambi i posti e le parti brutte del passaggio saranno probabilmente meglio comprese e forse risolte.


18
Non vedo come il mio morale sarebbe migliorato se fossi "retrocesso" per lavorare sul sistema legacy.
Telastyn,

3
Un paio di svantaggi stanno aumentando il tempo di sviluppo iniziale e gli altri compiti specifici del team legacy ottengono priorità più basse.
Oded,

16
@Telastyn Se la mia vecchia azienda fosse uscita dal lavoro precedente, lavorerei ancora lì. Certo che fa schifo per essere ruotato, ma fa ancora più schifo sapere che non sarai mai ruotato semplicemente perché hanno bisogno di un dev legacy.
Barbuto,

8
@Telastyn e Christian e altri: è un tuo problema se lo vedi come una degradazione. Lavorare su sistemi legacy è una sfida in sé e per sé che può offrirti un'esperienza incredibilmente preziosa da utilizzare a tuo vantaggio nello sviluppo di campi verdi. Lo sviluppo di Greenfield dovrebbe davvero avere molto meno "credito" di quanto non lo sia in quanto è molto più facile che provare a creare nuove funzionalità su una base esistente anche senza un debito tecnico eccessivo. Lo sviluppo del campo marrone è il luogo in cui trovi i veri artigiani e donne. Sì, li trovi anche altrove, ma non quelli induriti sul campo di battaglia.
Marjan Venema,

8
@MarjanVenema - Mi spiace, fare qualche lavoro di manutenzione a Cobol non farà avanzare la mia carriera. Certo, potrebbe essere necessario svolgere il lavoro e potrebbe anche essere un'esperienza preziosa, ma se il mio manager mi porta a quel tempo pieno, avrò il mio curriculum al più presto. Il fatto è che alcuni sviluppatori lo percepiranno come una degradazione, indipendentemente da ciò che è realmente. Bilanciare questa percezione con il desiderio di impollinare trasversalmente non è un mio problema, è il problema del manager; quello è il loro lavoro .
Telastyn,

6

È interessante notare che, nella mia esperienza, abbiamo spesso avviato i nostri progetti con questo intento. Lungo la linea, spesso non siamo riusciti ad agire su questo intento a causa dei vincoli sul nuovo progetto e della convinzione che il cross training sia troppo costoso.

Vorrei sempre che ci fossimo riusciti, poiché a lungo termine credo che sia vantaggioso per tutte le parti - team, società, client e software. 2/3 mesi sembra un periodo abbastanza lungo che vi è un rischio limitato di qualsiasi impatto negativo grave, non vi è alcun cambio di contesto in corso per gli sviluppatori coinvolti, tranne nel momento in cui possono dedicarsi al progetto alternativo.

Un paio di possibili benefici non menzionati:

  • Migliore gestione del progetto. Se i project manager di entrambi i progetti sono a bordo, è nel loro interesse lavorare sodo in modo che i periodi di transizione non siano dolorosi per nessuno dei due progetti. Questo è il turno (a seconda della configurazione) potrebbe portare a una più stretta collaborazione tra i PM e i team di sviluppo.
  • Migliore documentazione (proattiva). Se sai che stai entrando e uscendo da un progetto, non è solo nel miglior interesse del progetto, nell'interesse delle aziende, delle migliori pratiche in generale, ma ora in ogni sviluppatore il miglior interesse per rendere la vita facile mentre rimbalzano in giro.
  • La cosa morale è un grosso problema, se i tuoi sviluppatori non hanno avuto abbastanza di essere bloccati su un progetto legacy, allora potrebbero non essere gli sviluppatori che desideri! Se lo fanno, cambiarli e convincere altri sviluppatori a lavorarci su farà sentire l'amore per la tua azienda - potrebbero semplicemente mettere in ordine i frammenti di codice che pensavano che nessuno avrebbe mai visto. I sistemi legacy sono spesso visti come progetti di seconda classe che spesso vanno a scapito di loro, forse in questo modo puoi aiutare a cambiare quella percezione.

Penso che sia così che finisce nella maggior parte delle aziende. Obiettivi elevati, ma le esigenze di rapida inversione di tendenza e di riduzione dei costi immediata minima di solito precludono il cross-training e lo sviluppo incrociato a causa della perdita di produttività nel portare qualcuno di nuovo al passo con i tempi su un progetto.
BBlake,

2
@BBlake Sì, sfortunatamente è così. Peccato, perché è molto miope e rischioso per un'azienda "limitare" la conoscenza di sistemi importanti a un numero inferiore di persone.
Marjan Venema,

1
Sfortunatamente, la maggior parte delle aziende, compresa la principale banca mondiale che ho lasciato di recente per lavorare altrove, è più interessata ai profitti per questo progetto o settimana o ciclo di bilancio, piuttosto che a pianificare in anticipo i costi che si verificano quando uno sviluppatore senior ( come me) lascia. Senza budget per il cross training sulle applicazioni, solo io avevo una conoscenza avanzata. Aggiungi le dozzine di ore di lavoro sprecate per rintracciare i problemi di produzione che avrei potuto risolvere in un paio d'ore perché conoscevo i sistemi. Corto, ma questo è il modo aziendale.
BBlake,

@Marjan: sarei disposto a scommettere che i costi sostenuti per fare il cross-training su base regolare sarebbero molto, molto più alti dei costi di formazione di un nuovo noleggio, se necessario, se qualcuno lascia. Ora, se un'intera squadra se ne va, allora è una questione diversa.
Dunk,

1
@Dunk: non so che sarebbe. L'allenamento incrociato non deve spingersi fino a renderlo un esperto nel campo che non è direttamente suo. Deve solo spingersi al punto di garantire che l'impresa non si metta immediatamente in pericolo e rischi di perdere clienti quando gli esperti del settore lasciano il terreno facendo arrestare lo sviluppo in quel campo. Nessuno è insostituibile, ma le imprese corrono rischi quando conoscenze o abilità importanti sono limitate a pochissime persone. E i costi di tale rischio che diventano realtà possono essere davvero molto elevati.
Marjan Venema,

4

La rotazione è una buona cosa per l'azienda e può essere una buona cosa anche per gli sviluppatori.

Ci sono molte buone ragioni e Wyatt ne ha menzionato molte nella sua risposta.

Detto questo, nella tua situazione, potresti scoprire che quando si introduce questo, gli sviluppatori che stanno spostando il progetto più recente sul progetto legacy potrebbero non essere felici, quindi ci deve essere una comunicazione molto chiara sul perché questo accada e per quanto tempo è per, e il piano andrà avanti.

Potrebbe essere utile pensare di non scambiare le squadre all'ingrosso per iniziare e ruotare 1 o 2 sviluppatori per cominciare, anche se questo potrebbe sembrare come individuare le persone per una degradazione (che alcune persone potrebbero vedere).


Mi piace l'idea di scambiare solo 1-2 sviluppatori per cominciare. Ciò contribuirà a ridurre l'impatto negativo iniziale sulla produttività.
superM

Hai a che fare con sviluppatori di software, non con persone normali. Gli sviluppatori di software tendono ad essere logici. Non possono essere facilmente manipolati come il grande pubblico incorporando idee come sopra. Altri trucchi sono più efficaci su di essi, (ad es. Monitor più grandi, computer più veloci), ma non lo stile politico come questa idea sta cercando di fare. Sarà negativo per quelli del nuovo team di sviluppo, qualunque cosa accada. Le promesse di ricompense (es. Vedi sopra) sono circa l'unico modo per nascondere il cattivo gusto. Certo, sarà fantastico (all'inizio) per i ragazzi malvagi, fino a quando non si renderanno conto di non essere all'altezza.
Dunk,

2

Concordo con Aaronaught che è molto strano vedere quante persone semplicemente non vedono gli svantaggi ... Pochi pensieri negativi, che puoi puntare molto velocemente - il codice non ha il proprietario e quando tutti sono responsabili di tutto non è così buono per la qualità . Gli sviluppatori non sono risorse (anche se vengono chiamati così spesso dai manager), sono persone e per il team è molto importante conoscersi, la rotazione fa un po 'caos lì. Se lavori per qualche progetto più a lungo diventerai un esperto (non solo nel dominio, ma in quel progetto), saprai da dove provengono la maggior parte dei problemi, chi ti darà le risposte migliori o forse alcune conoscenze di dominio più specifiche ecc. Se sei nuovo, dovrai imparare tutto ciò che pensa, quindi rallenterà i progressi. Ma ovviamente è anche bene conoscere altre pratiche nella tua organizzazione, come gli altri team costruiscono e organizzano. È particolarmente utile se i tuoi progetti sono correlati in qualche modo, ad esempio un progetto è inserito per un altro (non necessario direttamente), quindi otterrai una migliore comprensione del quadro generale. E, naturalmente, la diffusione delle competenze è buona (se avrai tempo per ottenere queste conoscenze).


questo post è piuttosto difficile da leggere (wall of text). Ti dispiacerebbe modificarlo in una forma migliore?
moscerino

2

Sono d'accordo con la risposta migliore di Aaronaught e ho alcune aggiunte.

  • Alla gente non piace essere spinta in giro.
  • In un contesto aziendale gerarchico, alle persone possono essere assegnate responsabilità che vengono successivamente rimosse da loro. Questo potrebbe far parte del lavoro. Tuttavia, più spesso ciò accade, minore è la probabilità che queste persone si sentano responsabili di qualsiasi cosa a loro assegnata.
  • Il primo punto si applica anche ai lavori di manutenzione su cose che le persone stesse non hanno creato. Pulire il caos di altre persone (o più neutralmente formulato: lavoro incompiuto) non è particolarmente motivante per la maggior parte degli individui creatori.
  • La filosofia "un programmatore è un programmatore è un programmatore, sono plug-in anonimi da inserire nei progetti secondo necessità" non fa sentire programmatore apprezzato o si preoccupa di più dei compiti che gli vengono assegnati.

Il momento perfetto per riassegnare chiunque è quando iniziano ad annoiarsi con quello che stanno facendo. Non c'è altro da guadagnare, tutto è sotto controllo, il lavoro è fatto. In questi casi, in genere si fanno avanti e chiedono altre opportunità stesse.

Naturalmente la realtà è testarda e spesso non c'è scelta, qualcuno potrebbe essere necessario altrove per qualsiasi motivo. Questo non è necessariamente negativo, può anche far sentire importante una persona e se la persona deve risolvere qualche grosso problema, ci sarà credito per lui.

Mescolare persone in giro per diffondere la conoscenza probabilmente aumenterà il turnover. In questo modo la conoscenza verrà diffusa, ma verrà diffusa al di fuori dell'azienda, che probabilmente non è l'intento.


0

TL; DR Fallo diventare un team e poi è un team che supporta 2 progetti.

Per echeggiare @Aaronaught, penso che mescolare i team possa essere problematico in quanto potrebbe volerci del tempo per adattarsi a nuove pratiche, processi, ecc. Se si ruotano troppe persone per far sì che il team rapidamente perda la sua identità. Questo porta a più domande, confusione e tempo speso cercando di recuperare quell'identità.

D'altra parte, se c'è uno sforzo concertato per unire le 2 squadre in una squadra e avere 1 squadra di supporto 2 progetti, penso che funzioni alla grande finché la squadra non è troppo grande. Ho fatto parte di numerosi team che supportano più progetti. Più la tecnologia si avvicina ai 2 progetti, più facile è la transizione. Nella mia esperienza, il costo più elevato nel passaggio da un progetto a un altro deriva dall'incrocio tra lingue, client / server (in particolare la GUI), industria (medica, web, giochi) o altre linee simili. Il trucco è far sì che diverse persone lavorino sul progetto abbastanza frequentemente per ottenere i benefici, ma non così spesso che il costo di transizione superi i benefici.

Quindi i vantaggi di coinvolgere più persone in un progetto sono abbastanza noti, così come i costi.


1
"Finché la squadra non è troppo grande" è la chiave qui, penso; se ogni squadra ha 10 persone, è molto probabile che una squadra di 20 persone sia troppo grande. Inoltre, se esiste una separazione fisica tra i team (l'OP non specifica), non funzionerà come un singolo team e renderà le cose più disorganizzate. Questo sicuramente potrebbe funzionare, ma dipende dalla situazione (i team possono essere uniti in modo efficace) e anche dagli obiettivi del management (la fusione è più o meno permanente, aggiungerà più risorse ma non raggiungerà gli stessi fini di un progetto rotazione).
Aaronaught,

0

La rotazione dei programmatori è una buona cosa dal punto di vista dell'azienda e dal punto di vista degli sviluppatori.

Dal punto di vista dell'azienda

  1. Il management imparerà a conoscere la forza e la debolezza di un particolare sviluppatore se è in grado di gestire il multitasking o meno e adattarsi ai cambiamenti.
  2. Se qualche sviluppatore lascia l'azienda per qualche motivo, l'azienda ha già il backup pronto per il futuro.
  3. Migliorerà le prestazioni del progetto, poiché molte persone lavoreranno su di esso, la stessa cosa viene testata da sempre più sviluppatori. (Test degli sprechi di risorse ridotto al minimo)
  4. Tutti i membri del team lavorano in gruppo e aumenteranno le prestazioni del progetto e in futuro il management saprà quale tipo di team deve essere creato durante l'implementazione di moduli o attività difficili.

Dal punto di vista dello sviluppatore

  1. Renderà lo sviluppatore più positivo all'aumentare della sua fiducia.
  2. Gli sviluppatori ottengono sempre migliori idee dal codice degli altri compagni di squadra e possono usare quella tecnica per lo sviluppo futuro.
  3. Da idee e suggerimenti migliori degli altri membri del team aumenta la produttività degli sviluppatori.

Solo una cosa principale, è necessario tenere presente che,

La rotazione dei programmatori non dovrebbe avvenire molto frequentemente. dopo lo sviluppo del 60% - 70%, sarà utile solo lo spostamento.


3
Vedo qui molte affermazioni calve. Alcuni di loro non hanno quasi nulla a che fare con la rotazione ("la direzione imparerà a conoscere la forza e la debolezza di un particolare sviluppatore"?), Altri hanno una frase goffa o semplicemente non hanno senso ("tutti i membri del team lavorano in team e aumenterà le prestazioni del progetto "?). Su cosa si basano tutti questi punti? Hai una fonte? È esperienza personale? In tal caso, quale esperienza? La tua "prospettiva aziendale" proviene dall'esperienza come manager o team leader? Hai davvero visto qualcosa di simile funzionare nella pratica?
Aaronaught,

1
La maggior parte di questi benefici proposti sembra davvero essere collegata al fatto di essere semplicemente in una squadra invece di essere ruotati tra le squadre ...
Aaronaught,

primo "La direzione conoscerà la forza e la debolezza di un particolare sviluppatore". è in realtà l'opposto, perché è molto più facile nascondere i tuoi punti deboli quando ti sposti da un posto a un altro, c'è sempre più persone / software da incolpare, perché era tardi, buggy, non fatto.
Dainius,

Non c'è modo in h ... che le prestazioni del progetto non subiranno un impatto molto negativo. Perché mai pensi che le prestazioni di un progetto sarebbero "migliorate"?
Dunk,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.