🌐 ZH-TW

Util Monster Magazine

給開發者的時間管理技巧

開發排程不能只把程式撰寫時間加總起來。還要一併安排需求確認、程式碼審查、測試、部署,以及意外故障的處理時間。先從配合團隊工作方式,區分專注時間與協作時間開始吧。

給開發者的時間管理技巧

區分專注工作與回應時間

設計或除錯等需要長時間維持脈絡的工作,請在行事曆上安排成一個完整時段。上午不一定適合所有人。選擇自己實際能專注的時段,並事先和團隊約定接收緊急聯絡的方式,會更符合現實。

把工作縮小為下一個行動的大小

只寫下「開發付款功能」這類大型名稱時,往往看不出該從哪裡開始。請拆分成確認需求、撰寫失敗條件、加入測試、實作、提出審查請求等下一步行動。設定每日優先順序時,也不必勉強固定數字,可以依據期限、對使用者的影響,以及是否有人正在等待來決定。

把計時器當作可選工具

番茄鐘是一種專注一段時間後休息的方法。如果 25 分鐘不適合你,也可以使用更短或更長的時段。如果計時器反而打斷工作節奏,不使用也沒關係。重要的是在開始前決定一項成果,結束後留下下一個行動。

確認會議目的,而不只是時間

如果沒有要決定的事項、必要的參與者和準備資料,請先確認是否能以文件或訊息取代會議。像複雜的設計討論這類需要快速對話的工作,可以召開會議,但結束時要記錄決定事項、負責人和下次確認日期。不必把所有會議都固定在下午或限制在 30 分鐘以內。

把等待審查的時間納入排程

寫完程式碼後,還需要留下審查、修改、測試和部署的時間。工作計畫除了自己的工作,也要安排其他人確認的時間。大型變更應拆成容易審查的單位,並一併寫明修改原因與確認方法,就能減少來回溝通的時間。

依重複次數與失敗成本選擇自動化

不必因為某件事一次需要 5 分鐘,就把所有事情都自動化。請先針對經常重複、容易被人忽略的測試、格式檢查和部署前確認,試行小型自動化。如果維護時間大於節省的時間,簡單的檢查清單可能更合適。

結論

本週的排程先改一件事就夠了。把需要專注的工作預約成一個完整時段,並在會議前寫下目的與需要做出的決定。自動化則應先從經常重複且出錯成本高的工作開始,以小範圍試行。

常見問題

專注時間應該安排幾個小時?
沒有標準答案。可以先試著安排 45 分鐘或 1 小時等自己能遵守的長度,再確認重新理解工作所需的時間是否縮短。緊急聯絡管道則應另外和團隊協議。
一定要遵守番茄鐘的 25 分鐘規則嗎?
不必。25 分鐘只是起點。請依工作性質與專注時間調整,如果計時器經常打斷工作節奏,就選擇其他方法。
什麼情況下可以把會議改成訊息?
像是傳遞資訊或簡單確認等,每個人閱讀後即可回覆的事情,很適合使用文件和訊息。如果需要立即詢問多個選項的優缺點並做出決定,短時間的會議可能更快。
應該先從什麼工作開始自動化?
請一併考量重複頻率、人為出錯的可能性,以及失敗時的成本。先從一項小型檢查開始,確認是否確實節省時間後,再逐步擴大範圍會比較安全。