¿Cómo lidias con un acaparador de información? [cerrado]

29

Todos debemos habernos topado con ellos: desarrolladores que han existido durante años y tienen un conocimiento de dominio fantástico y, sin embargo, no comparten ese conocimiento con su equipo.

El equipo necesita desesperadamente compartir el conocimiento, pero parece que no pueden sacarlo del acaparador.

¿De qué maneras los equipos han resuelto con éxito este problema?

— sheikhjabootie
fuente

2

¿La gerencia te respalda?

Un acumulador de información solo recopila información, el acaparamiento no significa que no compartirán. ¿Quizás quiera preguntar cómo tratar con una persona reservada, paranoica o protectora?

— asoundmove

en realidad no, un acaparador de información es, por definición, alguien que guarda información para sí mismos. por lo tanto, están protegiendo la información que ya poseen.

— Tipo anónimo

@Thorbjorn: sí. La gerencia puede ver el problema. Pero están nerviosos por actuar demasiado descaradamente.

— sheikhjabootie

2

@ Tipo anónimo: la pregunta es sobre cómo manejar los cuellos de botella de información que pueden ocurrir en un equipo de desarrollo y avanzar. Cuando lo escribí, asumí que todos los acumuladores estaban tratando de atrincherarse. De algunas de las publicaciones, está claro que este no es el caso. Y se han hecho algunas sugerencias muy prácticas para trabajar con acumuladores que carecen de las habilidades de comunicación para quitar el cuello de la botella. Esta perspectiva es importante para evitar un antagonismo indebido. Este no es un club que atesora y odia, solo quería saber cómo lidiar mejor con un problema de desarrollo común :-)

— sheikhjabootie

35

Eliminar la propiedad del código del equipo. Difundir la carga de trabajo. Hacer revisiones de código. Organice sesiones de transferencia de conocimiento, espere algunas sesiones y luego pídales que hagan una presentación sobre su área.

Por supuesto, es imperativo que si usted no es el gerente, cuente con el respaldo de su gerente, pero si todos los miembros de un equipo comparten información regularmente, hay tantas excusas que alguien puede encontrar para no hacer lo mismo. .

Además, su gerente debe sentarse con él y explicarle que esto no amenaza su trabajo. Porque por eso lo está haciendo.

Es bueno que el individuo no sea la fuente de todo conocimiento. Le libera para hacer otras cosas más interesantes.

— pdr
fuente

77

Dependiendo de dónde trabaje y lo que haga, esto podría amenazar su trabajo. Apuesto a que muchas personas que tenían trabajos altamente automatizables están aterrorizadas de que su gerencia lo descubra. La documentación es una forma para que las personas descubran cuánta potencia cerebral entra en un trabajo, y hace que sea mucho más fácil reemplazar a esa persona, voluntariamente o no.

— l0b0

1

@ l0b0 - Si una empresa tiene éxito, siempre hay algo más que hacer, otros proyectos en segundo plano. Espero que un gerente crea en la compañía lo suficiente como para venderla.

— pdr

@pdr: en este equipo, el equipo se esfuerza en proyectos de marcha de la muerte y, por lo tanto, el acumulador siempre está "demasiado ocupado" para ejecutar sesiones de entrega, producir documentos, etc. Intentamos cambiar su trabajo para ser exclusivamente un entrenador, pero Dirigiría qué hacer sin enseñar cómo o por qué. Se las arregló para dejarlos tanto en la oscuridad como antes. Su versión de la programación en pareja es que él lo hace todo mientras un joven se confunde. Causa problemas de retención; pero no podemos perder al acaparador. Quiero inspirarlo a ser un gran líder del equipo que apoya a sus compañeros pero parece miedo de pegarse el cuello hacia fuera ...

— sheikhjabootie

8

@Xcaliburp - nuevamente, si te estás enfocando en él, él se resistirá. Si está haciendo política de equipo, entonces solo puede aguantar tanto tiempo. Si se niega rotundamente, debe ser despedido. He estado en empresas que perdieron a alguien indispensable y ¿sabes qué? Sobrevivimos.

— pdr

9

Habitualmente, hacer algo perjudicial para su equipo debería ser una razón para perder su trabajo.

— JeffO

33

Creo que Gerald Weinberg se refería a este tipo exacto de persona cuando comentó en The Psychology of Computer Programming (parafraseado porque no tengo el libro delante de mí), si notas que un programador intenta hacerse indispensable, dispara él de inmediato. 25 años después, cuando volvió a publicar el libro, comentó que ningún otro consejo le había dado tantas gracias como este.

Entonces esa es una solución.

— btilly
fuente

1

Esa es una cita increíble, desearía haber leído este libro ya.

— Tipo anónimo

Es gracioso que digas esto ... hice que el CEO de nuestra compañía me dijera esto hoy y él es de Suiza (no de los Estados Unidos). Esto parece ser un sentimiento internacional de que si alguien está tratando de hacerse indispensable, entonces lo despide.

— Brian

1

Sería genial si pudiera votar más de una vez. Le daría al menos +20 por la cotización.

— Jacek Prucia

12

Déles lo que quieren: asígneles todo el trabajo de mantenimiento y las tareas que solo él / ella tiene el conocimiento para hacer.

No, no pueden hacer nuevos trabajos porque nadie más puede hacer estos otros trabajos de mantenimiento muy importantes.

Sí, los nuevos empleados están haciendo el trabajo divertido y jugando con los nuevos juguetes brillantes, pero debes hacer estas tareas muy difíciles, de alta prioridad y aburridas porque no saben nada de lo que haces.

A menos, por supuesto, que quieras mostrarle a uno de ellos cómo hacerlo ...

— jqa
fuente

1

Estoy de acuerdo con usted en principio, pero alguien a cargo debe hacer cumplir las reglas. Esto no se mantendrá.

— JeffO

2

En mi experiencia con gerentes, programadores y gerentes, 'hacer cumplir las reglas' es una buena teoría pero (menos problemas de recursos humanos) difícil. Con algunas personas, puede descubrir en 5 segundos que está tratando de empujar la cuerda húmeda cuesta arriba. Entonces, si quieren hacer algo de una manera particular, entonces los hago responsables de su decisión y les devuelvo todas sus excusas (pueden soñar con el suministro de excusas más sorprendente e incesante y me ahorra pensar refutaciones). Y el resto del equipo no es arrastrado hacia abajo. Cuando se dan cuenta de que se han metido en un agujero, comienzan a darse la vuelta.

— jqa

Veo esto como una solución agresiva muy pasiva. Creo que sería mucho más fácil despedir a la persona. Por supuesto, razone con ellos primero. Asegúrese de que sepan la importancia de la situación. Pero en su defecto, los suelta.

— ConditionRacer

11

Esto recuerda a este artículo de Rands in Repose.

Creo que necesitas descubrir por qué este tipo está acumulando información. La seguridad laboral (como el artículo sobre The Fez) es muy importante. Pero también lo es la inseguridad. O simplemente que le gusta este tipo de trabajo y lo quiere todo para sí mismo, o siente un intenso sentido de propiedad sobre un área en particular. O está demasiado comprometido y no ha visto una manera de hacer el tiempo.

Algunos de esos problemas pueden resolverse mediante trucos sin confrontación:

conseguirle al chico algunas tareas que amplíen sus horizontes y obligarlo a entregar algo de trabajo.
averiguar de dónde viene la inseguridad y trabajar en cualquier problema real que conduzca al acaparamiento de información.
Señale al tipo que quedarse demasiado atrapado en la rutina como el único poseedor de conocimiento significa que nunca estará libre de eso y su carrera estará estrechamente unida a la tecnología, y toda tecnología finalmente desaparecerá.
averiguar de dónde viene el exceso de compromiso y averiguar qué es lo más importante

También vale la pena participar en algunos intentos de solicitud de información: puede llevar dos hasta el tango, y es posible que no desee descartar la idea de que hay suficiente intimidación que los que hacen preguntas no están haciendo buenas preguntas, por lo tanto exacerbando el problema. Es posible que deba intervenir y comenzar a respaldar las cosas y hacer preguntas más amplias para que el tipo se mueva. Además, tener a la gerencia allí haciendo preguntas le da peso e importancia a la actividad de intercambio de información: es mucho más difícil retroceder y evitar la administración. Por lo general, con algunas sesiones productivas en marcha, puede salir del medio y decir "ustedes tienen esto, no me necesitan" y pasar al siguiente problema.

Otra clave es NO dejar que el chico domine el trabajo en las áreas donde necesita compartir conocimientos. Ponga a alguien más a cargo del trabajo y deje en claro que es el trabajo del acumulador de información compartir el conocimiento. Si él no puede compartir entonces, es posible que necesite tener una conversación brutal donde explique que compartir información es un requisito para el equipo, no una opción. Que está contribuyendo a los problemas de programación del equipo al no ayudar a otra persona a aprender.

— bethlakshmi
fuente

9

No estoy seguro de que "rechazar" sea a menudo la palabra correcta, generalmente están demasiado ocupados y no tienen el tiempo libre (o inclinación o habilidades sociales) para tomarse mucho tiempo libre para explicarles lo obvio (a ellos ) a los n00bs.

La solución positiva es proporcionarles asistentes, casi como difundir el trabajo en todo el equipo (pero supongo que no hay mucho equipo si tienes veteranos que saben todo sobre el sistema y nuevos tipos que no , dada esta configuración, ¡no es de extrañar que no quieran comunicar sus preciosas habilidades y ser reemplazados por una versión más joven y más barata! al nuevo equipo subcontratado ... ¿hmm?)

Recomiendo que el asistente trabaje en una parte del sistema, y se espera que se convierta en un experto en él con el tiempo, se espera que el desarrollador experimentado los ayude a hacer su trabajo en esa pequeña área. Todos hemos estado allí de todos modos, "si quieres saber cómo funciona X, olvida la documentación (obsoleta o inexistente) y habla con Jim".

Darles un asistente no solo confirma su posición como desarrolladores experimentados (que son), y les da la oportunidad de aliviar parte de su carga de trabajo, sino que también difundirá el conocimiento con el tiempo. Se convierten en mentores o en puestos de "primer paso para liderar el equipo" que deberían asegurarles que sus trabajos son seguros y que su experiencia es valorada. Si no puede hacer ninguna de esas cosas, está fallando como gerente.

No olvide que si tiene algún tipo de sistema supercomplejo (lo que tiene, o los nuevos muchachos deberían poder resolverlo por sí mismos), la transferencia de conocimiento es un proceso muy largo. No hay forma de que alguien pueda sentarse y poner a alguien completamente al día, en mi lugar tal tarea tomaría un mínimo de 6 meses, e incluso entonces ... diablos, todavía estoy aprendiendo cosas sobre lo que hace nuestro producto y he estado Aquí casi una década!

— gbjbaanb
fuente

3

@gbjbaanb - Gracias por la respuesta. Creo que parte del problema es que el acumulador a menudo es experto en codificación o resolución de problemas, pero no es experto en explicar, entrenar o documentar. Entonces, el tesoro se acumula involuntariamente. No quise decir "rechazar" de la manera fuerte, tal vez "resistir" hubiera sido mejor. Todos reconocemos la necesidad de compartir el conocimiento, pero luego un millón de razones impiden que suceda. Entonces su sugerencia para un asistente podría funcionar. Un asistente ideal sería un desarrollador obsesionado con la documentación

— Sheikhjabootie

@Xcaliburp - No estoy de acuerdo, implica que los gerentes / otros miembros del equipo siempre están interesados en todas estas "cosas complejas y difíciles". De hecho, a la mayoría de las personas no les importa la documentación, los wikis ni las presentaciones. Obviamente, la especie del "informador" lo hace. De alguna manera me considero en esta categoría, para mí mismo documente muchísimo. De vez en cuando también lo hago para otros, en carpetas compartidas / Wiki, etc. Pero generalmente a nadie le interesa eso. ;) (Ni en mi documentación ni en la documentación de ellos mismos ...)

— Philip

1

@Xcaliburp: ¡buena suerte al encontrar que 'dev que ama a docco!' :)

— gbjbaanb

1

@Philip: cuando eres un desarrollador junior, todo lo que quieres hacer es codificar. Pero a medida que gana antigüedad y se convierte en un líder de equipo, se da cuenta de que la mayoría de los sistemas necesitan mucha gente capacitada para colaborar y crear una solución que ninguna persona sola pueda hacer sola. Entonces, el mejor código ya no es el más rápido o el más inteligente, sino el más simple. Ayudar a tus compañeros de equipo es la mejor manera de crear un software increíble. No me encanta escribir documentación, pero la idea de que mi "nombre" sea maldecido en años por ser el desarrollador que construyó esta gran bola de barro es un incentivo suficiente para tratar de sobresalir en esa parte del trabajo :-)

— sheikhjabootie

@Xcaliburp: Claro, pero ¿me estás diciendo que te gustaría escribir toneladas de documentación que todos puedan entender fácilmente pero que nadie leería, ni siquiera tú? ;)

— Philip

5

Haga que la comunicación sea un compromiso para cada miembro del equipo y evalúelos en esto como parte de la revisión anual.

Asegúrese de que el equipo sea reconocido por sus logros y no solo por las personas, y asegúrese de que todas las personas sepan que el éxito del equipo es su prioridad, penalícelas si impiden que el equipo tenga éxito.

Asegúrese de que no haya bloques en la comunicación, asegúrese de que haya procesos y sistemas para escribir documentos y compartir información; por ejemplo, wikis, sitios sharepoint, entregables programados para documentos de diseño, etc.

— Steve
fuente

Todo bien, pero no impide el acaparamiento de información. El acumulador aún puede prosperar en ese entorno. Y una vez que alguien comienza a atesorar, es difícil penalizarlos, ya que tienen las llaves de un conocimiento valioso.

— edA-qa mort-ora-y

Entonces es un problema de gestión: todo el personal es consciente de que deben comunicarse, el "acumulador" será penalizado en el momento de la revisión (o por cualquier proceso que exista para la gestión de la carrera). Si tiene otras sugerencias, no dude en agregarlas.

— Steve

4

Asegúrese de que todos los proyectos tengan al menos dos programadores que puedan trabajar en él. Esto para asegurarse de que siempre tenga una copia de seguridad cuando alguien abandone la empresa.

También comenzamos un wiki que contiene toda la información de nuestra base de datos. Es una forma muy útil de acceder o actualizar rápidamente la información.

— Carra
fuente

3

Si el "acaparador" realmente no lo está haciendo a propósito, pero de hecho lo está haciendo debido a algo como falta de habilidades sociales, compromisos de tiempo, etc. Consíguele un "asistente" o programador junior específicamente encargado de facilitar la carga de trabajo o ayudar a extraer el conocimiento. Deje en claro a ambas partes que este es el propósito de las nuevas personas e involucre al "acaparador" en el proceso de la entrevista. La gerencia debe intervenir en esto y hacer posible que compartan sus conocimientos. Ese es el propósito de la administración, eliminar obstáculos y hacer posible que los trabajadores realicen su trabajo.

— John Gaines Jr.
fuente

55

Olvídate del asistente junior. Haga que una persona experimentada, inteligente y conocedora trabaje con él. Se convierten en colegas en el sentido de la palabra, y la persona # 2 escribe la documentación. Recuerde, recompense la fuerza de las personas, no castigue su debilidad.

— Christopher Mahan

@Christopher - bien dicho. He estado en la situación de ser un "acaparador involuntario", y puedo decirte que tratar de compartir este exceso de conocimiento específico con un joven es una tortura. Tiene que ser alguien experimentado que pueda recogerlo y digerirlo lo más fácilmente posible.

— Carson63000

3

En mi experiencia, los acumuladores de información pueden clasificarse en dos tipos: aquellos a quienes les gusta compartir sus conocimientos y obtener un sentido de satisfacción al ayudar abiertamente a otros, como yo, y aquellos que no lo hacen. Obviamente.

Ahora, ambas partes tienen sus razones, y la que le gusta compartir sus conocimientos rara vez lo dará todo por la misma razón que las personas que no comparten sus conocimientos no: están tratando de hacer que la gente esté cerca. ellos mejor, y en mi opinión sesgada, tienen razón al hacerlo. (por supuesto, también tiene aquellos que no comparten el conocimiento simplemente para hacerse indispensables también, y eso es por las razones equivocadas, y deberían eliminarse ya que, por lo general, no son tan buenos para comenzar)

Después de todo, tuvieron que profundizar en los mares arcanos y esotéricos para aprender lo que saben, generalmente a través de la experimentación pura, una aplicación liberal de pensamiento crítico, destellos de intuición y perspicacia, y ritos místicos que involucran varios tipos de ganado sacrificial, y salieron mejor por eso. La línea de pensamiento generalmente es que si las personas que los rodean son demasiado flojas o no pueden manejar lo mismo, entonces ni siquiera deberían estar haciendo el trabajo, y ciertamente no son dignas de su conocimiento. Cuando los que los rodean pasan por las mismas cosas que tenían que hacer, entonces saldrán como un mejor programador porque habrán aprendido a pensar bien y resolver problemas complejos y todo eso.

Esencialmente está obligando a otros a mejorar a través de la lucha. Si bien se pisoteará y expulsará a muchos, quienes logren superar el desafío inevitablemente serán mucho mejores de lo que hubieran sido si hubieran mejorado gracias a la cooperación.

Ahora, en cuanto a conseguir que compartan la información: no puede obligarlos a hacerlo. Intentar obligarlos a hacerlo hará que te vean como codicioso, perezoso o demasiado estúpido para llegar allí por tu cuenta, y ciertamente no van a tener lástima de ti en ninguno de esos casos. Si alguien superior intenta forzarlo a hacerlo, podría volverse muy desagradable, volcando toda su considerable inteligencia para frustrar al individuo, o incluso dejar de fumar en lugar de traicionar sus principios, después de todo, hay muchos lugares que podrían usar sus habilidades. y el conocimiento.

En realidad, solo hay una forma de obtener uno de estos que no le gusta compartir su conocimiento para compartirlo voluntariamente: ser digno de él. Por lo general, tener conocimiento de que no tienen es suficiente (pero difícil de hacer). Quid pro quo y todo eso. De lo contrario, compre un par de cabras y sumérjase.

— Fénix
fuente

@ Phoenix: ¿decirle a los muchachos que lo descubran ellos mismos y que el viaje perfeccionará sus habilidades? Supongo que no hay mal que por bien no venga ;-) sería bastante trabajo en algún lugar donde me dieron ayuda y el apoyo de perro come perro ...

— sheikhjabootie

Un equipo cooperativo en su conjunto probablemente será mejor que un solo programador que sea realmente bueno. Sin embargo, solo se necesitan uno o dos programadores realmente buenos para convertir un buen equipo en uno excelente, incluso si simplemente están utilizando lo que saben y no lo comparten. Quienes comparten a menudo omiten partes, lo que conducirá a problemas que otros tendrán que resolver por su cuenta. Regalarlo todo lleva a un problema similar al aprendizaje versus memorizar. Para aprender realmente algo, debes comprenderlo en todas sus complejidades, en lugar de simplemente realizarlo de memoria como otros han indicado.

— Phoenix

Además, estaba pensando: tampoco es realmente "perro come perro", porque no están tratando de fomentar la competencia entre los programadores individuales, sino que están tratando de fomentar la competencia entre los programadores y el conocimiento mismo.

— Phoenix

En la cultura aborigen australiana tradicional, no tenían escritura, por lo que hicieron que la información fuera escasa y por lo tanto valiosa. Solo a los ancianos más respetados se les podía confiar la responsabilidad de transmitir el aprendizaje de las edades. Aquellos que querían información 1) tenían que ser dignos de ella y 2) tenían que pagarla. Esto funcionó bien durante unos 30000 años y luego aparecieron algunos tipos con la escritura y se resolvió el problema de compartir información perfectamente. Lo que describe suena como la forma aborigen que funciona, pero ¿no sería aún mejor si lo escribieran?

— sheikhjabootie 05 de

Supongo que lo que quiero decir es que no estamos hablando de deshacernos de los buenos programadores con todo el conocimiento, queremos mantenerlos haciendo el buen trabajo que hacen, y también queremos que los otros programadores puedan trabajar efectivamente también. Veo a qué te refieres con lo del "perro come perro". Cree que la lucha por obtener información de calidad es beneficiosa a largo plazo. Según mi experiencia, los reclutas con cualquier tipo de talento o pasión se sienten tan frustrados con lo difícil que es hacer algo sin compartir información que renuncian bastante rápido y se van a trabajar a un lugar más solidario.

— sheikhjabootie 05 de

2

¿Quién es el jefe? Donde termina No tienes que compartir información. No tiene que proporcionar documentación. Continuamente fallas en hacer las cosas a tiempo. No sigas los estándares de codificación. O alguien a cargo piensa que esto es importante o no. Debería haber consecuencias. Básicamente están robando a la empresa.

— JeffO
fuente

2

Las personas que juegan al "Tengo un juego secreto" son lo peor. Estas personas tienden a ser inseguras y crean o florecen en modo de crisis .

Les haría documentar cada cambio o modificación que hagan al sistema. También les haría proporcionar una autopsia para cada arreglo que desarrollaron para incluir ...

que pasó
porqué sucedió
cómo evitar que suceda
¿Qué otros sistemas son vulnerables al mismo error?

También haría responsable a esta persona de ...

desarrollo de estándares de codificación
mantener una biblioteca de códigos

— Michael Riley - también conocido como Gunny
fuente

1

Mucho depende del tipo de conocimiento involucrado; ya sea directamente código o orientado a procesos de negocio. Normalmente, este último está disponible en otras partes del negocio ... y se puede adquirir.

En segundo lugar, existe un argumento para garantizar que ningún desarrollador pueda pasar toda su vida laboral en áreas específicas sin compartir, por así decirlo. Entonces, si tiene un gerente de línea que es responsable de repartir el trabajo, vale la pena hacer que se asegure de que cualquier solicitud de cambio comercial se envíe a través de él / ella sin que un desarrollador específico se convierta en la primera línea de contacto para el propietario de un proceso comercial ... Esto dificultará los esfuerzos de un desarrollador para convertirse en un gurú.

— temptar
fuente

-2

¿Sería lo mejor para ambas partes si se animara al acaparador de información a encontrar una empresa de menor tamaño o incluso a comenzar su propia empresa? Quizás la persona prosperaría en ese tipo de entorno más pequeño. (Tengo curiosidad por saber si alguien ha intentado este enfoque en el mundo real también).

— mg1075
fuente

Quien haya rechazado esto, sea tan cortés como para dar una razón; o tal vez también eres un acaparador de información?

— mg1075

1

No sé la razón del downvoter, pero creo que el OP está más preocupado por el equipo, y esto no parece hacer nada por el equipo, excepto eliminar al acumulador.

— Zachary Yates

@ZacharyYates - entendido. Mi suposición implícita es que la acción que sugerí podría, en última instancia, ayudar a todas las partes involucradas en la situación, incluso pensando que eso significaría que el acaparador abandonara el equipo.

— mg1075