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，文件的需求就浮上檯面來
試誤的過程
剛開始寫規格時，只是把身為工程師覺得開發所需的資訊隨意的列出來。結果，首先就因為格式不統一，導致自己在功能之間切換時，因為必須不斷調整心智模型，而花費不少多餘的力氣
後來想辦法撨（tshiâu）了一套比較固定的文體，卻發生另一個問題，以前我覺得主管提需求時沒把脈絡交代清楚、導致我必須不斷追問，現在換我來寫規格以後，變成我沒把脈絡交代清楚、導致負責實做的工程師必須不斷追問 💦
除此之外，我憑著野性直覺撰寫的驗收條件，常常到內部試用時，才發現忘記考慮在不同環境變數下要有不同的行為，或者擁有不同權限的使用者進入時要提供不同的內容。關於先決條件、或者替代路徑的邏輯，常常會漏掉
後來在室友建議下，讀了 specification by example 這本書，又以 BDD 為關鍵字搜尋了一些網路文章，才終於找到解決方法。自從統一用 as a - I want to - so that I can 的格式撰寫 user story、用 given - when - then 的格式撰寫 acceptance criteria 以後，上述的症狀就大幅緩解了。雖然偶爾還是有些缺漏，但已經是我自己覺得可以接受的程度
現狀
目前的流程，是 tech lead 跟公司高層確認要做的功能後，在 Jira 開 epic ticket 附上 requirement doc，我把 epic ticket 切成 story ticket，工程師再把 story ticket 切成 task ticket，其中只有 story ticket 會送交給 QA 檢查
story ticket 的內容通常會包括
- user stories：利害關係人的立場、意圖進行的操作、想藉此獲得的好處/解決的問題。利害關係人通常是使用者，偶爾會有服務提供者或外部合作對象等
- minimal required UI elements：只列出最低限度需要的 UI 元素，在此之上歡迎設計師跟工程師發揮各自的特異功能來替產品加分
- (optional) definitions：偶爾會有些需要進一步定義的細節，如支援的檔案格式列表、權限列表... 等
- (optional) minimal required API endpoints/schema：如果不是我自己掛 feature owner 的專案，這段通常會轉由負責實做的工程師處理
- (optional) visual/interaction/component design：如果已經有 prototype、或者功能都已經有具體定義，會請設計師製作包括 Figma component 在內的詳細藍圖
- (optional) related React components：可能會用到的前端元件的 storybook 連結，如果負責實做的工程師已經很熟悉內部 UI lib，這段就可以略過
- (optional) known issues in current implementation：需要請設計師跟工程師幫忙發想改善的 UX 層面的問題
- acceptance criteria：要請 QA 人員檢查的項目，等於 end to end test cases，只列出最低限度的驗收條件，在此之上歡迎設計師跟工程師發揮各自的特異功能來替產品加分
會用到的技能
撰寫 user stories 的時候，需要反推目標客群的需求、使用情境、以及自家產品的 product-market fit，跟以前寫 business plan 的感覺蠻像的，會用到商業腦和企劃技能
撰寫 minimal required UI elements 的時候，需要透過 user journey 推演操作流程、規劃介面並製圖說明，跟以前做 UI design 的時候差不多，會用到企劃腦和設計技能
功能比較複雜或抽象的時候，有時會先在前端 repo 開個 poc branch 試做看看，排除不確定因素，這時候會用到工程腦和前端技能
不同階段的挑戰
當功能處於探索期（即將交付 pre-alpha 版本）的時候，有許多不確定因素，為了寫出 user stories，必須學習領域知識、瞭解產業生態、研究競爭產品與替代產品，才有辦法穿上目標客群的鞋子走路。這段期間 input 很多但 output 很少，主要的挑戰是必須想辦法讓主管瞭解自己到底在幹嘛，我目前的作法是在進度報告上把看過的連結列出來，並且簡單的寫些 findings
當功能處於發佈期（即將交付 alpha 版本）的時候，大方向已經確定，相較於探索期，研究工作的比重少很多，規格寫起來也快很多。由於需要設計師的參與，主要的挑戰是協助設計師理解功能，我目前的作法是請 infra 同事把 pre-alpha 版本部署到某處給設計師試用，然後盡可能把設計需求聚焦在特定的 UX 議題
當功能處於改善期（即將交付 beta 以上版本）的時候，通常是因應 user feedback 進行 bug fix 或 UX improvement。由於過程中程式碼往往需要重構，這段期間主要的挑戰是避免改東邊壞西邊，我目前的作法是誠心感謝認真撰寫 unit test 的工程師，然後自己用 cypress 寫 end to end 來測那些 unit test 測不到的地方
結語
目前這份 feature analyst 的職務，以個人主觀感覺算是有上軌道，但有個隱憂一直揮之不去，就是不論何時去逛前端的 job board，都不曾看到「會寫 spec 的前端工程師」這樣的職缺，讓我不由得懷疑這樣的技能組合到底有沒有市場呢？如果這個路線無法讓我爭取到比純工程職更好的 offer，那麼或許接下來得調整自我投資的方向才行了... 😅
沒有留言:
張貼留言