-
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.
- 語言：文字、口語、文件
- 媒介：書籍、網路、講座、研討會、網路社群、社交媒體、電視、電影、廣播等等
-
知識分享是一場賽局，需要分享者分享知識，聆聽者分享反饋，雙方都選擇分享的行為，才能達到共贏的局面，知識分享不是零和賽局而是變和賽局，但如果一方選擇不分享（「搭便車」），則可能導致另一方損失。
- 知識分享的資訊不對稱問題：
- 分享者可能無法知道聆聽者的需求，因此無法提供適當的知識
- 分享者的表達能力可能不足以讓聆聽者理解以及提供反饋
- 聆聽者可能無法理解分享者的知識
- 聆聽者可能無法提供適當的反饋
- 不明的分享管道可能導致知識無法傳遞
-
協調者可以做的事情（降低知識分享的門檻及減少資訊不對稱）
- 提供知識分享的平台，公開聆聽者的需求，讓分享者知道，公開既有分享者的知識，讓聆聽者知道
- 提供知識分享的規則，例如分享者應該分享什麼樣的知識，聆聽者應該如何提供反饋
- 提供促進知識分享的環境如任何正式、非正式的活動，例如分享會、讀書會、研討會、講座等等滿足不同分享者、聆聽者的需求，如準備分享的心理壓力、分享內容的理解程度、分享內容的負擔。