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

Soprattutto : comunica le tue aspettative e progetta in tanti modi diversi possibili. I diagrammi sono buoni per alcuni; le interfacce definite funzionano per gli altri; la programmazione della coppia funziona anche; le recensioni formali del codice possono anche aiutare alcune persone.

I anche consiglia di utilizzare l'automazione il più possibile:

• Fai in modo che il team utilizzi uno strumento come NDepend o Resharper se sei nel dominio .Net. Modifica le regole standard se non ti piacciono.
• Automatizza i tuoi test per quanto possibile.

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

Se stai veramente lavorando con una grande varietà di livelli di abilità nello stesso progetto, ci saranno dei problemi. La domanda è quando ti occupi di loro? Stanno andando a scrivere un codice così brutto che potrebbe essere meglio non avere la loro assistenza? Questo creerà tensione personale? Hai intenzione di porre fine alle amicizie? A queste domande nessuno può rispondere se non tu.

Supponendo che tutti rimarranno nel team, raccomando di suddividere i compiti in piccoli blocchi (quelli più grandi vanno a quelli più esperti) e lasciare che il più esperto riparatore di sviluppatori quando hai finito. Assicurati di eseguire il controllo di qualità a intervalli regolari e stretti. Questo è abbastanza vicino a quello che succede nella realtà comunque.

Per quanto possibile, stai fuori dalle erbacce. In qualsiasi squadra, se sei il leader, è necessario salvare un certo pezzo della larghezza di banda per le crisi e il quadro generale. I diagrammi sono buoni e gli standard di codifica sono sempre equilibrati, 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 protagonisti: il team di solito riesce a superare qualsiasi debolezza individuale.

La cosa che consiglierei è di resistere all'impulso, per quanto possibile, di dire alla gente quali errori vedi nella loro codifica - invece, portarli a vederlo da soli. Resta una parte della revisione collaborativa del lavoro di sviluppo, ma assicurati di non contribuire più degli altri membri. Piuttosto, metti lo sforzo in più 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: oltre a una ragionevole interruzione del lavoro, puoi chiedere ai membri del team di controllare tra di loro, e quindi solo 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 quello che devi fare è essere il tie breaker quando le aree principali non sono d'accordo.

Quindi salva i tuoi sforzi per guardare collettivamente al team. Ogni persona avrà alcuni punti di forza eccezionali e alcune affascinanti debolezze. Idealmente, inizierai a lanciare il lavoro a persone che si adattano ai loro punti di forza mentre continui a dare 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 sta rendendo le persone consapevoli delle loro debolezze in modo tale da essere motivate e sufficientemente informate da iniziare a risolverle.

Siediti e discuti sulle tecnologie e i set di strumenti in cui tutti i membri del team sono d'accordo. Alcune persone possono avere maggiore esperienza negli strumenti concordati rispetto ad altri membri del team, quindi coloro che sono più esperti devono essere disposti e graditi a condividere l'esperienza e le conoscenze con il resto.

Discutere, Accettare, Annotare, Modellare e comunicare gli standard (come convenzione di denominazione, best practice di codifica e strutture di cartelle).

Effettua test continui e regolari e controllo di qualità. Notifica la persona APPENA POSSIBILE quando vedi incongruenze.

Stavo per dire 'prendi la persona più esperta nel team per organizzarlo', ma sembra che tu sia quella persona.

Se puoi, dividi il progetto in due livelli. Livello di applicazione / livello di driver è una buona divisione. Crea due sottogruppi all'interno del tuo team e rendi una persona in ciascun responsabile di quel livello. Può funzionare molto bene.

Rassegnati ad esso. Dovrai rivedere tutto ciò che commettono, soprattutto all'inizio. Se tutto andrà a gonfie vele, farai solo il codice a occhio. La revisione non ti ci vorrà molto tempo e ti darà molta fiducia che le cose stanno andando bene. Più probabilmente scoprirai che qualcuno sta utilizzando 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 osservare il codice mentre viene scritto per stroncare i problemi del codice sul nascere.

Cosa ci si aspetta normalmente da un capo tecnico nella tua azienda? Sono un manager e sono stato in questo posto un paio di volte e sto per rifarlo a partire da questa settimana (assumere neofiti e altri per unirmi a un team di persone con esperienza ventennale e quadriennale).

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

• Valuta le capacità e i punti deboli dell'intero team.
• Crea un piano di crescita - Mentre la tua attenzione è rivolta ai membri più deboli, dovresti concentrarti sulla crescita di tutti come individui e come squadra.
• Comunicare questo piano e impostare le aspettative di tutti.
• Distribuisci l'apprendimento e la convalida attraverso il team. Mentre tu, in qualità di protagonista, il mio lavoro in comune, il distribuire il lavoro aiuterà i tuoi membri più anziani a diventare 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 sta lavorando e non lo farà, anche con un aiuto ragionevole, sii pronto a farli uscire. Questo è complicato, ma se hai impostato un piano, le aspettative e fornisci un ciclo 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 impostare il risultato.

Prova a cercare in cosa consiste la definizione di una "architettura software". La creazione di moduli sviluppabili separatamente è uno dei motivi principali per fare progettazione e analisi anticipate. So che fare questo tipo di lavoro è fuori moda, ma funziona in tutti i casi, al contrario di solo alcuni casi che i nuovi metodi di sviluppo sposano.

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

Lascia che il team assegni il lavoro a se stesso usando kanban , e poi trascorri l'intera giornata a fare accoppia la programmazione con ciascuno di essi.

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

Dopo alcune settimane, sarai in grado di rallentare il tuo coaching pesante in quanto le abilità generali del team si avvicineranno alle tue.

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

1. Quanto conosco questa squadra. Conoscete i punti di forza e di debolezza di tutti nel team? Sai come ottenere il meglio da ogni persona? Sai come dividere il lavoro in modo relativamente equo per tutti? Questo tipo di domande è qualcosa da chiedere e capire che potrebbero esserci cambiamenti in questi elenchi nel tempo, dal momento che alcune persone potrebbero sviluppare alcune abilità che potrebbero 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 la gente a rispondere onestamente, ma può aiutare molto se ciò può essere divulgato e discusso in modo significativo senza suscitare offesa o risentimento che può essere piuttosto facile se ciò che viene discusso è molto personale per alcuni persone. Non cercare di ottenere opinioni personali in una riunione di gruppo, ma ottenerlo in privato in una riunione, poiché non c'è niente di peggio che cercare di convincere qualcuno ad ammettere qualcosa di piuttosto personale di fronte ai compagni di squadra che desiderano non essere pubblici.

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? Ti aspetti di entrare regolarmente nelle trincee? Ci sono delle pratiche che hai visto che vorresti presentare a questa squadra per aiutarle a guidarle? Ci sono segnali di avvertimento che ricordi dalle esperienze passate che potrebbero essere utili per vedere se qualcuno di questi sta iniziando a comparire nel lavoro che sta facendo il team.

In un certo senso tutto si riduce alla comunicazione. Buona fortuna!

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

Qualche coach su come tenere un discorso potrebbe essere in ordine per tutti. Ho avuto un professore universitario che lo ha fatto per me ed è stato molto utile.