Confluence 打造團隊知識庫：讓每個人都找得到需要的資訊

知識散落在 Email、Slack、Google Drive 的時代該結束了。這篇文章告訴你如何用 Confluence 建立一個真正有人用、有人維護的知識庫系統。

「那個 API 的文件在哪裡？」「上次那個功能的設計決策是什麼原因？」「新人入職需要申請哪些工具帳號？」 如果你的團隊每天都在重複問這些問題，說明你們的知識管理有問題。知識就在某個人的腦海裡、某封 Email 的附件、某個人桌面的 Word 文件，或是某個沒人記得的 Slack 頻道。Confluence 是目前最被廣泛使用的企業知識庫平台，但裝了 Confluence 不代表就有了知識庫。本文告訴你如何從零建立一個真正好用的 Confluence 知識庫。 為什麼大多數 Confluence 知識庫會失敗 知識庫失敗的原因通常不是工具問題，而是以下幾種情況： 內容過期沒人更新 ：產品功能改了，但文件還是 6 個月前的舊版本。讀者踩坑後失去信任，從此不再參考 Confluence。 結構混亂找不到東西 ：有 20 個 Space，每個 Space 的組織方式都不同，搜尋出來一堆結果不知道哪個才對。 只有少數人在寫 ：知識庫變成「那幾個認真的人」的額外工作，而不是整個組織的共同資產。 格式不一致品質參差 ：有些文件非常詳細，有些只有一句話，讀者無法預期文件的品質。 要建立真正好用的知識庫，你需要在「架構」、「流程」和「文化」三個面向下功夫。 1. 設計清晰的 Space 架構 Space 是 Confluence 的頂層組織單位。很多團隊犯的第一個錯誤是建立太多 Space。當你有 30 個 Space，每次要找資料都不知道應該去哪個 Space 找，搜尋就變成了唯一的入口。 對於 50 人以下的公司，建議的 Space 架構： Company Hub ：公司文化、政策、福利、組織架構 Engineering ：技術文件、架構決策、API 規格、Runbook Product ：產品路線圖、功能規格、用戶研究 Marketing ：行銷計畫、品牌指南、活動資料 People & HR ：入職流程、HR 政策、績效評估指南 對於 50-200 人的公司，可以在上面的基礎上，為重要的跨功能專案建立 Project Space，專案結束後 Archive 這個 Space。 Space 命名原則：使用清楚的功能性名稱（「Engineering」比「Tech」更清楚）、避免縮寫、在 Space 描述中說明這個 Space 存放什麼。 2. 建立頁面模板確保一致性 頁面模板是讓知識庫保持一致性的最重要工具。對於每種文件類型，建立對應的模板。 會議記錄模板 應包含：日期、參與者、議程（會前填寫）、討論摘要、決議事項、Action Items（含負責人、任務、到期日）。 技術規格（Tech Spec）模板 應包含： 狀態（DRAFT / IN REVIEW / APPROVED） 背景（Context）：為什麼需要做這件事 目標（Goals）：做完之後要達到什麼效果 技術方案：怎麼做，包含架構圖 不在範圍內（Out of Scope）：明確說明不做什麼 風險與考量：已知的風險和如何降低 時間表：各階段預計完成日期 架構決策記錄（ADR）模板 應包含：背景、決策、考慮過的方案、決策理由、後果、相關決策。 3. 建立「可信賴的文件」系統 讀者失去對知識庫信任的最大原因是：打開文件，發現內容和現實不符。解決方法是建立文件的「新鮮度」機制。 在每個頁面頂部插入「Status」巨集，清楚標示文件狀態： Up to Date ：內容是最新的，可信賴 In Review ：正在審核中，可參考但可能有變更 Outdated ：已過期，僅供參考，請向文件負責人確認最新資訊 Draft ：草稿，尚未正式發布 在 Page Properties 巨集中加入「下次審查日期」欄位，然後建立 Page Properties Report 自動列出即將到期的文件。建議的審查週期：技術文件每季審查，流程文件每半年審查，公司政策每年審查。 4. 降低寫文件的門檻 知識庫無法持續的最大原因不是沒有工具，而是「寫文件太麻煩了」。你需要讓貢獻知識變得和在 Slack 發訊息一樣自然。 策略一：「夠好就好」原則 明確告訴團隊：文件不需要完美，能解決問題的文件就是好文件。一頁只有幾個要點的粗糙文件，比一頁完整詳盡但從未寫出來的文件更有價值。 策略二：在工作流程中內嵌文件步驟 不要把「寫文件」當成工作之外的額外任務，而是把它內嵌到日常工作流程中：每個 Jira Story 完成時確認相關 Confluence 頁面已更新、每次 Retrospective 後把結論記錄到 Confluence、每次重要決策後立即建立 ADR。 策略三：設定「文件大使」角色 在每個部門指定 1-2 位「文件大使」，負責定期提醒團隊更新文件、幫助同事把知識轉化為文件、主持每季的「知識庫健康檢查」會議。