Alla fine, l'unica risposta corretta a qualsiasi domanda sulla gestione di un membro del team problematico è "Comprendi le sue motivazioni, reagisci di conseguenza".

Non possiamo davvero dirti quali sono le sue motivazioni. Posso azzardare un'ipotesi, perché sono stato accusato della maggior parte delle cose che descrivi, ma questo non significa che siamo persone simili. Sarebbe solo il mio proiettare le mie frustrazioni sul posto di lavoro sul membro del tuo team, il che potrebbe essere giusto, ma allo stesso modo potrebbe non esserlo.

L'unico modo per capire veramente la motivazione di una persona è ascoltarla. Molto.

Portali fuori dall'ufficio, in un luogo confortevole e fai alcune gentili domande approfondite. E una volta che inizia a parlare, ascolta. Rands in Repose ci ha spiegato come farlo in un eccellente articolo intitolato The Update, The Vent and The Disaster.

Stessa ora ogni settimana. Quando diventi un manager di persone, accade una cosa strana. Vieni automaticamente percepito come più impegnato. Che tu lo sia o meno è irrilevante; le persone pensano che tu sia. Portare costantemente il tuo 1: 1 alla stessa ora nello stesso giorno è un promemoria settimanale che sei qui per loro, non importa quanto occupato.

Fallo sempre. Ok, quindi sei davvero impegnato. Stai correndo da una riunione all'altra. È facile togliere la priorità a un 1: 1 perché, a differenza di qualsiasi incontro a cui stai partecipando, un 1: 1 non rappresenta un problema urgente che deve essere risolto. Più avanti in questo articolo sconfiggerò questa percepita mancanza di opinione di valore, ma per ora capisco che ogni volta che esegui la cauzione su un 1: 1 sentono: "Non importa".

30 minuti, almeno. Un'altra mossa preferita del manager impegnato è programmare un 1: 1 per 15 minuti o meno. È il meglio che posso fare, Rands. Ho 15 persone che lavorano per me. Primo, quelle 15 persone non lavorano per te; lavori per loro. Pensala in questo modo: se quelle 15 persone se ne andassero, uscissero dall'edificio domani, quanto lavoro verrebbe effettivamente fatto? Secondo, se hai 15 persone che lavorano per te, non sei il loro manager, sei solo il ragazzo che sorride a disagio mentre passi di rado in ufficio, chiede come va e poi non ascolta davvero la risposta.

L'unica cosa di cui sono quasi sicuro è che la persona con cui stai parlando non è maliziosa. La maggior parte delle persone non lo è. (Se è uno dei pochi, assicurati di questo e poi licenziatelo.)

Quando le persone reagiscono emotivamente in situazioni inappropriate, di solito è perché nessuno offre loro una situazione appropriata in cui sfogare le proprie frustrazioni. Quindi, dagli questo, penso che sarai sorpreso di quanto sia facile risolvere questo problema.

Ti dirà quello che vuole, se crede che tu stia ascoltando e che stai il suo fianco. Se non puoi darglielo, diglielo (e digli perché, così capisce), direttamente e incoraggialo a pensare a un'alternativa.

EDIT: un ultimo pensiero, che potrebbe essere ovvio, ma vale comunque la pena affermarlo.

Non farlo solo per la persona che ti causa problemi. Per prima cosa non dovresti individuarlo. In secondo luogo, non dovresti incoraggiare un comportamento scorretto facendogli pensare che ora si è guadagnato uno status speciale.

Ma peggio, potresti anche scoprire che altre persone stanno ribollendo silenziosamente degli stessi problemi. Se li lasci ribollire, alla fine potrebbero esplodere, in un modo molto più distruttivo dell'individuo che lascia uscire le sue frustrazioni in ogni occasione, anche quando non dovrebbe.

A differenza di pdr, non ho paura di proiettare :). Leggendo tra le righe, vedo qualcuno che sa di essere stato assunto per le sue forti capacità di programmazione messo in un ambiente in cui non si hanno gli strumenti di base che la maggior parte di noi dà per scontati. Ad esempio, la maggior parte dei sistemi di controllo delle versioni può essere integrata con sistemi di ticketing, spesso gratuiti. Ad esempio, utilizziamo SubVersion e l'abbiamo integrato con Trac. Quindi, se non hai un sistema di ticketing, probabilmente non hai il controllo della versione. E se non hai il controllo della versione, ciò implica che ci sono molti problemi con il tuo codice e l'ambiente che potrebbe dover affrontare.

Questo ragazzo potrebbe trovarsi in una situazione in cui sente la pressione di eseguire come programmatore, ma si trova in un ambiente in cui ciò è molto difficile. Quindi potrebbe pensare che anche se trascorre il 110% della sua giornata a svolgere le attività di programmazione per cui lo hai assunto, non può soddisfare le tue aspettative a causa dell'ambiente in cui lo hai inserito. Sono stato in questa situazione, e porta ai sintomi che hai descritto - tagliare le persone che ritieni stiano facendo un punto che hanno già fatto in modo da poter ottenere una risposta e tornare al lavoro, mettendoti sulla difensiva in modo che le persone si rendano conto che ti trovi in ​​una situazione difficile e dici spesso "no" in modo da poter finire quello che hai nel piatto prima di iniziare ad accumulare altri compiti.

Dal suo punto di vista, potrebbe ritenere che i compiti di programmazione siano quelli che solo lui può fare, mentre i compiti di comunicazione possono essere scaricati su qualcuno che può dedicarci tranquillamente attenzione senza influenzare le critiche (per lui ) attività in cui è impegnato. Questo è un modo molto "programmatore" di guardare le cose: le attività vengono svolte in parallelo, ciascuna dalla risorsa più attrezzata per gestirla.

Potresti esaminare esattamente quanta pressione è sottoposto a questo ragazzo e capire se c'è un modo per te come suo manager per alleviarlo. Tieni presente che alcune di queste pressioni potrebbero essere interne a lui: potrebbe aver fissato obiettivi per se stesso di cui non sei a conoscenza e la sua spinta a raggiungerli potrebbe ignorare le tue aspettative su di lui per comunicare di più. Se la pressione è esterna, potrebbe essere necessario acquistargli un po 'di spazio in modo che si senta a suo agio dedicando tempo a cose che potrebbe percepire come sminuenti la sua capacità di rispettare scadenze (forse irragionevoli). Se la pressione è interna, potresti dover parlare con lui in modo che si conceda il permesso di dedicare tempo alle attività che tu apprezzi.

Nella nostra organizzazione non abbiamo il lusso di strumenti. Principalmente dobbiamo dipendere dai fogli Excel. Ho provato a semplificare il processo creando tracker di Excel che hanno ancora una certa quantità di intervento manuale che richiede come aggiornare Excel entro la fine della data e pubblicare in tutto il team, ecc.

Gli strumenti non lo sono una lussuria." Almeno non gli strumenti menzionati finora (bug tracker e controllo della versione). Questi sono metodi estremamente semplici per gli sviluppatori per più efficacemente produrre codice di buona qualità e per concentrarsi sulla creazione di valore per il cliente.

Il tempo impiegato per creare un tracker personalizzato in Excel sarebbe molto meglio speso per installare e configurare un tracker gratuito esistente. Anche il miglior programmatore VBA al mondo avrebbe bisogno letteralmente di migliaia di ore di lavoro per implementare le funzionalità di base di qualsiasi importante bug tracker. Usare un bug tracker significa che tutti possono aggiornare le informazioni contemporaneamente senza collisioni (un problema fondamentale con qualsiasi documento singolo condiviso), il che significa già meno tempo speso per ogni aggiornamento per verificare se qualcun altro sta modificando , blocca il documento in qualche modo, quindi sbloccalo alla fine.

Il controllo della versione è un altro strumento estremamente importante per gli sviluppatori. Se questo non è disponibile, semplicemente non sorprenderti se non puoi assumere buoni sviluppatori.

Fornire tali strumenti sarà vantaggioso anche per te: la maggior parte dei sistemi di controllo delle versioni e di tracciamento dei bug sono eccellenti in automaticamente creando aggiornamenti di stato. Ad esempio, sia in Git che in Bugzilla, ottenere un elenco delle modifiche negli ultimi giorni è banale e spesso puoi modificare la quantità di dettagli contenuti in questi rapporti. Ciò non richiede alcun lavoro aggiuntivo da parte degli sviluppatori, tranne una conoscenza di base di come funzionano questi strumenti.

È importante tenere presente che molto probabilmente è a conoscenza di quanto sopra. Come hai detto, ha "forti capacità di programmazione" - questo significa in particolare che è in grado di rilevare le attività di routine e sente che queste possono essere rese più facili. Ciò significa anche che è in grado di cercare e scoprire strumenti efficienti per lavori particolari (altrimenti, non si potrebbero qualificare le sue capacità come "forti").

Per questo motivo, sarebbe è più sicuro per te presumere che sia a conoscenza di un'ampia varietà di strumenti di gestione dei progetti economici, ricchi di funzionalità ed efficienti - anche una rapida ricerca sul web rivela un elenco di esempio di tali strumenti nella rispettiva pagina di Wikipedia, insieme a molti altre risorse.

Tenendo conto di una probabile consapevolezza sopra descritta, sarebbe inaccurato presumere che percepisca la mancanza di strumenti come una questione di semplice inconveniente, è davvero più pericoloso di questo.

Dal punto di vista di un dipendente consapevole degli strumenti , una tale mancanza potrebbe indicare o un'incapacità piuttosto profonda di risolvere un semplice problema di gestione ( "hey why don ' Basta controllare l'elenco su Wikipedia e scegliere lo strumento appropriato conveniente, è così semplice ") o altrettanto profondo senso di negligenza nei confronti del loro ha bisogno ( "non essere disposto a fare una cosa così semplice mostra quanto io sia poco importante ai tuoi occhi, è così semplice" ).

Nota come una di queste percezioni vada contro le prime due dei famosi principi di Packard:

1. Pensa prima agli altri compagni. Questo è IL fondamento, il primo requisito - per andare d'accordo con gli altri. Ed è l'unico risultato veramente difficile che devi ottenere. Ottenendo questo, il resto sarà "un gioco da ragazzi".

2. Rafforza il senso di importanza dell'altra persona. Quando facciamo sembrare l'altra persona meno importante, frustriamo uno dei suoi impulsi più profondi. Permettigli di provare uguaglianza o superiorità e possiamo facilmente andare d'accordo con lui ...

Questo essenzialmente distrugge la sua fiducia nelle tue capacità manageriali che a loro volta rende davvero difficile collaborare su qualsiasi questione.

Per quanto riguarda il trattare direttamente con il dipendente, puoi provare a organizzare riunioni regolari 1: 1 con tutti gli sviluppatori per comprendere le sfide e le frustrazioni prima che si sfogino nel più grande gruppo disponibile Questa persona può essere verbosa e conflittuale, ma le preoccupazioni dietro potrebbero essere condivise da altri nel gruppo (o al contrario, possono essere considerate non importanti). Come sottolineato dopo il salto, è difficile stabilire 1: 1 utili, ma può disinnescare il conflitto prima che si diffonda.

Lavoro sempre con persone come queste. Quello che devi fare è che ci sia un vantaggio per lui di fare quello che vuoi. È troppo grande perché l'unico vantaggio sia quello di mantenere il proprio lavoro.

Quindi, a questa persona non piacciono le riunioni. Non ti piace quello che fa alle riunioni. Vuoi che invii e-mail e aggiorni gli elementi di lavoro o rintracci gli elementi o gli elenchi di stato o altro. Questo può essere completamente risolto.

1. Rendi il processo il più leggero possibile. Ad esempio uno strumento di tracciamento del lavoro integrato con lo strumento di programmazione in modo da selezionare semplicemente qualcosa da un menu a discesa quando si archivia una modifica e lo stato dell'elemento viene aggiornato per te (Visual Studio Express lo fa in coppia con TFS ospitato, che è gratis per 5 sviluppatori o meno. I grandi strumenti non devono costare decine di migliaia di dollari)

2. Dagli quello che vuole in cambio di quello che vuoi. "Se mi ricevi quell'e-mail di stato entro le 9:00, avrò il tempo di esaminarla e chiederti qualsiasi cosa prima della riunione, e tu non devi venire alla riunione." "Se mi mandi un'e-mail sullo stato del modulo di punti, lo trasformerò in frasi e lo invierò a tutti gli stakeholder." "Se dedichi 15 minuti a un incontro individuale, possiamo aggiornare insieme il documento di stato e io scriverò a macchina"

Portagli vantaggio, lascia che il suo il lavoro assomiglia di più a quello che lui vuole che sia, e il tuo valore è chiaro. Molti sviluppatori vedono i PM e i lead di progetto come scudi per mantenere la gestione e gli utenti lontani da loro in modo che possano programmare. Se sei disposto a essere uno scudo per lui, ti aiuterà con ciò di cui hai bisogno per farlo.

Mi sono seduto con sviluppatori e persone di supporto e li ho aiutati a inserire e aggiornare "ticket" ed elementi in vari tracker. Dopo averlo attraversato alcune volte, iniziano a trarne vantaggio. Quando qualcuno li interrompe per lo stato, faccio notare che possono semplicemente guardare nel tracker (e lasciare il dev da solo) e dopo che ciò accade un paio di volte lo sviluppatore inizia a vedere il punto. Niente è più frustrante di qualcuno che interrompe i tuoi progressi per chiedere informazioni sui tuoi progressi! Puoi pazientemente insegnare a questo sviluppatore che la segnalazione proattiva e l'aggiornamento dello stato lasceranno molto tempo per programmare in pace. Se allo sviluppatore non piace digitare frasi, puoi aiutare con quello. Far avanzare i progressi (e vedere di persona dov'è il problema - aggiornare i fogli Excel condivisi è dannatamente orribile) farà una differenza più grande che correggere e infastidire lo sviluppatore a fare ciò che non è motivato a fare.

Se queste abilità che descrivi come settimanali o inesistenti sono importanti per il suo ruolo nel team, la selezione di questo dipendente per quel ruolo era sbagliata o la formazione era un problema. Se non hanno mai svolto queste attività, non sono stati adeguatamente formati su ciò che è richiesto nel ruolo o la formazione non ha suscitato riluttanza a svolgere tali attività.

Se vedono il loro unico vero ruolo di programmatore , allora quello potrebbe essere il ruolo per loro. La riluttanza a comunicare correttamente (al proprio team, al proprio team, ai clienti) è un segno che non sono pronti per questo o potrebbero non essere mai pronti per questo ruolo.

Le email consegnate in base a una pianificazione prestabilita su un argomento stabilito non vengono gestite. Queste e-mail vengono rapidamente visualizzate come un lavoro di routine, soprattutto se sembrano essere nient'altro che qualcosa da selezionare in una casella. Andare regolarmente in giro per tutte le parti del team, con te che poi prendi appunti quando torni in ufficio, può alleviare i comunicatori riluttanti.

Posso inviarti un'email regolare, ogni giorno che fa credi che si stiano compiendo progressi costanti; o che stiamo superando ostacoli difficili; o quello che siamo è un disperato bisogno di risorse aggiuntive. Se questa è la tua unica finestra sul progresso, non stai guidando la squadra.

Per quanto riguarda la comunicazione con i clienti. Potrebbe non essere nemmeno necessario averlo lì. Ho conosciuto molte persone che erano molto felici di non parlare mai con i clienti.

Devi riassumere le competenze essenziali necessarie per l'attività, sia di programmazione che di non programmazione. Quindi devi decidere cosa può fare quella persona ora, cosa può fare con una formazione aggiuntiva e cosa non sarà mai in grado di fare. Quindi devi trovare un modo nel tuo team per mitigare questi problemi. Possono essere compiti aggiuntivi per te o per qualcuno della tua squadra; o un cambiamento è un ruolo per loro.

Personalmente credo che tu abbia una persona che ricopre un ruolo che non è adatto a ricoprire. Una volta che prendi una posizione di comando, la codifica è una tua responsabilità secondaria e non dovrebbe occupare più del 50% - 70% del tuo tempo (personalmente vado con 50 ma lui è un modulo lead non un generale piombo, quindi forse il 70% è più appropriato). Vorrei sedermi con lui e chiedergli quanto tempo pensa di dover dedicare alle attività di gestione della codifica dei vizi e poi dirgli la tua effettiva aspettativa della divisione tra i due e poi chiedergli se preferirebbe essere uno sviluppatore piuttosto che un lead se le due stime sono fuori posto e lui non è disposto a cambiare la tua stima. Avere un vantaggio che svaluta il tempo speso nella gestione significa che non hai un vantaggio.

Potrebbe essere uno scontro diretto di personalità. Ero uno dei due team leader di una determinata azienda. L'altro Team Lead aveva uno sviluppatore che suona in modo estorsivo come il tuo. Man mano che i problemi aumentavano e le difficoltà aumentavano, lo sviluppatore è stato spostato nel mio team. Sono riuscito a capovolgerlo vedendo i problemi che aveva con l'altro Team Lead e utilizzando un diverso insieme di criteri per motivarlo e sfidarlo. Per molti aspetti sono stato più assertivo, stimolante e più duro (come nel fissare scale temporali aggressive, e davvero smontare il suo lavoro e costringerlo a farlo di nuovo) con lui. Questo lo ha fatto crescere, soprattutto perché ho ascoltato molto quello che aveva da dire e l'ho proposto di condurre show-and-tell e parlare direttamente con l'alta dirigenza dei progetti. Dopo tre mesi, il mio manager ha discusso con me una promozione per questo ragazzo e l'abbiamo debitamente fatto. Tre anni nell'altra squadra non è andato da nessuna parte, sei mesi nella mia, si è voltato e ha brillato.

Alla fine, ho fatto poco diverso dal mio collega Team Leading poiché tutti i processi manageriali di base erano il lo stesso per le squadre. Tutto si riduceva al fatto che la mia personalità era diversa.

Non intendo essere apertamente critico nei confronti dell'OP, ma c'è un'enorme differenza tra Team-Leadership e Team-Management. Mi ha fatto capire che la situazione è più basata su un processo manageriale, piuttosto che sulla leadership effettiva.

Ti aiuterà a far fronte alla tua situazione se ti riconcili con diverse verità inconfutabili:

1. Gli ingegneri del software sono lavoratori esperti della conoscenza a cui non piace fare documenti. A loro piace programmare.

2. Gli ingegneri del software, almeno quelli bravi, come è stato detto sopra, rilevano facilmente le insidie ​​operative (ad esempio "Nella nostra organizzazione non abbiamo il lusso di strumenti. Per lo più dobbiamo dipendere da fogli Excel. "e da troppe riunioni inutili) e, poiché sono talentuosi knowledge worker, sono facilmente infastiditi da quella circostanza ed essendo soggetti a dover svolgere un lavoro più faticoso, insignificante, burocratico perché i loro manager erano sciatti o economici per investire in infrastrutture adeguate. Se sono bravi, non lo sopporteranno e andranno a lavorare altrove. Noto il tono del tuo esclamare che non hai strumenti come se ne fossi quasi orgoglioso (simile a "quando avevo 8 anni, dovevo andare a scuola a piedi per 11 miglia nella neve") mentre è piuttosto stato imbarazzante della tua organizzazione.

3. Il tuo socio, secondo il tuo account, probabilmente ha la sindrome di Asperger. Indovina un po ', questo è il termine scientifico per definire il nerd definitivo a cui può essere attribuita la maggior parte dei risultati tecnologici. Non ti piacciono gli Aspies, la loro introversione e imbarazzo e preferiresti che il tuo sviluppatore fosse un venditore di auto usate da confratello con ... uhm ... abilità umane? Beh, il ragazzo della confraternita non sa come programmare. Che ne dici di tornare all'età della pietra se le abilità interpersonali sono così importanti? Non puoi avere entrambi. Se vuoi che il software sia costruito bene, dovrai adattarti ai tipi nerd.

La mia risposta finale è di accogliere il tuo socio Aspie. Mi vedo in lui al 100%. Perché qualcuno che sa programmare dovrebbe essere tenuto a partecipare a riunioni senza senso per mezza giornata? O stai riempiendo le copertine sul loro rapporto TPS? Pensa al tuo processo e rendilo leggero a vantaggio di tutti. Una volta che diventerà semplice e snello, forse al tuo collaboratore non dispiacerà spendere 10 minuti al giorno per inviare gli artefatti necessari per tenere tutti aggiornati.

Perché hai assunto questa persona / perché ha accettato questo lavoro? Da qualche parte si è verificata una disconnessione quando questa persona è stata abbinata a questa posizione. Ovviamente un programmatore non "vuole" fare cose non di programmazione, ma se accettasse il lavoro e acconsentisse, suggerirei di rimandarlo a casa e di lasciarlo tornare quando è pronto a lavorare.

Approfitta delle competenze che ha. Se la tua azienda pensa di poter assumere e compensare programmatori di alto livello rendendoli una sorta di manager, questo è un perfetto esempio di perché questo è un errore. Perdi soldi ogni minuto che non sta programmando. Vuole strumenti migliori, digli di iniziare a implementare e integrare alcuni dei prodotti open source. Lascialo condividere e insegnare agli altri sviluppatori come usarli. Otterrai un maggiore ritorno sull'investimento in questa persona se i tuoi altri programmatori possono imparare qualcosa da lui. Mettilo nei progetti difficili. Lascia che crei i repository, i framework e le API che possono essere sfruttati da altri.

Strategia di riunione migliorata Odio quando un manager mi trascina in una riunione in cui hanno una chiara agenda di come gestire il cliente / situazione, ma non si è mai preso la briga di spiegarmelo in anticipo. Ci vuole un grande sforzo per evitare opinioni contraddittorie e andare fuori tema. Incontra prima. Fagli sapere che questo è il momento del dissenso e quando entri nella riunione, sii un giocatore di squadra e rispetta il piano, che ti piaccia o no.

Comunicazione Chiunque abbia un'avversione per la comunicazione impara meglio a STFU tenere a freno la lingua durante le mie riunioni. Non puoi averlo in entrambi i modi. Ovviamente dovresti evitare di mettere questa persona in questa situazione in primo luogo.

Un altro approccio è iniziare in piccolo. Le email di stato a te stesso sono un bel posto sicuro per iniziare. In qualità di responsabile / manager del team, è perfettamente ragionevole che tu chieda un'email di stato settimanale (o giornaliera). In realtà vorrei iniziare quotidianamente per migliorare la comunicazione tra voi due. Non è un grosso problema per lui inviarti un'email una volta al giorno.

E alla fine, tutti facciamo cose che non ci piacciono. Ecco perché veniamo pagati. Se qualcuno vuole programmare senza interagire con nessun altro, quello è un hobby, non un lavoro.

Quando si parla con lui, questo è un punto importante. Che il nostro lavoro NON è programmare. È produrre valore per il cliente. La programmazione fa parte di questo. Non tutto.

Mi sembra che il tuo collega sia molto creativo. Indovina un po? La gestione delle persone creative è un campo creativo in sé. Mi viene in mente una scenetta di Hee Haw:

Paziente: Dottore, fa male ogni volta che muovo il braccio in questo modo! Dottore: Bene, allora smettila di muovere il braccio in questo modo!

Se sei stanco di litigare con lui, smettila di discutere con lui. Non pretendo di avere tutte le risposte. Tuttavia, vorrei sottolineare che hai due soluzioni affidabili: convincere qualcuno a licenziarlo. Oppure lascia il tuo lavoro e lavora da qualche altra parte.

Quando hai a che fare con questo programmatore, dovresti tenere a mente una cosa: i problemi che hai con lui potrebbero benissimo essere anche le cose che lo rendono utile per te. Quello che ho sentito da te è "Questo è un dipendente molto competente. Tuttavia, nella nostra azienda ci aspettiamo che le persone si comportino in modo x e questo dipendente non si comporta in questo modo".

Capisco perfettamente la necessità di avere una direzione comune e alcune regole comuni. Tuttavia, la ricerca ha dimostrato che (in generale) è una buona cosa per le organizzazioni avere i propri dissidenti. In effetti, potresti effettivamente considerare questo un " buon problema da avere". Alcune persone si limitano a marciare al ritmo di un tamburo diverso, e non solo va bene, probabilmente dovresti incoraggiarlo.

D'altra parte, la tua organizzazione ha vincoli pratici. Non puoi lasciare che questo dipendente agisca in modo tale da abbattere tutti gli altri. Il mio suggerimento è pensare in modo pratico. Identifica due cose:

1. Le principali battaglie che sono veramente che vale la pena combattere. Tendo a chiedermi cosa dirò al riguardo tra 20 anni. Tra 20 anni dirai davvero "Avrei voluto convincerlo a comunicare meglio via e-mail"? È più probabile che ti ritroverai a dire qualcosa di più sulla falsariga di "Vorrei aver trovato un modo migliore per sfruttare il suo talento. Ragazzi, ha detto alcune cose divertenti durante le riunioni".
2. Il frutto basso appeso. Cose che puoi risolvere senza troppi problemi. Ho il sospetto che quando sei arrivato a dove sei, probabilmente hai già risolto la maggior parte di queste cose. Tuttavia, vale la pena fare attenzione.

Queste sono le cose per le quali devi fare qualcosa. Il mio suggerimento è di combattere l'impulso di "risolvere" semplicemente i problemi nella categoria 1, perché probabilmente non sarai in grado di risolverli. Detto questo, se tu e lui riuscite a capire un paio di problemi importanti e concreti su cui concentrarvi, è molto più facile risolverli.

Il lavoratore può essere piuttosto creativo come accennato in precedenza, o può essere molto concentrato sulla risoluzione dei problemi (il problema per come lo comprende) ed essere molto meno interessato al quadro generale (creare software che si integri perfettamente con i progetti di altri gruppi, per esempio).

Un'idea che avrei sarebbe quella di dimostrargli alcuni dei problemi che potrebbe presentare essendo così concentrato e riluttante a comunicare con gli altri. La mia idea è di scrivere un esercizio per tutti i membri del team da completare all'inizio di una riunione (priorità bassa). L'esercizio dovrebbe iniziare con un'istruzione del tipo "Questo esercizio è a scopo di discussione; gli errori sono previsti e sono accettabili. Si prega di leggere l'intero esercizio prima di iniziare". (Porta penne extra nel caso in cui le persone abbiano solo matite e le penne sono disponibili vicino a te, probabilmente in una piccola pila di fronte a te, ma non distribuirle.) Avere uno spazio in alto con l'etichetta Nome: (dove inserirà il loro nome) ;-)

L'idea dell'esercizio è di chiedere risposte che cambieranno in base alle informazioni (dettagli aggiuntivi) fornite in seguito. È un esercizio di trucco, si spera che dimostri che un lavoratore supponendo di comprendere abbastanza bene le esigenze e non coordinare lo stato e gli aggiornamenti porterà a errori e riscritture.

Supponendo che tutti i membri del team siano programmatori), l'esercizio potrebbe essere così:

1. Scrivi un semplice programma o diagramma di flusso che includa le fasi di immissione di nomi e indirizzi utente, assegna loro un numero cliente e stampa il numero cliente e i nomi utente e indirizzi.

   (includere un mezzo foglio di carta vuoto.)

2. Gli utenti dovrebbero essere in grado di ordinare i dati in base a un numero di identificatori, incluso il numero cliente, nome del cliente, città del cliente, codice postale del cliente, numero di telefono del cliente, SSN del cliente, data di apertura del conto del cliente o data dell'ultima transazione del cliente.

   (Includere uno spazio vuoto su terzo di una pagina.)

3. Per favore usa solo una penna per il tuo lavoro e non discutere l'esercizio durante questa riunione.

4. Importante: ignora le istruzioni di cui sopra. Invece, scrivi solo il tuo nome in alto e metti un segno di spunta accanto ai numeri di istruzione 1, 2, 3 e 4 e attendi in silenzio che gli altri finiscano.

Dopo circa due minuti, dì grazie, è tutto il tempo che abbiamo per questo. Per favore riprendi il tuo lavoro da dove l'avevi interrotto Quindi procedi con il normale incontro.

Probabilmente molti o la maggior parte seguiranno le istruzioni che iniziano con 1, poi 2, invece di leggerle tutte prima e fare solo ciò che 4 chiede. Questa è la tua apertura per quel dipendente, o se lo desideri, per l'intero gruppo, da solo o in gruppo (ma singolarmente sarebbe meglio per una migliore conversazione con il bambino problematico) sul valore della condivisione delle informazioni, tenersi aggiornati sui cambiamenti bisogni, ecc. Assicurati di scusarti per il trucco, ma volevi avere un modo per farlo notare a basso costo, al contrario delle grandi riscritture che potrebbero costare straordinari, recensioni negative, ecc.

Una volta sono stato a capo del team dello sviluppo software della mia azienda per oltre 2 anni e ho osservato che molte volte la produttività di ogni membro del team dipendeva dal loro livello di motivazione e da qualche riconoscimento. Una volta ho avuto un ragazzo nel mio team con relativamente più esperienza degli altri membri e avevo davvero bisogno del suo contributo. Mi sono reso conto dopo diversi colloqui con lui che la sua mancanza di collaborazione era dovuta al fatto che non voleva essere trattato come gli altri membri della squadra. quello che ho fatto è stato dargli alcune responsabilità e fare riferimento a lui. In questo modo è diventato più collaborativo, quindi ho provato a trovare o creare una responsabilità e metterlo a capo di essa, più come lasciarlo guidare in un'area. Quindi potresti dover inventare qualcosa di molto creativo come ha detto Jason. il punto è cercare di trovare un modo per metterlo a capo / responsabile di qualcosa in modo che si senta un senso di responsabilità e apprezzato e molte volte funziona. So che può essere frustrante gestire una persona del genere. Un modo simile per esprimere questa strategia è dare ai lavoratori l'opportunità di creare un "impatto" in "Le 9 cose principali che motivano i dipendenti a ottenere risultati"