Project 🚩軟體需求管理：你應該要知道的五件事
筆者任職 Yahoo ，《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師 (文末有折扣碼限時 8折)
Hi 大家好，我是 Jayden，先前曾經撰寫系列文分享我在外商進行跨國軟體開發的心得：
在我的職涯中，因為帶團隊的關係，處理過大大小小各種軟體需求管理的狀況，以下總結了五件我認為「應該要知道的五件事」，一起來看看吧！
▍1. 儘早引入使用者的參與
做軟體絕對不是「閉門造車」
- 如果是盈利產品，我們做出來的產品是需要受到商業市場的檢驗的，很少有人可以如賈伯斯 (Steve Jobs) 般天縱英才，不跟使用者溝通就做出使用者願意買單的產品。
- 如果是內部系統，也要尋求公司內部同仁的反饋。然而在業界當中，商業部門 (Business Unit) 與開發部門的對立並不少見，衝突不能解決問題，在缺乏交流的情況下，「想要的功能沒人做，做完的功能沒人用」更是時常發生。此外，在公家部門，外包廠商開發後，強迫單位使用的案例更是屢見不鮮。
這些產品的失敗，都可以歸咎在需求管理時，就忽視了使用者的參與。
要解決這些問題，我們可以透過 Persona 方法 (如上圖所示)，描繪我們的使用者樣態，進而鎖定我們的目標客戶，精準設計相對應的產品，或是邀請使用者實際試用產品，給予我們反饋 ，例如：Yahoo 早期有舉辦使用者之夜 ( User Night) 的傳統，讓工程師可以和使用者直接對話 (如下圖所示)，在軟體需求中及早納入使用者的回饋，可以避免我們做出不符合現實的產品。
▍2. 配合時間框方法 (Timeboxing) 循序漸進
在現代 (Modern) 的軟體開發方法當中，一次性地完成大量前期設計 (Big Upfront Design, BUFD) 的作法已經被廢棄。現在更強調的是：隨著時間過去，我們對專案內容愈來愈理解之後，再做出更多的決定 (Decision)。
以譬喻的方式來說，當你在買賣股票的時候，你不會在還不了解股票市場時，就做出許多買賣的決定 (Decision)，你會隨著時間，愈來愈了解股票市場之後，再做出愈來愈多的決定，軟體開發也是一樣的道理 (如下圖所示)。
因此，在軟體需求管理中，一口氣將所有需求列舉完的方式也已經不合時宜，而是會切分時間框 (Timebox) ，依序將需求整理出來，下圖動畫是以一周為單位的時間框來進行專案，意即每一週隨著對專案的了解程度提高，逐步調整需求內容。
時間框的區間劃分，可以依照實際專案情況調整，不一定要以一週為單位。不過要特別注意的是，時間框方法 (Timeboxing) ，一旦開始執行後：
「內容可以調整變化，但是時間不可以變化」
這是時間框方法的重要特色，這樣做有以下幾點好處：
- 快速驗證需求：因為時間框限制，開發內容會被切分為許多小任務放進時間框內，因此能夠快速看到部分成品，驗證需求是否符合目的。
- 保證重要的需求先做：因為時間框限制，如果截止時間快到了但是預計的任務還沒做完，就可以削減任務，捨棄較不重要的任務，保證重要的任務先完成。
因此，將需求管理配合時間框方法 (Timeboxing) 循序漸進地進行，可以更有效地完成專案。
▍3. 不能只靠文件 (Documents)
Stop exchanging documents
Tell me your story.
— Kent Beck
軟體開發大師 Kent Beck 這句話的意思是說：需求溝通不該只是文件間的交換，更重要的是人和人的交流。在真實的專案場景也是如此，我沒有見過只依靠寫文件就做好需求管理的專案，甚至是文件寫得愈精美，管理狀況反而愈差。
在實務上，除了文件之外，我們會透過使用者故事(User Story)、使用者案例 (Use Case) 或是事件風暴(Event Storming) 等方法釐清需求(如下圖所示)，經由反覆的對話來建立共同的認知，也會透過「可用的軟體」(Working Software) 來驗證結果和交流想法。在需求的溝通上，這些方法都比單純的文件交換更為有用。
▍4. 問題導向 (Problem-oriented) 到解法導向 (Solution-oriented)
當你只提出「我要一匹更快的馬」
那你永遠無法發明出汽車和火箭
顧名思義，問題導向 (Problem-oriented)的需求說明方式，會更貼近問題本身，而解法導向 (Solution-oriented)的需求說明方式，則限制了解決方案，以下為範例：
❌ 我要一匹更快的馬 (解法導向：限制了解決方案)
🟢 我要能更快地到達目的地 (問題導向：不限制解決方案，能有更多創新)軟體產品更是如此，以解法導向來提出需求等於限制了工程師的創意，因此在需求討論時，要從問題導向 (Problem-oriented)的需求開始討論，再慢慢推導出解法導向 (Solution-oriented)的需求，不要在一開始就限制了產品的發展。
▍5. 軟體開發的 60/60 法則：系統限制很重要
在軟體的生命週期中，平均來說，總共有 60% 的時間花在維護舊有的程式碼(軟硬體升級、功能強化、Bug 修復)，在維護時，又有平均 60% 花在使用者引發的功能強化，這樣的現象稱為「軟體開發的 60/60 法則」。
這個法則非常重要，讓我們以全新的觀點來看軟體開發這件事情：我們做「新」的開發其實佔比不多，更多時候我們是在和「舊的程式碼相處」。因此，在需求規劃時，考量目前的「系統限制」，確保目前的程式碼保持「可維護」便十分重要了，例如：
- 是否要安排時間處理技術債 (Tech Debt)？
- 目前採用的平台 (e.g. iOS 或是 Android) 會不會影響我們添加新功能？
- 目前的軟體架構是否需要調整？
- 軟體和硬體是否需要進行升級？
在實務上，你不可能永遠無視系統限制這個現實因素：因為如果該升級的機器不安排升級、軟體架構不當卻不調整、軟體品質太差難以維護，工程師會直接在需求規劃會議裡面說：「這個需求做不了，改不動了。」
在需求規劃時一定要評估系統限制，將其作為風險考量，然而，可能許多 PM 因為不熟悉技術，或單純認為「這是工程師的事」，較容易忽略這部分的重要性，「系統限制」問題通常是造成專案進行不下去的最大原因，也是最大的風險。
▍小結
總結以上五件事，分別為：
- 儘早引入使用者的參與
- 配合時間框方法 (Timeboxing) 循序漸進
- 不能只靠文件 (Documents)
- 問題導向 (Problem-oriented) 到解法導向 (Solution-oriented)
- 軟體開發的 60/60 法則：系統限制很重要
這些都是在軟體需求管理當中非常重要的觀念，也是我在實際操作需求管理時，會不時提醒自己的事。以上的分享，希望對大家有幫助。
最近我開設一門《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程，談怎麼將天馬行空的需求整理成工程師理解的規格，目前在 Hahow 平台上線募資，募資在 5 天內就突破 200% ，確定會開課了。
我目前還有些許折扣碼，數量不多，可以用募資價 8 折獲得課程 (原價57折)，前150名購買再加碼抽 10 本歐萊禮好書，如果對課程有興趣的話，可以直接私訊 程式猿吃香蕉 FB 粉絲團，就說在 Medium 看到這篇文章就可以了。
課程連結：https://hahow.in/cr/rqmt-intro
若是喜歡我分享的內容，歡迎幫我按個拍手，可拍 50下，給我一點鼓勵，或是加入我的粉絲團《程式猿吃香蕉🍌》，一起分享軟體知識與心得！
