本文是「測試之外的那一半：一個 QA 回頭帶當年的自己」系列第 17 篇。
最近我替一條產品線寫了一份文件，給新進 QA 用的。沒有人要求我寫。
寫的時候我一直想到剛進來的自己。
實習的時候，我拿到的第一份東西是需求規格。裡面有一整區的專有名詞我看不懂，多數是縮寫，都跟區塊鏈有關。
我沒有買過加密貨幣。那個領域的東西我一個字都沒接觸過。
而寫那份規格的人，還有會議上討論它的人，全都買過。對他們來說那些縮寫是不需要解釋的常識，就像你不會在文件裡解釋什麼叫登入。
我的反應是回去自己查，查不到就放著，假裝下次會懂。我沒想過要問，因為我覺得那是我該自己補起來的基本功。
後來我確實去補了。花了一段時間把那個領域的基礎讀過一遍，再回頭看那份規格，就看得懂了。
需求規格是寫給已經懂的人看的。
它假設讀者知道這個產品在賣什麼、知道那些縮寫、知道畫面上的數字從哪裡來。對 PM 和 RD 來說這些假設都成立，所以文件寫成那樣是合理的。
問題不在那份文件上。PM 該產出的規格文件他都產出了，而且通常寫得很完整。
缺的是另一種文件：把規格翻譯成新人能用的形狀。導讀順序、縮寫對照、帳號怎麼拿、數字該跟什麼比對。
而這一層不在任何人的職責描述裡。
PM 的主業是定義產品方向，RD 是把它做出來，QA 是驗證它。「幫新人讀懂」對每個角色都是順便。而順便這兩個字在組織裡的命運，是排在 backlog 最底下，然後不會被翻上來。
不只是沒被寫出來。已經寫出來的那些，會慢慢跟現實對不上。
我看過幾份文件走一樣的路：啟動時寫得很認真，前兩個 sprint 大家都會回去更新，然後某次需求臨時改、時程很趕，於是「先做了再回頭補」。幾次之後，團隊心照不宣地知道那份文件不能信，新人報到時會被告知「程式才是真相，文件僅供參考」。
死因跟前面那一層一樣：維護它不是任何人的 KPI。
它沒有交付儀式。寫程式有 PR 可以 merge，沒有人會在 sprint review 上鼓掌說這份文件更新得真好。它的價值也是負面的——維護好了看不出差別，因為「沒有人誤會需求」永遠不會被報導。
Day 6 講的非晉升性任務、Day 11 那份沒人敢刪的清單，跟這個是同一種東西。
沒什麼方法論，就是一份補充文件，六個部分：
核心只有一句：這份文件不是複製規格，是把它翻譯成新人能用的形狀。
那份文件我寫出來了，新人也真的在用。但那個缺口一點都沒有變小。
它還是不在任何人的 KPI 上，包括我的。而且哪天我不做了，它大概就會照上面那個劇本走一遍——誕生、黃金期、拐點、遺棄。接手的人同樣沒有義務維護它。
我看得懂為什麼會這樣，但我改不了。改它需要有人決定「這份文件由誰負責」，那是組織設計的決定，不是我下得了的。
實習的時候我把讀不懂整個歸因到自己身上。那個歸因有一半是對的，知識確實得我自己補。錯的是另一半：我以為連「該補什麼」都得自己摸索，是理所當然的事。
差別只在於，我知道我補的是一個結構上的洞，跟我夠不夠格無關。
讀不懂手上那份文件的時候，先分清楚兩件事：
這份文件是寫給誰的？ 如果它是寫給已經懂的人看的，你讀不懂是正常的，不是你的程度問題。
它上次更新是什麼時候？ 如果距離現在很久，而功能一直在改，那你讀懂了也沒用。
這兩個問題都不是在質疑寫文件的人。它們幫你決定一件事：這份文件還能不能當依據，還是你得另外找一個人問。
明天聊：可測試性壞掉的時候，你要去找誰。
iThome鐵人賽
看影片追技術