使用者真正需求的弔詭

在本期的程式人單元，王建興在專欄中探討一個一直困擾著開發團隊的大問題：找出使用者真正的需求。他從開發團隊的角度分析，要找到使用者真正的需求的確很困難，但如果沒找出真正的需求，軟體開發專案最後也不會有好下場。

他提醒軟體規畫者：加法容易、減法難，千萬不要掉入專家陷阱，就自己一股腦想出一個又一個理所當然應該要有的強大功能，而不顧使用者真正的需求，最後把軟體變成一個四不像，什麼都有，卻什麼都不是，落得勞民傷財的下場；開發人員既怨聲載道，而消費者又不埋單。

原本開發軟體是要創造競爭優勢的，但若沒有把使用者真正的需求謹記在心，最後結果可能反而會捅了自己一刀。所以他建議，在規畫軟體功能時，減法要比加法來得重要。

我過去曾經是提需求的人，對這篇文章感觸良多，建議開發團隊可以好好思索這篇文章的內容。

這讓我聯想到另一件事情。就以眾人推崇的蘋果來說，應該沒人敢否認蘋果的軟體開發團隊是頂尖高手，因為蘋果設計的軟體人人稱讚，大人小孩一用就上手。所以，蘋果出手一定是精準，絕非我等這樣規格改來改去折騰開發人員。然而，如果你曾經一路追隨iOS 7的測試版本，你就會發現事實並非如此。

iOS 7的操作介面首度換成平面化風格，光是大家最熟悉的「滑動解鎖」功能的設計，在測試版過程就修改了好幾次。最初是採用貫穿整個螢幕的色塊按鈕，後來又改為在螢幕兩側都留空的色塊按鈕，最後正式版則是連色塊都沒了。

你可以看到蘋果不斷在嘗試，以找到最好的設計。這也說明了，要滿足使用者的需求，可不是靠天才大手一揮就決定，而是一次又一次的調整方向。那麼，一開始就期待依照使用者真正的需求來開發，其實很難。

開發軟體並不難，但是要做出使用者喜愛的軟體，卻大不易。一方面軟體被期待要有創意，滿足人們各式各樣的需求，然而軟體的本質卻是一絲不苟的工程。

在創意的這一端，靈光一現的靈感式創意是少之又少，大多數是不斷顛覆自己的想法，也就是一再嘗試錯誤，在嘗試中找到創意。

然而，軟體開發的另一端是工程，工程要求的是嚴謹，設計精準、按圖施工。如果需求規格一直在變，那就很像房子蓋錯又打掉重建，徒勞無功。雖說軟體開發不如其他工程要投入材料成本，做錯重來要付出的成本代價相對低，但軟體開發錯誤導致的人力成本損失也不容忽視。

該如何避免一再打掉重做？從工程的角度來看，就是藍圖設計清楚，按部就班施工。套用在軟體開發上，就是功能規格定義清楚，亦即找出軟體使用者真正的需求。

因此，需求訪談、分析被認為是軟體專案成功的第一步，倘若沒做好需求訪談，找不出使用者真正的需求，必然就會導致軟體專案最後的失敗。開發者在這樣的認知下，就會期待依照一個像鐵一般不會改變的規格需求來施工。這也說明了，「要殺一個程式設計師不需要刀，改三次規格就好。」的說法。

我倒認為開發者不應期待規格是不會改變的，而是一開始就為了「規格一定會變來變去」做好準備，因為大多數完美的設計都是歷經一次又一次的修改，而不是有個天才一次定案的。

當然，軟體開發絕對是工程，工程變更絕對要付出成本代價，所以，需求端或是規畫者也必須尋求新的方法，例如採用擬真的雛型設計工具，讓自己更早感受到軟體的實際操作與呈現，就能在設計階段盡早修改，以減少變更的機會。

面對變化更快的未來，開發團隊與其祈求有明確不變的需求規格，倒不如視需求變動為常態，找出如何因應需求變動的工作方法。