TL;DR
2025 年快結束了。每到這個時候，上班族多少都會面臨一個大型挑戰：Performance Review、PMD，或是各種形式的年度考核。
因為去年對自己的考績不太滿意，今年初我在工作上做了一些調整──希望在年底時，能更清楚地呈現自己的貢獻。
這幾天剛完成今年的 Review，趁著結果還沒公佈 (還沒有過多情緒 XD)，試著客觀地回顧這一年的調整，也紀錄下自己的心得。
一、今年我做得好的地方
過去每到年底要整理自己的工作成果，都會覺得很痛苦。
今年試著改變做法：在日常累積 Brag Document，在平時就紀錄每個重要專案、每次明顯的推進以及自我創造的價值。
這件事在年底真的減少了很多「回想」與「補資料」的成本，也讓我更清楚自己一年到底把時間花在哪裡。
另一個部分是與「主管的溝通」，去年最後得到的回饋是「做的事情不錯，但沒有超乎預期。」
我忍不住思考：
如果連「預期」是什麼都沒有對齊，那什麼叫超乎預期？如何達到這個境界？
後來和 Skip manager 有過一段激烈的討論，不過在考績出來後，才爭論這個問題是沒有意義的。
因此今年試著：在年初就把方向定清楚。
今年在一開始就規劃了整年的工作目標，試著拆解成明確的 Milestone，並主動安排與 Manager、Skip manager 的會議。
確認大家對工作的理解是否一致，也確認這些內容是否符合當前職級的期待。
在方向一致的前提下，也維持了穩定的 1:1，今年與直屬 Manager 和 Skip manager 各約了四次的 1:1。
先前在 “How to Be More Visible at Work” 看到：不應該依賴你的 Manager 來提升能見度。
所以對我來說，這些 1:1 並不是因為「考績」才特別去做，而是想藉此理解不同層級的人，對相同問題會有什麼不同看法，也算是在練習「向上管理」。
(如果對於 1:1 有興趣，歡迎點擊 : 每個月和主管 1 on 1，半年後帶給我什麼樣的啟發？)
二、但在年末，我仍然卡住了
今年在主管的授權下，試著推動一個跨部門的專案，最終成功在組織內導入一個新的治理框架。
照理來說，應該要覺得很有成就感，但在準備資料時，一個很奇怪的感覺浮上來：
我好像在東拼西湊素材，硬要擠出亮點。
那種不對勁不是因為這些成果不重要，而是：
如果一件事真的做得夠好，應該不需要「擠」吧？
於是我開始回頭問自己：為什麼我會覺得沒有什麼「拿得出手」的東西？
三、原因之一：維運團隊的挑戰，與被看見的困難
身在協助 MLE 部署服務的 DevOps 團隊，有很多工作都是「維運性質」。
而維運工作有個很弔詭的地方：
不出錯是「應該的」；穩定被視為「本來就應該如此」。
換句話說：越不出錯的系統，越難說服別人你做了什麼。
Pipeline 正常運作、沒有意外、沒有阻塞、順利服務多個團隊──這些都很重要，但難以被量化，也難被視為「超乎預期」。
先前在 “軟體工程的知識落差” 中看到一個概念非常有感：“軟體團隊與下游團隊的合作難以評核”，對於 DevOps 或是 Platform Team 來說，與下游團隊的合作品質很難被量化。
回答內部 User 的客服再友善、再有效率，不會讓績效變好，只會帶來更多客服，消耗更多工時。
這種結構性問題，目前我還沒有很好的解法。
但這其實只是表層原因。更深的問題在於—我過去規劃工作的方式，也讓成果難以被看見。
四、另一個更核心的問題：我在規劃時，缺少了「產品思維」
回頭看自己年初的 Roadmap，我察覺自己犯了一個錯：
看到新的、酷的、熱門的技術，就直接把它塞進計畫。
但年底整理時會發現一件殘酷的事：除了你，沒有人在乎它。
大家會對新技術拍拍手、稱讚很棒，但它並沒有真的解決痛點，也沒有創造影響力。
這是我後來才意識到的盲點。
如同 Peter Su 在 “產品專案的起手式” 中提到的一個思維誤區 - 「直接跳入解決方案」：遇到問題時都直接思考「解決方案」是什麼？
若是以產品團隊的角度出發，追求的是「最大化產品的成果與價值」，那在解決問題時，真正該思考的或許是：
如何設計出能「傳遞價值」的解決方案？
我常把「做得很辛苦」錯當成「做得很重要」。
這樣很容易落入 “最有生產力的一年” 中提到的「虛假的生產力」: 對於生產力的「體感」和「實際創造的生產力」是兩回事：
“我們很難量化「短期成就」（該怎麼量化？請問你今天的成就是幾單位？），所以透過「忙碌程度」來判斷自己是否有生產力，就變成一條不擇手段，但通常 「不夠準確」 的捷徑。”
這也讓我更能理解，為什麼有些時候，我感覺很忙，卻沒有真正推動什麼。
五、給明年的自己：把工作當成產品來設計
如果今年有什麼值得記住的洞見，大概是：
工作要被看見，不是靠年底的包裝，而是靠「產品化」。
明年我希望能更系統性地規劃工作，練習把手上的工作視為一個 Internal Product，把自己當成一個負責 Internal Product 的 PM，在規劃技術架構前，先思考:
- 目標使用者是誰？
- 他們真正的痛點是什麼？
- 我做的事情能不能帶來可感知的價值？
- 這項功能的重要性是否大於實作的難度？
- 該如何衡量價值？
當我開始站在產品的視角來看這份工作，就比較不會跳入解決方案，而是先問：
「這個東西，真的值得做嗎？」
也許亮點不會在年底才出現，而會在日常的累積中自然浮現。
我希望讓產品本身的價值成為證據，而不是在年底才苦苦想理由。
明年繼續加油。
About Byte & Ink
我會定期在部落格分享不同主題的文章，目前包含：
- 職涯心得
- 個人成長
- 筆記軟體 - Obsidian 教學
- 技術相關 (
K8S,DevOps,軟體測試…)
如果你覺得內容有幫助，歡迎你點此訂閱我的文章，你的訂閱會帶給我更多動力，持續分享有意義的內容！