工程師心想：「前幾天熬夜加班，好不容易才做出來的功能，居然今天一上班規格又要改！我加班到底是為了什麼？」我想上面這個情境，應該在許多公司不斷上演

工程師心想：「前幾天熬夜加班，好不容易才做出來的功能，居然今天一上班規格又要改！我加班到底是為了什麼？」

我想上面這個情境，應該在許多公司不斷上演；規格變更的原因很多，比如：

1. 客戶突然想要增加／修改／刪除某個功能，而 PM 無力阻擋、談判。
2. 規格打從一開始就有問題，但開發到一半才發現。
3. 規格本身很模糊，每個人對規格的見解都不一樣，導致做出來的成品不符預期。

問題千千萬萬，但總歸都跟「人」有關係。

在文章開始前，筆者先跟大家取得一個共識：「PM 不是萬能的存在，客戶也沒那麼好溝通，規格一次到位的可能性趨近於零。」

在認知到規格變更是必須要面對的狀況後，我們接著來討論：「如何減少非必要的規格變更，盡可能降低自己的 Loading。」

▋準備相關證據

因為規格變更導致工程師加班的狀況並不罕見，但有些工程師的抱怨，會被不明事理的主管認為是能力不足。

為了避免上述狀況發生，我們需要準備「具體可量化」的證據，筆者建議從幾個面向來準備：

1. 記錄每次規格變更：有些規格變更並不是在會議上提出，而是透過私訊、電話或口頭告知，這些紀錄全部都要保存；如果團隊有使用專案管理系統，就能更好的記錄這些變更是由誰提出的（別忘記 tag 提出的人）。
2. 紀錄每次規格變更所增加的工時：絕大多數的規格變更，都需要花更多的時間來處理，這些時數都要記錄下來。
3. 哪些規格變更是可以避免的： 有些規格變更，是因為一開始根本沒想清楚，只是單純把客戶的需求寫上規格，這類問題有機會透過內部溝通協調來改善。

▋與主管溝通

建議一開始先跟 PM 溝通，如果溝通多次無果（請留存證據）再去找主管。

與主管溝通時記得拿出先前準備的「證據」，並強調以下幾點：

1. 頻繁的更動規格，會影響到專案穩定性（ex：測試程式都需要改寫）。
2. 建議先與客戶在規格上取得共識後，再進行開發（ex：先用 Wireframe 讓客戶確認流程），避免重工浪費時間。
3. 自己不是不能接受規格變更，但 A、B、C... 這幾項規格變更應該是可以避免的。
4. 現在的 Loading 實在太重（提出因規格變更導致的加班時數），假使規格變更無法避免，是否有補充人力或延長專案交期的可能性。

有些問題應該是主管要自己發現並去解決的，但主管日理萬機，偶有遺漏在所難免；我們能做到的就是透過「證據」把問題攤在陽光下，並說出建議的改善方向。

筆者過去曾寫過一篇文章，分享主管面對問題時會考慮的點。

▋結語

如果問題是長時間累積下來的，那想在短時間，或透過一套方案解決並不現實。

假使提出證據，並且充分溝通後還是沒有改善的跡象；而你也無法忍受這樣的工作環境，也許是時候考慮自己職涯了。

人，不是只有在痛苦的環境中才能成長；在合適的環境中，成長才會更加快速。

轉職一定要經過謹慎評估，筆者僅是提出個人觀點。

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

這篇文章 規格改了又改，工程師除了加班還能做些什麼？｜專家論點【林鼎淵】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。