knowledge-management - software - knowledge management tools

Cuál es la mejor manera de recordar el conocimiento técnico en la organización (18)

¿Usamos una wiki de la compañía?
¿Qué tal si guarda los documentos técnicos como parte del control de código fuente y luego tiene enlaces a ellos desde varios archivos de origen (para comprender cómo funciona esto, vea el artículo ... en el directorio ...)

¿Cuáles son los pros y los contras de estos y otros métodos? ¿Alguna buena herramienta para este propósito?

Si recomienda una wiki, ¿qué wikis recomendaría utilizar? ¿interno? alojado? ¿gratis? ¿pagado?

Las personas son el contenedor de conocimiento más efectivo en su empresa. Y la forma más efectiva de transferir conocimiento es de personas a personas. Las Wiki y la documentación también son útiles, pero a menos que sus empleados sean excelentes redactores técnicos, la documentación escrita es una forma terrible de transferir todo, excepto el conocimiento más trivial. Los escritores tardan años en escribir un libro, por lo que no puede esperar que los desarrolladores escriban documentación de calidad en un par de horas.

La mejor manera de mantener el conocimiento en su organización es hacer que las personas trabajen juntas. Asegúrate de que nadie trabaje solo. Haga que la gente programe un par y revise el código de cada uno. Organiza sesiones técnicas, etc.

Si realmente desea almacenar el conocimiento en alguna parte, trate de enriquecer los datos. Facilite la adición de fotos de pizarras, etc. a la wiki. Otro problema con la documentación escrita es que la gente parece pensar que el texto abstracto prolijo es ''profesional''. Asegúrese de mantener la documentación breve, clara y al punto para que la gente realmente la lea.

Como alternativa a una wiki, considere usar SharePoint. Le permite manejar eventos (como reuniones), tareas y documentos. Funciona muy bien con el público no técnico, lo que puede permitir a los escritores técnicos y gerentes echar un vistazo a lo que está sucediendo. También es parte de Windows 2003, por lo que es posible que no necesite una licencia adicional.

En el lado negativo, casi puedo garantizar que habrá un luddite que te culpa por cada pequeña objeción de UI. Sin embargo, los de más arriba probablemente lo amarán.

Usamos una combinación de blog de proyecto y wiki.

Creo que las personas se sintieron un poco desanimadas por una wiki, que sintieron que necesitaban ingresar algunos párrafos para justificar la entrada, así que comenzamos un blog que es útil para capturar pequeñas cosas o cosas que suceden en tiempo real. , por ejemplo, ''Cambié la longitud del campo de la columna de 40 a 50'' o ''datos de la tabla de auditoría purgados anteriores a la semana pasada''.

Espero (espero) que algunas entradas de blog se conviertan en el material de origen para las entradas de wiki más largas a medida que avanza el proyecto.

Probablemente puedas echarle un vistazo a Associativy . Almacena fragmentos de conocimiento como nodos de un gráfico donde los bordes representan una conexión asociativa (en un sentido humano). El gráfico se puede buscar y explorar de múltiples maneras, dado un conjunto de términos de búsqueda, el software puede "pensar" sobre una asociación adecuada.

Soy de código abierto y se ejecuta en el CMS de Orchard , un proyecto de código abierto también.

Este fue un enchufe desvergonzado (Associativy es mi proyecto), lo siento.

Editar: acaba de reconocer la edad de esta pregunta ...

Creo que la herramienta que utilizas no es tan importante. Lo realmente importante es que todos los miembros de su equipo se interesan por un lado y un lugar por la documentación.

Puede usar una base de datos de wiki o notas o una aplicación de elaboración propia.

Personalmente prefiero que todas las cosas estén en un solo lugar. Entonces, para la documentación técnica, el sistema de control de fuente será el lugar correcto. Para la documentación, que es utilizada por no desarrolladores, el control de fuente es definitivamente el lugar equivocado. Para todos los documentos, tal vez un servidor de SharePoint es la herramienta que debe usar. Tiene algún tipo de control de versión y es accesible sin aplicaciones cliente especiales.

De hecho, he comenzado un proyecto paralelo que lo aborda. Todavía está en la fase de planificación, pero identifiqué algunas áreas donde el conocimiento técnico se mantiene en las organizaciones. Ahora bien, esto no se aplica a todas las organizaciones, pero cada organización usa al menos una de ellas.

Gente
Sitios web estáticos (Internet e Intranet)
Libros (una biblioteca de la compañía)
Libros (libros de un individuo)
Sitios web dinámicos (Internet e Intranet)
Bases de datos y repositorios

Exactamente cómo utiliza cada uno de estos es diferente, pero una clave es hacer que las personas utilicen sitios web estáticos y / o dinámicos para capturar información o, al menos, identificar dónde está en libros y repositorios. Si las personas no están alimentando las casas de conocimiento, entonces no importa qué tecnología uses. El conocimiento debe ser actual, preciso y profundo, o inútil, por lo que he podido reunir.

Otro concepto clave que es importante, como señaló Vinko Vrsalovic, es la capacidad de vincular los datos / información / conocimiento a su razonamiento. Una práctica común en el análisis de requisitos es la capacidad de rastrear el requisito hasta su origen. Lo mismo debería decirse para el conocimiento. Todos en la organización pueden saber todo en el mundo. Sin embargo, si nadie sabe POR QUÉ ese conocimiento es útil o DÓNDE / CUANDO usar ese conocimiento, se desperdicia.

Si me falta alguno, siéntete libre de editar esta publicación o responderla como comentario. Creo que esta pregunta ayudará a mis esfuerzos de proyecto.

EDITOR 1: Agregó a Vinko Vrsalovic que no se trata solo del conocimiento, sino de vincular los datos a los problemas de producción a los que se refiere el conocimiento.

El Wiki funciona bien, pero complementamos el Wiki con los screencasts de Ignite y Camtasia. Esto ahorra tiempo al representar la configuración, etc. Los screencasts son fáciles de hacer, rápidos, y no tiene que preocuparse si ha capturado los detalles correctos para su audiencia, ya que rebobinan / reproducen las secciones que necesitan revisar.

Hemos probado los artículos de la base de conocimiento y hace que las personas sean flojas: "No entiendo esta sección" significa que reescribirá un montón. Dé a una persona un screencast y ellos pueden hacer sus propias notas.

He usado ambos métodos en el pasado y he encontrado que el formato wiki es el más aceptado. El almacenamiento de documentos en el control de código fuente puede tener un impacto en la fusión de versiones (obviamente depende del software de control de origen en uso y las metodologías aplicadas). Lo mismo es cierto para las soluciones basadas en wiki, pero por alguna razón nunca pareció presentar un problema masivo en las implementaciones que he usado.

La capacidad de búsqueda de las principales wikis es otro factor importante para su éxito. Es mucho más fácil buscar un término de búsqueda en una wiki que encontrar una referencia a un documento en una pieza de código potencialmente no relacionada.

<2c />

Las wikis son buenas, pero una de sus mayores ventajas aún no se ha mencionado. Muy a menudo la persona que lo escribió no encuentra los defectos en la documentación, porque el autor no necesita ni lee la documentación. Los defectos se encuentran cuando el autor está de vacaciones o enfermo, y otra persona intenta seguir la documentación y parte de ella no funciona. Usando un Wiki, cualquier persona pobre que termine descubriendo el defecto en los documentos puede corregirlo de inmediato, en lugar de tener que enviar un correo electrónico al autor, donde es enterrado en los otros miles de correos electrónicos que el autor recibió mientras estaba de vacaciones, o tratando de recordar contar el autor después de que el autor regrese.

Además, asegúrese de que al menos dos personas sepan cómo hacer todo y mantenga los niveles de personal . Cuando alguien se va, puede ser muy tentador no reemplazarlos si ya tiene otras personas que pueden hacer todo lo que hicieron, pero si ahora tiene múltiples piezas de infraestructura o código que cada uno solo entiende por una persona, entonces usted es vulnerable . La transferencia de conocimiento de una persona a otra requiere tiempo y trabajo práctico. No es fácil, pero es infinitamente más fácil que tratar de aprender una infraestructura o base de código solo de documentos.

Lo más importante sobre la retención de conocimiento en una empresa, independientemente de la solución, es hacer que las personas utilicen el sistema. Los wikis son mis favoritos, pero sin la aplicación de la administración o los líderes de equipo, es difícil mantener ese nivel de conocimiento útil: la gente odia documentar lo que parece, especialmente cuando los hace fácilmente reemplazables.

Me gustan los wikis. Incluso los uso para mis propios proyectos de hobbies, documentando cómo solucioné problemas desagradables con los que no quiero tener que lidiar de nuevo, o manteniendo una lista de referencias a recursos relacionados.

Tener muchas personas que contribuyan a una wiki así es aún más poderoso, sin embargo, la posibilidad de discusión también es muy importante.

Si puede reunir el soporte, un medio social que tenga reputación (como este mismo sitio) puede funcionar extremadamente bien en una intranet. La gente necesita un poco de incentivo para alimentar la base de conocimiento.

Te daré algunos inconvenientes de Wiki, o donde tal vez se requiera algo más de reflexión:

Si el conocimiento / la documentación técnica se comparte con clientes u organizaciones que no tienen acceso a su Wiki
La documentación asociada con una versión particular del software a menudo vive mejor con la fuente asociada con el lanzamiento. A menudo Wiki contiene la información más actualizada pero puede ser difícil (dependiendo de la atención de los editores) mapear la documentación a versiones anteriores

Use una wiki, pero asegúrese de que alguien tenga la propiedad editorial de lo que entra. Esa persona debe garantizar que se cumplan los estándares de nomenclatura y la jerarquía de documentos. Es muy fácil para una wiki de la compañía convertirse en un caos extenso.

Yo recomendaría el MindTouch Deki . Es mucho más que una wiki, con integraciones en varias otras fuentes, incluida la capacidad de integrarla en fuentes de datos personalizadas en su organización.

Yo recomendaría usar una wiki. Funciona muy bien como fuente de documentación central y tiene control de revisión incorporado. También puede hacer referencia a los documentos en el código a través de las URL.

He visto que muchas discusiones de conocimiento suceden dentro del correo electrónico dentro de una organización. Este conocimiento permanece en el correo electrónico durante mucho tiempo y, finalmente, se pierde y no es accesible para otras personas que no formaron parte de la discusión original.

El uso de herramientas como http://grexit.com puede ayudarlo a trasladar estos conocimientos de su bandeja de entrada a un repositorio compartido de coomon dentro de su organización. Actualmente, esto solo funciona para las aplicaciones de Gooogle, pero vale la pena intentarlo.

Definitivamente una wiki. Usamos TWiki y hacemos uso de algunos complementos excelentes.

Editar: Olvidé agregar que le gustaría consultar las respuestas a esta pregunta sobre documentos y control de versiones.