Sono un team leader con oltre 5 sviluppatori. Ho uno sviluppatore (chiamiamolo A ) che è un buon programmatore, che scrive un codice pulito, facile da capire. Tuttavia è un po 'difficile da gestire, e a volte mi chiedo se sia davvero poco performante o meno.

1. La nostra azienda richiede agli sviluppatori di indicare l'avanzamento del lavoro nel tracker dei bug che utilizziamo, non tanto per monitorare i programmatori, ma per tenere le parti interessate al corrente dei progressi. Il fatto è che A aggiorna solo l'avanzamento di un'attività quando viene eseguita (forse 3 settimane dopo che è stata elaborata per la prima volta) e questo lascia tutti a chiedersi cosa stia succedendo nel mezzo della settimana di sviluppo. Non cambierebbe abitudine nonostante ripetuti sondaggi. (Va bene, gli sviluppatori odiano le scartoffie, anche io)
2. Negli ultimi 2-3 mesi è in congedo abbastanza spesso a causa di vari eventi - o è malato, o deve partecipare a molti eventi personali ecc. (Va bene, le cose brutte accadono in una stringa. È solo una coincidenza)
3. Definiamo sprint o roadmap per ogni mese. E all'inizio dello sprint, discuteremo della quantità di lavoro che ciascuno degli sviluppatori deve svolgere in uno sprint e gli sviluppatori potranno impostare il tempo necessario per ogni attività . Di solito non sarà in grado di completarli tutti. (Va bene, agli sviluppatori mancano regolarmente scadenze non dovute a colpa loro).
4. Sono di base a Singapore. Non sono sicuro che sia importante. Sì, gli asiatici sono noti per essere reticenti, ma importa?

Se si verificano solo uno o due degli eventi sopra citati, non sentirò che A sia sotto-performante, ma accadono tutti insieme. Quindi ho la sensazione che A sia poco performante e forse-- Dio non voglia --- rallentare.

Questa è solo una sensazione basata sui miei anni di esperienza come programmatore. Ma potrei sbagliarmi.

È notoriamente difficile misurare il lavoro di un programmatore, dato che non tutti e due i compiti sono uguali e manca un obiettivo standard per misurare l'impegno di un programmatore nella propria azienda. È assolutamente impossibile dire se il programmatore sta facendo il suo lavoro o stia rilassando. Tutto quello che puoi fare è fidarti di loro-- sì, fidarsi e dare loro l'autonomia è il modo migliore per far funzionare i programmatori, lo so, quindi non iniziare una lezione sul perché devi fidarti dei tuoi programmatori, grazie molto - ma se abusano della tua fiducia, puoi saperlo?

Risultato:

Ho una chiacchierata diretta con lui sulla mia percezione della sua esibizione. Era indignato quando ho suggerito di avere la sensazione che non si stesse esibendo al suo livello migliore. Sentiva che era una sensazione completamente ingiusta. Ho quindi risposto che questo era il mio sentimento e non sapevo se il mio sentimento fosse giusto o meno. Non avrebbe avuto nulla di tutto ciò e terminò immediatamente la discussione.

Prima di andarsene disse che "avrebbe cercato di dare di più alla compagnia" in tono molto freddo. Sono stato colto di sorpresa dalla sua reazione. Sono sicuro di averlo offeso in qualche modo. Tuttavia, non sono sicuro che sia stata la cosa giusta da fare per me essere così sincero con lui.

La mia domanda è: come puoi sapere se i tuoi programmatori non funzionano bene? Sicuramente ci sono esperienze di team leader che sanno meglio di me su questo? 

Note extra:

1. Odio il micromanaging. Quindi tutto ciò che abbiamo per il nostro processo software è Sprint (in cui le attività sono prioritarie e assegnate e, alla fine del mese, una revisione della quantità di lavoro svolto). Gli sviluppatori dovrebbero aggiornare le attività man mano che vanno avanti tutti i giorni.
2. Non esiste una riunione stand-up o qualcosa del genere. Principalmente perché abbiamo la libertà di lavorare da casa e tutti hanno a cuore questa libertà.
3. Anche se sono io a fissare la scadenza, ma gli sviluppatori forniranno la stima per ciascuna attività e deciderò, in base alla stima, le attività che vanno a un determinato sprint. Se non riescono a finire i compiti alla fine dello sprint, li spingerò al successivo. Quindi teoricamente si possono fare solo 1 o 2 compiti durante l'intero sprint e quindi spingere i rimanenti 99 compiti allo sprint successivo e comunque starà bene finché lo giustifica, sotto forma di aggiornamenti quotidiani sullo stato di avanzamento del lavoro

Questo dovrebbe essere un problema sorprendentemente facile da risolvere.

Incontra un secondo incontro con lui. Digli che accetti che probabilmente è la tua percezione della realtà a essere colpevole. Quindi qualificalo con "tuttavia, se è così, allora dobbiamo lavorare insieme per migliorare la mia percezione". Alla fine sfidalo a risolvere quel problema, quindi non si sente micro-gestito.

Questa cosa esatta mi è successa molto tempo fa. Per me, il problema era che non mi piaceva la possibilità che qualcuno potesse pensare che stavo cercando credito extra per aver semplicemente fatto il mio lavoro. E questo è stato abbastanza giusto, ma ci deve essere un regolare ciclo di feedback tra qualsiasi membro dello staff e il loro manager di linea.

Se non c'è, allora ottieni questi problemi.

Regolari, pianificati, 1: 1 sono un'ottima idea. E, come hanno sottolineato le persone, gli standup non devono essere ortogonali al lavoro da casa. Ma devono coinvolgere le tre domande: cosa hai fatto ieri? Cosa hai intenzione di fare oggi? E quello che la maggior parte della gente dimentica ... Cosa (se mai) ti sta trattenendo?

Detto questo, dovresti cercare di scoraggiare le situazioni in cui i membri del team non lavorano mai insieme. Ho già lavorato in quella situazione e ha seminato sfiducia all'interno della squadra e all'esterno. Ti auguro una giornata normale per venire tutti in ufficio. Avere un incontro regolare in cui le persone possano esprimere alcune idee su come migliorare i processi o altro.

Non renderlo un evento di segnalazione di linea. Rendilo un'opportunità per parlare. Sarai sorpreso di ciò che impari. Se possibile, trasformalo in un evento sociale, scegli un paio di drink sull'orario di lavoro come esercizio di legame.

Ci sono molti ottimi consigli qui, e non voglio togliermene nulla, quindi sto pubblicando questo come risposta separata.

Innanzitutto, è evidente per me (e apparentemente altri) che non hai scoperto la radice del problema . Stai fissando un sintomo e stai cercando di curarlo. Devi scoprire cosa sta causando così tanto attrito tra te e questo sviluppatore. Forse sei troppo autorevole (il mio Product Owner ha recentemente descritto se stessa come "Potere infinito" per un progetto e questo mi è stato offensivo, anche se ha riso quando lo ha detto). Forse ha gravi problemi familiari (spiegherebbe sempre senza lavoro). C'è un problema di root qui, e fino a quando non lo trovi, questo non verrà risolto.

Buona pesca!

Se la sua performance potrebbe essere migliore, è fantastico che tu l'abbia determinato. Ricorda, tuttavia, che se le sue cattive prestazioni sono ancora buone prestazioni al confronto, allora devi camminare con attenzione per evitare di perdere un buon sviluppatore. È difficile trovare buoni sviluppatori e buoni sviluppatori richiedono una serie di cose molto specifiche. Forse dai un'occhiata al Joel Test per vedere se i suoi bisogni sono stati soddisfatti.

Trova la fonte del problema

Se non è soddisfatto di qualcosa legato al lavoro che sta facendo, puoi risolverlo solo determinando l'origine del problema. Sia chiaro, hai detto che il tuo programmatore ha scritto un buon codice. Ciò significa che ama la programmazione. È più che evidente che è frustrato al lavoro (dalla tua descrizione dell'incontro), e probabilmente hai ragione che la sua esibizione è al di sotto di dove dovrebbe essere, ma non dare per scontato . Ricorda che molti programmatori non hanno abilità sociali.

Neanche tu sei perfetto

Ricorda che a volte avrai conflitti di personalità, specialmente con gli introversi . Se questo risulta essere un conflitto di personalità, considera quanto sei disposto ad andare per ottenere un aumento delle prestazioni (vedi 1)

Tutto ciò detto

Ho scritto un post sul blog sulla gestione dei programmatori. Penso che dovresti leggerlo.

http://deltreey.blogspot.com/2012/07/managing-programmers.html

Non posso sottolineare abbastanza l'ultima parte di quel post.

Se i tuoi sviluppatori sono bravi, vogliono programmare.

Il tuo programmatore, anche se si sta rilassando, non vuole essere rilassato. Devi trovare la radice di questo problema, e potrebbe rivelarsi qualcosa che semplicemente non può essere risolto e che deve essere lasciato andare, ma qualunque cosa sia, non puoi prendere una decisione informata senza determinarla.

Quando si sente qualcuno è "un po 'difficile da gestire", come lei descrive, per capire meglio come si fa a eseguire e se ci sono problemi (oggettivi o soggettivi) che influenzano la produttività dei membri del team dev, considerare la creazione di una pratica di regolare 1: 1 di con la vostra membri del team, come presentato in un eccellente articolo The Update, The Vent e The Disaster :

... Non sto suggerendo che ogni 1: 1 è un affare tortuoso per scoprire disastri emergenti profondamente nascosti, ma vuoi creare un luogo settimanale in cui l'insoddisfazione potrebbe apparire in silenzio. A 1: 1 è la tua possibilità di eseguire la manutenzione preventiva settimanale, comprendendo anche la salute della tua squadra.

... Il suono che circonda il regime di successo di 1: 1s è il silenzio. Tutto l'ascolto, l'interrogatorio e la discussione che si verificano durante un 1: 1 è una manutenzione preventiva gestionale. Vedrai quando l'interesse per un progetto inizia a calare e ad agire prima che diventi insoddisfazione del lavoro. Sentirai della tensione tra due dipendenti e modererai una discussione prima che diventi una partita urlante in una riunione. La tua ricompensa per una cultura di sano 1: 1 è una netta mancanza di drammaticità .

_{Un punto molto forte dell'articolo citato è che è autonomo , nel senso che oltre a spiegare i benefici, fornisce anche una serie di raccomandazioni pratiche che consentono sostanzialmente di iniziare a praticare 1: 1 regolari senza scavare in altre fonti (anche se cercando ulteriori informazioni non fanno male, lo sai).}

Ovviamente, c'è un grosso problema di comunicazione qui. Potrebbe benissimo fare un lavoro fantastico, ma se hai la sensazione di non sapere cosa sta facendo, questo da solo è un problema. E se non sai cosa sta facendo, probabilmente neanche i suoi colleghi lo sanno. Ciò può causare problemi quando controlla il suo codice di due settimane. Soprattutto se c'era qualcuno che lavora in un'area simile.

Puoi sempre suggerire che acceda / fornisca gli aggiornamenti più regolarmente per ridurre al minimo questo tipo di conflitti. Questo potrebbe permetterti di presentare la tua richiesta in termini di aiuto alla squadra piuttosto che "Non so cosa stai facendo".

So che gli standup hanno molto odio, ma in realtà non devono essere tenuti nella stessa stanza. Una chiamata veloce o un aggiornamento di Skype di gruppo una volta al giorno è molto rapido e mantiene tutti sulla stessa pagina.

Attualmente sto lavorando dall'India con un team in Irlanda e non riesco a immaginare di non comunicare quotidianamente con ognuno di loro e so all'incirca a cosa si trovano ciascuno o posso scoprirlo molto rapidamente.

Inutile

Gli aggiornamenti di stato giornalieri sono inutili. Fare in modo che le persone segnalino "oggi sono completo al 2,5%", "oggi sono completo al 3,74%" è ridicolo.

Non fornisce alcun valore agli stakeholder e infastidisce le persone che svolgono il lavoro.

Lasciali al loro lavoro, indisturbati.

infondato

Per quali motivi ritieni che lo sviluppatore A sia "sottoperformante"? Se il suo lavoro viene svolto in tempo, dovrebbe essere abbastanza buono.

Dici di odiare il micromanaging, ma quello che hai descritto è esattamente questo.

La nostra azienda richiede agli sviluppatori di indicare l'avanzamento del lavoro nel tracker dei bug che utilizziamo, non tanto per monitorare i programmatori, ma per tenere le parti interessate al corrente dei progressi. ... Gli sviluppatori dovrebbero aggiornare le attività man mano che vanno avanti tutti i giorni.

Questa è una sciocchezza senza senso (vedi sopra). La tua squadra non sta lanciando hamburger, stanno creando soluzioni tecniche. Il progresso non è lineare, né è facilmente misurabile o addirittura stimabile. Anche se lo fosse, tali misurazioni o stime giornaliere non hanno valore.

Pericoloso

Riesaminare la base per la vostra "sensazione" che lo sviluppatore A sia "sottoperformante". Pensi che potrebbe fare di meglio, ma sulla base di quali prove?

Insoddisfatto! = Poco performante

Continuare come descritto e, a un certo punto, lo sviluppatore A deciderà probabilmente di essere sottovalutato, di aver dato abbastanza alla società e di trovare un'altra società. La compressione dell'ultimo 0,01% degli sforzi da parte dei dipendenti è molto meno importante del mantenimento a lungo termine.

Gli sviluppatori potrebbero odiare lo sforzo di documentare ciò che fanno e di aggiornare gli stati, ma questo fa parte dell'essere uno sviluppatore professionista. Suggerirei che potresti provare a fargli notare che i suoi ultimi aggiornamenti del registro dei problemi stanno causando una percezione negativa non necessaria del suo lavoro. Se non vede che la sua incapacità di comunicare è un problema di prestazioni - beh, sei il suo capo squadra; digli che lo è.

Per quanto riguarda la stima, questo è un problema classico. Consiglio di leggere "Software Estimation - Demystifying the black art" di Steve McConnell. In questo caso, dai l'impressione che la maggior parte dei tuoi sviluppatori sottovaluti. Questo è, curiosamente, normale e raramente affrontato. Suggerirei che hai un problema con il processo di stima stesso, piuttosto che con questo individuo.

Prova a 'chiudere il ciclo' di stima-misura-revisione e migliorare. Quindi, se i tuoi sviluppatori arrivano puntuali più regolarmente e questo non lo è, puoi considerare cosa fare con lui.

Infine, fai una riunione in piedi. Anche se è tramite Instant Message. Tutto quello che vuoi è che tutti sappiano "cosa ho fatto, cosa faccio oggi, qualsiasi problema". E se ci sono problemi, portali offline per la discussione in seguito. Questo è quello che ho fatto prima ed è stato un successo per quella squadra.

Prima cosa, perché i tuoi sprint sono così lunghi? Gli sprint non dovrebbero mai superare le due settimane. Penso che la maggior parte del tuo problema sia lì. Ti consiglierei di abbreviare il tempo di sprint su una base di prova e di analizzare nuovamente la tua domanda.

Che dire del check-in del codice? Controlla sempre il suo codice? Personalmente penso che i programmatori non siano davvero dei dirigenti e più si tenta di gestire, più saranno frustrati. In realtà, odio svolgere quelle attività di aggiornamento e probabilmente è per questo che PM e Lead sono lì per questo. Allo stesso tempo, conferisco uno status durante le riunioni di mischia o ogni volta che ci incontriamo. Ora quando assegni un'attività, si impegnano in una sequenza temporale o sei tu che assegni loro la sequenza temporale?

Pertanto, l'unico modo per capire se qualcuno è in difficoltà è mappare la sequenza temporale impegnata al% del lavoro svolto. Ora, naturalmente, se qualcuno dice che ci vorranno due giorni per scrivere un metodo che sommi due numeri, sai che c'è un problema, quindi la sequenza temporale dovrebbe essere qualcosa di realistico e concordato da entrambe le parti.

Prendi in questo modo- Se riesci a scrivere un pezzo di codice in un'ora, dagli un'ora + un po 'di buffer. Se te lo sta offrendo in quel lasso di tempo, penso che voi ragazzi stiate andando bene. Se non lo è, allora interrogalo e poi spetta a te decidere se sta fornendo una spiegazione ragionevole o meno.

Una cosa che puoi fare è integrare qualcosa come XPlanner con lo strumento di versioning.

Non penso che la professione di programmazione sia intrinsecamente diversa dalle altre professioni quando si tratta di identificare qualcuno che si sta rilassando. Potrebbe essere necessario andare con il tuo intestino.

Personalmente penso che sia strano che A si rifiuti di fornire aggiornamenti per settimane alla volta. Sono un programmatore che lavora da casa e c'è un contratto implicito tra me e il mio datore di lavoro che devo fornire aggiornamenti quotidiani sui miei progressi. Non si tratta di aggiornamenti "ufficiali", è solo una breve e-mail o un messaggio istantaneo che gli fa sapere cosa sta succedendo con il software che sto pagando per creare. L'aggiornamento richiede meno di un minuto o due per la scrittura e offre la chiusura a entrambi. Per le correzioni di bug, contrassegno il ticket come risolto nel nostro bug tracker entro la fine della giornata. Queste non sono procedure difficili per me, anche se mi piace un ambiente di lavoro rilassato con pochissime scartoffie.

Anche gli aggiornamenti casuali sarebbero apprezzati da lui, ne sono sicuro. Sembri molto, molto indulgente nel tuo post. Se sospetti che stia rallentando per un lungo periodo di tempo, non hai bisogno di un'altra scusa per affrontarlo.

Standup giornalieri anche se su Skype o in una chat room sono il modo per aggirare questo, ma non se lo trattate come un aggiornamento per le parti interessate. Quando una volta al giorno l'intero team fa il check-in per dire a cosa stanno lavorando, in quali sfide stanno affrontando e in che cosa intendono fare successivamente, ottieni diverse vittorie:

• Che tu stia perdendo tempo per ragioni buone o cattive, che qualcosa che impiega troppo tempo sarà più trasparente, incoraggiando i tuoi sviluppatori a chiedere aiuto quando ne hanno bisogno e non esagerare nella ricerca che probabilmente non ha bisogno di accadere o risolvere un problema per la sfida quando l'input da parte del resto della squadra li avrebbe aiutati a eliminarlo molto più velocemente.

• Come manager puoi vedere dove le persone incontrano blocchi stradali più frequentemente, il che ti aiuta a stimare meglio e possibilmente a risolvere problemi fondamentali che stanno sprecando tempo / denaro.

• IMO, aiuta davvero il team a imparare a sottostimare meglio le stime quando possono vedere quanto tempo impiega normalmente a fare anche cose relativamente semplici a volte.

• Ti verrà spesso ricordato ciò che deve essere comunicato in termini di ridefinizione delle priorità quando i membri del tuo team ti dicono cosa intendono fare dopo.

Quindi dimentica "% di completo". Basta rendere il processo per rendere tutti onesti con se stessi tanto quanto con tutti gli altri, fare stime migliori / più affidabili man mano che acquisiscono più esperienza e dare alle persone un po 'più motivazione per fare progressi senza riportare in mente -esercizio inutile di mettere un numero su qualcosa che davvero non puoi.

Sembra che il vertice capisca che le scadenze non vengono sempre rispettate. Fare standup giornalieri ti darà più munizioni su quel fronte perché avrai idee molto più specifiche sul perché non vengono colpiti.

E non farli prima cosa. Sempre un errore IMO. Le persone hanno bisogno di tempo per affondare nuovamente i denti nel problema prima di poter riferire in modo più affidabile su tutti i problemi, IMO.

Standup rapidi che riguardano più la comunicazione che la responsabilità e semplicemente la fissazione di obiettivi, più di ogni altra cosa sono ciò che rende agile il lavoro secondo me. Il resto che ho potuto prendere o lasciare, in particolare Scrum, che ho visto come olio di serpente esecutivo / delle parti interessate.

Poco efficiente?

L'intensità diminuisce e scorre durante la carriera di una persona. Se vale più di quanto costa, allora parla con lui e cerca di semplificare il suo lavoro. Oppure inizia a cercare un sostituto.

Comunicazione

Non fare affidamento su riunioni settimanali. Molte persone non hanno intenzione di fare un braindump completo. Pianifica più 1: 1s. Chiedi loro come stanno andando le cose, cosa puoi fare meglio e cosa pensi che possano fare meglio. A volte, non ci sarà nulla di cui parlare, ma va bene. Avendo più 1: 1, aumenti la probabilità che si ricordino di menzionare qualcosa.

Avere un mezzo di comunicazione più persistente

Puoi ottenere più informazioni dalle persone se non le fai sembrare un lavoretto in più. Se sono tutti remoti, utilizza un programma di chat con funzionalità di registrazione come Hipchat o IRC. Avere un mezzo di comunicazione più persistente incoraggia le persone a parlare di più. Dai l'esempio e parla spesso, per incoraggiare gli altri a fare lo stesso. Almeno una volta al giorno, chiedi alle persone dove si trovano con i loro progetti. A volte, semplicemente guardando la chat, puoi avere un'idea di come stanno andando le cose.

Controllo della fonte

Chiedi a tutti di controllare quotidianamente il proprio codice. Se stai usando git, falli spingere nella propria filiale nel repository dell'azienda. Osservando i commit, puoi dire come stanno.

Separare i mezzi dalle estremità

Le parti interessate vogliono essere aggiornate? Gestisci tu stesso le parti interessate. Parte del tuo lavoro come manager è quello di essere l'ombrello di merda, in modo che i tuoi programmatori possano concentrarsi sul loro lavoro. Dai un'occhiata ai registri e ai commit della chat, quindi scrivi un riepilogo di come stanno andando le cose.

Questi sono i miei suggerimenti:

1. Innovazione: immaginazione e creatività utilizzate per ridurre i costi e migliorare la situazione attuale.

2. Corporation: disponibilità ad aiutare gli altri a raggiungere i propri obiettivi

3. Iniziativa: tentare lavori e attività non di routine.

4. Frequenza: assenze o ritardo, al di sotto degli standard.

5. Avviso: capacità di comprendere rapidamente nuove informazioni e situazioni

6. Precisione e qualità: revisioni del codice, consegna puntuale, tasso di emissione).