本案從起案、舊系統功能盤點、需求訪談、規格分析、功能規格撰寫、會議記錄、技術文件等大小資訊，統一收錄於 ADO 專案下的 Wiki，藉此知識不再靠「問人」就能運作。很多流程、工具、系統設定都靠口耳相傳，一旦關鍵人物請假或離職，就會陷入「沒人知道怎麼做」的恐慌。再來是養成「寫下來」的好習慣，減少重複解釋、節省溝通成本。一件事情講一次、寫一次，就能傳一百次。

團隊成員不需要一再詢問同樣問題，只要丟出知識庫連結就好。初期因成員加入時間不一，因此提問很正常，以下是初期常有的對話：
A 成員：「請問你們有遇過後端站台沒辦法啟動服務的問題嗎？」
B 成員：「我遇過，你等等喔」
過不到一分鐘後：
B 成員：「在這裡：http:wiki.xxxxxx」
A 成員：「OK了~感謝」

隨著時間演進，你會發現對話內容會演變成：

成員 A：「@ALL 我剛剛遇到了import 元件後畫面無法顯示，問題已經排除，所以新增了一篇wiki記錄下來，請參考此篇(連結)。」
成員 C：「@ALL 這個問題還可以使用另個方式替代，因此我補充了上去了，大家可以再參考看看。」

大家已經習慣有問題先去尋找知識庫，即便遇到沒有記錄的也沒關係，仍然「先寫下來」再說，並進一步累積組織的集體智慧。每一段經驗、每一個踩過的坑，都是資產。透過記錄錯誤、復盤、流程優化，知識庫會隨著時間越來越強大。

知識共享，鼓勵團隊學習分享文化
建立知識分享的正向循環，鼓勵每位成員都能「寫下來」，讓知識不再藏在腦中，而是變成團隊可用的資源。

本專案實際跑將進4個月後累積下來的豐碩成果

那透過 OneDrive 或 Google Drive 共編一份，Word 或是 Excel 也能達成嗎？ 我最近一次被問這個問題是在我寫這篇的一週前，一位來自某 PMO 辦公室的 PM。兩者的目的性是完全不同的：過去共編文件都是以「文件」為導向，討論為重，臨時性、草稿、會議記錄、需求討論快速紀錄內容作為資訊的「傳達」，而非「傳承」。Wiki 則是以「頁面」導向，目的在於長期知識整理、結構化管理，可有樹狀架構、清楚目錄與連結關聯。

舉個簡單的例子，資訊單位接受需求時，需要進行需求訪談，訪談結束後雙方落款留存一份會議紀錄，透過 doc 文件方式進行保存。而 Wiki 則是為了保留「為何需求會是這樣」的結論，將知識傳承給其他團隊成員知曉，因此改以「頁面」與文字的模式，便於查找與搜索。
此外，ADO上的Wiki 我特別鍾愛它可與專案中的工作項、甚至 PR 資訊做勾稽，這意味著，我們可以有更多軌跡可循，更多關聯可以查看：

除了 Wiki 外，專案的 Repo 中的 README 也是很好的專案知識傳授的地方，但目的性不太相同，主要輔助開發者能夠快速獲取 source code 並融入開發作業中。最需要知道的是「怎麼跑起來」，包含安裝依賴、執行方式、環境設定。

協作開發的關鍵時刻：文件、工具都齊了，為何還是得面對面談？

有了 DevOps、工作項、與強大的知識庫就好了嗎？不，溝通這件事，有時候仍然得「本人親自解決」，簡單而暴力地去破解。即便是依據規格開發，也會需要有「面對面」討論的時候。某次我獲得了一個新的 User Story 開發任務，核心內容是希望透過排程以固定頻率去外部 API 取得資料，並回寫至系統 Table 內。由於我剛好是首個被分派到排程類的開發者，此時我心中已浮現一個念頭：「我可能需要調整原本開發的專案結構，好讓排程能減少重工並將共用最大化」，可是對於實際該怎麼實作，我其實毫無頭緒。

當下便立刻無禮地打斷了戰友山姆進行討論，說明我的需求原意與希望達到的目的。我們花了大約 3 小時，在電腦端開始開分支進行結構調整的實驗。完成實驗後，發 PR 併入。下一秒，山姆即刻於開發群組內公告：「@ALL 我和 Lin 將所有 Module 與 DTO 往 XXX 層搬了，請大家可以的話先 Fetch 一下，有問題請立刻舉手。」

殊難想像這類需要調整專案結構性的問題，僅是透過發工作任務給山姆，光是在上面確認我的目的與用意的討論串就要花時間。而他理解我的目的之後給出的建議呢？是他做，還是我去執行呢？不論是誰，都沒有面對面共同參與實作的共感。因為兩人同時實驗調整架構的過程中，我們不斷持續確認雙方是否 on the same page：我確認山姆是否理解我的需求並朝我想要的結果，山姆確認我是否完全理解並支持他提出的方案。

另外還有一個去年有趣的案子，對方是新創公司，因此大部分工程師都是遠端工作模式，初期的需求訪談大多以線上進行。但對方並不會因為是線上會議而馬虎，反而提供了很多系統雛型建議，每次都有近 100 頁的簡報提案。幾次開會下來，需求單位卻不買單，且多個需求窗口一致認為廠商抓不到核心需求，但需求單位也說不上來到底缺了什麼。

最後團隊決議改以實地會議、面對面討論。後來的每次需求訪談僅透過最多 10 張簡報完成整個專案的需求訪談。總結以上故事，在面臨以下情況時，強烈建議面對面直接溝通，會更加快速：

• 需求釐清階段
• 設計與技術決策
• 衝突處理或任務協調

不是每件事都要當面談，但關鍵的事要有機會『直球對決』。如果可以的話，建立每天 5~10 分鐘的站立會議，也會是很好的同步方式。

Ending Remarks

我們學到的不是只有「寫下來」這件事，而是建立一種能持續演進的團隊文化：遇到問題先找知識庫、沒有就自己寫下來、遇到關鍵挑戰則直球對決。當知識能共享、對話能即時，團隊的智慧才會不斷累積並轉化為真正的組織資產。