知識分享的本質與組織運作框架

沒什麼組織、一些倏忽即逝有趣或不有趣的想法

• why people reject some new tools (noted from James’s notable saying in PyConJP’24):

  • Too advanced
  • Not my use-case
  • Too complicated

• 設計組織的運作框架的步驟

  • 釐清這個框架要完成的目標、核心的概念是什麼
  • 其次要釐清這個框架的組成要素，以及這些要素之間的關係
  • 蒐集相似框架的相關資訊，既有現成的運行框架、以及蒐集既有參與者的需求與動機
  • 根據參與者的不同及需求不同修正既有框架製作框架的變體
  • 透過實驗、測試、反饋來修正框架，並且持續維護框架

• 知識分享的組成要素

  • 角色 (Player)
    • Giver: 提供知識的人，具有知識並且願意分享知識的人，獲得表達能力、信任感、滿足感、名譽感、獲得反饋、建立關係的機會
    • Taker: 接收知識的人，具有學習意願並願意分享經驗、想法的人，獲得未知的知識、建立關係、訓練理解力的機會
    • 二角色其最重要的是分享這個行為本身，而非知識的內容，交流過程中的互動、反饋、理解才是知識分享的核心，亦是知識的產生之處
      • 知識本身未必是最重要的，交流的這個互動行為背後代表者更多的是信任、建立共同語言、建立關係、建立共同的價值觀等等，而後者是凝聚共識、建立文化的基礎
  • 內容 (Topic)
    • 顯性知識（Explicit Knowledge）：任何能夠被結構、非結構化的知識，例如文件、影片、書籍、課程等
    • 隱性知識（Tacit Knowledge）：無法被結構化難以紀錄的知識，例如技能、經驗、直覺、洞察力、思考方式等等
  • 管道 (Channel)
    • 知識管理系統：HackMD, Notion, Confluence, Wiki, etc.
    • 語言：文字、口語、文件
    • 媒介：書籍、網路、講座、研討會、網路社群、社交媒體、電視、電影、廣播等等

• 知識分享是一場賽局，需要分享者分享知識，聆聽者分享反饋，雙方都選擇分享的行為，才能達到共贏的局面，知識分享不是零和賽局而是變和賽局，但如果一方選擇不分享（「搭便車」），則可能導致另一方損失。

  • 知識分享的資訊不對稱問題：
    • 分享者可能無法知道聆聽者的需求，因此無法提供適當的知識
    • 分享者的表達能力可能不足以讓聆聽者理解以及提供反饋
    • 聆聽者可能無法理解分享者的知識
    • 聆聽者可能無法提供適當的反饋
    • 不明的分享管道可能導致知識無法傳遞

• 協調者可以做的事情（降低知識分享的門檻及減少資訊不對稱）

  • 提供知識分享的平台，公開聆聽者的需求，讓分享者知道，公開既有分享者的知識，讓聆聽者知道
  • 提供知識分享的規則，例如分享者應該分享什麼樣的知識，聆聽者應該如何提供反饋
  • 提供促進知識分享的環境如任何正式、非正式的活動，例如分享會、讀書會、研討會、講座等等滿足不同分享者、聆聽者的需求，如準備分享的心理壓力、分享內容的理解程度、分享內容的負擔。