PM＆工程師都應該學習！當遇到「第一次」的事件被問何時解決，千萬別這樣說！｜專家論點【林鼎淵】

林鼎淵 — Mon, 14 Nov 2022 07:30:00 +0000

站在專案管理的角度，每個時程估的越精確越好；但從開發實務面來說，不管是第一次接觸的技術，還是第一次遇到的 Bug，這類「第一次」的事件真的很難估出一個具體時間。不過我們或許可以這樣做...

圖片來源：freepik

站在專案管理的角度，每個時程估的越精確越好；但從開發實務面來說，不管是第一次接觸的技術，還是第一次遇到的 Bug，這類「第一次」的事件真的很難估出一個具體時間。

如果你擔任公司的 PM 或主管，在下次專案出現 Bug 時，不妨參考文章的方式來溝通；如果你是工程師，也能採用文章的建議，減少自己修 Bug 時被打擾的次數。

▋釐清問題前，盡量不要強壓時間

有些主管在 Bug 出現後，根本不管問題複雜度，直接命令工程師：「給我在 15 分鐘內修復完成！」

如果是問題明確的小 Bug，那壓個時間倒也還好；但如果問題複雜度高，強壓一個不合理的時間，那對解決問題並沒有幫助。

說實話，遇到 Bug 的時候工程師就已經很緊張了，如果再加一個很短的時間限制；在腦袋一團亂的狀態下，就算解決了表面上的 Bug，可能背後又同時埋下了更多的 Bug。

筆者比較建議的詢問方式為：「大概需要多少時間釐清問題？」

這裡想表達的是，讓有專業能力的人來估時間；而不是由搞不清楚狀況的人，隨意定一個時間。

要給的是「回報時間」，而不是「解決時間」。

面對完全摸不著頭緒的問題，如果直接說自己可以在 xxx 時間內解決，那會給主管一個錯誤的期待。

如果你真的順利在時間內解決那是皆大歡喜，但萬一還是無法解決那怎麼辦？

就算之前都運氣好順利解決，但只要你失敗過一次，許多主管就只會記得失敗的那次。

因此筆者建議用這種方式回覆：「這邊我們先釐清問題，半小時後向您回報 Bug 處理狀況，如果有順利提前解決也會即時回報。」

這樣做有以下好處：

如果說自己會盡快解決，那有高機率每 3~5 分鐘就被打擾一次。

因為每個人對「盡快」的時間定義不同，人一但急了就會催促，而對工程師來說，如果在釐清邏輯時被打斷，那可能會需要再重新順一遍；所以筆者建議要說出「具體時間」，避免在解決問題的過程被頻繁打擾。

遇到 Bug 時，無論主管、PM 還是工程師都很緊張；但有時越急犯的錯越多，下次不妨嘗試看看：

讓工程師自己定下回報時間：建議將回報時間設定在 30 ~ 60 分鐘。
回報時間內不要打擾工程師：大家都很急，如果耐不住性子打斷工程師的思緒，就可能導致需要更多的時間來解決 Bug。
要求工程師定時回報處理進度：如果判定問題無法短時間解決，工程師就需要「定時」回報處理進度（若沒有定時回報的機制，有些人就算卡住了也不會主動說）；這個「定時」會給人增加一些安全感，並減少工程師被打擾的次數。

希望這篇文章的建議，能讓大家日後遇到 Bug 時合作更為和諧；如果您有不一樣的觀點，也歡迎留言討論。

☛ 如果想更深入認識我，可以 Follow 筆者的技術部落格。
☛ 如果對工程師的職涯感到迷茫，筆者最近出版的新書也許能給你帶來不同的觀點。