Como você lida com um acumulador de informações? [fechadas]

29

Todos nós devemos nos deparar com eles - desenvolvedores que já existem há muito tempo e têm um conhecimento fantástico do domínio, e ainda assim não conseguem compartilhar esse conhecimento com sua equipe.

A equipe precisa desesperadamente compartilhar o conhecimento, mas parece que não consegue arrancá-lo do acumulador.

De que maneira as equipes resolveram esse problema com sucesso?

sheikhjabootie
fonte
2
A gerência faz o backup?
Um armazenador de informações apenas coleta informações, o armazenamento não significa que elas não serão compartilhadas. Talvez você queira perguntar como lidar com uma pessoa secreta, paranóica ou protetora?
asoundmove
na verdade não, um acumulador de informações é, por definição, alguém que mantém as informações para si. portanto, eles estão protegendo as informações que já possuem.
Tipo anônimo
@Thorbjorn - sim. A gerência pode ver o problema. Mas eles estão nervosos em agir de maneira muito impetuosa.
Sheikhjabootie 4/11
2
@ Tipo Anônimo - A questão é sobre como lidar com os gargalos das informações que podem ocorrer em uma equipe de desenvolvimento e seguir em frente. Quando o escrevi, assumi que todos os acumuladores estavam tentando se entrincheirar. Em algumas postagens, fica claro que esse não é o caso. E algumas sugestões muito práticas foram feitas para trabalhar com acumuladores que não possuem habilidades de comunicação para remover o gargalo da garrafa. Essa perspectiva é importante para evitar antagonismos indevidos. Este não é um clube de colecionador e ódio, eu só queria saber como lidar com um problema de desenvolvimento comum melhor :-)
sheikhjabootie

Respostas:

35

Remova a propriedade do código da equipe. Espalhe a carga de trabalho. Faça revisões de código. Organize as sessões de transferência de conhecimento, aguarde algumas sessões e peça que façam uma apresentação em sua área.

É, é claro, imperativo que, se você não é o gerente, tenha o apoio do gerente, mas se todos da equipe estiverem compartilhando informações regularmente, existem tantas desculpas que alguém pode inventar por não fazer a mesma coisa. .

Além disso, seu gerente deve sentar-se com ele e explicar que isso não ameaça seu trabalho. Porque é por isso que ele está fazendo isso.

É bom que o indivíduo não seja a fonte de todo conhecimento. Isso o libera de fazer outras coisas mais interessantes.

pdr
fonte
7
Dependendo de onde você trabalha e o que faz, isso pode muito bem ameaçar seu trabalho. Aposto que muitas pessoas que tiveram empregos altamente automatizáveis ​​estão aterrorizadas com o que a gerência descobrirá. A documentação é uma maneira de as pessoas descobrirem quanta energia cerebral entra em um trabalho e facilita muito a substituição dessa pessoa, voluntariamente ou não.
L0b0
1
@ l0b0 - Se uma empresa é bem-sucedida, sempre há mais alguma coisa a fazer, outros projetos em segundo plano. Eu espero que um gerente acredite na empresa o suficiente para vendê-la.
pdr
@pdr - Nesta equipe, a equipe se empenha em projetos de marcha da morte e, portanto, o acumulador está sempre "muito ocupado" para realizar sessões de entrega, produzir documentos etc. Tentamos mudar seu trabalho para ser exclusivamente treinador, mas ele diria o que fazer sem ensinar como ou por quê. Ele conseguiu deixá-los tanto no escuro quanto antes. Sua versão da programação em pares é ele fazendo tudo enquanto um júnior fica confuso. Causa problemas de retenção; mas não podemos perder o acumulador. Eu quero inspirá-lo para ser um grande líder da equipe que suporta seus companheiros de equipe, mas ele parece com medo de arriscar seu pescoço ...
sheikhjabootie
8
@Xcaliburp - novamente, se você estiver focando nele, ele resistirá. Se você está adotando a política da equipe, ele pode aguentar tanto tempo. Se ele recusar, então ele deve ser demitido. Eu estive em empresas que perderam alguém indispensável e você sabe o que? Nós sobrevivemos.
Pd
9
Habitualmente, fazer algo prejudicial à sua equipe deve ser um motivo para perder o emprego.
JeffO 3/11/16
33

Acredito que Gerald Weinberg estava se referindo a esse tipo exato de pessoa quando comentou em A Psicologia da Programação de Computadores (parafraseada porque não tenho o livro na minha frente). Se você notar um programador tentando se tornar indispensável, atire ele imediatamente. 25 anos depois, quando reeditou o livro, ele comentou que nenhum outro conselho o havia agradecido tanto quanto este.

Então essa é uma solução.

btilly
fonte
1
Essa é uma citação tão impressionante, gostaria de ter lido este livro já.
Tipo anônimo
Engraçado você dizer isso. O CEO da nossa empresa me disse isso hoje e ele é da Suíça (não dos EUA). Parece ser um sentimento internacional de que, se alguém está tentando se tornar indispensável, demiti-lo.
Brian
1
Seria ótimo se eu pudesse votar mais de uma vez. Eu daria a você pelo menos +20 para a cotação.
Jacek Prucia
12

Dê a eles o que eles querem - atribua a eles todo o trabalho e tarefas de manutenção que somente ele / ela tem o conhecimento para realizar.

Não, eles não podem fazer um novo trabalho, porque ninguém mais pode executar esses outros trabalhos de manutenção muito importantes.

Sim, os novos contratados estão recebendo o trabalho divertido e brincando com os brinquedos novos e brilhantes, mas você deve executar tarefas muito difíceis, de alta prioridade e chatas, porque eles não sabem nada do que você faz.

A menos que você queira mostrar a um deles como fazê-lo ....

jqa
fonte
1
Concordo com você em princípio, mas alguém no comando precisa fazer cumprir as regras. Isso não vai aguentar.
JeffO 3/11/16
2
Na minha experiência com gerentes, programadores e gerentes, 'impor as regras' é uma teoria legal, mas (sem problemas de RH) difícil. Com algumas pessoas, você pode descobrir em 5 segundos que está tentando empurrar as cordas molhadas para cima. Então, se eles querem fazer algo de uma maneira específica, eu os responsabilizo por sua decisão e dou todas as suas desculpas de volta (eles podem sonhar com o suprimento mais incrível e incessante de desculpas e isso me impede de pensar em refutações). E o resto da equipe não é arrastada para baixo. Quando percebem que se abriram em um buraco, começam a se virar.
JQA
Eu vejo isso como uma solução agressiva muito passiva. Eu acho que seria muito mais fácil apenas demitir a pessoa. Claro, discuta com eles primeiro. Verifique se eles sabem a importância da situação. Mas, na falta disso, solte-os.
ConditionRacer
11

Isso lembra este artigo da Rands in Repose.

Eu acho que você precisa descobrir por que esse cara está acumulando informações. A segurança no emprego (como o artigo sobre The Fez) é grande. Mas a insegurança também. Ou apenas que ele gosta desse tipo de trabalho e quer tudo sozinho, ou sente algum senso intenso de propriedade sobre uma área específica. Ou está comprometido demais e não viu uma maneira de ganhar tempo.

Alguns desses problemas podem ser resolvidos por truques sem confronto:

  • dê ao sujeito algumas tarefas que ampliam seus horizontes e o forçam a entregar algum trabalho.
  • descubra de onde vem a insegurança e trabalhe em qualquer problema real que esteja levando ao acúmulo de informações.
  • indique ao cara que ficar muito preso na rotina como o único detentor de conhecimento significa que ele nunca estará livre disso e sua carreira será fortemente acoplada à tecnologia - e toda a tecnologia eventualmente desaparecerá.
  • descobrir de onde vem o comprometimento excessivo e descobrir o que é mais importante

Também vale a pena participar de algumas tentativas de solicitação de informações - pode levar duas para dançar o tango, e você pode não querer descartar a idéia de que há intimidação suficiente para que os participantes não façam boas perguntas, portanto exacerbando o problema. Pode ser necessário entrar e começar a fazer backup das coisas e fazer perguntas mais amplas para que o cara se mexa. Além disso, ter a gerência fazendo perguntas dá peso e importância à atividade de compartilhamento de informações - é muito mais difícil recuar e evitar o gerenciamento. Geralmente, com algumas sessões produtivas em andamento, você pode sair do meio e dizer "vocês têm isso, não precisam de mim" e continuar com o próximo problema.

Outra chave é NÃO deixar o sujeito dominar o trabalho nas áreas em que ele precisa compartilhar conhecimento. Coloque outra pessoa encarregada do trabalho e deixe claro que é tarefa do acumulador de informações compartilhar o conhecimento. Se ele não puder compartilhar, talvez seja necessário ter uma conversa brutal, explicando que o compartilhamento de informações é um requisito para a equipe, não uma opção. Que ele está contribuindo para os problemas de agendamento da equipe, não ajudando outra pessoa a aprender.

bethlakshmi
fonte
9

Não tenho certeza se 'recusar' é geralmente a palavra certa, geralmente eles estão muito ocupados e não têm tempo livre (ou inclinação ou habilidades sociais) para dedicar muito tempo para explicar o óbvio (para eles). ) para os n00bs.

A solução positiva é fornecê-los com assistentes - quase como espalhar o trabalho pela equipe (mas acho que não há muita equipe se você tem veteranos que sabem tudo sobre o sistema e novos caras que não sabem). , dada essa configuração, não é de admirar que eles não desejem comunicar suas preciosas habilidades e serem substituídos por uma versão mais jovem e barata!) (você também não - imagine se o seu gerente veio até você e pediu para você comunicar tudo o que sabe para a nova equipe terceirizada ... hmm?)

Eu recomendo que o assistente trabalhe em uma parte do sistema e que, com o tempo, se torne um especialista nele, espera-se que o desenvolvedor experiente os ajude a fazer seu trabalho nessa pequena área. Todos nós já estivemos lá de qualquer maneira, "se você quiser saber como o X funciona, esqueça a documentação (obsoleta ou inexistente) e converse com Jim".

Dar a eles um assistente não apenas confirma sua posição como desenvolvedores experientes (o que são) e oferece a oportunidade de aliviar parte da carga de trabalho anterior, mas também difunde o conhecimento ao longo do tempo. Tornam-se mentores ou posições de “primeiro passo para liderar a equipe”, que devem tranquilizá-los de que seus empregos são seguros e que sua experiência é valorizada. Se você não pode fazer nada disso, está falhando como gerente.

Não se esqueça de que, se você tem algum tipo de sistema supercompleto (o que você tem, ou os novos caras devem ser capazes de descobrir por si mesmos), a transferência de conhecimento é um processo muito longo. Não há como alguém se sentar e levar alguém completamente à velocidade, na minha casa essa tarefa levaria 6 meses no mínimo, e mesmo assim .. diabos, ainda estou aprendendo coisas sobre o que o nosso produto faz e já estive aqui quase uma década!

gbjbaanb
fonte
3
@gbjbaanb - Obrigado pela resposta. Penso que parte do problema é que o acumulador é freqüentemente habilitado em codificação ou resolução de problemas, mas não habilitado em explicar, treinar ou documentar. Portanto, o tesouro se acumula sem querer. Não quis dizer "recusar" da maneira mais forte - talvez "resistir" teria sido melhor. Todos reconhecemos a necessidade de compartilhar conhecimento, mas um milhão e uma razões impedem que isso aconteça. Portanto, sua sugestão para um assistente pode funcionar. Um assistente ideal seria um desenvolvedor que estava obcecado com a documentação
sheikhjabootie
@Xcaliburp - Eu discordo, você implica que os gerentes / outros membros da equipe estão sempre interessados ​​em tudo isso "coisas complexas e difíceis". De fato, a maioria das pessoas não se importa com documentação, Wikis, apresentações. Obviamente, as espécies da "ordem da informação" o fazem. De alguma forma, eu me incluo nessa categoria, para mim eu documento muito. Ocasionalmente, eu também faço isso para outras pessoas, em pastas compartilhadas / Wiki etc. Mas geralmente ninguém está interessado nisso. ;) (Nem na minha documentação nem documentar coisas theirselves ...)
Philip
1
@Xcaliburp: boa sorte ao descobrir que 'dev quem ama a docco!' :)
gbjbaanb
1
@ Philip - quando você é um desenvolvedor júnior, tudo o que você quer fazer é codificar. Mas, à medida que você ganha a antiguidade e se torna um líder de equipe, percebe que a maioria dos sistemas precisa de muitas pessoas qualificadas para colaborar e criar uma solução que nenhuma pessoa sozinha pode fazer sozinha. Portanto, o melhor código não é mais o mais rápido nem o mais inteligente, mas o mais simples. Ajudar seus companheiros de equipe é a melhor maneira de criar um software incrível. Eu não amo escrever documentação, mas o pensamento de meu "nome" ser amaldiçoado por muitos anos, por ser o desenvolvedor que construiu essa grande bola de barro, é um incentivo suficiente para tentar se destacar nessa parte do trabalho :-)
sheikhjabootie
@Xcaliburp: Claro, mas você está me dizendo que gostaria de escrever toneladas de documentação que todos possam entender facilmente, mas ninguém leria, nem você? ;)
Philip
5

Torne a comunicação um compromisso para cada membro da equipe e avalie-a como parte da revisão anual.

Certifique-se de que a equipe seja reconhecida por realizações e não apenas por indivíduos e garanta que todos saibam que o sucesso da equipe é sua prioridade; penalize-os se impedirem que a equipe seja bem-sucedida.

Verifique se não há bloqueios na comunicação, verifique se existem processos e sistemas para escrever documentos e compartilhar informações; por exemplo, wikis, sites de compartilhamento, entregas programadas para documentos de design etc.

Steve
fonte
Tudo bem, mas não impede a acumulação de informações. O acumulador ainda pode prosperar em tal ambiente. E uma vez que alguém começa a acumular, é difícil penalizá-lo, pois possui as chaves do conhecimento valioso.
EdA-qa mort-ora-y
Depois, é uma questão de gerenciamento - todos os funcionários sabem que devem se comunicar, o "acumulador" será penalizado no momento da revisão (ou por qualquer processo que exista para o gerenciamento de carreira). Se você tiver outras sugestões, não hesite em adicioná-las.
21311 Steve Steve
4

Certifique-se de que todos os projetos tenham pelo menos dois programadores que possam trabalhar nele. Isso para garantir que você sempre tenha um backup quando alguém sair da empresa.

Também iniciamos um wiki que contém todas as informações do banco de dados. É uma maneira muito útil de acessar ou atualizar rapidamente as informações.

Carra
fonte
3

Se o "acumulador" realmente não está fazendo isso de propósito, mas de fato está fazendo isso devido a algo como falta de habilidades sociais, compromissos de tempo, etc. De qualquer forma, consiga um "assistente" ou programador júnior especificamente encarregado de facilitar a carga de trabalho ou ajudando a extrair o conhecimento. Deixe claro para ambas as partes que esse é o objetivo das novas pessoas e envolva o "acumulador" no processo de entrevista. A gerência precisa ajudar nisso e possibilitar que eles compartilhem seus conhecimentos. Esse é o objetivo do gerenciamento, remover obstáculos e possibilitar que os trabalhadores concluam o trabalho.

John Gaines Jr.
fonte
5
Esqueça o assistente júnior. Consiga uma pessoa experiente, inteligente e experiente para trabalhar com ele. Eles se tornam colegas no sentido da palavra e a pessoa nº 2 escreve a documentação. Lembre-se, recompense a força das pessoas, não castigue suas fraquezas.
Christopher Mahan
@Christopher - bem colocado. Já estive na situação de ser um "acumulador não intencional" e posso dizer, tentar torturar esse excesso de conhecimento específico com um júnior é uma tortura. Deve ser alguém experiente que possa pegá-lo e digeri-lo o mais facilmente possível.
Carson63000
3

De acordo com minha experiência, os acumuladores de informações podem ser classificados em dois tipos: aqueles que gostam de compartilhar seus conhecimentos e têm algum senso de gratificação por ajudarem abertamente os outros, como eu, e aqueles que não. Obviamente.

Agora, ambos os lados têm seus motivos, e aquele que gosta de compartilhar seu conhecimento raramente divulga tudo pelo mesmo motivo que aquele que não compartilha seu conhecimento não: eles estão tentando convencer as pessoas. eles melhor e, na minha opinião tendenciosa, eles estão corretos ao fazê-lo. (é claro, você também tem aqueles que não compartilham conhecimento apenas para se tornarem indispensáveis, e isso é pelos motivos errados, e eles devem ser eliminados, pois geralmente não são tão bons assim)

Afinal, eles tiveram que mergulhar profundamente nos mares arcanos e esotéricos, a fim de aprender o que sabem, geralmente através de pura experimentação, uma aplicação liberal de pensamento crítico, lampejos de intuição e insight e ritos místicos que envolvem vários tipos de gado de sacrifício, e eles saíram melhor por isso. A linha de pensamento geralmente é que, se as pessoas ao seu redor são muito preguiçosas ou não conseguem gerenciar o mesmo, elas nem deveriam estar fazendo o trabalho, e certamente não são dignas de seu conhecimento. Quando aqueles que os rodeiam passam pelas mesmas coisas que precisavam, então serão um programador melhor, porque terão aprendido a pensar bem e resolver problemas complexos e tudo mais.

É essencialmente forçar os outros a se tornarem melhores através de conflitos. Embora muita coisa seja pisada e expulsa, aqueles que passarem pela manopla serão inevitavelmente muito melhores do que teriam se ficasse melhor com a cooperação.

Agora, quanto a fazê-los compartilhar as informações: você não pode forçá-los a fazê-lo. Tentar forçá-los a fazer com que eles vejam você como ganancioso, preguiçoso ou muito estúpido para chegar lá por conta própria, e eles certamente não terão pena de você em nenhum desses casos. Se alguém mais alto tenta forçá-lo a fazê-lo, ele pode se tornar muito desagradável, concentrando toda sua inteligência considerável em frustrar o indivíduo, ou até mesmo desistir completamente, em vez de trair seus princípios, afinal, existem muitos lugares que poderiam usar suas habilidades e conhecimento.

Na verdade, existe apenas uma maneira de obter uma delas que não gosta de compartilhar seu conhecimento para compartilhar de bom grado: tornar-se digna. Normalmente, ter o conhecimento que eles não têm é suficiente (mas difícil de fazer). Quid pro quo e tudo isso. Caso contrário, compre duas cabras e mergulhe.

Fénix
fonte
@ Phoenix - diga aos caras para descobrirem eles mesmos e a jornada aprimorará suas habilidades? Eu acho que cada nuvem tem um forro de prata ;-) eu estaria um pouco em algum lugar de trabalho onde eu comecei a ajuda e apoio do cão come cão ...
sheikhjabootie
Uma equipe cooperativa como um todo provavelmente será melhor do que um único programador que é realmente bom. No entanto, são necessários apenas um ou dois programadores realmente bons para transformar uma boa equipe em uma ótima, mesmo que estejam simplesmente utilizando o que sabem e não o compartilhando. Aqueles que compartilham frequentemente omitem bits, o que levará a problemas que outros terão que resolver por conta própria. Dar tudo isso leva a um problema semelhante a aprender versus memorizar. Para realmente aprender algo, você deve entendê-lo em todas as suas complexidades, em vez de simplesmente executar de maneira mecânica, como os outros instruíram.
Phoenix
Além disso, eu estava pensando: também não é realmente "cachorro come cachorro", porque eles não estão tentando promover a competição entre os programadores, em vez disso, eles estão tentando promover a competição entre os programadores e o próprio conhecimento.
Phoenix
Na cultura tradicional aborígine australiana, eles não tinham escrita; portanto, tornavam as informações escassas e, portanto, valiosas. Somente os anciãos mais respeitados podiam confiar a responsabilidade de transmitir o aprendizado das eras. Aqueles que queriam informações 1) tinham que ser dignos e 2) tinham que pagar por isso. Isso funcionou bem por cerca de 30000 anos e, em seguida, surgiram alguns caras com a escrita e o problema de compartilhar informações perfeitamente foi resolvido. O que você descreve soa como a maneira aborígine que funciona - mas não seria ainda melhor se eles simplesmente escrevessem?
Sheikhjabootie 5/05
Acho que o que quero dizer é que não estamos falando de nos livrar dos bons programadores com todo o conhecimento, queremos mantê-los fazendo o bom trabalho que eles fazem, e também queremos que os outros programadores possam trabalhar efetivamente também. Entendo o que você quer dizer com a coisa "cachorro come cachorro". Você acha que a luta por informações de qualidade é benéfica a longo prazo. É apenas na minha experiência que os recrutas com qualquer tipo de talento ou paixão ficam tão frustrados com a dificuldade de fazer qualquer coisa sem o compartilhamento de informações que eles param rapidamente e vão trabalhar em algum lugar mais favorável.
Sheikhjabootie 5/05
2

Quem é o chefe? Onde isso termina? Você não precisa compartilhar informações. Você não precisa fornecer documentação. Continuamente não conseguem fazer as coisas a tempo. Não siga os padrões de codificação. Alguém responsável acha que isso é importante ou não. Deveria haver consequências. Eles estão basicamente roubando da empresa.

JeffO
fonte
2

As pessoas que jogam o "Eu tenho um jogo secreto" são as piores. Esses indivíduos tendem a ser inseguros e criar ou florescer no modo de crise .

Eu os faria documentar todas as alterações ou modificações que fizerem no sistema. Também os faria fornecer um post mortem para cada correção que eles desenvolvessem para incluir ...

  • o que aconteceu
  • porque aconteceu
  • como impedir que isso aconteça
  • quais outros sistemas são vulneráveis ​​ao mesmo bug

Eu também tornaria essa pessoa responsável por ...

  • desenvolvendo padrões de codificação
  • mantendo uma biblioteca de códigos
Michael Riley - também conhecido por Gunny
fonte
1

Depende muito do tipo de conhecimento envolvido; seja diretamente de código ou orientado a processos de negócios. Normalmente, o último está disponível em outras partes do negócio ... e pode ser adquirido.

Em segundo lugar, há um argumento para garantir que nenhum desenvolvedor passe toda a sua vida profissional em áreas específicas sem compartilhar, por assim dizer. Portanto, se você tem um gerente de linha responsável por distribuir o trabalho, vale a pena garantir que qualquer solicitação de mudança de negócios seja entregue sem que um desenvolvedor específico se torne a primeira linha de contato de um proprietário de processo de negócios ... Isso dificultará os esforços de um desenvolvedor para se tornar um guru.

tentador
fonte
-2

Seria no melhor interesse de ambas as partes se o acumulador de informações fosse encorajado a encontrar uma empresa com um tamanho menor ou mesmo a iniciar sua própria empresa? Talvez a pessoa prosperasse nesse tipo menor de ambiente. (Estou curioso para saber se alguém já tentou essa abordagem no mundo real.)

mg1075
fonte
Quem quer que tenha votado contra, seja gentil a ponto de explicar; ou talvez você também seja um acumulador de informações?
mg1075
1
Eu não sei o motivo do voto negativo, mas acho que o OP está mais preocupado com a equipe, e isso não parece fazer nada pela equipe, exceto remover o acumulador.
Zachary Yates
@ZacharyYates - entendido. Minha suposição implícita é que a ação que sugeri pode ajudar todas as partes envolvidas na situação, mesmo que isso signifique que o açambarcador deixe a equipe.
mg1075