軟體開發的流程,從瀑布式 (Waterfall)、CMMI、Scrum 等等,有各種專案管理的方法。不過這次想討論是在專案管理過程中,溝通頻率最高的「工作內容」。
我認為「工作內容」除了要完成的事情外,還有「需要交付的時刻」。事情和時刻合起來,就是要達成的「結果」。要完成工作,並不是事情完成就好,而是要達到預期的「結果 (Result)」才對。
功能 (Feature) 需求
我常遇到的狀況,在溝通工作內容(需求)的時候,大家會直接講希望要完成的具體事情是什麼。例如說:「我想要發個Email給平台的用戶」,或是「我想要在這個頁面上多加一個按鈕」。相信各位讀者也會常常收到這種需求說明。這樣的需求說明,我稱他為 Feature (功能) 的需求。這樣的好處有:
簡單、易懂
驗收條件明確
容易評估成本
對於代工生產類型(例如外包)的開發模式,這樣的方式是相當適合的,在合約上也比較簡單,驗收條件明確也能夠容易地判斷履約與否。
不過由於技術進步,訊息的傳遞效率越來越高,因此世界的變化越來越快。原本變化的週期可能是以年來計算的,但現在可能已經不是以「季」來計算,甚至可以說以「日」來計算了。舉例來說,當美軍宣布從阿富汗完整撤軍日期後,神學士只花了十幾日就攻進了首都坎布爾。但幾十年前,可能撤軍的消息才剛傳到敵方的指揮階層裡。
這樣的時代,有一個從1990年代由軍事開始使用的用語VUCA(霧卡)來描述現在變化快速的環境。當環境變化越快、越不確定、越複雜、越模糊的時候,在溝通工作內容時,原本以功能為主的需求說明,就很難產生預期的「結果」。
價值 (Value) 需求
當軟體開發處於現今的環境下,我認為對於產品技術團隊,應該是要以「價值 (Value)」為主來溝通。當溝通的是價值的時候,需求說明可能會是這樣:「我想要通知用戶讓他們知道最新的付費方案」或是「我想要讓使用者可以在平台內留下他們的看法,讓其他使用者能夠讀到並進行討論」等等。
可能有人會覺得,所謂的價值需求比較模糊,反而不太好理解,要花比較多時間在溝通上。但是,產出的「結果」是事情和時刻兩者結合而成的。當把「需要交付的時刻」考慮進去的時候,如果是以功能需求來溝通的時候,常常就會遇到需要取捨的問題,也扼殺了創意與新方法的誕生可能性。
用價值需求來溝通的好處:
能夠快速驗證:用短時間先產生解決方案,確認客戶想要的價值是不是原先想像中那樣
創意與新方法:創意與新方法一定是在有限的資源下才能產生
能延遲決策:在開發過程當中,滿足客戶想要價值的同時,也能收集更多資訊以便做出產品長相最終的決定
那現在,什麼時候用功能需求來溝通呢?
雖然前面講了很多價值需求的優點,但並不是功能需求的溝通方法就一無是處。我認為用功能需求來溝通有幾個適合的地方:
已經處於成熟期,變化不大的產品
外包開發的軟體:這個是需要有內部同仁來轉譯,將價值需求轉換成可以在時間內完成且有價值的功能,才能夠變成功能需求來溝通
團隊還沒成熟,需要用功能需求來溝通才聽得懂:這也需要有其他人來轉譯
User Story
大家常聽到的使用者故事(User Story)其實就是一種價值溝通的工具。使用者故事是以客戶或使用者的觀點寫下軟體如何跟使用者互動,進而推動開發工作。舉例來說:
使用者想使用圖片來描述他想要找的網頁內容,希望可以提供圖片後,軟體(搜尋引擎)可以找出與該圖片主題相關的網頁。
這個例子是圖片搜尋的 User Story。這個 User Story 可以拆成以下的幾個 Feature:
需要把圖片的特徵找出來
把特徵與已經在資料庫內的圖片作比較
顯示相關的圖片所連結的網頁
也可以拆成以下的幾個 Feature:
需要判斷圖片是代表什麼,以英文呈現
用英文去搜尋資料庫裡面的內容
顯示相關內容所連結的網頁
我想大家應該可以舉出更多的 Feature Set。這些 Feature Set 在不同的團隊或產品裡,需要的成本與時間一定是不同的,因此團隊可以選擇在時程內能夠滿足價值需求的解決方案。
#技術管理閒聊 系列不定期出刊,如果您覺得有幫助,歡迎分享出去讓更多人看到。
如果你除了本系列文章,還想收到定期出刊的 #技術管理觀點 系列,歡迎輸入 Email 訂閱電子報。
技術管理閒聊:Feature & Value