Pregunta:
¿Cómo transfieren sus conocimientos las personas más ocupadas?
Reinstate Monica - Goodbye SE
2012-04-13 02:22:23 UTC
view on stackexchange narkive permalink

Recientemente, encuestamos a los usuarios de wiki de toda nuestra empresa y descubrimos que hay dos grandes grupos de usuarios:

  • personas con mucho conocimiento pero (que afirman no tienen) tiempo para documentar
  • personas con tiempo pero (que afirman tener) no tienen suficiente conocimiento que valga la pena documentar

Cada grupo cubierto ¡casi el 50% de los usuarios!

¿Cómo manejan esto sus empresas? Es decir, ¿cómo puede animar a las personas más ocupadas o con más conocimientos a compartir sus conocimientos?

PM.SE relacionado q: [¿Cómo alienta a los miembros del proyecto a documentar su trabajo para la transferencia al final del proyecto?] (http://pm.stackexchange.com/q/799/167)
Ocho respuestas:
#1
+26
Karl Bielefeldt
2012-04-13 02:43:06 UTC
view on stackexchange narkive permalink

Puede señalar a los poseedores de conocimientos que es probable que de todos modos estén pasando mucho tiempo siendo molestados por preguntas. Escribir una entrada en una wiki es una inversión a corto plazo que vale la pena a largo plazo. Si no les molestan las preguntas, probablemente no sea lo suficientemente importante como para documentarlo.

Además, los receptores de conocimiento son una mejor opción para escribir un artículo wiki de lo que piensas, porque entienden el punto de vista de alguien que necesita aprender el tema. También ayuda a organizar y solidificar sus pensamientos. Sería muy beneficioso que alguien con más tiempo escriba el artículo y lo publique el gurú para su revisión.

+1 por que el receptor lo escriba. A veces, un titular y un receptor entenderán la misma oración de manera diferente.
Acordó que el receptor lo escriba, pero que los poseedores del conocimiento / expertos lo revisen en dos frentes: Corrección e Completitud. Una buena documentación explica tanto el Cómo como el * Por qué *.
+1 Asumir que los poseedores de conocimientos también son buenos para documentar es una falacia. Sin mencionar un tiempo precioso y un buen karma que ahorraremos al poner a las personas adecuadas para el trabajo.
@voretaq7, en realidad, una de las grandes ventajas de un wiki es la edición. Continúe y publique lo que aprendió, marque las partes de las que no está seguro y deje que el SME o la * siguiente * persona que necesita saber esto desarrolle desde allí.
@MonicaCellio está de acuerdo: los wikis son excelentes recursos. Desafortunadamente, la edición de la comunidad también puede ser una desventaja cuando alguien edita información mal entendida / incorrecta y se olvida de marcarla como "incierta". En última instancia, un Wiki es tan bueno como las personas que lo revisan para verificar su corrección :-)
también: los receptores pueden escribir la parte "Q" del wiki, y los titulares pueden escribir la "A"
Encuentro que los wikis simplemente no se leen o editan lo suficiente como para que valga la pena el esfuerzo.Los he visto probar en múltiples trabajos, nunca he visto uno funcionar.
#2
+15
HLGEM
2012-04-13 03:33:59 UTC
view on stackexchange narkive permalink

Uno de nuestros líderes tecnológicos tiene una gran política, la tercera vez que recibe la misma pregunta, escribe la respuesta y la envía por correo electrónico a la persona que la pregunta y al wiki de conocimiento que hemos configurado. Como probablemente iba a escribir ese correo electrónico de todos modos, el único trabajo adicional es agregar la dirección de la Wiki.

Buena política general: si se lo han preguntado tres veces, es importante documentarlo. Como beneficio adicional, probablemente también lo haya pensado lo suficiente como para tener una respuesta buena y coherente para convertirla en documentación oficial. (Esta es también la regla que utilizo para automatizar tareas: la tercera vez que debe hacerse, debe automatizarse)
@voretaq7, Pensé que la parte de conectar el Wiki a un correo electrónico para revisar los temas del wiki fue inspirada por mí mismo. Es mucho más fácil documentar el conocimiento cuando todo lo que tiene que hacer es agregar otra dirección de correo electrónico a un correo electrónico que iba a escribir de todos modos.
¿Por qué esperar tres veces? Si alguien ha hecho la pregunta, lo más probable es que alguien más lo haga, así que documente y envíele por correo electrónico un enlace a los documentos actualizados. Scott Hanselman habla sobre la idea de conservar las pulsaciones de teclas en su blog aquí: http://www.hanselman.com/blog/DoTheyDeserveTheGiftOfYourKeystrokes.aspx
@ridecar2 No soy un experto, pero diría la misma razón por la que espero hasta la tercera vez para automatizar una tarea: a veces, hacerlo usted mismo es la solución más rápida / mejor si solo va a suceder una vez, y a menudo no lo hace. sé que va a ser algo repetitivo la primera vez. Por tercera vez, por lo general, se está acercando a un punto de inflexión de costo-beneficio en el que es obvio que la tarea seguirá apareciendo y el trabajo para documentar o automatizar definitivamente dará sus frutos a largo plazo.
No hay ningún costo adicional por hacer una publicación de blog o enviar un correo electrónico, así que ¿por qué no publicar la publicación de blog directamente? Estoy de acuerdo con la automatización de tareas en las que configurar eso es difícil, aunque eso no es lo que estaba hablando.
#3
+6
Atif
2012-04-13 02:41:21 UTC
view on stackexchange narkive permalink

Sugiero grabar capturas de pantalla de unos 45 minutos. Reúna a todos y el presentador hace un screencast y transfiere el conocimiento. Es más fácil y efectivo mostrar cómo hacer algo, luego solo la documentación escrita (que también puede incluir tiempo adicional para formatear, etc.)

En un lugar donde solía trabajar , tenían un "Lunch n'learn" semanal o mensual. Un chico almuerza temprano y hace una presentación para el equipo mientras comen. Esto podría funcionar si las personas tienen poco tiempo.

+1 ¡gran idea! Teníamos una idea similar y la empresa proporcionaría un almuerzo para fomentar la participación.
Comer y aprender es una práctica horrible.Si es lo suficientemente importante como para entrenar, debe hacerlo cuando esté en el reloj, no durante un descanso. La hora del almuerzo NUNCA debe incluir el trabajo.
@HLGEM - Soy un * ENORME * creyente en Lunch & Learns.Sin embargo, nunca se contaron como tiempo de descanso cuando estuve involucrado. También creo que el experto en la materia en un área en particular debe * NO * ser el que realiza la presentación.La mejor práctica que he visto es poner a empleados intermedios y junior a cargo de preparar las presentaciones.Lo abordan con menos suposiciones y lo hacen más accesible.y cuando se están preparando para ello, lo aprenden.
No estoy en contra de este tipo de formación, solo que nunca se debe realizar en el almuerzo, que normalmente no es tiempo remunerado y no pertenece a la empresa.Es tan malo como pedirme que entrene después de la cena.Hay una buena razón por la cual las pausas para el almuerzo son obligatorias legalmente en muchas jurisdicciones.
#4
+6
Mark Booth
2012-04-17 19:14:11 UTC
view on stackexchange narkive permalink

La mejor manera de transferir conocimiento es que las personas que necesitan el conocimiento trabajen con aquellos que tienen el conocimiento.

Si bien es posible que las personas informadas no tengan el tiempo para trabajar para documentar sus conocimientos por sí mismos, es posible que ya estén dedicando parte de su tiempo a explicar a los demás qué hacer y cómo hacerlo.

Incluso si las personas informadas tuvieran tiempo para escribir sus conocimientos, No es necesariamente el caso de que la documentación que produjeron sea de utilidad para las personas menos informadas. Es sorprendentemente fácil perder información importante ' obvia ' cuando se trata de impartir conocimiento.

Al hacer que la transferencia de conocimiento sea más explícita y cooperativa, y hacer que los usuarios de esa redacte la documentación para que puedan entenderla, usted podría aliviar la carga de las personas informadas y obtener más información transferida.

Si las personas informadas son realmente presionado por el tiempo, podría pedir a las personas que necesitan ese conocimiento que escriban lo que entienden ahora , y luego hacer que las personas con conocimientos revisen y corrijan cualquier malentendido. Esto podría acelerar sustancialmente las cosas y también podría ayudar a identificar áreas donde falta el conocimiento.


Como ejemplo de esto, trabajo en software científico. Ni yo ni los científicos de las instalaciones con los que trabajo podríamos, por sí solos, documentar gran parte del software que escribo. Podría explicar qué hace mi software e incluso por qué lo hace de esa manera, pero son los científicos de las instalaciones los que necesitan escribir documentación sobre por qué y cómo deben usarlo los científicos visitantes.

De hecho, esta es exactamente una de las soluciones que consideramos; es similar a la idea del * aprendizaje *. Además, el aprendiz (que probablemente tiene más tiempo) puede documentar lo que ha aprendido.
#5
+5
voretaq7
2012-04-13 03:20:54 UTC
view on stackexchange narkive permalink

Mi sugerencia es presupuestar el tiempo de documentación en cada proyecto y convertirlo en parte integrante de lo que haces. Si no ha estado haciendo eso todo el tiempo, probablemente necesite programar "Días de documentación" para comenzar las cosas (por ejemplo, digamos que todos los viernes después del almuerzo, los que tienen el conocimiento se liberan de todos los demás proyectos y solo trabajan en la redacción de documentación). / p>

Puede ser difícil introducir la cultura de la documentación en una empresa cuando nunca ha sido parte de la forma en que se hacían las cosas antes, pero las recompensas son evidentes cuando puede contratar a una nueva persona y ponerla al día y Trabajar de forma independiente en una semana: por ejemplo, el proyecto PostgreSQL tiene una sólida cultura de mantener una excelente documentación. Su manual es mejor que algunos productos comerciales.

En principio, estoy de acuerdo, pero he visto muchas veces que se ha omitido la documentación debido a un pensamiento a corto plazo con una fecha límite del proyecto.
@Wikis Mala cultura corporativa en mi humilde opinión. La documentación es parte del producto (en mi caso, literalmente: los estándares internacionales y las regulaciones federales lo exigen para los fabricantes de dispositivos médicos, por lo que no tengo que discutir demasiado al respecto. Tengo suerte :-)
#6
+4
Karlson
2012-04-13 02:33:21 UTC
view on stackexchange narkive permalink

Existe una tendencia desafortunada en mi experiencia en lo que respecta a la transferencia de conocimientos y es la falta de interés del receptor . Podría tener a la persona dispuesta a hacer el volcado de cerebros a otra persona, pero si no hay interés en recibirlo, ¿por qué el experto se tomaría el tiempo?

Cuando me estaba yendo varios lugares donde trabajaba me pidieron que hiciera esto porque era una de las pocas personas que entendía los sistemas que estaba apoyando, pero cuando me asignaron a alguien para esta tarea, pude ver en su comportamiento que esto les molestaba y no tenía ningún interés en ello. Así que mi motivación para hacer la transferencia de conocimientos se redujo básicamente a nada.

Así que lo único que puedo sugerir sobre el tema es asegurarme de que la persona que recibe el conocimiento esté realmente interesada en el tema. La audiencia cautiva que hace preguntas hace maravillas en la motivación del orador.

+1 - Como una de las "personas más ocupadas", a menudo encuentro que es difícil conseguir tiempo de * todos los demás * para capacitarlos adecuadamente.
+1 - @voretaq7 - Ha habido muchas ocasiones en las que les he sugerido a otros que podría explicarles por qué o cómo hice algo y les dije que no creían que era necesario. Entonces, tal vez parte del problema sea tener receptores de conocimiento dispuestos.
@Giliane Suena como problemas separados pero estrechamente relacionados que conducen al mismo fin: en mi caso, los receptores del conocimiento en realidad * querían * aprender, pero estaban realmente demasiado ocupados cuando tenía tiempo para enseñar o sus supervisores se negaban a dejarlos aprender. tiempo de inactividad para la capacitación porque el supervisor no vio el valor.
#7
+4
Tangurena
2012-04-13 04:59:50 UTC
view on stackexchange narkive permalink

Siempre trato de configurar una wiki para documentar cosas. Los wikis son simples y fomentan la adición de fragmentos con el paso del tiempo. Con los sistemas de documentación formales, el papel en blanco parece abrumador para los usuarios y, como resultado, solo se llena cuando se les pone un arma en la cabeza. Por lo general, camino con un cuaderno e ingreso cosas en la wiki para que se puedan ubicar fácilmente; de ​​esta manera, las tareas anuales se pueden repetir correctamente en lugar de tener que redescubrir cómo se suponía que debían suceder.

Un jefe anterior solo estaba dispuesto a permitir "documentos completos y completos" que nunca se hicieron. Prohibió los wikis porque creía que fomentaban el pensamiento laxo y la documentación deficiente. Dado que los "documentos completos y completos" anteriores tenían más de 5 años en el momento en que me fui, no le importaba comprender que sus deseos estaban en oposición directa con la forma en que trabajaba su personal.

Solo en la más extrema emergencia cuando una persona crítica se fue, hizo y grabó webcasts de caminar a través del código que solo él entendía. Esta fue una de las pocas veces que cuando un empleado notificó, transfirió conocimientos, en lugar de trabajar en cosas hasta el día en que se fue.

#8
+2
Hi pals
2012-04-13 04:06:32 UTC
view on stackexchange narkive permalink

Este es realmente un problema de política, no de motivación. Los empleados con conocimientos críticos deben tener la oportunidad de documentarlo y debe ser obligatorio. Si no proporcionan suficiente documentación y sus supervisores les han dado suficiente tiempo "libre" para hacerlo, deben ser disciplinados.

No importa cuánto sepa o pueda lograr una persona, si es el único que tiene ese conocimiento, entonces es una responsabilidad. La documentación no debería ser opcional.

Creo que la "disciplina" es un [probablemente] mal enfoque, siempre que los empleados se mantengan productivos, penalizarlos solo los alentará a irse, lo que frustrará el propósito. En lugar de refuerzo negativo, utilice refuerzo positivo, alguna forma de incentivo / beneficio para proporcionar documentación.


Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...