TL;DR 總結論
使用 as a - I want to - so that I can 的格式撰寫 user story，就不容易漏掉開發時需要的背景資訊，可以節省工程師反覆追問使用情境的時間
使用 cross-functional process flow 的格式繪製 user journey，就不容易漏掉 happy path 以外的操作邏輯，可以節省工程師反覆確認產品行為的時間（感謝強者前同事 19 教我這個招式）
使用 given - when - then 的格式撰寫 acceptance criteria，就不容易漏掉驗收時需要一併檢查的先決條件和分支路線，可以節省功能交付後才回過頭來東敲西補的時間
把 acceptance criteria 變成自動化測試的 test cases，就不容易記錯預期的產品行為，可以節省工程師翻閱 source code 回答 PM 問題的時間，也可以降低重構時把既有功能搞壞的機率
去年中的時候，也就是我轉職前端工程滿四年無法再藉由自稱菜鳥來逃避責任的時候，因為團隊裡寫規格的人手不夠，開始兼任文件寫手的工作
團隊成長的代價
轉職前端的頭兩三年，團隊很小，PO、QA、客服由同一條龍同一位同事擔任，任何事情問他就能得到最終答案。因為有這麼一個會走路的 single source of truth，開發過程中幾乎沒有寫文件的必要，同事從客戶那邊帶回新需求時，會找前後端一起討論，我出 wireframes 確認以後，大家就各自散開寫 code。當時這個以一條龍為祭品 conversation over documentation 的模式，從工程師的角度看，覺得運作得蠻順暢的
後來團隊跟著產品一起出售，來到一間比較大的公司，產品變複雜分工變細，溝通協調的難度也跟著變高
首先遇到的問題，是層層轉達造成的資訊衰減。客戶的意見過了 N 手、抵達工程師這裡時，我們只知道「決定要做某某功能了」，但究竟是為了滿足什麼需求、要在什麼情境下被如何使用，這類脈絡性的資訊往往會遺失
除此之外，由於產品範疇變大功能變多，超過一條龍一個人可以負擔的程度，工作自然會被拆到不同人身上。當設計跟前端由不同人處理，對介面行為的認知就會有不同版本；當 PO 跟 QA 由不同人擔任，對驗收標準的認知就會有不同版本；隨著時間過去，每個人的認知還會漸漸變模糊。由於不再有人能擔任祭品產品規格的 single source of truth，單靠 conversation 的溝通就不容易收斂出具體的結論
於是，為了讓資訊不會在多次傳遞之後衰減或佚失，以及為了找回產品規格的 single source of truth，文件的需求就浮上檯面來
