El conocimiento tácito es peligroso

El conocimiento tácito o “tribal” en los equipos de software plantea preguntas sobre qué se puede documentar de forma realista y qué solo puede aprenderse mediante experiencia y mentoría. Los comentaristas critican la confusión entre peculiaridades de procesos no documentadas y el verdadero conocimiento tácito (como el criterio de diseño o la intuición para depurar), advirtiendo que intentar formalizar por completo este último puede salir mal y debilitar a los expertos. Otros exploran cómo prácticas como una mejor documentación, canales internos públicos e incluso “oráculos” LLM específicos de la empresa podrían sacar a la luz conocimiento oculto, al tiempo que señalan los costes de seguridad, responsabilidad y mantenimiento de capturarlo todo.

Definición de conocimiento tácito frente a conocimiento tribal/no documentado

  • Muchos sostienen que el artículo usa mal “conocimiento tácito”, confundiéndolo con conocimiento “tribal” o simplemente no documentado.
  • En el hilo, el conocimiento tácito se describe como:
    • Habilidad/intuición que no puede capturarse por completo en documentos (por ejemplo, montar en bicicleta, el “gusto” por el código, instintos de depuración, habilidades de artesanía física).
    • Conocimiento que surge de la experiencia y el contexto, no solo de leer especificaciones.
  • Los hechos explícitos no documentados (por ejemplo, “la cuenta interna debe crearse antes que la cuenta externa”) se consideran documentables y distintos del conocimiento tácito.

Papel y límites de la documentación

  • La documentación es crucial para escalar, incorporar personas nuevas y reducir el “bus factor”, pero es costosa de crear y mantener y a menudo queda obsoleta.
  • La sobre-documentación y los intentos de “micro-documentar” todo pueden desmotivar a los expertos y ralentizar a las organizaciones.
  • Algunos ven la documentación como algo positivo para la carrera (“hazte reemplazable para crecer”); otros señalan culturas en las que compartir te vuelve prescindible.
  • Múltiples ejemplos: wikis que se vuelven desordenados, necesitan mantenimiento constante y tienden a ser escritos por una pequeña minoría.

Conocimiento tácito, experiencia y aprendizaje

  • El conocimiento tácito se ve como inevitable y central para la pericia; intentar eliminarlo se considera dañino.
  • La verdadera experiencia incluye saber qué regla práctica aplica en qué contexto; este mapeo es difícil de poner por escrito.
  • Se dice que muchas habilidades (matemáticas, música, diseño, depuración, patinaje artístico, etc.) requieren práctica y mentoría más allá de la documentación.

LLMs y oráculos de conocimiento

  • Algunos proponen “loremasters” de la empresa impulsados por LLMs, entrenados con chats, documentación y transcripciones de reuniones.
  • Otros son escépticos:
    • Los LLMs alucinan y no dicen de forma fiable “no lo sé”.
    • Los registros brutos de reuniones son ruidosos; aún se requiere contenido de alta calidad escrito por humanos.
  • Las preocupaciones de seguridad y responsabilidad son importantes: un solo modelo robado o acceso a la API podría exponer notas de reuniones, política interna y detalles de seguridad, y a los modelos les cuesta “olvidar” eventos sensibles.

Prácticas organizativas e incentivos

  • Prácticas sugeridas: canales públicos de Slack, “el miembro más reciente mantiene la documentación”, runbooks vinculados a las operaciones y abrir la información interna por defecto.
  • Algunos señalan marcos formales de gestión del conocimiento (p. ej., DIKW) y prácticas militares que combinan documentación, automatización y visión compartida.
  • Sentimiento general: gestionar de forma agresiva el conocimiento explícito no documentado; aceptar que la experiencia profunda siempre será en parte tácita.