磨人在客戶專案裡用 Slack 的共用頻道，留下需求、決策與上線通知的紀錄。共用頻道的價值，是把決定留在雙方都看得到的地方。這個價值以約定好的使用規則為前提。頻道也會打斷工作，磨人的做法同時顧及打斷的成本。
研究怎麼看軟體團隊使用共用頻道
Stray 等，2019 以個案研究檢視分散式專案使用 Slack 的情形。好處是透明度、團隊覺察與非正式溝通提升。挑戰包括語言問題、過度使用私訊，以及成員的活躍程度不平均。作者建議團隊自行約定工具的使用準則。這是單一專案的個案。
Lin 等，2016 是篇短文形式的初步研究，指出開發團隊把 Slack 用在個人、團隊與社群三種層次，部分情況下取代電子郵件。研究對象是開發團隊本身。
Storey 等，2017 對 1,449 位 GitHub 使用者做問卷，整理開發者認為工作必備的溝通管道，以及同時使用多種管道的挑戰。受訪者偏向開源與開發者社群。
磨人把頻道的使用方式寫成具體的規則。例如設計稿沒涵蓋的部分直接在頻道提出，回報一律貼在同一串。以下各節依專案階段說明這些規則。
共用頻道從專案初期建立，成員依階段加入
磨人在專案初期就建立共用頻道，之後依階段逐步邀請專案窗口、前端開發者與後端開發者加入。進入開發前，磨人把頻道改成僅受邀者可見。
前端開發者加入後，磨人立刻開放前端程式庫的權限，並提供關鍵設定 API 的說明。新成員一開始就拿到所需的資源。磨人請前端開發者決定分支規則，依功能劃分或依開發者劃分都可以。實際寫程式的人決定協作規則。
回報清單的欄位與狀態
頻道上的訊息回報會轉成回報清單上的項目，成為可追蹤的紀錄。清單有六個欄位。
| 欄位 | 填寫內容 |
|---|---|
| 名稱 | 以年月日加簡述開頭，利於排序與追溯 |
| 外部 | 標記回報是否來自客戶的第一線使用者 |
| 完成時間 | 更新正式站後填寫完成日 |
| 內部狀態 | 待處理、測試完成準備上正式、已完成、已取消、待檢查 |
| 負責人 | 磨人的工程人員 |
| 提出人 | 客戶的專案成員，或磨人自己 |
運作方式如下圖。提出人建立項目，負責人認領後在測試站修正，狀態改為測試完成準備上正式。更新正式站後，負責人標記已完成並填寫完成日。所有狀態變動都保留在清單上，提出人在清單上就看得出處理到哪一步，不必另外追問。
依磨人實際使用的回報清單整理。不做的項目標記已取消，需複查的標記待檢查。
專案開發階段的品質確認，用的是同樣的邏輯。專案成員使用後台時覺得不順的地方，直接新增到線上看板。每輪討論後，磨人把新增的優化項目同步到看板與設計稿，並在頻道貼出該輪清單，標明各項負責人。開發者處理完，把卡片移到待確認區，再請客戶的專案成員協助確認。每個回報都有人認領，處理完有確認動作。
上線之後，磨人同樣用回報清單接客戶的回報，這部分的服務內容見 長期維運與平台建置。週期檢查與維運報告見 上線後的例行維運，例會、回報清單與上線檢查的整體節奏見 年度專案的例會、回報清單與上線檢查。
異動與上線通知用條列逐項寫明
設計稿更新時，磨人把調整項目條列貼在頻道，例如選單項目、導覽列的字體與樣式、頁面內容，並預約時間向前端說明細節。設計稿有多個頁面時，磨人在頻道講明以元件總覽頁為準，請設計師把其餘頁面同步成同一版本。設計師在頻道確認更新。目的是避免前端看到不同版本的設計。
需要多端同時調整的異動，磨人用一則訊息逐項列出，每項標明由哪一端處理。必要時附圖與代碼對照表，例如頁面名稱對應的介面代碼。訊息預先點出可能被影響的既有功能，並寫明有遺漏請接著討論。工程端回覆確認影響範圍，原有流程不受影響，隨後更版。範例包括條款頁改名與合併、段落樣式調整，以及新增供使用者下載的檔案區塊。多端同時改動時不易漏項，事後也能追溯。
把多項異動寫進同一則訊息，也是在減少打斷。Mark 等，2008 的實驗發現，被打斷的工作在較短時間完成，品質沒有差異，人們靠加快速度補償，代價是更多壓力、挫折、時間壓力與投入的心力。實驗任務在實驗室進行。這項研究支持通知打斷有成本的說法。磨人把同一批異動集中成一則訊息，對方一次讀完。
每次部署前後，磨人在頻道標註客戶的專案窗口。部署前先說明預計完成的時間，完成後說明已更新，可以進行內容上架。客戶仍在編輯資料時，會回覆需要一段作業時間。部署與內容更新因此在頻道留下時間紀錄。
上線初期回報量大，需要單一入口與可預期的更新節奏。磨人把上線公告的貼文兼作集中回報處，客戶在正式站測到的問題，一律可以貼在這一串。磨人依影響程度分批更新，畫面與文字類問題先更新，其餘議題集中在後續的批次。每批更新的進度，以及是否併入正式站更新，磨人都在同一串回報。客戶持續在同一串補充截圖與文字說明，磨人逐項標記處理中或已處理。
有取捨的做法，把方案與代價寫在討論串
做法有取捨時，負責的工程師在討論串列出兩種方案與各自的代價。資料與介面的負責人表達傾向，產品端核可後才動工。尚未定案的項目，標明待細節會議確認後再改。
逐頁必填驗證是一例。一種方案由前端只檢查有無填寫，訊息統一。另一種方案另開介面做單頁驗證。必填欄位已經討論定案，改動的機率低，前端攔截較容易。缺點是日後異動需要前後端都改。產品端核可後採用前端攔截的方案，並更版。段落樣式也有同類的取捨，方案是換用編輯器套件或沿用純文字。
開發階段，磨人要求前端把設計稿沒涵蓋的部分直接在頻道提出，讓設計師與磨人同時知道，避免互相等待。共用樣式的下拉選項，可到元件頁查看。選項資料一開始就約定由後端 API 提供，選項有異動要告知後端，缺資料也可以直接在群裡確認。目的是縮短來回溝通的時間，日後維運時資料來源也明確。
Stray 等，2019 將過度使用私訊列為挑戰之一。問題寫在頻道，設計師、前端與磨人同時看得到，不必逐一私訊詢問。
需求、入口與會議紀錄的正本放在頻道之外
需求與待辦以追蹤卡片作為正本。客戶成員在卡片上申請更換帳號、留言反映問題，磨人在卡片上更新狀態，並在頻道回覆。頻道用來提醒與討論。卡片留下可追溯的處理狀態。客戶成員在卡片系統無法留言時，工程師先檢查是否為權限問題。
環境入口與進度集中在頻道內的共用畫布。磨人在頻道裡掛了兩份共用畫布，一份放正式與測試環境的前台與後台入口，另一份追蹤專案進度。磨人與客戶成員在專案期間持續更新。交接與追查時，兩份畫布就是單一正本。
例行會議的議題與紀錄，以頻道內的共享文件留存，依日期命名。客戶成員在會前貼出議題預告，磨人成員也會回頭在文件中補充。需要引用先前資料時，會把資料放進當次的會議紀錄，再通知磨人取用。需求與決議因此集中在可回查的地方，不會散在對話裡。
會議紀錄也貼在頻道，逐項標明負責人與待辦，例如確認資料內容、文件交接的日程。優先序較低的項目在紀錄中註明，由相關成員自行約時間討論。
- 頻道裡出現需要留存的內容
- 依內容的性質選定正本的位置
- 需求或待辦追蹤卡片磨人在卡片更新狀態，並在頻道回覆
- 環境入口與專案進度頻道內的共用畫布磨人與客戶成員持續更新
- 例行會議的議題與決議依日期命名的共享文件會前貼議題預告，磨人成員回頭補充
- 做法有取捨討論串列出方案與代價，核可後才動工
Stray 等，2019 建議團隊自行約定工具的使用準則。圖中的存放位置，就是磨人在專案裡採用的準則。每種內容集中在一個位置，查找與交接時有單一的依據。
共用頻道不適合的情況
- 雙方沒有固定查看頻道的人。訊息只會累積成未讀，決定沒有人確認。
- 專案只有單次交付，後續往來很少。電子郵件加一份清單就足夠。
- 客戶內部已有固定使用的溝通工具。再增加一個管道，會加重同時使用多種管道的負擔。這時回報清單與正本位置的規則仍可沿用，工具改成客戶既有的那一個。
開始前要準備什麼
磨人在專案開始前，與客戶逐項確認以下項目。
- 各階段加入頻道的成員名單與進場時機，以及進入開發前改成僅受邀者可見的時點。
- 客戶的專案窗口，負責在頻道回覆，部署前後也會標註這些窗口。
- 回報清單的六個欄位與五種內部狀態，雙方確認用字。
- 追蹤卡片、共用畫布與共享文件的存取權限，確認客戶成員能留言與更新。
- 頻道的使用規則，例如設計稿沒涵蓋的部分直接在頻道提出，回報貼在同一串，有取捨的做法在討論串列出方案與代價。
評估廠商的溝通與紀錄做法時，可對照 軟體外包廠商的評估表與簽約前查核項目。
磨人會依專案階段與目前使用的溝通管道，說明頻道、清單與正本位置的配置。需要時可以 聯絡磨人，討論專案的溝通規則與回報清單。
