Dobbiamo averli incontrati tutti - sviluppatori che sono stati in giro da secoli e hanno una conoscenza fantastica del dominio eppure non riescono a condividere questa conoscenza con il loro team.
Il team ha bisogno disperatamente di condividere la conoscenza, ma non riesco a tirarlo fuori dall'accaparratore.
In che modo i team hanno risolto con successo questo problema?
Rimuovi la proprietà del codice dal team. Diffondi il carico di lavoro. Fai recensioni di codice. Organizzare sessioni di trasferimento delle conoscenze, attendere alcune sessioni e poi chiedere loro di fare una presentazione sulla loro area.
Ovviamente, è imperativo che se non sei il manager hai il sostegno del tuo manager, ma se tutti in una squadra condividono regolarmente le informazioni, ci sono solo tante scuse per qualcuno può venire con per non fare la stessa cosa.
Inoltre, il suo manager dovrebbe sedersi con lui e spiegare che questo non minaccia il suo lavoro. Perché è per questo che lo sta facendo.
È un bene che il singolo non sia il font di tutta la conoscenza. Lo libera per fare altre cose più interessanti.
Credo che Gerald Weinberg si riferisse a questo esatto tipo di persona quando ha commentato in La psicologia della programmazione informatica (parafrasato perché non ho il libro di fronte a me), Se noti un programmatore che cerca di rendersi indispensabile, licenziatelo immediatamente. 25 anni dopo, quando ha ristampato il libro, ha commentato che nessun altro consiglio gli aveva dato tanto grazie come questo.
Quindi questa è una soluzione.
Dai loro ciò che vogliono - assegna loro tutti i lavori di manutenzione e le attività che solo lui / lei ha le conoscenze da fare.
No, non possono fare nuovi lavori perché nessun altro può eseguire questi altri importantissimi lavori di manutenzione.
Sì, i nuovi assunti stanno ottenendo il lavoro divertente e giocando con i nuovi giocattoli brillanti, ma devi svolgere questi compiti molto difficili, con priorità alta e noiosi perché non conoscono le cose che fai.
A meno che tu non voglia mostrare a uno di loro come farlo ....
Questo promemoria di questo articolo da Rands in Repose.
Penso che tu debba capire perché questo tipo stia accumulando informazioni. La sicurezza del lavoro (come l'articolo su The Fez) è grande. Ma così è l'insicurezza. O solo che gli piace questo tipo di lavoro e vuole tutto per sé, o sente un intenso senso di proprietà su una particolare area. Oppure è troppo impegnato e non ha visto un modo per guadagnare tempo.
Alcuni di questi problemi possono essere risolti con trucchi non conflittuali:
Vale anche la pena di unirsi a qualche tentativo di sollecitazione informativa - possono volerci due persone per ballare il tango, e non si può voler escludere l'idea che ci sia abbastanza intimidazione in giro che la domanda-chi chiede non stia chiedendo domande, esacerbando così il problema. Potrebbe essere necessario saltare dentro e iniziare a fare il backup e fare domande più ampie per far muovere il ragazzo. Inoltre, avere la gestione lì facendo domande dà peso e importanza all'attività di condivisione delle informazioni: è molto più difficile arretrare ed evitare la gestione. Di solito con alcune sessioni produttive in corso, puoi uscire dal centro e dire "voi ragazzi avete questo, non avete bisogno di me" e passare al prossimo problema.
Un'altra chiave è non lasciare che il ragazzo domini il lavoro nelle aree in cui ha bisogno di condividere la conoscenza. Mettere qualcun altro a capo del lavoro e chiarire che è il lavoro del tessitore di informazioni condividere la conoscenza. Se non può condividere, potrebbe essere necessario avere una conversazione brutale in cui spieghi che la condivisione delle informazioni è un requisito per la squadra, non un'opzione. Che sta contribuendo ai problemi del programma di squadra non aiutando qualcun altro a imparare.
Non sono sicuro che "rifiutare" sia spesso la parola giusta, di solito sono troppo occupati e non hanno il tempo libero (o inclinazione o abilità sociali) per dedicare molto tempo a spiegare l'ovvio (a loro) al n00bs.
La soluzione positiva è quella di fornire loro assistenti - quasi come diffondere il lavoro intorno alla squadra (ma credo che non ci sia molta squadra se si hanno veterani che sanno tutto del sistema, e nuovi ragazzi che no, dato questo setup non c'è da meravigliarsi se non vogliono comunicare le loro preziose abilità e essere sostituiti con una versione più giovane, più economica!) (non lo faresti neanche - immagina se il tuo manager è venuto da te e ti ha chiesto di comunicare tutto quello che sai al nuovo team in outsourcing ... hmm?)
Raccomando che l'assistente lavori su una parte del sistema e ci si aspetta che diventi esperto in esso nel tempo, ci si aspetta che lo sviluppatore esperto li aiuti a svolgere il loro lavoro in quella piccola area. Siamo stati tutti lì comunque, "se vuoi sapere come funziona X, dimentica la documentazione (obsoleta o inesistente) e parla con Jim".
Assegnare loro un assistente non solo conferma la loro posizione di sviluppatori esperti (quali sono), e dà loro l'opportunità di alleviare alcuni dei maggiori carichi di lavoro, ma anche di diffondere la conoscenza nel tempo. Diventano mentori o posizioni di "primo passo verso la leadership" che dovrebbero rassicurarli sul fatto che il loro lavoro è sicuro e la loro esperienza è valutata. Se non riesci a fare nessuna di queste cose, fallirai come gestore.
Non dimenticare che se hai un qualsiasi tipo di sistema super-complx (che fai, o che i nuovi ragazzi dovrebbero essere in grado di capirlo da soli), allora il trasferimento delle conoscenze è un processo molto lungo. Non c'è modo in cui nessuno può sedersi e portare qualcuno completamente alla velocità, al mio posto questo compito richiederebbe almeno 6 mesi, e anche allora .. diamine, sto ancora imparando cose su ciò che fa il nostro prodotto e sono stato qui quasi un decennio!
Rendi la comunicazione un impegno per ogni membro del team e valutali su questo come parte della revisione annuale.
Assicurati che il team sia riconosciuto per i risultati raggiunti e non solo per gli individui e assicurati che tutti sappiano che il successo della squadra è la loro priorità, penalizzali se impediscono al team di avere successo.
Assicurati che non ci siano blocchi per le comunicazioni, assicurati che ci siano processi e sistemi per scrivere documenti e condividere informazioni; per esempio. wiki, siti sharepoint, risultati programmati per i documenti di progettazione ecc.
Assicurati che tutti i progetti contengano almeno due programmatori che possono lavorarci. Questo per assicurarti di avere sempre un backup quando qualcuno lascia l'azienda.
Abbiamo anche avviato una wiki che contiene tutte le informazioni del nostro database. È un modo molto utile per accedere o aggiornare rapidamente le informazioni.
Se lo "accaparratore" non lo sta facendo apposta, ma in realtà lo fa solo a causa di mancanza di abilità sociali, impegni di tempo, ecc. Prendete loro in particolare un "assistente" o un programmatore junior incaricato di alleggerire il carico di lavoro o aiutare ad estrarre le conoscenze. Fai capire a entrambe le parti che questo è lo scopo delle nuove persone e coinvolgere il "accaparratore" nel processo dell'intervista. La gestione deve prendere una mano in questo e permettere loro di condividere le loro conoscenze. Questo è lo scopo del management, rimuovere gli ostacoli e consentire ai lavoratori di portare a termine il lavoro.
Secondo la mia esperienza, gli accaparratori di informazioni possono essere classificati in due tipi: quelli a cui piace condividere le loro conoscenze e ottenere un senso di gratificazione aiutando apertamente gli altri, come me stesso e quelli che non lo fanno. Ovviamente.
Ora, entrambe le parti hanno le loro ragioni, e quella a cui piace condividere le proprie conoscenze raramente darà tutto per lo stesso motivo per cui le persone che non condividono le proprie conoscenze non lo fanno: stanno cercando di fare le persone intorno a loro meglio, e secondo la mia opinione parziale, hanno ragione nel farlo. (Naturalmente, hai anche quelli che non condividono la conoscenza semplicemente per rendersi indispensabili, e questo è per le ragioni sbagliate, e dovrebbero essere eliminati perché di solito non sono così grandi per cominciare)
Dopo tutto, hanno dovuto scavare in profondità nei mari arcani ed esoterici per apprendere ciò che sanno, di solito attraverso pura sperimentazione, un'applicazione liberale del pensiero critico, sprazzi di intuizione e intuizione e riti mistici che coinvolgono vari tipi di bestiame sacrificale, e ne è venuto fuori il meglio. Di solito, la linea di pensiero è che se le persone intorno a loro sono troppo pigre o non riescono a gestirle nello stesso modo, non dovrebbero neanche iniziare il lavoro, e certamente non sono degne delle loro conoscenze. Quando quelli intorno a loro passano attraverso le stesse cose che devono fare, allora escono fuori un programmatore migliore perché avranno imparato come pensare bene e risolvere problemi complessi e tutto il resto.
Sta essenzialmente costringendo gli altri a diventare migliori attraverso la lotta. Mentre troppa sarà calpestata e scartata, quelli che supereranno la sfida saranno inevitabilmente molto meglio di quanto avrebbero se migliorassero grazie alla cooperazione.
Ora, per far sì che condividano le informazioni: non puoi costringerli a farlo. Cercare di costringerli a farlo ti farà vedere come avido, pigro o troppo stupido per arrivarci da solo, e certamente non avranno pietà di te in nessuno di questi casi. Se qualcuno più in alto cerca di costringerli a farlo, potrebbe diventare molto cattivo, trasformando tutta la loro considerevole intelligenza per ostacolare l'individuo, o addirittura abbandonare apertamente piuttosto che tradire i loro principi, dopo tutto, ci sono molti posti che potrebbero usare le loro abilità e conoscenza.
C'è davvero un solo modo per ottenere uno di questi a cui non piace condividere le proprie conoscenze per condividere volontariamente le proprie conoscenze: diventarne degni. Di solito avere una conoscenza che non hanno è abbastanza (ma difficile da fare). Quid pro quo e tutto il resto. Altrimenti, compra un paio di capre e tuffati dentro.
Chi è il capo? Dove finisce? Non devi condividere informazioni. Non è necessario fornire documentazione. Non riescono continuamente a fare le cose in tempo. Non seguire gli standard di codifica. O qualcuno responsabile pensa che questo sia importante o loro no. Ci dovrebbero essere delle conseguenze. Praticamente stanno rubando dalla compagnia.
Le persone che interpretano il "Ho un gioco segreto" sono il peggiore in assoluto. Queste persone tendono ad essere insicure e creano o prosperano in modalità di crisi .
Li farei documentare ogni cambiamento o modifica che fanno al sistema. Vorrei anche fornire loro un post mortem per ogni correzione che hanno sviluppato per includere ...
Vorrei anche rendere questa persona responsabile per ...
Molto dipende dal tipo di conoscenza coinvolta; se è direttamente codice o orientato al processo aziendale. In genere quest'ultimo è disponibile altrove nel business ... e può essere acquisito.
In secondo luogo, c'è una discussione nel garantire che nessuno sviluppatore debba passare l'intera vita lavorativa su aree specifiche senza condividere, per così dire. Quindi, se hai un manager di linea incaricato di distribuire il lavoro, vale la pena di fargli fare in modo che tutte le richieste di cambiamento di business arrivino attraverso di lui / lei per essere distribuite senza che uno sviluppatore specifico diventi la prima linea di contatto per un processo proprietario ... Ciò ostacolerà gli sforzi da parte di uno sviluppatore di diventare un guru.
Sarebbe nel migliore interesse di entrambe le parti se l'informazione l'accaparratore è stato incoraggiato a trovare un'azienda di dimensioni più ridotte o anche per avviare la propria azienda? Forse la persona potrebbe prosperare quel tipo più piccolo di ambiente. (Sono curioso se qualcuno ha mai provato questo approccio anche nel mondo reale.)
Leggi altre domande sui tag knowledge-management team-leader collaboration information