Tony Yeh

Team Culture

這篇不是什麼很正式的管理學文章，只是整理一下我希望 team 裡大家可以一起養成的做事方式。

我覺得好的 team culture，不是貼在牆上的標語，而是每天怎麼做事、怎麼溝通、怎麼交付。

何謂功能完成？

所謂功能完成，不是只有「code 寫完」。

至少要做到：

• code 有經過 review
• code 已經 merge 到主要的 branch
• README 有明確的測試及執行步驟
• 其他人知道怎麼跑、怎麼驗證、怎麼接手

東西要做，就把它做完整。

不要做了一半就丟在那邊，也沒人在用。這樣有你沒你，對專案完全沒有差別，只是在瞎忙而已。

Code review

養成盡快將 code merge 回 main branch 的習慣。

基本流程：

• 開 PR
• 指定至少 1 位 peer review
• peer review 完，再請主管 review
• review 完就盡快 merge 回 main branch

Why?

• 讓其他人有機會學習
• 讓其他人有機會告訴你可以改進的地方
• 避免 branch 放太久，最後越來越難 merge
• 避免知識只停留在一個人身上

Code review 不是找碴，而是讓整個 team 的品質一起提高。

目標感

我們不是研究單位，做事不能太鬆弛。

不要無止盡 study 而不動手，也不要花太久時間解一個其實不重要的問題。

做事要用大局的角度想：

• 這件事現在真的重要嗎？
• 它會不會影響主要交付？
• 有沒有更簡單的做法？
• 是不是先做到能用比較重要？
• 還是其實可以先不要做？

任何 task 都要設定 ETA，也就是預計完成時間。

如果每次預估都 delay，那就要檢討 root cause：

• 是一開始低估了？
• 是需求沒問清楚？
• 是中間被其他事情打斷？
• 是太晚發現問題？
• 是遇到困難沒有及早求助？

delay 不是不能發生，但如果每次都 delay，就要想辦法讓這件事不要一直重複發生。

資訊流通

如果你認為那個人應該知道這件事，就把他加到群裡面來。

不要害怕在大群發問，不然問題很容易被 block 住，也可能真正知道答案的人根本沒看到。

如果你覺得某件事重要，就把它寫到 wiki 上，主動 share 出來。

例如：

• spec 討論
• 測試方式
• 已知問題
• debug 方法
• 架構決策
• 踩坑紀錄

有些 spec 討論只在私下的小群裡，其實應該要讓更多人知道。

資訊不要卡在某幾個人手上，這樣 team 才會一起變強。

開會

如果你參加某個會議，發現討論內容跟你無關，或是你手上有更重要的事情，可以隨時告知離開。

無需浪費生命。

但如果你人在會議中，就要練習 100% 專注在討論的內容。

你應該要：

• 有不懂的地方就問
• 覺得哪裡怪怪的就提出來
• 發現風險就提醒
• 討論發散時幫忙拉回來
• 確認最後有沒有結論
• 確認有沒有 action item

你的目標是：

• 因為你的加入，會議討論的 quality 就此提高

會議要有結論跟 action item，不然就是在清談而已。

自評

每半年，也就是 6 月和 12 月，大家要寫一次自評。

內容就是總結半年來自己的貢獻，這會跟考績與分紅有關。

我的建議是直接在 wiki 開 page 寫，彼此都看得到。

好處是：

• 自己的貢獻有被記錄下來
• 主管回顧時比較清楚
• team member 也知道彼此做了什麼
• 之後也比較容易整理 team 的成果

如果你忘了寫，那就是靠平時的印象分數打考績。

當個 Dyson 吸塵器

做測試工具、寫 script，就算功能再強，如果使用方法很複雜，也沒人會用。

環境還是很髒亂。

所以工具要盡量做到：

• 一鍵執行
• 全自動完成
• 不需要手動做一堆設定
• 文件簡單清楚
• 錯誤訊息看得懂
• 其他人不用一直問你怎麼用

能一鍵執行、全自動完成，大家使用的摩擦力就小，執行動力就高。

大人小孩都喜歡，地板亮晶晶。

做真正重要的事

花時間做投影片、架構圖，好好說明給其他人，這件事很好。

但是如果真正的 task 沒有完成，卻花好幾個小時做投影片、改格式、作圖，那就有點本末倒置。

不如把時間花在把 task 完成。

會議說明的部分，很多時候用紙筆、白板、簡單 diagram 就可以。

重點不是投影片多漂亮，而是：

• 問題有沒有講清楚
• 有沒有做出決策
• 有沒有 action item
• 真正該完成的 task 有沒有往前推進

不要把「看起來很專業」誤以為「真的有進展」。

總結

我希望 team 裡大家可以養成的文化：

• 把東西做完整
• code 要 review，也要盡快 merge 回 main branch
• 做事要有目標感，不要無止盡 study
• task 要有 ETA，delay 要檢討 root cause
• 資訊要流通，不要只放在小群裡
• 會議要專注，要有結論跟 action item
• 重要的東西要寫到 wiki
• 工具要降低使用摩擦力
• 把時間花在真正重要的事情上

這些事情看起來都很基本，但能不能每天做到，就是 team culture 的差別。