初次見面。我是在 PRUM 株式会社擔任工程師的 すもも🍑
平時我會整理並分享在程式設計學習與實務中容易卡關的重點，以及思考方式。
如果你對 PRUM 感興趣，也歡迎參考我們的企業網站。
▶企業網站
—明明以為自己是一個接一個地完成任務，回過神來卻發現期限已經逼近—
你有過這樣的經驗嗎？我在研究專案管理基礎時接觸到「關鍵路徑」這個概念，才終於明白原因。
關鍵路徑，就是左右整體期限的「急所」
一般來說，專案或任務具有兩個特徵：「有期限性」（總有一天會結束）與「獨特性」（每次條件都不同），因此會必然產生不親自做做看就不會知道的不確定性。
而用來控制這種不確定性的工具之一，就是關鍵路徑。
- 指的是整個專案中，耗時最長的一連串作業
- 這裡如果延遲 1 天，整個專案的完成日也會延後 1 天
- 把作業與時間放到甘特圖上，這個急所在哪裡就能一眼看出來
也就是說，所有作業並不是都具有相同的重要性；有會拖慢整體進度的「急所」，也有即使稍微延遲，影響也比較小的部分。
急所其實藏在「涉及他人」的任務中
讀完這段說明後，我重新回頭檢視自己的工作方式。以前我只是把眼前的任務照順序消化掉，幾乎沒有「優先順序」這個概念。
結果，總是延遲的，往往是那種包含自己先作業 → 再交由對方確認或判斷 → 接著根據對方回饋再由自己繼續作業的流程。這類任務中，等待對方回覆的「等待時間」通常比自己實際作業的時間還長。
自從遠端工作成為常態之後，這個等待時間又更長了。
如果是在同一個空間，口頭確認一下就能解決的事情，到了聊天訊息裡，可能得等好幾個小時才會收到回覆。無論自己的工作速度提高多少，等待對方回覆的時間，都不是靠自己的努力就能縮短的。
帶有等待時間的任務，才是關鍵路徑
套用關鍵路徑的概念來看，答案其實很單純。凡是牽涉到他人確認或判斷的任務，由於一開始就內含了自己無法控制的「等待」時間，因此越往後拖，就越容易成為卡住期限的急所。
相反地，能夠靠自己一個人完成的任務，即使稍微延後，只要自己夠努力，仍然有補救並趕上的餘地。即使看起來都像是「很緊急的任務」，只要是否包含等待時間不同，優先處理的程度就會完全不一樣。
提前產生等待時間
在有了這個體悟之後，我也改變了處理任務的順序。比起先做能獨立完成的任務，我會先把需要他人確認或回饋的任務，第一時間先丟給對方。目的是盡早讓自己無法控制的等待時間開始流動。
等待的期間，則同時處理其他自己一個人就能推進的任務。等到對方回覆之後，再接著做後續。自從改成這樣之後，到了期限前夕才突然發現「啊，這個是在等回覆」而慌張的情況，真的減少了不少。
今天就能開始做的事
- 收到任務時，先區分「能否只靠自己完成」與「是否會夾雜他人的確認或回覆」
- 只要是會夾雜他人確認或回覆的任務，即使內容還沒完全定案，也先送出去
- 在等待回覆的期間，先著手處理其他自己一個人就能進行的任務
- 對於「看起來很緊急的任務」，先懷疑一下它是否真的包含等待時間
因為只是調整順序，所以從明天早上的第一個任務分派開始就能立刻試試看。
總結
任務會延遲，並不完全是能力或速度的問題。若只是照順序消化任務，凡是包含自己無法控制的「等待時間」的任務就會被往後擺，而那正是造成期限延誤的急所。
最先該做的，是把需要他人確認或回覆的任務盡可能放在最優先，並立刻交給對方。
等待回覆的期間，則先推進其他能由自己單獨完成的任務。
只要先讓容易成為急所的任務動起來，追著期限跑的感覺應該就會減少很多吧。若想讓工作更有效率，在安排任務排程時，也希望能把他人回應所需的時間一起納入考量。
PRUM 的工程師多數都是從無經驗者開始招募的。
如果可以，也歡迎來我們的企業網站逛逛。
▶ PRUM 招募頁面
我們也有經營整理給工程師參考的文章網站。如果你有興趣，歡迎看看。
▶ 對工程師有幫助的文章網站
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
