In che modo aiuti i tuoi colleghi programmatori a crescere?

Come team leader, come puoi aiutare i tuoi programmatori a crescere?

Il motivo per cui lo chiedo è perché ci sono alcuni programmatori che lavorano con me e voglio davvero "metterli in libertà", realizzare il loro massimo potenziale e renderli felici.

Ma non so proprio come fare questo, devo

1. Interagisci con loro frequentemente o dai loro un momento di tranquillità, lasciandoli indisturbati?
2. Chiedere loro di seguire le linee guida per la codifica, come applicare unit test, stili di codifica o lasciare che facciano ciò che ritengono opportuno?
3. Sii indulgente con loro. Ad esempio, non importa se entrano davvero in ufficio per 8 ore o 4 ore o devono applicare alcune "discipline" sul posto di lavoro?

Indovina un po ', ogni posizione ha i suoi punti e persone diverse litigherebbero per cose diverse. Tali confusioni rendono la gestione delle persone indefinitamente più difficile.

Cosa pensi?

È una linea molto sottile che devi camminare.

Alla fine, tutte le decisioni tecniche che prendi sono decisioni con cui non dovrai convivere. Quindi creane il minor numero possibile, lascia che le persone che vivono con loro facciano le proprie scelte. Ma guidali se pensi che stiano percorrendo una brutta strada.

D'altra parte, le scelte di processo sono tue. In quelle decisioni, lascia che il team ti guidi, ma alla fine devi prenderle. Almeno all'inizio.

Leggi le tre fasi di maturità di Roy Osherove di un team di software e vedi se riesci a capire a che punto è attualmente il tuo team. Ciò dovrebbe influire sul modo in cui agisci. Più caotico, più devi mettere in atto i controlli. per esempio. In un team estremamente caotico, è necessario iniziare rivedendo tutto il codice impegnato. Ma mentre lo fai, prenditi il ​​tempo necessario per insegnare loro a rivedere il codice degli altri.

E se riesci a trascinare una squadra dal caos alla mezza età, cambia il tuo comportamento a quel punto, altrimenti non si sposteranno più (quest'ultima per esperienza personale).

Sì, gestire le persone è indefinitamente più difficile della gestione di computer o software, proprio perché ogni persona è diversa e possiamo cambiare anche di giorno in giorno. Quindi non esiste una risposta universale. Credo che devi solo comunicare molto con i tuoi sviluppatori per conoscerli e capire i loro punti di forza / debolezza, il loro atteggiamento verso il lavoro e l'apprendimento, ecc. Puoi così conoscere ognuno di loro, indipendentemente dal fatto che preferisca tanta comunicazione e seminari, o imparare da solo in un angolo tranquillo.

Gli sviluppatori IMHO in circostanze normali hanno un naturale bisogno di imparare (a meno che non siano stati bruciati o sfiniti da una precedente brutta esperienza lavorativa). Quindi tutto ciò che devi fare è capire cosa e come vorrebbero imparare e fornire loro gli strumenti e il tempo per farlo (entro limiti ragionevoli ovviamente).

Ad esempio, nel nostro team, possiamo definire liberamente compiti di apprendimento per noi stessi, purché in qualche modo (direttamente o indirettamente) siano collegati al progetto. Queste attività sono in genere da poche ore a un giorno per sprint (non in ogni sprint però). (Un esempio recente: ho avuto un compito da imparare e sperimentare con Scala accettato, sulla base del fatto che questo - e un approccio funzionale in generale - potrebbero aiutare a semplificare una parte complessa del nostro codice Java.) Questi quindi vengono prioritari e programmati in un Sprint, proprio come i normali compiti. È anche incoraggiato e ci si aspetta che esegua dimostrazioni / lezioni su ciò che abbiamo appreso, per trasferire la conoscenza ad altri membri del team (e potenzialmente anche agli sviluppatori di diversi team).

Chiedere loro di seguire le linee guida per la codifica, come applicare unit test, stili di codifica o lasciare che facciano ciò che ritengono opportuno?

Quando si lavora in gruppo, è necessario seguire lo stesso processo di sviluppo. Naturalmente, quel processo dovrebbe essere la cosa più semplice che potrebbe funzionare, non qualcosa descritto in un manuale di 600 pagine. E il processo dovrebbe essere definito e adattato continuamente alla situazione dal team stesso . Quindi, se il team ha accettato uno standard di codifica e TDD, devono seguirlo.

Sii indulgente con loro. Ad esempio, non importa se entrano davvero in ufficio per 8 ore o 4 ore o devono applicare alcune "discipline" sul posto di lavoro?

Se non conosci uno sviluppatore, è normale seguire più da vicino cosa sta facendo, le sue consegne, il suo ritmo di lavoro ecc. È anche OK rivedere il suo codice (o te stesso o un team esperto e di fiducia membro). Una volta guadagnata la fiducia, può gradualmente ottenere più libertà. Ma quella fiducia deve essere guadagnata per prima. Per quanto riguarda l'orario di lavoro, nella mia esperienza l'orario flessibile è ottimo fino a un limite, vale a dire è bene avere un minimo comune concordato, come ogni giorno tra le 11:00 e le 14:00, quando gli sviluppatori si trovano (di solito) sul posto di lavoro, in modo che può essere affrontato con domande o invitato alle riunioni. Ma a parte questo, non ha senso essere severi.

OK, come piombo, è il tuo lavoro far uscire i progetti. Quindi devi essere quello che impone gli standard, le revisioni del codice, chiede rapporti sui progressi e tutte quelle cose quando gli sviluppatori preferiscono che tu li lasci soli. Queste cose sono solo requisiti di gestione e, fatta eccezione per le revisioni del codice, non aumentano davvero le competenze dei dipendenti.

Tuttavia, vuoi aiutarli a crescere, il che è un grande attributo in un leader.

Le revisioni del codice sono certamente un primo passo, ti aiuteranno a vedere chi ha abilità meno che stellari e ha bisogno di miglioramenti per avere anche prestazioni satsifattive. Aiuteranno gli sviluppatori a vedere altri modi per fare le cose e comprendere parti diverse della base di codice rispetto a quelle su cui hanno lavorato personalmente. A mio avviso, le revisioni del codice vengono eseguite di persona in una sala conferenze con lo sviluppatore e il revisore (che dovrebbe essere un altro sviluppatore quando possibile non sempre il lead, rivedere il codice di altri è anche un'abilità che deve essere sviluppata) e tu come un moderatore. Dovresti tenere nota di ciò che deve essere cambiato per identificare le tendenze. Quello che stai veramente cercando non sono errori o modifiche (il codice di tutti può essere migliorato), ma un consistente fallimento nell'imparare dagli errori. Non dire al vertice aziendale che stai conservando queste note o ti ritroverai costretto a usarle come misurazioni nel processo di revisione delle prestazioni che francamente vanifica lo scopo. Se diversi sviluppatori commettono gli stessi errori, una sessione di allenamento o una voce wiki su come fare X potrebbero essere in ordine.

Passiamo ora al vizio in crescita per arrivare al livello minimo. In primo luogo, devi sapere quali set di abilità hanno gli sviluppatori e quali set di abilità sarebbe utile avere e quali potrebbero essere interessati a conoscere meglio. Devi parlare con loro, rivedere i loro curriculum e capire cosa mentono e non mi piace fare.

Non dare tutti gli incarichi interessanti solo ai più abili. Ciò non aiuta gli altri ad aggiornarsi su nuovi problemi e tecnologie. Non puoi passare dall'essere il ragazzo più giovane a ottenere solo i compiti più piccoli e meno importanti per il ragazzo senior a meno che qualcuno non ne abbia l'occasione e ti assegni un lavoro più difficile. Detto questo, i meno esperti potrebbero aver bisogno di essere assegnati per primi per accoppiare un programma con un senior per ottenere abilità più avanzate. Includere i giovani nelle revisioni del codice li esporrà anche a tecniche più avanzate.

Prima di tutto, dai loro la possibilità di capire da soli il problema. Ma a volte le persone sono bloccate e non sanno da dove cominciare (un'abilità che devi sviluppare anche in nuovi programmatori) o cosa fare per risolvere un problema.

Se dai loro un paio di giorni per cercare qualcosa e non hanno ancora una direzione su come faranno qualcosa, allora potresti dover intervenire con alcuni suggerimenti. Se sei un tecnico, puoi dare loro alcune idee su come risolvere il problema. In caso contrario, un incontro con diverse persone in cui fai brainstorming di idee può aiutare se la persona è bloccata. O chiedere a una persona più esperta di dare alcuni suggerimenti. Quello che non vuoi fare è togliere loro il problema e risolverlo da solo. Ma devi bilanciare il completamento del progetto con l'ego del programmatore e, a volte, devi inviarlo in una direzione specifica. Se ha una cattiva soluzione e deve essere risolto, la cosa peggiore che puoi fare è darla a qualcun altro a meno che tu non abbia intenzione di licenziare il programmatore.

Ho visto cattivi programmatori intrappolati, dove qualcun altro deve risolvere quasi tutto ciò che fanno. Gli altri programmatori si risentono e vogliono solo che la persona esca dalla propria vita. La coccole di un cattivo programmatore porta alla partenza dei bravi programmatori. Devi trovare la linea tra abilità di coddling e devloping. Se dai a qualcuno diverse possibilità e lui o lei non migliora mai, allora liberalo.

Per gli anziani che sono già competenti nelle loro attuali competenze, le cose sono più facili. Di solito devi solo dare loro l'opportunità di fare qualcosa di nuovo e loro saltano dentro e lo imparano. Assicurati solo che le interessanti opportunità si diffondano e non tutti vanno a Joe the Wonder Programmer che può aggiustare qualsiasi cosa. Vuoi finire con dieci Joes non solo uno.

Un altro modo per sviluppare le competenze consiste nell'avere una sessione di allenamento settimanale di 1 ora. Rendi ogni sviluppatore responsabile di un determinato argomento. Ciò li aiuterà a migliorare la comunicazione, a fare ricerche approfondite e offrirà a tutti i benefici della loro ricerca. Alcuni argomenti dovrebbero essere assegnati a persone che non hanno familiarità con l'argomento per costringerli a sviluppare alcune conoscenze in tal senso e alcuni dovrebbero essere assegnati a persone che conosci siano gli esperti locali su quell'argomento. Gli argomenti dovrebbero essere una combinazione di cose di cui le persone hanno bisogno per essere bravi nel prossimo futuro o in questo momento e una certa copertura delle nuove tecnologie imminenti che non si usano in questo momento, ma le persone sono interessate a sapere se potrebbero essere utili. Ma a tutti, incluso il più giovane, deve essere assegnato un argomento.

A seconda di come vengono fatturati i tempi dei tuoi sviluppatori (questo è più difficile in una situazione di fatturazione dei clienti), di solito vale la pena per gli sviluppatori di avere 4-8 ore alla settimana per lavorare su progetti personali. Saranno entusiasti di farlo. Le persone migliori vorranno lavorare lì e impareranno molto che diventeranno utili per il futuro. È difficile per i contatori di bean capire la necessità di questo, ma questa volta verrà ripagato molte volte in termini di soddisfazione dei dipendenti, nuove funzionalità o software che nessuno ha richiesto (o che aiuteranno ad automatizzare parte della fatica) e uno sviluppo più rapido a causa di nuove tecniche apprese. Alcuni sviluppatori useranno questa volta rigorosamente per progetti personali non correlati a ciò che fai (e va bene, continueranno ad acquisire competenze e felici per l'opportunità), ma molti altri lo useranno per risolvere problemi persistenti che, a causa della natura della gestione dei progetti, nessuno ha avuto il tempo di risolvere in anticipo. Quindi potresti ottenere refactoring a beneficio di tutti; alcune persone potrebbero scrivere test per migliorare la copertura dei test per facilitare il refactoring; altri potrebbero esplorare alcune nuove funzionalità che potrebbero rendere il tuo software più utile ai suoi clienti. In generale, se riesci a persuadere i segnalini fagiolo, non c'è modo di perdere concedendo loro questa libertà.

Devi imparare a bilanciare lasciando che le persone abbiano un po 'di sforzo per le loro capacità e mantenendo il progetto sulla buona strada. Meno esperto è lo sviluppatore, più qualcuno deve controllare i progressi, specialmente nelle fasi iniziali, quando è più facile cambiare direzione. Gli inesperti possono avere difficoltà e avere paura di parlare. Queste persone tendono ad andarsene poco prima del lancio e scopri che la loro parte del progetto non è da nessuna parte vicina alla conclusione. Prestare particolare attenzione a controllare i progressi di chiunque abbia cambiato lavoro frequentemente (a meno che non si tratti di un appaltatore poiché è la natura del contratto).

I più esperti possono in genere fidarsi di dirti quando hanno problemi a trovare la soluzione e hanno bisogno dell'assistenza di qualcuno con maggiori conoscenze nell'area o cercheranno quella persona e otterranno il trasferimento delle conoscenze. Quindi non hanno bisogno di essere monitorati da vicino nelle fasi iniziali dell'apprendimento di una nuova serie di competenze per un progetto. Troveranno un modo per consegnare il progetto. Coloro che hanno una comprovata esperienza nella consegna possono di solito essere lasciati soli, tranne per i rapporti di avanzamento minimi (di solito devi riferire anche alla tua direzione e quindi hanno bisogno di alcune informazioni).

1. Offri al tuo team un lavoro stimolante e gli strumenti per risolverli. Anche se vedi il tuo lavoro come banale perché stai solo supportando un sistema legacy, spingi tutti a migliorarlo.
2. Il tuo team dovrebbe sviluppare standard di codifica. Il tuo compito è aiutarli a far rispettare e ad adeguare gli standard.
3. Collabora con il tuo team per sviluppare un sistema di stima. Il tuo compito è di aiutare a coordinare questo sforzo con il team e garantire l'applicazione. Le forze esterne si aspettano il codice di qualità in modo tempestivo e non sempre hanno ragionevoli o forniscono alcuna logica per le loro richieste. Non puoi sfuggire a questo, ma devi gestire entrambe le parti. Una volta che la tua squadra si è guadagnata la reputazione per fare le cose, tutti accetteranno di più le stime del tempo. Devono sapere che li sosterrai se stanno facendo lo sforzo.

Quando dico che il tuo compito è quello di far rispettare, non intendo assumere una sorta di stile di leadership draconiana. Quando un gruppo di individui capaci ha input su come si comporteranno, devono anche accettare le conseguenze per non aver seguito le regole. Qualcuno è in definitiva responsabile e dato che sei quel caposquadra, sei tu.

Interagisci con loro frequentemente o dai loro un momento di tranquillità, lasciandoli indisturbati?

Interagisci con loro frequentemente. Ovviamente non è il punto di infastidirli, ma come loro manager dovresti avere conversazioni regolari con loro su come stanno andando le cose e chiacchiere più generiche. All'incirca una volta ogni poche ore suona la frequenza giusta ma suonala a orecchio.

Chiedere loro di seguire le linee guida per la codifica, come applicare unit test, stili di codifica o lasciare che facciano ciò che ritengono opportuno?

Dovresti aspettarti che funzionino esattamente con gli stessi standard che fai. Se si eseguono test unitari e si seguono le linee guida, dovrebbero farlo. Hanno bisogno di imparare a programmare bene ed è tua responsabilità insegnare loro questo.

Sii indulgente con loro. Ad esempio, non importa se entrano davvero in ufficio per 8 ore o 4 ore o devono applicare alcune "discipline" sul posto di lavoro?

Vorrei essere più preciso all'inizio, ma alleggerirmi quando dimostreranno di poterci fidare. Dare alla gente la fiducia di lavorare 4 ore al giorno fin dall'inizio è chiedere problemi, ma lasciare che un dipendente stimato che lavora regolarmente fino a tardi abbia qualche gioco tra i progetti va bene.

In relazione ai tuoi tre punti:

Interagisci con loro frequentemente o dai loro un momento di tranquillità, lasciandoli indisturbati?

Dirò che dipende davvero dal tipo di persona con cui lavori. Alcuni preferiscono discutere all'orario fisso del caffè (alle 10 circa) e altrimenti lavorare da soli, indisturbati. Con loro (OK, lo ammetto, sono esattamente così), di solito invio e-mail (anche quando sono vicino a me, a 2-3 metri di distanza) in modo che tu possa lasciarle la scelta quando leggono le tue informazioni . E a proposito, non chiedere loro se " hanno ricevuto il tuo promemoria" :-) E, naturalmente, alcuni "hanno bisogno" di più guida, più interazione.

Chiedere loro di seguire le linee guida per la codifica, come applicare unit test, stili di codifica o lasciare che facciano ciò che ritengono opportuno?

Per quanto riguarda le seguenti linee guida, è abbastanza chiaro per me. Se si imposta le linee guida relative allo stile di codifica, sempre-fornire-test-case regola, ecc allora si deve far rispettare loro se tu sei il capo sviluppatore. Per il progetto che stai gestendo, ogni sviluppatore dovrebbe seguire le tue linee guida, senza eccezioni, anche per le " superstar ".

Sii indulgente con loro. Ad esempio, non importa se entrano davvero in ufficio per 8 ore o 4 ore o devono applicare alcune "discipline" sul posto di lavoro?

Se sai già come funzionano le persone e sei fiducioso di non rovinare la tua fiducia, puoi rilassare la disciplina. Ma penso che per questo punto la regola (o nessuna regola) che definisci dovrebbe valere per tutti. L'importante è che non ci dovrebbero essere eccezioni. Al momento sono molto felice di lavorare per un project manager che dice semplicemente "fintanto che fai i tuoi 40 lavori a settimana e il lavoro è fatto, va bene". In questo modo potresti arrivare in ritardo una mattina, lavorare solo 6 ore e i due giorni successivi lavorano per 9 ore. Non importa "finché il lavoro è fatto". Mi piace quella regola.

Direi che la quantità di esperienza (non solo di programmazione, ma anche in ambienti aziendali) dei tuoi sviluppatori è un elemento chiave in quanto tempo passi con loro. Attualmente sto lavorando con alcuni sviluppatori che hanno appena finito la scuola e sto scoprendo che hanno bisogno di maggiori indicazioni su come lavorare con gli altri, non solo nei modi di documentare / testare / standard, ma anche nei modi interpersonali (quando chiamare al telefono o incontrarsi di persona, invece di inviare semplicemente e-mail). Anche la conoscenza della nostra attività è una cosa fondamentale da imparare, poiché molte delle stesse parole sono usate in modo molto diverso nel nostro contesto aziendale rispetto a un contesto di sviluppo software. E questo è prima di arrivare agli acronimi ...

Ma non so proprio come fare questo, devo

1. Interagisci con loro frequentemente o dai loro un momento di tranquillità, lasciandoli indisturbati?
2. Chiedere loro di seguire le linee guida per la codifica, come applicare unit test, stili di codifica o lasciare che facciano ciò che ritengono opportuno?
3. Sii indulgente con loro. Ad esempio, non importa se entrano davvero in ufficio per 8 ore o 4 ore o devono applicare alcune "discipline" sul posto di lavoro?

Il mio suggerimento è di avere alcune conversazioni su quale stile funziona meglio per quella persona e sintonizzarsi nel tempo. Alcune persone potrebbero voler incontrarsi una volta al giorno per rivedere come stanno andando le cose, mentre altre potrebbero ritenere che una volta al trimestre sia eccessivo. Alcune persone potrebbero desiderare una revisione formale delle prestazioni scritta ogni mese e altre potrebbero semplicemente desiderare una chat sulle prestazioni. La chiave è ottenere la relazione con il palcoscenico in cui puoi essere onesto su ciò che funziona e non funziona per qualcuno.

Il rovescio della medaglia a questo sarebbe studiare le filosofie dello sviluppo personale sebbene questa possa essere una strada difficile se qualcuno viene analizzato in modo errato. Se vuoi alcuni esempi di tali filosofie potresti guardare Myers-Briggs, Enneagram e Strengths Finder 2.0 per alcuni esempi.

Chiedete loro come preferirebbero lavorare.
Cosa vorrebbero cambiare e così via.

Non tutto in una volta. Solo ... mentre le cose si presentano.
Rimani naturale. (o sentiranno l'odore della paura)

E poi ... potresti persino imparare cose da loro . Se non pensi che sarebbe mai il caso, (troppa distanza nell'istruzione e nell'esperienza) non preoccuparti davvero di farli crescere, li confonderebbe solo.

(In quel caso speciale, arrenditi e domina con un pugno di ferro , è più onesto del finto interesse che non hai in loro)

Stabilire un processo democratico , votare le cose, discutere questioni.

Come ogni presidente là fuori, mantieni l'ultima parola: il veto .
Il resto dipende dal gruppo.

Un modo per aiutare la tua gente a crescere è far loro fare ciò che fanno meglio.

Se sei fortunato, avrai uno o due programmatori i cui standard di "test" personali sono più severi di quelli del dipartimento nel suo insieme. In tal caso, è possibile inserirli nel "sistema d'onore" per tali problemi o persino adottare i loro metodi.

Con "tempo flessibile", puoi permetterti un margine di manovra più ampio per i tuoi lavoratori più produttivi. Fintanto che stanno svolgendo il lavoro, mi preoccuperò meno delle loro ore. Alcune persone entrano, mettono in 5-6 ore "senza sosta" e ottengono più di altre che impiegano 10 ore a ritmo lento.

Ma uno dei tuoi lavori come manager è quello di correggere i DEBOLI. Cioè, dovrete BEAR DOWn su programmatori sciatti i cui standard di test sono inadeguati o su persone che non sono abbastanza produttive, perché non stanno riducendo i tempi.