實習的時候，我看不出來誰在評估我。
也看不出來，我做的哪些事會讓一家公司願意多付我錢。
一件是環境設定的筆記。那時候還沒辦法叫 AI 幫你把整套系統建起來，新的人要跑起來環境，得有人把坑一個一個寫下來。我寫了。
另一件是我自己覺得比較厲害的：在開始測試之前，我會先讀規格，然後把裡面沒寫清楚的地方問出來。有些問題 PM 自己也還沒想到，被我問出來之後他回去補。
那時候我以為，問題出在沒有明確的指標。等到哪天這些東西能被寫成指標，我對團隊的貢獻就算得進去了。
然後我發現，軟體測試的績效本來就不好評估。
這禮拜找到幾個 bug、自動化覆蓋率多好看、測試報告能不能準時交——每一個數字都照到一個角度，但整個開發過程比這些角度加起來複雜太多。
「交付一個高品質的產品」這件事，本身就很難被明確定義成「我們把事情做好了」。
指標沒有解決我實習時的困惑，它只是把困惑換了一個位置。
2017 年，Linda Babcock 幾位研究者給這類工作取了一個名字：非晉升性任務。定義是對組織有價值，但對做的人沒有職涯報酬。
他們的判準有三個。一件事會不會進到年底那張表，看它有沒有可歸屬的成果、有沒有一個明確的結束點、有沒有第二個人知道那是你做的。
三項都缺，它在系統裡就等於沒有發生。
我拿這三條回頭檢查我實習時做的那兩件事。
環境筆記還好，它至少是一份看得見的東西，如果我當時把它變成一份有名字、有版號、有人知道是我維護的文件，它是可以被計分的。我沒有做那一步。
至於我自己最得意的那件：在測試之前把規格的漏洞問出來，三項全缺。
它沒有可歸屬的成果，因為產出只是 PM 文件上被補的一行字。
它沒有結束點，因為規格永遠可以再問下去。
沒有第二個人知道那是我問出來的，因為補完之後那份規格看起來就像本來就寫得很完整。
而且還有更麻煩的一層。
那件事做成功的樣子，是什麼都沒發生。
那個 bug 從來沒有出現過。所以沒有 bug 編號、沒有修復時間、沒有事故報告、沒有任何一條紀錄可以指著說「這是我擋下來的」。
你做得越好，留下的證據越少。
這不只是我實習時的狀況。它是 QA 這份工作的一部分結構——我們最有價值的產出，經常是一件沒有發生的事。
我沒有去衝數字。我做的是在本來就要做的事情上多做一點，讓別人比較好辦事。
讓 RD 比較容易解我的 bug。不要只寫「按鈕沒反應」，寫「按鈕沒反應，F12 看到後端回 403，懷疑是某個模組更新後權限失效」。多這一句，他省掉第一步。
讓 PM 看得懂這個 bug 會影響多少商業利益。同樣一個問題，寫成「這個情境下使用者會付不了錢」，跟寫成「結帳頁面異常」，得到的處理順序不一樣。
你為別人多做一點小事，別人很難因此說你做得多棒。
更常見的是反過來——因為你哪一天沒做，他們才來問你為什麼沒做。
也可能要等到很久以後，等他們合作過其他的 QA，才會想起來「當初那個人做了很多細節，我們都沒注意到」。
這個結構我到現在還是覺得不太舒服，而我沒有解法。
我心裡最深處想要的，其實就是被肯定。
認清這件事之後我並沒有過的比較輕鬆或躺平，但至少我不會再把「沒被計分」讀成「我做得不夠好」。
那是兩件事。
我是基督徒，所以還有一句話我會拿來提醒自己：我的好壞不是考績表決定的。上帝愛我這件事，跟我這季找到幾個 bug 沒有關係。
把一張表當成衡量自己的尺，那張表就會一直不夠。
挑一件你做最久、最沒有人會來搶的事。
給它三樣東西：一個名字、一個結束點、一個知道那是你做的人。
不用全部的事都這樣做，一件就好。
先分辨哪些事本來就不算，你才有資格決定要不要繼續花力氣在上面。
明天是第一週的回顧：前六天其實都在講同一件事。
非晉升性任務的概念來自 Babcock、Recalde、Vesterlund、Weingart 2017 年的研究。我是在 這篇 Threads 貼文 讀到的，裡面用兩個角色把這件事講得很清楚，推薦去看。
iThome鐵人賽
看影片追技術