Ruotare lo sviluppatore principale è una buona o cattiva idea?

Lavoro in un team che è stato piatto in modo organizzativo da quando è stato creato diversi mesi fa. Il mio manager non è tecnico e questo significa che tutto il nostro team è responsabile del processo decisionale.

Il mio manager sta cominciando a rendersi conto che ci sono molti vantaggi nell'avere uno sviluppatore principale, sia per il suo interesse (un unico punto di contatto e una sola parte responsabile per i compiti) che il nostro (risoluzione delle controversie, assistenza tecnica organizzata, ecc.).

Poiché il team è stato piatto, una preoccupazione è che scegliere uno sviluppatore principale può scoraggiare gli altri. Un non sviluppatore ha suggerito al mio manager che ruotare lo sviluppatore principale è un modo possibile per evitare questo problema. Uno sviluppatore sarebbe in testa un mese, un altro il prossimo e così via.

E 'questa una buona idea? Perché o perché no?

Tieni presente che ciò significa che tutti gli sviluppatori - Tutti gli sviluppatori sono bravi, ma non necessariamente ugualmente adatti alla leadership.

E se è non è , come faccio consiglio evitiamo questo approccio senza sembrare come se fosse solo per motivi egoistici?

Non ruotare.

Non penso che nessuno ottenga nulla dalla posizione che viene ruotata (a parte quelli che non meritano di essere il protagonista potrebbe ottenere più soldi di quelli che stanno attualmente ricevendo).

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

1. Sa delegare.
2. È in controllo.
3. È uno sviluppatore esperto.

È una fonte unica per il resto della squadra a cui rivolgersi e chiedere consigli. È anche il mediatore tra il management di livello superiore e il team di sviluppo principale. Non conosco nessun team manageriale a cui piaccia affrontare il cambiamento (a meno che non siano loro a istigarlo).

Se sei davvero il più adatto per la posizione, lo saprebbero tutti. Tutti lo saprebbero (ad es. Gestione di livello superiore, il tuo compagno di squadra, ecc.). Afferma che non credi che valga la pena ruotare la posizione (se lo credi). Quindi siediti e lascia che facciano gli appuntamenti - astenersi dal far cadere il nome o qualsiasi tipo di auto-promozione in quanto ciò ti renderebbe poco professionale

Ci sono due parti per essere uno sviluppatore principale:

• Leadership tecnica Per la leadership tecnica, ha senso scegliere un diverso sviluppatore principale a livello di progetto. Rendi ogni sviluppatore un lead tecnico per un progetto diverso, ruotando se necessario man mano che i progetti ruotano. Questo tipo di approccio può gestire le dinamiche del team e assicurarsi che tutti siano adeguatamente messi alla prova

• Comunicazione Un singolo punto di contatto per la comunicazione con il mondo esterno fa bene al mondo esterno e fa male al punto di contatto. Chiunque rimanga bloccato con la sfera di comunicazione avrà meno tempo per fare un vero lavoro e dovrà correre in giro per ottenere informazioni da tutti per passare. Se sei il miglior comunicatore e sei disposto a smettere di fare tanto lavoro divertente in cambio di fare tutto il parlare, più potere per te.

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

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

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

Se ruoti, 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 ciascuna posizione per quel particolare progetto. Ma non rendere Joe "programmatore principale" solo perché è il suo momento nel roster per eseguire il lavoro. Potrebbe non essere qualificato per questo, potrebbe anche non voler il lavoro.

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

Ognuno è un buon sviluppatore non significa che tutti siano un buon 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 che la leadership di ogni sviluppatore sia diversa. Penso che puoi consigliare il 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 ruotare lo sviluppatore principale potrebbe essere una cattiva idea. Generalmente per i progetti più grandi esiste un unico capo tecnico a capo del progetto e quella persona può avere diversi componenti che li segnalano per discutere di vari problemi a livello di sistema.

Tuttavia, un punto importante che Jonathan non ha menzionato è che il responsabile tecnico sviluppa anche un alto grado di conoscenza istituzionale che altri sul progetto potrebbero non avere. Ruotando la guida tecnica, si richiede loro di sviluppare tale conoscenza ogni volta che qualcuno viene ruotato nella posizione. Inoltre, il responsabile svilupperà un rapporto con i clienti al di fuori del progetto in quanto dovrebbero idealmente essere presenti per alcune delle (più grandi) riunioni con gli utenti finali.

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

Penso che prima sia necessario determinare qual è 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 lavori il resto di te e se ridurrà le tue prestazioni. Avere una persona deve "approvare" ogni riga del tuo codice piuttosto che qualsiasi 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". A chi è il migliore nel comunicare tra il manager e gli altri può essere assegnato un ruolo specifico per farlo, ma ciò non significa che siano uno "sviluppatore principale" e potrebbero non essere la persona che è tecnicamente migliore o migliore in facendo 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 raramente riflettono il modo in cui le persone lavorano realmente. Grafici particolarmente idealizzati come "una squadra piatta".

Se la tua organizzazione è piatta, fai in modo che tutti i tuoi sviluppatori seguano la formazione sull'analisi dei requisiti e delle soluzioni (RSA) per farli seguire 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 affermato che il gestore non è tecnico, quell'individuo può comunque guidare il processo RSA e facilitare la comunicazione. È inoltre possibile assegnare una determinata PMI come guida su un progetto in base al progetto per facilitare l'agevolazione e sviluppare le proprie competenze individuali.

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

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

PS Non penso che la rotazione sia una buona idea, la persona deve avere abilità nella comunicazione e avere una buona esperienza nella gestione di una squadra.

Come suggerisce la tua domanda, l'intero team è responsabile del processo decisionale, suggerirei che puoi mantenerlo allo stesso modo. Tuttavia, per comunicare e riferire alle autorità esterne al team, è possibile selezionare un coordinatore del team con all'interno del team. Le sue responsabilità includeranno tutto ciò che non è tecnico. Per tutti gli aspetti tecnici, il team dovrebbe sedersi e discutere nello stesso modo in cui lo fai adesso. Qualunque decisione prendiate, 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 in base al livello di esperienza> esperienza nello stesso progetto> esperienza nella stessa azienda. E se necessario, la posizione può essere ruotata da una fase all'altra. Idealmente, ogni fase di sviluppo ha una propria serie di requisiti e risultati, che possono essere pianificati e lavorati come mini progetti. Avere un vantaggio diverso per ogni fase minimizzerebbe quasi tutti gli impatti negativi della rotazione.

Invece di avere uno sviluppatore capo rotante, avere un capo progetto rotante, qualcuno che abbia la maggior conoscenza e comprensione per ottenere x progetto verso il completamento.

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

Ma per aiutare ad addestrare e sviluppare le capacità di leadership, ruota chi è responsabile di diversi progetti e quindi fai una chiara misurazione di quanto bene hanno fatto o meno.

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

Se il manager non può o non può ricoprire quel ruolo, uno degli sviluppatori deve essere nominato per ricoprire questo ruolo.

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

Tra i vantaggi di uno sviluppatore che hai citato, alcuni di essi (guida tecnica organizzata ...) dovrebbero già accadere se in realtà ci fosse una persona naturalmente eccezionale in termini di abilità tecniche. In questo caso, non riesco a vedere come rendere ufficialmente quella persona uno sviluppatore principale darebbe risultati migliori di quelli che ottieni ora. Se un tale membro del team non esiste nel tuo team, non riesco a vedere come dare ufficialmente l'autorità tecnica a una persona porterebbe a risultati migliori della discussione e della decisione collettiva.

Vedo molto più valore nello stabilire un leader organizzativo, come ha affermato un coordinatore danese. Non un manager, non un capo, ma qualcuno che organizzasse il processo decisionale collettivo e fungesse da portavoce del team, un'interfaccia verso l'esterno. Se vai in questo modo, la rotazione può essere una buona idea per evitare i problemi di cui sopra: differenze salariali, gelosia ...

A volte, essere un leader è piuttosto una responsabilità più pesante di qualcos'altro. Qualcuno DEVE assumersi la responsabilità delle scelte, ecco come funziona la società quando nessun altro vuole farlo.

Il fatto che una squadra voglia ruotare il leader può significare che tutti sentono di poter assumersi la responsabilità di ciò che fanno, e non vogliono favorire nessuno, e sembra essere una buona cosa: non ci sono sentimenti duri, e tutti vogliono che la squadra abbia successo.

In quei casi, quando ci sono decisioni difficili da prendere, basta votare per quelle decisioni e quando hai bisogno di un rappresentante per parlare con altre persone, basta eleggere qualcuno che abbia le migliori capacità comunicative.

Prima di tutto, penso che tu debba separare i ruoli. Non vi è alcun motivo per cui la persona che funge da punto di contatto tra il team e il resto dell'azienda debba necessariamente essere anche la persona che prende le decisioni tecniche finali.

Agire come punto di contatto non dovrebbe conferire alcuna autorità, pertanto non dovrebbe essere necessario ruotare tale responsabilità su un programma fisso. Direi che il team si sieda, tutti dicono quanto gli dispiacerebbe fare il lavoro (ad alcune persone potrebbe piacere, ad altri potrebbe essere fortemente contrario a farlo), quindi vota 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 ognuno ha lo stesso set di abilità e all'incirca lo stesso livello di esperienza, allora sicuramente, lascia che tutti provino a fare da guida. L'importante è assolutamente non cambiare a metà progetto. Attendi fino all'inizio di un nuovo progetto, quindi scegli il lead che ha la maggiore esperienza in quell'area o in modo casuale.