Project 🚩軟體需求管理:你應該要知道的五件事

Jayden Lin
Jul 28 · 8 min read

筆者任職 Yahoo ,《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師 (文末有折扣碼限時 8折)

(圖片來源:www.level12.io)

Hi 大家好,我是 Jayden,先前曾經撰寫系列文分享我在外商進行跨國軟體開發的心得:

在我的職涯中,因為帶團隊的關係,處理過大大小小各種軟體需求管理的狀況,以下總結了五件我認為「應該要知道的五件事」,一起來看看吧!

▍1. 儘早引入使用者的參與

做軟體絕對不是「閉門造車」

  • 如果是盈利產品,我們做出來的產品是需要受到商業市場的檢驗的,很少有人可以如賈伯斯 (Steve Jobs) 般天縱英才,不跟使用者溝通就做出使用者願意買單的產品。
  • 如果是內部系統,也要尋求公司內部同仁的反饋。然而在業界當中,商業部門 (Business Unit) 與開發部門的對立並不少見,衝突不能解決問題,在缺乏交流的情況下,「想要的功能沒人做,做完的功能沒人用」更是時常發生。此外,在公家部門,外包廠商開發後,強迫單位使用的案例更是屢見不鮮。

這些產品的失敗,都可以歸咎在需求管理時,就忽視了使用者的參與。

(Persona 範例)

要解決這些問題,我們可以透過 Persona 方法 (如上圖所示),描繪我們的使用者樣態,進而鎖定我們的目標客戶,精準設計相對應的產品,或是邀請使用者實際試用產品,給予我們反饋 ,例如:Yahoo 早期有舉辦使用者之夜 ( User Night) 的傳統,讓工程師可以和使用者直接對話 (如下圖所示),在軟體需求中及早納入使用者的回饋,可以避免我們做出不符合現實的產品。

(Yahoo 早期的使用者之夜活動)

▍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下,給我一點鼓勵,或是加入我的粉絲團《程式猿吃香蕉🍌》,一起分享軟體知識與心得!

程式猿吃香蕉

喜歡將軟體知識以簡單生動的方式講給你聽

程式猿吃香蕉

『來點更營養的軟體知識,吃香蕉吧!』我們是一群軟體開發愛好者,喜歡將軟體知識以簡單生動的方式講給你聽,順口好消化,營養又健康!

Jayden Lin

Written by

Yahoo 擔任 Lead Engineer,負責廣告系統,帶團隊做跨國開發。也是《程式猿吃香蕉》團隊創辦人,喜歡將實用的軟體知識以簡單生動的方式講給大家聽 😄😄😄

程式猿吃香蕉

『來點更營養的軟體知識,吃香蕉吧!』我們是一群軟體開發愛好者,喜歡將軟體知識以簡單生動的方式講給你聽,順口好消化,營養又健康!