※本文內容基於筆者個人經驗與觀點，不代表所屬組織或特定廠商的官方見解。此外，這裡介紹的方法不保證對所有組織都有效且安全。實際導入時，請根據貴公司的狀況、合約、法規、安全政策等進行判斷。

前言：最浪費的其實是「認知同步」這個問題 #

在本公司這種基礎架構、應用程式、儲存混雜的現場工作時，
經常會遇到這樣的情況。

• 「這個最後到底是根據什麼方針決定的？」

• 「那張工單進展到哪裡了？」

• 「這個設計，不知道是誰基於什麼前提思考的…」

比起實作時間，更多時間消耗在「認知同步」上的感覺，你有過嗎？

於是突然產生了一個想法，

「如果能把相關工程師的大腦和身體連結起來，作為集合體行動不是最強嗎？」

這已經是偏向科幻的發想了。
當然，在現實中透過 Brain Machine Interface (BMI) 將大腦物理連結還是相當遙遠的未來。

不過，如果結合工具、營運和文化，應該能接近「類似連結的狀態」吧？
因此，我們針對 10 人以下的團隊，思考了一個「類 BMI 團隊營運模型」。

目標團隊的條件 #

這次假設的團隊大致如下。

• 成員：10 人以內

• 角色：基礎架構、應用程式、儲存混雜（雲和地端都會接觸）

• 使用工具（範例）

  • GitHub

  • Slack

  • Notion

  • Teams / SharePoint（與其他部門或外部協作用）

  • Nextcloud（檔案共享等）

簡單來說，假設的是**「全員什麼都碰的全端型小團隊」**。

概念：在外部建立團隊的「集合大腦」 #

希望達成的狀態用一句話來說，

「減少只存在某人腦中的資訊」，
將其集中到團隊整體的「外部大腦」。

就是這樣。

代替 BMI，

• 工具（GitHub / Slack / Notion / 儀表板）

• 協定（如何流通資訊）

• 文化（如何行動）

組合這些要素，建立**「類似連結的狀態」**。

工具的角色分擔：將哪裡視為「大腦」 #

首先，為手邊的工具明確分配角色。

1. GitHub：任務、程式碼與決策的「中樞神經」 #

• Issue / Projects：任務管理（基礎架構與應用程式混合也可以）

• PR：程式碼與設定的變更點

• docs/adr：架構的「決策日誌」（ADR）

重點在於，

基礎架構與應用程式，首先全部放在 GitHub Issue 上

制定這樣的規則。
「將任務的入口統一在 GitHub」，就能讓認知的入口一致。

2. Slack：即時的「腦內聊天」 #

Slack 是用來共享對話與「現在腦中想法」的地方。

範例：頻道結構

• #dev-general：開發與基礎架構總覽

• #infra：網路、虛擬機基礎架構、儲存系統

• #alerts：監控與警報整合

• #daily-sync：每日「腦中想法」共享（後述）

• #random：閒聊

重要的是，

在 Slack 討論後如果產生「決定事項」，
必須記錄到 GitHub Issue / ADR / Notion

這個步驟很重要。
「討論完就結束」的話，會立刻被遺忘。

3. Notion：設計與知識庫的「長期記憶」 #

在 Notion 中，放置多次重複使用的知識與設計。

結構範例：

• 📚 Knowledge

  • 系統清單（URL、負責人、概要）

  • 常見流程（Runbook）

• 🧠 Architecture

  • 整體架構

  • 網路概要

  • 認證／權限的整體架構

• 📝 Meeting Notes

  • 定期會議的備忘錄

  • 各頁面最後加上「決定事項」區塊

• ✅ Playbooks

  • 障礙應對及定期維護程序

「同樣的說明重複3次以上就提升至 Notion」
這樣的簡易標準也是可行的。

4. Teams / SharePoint / Nextcloud：對外介面 & 倉庫 #

• Teams：與其他部門/客戶溝通使用(對外窗口)

• SharePoint / Nextcloud：文件與檔案的存放處

內部的「工程師思維」集中在 GitHub / Slack / Notion,
將其他工具定位為「與外部世界的連接點」,會更容易整理。

擬似BMI式「一天的流程」設計 #

早晨：團隊的「腦波同步」(約15分鐘) #

1. #daily-sync 各自發文 #

格式範例：

光是這樣,

• 誰在留意哪些事項

• 哪裡可能成為瓶頸

就能透過文字快速掌握。

2. 瀏覽儀表板 #

準備一頁彙整監控・CI・主要指標的儀表板,
由某人(也可輪流)在早上先瀏覽一遍,如有異常就在 Slack 發個訊息：

「DB延遲比昨天惡化。今天會一邊觀察一邊找原因」

光是這樣,就能避免「莫名的不安」擴散。

日間：任務著手〜完成的流程 #

任務開始時 #

1. 將 GitHub Projects 的卡片移至 Doing

2. 在 Issue 開頭寫下目前已知的背景資訊：

保留「上下文資訊包」，
之後任何人都能輕鬆追溯狀況。

遇到瓶頸時 #

• 在 Issue 的留言中寫下「做到哪裡」「卡在哪裡」

• 將該留言複製並貼到 #infra 或 #dev-general：

「作業記錄＋思考記錄」一起呈現，
其他成員更容易「連同思路一起共享」。

方針確定時 #

• 在 Issue 寫下結論

• 重要事項建立一份 ADR

• 在 Slack 貼上「已撰寫ADR」的連結

如此一來，
「一次討論達成的共識」就會成為團隊的長期記憶。

下班前：小型「大腦快照」（5分鐘） #

每個人要做的事很簡單。

• 在 Doing 的Issue中記下一行「明天要做的事」

• 有餘力的話在 #daily-sync 簡單補充「今天做了什麼」

隔天早上自己或成員能更容易重建狀況，
腦內脈絡的重新載入成本就會降低。

為了不忘記決策的「ADR」機制 #

討論時間最浪費的情況是，
**「又在說明之前已經決定過的事」**。

這時可以導入 ADR（Architecture Decision Record）。

• 在各儲存庫建立 docs/adr 目錄

• 只記錄「日後可能爭論／可能忘記的決策」也可以

檔案範例：docs/adr/0001-choose-proxmox-as-hypervisor.md

Slack 討論結束後，只要有人撰寫 ADR，
並在 #dev-general 貼上連結，效果就很顯著。

「為何選擇這個」，
會從個人腦內移至團隊的「外部大腦」的形象。

若要分階段導入 #

一次全部進行會很辛苦，
分階段進行會比較順利。

Phase 1（最初 2 週）：入口統一為一個 #

• 建立 GitHub Projects，
  試著建立新任務必定建立 Issue 的規則

• 在 Slack 建立 #daily-sync，試著每天發文一行也好

Phase 2（接下來 2〜4 週）：養成記錄決策的習慣 #

• 出現重要技術判斷時，至少撰寫一份 ADR

• 在 Notion 只建立以下 3 項：

  • 系統清單

  • Runbook

  • Meeting Notes

Phase 3：培養儀表板和 Playbook #

• 將監控、CI 的儀表板整合到一個畫面

• 將重複性作業以 Notion 的 Playbook 形式保存下來

總結：以「外部大腦」取代 BMI 的鍛鍊 #

本文介紹的擬似 BMI 模型,
簡單來說就是以下的概念。

• 將任務、決策、設計從特定人員的腦中移轉到 GitHub / Slack / Notion

• 在一天的開始和結束時,分享小型的「大腦快照」

• 重要決策以 ADR 形式記錄,避免重複相同討論

透過這樣的做法,

• 認知對齊會議的時間縮短

• 「只存在於某人腦中的前提」減少

• 整個團隊更容易作為一個「集體智慧」運作

雖然不知道真正以 BMI 直接連結大腦的時代是否會到來,
但我認為只要結合工具、營運和文化,
現在就足以接近「擬似連結狀態」。

如果有團隊也面臨類似的課題,
請務必嘗試看看,即使只實施部分內容也好。
一定能發現某些「認知對齊上的浪費」。