技術管理閒聊：Feature & Value

軟體開發的流程，從瀑布式 (Waterfall)、CMMI、Scrum 等等，有各種專案管理的方法。不過這次想討論是在專案管理過程中，溝通頻率最高的「工作內容」。

我認為「工作內容」除了要完成的事情外，還有「需要交付的時刻」。事情和時刻合起來，就是要達成的「結果」。要完成工作，並不是事情完成就好，而是要達到預期的「結果 (Result)」才對。

功能 (Feature) 需求

我常遇到的狀況，在溝通工作內容（需求）的時候，大家會直接講希望要完成的具體事情是什麼。例如說：「我想要發個Email給平台的用戶」，或是「我想要在這個頁面上多加一個按鈕」。相信各位讀者也會常常收到這種需求說明。這樣的需求說明，我稱他為 Feature (功能) 的需求。這樣的好處有：

1. 簡單、易懂

2. 驗收條件明確

3. 容易評估成本

對於代工生產類型（例如外包）的開發模式，這樣的方式是相當適合的，在合約上也比較簡單，驗收條件明確也能夠容易地判斷履約與否。

不過由於技術進步，訊息的傳遞效率越來越高，因此世界的變化越來越快。原本變化的週期可能是以年來計算的，但現在可能已經不是以「季」來計算，甚至可以說以「日」來計算了。舉例來說，當美軍宣布從阿富汗完整撤軍日期後，神學士只花了十幾日就攻進了首都坎布爾。但幾十年前，可能撤軍的消息才剛傳到敵方的指揮階層裡。

這樣的時代，有一個從1990年代由軍事開始使用的用語VUCA（霧卡）來描述現在變化快速的環境。當環境變化越快、越不確定、越複雜、越模糊的時候，在溝通工作內容時，原本以功能為主的需求說明，就很難產生預期的「結果」。

價值 (Value) 需求

當軟體開發處於現今的環境下，我認為對於產品技術團隊，應該是要以「價值 (Value)」為主來溝通。當溝通的是價值的時候，需求說明可能會是這樣：「我想要通知用戶讓他們知道最新的付費方案」或是「我想要讓使用者可以在平台內留下他們的看法，讓其他使用者能夠讀到並進行討論」等等。

可能有人會覺得，所謂的價值需求比較模糊，反而不太好理解，要花比較多時間在溝通上。但是，產出的「結果」是事情和時刻兩者結合而成的。當把「需要交付的時刻」考慮進去的時候，如果是以功能需求來溝通的時候，常常就會遇到需要取捨的問題，也扼殺了創意與新方法的誕生可能性。

用價值需求來溝通的好處：

1. 能夠快速驗證：用短時間先產生解決方案，確認客戶想要的價值是不是原先想像中那樣

2. 創意與新方法：創意與新方法一定是在有限的資源下才能產生

3. 能延遲決策：在開發過程當中，滿足客戶想要價值的同時，也能收集更多資訊以便做出產品長相最終的決定

那現在，什麼時候用功能需求來溝通呢？

雖然前面講了很多價值需求的優點，但並不是功能需求的溝通方法就一無是處。我認為用功能需求來溝通有幾個適合的地方：

1. 已經處於成熟期，變化不大的產品

2. 外包開發的軟體：這個是需要有內部同仁來轉譯，將價值需求轉換成可以在時間內完成且有價值的功能，才能夠變成功能需求來溝通

3. 團隊還沒成熟，需要用功能需求來溝通才聽得懂：這也需要有其他人來轉譯

User Story

大家常聽到的使用者故事（User Story）其實就是一種價值溝通的工具。使用者故事是以客戶或使用者的觀點寫下軟體如何跟使用者互動，進而推動開發工作。舉例來說：

使用者想使用圖片來描述他想要找的網頁內容，希望可以提供圖片後，軟體（搜尋引擎）可以找出與該圖片主題相關的網頁。

這個例子是圖片搜尋的 User Story。這個 User Story 可以拆成以下的幾個 Feature：

1. 需要把圖片的特徵找出來

2. 把特徵與已經在資料庫內的圖片作比較

3. 顯示相關的圖片所連結的網頁

也可以拆成以下的幾個 Feature：

1. 需要判斷圖片是代表什麼，以英文呈現

2. 用英文去搜尋資料庫裡面的內容

3. 顯示相關內容所連結的網頁

我想大家應該可以舉出更多的 Feature Set。這些 Feature Set 在不同的團隊或產品裡，需要的成本與時間一定是不同的，因此團隊可以選擇在時程內能夠滿足價值需求的解決方案。

---

#技術管理閒聊 系列不定期出刊，如果您覺得有幫助，歡迎分享出去讓更多人看到。

如果你除了本系列文章，還想收到定期出刊的 #技術管理觀點 系列，歡迎輸入 Email 訂閱電子報。