前言

既然是一個團隊，自然少不了溝通的過程，但在一問一答的過程中，時間就緩緩消逝。

有些事情只說一次還可以，但很多時候都是類似的東西頻繁出現，比如：

• 程式碼不要把 console.log 給 commit 上來
• 每天都要跟主管 stand-up meeting 匯報進度
• 我是新人，我該怎麼安裝環境？

只有一個人問就算了，如果同一個問題，每個成員都問一次，那團隊將會付出龐大的溝通成本上。

難題

Code Review

無論是團隊主管或其他資深同仁，在幫其他成員 code review 時，往往有些地方需要溝通：

• 留下一些比較大方向，需要細節說明的 comment

  這一行不適合這樣寫，建議改一下

• 不斷重複遇到很基本的疏忽問題

  程式碼不要把 console.log 給 commit 上來

• 有一定的 pattern 需要遵守

  請比照 XXX 的寫法

這類的說明一次兩次還 OK，但時間久了如果不斷重複，說明起來也是很大的成本。

Sync 進度

主管想要知道每個成員目前的工作進度，往往需要安排每天早上一個時段，團隊所有人一起來個 stand-up meeting。

雖然時間不長，但這個時段前後就被鎖死，無法安排其他會議，而更重要的是，很多時候比較像是，主管自己想要確認每個人的進度，有沒有遇到困難，今天預計完成進度等，而不是所有人都需要知道。

於是就變成，許多成員每天都被迫來開了一個 15 分鐘的會議，但其實只需要講 2 分鐘的話，其他時間都在放空。

知識管理

初來乍到的新人，往往會有許多問題：

環境怎麼裝？程式碼有什麼規範？更版時間是什麼時候？

即便是老鳥，也會有許多要問：

這個問題上次那個誰是不是有解過？

然後就會許多人跳出來解答，但有時候又不是每個人想得都一樣，變得七嘴八舌，最後花費大量時間在討論上。

策略

最終的目標就是：

同事之間一句話都不用說，就可以完成一天的工作

Code Review

與成員約定一套 code review 的準則，比如：

• 使用 Conventional Commits，並根據修改內容分拆多次小 commit，讓 reviewer 可以快速掌握脈絡
• 使用 Conventional Comments 提供更多標準化的訊息給成員
• 使用 eslint、husky、SonarQube 等工具，在 reviewer 看到 code 之前就確保程式碼沒有低級錯誤，並符合規範

另外，制定 coding guideline 或許也是個好辦法，可以讓減少許多「這樣做好像也可以」的模糊溝通。

Sync 進度

使用 ticket 管理工具如 Trello、Asana 或 Jira，協助追蹤任務、進度和工作分配，比如：

• 將新的任務分配給成員，即自動寄信給該成員，不用人工通知
• 請成員確實更新自己的卡片狀態，只要看他的卡片牆，就能夠知道目前哪些已完成，目前正在忙什麼
• 如果是 hotfix 任務，直接在卡片上標註 label 及 priority，不用再一個個私訊說哪一張卡要優先解決

再搭配一些通訊軟體，設定每天一早的寄出匯報要求給成員，今天預計的進度、是否遇到困難，以及請假等資訊，主管可以每個人都追蹤到，其他人也只要填寫即可，不用被迫綁時間在早上的 stand-up meeting。

知識管理

建立內部知識庫(wiki)，使成員可以隨時查找答案，減少對同事的直接提問。

結語

其實內部溝通成本遠不止於此，我只挑了我自己比較有感的三個主題。

不得不說「懶」真的就是工程美德，因為「懶得溝通」，所以就會把各種能夠自動化，能夠記錄成文章的東西都完成，以避免掉很多重複的工。