Come dovrei gestire una squadra con diversi livelli di abilità?


16

Lavorerò su un progetto software con alcuni miei amici e sono stato nominato responsabile tecnico. Nessuno di questi ragazzi è un cattivo programmatore, ma ho molta più esperienza di loro. Devo essere in grado di distribuire il lavoro tra tutti i membri del team, assicurandomi anche di non calpestarci l'un l'altro; che soddisfano gli standard relativamente elevati di qualità e scalabilità di cui abbiamo bisogno per rendere questo progetto di successo, senza richiedermi di rivedere tutto ciò che commettono.

Come devo mantenere gli standard evitando la microgestione? È sufficiente fare alcuni diagrammi, pianificare alcune revisioni del codice e confidare che sarò in grado di risolvere tutto ciò che potrebbero rompersi, o dovrei seguire il percorso TDD e scrivere test espliciti che il team possa soddisfare?


11
C'è una squadra con gli stessi livelli di abilità?
P.Brian.Mackey,

@ P.Brian.Mackey: intendo abbastanza diverso.
Jon Purdy,

@Jon: Spero davvero che tu sappia in cosa ti stai cacciando. Assicurati di avere un po 'di "maiale" nell'affare fin dall'inizio (!). Ho la vaga sensazione di aver bisogno di qualcuno con molta esperienza lì con te, se, a quanto pare, non riescono nemmeno a scrivere unit-test e (!) Non hanno scoperto come farlo da soli: porta penso che forse stai sopravvalutando le loro capacità. Inutile dire che assumere una competenza superiore a quella del caso non è una buona tecnica di gestione del progetto.
Henrik,

@Henrik: so in cosa mi sto cacciando, ma non ho molta esperienza nella gestione di altri sviluppatori e voglio avere qualche consiglio su come garantire che le cose procedano senza intoppi. Ho piena fiducia nelle loro capacità e penso che le persone stiano leggendo molta più negatività nella mia domanda di quanto non abbia effettivamente posto lì. Ho programmato per poco più della metà della mia vita, quindi ho già commesso molti errori che questi ragazzi con 2-3 anni di esperienza devono ancora affrontare.
Jon Purdy,

È per un'azienda o un progetto secondario?
Marcie,

Risposte:


10

Dovresti rivedere alcuni dei loro codici e lasciarli rivedere a vicenda. Non è che tu voglia diventare la polizia di Check In, ma vuoi fornire un feedback il più spesso possibile. Essere un revisore può rafforzare la loro comprensione. Lascia che anche loro rivedano il tuo codice. Sii il modello.

Nota a margine: non dovrebbero esserci sorprese durante una revisione annuale.


2
+1 per "Sii il modello". Questo è stato il più grande vantaggio che ho visto nelle recensioni del codice: imparare dalla lucidità degli altri. Quello e la cattura del difetto occasionale.
Peter K.,

1
Uno strumento per la revisione del codice pur essendo un "purgatorio" è [ code.google.com/p/gerrit/]
Henrik

9

Soprattutto : comunica le tue aspettative e progetta in quanti più modi possibili. I diagrammi sono buoni per alcuni; interfacce definite funzionano per gli altri; funziona anche la programmazione in coppia; revisioni del codice formale possono anche aiutare alcune persone.

Consiglio anche di utilizzare l'automazione il più possibile:

  • Prendi la squadra ad utilizzare uno strumento come NDepend o ReSharper se siete nel regno .Net. Modifica le regole standard se non ti piacciono.
  • Automatizza i tuoi test tanto quanto pratico.

È difficile discutere con un caso di test fallito o uno strumento di ispezione automatizzato, a condizione che siano impostati correttamente.


3
I programmatori errati probabilmente impostano casi di test errati?
JeffO,

1
Strumenti come Resharper sono def. pulito, ma certamente non sono gratuiti. I test automatizzati richiedono la scrittura di codice che può essere testato, il che potrebbe stabilire un requisito impraticabile se i loro livelli di abilità sono molto lontani.
P.Brian.Mackey,

@Jeff: Non sono cattivi programmatori, abbiamo solo sfondi diversi e ho anni con loro. Presumibilmente io e il ragazzo più esperto scriverei le prove, se ce ne fossero.
Jon Purdy,

@Jeff O: Quindi togliili dalla squadra.
Peter K.,

@ P.Brian.Mackey: non c'erano specifiche di strumenti gratuiti nella domanda. Se il codice non è testabile, eliminali dal team. Prova a mostrare loro come scrivere codice testabile e, se non apportano alcun miglioramento, eliminali dal team.
Peter K.,

5

Se stai davvero lavorando con una grande varietà di livelli di abilità nello stesso progetto, ci saranno alcuni problemi. La domanda è quando le affronti? Scriveranno un codice così cattivo che potresti stare meglio non avere la loro assistenza? Questo creerà tensione personale? Hai intenzione di porre fine alle amicizie? A queste domande nessuno può rispondere tranne te.

Supponendo che tutti rimarranno nella squadra, raccomando di suddividere i compiti in piccoli pezzi (quelli più grandi vanno a ragazzi più abili) e lasciare che gli sviluppatori più abili rifattorino quando hai finito. Assicurati di eseguire il controllo qualità a intervalli regolari e stretti. Questo è abbastanza vicino a ciò che accade nella realtà comunque.


3

Per quanto possibile, stai lontano dalle erbacce. In qualsiasi squadra, se sei il leader, devi salvare una parte della tua larghezza di banda per le crisi e il quadro generale. I diagrammi sono buoni e gli standard di codifica sono sempre sani, ma impostare processi in cui le persone si controllano a vicenda è ancora meglio (test incrociati, revisioni tra pari, programmazione di coppie). Non tutti i membri del team devono essere una star: il team insieme può in genere superare eventuali punti deboli degli individui.

La cosa che consiglierei è di resistere all'impulso, per quanto possibile, di dire alla gente quali errori vedi nella loro codifica, invece, inducili a vederlo da soli. Rimani parte della revisione collaborativa del lavoro di sviluppo, ma assicurati di non contribuire più degli altri membri. Invece, fai lo sforzo extra per incoraggiare le persone a vedere ciò che vedi e dare molte spiegazioni sul perché le cose che vedi contano.

Non preoccuparti troppo della sovrapposizione: al di là di una sensibile interruzione del lavoro, puoi chiedere ai membri del team di effettuare il check-in tra loro e quindi verificare che la comunicazione sia avvenuta. Il team inizierà rapidamente a guardarsi l'un l'altro come un modo per raggiungere il consenso, e questo rende il tuo lavoro circa 20 volte più semplice - quindi tutto ciò che devi fare è essere il pareggio quando le aree principali non sono d'accordo.

Quindi risparmia i tuoi sforzi per guardare la squadra collettivamente. Ogni persona avrà alcuni punti di forza fantastici e alcune affascinanti debolezze. Idealmente, inizierai a dedicare lavoro alle persone che soddisfano i loro punti di forza, dando comunque loro la possibilità di superare le loro debolezze in modi che non disabilitano la produttività del team.

L'ultima stella d'oro della leadership del team è rendere le persone consapevoli delle proprie debolezze in modo tale da essere motivate e sufficientemente informate da iniziare a risolverle.


2

Siediti e discuti sulle tecnologie e sui set di strumenti su cui tutti i membri del team concordano. Alcune persone potrebbero essere più esperte negli strumenti concordati rispetto ad altre nel team, quindi coloro che hanno più esperienza devono essere disposti e gradevoli a condividere l'esperienza e la conoscenza con il resto.

Discutere, concordare, scrivere, modellare e comunicare gli standard (come la convenzione di denominazione, le migliori pratiche di codifica e le strutture di cartelle).

Esegui test continui e regolari e controlli di qualità. Avvisare la persona il prima possibile quando si notano incoerenze.


2

Stavo per dire "chiedi alla persona più esperta del team di organizzarla", ma sembra che tu sia quella persona.

Se puoi, dividi il progetto in due livelli. Il livello applicazione / livello driver è una buona divisione. Forma due sottogruppi all'interno della tua squadra e rendi una persona responsabile per quel livello. Questo può funzionare molto bene.

Rassegnati ad esso. Dovrai rivedere tutto ciò che commettono, in particolare all'inizio. Se tutto sta andando a gonfie vele, ti limiterai a fissare il codice. La revisione non ti richiederà molto tempo e ti darà molta fiducia che le cose stanno andando bene. Più probabilmente scoprirai che qualcuno sta usando i semafori in modo errato o sta scrivendo la propria versione di una funzione di libreria o una tale follia. La mia esperienza è che devi guardare il codice mentre viene scritto per evitare problemi di codice sul nascere.


Concordare la parte di revisione del codice. Devi guidarli il prima possibile.

2

Cosa ci si aspetta normalmente da un lead tecnico nella tua azienda? Sono un manager e sono stato in questo posto un paio di volte e sto per farlo di nuovo a partire da questa settimana (assumendo neofiti e altri per far parte di un team di persone con esperienza di 20 e 4 anni).

Sono un manager e posso essere un capo tecnico (negli ultimi anni ho ricoperto l'ultimo ruolo per far crescere la leadership all'interno del team. In ogni caso, alcuni pensieri:

  • Valuta le competenze e i punti deboli di tutto il team.
  • Crea un piano di crescita - Mentre la tua attenzione sta facendo crescere i membri più deboli, dovresti davvero concentrarti sulla crescita di tutti come individui e come squadra.
  • Comunicare questo piano e impostare le aspettative di tutti.
  • Distribuire l'apprendimento e la convalida in tutto il team. Mentre tu, come capo, possiedo la parte comune del lavoro, distribuire il lavoro aiuterà i membri del tuo team più senior in leader.
  • Crea un ciclo di feedback regolare. Incontra i membri del team per valutare i progressi e fornire feedback.
  • Adeguare il piano, se necessario, per assicurare il successo.
  • Se qualcuno non si sta allenando e, anche con un aiuto ragionevole, non sarà pronto a respingerlo. Questo è complicato, ma se hai impostato un piano, aspettative e fornito un circuito di feedback, sarai in una posizione molto migliore per farlo.
  • Tieni d'occhio il morale della squadra. Questo tipo di situazione può fare grandi cose per far crescere una squadra o distruggerla. Le tue capacità di leadership e gli investimenti nel team faranno molto per stabilire il risultato.

1

Prova a esaminare cosa significa definire un'architettura software. La creazione di moduli separatamente sviluppabili è uno dei motivi principali per la progettazione e l'analisi iniziali. So che fare questo tipo di lavoro è fuori moda, ma funziona in tutti i casi, al contrario di alcuni casi che i nuovi metodi di sviluppo abbracciano.


1

Come sviluppatore più esperto del team, mi aspetterei dal tuo coaching pesante .

Lascia che il team assegni il lavoro a se stesso usando kanban , quindi trascorri l'intera giornata a programmare la coppia con ciascuno di essi.

Quando vedi una cattiva abitudine o qualcosa di cui dovrebbero (tutti) essere consapevoli, ferma tutto e disegna sulla lavagna.

Dopo alcune settimane, sarai in grado di rallentare il coaching pesante man mano che le abilità generali della squadra si avvicineranno alle tue.


1

Ci sono un paio di elenchi diversi che sarei tentato di rivedere dalla tua posizione:

  1. Conosco bene questa squadra. Conosci i punti di forza e di debolezza di tutti i membri del team? Sai come ottenere il meglio da ogni persona? Sai come dividere il lavoro in modo relativamente equo per tutti? Questi tipi di domande sono qualcosa da porre e capire che potrebbero esserci dei cambiamenti in questi elenchi nel tempo poiché alcune persone possono sviluppare alcune abilità che possono cambiare il modo in cui vengono visualizzate. Quando sei stato nominato c'erano delle aspettative che alcuni membri del team avevano di te? Quest'ultima domanda può essere difficile da convincere le persone a rispondere onestamente, ma può aiutare molto se può essere divulgato e discusso in modo significativo senza suscitare offesa o risentimento che può essere abbastanza facile se ciò che viene discusso è molto personale per alcuni persone. Non cercare di ottenere opinioni personali in una riunione di gruppo,

  2. Quanto bene conosco me stesso. Quali elementi del tuo background stai usando per rivendicare qualche autorità tecnica qui? Quali punti di forza e di debolezza porti alla squadra? Dovresti entrare regolarmente nelle trincee? Ci sono pratiche che hai visto che vorresti presentare a questa squadra per aiutarle a guidarle? Ci sono segnali di avvertimento che ricordi dall'esperienza passata che possono essere utili per vedere se qualcuno di questi sta iniziando a comparire nel lavoro svolto dal team.

In un certo senso tutto ciò si riduce alla comunicazione. In bocca al lupo!


0

avere una presentazione (settimanale) periodica di alcuni argomenti tecnici e farli ruotare attorno al gruppo. In questo modo tutti impareranno qualcosa. E lascia che anche i membri più giovani presentino, non c'è modo migliore per capire davvero qualcosa che insegnarlo. Potrebbe essere necessario aiutarli a scegliere gli argomenti.

Alcuni coach su come tenere un discorso possono essere adatti a tutti. Avevo un professore al college che lo ha fatto per me ed è stato molto utile.

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.