Ruotare lo sviluppatore principale è una buona o cattiva idea?

Non ruotare.

Non credo che qualcuno guadagni qualcosa dalla posizione che viene ruotata (a parte quelli che non meritano di essere il protagonista potrebbero ottenere più soldi di quelli che stanno attualmente ricevendo).

Avere un brillante sviluppatore capo che può fare quanto segue, fa miracoli per il processo di sviluppo:.

1. sa come delegare.
2. È sotto controllo.
3. È uno sviluppatore esperto.

È una singola fonte per il resto del team per cercare e chiedere consigli. È anche il mediatore tra la gestione di livello superiore e il team di sviluppo principale. Non conosco nessun team manageriale che ami affrontare il cambiamento (a meno che non siano quelli che lo istigano).

Se sei davvero il più adatto per la posizione, tutti lo saprebbero. Tutti lo saprebbero (ad esempio, la gestione di livello superiore, il tuo compagno di squadra, ecc.). Dichiari che non credi che ruotare la posizione sia utile (se lo credi). Quindi siediti e lascia che facciano la nomina - astenersi dal cadere di nomi o da qualsiasi tipo di auto-promozione in quanto ciò ti farebbe sembrare poco professionale

Ci sono due parti per essere uno sviluppatore principale:

• Leadership tecnica Per la leadership tecnica, ha senso scegliere un altro sviluppatore principale a livello di progetto. Fai diventare uno sviluppatore un lead tecnico per un progetto diverso, ruotando se necessario mentre i progetti ruotano. Questo tipo di approccio può gestire le dinamiche del team e assicurarsi che tutti siano debitamente sfidati

• Comunicazione Un unico punto di contatto per la comunicazione con il mondo esterno è positivo per il mondo esterno e negativo per il punto di contatto. Chi rimane bloccato con la sfera della comunicazione avrà meno tempo per fare un vero lavoro e dovrà correre in giro a ricevere informazioni da tutti per passare. Se sei il miglior comunicatore e sei disposto a smettere di fare tanto del lavoro divertente in cambio di fare tutto il parlare, più potere a te.

Non è necessariamente una cattiva idea, a condizione che gli sviluppatori coinvolti siano impegnati e (idealmente) capaci.

Ho difficoltà a trovare riferimenti per questo (ma continuerò a cercare), ma se ricordo bene alcune aziende agili fanno questo - ruotano il titolo di "lead del team" ogni iterazione o in qualche altro pre -definisce il periodo di tempo. Ciò promuove il coinvolgimento degli sviluppatori e offre a tutti la possibilità di svolgere parte della gestione del team / comunicazione esterna senza spostare permanentemente uno sviluppatore dallo sviluppo in quel ruolo.

Alcuni inconvenienti includono la potenziale perdita di informazioni (questo può essere mitigato in vari modi) e un maggiore potenziale di leadership "cattiva". Potrebbe anche essere difficile mantenere una visione / direzione per la squadra. Tuttavia, se tutti sono d'accordo con questo approccio ei membri del team sono entrambi ben informati e interessati a far funzionare un sistema del genere, può valere la pena provare.

Se si ruota, non farlo durante un progetto. Non c'è nulla di intrinsecamente sbagliato nell'assegnare ruoli diversi a persone diverse per progetti diversi, in base a chi è più appropriato in ogni posizione per quel particolare progetto. Ma non fare di Joe il "programmatore capo" solo perché è il suo tempo sul roster per eseguire il lavoro. Potrebbe non essere abile per questo, potrebbe anche non volere il lavoro.

Ruotare lo sviluppatore principale in base al tempo è una cattiva idea.

Ognuno è un buon sviluppatore non significa che tutti sono dei buoni leader. E uno è un buon leader, non significa che è adatto per il leader di questo programma.

Penso che l'importanza delle missioni assegnate agli sviluppatori sia diversa, e la leadership di ogni sviluppatore è diversa. Penso che tu possa consigliare al tuo manager di tenere un voto. Ognuno vota 2 persone per il miglior candidato, e la persona che ottiene il maggior numero di voti dovrebbe essere lo sviluppatore leader

Sono propenso a concordare con Jonathan Khoo che la rotazione dello sviluppatore principale potrebbe essere una cattiva idea. Generalmente per i progetti più grandi c'è un unico lead tecnico che dirige il progetto e quella persona può avere diversi lead di componenti che segnalano a loro di discutere vari problemi di sistema.

Tuttavia, un punto importante che Jonathan non ha menzionato è che la guida tecnica sviluppa anche un alto grado di conoscenza istituzionale che altri membri del progetto potrebbero non avere. Ruotando il lead tecnico si richiede loro di sviluppare quella conoscenza ogni volta che qualcuno viene ruotato nella posizione. Inoltre, il lead svilupperà un rapporto con i clienti al di fuori del progetto in quanto dovrebbe idealmente essere presente per alcuni degli incontri (più grandi) con gli utenti finali.

Avere un vantaggio tecnico è buono, ma se provi a ruotarli puoi scoprire che stai meglio senza uno.

Penso che prima devi determinare quale sia il ruolo di questa persona, più di chi lo fa e per quanto tempo.

Devi anche determinare se questo cambierà in modo significativo il modo in cui il resto di te lavora e se ridurrà le tue prestazioni. Avere una persona deve "approvare" ogni riga del codice piuttosto che fare un peer che può avere un effetto serio.

Diversi ruoli specifici possono essere assegnati a diversi membri del team, senza che nessuno di voi sia "superiore". Colui che è più in grado di comunicare tra il manager e gli altri può avere un ruolo specifico per farlo, ma ciò non significa che sia uno "sviluppatore principale", e potrebbe non essere la persona che è la migliore tecnicamente o la migliore fare recensioni di codice.

Sarei disposto a scommettere che mentre la squadra è apparentemente piatta, c'è già un leader tra loro, E lo sanno già tutti.

Gli organigrammi riflettono raramente il modo in cui le persone effettivamente lavorano. Classifiche particolarmente idealizzate come "una squadra piatta".

Se la tua organizzazione è piatta, fai in modo che tutti i tuoi sviluppatori passino attraverso la formazione RSA (Requirements and Solutions Analysis) per fare in modo che seguano un processo formale. È quindi possibile assegnare più esperti in materia (PMI) a un progetto e ottenere un processo documentato per tutte le soluzioni.

Inoltre, poiché hai menzionato che il manager non è tecnico, quell'individuo può ancora guidare il processo RSA e facilitare la comunicazione. È inoltre possibile assegnare una particolare PMI come lead su un progetto per progetto per assistere nella facilitazione e costruire i propri skillset individuali.

Perché il team di sviluppo non vota in modo anonimo? Userei il voto preferenziale.

1. Puoi selezionare qualcuno della tua squadra per guidare la tua squadra.
2. Il tuo capo può assumere un'altra persona con esperienza per assumere questa posizione

P.S. Non penso che la rotazione sia una buona idea, la persona deve saper fare comunicazione e avere una buona esperienza nella gestione di una squadra.

Come suggerisce la tua domanda, l'intero team è responsabile per il processo decisionale, ti suggerirei di mantenerlo allo stesso modo. Tuttavia, per comunicare e comunicare alle autorità esterne al team, puoi avere un coordinatore del team selezionato nel team. Le sue responsabilità comprendono tutto ciò che non è tecnico. Per tutti gli aspetti tecnici, il team dovrebbe sedersi e discutere nello stesso modo in cui lo si fa ora. Qualsiasi decisione tu prenderai, verrebbe comunicata al mondo esterno tramite il coordinatore . Questa posizione può essere ruotata facilmente in base al tempo.

L'altro approccio può essere quello di avere uno sviluppatore principale basato sul livello di esperienza > esperienza sullo stesso progetto > esperienza nella stessa azienda. E se necessario, la posizione può essere ruotata di fase in fase. Idealmente, ogni fase di sviluppo ha il proprio insieme di requisiti e risultati, che possono essere pianificati e trattati come un mini progetto. Avere un vantaggio diverso per ogni fase ridurrebbe al minimo quasi tutti gli impatti negativi della rotazione.

Invece di avere uno sviluppatore leader rotante, avere un capo progetto in rotazione, qualcuno che ha più conoscenza e comprensione per portare a termine il progetto x.

Lo sviluppatore principale di solito è una promozione e dovrebbe essere guadagnato.

Ma per aiutare a formare e sviluppare capacità di leadership, ruotare chi è responsabile di diversi progetti e quindi avere una misurazione chiara di quanto bene hanno fatto o meno.

Ci deve essere un caposquadra nello stesso modo in cui c'è un capitano su una nave sufficientemente grande.

Se il gestore non ha o non può riempire quel ruolo, uno degli sviluppatori deve essere nominato per riempirlo.

Penso che prima dovresti realizzare collettivamente quanto sei fortunato ad avere il potere di prendere tutte le decisioni tecniche all'interno del team di sviluppo. Quanti team soffrono del peso di una gerarchia di micromanaging che impone loro i loro capricci tecnici, spesso con risultati incoerenti, incubi di compatibilità e frustrazione degli sviluppatori ...

Tra i vantaggi di un lead di sviluppo che hai menzionato, alcuni di essi (una guida tecnica organizzata ...) dovrebbero già accadere se in realtà ci fosse una persona naturalmente eccezionale in termini di abilità tecniche. Se questo è il caso, non vedo come rendere ufficialmente quella persona uno sviluppatore principale darebbe risultati migliori di quelli che si ottengono ora. Se un membro del team non esiste nella tua squadra, allora non riesco a vedere come dare ufficialmente l'autorità tecnica a qualsiasi persona porti a risultati migliori rispetto alla discussione e alla decisione collettiva.

Vedo molto più valore nello stabilire un leader organizzativo - un coordinatore come lo dice il danese. Non un manager, non un capo ma qualcuno che organizzerebbe il processo decisionale collettivo e fungerà da portavoce della squadra, un'interfaccia all'esterno. Se vai in quel modo, la rotazione può essere una buona idea per evitare problemi sopra citati - differenze salariali, gelosia ...

Prima di tutto, penso che sia necessario separare i ruoli. Non c'è motivo per cui la persona che funge da punto di contatto tra la squadra e il resto della società debba necessariamente essere anche la persona che prende le decisioni tecniche finali.

Considerando che il punto di contatto non deve conferire alcuna autorità, la rotazione di tale responsabilità su un programma fisso non dovrebbe essere necessaria. Direi che la squadra siederà, tutti dicono quanto gli dispiacerebbe fare il lavoro (a qualcuno potrebbe piacere, altri potrebbero essere strongmente contrari a farlo), quindi votare qualcuno per ricoprire il ruolo. Fai capire che possono consegnarlo a qualcun altro ogni volta che si ammalano di farlo.

Per quanto riguarda il lato tecnico. Se tutti hanno le stesse abilità e approssimativamente lo stesso livello di esperienza, allora certo, lascia che ognuno si cimenti nella guida. L'importante è non cambiare assolutamente a metà progetto. Attendi fino all'inizio di un nuovo progetto, quindi scegli il lead che ha la maggiore esperienza in quell'area o a caso.