# 遇到「第一次」的問題被問何時能解決？PM 跟工程師都千萬別這樣說！

- 作者：林鼎淵（Dean Lin）
- 網址：https://deanlin.net/blog/202211/estimating-first-time-issues/
- 發布：2022-11-14
- 主題：團隊合作
- 標籤：科技島專欄
- 摘要：站在專案管理的角度，每個時程估的越精確越好；但從開發實務面來說，不管是第一次接觸的技術，還是第一次遇到的 Bug，這類「第一次」的事件真的很難估出一個具體時間。

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

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

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

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

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

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

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

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

## 工程師要「主動」給出回報時間

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

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

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

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

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

這樣做有以下好處：

1. 主管知道什麼「時間點」會收到回報。
2. 如果提前解決，你會被認為是效率高。
3. 我們說的是「回報時間」並非「解決時間」，給自己一點緩衝空間。

## 工程師千萬別說自己會「盡快」解決

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

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

## 總結

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

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

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

---

關於作者：林鼎淵（Dean Lin），台灣的生成式 AI 企業內訓講師、外商資安公司軟體專家，也是生成式 AI 創新學院發起人。出版 7 本書（包含全台第一本 ChatGPT 應用專書），兩度獲得 iThome 鐵人賽佳作，累積上百場授課與顧問經驗。（https://deanlin.net/about/）
引用時請附上原文網址：https://deanlin.net/blog/202211/estimating-first-time-issues/