經過了前幾次的相處，我也逐漸建立起和 Ray 的合作模式。過去和前任工程師的互動非常制式化，大概是確認規格－開時程－功能準時交付進入測試環節。但畢竟對於新同學總是會多些耐心，其中一項，體現在固定關心開發進度。

畢竟身為 PM，工程師埋頭苦幹致力開發時，我也不可能坐在旁邊看他一行一行寫 Code，害怕投入的關心和成品成反比，目前能做的大概就是適時關心一下。當然，經過了day2的磨合，Ray 通常都會非常穩定地給我令人安心的答案：「沒問題。」

好的，我就如同等待初戀時般的忐忑不安，夾雜著既期待又害怕受傷害的心情等待著。

時間就這樣來到了交期，一般我和 RD 的默契是，交期是哪一天，那就是當天下班前交。當天鄰近中午，SA 傳來訊息：

「今天早上 Ray 來跟我確認規格。」
「OK，那有哪裡不確定嗎？」
「不......太對，我現在在一行一行幫他code review」

......OwO？

Progress Check：怎麼確認進度真的在向前推進？

什麼叫做有效的進度確認？

在跟 Ray 相處一段時間後，我有一種深深的感覺：若將他的進度做一個比喻，大概可以說成路徑長>0，但位移=0，不小心還會倒退。
（友人聽完：所以是做虛功嗎？）

過去在追開發進度時，比較常問：「目前還順利嗎？」、「有沒有遇到問題？」或「大概完成幾 % 了？」

但「順利」、「快好了」、「完成 80%」其實都很難讓 PM 判斷目前真正的狀況。尤其 PM 不會直接檢查 Code，更不可能每天驗證功能。因此在非常情況下，除了掌握百分比，也可以試著直接詢問：目前已經完成什麼、還剩下什麼，以及下一個可以被確認的節點是什麼？

PM 可以怎麼確認開發進度？

1. 確認「已經完成什麼」

除了問「做得怎麼樣了？」，可以更進一步確認目前實際完成的內容。

例如：

「目前已經處理到哪個部分？」
「現在是資料取得完成，還是判斷邏輯也改完了？」

重點不是讓 PM 判斷技術做得對不對，而是讓「進度」從模糊的敘述，變成比較具體的工作狀態。然後當夥伴開始說話變含糊的時候，當然可以相信他，但也可以心中默默敲響警鐘......適當請其他夥伴盡快協助。

同時，從對話中，可以在早期就察覺一些蛛絲馬跡......例如他完全看不懂規格（他真的是完全看不懂）

2. 確認「還剩下什麼」

「快好了」最危險的地方，是每個人對「快」的定義可能不太一樣。有人可能覺得剩下一個部分叫做快好了，殊不知那個部分要做三天，會讓 PM 再判斷上失準，或是多加幾句「快好了是還需要多久呢？」「那現在還剩下xxxx嗎？」

剩餘工作越具體，PM 才越容易判斷原本的交期是否仍然合理。

3. 約定下一個「可以確認的節點」

PM 不需要在開發途中驗收 Code，但可以和 RD 約定下一個明確的 Checkpoint。例如：

「好，那今天先完成這項判斷邏輯。」
「明天下午 Self Test 完，再把測試結果給我。」
「週四交測，所以週三主要 Case 要先確認可以 Pass。」

這樣追蹤的就不只是「交期那天會好」，還能多確認下一步要完成什麼，以及什麼時候可以確認結果。

PM 不一定能提前知道工程師是不是理解錯誤，也不可能百分之百保證開發一定準時完成；但至少可以讓「可能不會完成」這件事情，不要等到 Deadline 當天才突然被發現（斑斑血淚）

說是這樣說，但是呢，每次都聽到快好了，剩下一天就可以交，然後一天又一天，一天何其多。
後來因為當天得要交，但他實在寫不出來，我就去和前任工程師聊這件事情。由於他是調職，但經過上司許可，還是留在這個專案讓我們可以隨時詢問，只是不參與開發。
聽完我的敘述，以及詳閱了任務單，再好心地進去 git 看目前開發的內容，看完後對我說：

寫的內容跟規格只能說沒半毛關係啦

當天加班陪他改完後，下班踏著月色回家，月下吟詠：

情緒無法解決問題，想處理事情時，絕對不要帶著情緒。
情緒無法解決問題，想處理事情時，絕對不要帶著情緒。
情緒無法解決問題，想處理事情時，絕對不要帶著情緒。

無物堪比倫，教我如何說。