小孩子才做選擇？關於拆分需求的小小心得
在我有限的工作經驗中，對「需求」的感受是經常在不同的工作階段中砸來砸去QAQ。當然，我們有利用 Backlog 把暫時不處理的需求收好，但是總覺得有一些事情是在這之中沒有弄清楚的。
上個月剛好在 MOPCON 聽了程式猿吃香蕉的 Jayden Lin 大神分享「PM 說我全都要！工程師自救的7 種拆分需求技巧」，頓時腦中叮咚了一下，原來一直覺得沒有理清楚的東西就是這個啊！所以決定提筆把自己在拆分需求的小小心得記錄一下。
什麼時候拆？為什麼要拆？
因為不拆做不完啊（誤）！
產品開發流程的探索（Discovery）和交付（Delivery）相信大家早就不陌生了，請想像一個情況：
進入開發的功能比原先預期的還要花費更多的時間或是影響範圍更大，導致交付延期，壓縮到其他功能或項目開發的時間。
這樣的情況很常見，雖然表面上看起來是交付（Delivery）出了問題，但仔細回推，可能是在探索（Discovery）階段對需求的判斷失準了。
UX Designer 或是 Product Designer 經常是 Discovery 階段的主要負責人，而我個人覺得拆分需求可以說是 Discovery 階段的起手式，所謂需求拆的好，時程評估沒煩惱（才沒有XD）。
嘗試讓整個團隊在 Discovery 階段對需求有更近一步的討論，除了提高團隊對下一步的共識以外，對風險的掌握、需求拆分的顆粒也會更加精準。
怎麼拆？水平拆分與垂直拆分
先把產品的分工想像成一塊蛋糕好了，蛋糕有一層奶油、一層蛋糕、一層水果、一層布丁，可以對應到介面元件、體驗流程、前端元件、資料庫…等等。
1. 水平拆分
水平拆分就是根據工作類型，把同一層該做的事情分在一起，例如 UI 介面更新、前端元件更新。
這樣的拆分方式我們有嘗試過，我們曾經嘗試將點點簽（DottedSign）App版的介面做為一個需求進行盤點與更新，實際執行時遇到了以下的狀況：
- 影響範圍無限延伸：原本可能只打算進行一小部分功能的介面更新，結果開始進行後才發現其實影響了整個產品，結果就出現了前面所說的壓縮了交付的情況。
- 缺少合作：當我們把同一職能該做的事情直接切分的時候，就容易進入這就全是那個職能角色該做的事情的思考。以更新介面這個例子來說，我們最一開始就直接由 UI 設計師進行，後來發現這次的更新有新增的顯示資訊是原本沒有的，而這牽涉到後端的 API 有沒有給這些資訊。但我們最初就只有 UI 設計師投入，因此發現這件事情的時間點可能已經延到交付設計稿給 App 工程師甚至進入開發時才發現。
- 投入的成本難以直接轉換成價值：這裡的價值指的是業務面的價值（也就是酷錢錢），單純的介面更新、資料庫優化當然對產品架構、維運都有好處，可是卻沒辦法實際計算出有機會帶來多少獲益，因此優先級（Priority）也就很難估算。
2. 垂直拆分
垂直拆分則是像我們平常切蛋糕一樣，每一塊蛋糕都有奶油、蛋糕、水果、布丁，意思就是拆分下來的顆粒會需要設計、前端、後端等不同職能的人投入。
要達成這種模式我們可以利用情境或是流程來作為拆分的基準，來達成每一個顆粒都可以獨立運行，也就是回到了 MVP（Minimum Viable Product/Prototype） 的概念。
舉個一樣是點點簽的例子，我們有個功能是提供使用者可以將簽署完成的文件備份到雲端硬碟，而同樣是備份功能可能還包含了各種不同的情境。
因此我們將這個功能拆解成：
- 使用者手動備份：由使用者手動點擊備份按鈕，並將當下已經完成的任務全部備份到雲端硬碟上。
- 系統自動排程備份：使用者可設定條件，由系統在達成條件時自動將當下已完成的任務備份到雲端硬碟上。
這兩個顆粒都是獨立的，假設今天時程被壓縮了，單獨做一個功能還是能夠提供使用者新的價值，而且包含了不同職能的投入，我們也在執行之前讓整個團隊投入評估時程與可行性。
一些我常用的拆分策略
我在點點簽團隊裡的角色是產品設計師（PD，Product Designer）在我們目前的團隊，需求可能是從前線（包含 BD、MKT）帶回來的客戶情境，也可能是內部提出的優化。
PM 會負責需求優先級的排序，而 PD 負責將需求轉換成詳細的功能規劃，將功能的價值、使用情境帶回給前線作為與客戶對話和行銷的子彈。
所以拆需求的時間點可能有兩個：
- 需求剛被提出的時候：通常主要和 PM 合作，拆分需求是為了協助 PM 評估優先級。
- 準備要開始進入規劃之前：通常主要和 RD 合作，拆分需求是為了和 RD 確認可行性與評估時程。
下面簡單介紹我常用的拆分策略，當然還是需要按照實際情況，有時候會是多種策略合併使用。
1. 依使用情境拆分
如果需求有包含多個使用情境，通常會是一種可以拆分的方式。
舉一個點點簽的例子，點點簽提供發文者建立有序或是無序的簽署任務，有序代表簽署人會依照順序收到簽署邀請信，無序則反之，所有簽署人會同時收到邀請信。
在這個需求內我們可以這樣拆分：
- 發文者建立一個簽署任務，指定好簽署人後，將該任務設定成需依照順序簽署的有序任務。
- 發文者建立一個簽署任務，指定好簽署人後，將該任務設定成不需依照順序簽署的無序任務。
- 簽署人依序收到任務邀請信，並由信件進入簽署介面。
- 所有簽署人同時收到任務邀請信，並由信件進入簽署介面。
利用這樣的方式，可以簡單判斷每一個顆粒的範圍與情境，並且也可以跟 PM 一起討論優先級：有可能初期先只上有序簽署，觀察市場反應後再評估無序簽署功能需不需要實作。
通常我在進入撰寫 PRD 時，使用情境的部分也都是用這樣的方式來寫：定義好每一個流程的「起點」與「終點」，來確保使用情境中的流程各自是獨立而且可以被拆分。
2. 依 Happy / Unhappy Case 拆分
一個需求通常會涉及多個Happy Case與Unhappy case，正常情況下使用者會按照Happy case的流程走，但有時候會根據不同原因走到Unhappy case。
舉個例子，OTP（One Time Password）是許多產品基本會提供的身份驗證方式，系統會寄送一組驗證碼到使用者的手機號碼，使用者需輸入收到的驗證碼來驗證自己的身份。
在最初我們可以先盡可能考量：
- 使用者點擊發送驗證碼後，通過自己的手機號碼收到帶有驗證碼的簡訊，輸入驗證碼後驗證身份成功。
- 使用者點擊發送驗證碼後，一直收不到簡訊，等待 120 秒後重新點擊發送驗證碼，重新發送後通過自己的手機號碼收到帶有驗證碼的簡訊，輸入驗證碼後驗證身份成功。
- 使用者點擊發送驗證碼後，一直收不到簡訊，等待 120 秒後重新點擊發送驗證碼，重新發送後通過自己的手機號碼收到新舊兩組帶有驗證碼的簡訊，輸入舊驗證碼後提示驗證碼有誤。
- 使用者點擊發送驗證碼後，一直收不到簡訊，等待 120 秒後重新點擊發送驗證碼，仍收不到簡訊，重試 5 次後，系統提示電信端可能有問題，請稍待後再重試。
通盤考量後，功能涉及的範圍會越來越清晰，甚至並不是所有的Unhappy Case都需要實作，例如重試 5 次仍然失敗的提示不一定要做，可以讓使用者一直重試，甚至試到 5 次的情況已經相對極端了，不一定會有很多人碰到。
3. 依平台（裝置）拆分
早期我主要設計的產品通常是跨平台的 App，所以同一支產品可能有 iOS、Android、Windows 等多個平台要顧，甚至 iOS 又區分成 iPad、iPhone，或是有些產品還有 Apple Watch、Mac…。
點點簽則是 SaaS 產品，但我們仍然需要考慮到不同尺寸的使用狀況，這也是大部分 Web 產品的情況。
跨平台（裝置）一直是個難解的題，該有的就全平台都有其實是一個粗暴的解法。
在點點簽內，比起簽署，建立任務並發送給簽署人的流程功能是相對複雜的，因此我們藏在層級比較深的功能可能不會在最初就直接開發到 Mobile Web 或 App 這類版面比較小的裝置上。
考量的除了開發團隊資源的分配以外，在進行這樣的拆分前，團隊評估了大多數的使用者在不同裝置個別會做什麼事情。
4. 依參數/資料拆分
有時候一個功能會涉及多種資料類型作為不同選項，例如搜尋系統就是個相當常見的例子。
在雲端硬碟內，使用者可以利用不同的資料類型作為篩選條件：檔名關鍵字、檔案類型、檔案大小、是否有被手動加上星號、最近開啟時間…等。
在開發時間有限的情況下，不一定需要一次把考慮到的篩選條件實作完成，也許可以先以使用者常用或必須的條件為主，後續再透過優化的方式將其他條件逐步加上。
5. 依操作功能拆分
常見的增刪查改（CRUD，Create、Delete、Read、Update）在考量過情境的情況下也是可以拆分的策略之一。
以印鑑管理系統作為範例來說，若要符合稽核標準，編輯和刪除可能會需要在特定條件下才可以使用（例如該印鑑完全沒有被使用過才能刪除，以確保紀錄）。
在這個範例中，每一個操作功能可能都需要拆開來通盤了解情境和規範，來確保整支功能的合理性。
6. 依使用者角色拆分
涉及不同角色的情況在 B2B 產品很常見，根據每一個角色的用戶數量、權限、角色之前的關係、帶來的獲益等，可以用來確認涉及的流程與優先級。
例如在標籤管理系統內，團隊的管理者可以建立給全團隊成員取用的標籤；而各別的成員也可以建立自己帳戶內可以取用的標籤。
若客戶提出來的情境是希望以全團隊共用的角度來使用標籤系統，則個人帳戶內的標籤功能就會被我們拆開到優先級較低的部分。
7. 依緊急程度拆分
這裡所說的緊急程度是使用者是否會因為這個狀況而無法繼續使用的緊急程度，有時候是 Bug ，但有時候是最初功能規劃不夠完成而需要優化。
我們碰過使用者將夾檔上傳後再下載下來時解析度會被壓縮導致無法辨識的情況，在當時我們將成因拆解成兩個部分：
1. 使用者將表單轉檔成 PDF 後上傳，轉檔時可能會壓縮到解析度
2. 下載多個夾檔時，系統需要 合併 多個檔案，在合併時可能會壓縮到解析度
可能的解法也有：
- 支援更多種夾檔格式，讓使用者不必轉檔，減少轉檔造成的解析度壓縮
- 調整合併時壓縮解析度的程度
而在測試後我們發現主要壓縮到解析度的原因是來自於合併時所造成，因此雖然支援更多種夾檔格式對長遠的產品體驗也有幫助，但短解我們選擇先調整合併步驟。
8. 其他方法
當然，還有很多不同的拆分方式，以下列出給大家參考：
- 根據實作難度拆分
- 根據外部系統整合拆分
- 根據 SEO 需求拆分
- 根據營收多寡拆分
- 根據 Test Cases 拆分
- 根據易用性拆分
那，誰負責拆？
PM不能把需求拆乾淨再給我嗎？
雖然我沒這麼做過，但聽起來好像不錯？
需求拆分是一件相當跨職能的事情。風險的考量、市場的狀況是 PM 較熟悉的部分，但產品架構、系統架構則是 PD 和 RD 熟悉的領域，需求要拆分與優先級排序的基準其實上述缺一不可，因此回到最前面所說，善用團隊內不同角色的職能，除了可以提高團隊共識以外，最後拆分的結果也會更加精準。
所以囉！與其坐等 PM 拆出完美的需求，不如加入他一起拆！
總結
最後，我想借用 Bill Wakes 大神提出的 INVEST 原則來當作總結，在敏捷環境中需求會被以 User Story 的形式記錄下來，但無論是否是在敏捷的環境，我認為這些概念都很適合用來檢視每一次需求的拆分夠不夠恰當。
1. 獨立的（Independent）
拆分出來的需求是各自獨立的，不會互相影響導致無法使用。
2. 可協商的（Negotiable）
拆分後的需求仍然是有調整的彈性，不是逼開發人員或後續接手實作的團隊成員硬吃。
3. 有價值的（Valuable）
每一個拆分下來的需求都對客戶或產品本身有價值。
4. 可估算的（Estimate）
可被準確的估算出價值或排出優先級。
5. 小的（Small）
不一定是越小越好，但是是大小合適的，如果不確定怎樣才算夠小，我個人經驗是可以以團隊的幾個Sprint內完成作為參考。
6. 可測量的（Testable）
需要能夠被驗收測試，以及後續的追蹤。
產品開發相關的事情總是容易回到老話一句：「其實沒有 SOP 。」，實際情況還是回歸到團隊討論，找到最舒服、合適的解法吧。
參考資料
本文策略部分主要參考 10 Powerful Strategies To Break Down Product Backlog Items in Scrum (with cheatsheet) ，以此為基礎並加上個人經驗撰寫而成。
