Come gestisci una raccolta di informazioni? [chiuso]

Dobbiamo esserci imbattuti tutti in loro: sviluppatori che esistono da anni e hanno una fantastica conoscenza del dominio e tuttavia non riescono a condividere tale conoscenza con il loro team.

Il team ha un disperato bisogno di condividere le conoscenze, ma non riescono a toglierle dall'accaparratore.

In che modo i team hanno risolto con successo questo problema?

Rimuovere la proprietà del codice dal team. Distribuire il carico di lavoro. Esegui revisioni del codice. Organizza le sessioni di trasferimento delle conoscenze, attendi qualche sessione e poi chiedi loro di fare una presentazione sulla loro area.

Naturalmente, è indispensabile che se non sei il manager, hai il supporto del tuo manager, ma se tutti i membri del team condividono regolarmente informazioni, ci sono solo tante scuse che qualcuno può inventare per non fare la stessa cosa .

Inoltre, il suo manager dovrebbe sedersi con lui e spiegare che ciò non minaccia il suo lavoro. Perché è per questo che lo sta facendo.

È una buona cosa per l'individuo non essere il carattere di tutta la conoscenza. Lo libera di fare altre cose più interessanti.

Credo che Gerald Weinberg si riferisse a questo esatto tipo di persona quando ha commentato in The Psychology of Computer Programming (parafrasato perché non ho il libro davanti a me), se noti un programmatore che cerca di rendersi indispensabile, spara lui immediatamente. 25 anni dopo, quando ha ristampato il libro, ha commentato che nessun altro consiglio gli ha procurato ringraziamenti come questo.

Quindi questa è una soluzione.

Dai loro quello che vogliono - assegna loro tutto il lavoro di manutenzione e le attività che solo lui / lei ha le conoscenze da svolgere.

No, non possono fare nuovi lavori perché nessun altro può fare questi altri importantissimi lavori di manutenzione.

Sì, i nuovi assunti stanno ottenendo il lavoro divertente e giocando con i nuovi giocattoli luccicanti, ma devi fare questi compiti molto difficili, di alta priorità e noiosi perché non sanno nulla delle cose che fai.

A meno che ovviamente tu non voglia mostrare a uno di loro come farlo ...

Questo ricorda questo articolo di Rands in Repose.

Penso che tu debba capire perché questo ragazzo sta accumulando informazioni. La sicurezza del lavoro (come l'articolo su The Fez) è importante. Ma lo è anche l'insicurezza. O semplicemente che gli piace questo tipo di lavoro e vuole tutto per sé, o sente un intenso senso di proprietà su una determinata area. O è troppo impegnato e non ha visto un modo di fare il tempo.

Alcuni di questi problemi possono essere risolti con trucchi non conflittuali:

• porta al ragazzo alcuni compiti che allargano i suoi orizzonti e lo costringono a consegnare un po 'di lavoro.
• capire da dove viene l'insicurezza e lavorare su qualsiasi problema reale stia portando all'accumulo di informazioni.
• fai notare al ragazzo che diventare troppo bloccato nella routine poiché l'unico detentore della conoscenza significa che non ne sarà mai libero e la sua carriera sarà strettamente accoppiata con la tecnologia - e tutta la tecnologia alla fine se ne andrà.
• capire da dove proviene l'eccessivo impegno e capire cosa è più importante

Vale anche la pena partecipare a alcuni tentativi di sollecitazione di informazioni: possono volerci due per il tango e potresti non voler escludere l'idea che ci sia abbastanza intimidazione in giro che i richiedenti non stanno facendo buone domande, quindi esacerbando il problema. Potrebbe essere necessario saltare e iniziare a fare il backup delle cose e fare domande più ampie per far muovere il ragazzo. Inoltre, avere la direzione lì a porre 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 "ragazzi avete questo, non avete bisogno di me" e passare al problema successivo.

Un'altra chiave è NON permettere al ragazzo di dominare il lavoro nelle aree in cui deve condividere le conoscenze. Metti qualcun altro a occuparsi del lavoro e chiarisci che è compito del raccoglitore di informazioni condividere le conoscenze. Se non può condividere, potrebbe essere necessario avere una conversazione brutale in cui spieghi che la condivisione delle informazioni è un requisito per il team, non un'opzione. Che sta contribuendo ai problemi di pianificazione del team non aiutando qualcun altro a imparare.

Non sono sicuro che "rifiuto" sia spesso la parola giusta, di solito sono troppo occupati e non hanno il tempo libero (o l'inclinazione o le abilità sociali) per prendersi un sacco di tempo libero per spiegare l'ovvio (per loro ) ai n00bs.

La soluzione positiva è quella di fornire loro degli assistenti - quasi come diffondere il lavoro suscitando il team (ma immagino che non ci sia molto di un team se hai vecchi esperti che sanno tutto sul sistema e nuovi ragazzi che non lo fanno , data questa configurazione, non c'è da meravigliarsi se non vogliono comunicare le loro preziose abilità ed essere sostituiti con una versione più giovane ed economica! alla nuova squadra in outsourcing ... hmm?)

Consiglierei l'assistente che lavora su una parte del sistema e dovrebbe diventare un esperto nel tempo, lo sviluppatore esperto dovrebbe aiutarli a fare 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".

Dare loro un assistente non solo conferma la loro posizione di sviluppatori esperti (che sono) e offre loro l'opportunità di alleviare parte del carico di lavoro principale, ma diffonderà anche la conoscenza nel tempo. Diventano mentori o posizioni di "primo passo per condurre una squadra" che dovrebbero rassicurarli sul fatto che il loro lavoro è sicuro e la loro esperienza è valutata. Se non riesci a fare nessuna di queste cose, allora stai fallendo come manager.

Non dimenticare che se hai qualche tipo di sistema super-complx (cosa che fai, o i nuovi ragazzi dovrebbero essere in grado di capirlo da soli), il trasferimento delle conoscenze è un processo molto lungo. Non c'è modo in cui nessuno possa sedersi e mettere qualcuno completamente al passo, al mio posto un tale 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!

Trasformare la comunicazione in un impegno per ciascun membro del team e valutarli su questo come parte della revisione annuale.

Assicurati che la squadra sia riconosciuta per i risultati e non solo per gli individui e assicurati che tutti sappiano che il successo della squadra è la loro priorità, penalizzali se impediscono il successo della squadra.

Assicurarsi che non vi siano blocchi per la comunicazione, assicurarsi che esistano processi e sistemi per la scrittura di documenti e la condivisione di informazioni; ad esempio wiki, siti sharepoint, risultati programmati per documenti di progettazione ecc.

Assicurati che tutti i progetti abbiano almeno due programmatori che possano lavorarci sopra. Questo per assicurarti di avere sempre un backup quando qualcuno lascia l'azienda.

Abbiamo anche avviato un wiki che contiene tutte le informazioni sul nostro database. È un modo molto utile per accedere o aggiornare rapidamente le informazioni.

Se lo "accaparratore" non lo fa davvero di proposito, ma in realtà lo fa solo a causa di qualcosa come la mancanza di abilità sociali, impegni di tempo, ecc. Sicuramente procuragli un "assistente" o un programmatore junior specificamente incaricato di allentare il carico di lavoro o aiutare a estrarre la conoscenza. Spiegare ad entrambe le parti che questo è lo scopo delle nuove persone e coinvolgere il "difensore" nel processo di intervista. Il management deve prendere una mano in questo e consentire loro di condividere le proprie conoscenze. Questo è lo scopo della gestione, rimuovere gli ostacoli e consentire ai lavoratori di svolgere il proprio lavoro.

Nella mia esperienza, gli accumulatori di informazioni possono essere classificati in due tipi: quelli a cui piace condividere le proprie conoscenze e ottenere un senso di gratificazione dall'aiutare apertamente gli altri, come me, 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 che le persone che non condividono le loro conoscenze non lo fanno: stanno cercando di rendere le persone intorno loro meglio, e secondo la mia opinione parziale, hanno ragione nel farlo. (ovviamente, hai anche quelli che non condividono le conoscenze semplicemente per rendersi indispensabili, e questo è per motivi sbagliati, 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 imparare ciò che sanno, di solito attraverso la pura sperimentazione, un'applicazione liberale del pensiero critico, lampi di intuizione e intuizione e riti mistici che coinvolgono vari tipi di bestiame sacrificale, e ne sono usciti meglio. La linea di pensiero di solito è che se le persone intorno a loro sono troppo pigre o non riescono a fare lo stesso, allora non dovrebbero nemmeno fare il lavoro per cominciare, e certamente non sono degni della loro conoscenza. Quando quelli intorno a loro passano attraverso le stesse cose che hanno dovuto fare, allora usciranno un programmatore migliore perché avranno imparato a pensare bene e risolvere problemi complessi e tutto il resto.

Fondamentalmente sta costringendo gli altri a migliorare grazie al conflitto. Mentre un sacco verrà calpestato e scacciato, quelli che riescono a superare il guanto saranno inevitabilmente molto meglio di quanto avrebbero se diventassero migliori attraverso la cooperazione.

Ora, per far sì che condividano le informazioni: non puoi costringerli a farlo. Cercare di costringerli a farli vedere come avidi, pigri o troppo stupidi per arrivarci da soli, e certamente non avranno pietà di te in nessuno di questi casi. Se qualcuno più in alto tenta di costringerlo a farlo, potrebbe diventare molto cattivo, volgendo tutta la sua notevole intelligenza per contrastare l'individuo, o addirittura abbandonare apertamente invece di tradire i suoi principi, dopo tutto, ci sono molti posti che potrebbero usare le loro abilità e conoscenza.

C'è davvero solo un modo per ottenere uno di questi a cui non piace condividere le proprie conoscenze per condividerle volentieri: diventarne degne. Di solito sapere che non hanno è abbastanza (ma difficile da fare). Quid pro quo e tutto il resto. Altrimenti, compra un paio di capre e tuffati.

Chi è il capo? Dove finisce? Non è necessario condividere informazioni. Non è necessario fornire documentazione. Non riescono continuamente a fare le cose in tempo. Non seguire gli standard di codifica. O qualcuno in carica pensa che questo sia importante o no. Dovrebbero esserci delle conseguenze. Fondamentalmente stanno rubando dalla compagnia.

Le persone che giocano al "Ho un gioco segreto" sono le peggiori in assoluto. Queste persone tendono ad essere insicure e creano o prosperano in modalità crisi .

Vorrei fare loro documentare ogni cambiamento o modifica che fanno al sistema. Vorrei anche far loro fornire un post mortem per ogni correzione che hanno sviluppato per includere ...

• quello che è successo
• perché è successo
• come prevenirlo
• quali altri sistemi sono vulnerabili allo stesso bug

Vorrei anche rendere questa persona responsabile per ...

• sviluppo di standard di codifica
• mantenere una libreria di codici

Molto dipende dal tipo di conoscenza coinvolta; che si tratti direttamente di codice o orientato ai processi aziendali. In genere quest'ultimo è disponibile altrove nel settore ... e può essere acquisito.

In secondo luogo, c'è un argomento nel garantire che nessuno sviluppatore possa trascorrere la propria intera vita lavorativa in aree specifiche senza condividere, per così dire. Quindi, se hai un manager di linea che è responsabile della consegna del lavoro, vale la pena convincerlo a garantire che qualsiasi richiesta di modifica aziendale venga inviata a lui / lei per essere distribuita senza che uno sviluppatore specifico diventi la prima linea di contatto per un proprietario di un processo aziendale ... Ciò ostacolerà gli sforzi da parte di uno sviluppatore per diventare un guru.

Sarebbe nel migliore interesse di entrambe le parti se il raccoglitore di informazioni fosse incoraggiato a trovare un'azienda di dimensioni inferiori o addirittura a fondare la propria azienda? Forse la persona prospererebbe in quel tipo di ambiente più piccolo. (Sono curioso di sapere se qualcuno ha mai provato questo approccio anche nel mondo reale.)