Learn effective time management strategies for software engineers and gain an edge from the very beginning.

1. 「贏在起跑點」的時間術
Max Weng | 2024/03/22

2. 兵聞拙速 ,
未睹巧之久也

3. 情境：
「這個需求麻煩你兩週後幫我完成,
客戶很急著要」

4. 大部分的工程師…
D1
D2
D3
D4
D5
Weekend
D6
D7
D8
D9
D10
時間還早…
1. 簡單思考一下需求如何開發, 開始慢慢一點一點開發
2. 先順便處理一下手上的雜事
• 試著解積一陣子的陳年bug
• 查看一下e-mail, 寫其他wiki
3. 做一些自己一直想做的refactor
⚠️大限將至…開始衝刺
「靠…怎麼跟我想的有點不太一樣, 晚上加個班拼看看」
熬夜到一兩點還是做不完…等等上班跟主管講一下會Delay…

5. 為什麼總是無法on time…
1. 掌握風險的重要性：太晚開始衝刺, 無法提前掌握未知的風險
• 非預期的系統架構導致無法簡單實現需求, 需要大改
• 仔細看需求有許多邏輯上根本的錯誤, 還要跟Business analyst重新討論
• 最後幾天身體狀況不佳…
2. 沒有保留餘裕：
• Deadline將至, 心理壓力極大, 經常用最髒的方法處理問題
（出現大量的Spaghetti code )

6. 匱乏經濟學 – 為什麼老是在趕Deadline
https://pansci.asia/archives/84544
Situation:
美國密蘇里州醫院經常面臨: 人手充足但是手術室不夠
Option 1: 增加醫生的加班時數
- 增加單一醫生的輸出
Option 2: 增加手術室
- 花大錢增加資源, 確保能更多醫生同時處理
Final decision: 在醫院中空出一間手術室不用
原因： 在沒有餘裕的情況下, 有手術做不完的壓力, 手忙腳亂反而導致
醫生手術品質下降, 手術時間也變長
Result: 總手術量成長了5%, 醫生的生活品質還變好

7. 熬夜趕工的風險
On top of the obvious health risks, when you have any sleep
disturbance, your IQ drops by 5-8 IQ points, explained Swart.
While we can usually carry on, albeit a bit more groggy, studies
show that when we miss a night of sleep, our IQ drops by 1
standard deviation, meaning you’ll be “operating as if you’ve got
a learning disability,” she said.
簡單來說：
每次熬夜時, 你的智商會下降一個標準差
你的產出：
1. 錯誤邏輯的程式碼
2. A lot of code smell…
https://edition.cnn.com/2015/04/01/busine
ss/sleep-and-leadership/index.html

8. 「贏在起跑點」
D1
D2
D3
D4
D5
Weekend
D6
D7
D8
D9
D10
閒適期：
1. 處理剩下的三成
2. 修正PR收到的反饋以及bug
3. 完成自己其他想做的新技術Survey, 重構等等
衝刺期：目標完成進度7成-8成

9. 衝刺期

10. 集中力 = 想像力
界王拳：
七龍珠裡面悟空修煉時學會的招式, 透過集中精神控制氣, 讓
自己戰鬥力可發揮出十倍 、二十倍的成長
副作用是大幅消耗自身體力, 身體會非常疲勞

11. 衝刺期每天日程
D1
D2
D3
10 a.m. – 12 p.m. 20 x 界王拳
訂立極短期目標：
12點前我一定要完成什麼
12 p.m. – 2 p.m. 休息時間 - 健身
2 p.m. – 8 p.m. 20 x 界王拳
將時間切分兩小時為單位
每兩小時都有一定要完成的事項

12. 衝刺期應該做的事情
1. 邊行動邊思考：
• 有很多風險是要真的進去開發才會發現的
• 不要一開始就寫複雜的文件, 所有工作必定得都在修改
• 完成後才發現不是客戶要的
• 設計完才發現現有架構不可能做到
2. 沒有人在雕刻人像時, 會像執著在眉毛的
• 不要執著於細節, 先將雛型完成, 並列出風險
3. 如果發現前面30%的時間無法完成70%的工作, 提早告知主管風
險, 方便主管控制專案
• 人、 時間（加班） 、砍需求、犧牲品質（放棄UT,重構）
• 就算要熬夜, 也要趁前期狀態好時熬夜

13. 評價恐懼 - fear of evaluation
害怕自己開發的程式碼不夠完美, 發PR時會被別人批評
結果：
1. 整個需求都開發完才發PR, 結果發現不符預期
2. 執著於細節, 希望達到程式碼100分才發, 而非商業需
求想達成的目的

14. 最小化交付

15. 最小化交付 – 優點
1. 提早收到反饋 (From other engineer)：
• 小小的架構問題, 閒適期可以調整
• 大的問題：中斷目前進度, 先馬上調整
2. 提早收到反饋 (From QA and PM)：
• 發現需求可能不符合客戶想要的
• 文件設計錯誤

16. 閒適期每天日程
10 a.m. – 12 p.m. 10 x 界王拳 專注完成剩下三成, 以及其他重要的事情
12 p.m. – 2 p.m. 休息時間 - 健身
2 p.m. – 8 p.m. 2 x 界王拳
完成其他雜項工作
1. 準備文件
2. 修正小bug
3. 做一下重構
4. Survey 對專案有幫助的新技術
D4
D5
Weekend
D6
D7
D8
D9
D10

17. 閒適期應該做的事情
1. 早上還是盡量全力衝刺：
• 這時段通常干擾最少, 比較少人會一直來找你
• 避免剩下三成還是有意想不到的問題
2. 別用最高效率完成全部工作
• 集中力有限, 假設10天的工作你每次都3天就交件
「既然你這個都可以三天完成,接下來也麻煩你三天內交付了」
3. 保持穩定性與持續性, 會收到較好的評價

18. 情境2：
「這個需求你覺得你多久可以完成」

19. 大部分的工程師...
0 – 30 mins 簡單翻一下程式碼, 根據過去經驗在位置簡單想一下
30 mins later… 跟主管回覆：「兩個禮拜左右可以搞定」
D1
D2
D3
D4
D5
Weekend
D6
D7
D8
D9
D10
時間還早…
1. 簡單思考一下需求如何開發, 開始慢慢一點一點開發
2. 先順便處理一下手上的雜事
• 修看看積一陣子的陳年bug
• 查看一下e-mail, 寫其他wiki
3. 做一些自己一直想做的refactor
⚠️大限將至…開始衝刺
「靠…怎麼跟我想的有點不太一樣, 晚上加個班拼看看」
熬夜到一兩點還是做不完…等等上班跟主管講一下會Delay…

20. 「最後衝刺」是萬惡根源
1. 時間表只是參考, 工作進度不一定照時間表走
2. 時間截止前, 大不了我熬夜可以搞定
3. 真的做不完再講一下, 稍微延後期限

21. 「贏在起跑點」- 嚴守交件期限
0 – 30 mins 簡單翻一下程式碼, 粗估兩週左右可完成
30 mins later… 跟主管回覆：「請給我兩天的時間, 我想先評估這份工作的難易度」
D1
D2
直接著手進行開發, 將這兩天視為「贏在起跑點」的機會全力衝刺
將工作處理到「近乎完成」
狀況1. 全力衝刺還是落差很大（潛在危機）
 跟主管說明所有相關的風險, 並與其討論要怎麼走下一步
狀況2. 可完成7成-8成的進度
=> 回報主管可兩週內完成

22. 嚴守交件期限– 主管的觀感
最後一刻才說做不完要延後❌
v.s.
在專案很初期, 提前告知相關風險✅

23. Others…

24. 避免一心多用
QA: 「Max, 這個東西看起來怪怪的, 你可以幫我看一下嗎？」
我：「好啊我馬上看一下」
我：「你等我十五分鐘, 我這邊東西處理完後過去找你」
為什麼要這樣回答：
1. 確保自己手上正在開發的工作到一定進度, 避免不必要的context switch
2. 處理完手頭工作後主動去找有需要幫忙的人, 讓別人知道你很重視他的問題
3. 沒有人會因為要等你15分鐘生氣的..(大概吧）

25. 團隊中最糟糕的人 – 不聰明但努力的人
1. 遇到重複性的事情, 用大量時間來解決, 而不去思考未來有沒有
辦法透過其他方法節省時間
2. 修改舊的程式碼時, 即便覺得怪怪的, 也不敢提出來與大家討論
, 繼續堆疊床架屋
3. 經常性的加班, 影響團隊風氣
https://www.businesstoday.com.tw/article/category/80407/post/20
1712190040/

26. 案例：Production正式上版重大失誤事件
以前上版環境會區分為給客戶的preview環境(UAT) 的環境以及
正式環境(PROD)
Situation:
有個緊急需求, 需要在週二推到UAT給客戶看, 沒問題週三一大
早就要馬上推到正式環境
到了週二這天要同時進行UAT上版, 並先準備隔天production的
package.
這件事情主要由同事A進行處理, 他是個認真的人, 希望可以用
最快的效率完成這項任務
所以他同時開啟了兩個視窗, 一個UAT Jenkins的頁面, 另一個
Production 的Jenkins
但一個失誤….不小心直接部署到了正式環境
進而導致營運上損失慘重

27. Production正式上版重大失誤事件 - 如何避免
透過時間成本解決：（不聰明的做法）
1. 訂立SOP, 每次新人進來都在新人訓練的時候強調：不可以同時
開啟UAT/PROD做事情
調整業務流程: (聰明的做法）
改善上版流程, 讓UAT/PROD的Jenkins有明確的差異化
1. 在production Jenkins 新增第一步, 確認是否上版, 並強迫
輸入維護時間
2. 點選按鈕後透過聊天機器人通知整個團隊的Teams, 告知
預計上版到正式環境（第二層保護）
遇到重大問題時先與團隊討論：
有沒有任何方法, 可以做到完美的流程防呆, 連新人進來也不會出錯
而不是想著透過人來handle

28. Knowing is not enough, we must apply.
Willing is not enough, we must do.

29. Thank you for your attention