軟件項目發掘需求的技巧

軟件開發項目在需求上的不確定性遠比其他基建類型的項目要大得多，因此如果不在早期把用戶的期望和最終系統投入使用時實際的情況拉近的話，在用戶實際使用的時候，就會出現大量軟件不好用或不能解決＂某問題＂為由而要求修改系統的意見。如果相關方比較少的，又或者要解決的問題並不複雜的話，還比較好解決。但是如果項目相關方比較多又或者要解決的問題比較複雜的話，修改系統就不是一件容易的事了。這樣很容易使項目出現長尾的現象，要破解這種現象的發生，早期的投入是必不可少的。這一篇文章希望討論早前發掘需求時所投入的內容。

軟件系統存在的本質

我認為軟件系統存在的本質就是資料的處理。

在文章最初我先說一下軟件系統存在的本質，這是因為所有的需求幾乎都是圍繞在這個本質上進行的。試想一下我們使用軟件系統一般都是做些什麼？例如文書或筆記軟件是處理文字資料、繪圖軟件是處理圖像資料、銀行系統是處理數字資料。總而言之，軟件系統就是一個處理資料的工具而己。而資料的處理最複雜的往往不是處理的過程而是應該如何處理，即需要對應某種情況的前題下，系統應該如何把原始資料變成一些對我或下一個位處理者有意義的資料。而這裡最大的不確定就是＂某種情況＂到底包括有多少種情況。而我認為這種不確定就是讓項目進入長尾效應的真實原因。

下面介紹三種需求發掘和確認的方法，盡可能提前讓使用者表明系統要處理的各種情況和不能處理的情況。讓使用者能提前知悉未來的情況，使他們不會在收到系統的那一刻，才給予各種不同的意見。三種方法分別是：

• 先確定已經被滿足的需求

• 展示實際的未來

• 記錄系統的能力

以下就讓說明以上三點的詳情。

先確定已經被滿足的需求

在和用戶們討論他們需求時，幾乎可以想像到他們在不停地申訴著各種的事情，例如他們想要系統具備一些什麼樣的功能、系統能做到些什麼或是界面或操作要多麼的好看和方使等的要求。但是在這裡存在一個很大的陷阱，就是他們並沒有說出現在使用中的系統／工具滿足了的需求有那些。這個沒有說出來的內容，就是使用者在他們心中默認新系統應該要具備的能力。這個沒有說出來的部份往往是項目進入長尾的根本原因。

在使用者角度，原來能輕易完成的事情在換新系統後可能變得不能完成或是需要很複雜的方式才能完成，的確是會令人感到失望的。這種情況，往往是在使用者正式使用新系統的時候才會發現，即在項目很後期的時候（項目使用敏捷管理方式除外）。這個時候他們必然會帶出大量「原系統都能」的詞彙並要求解釋新系統為何不可以達成，而且他們投入大量的金錢就是為了改善現在資料處理的能力，不可能接受在更換系統後某些情況反而變差。此看以合理的動機在系統供應者眼中或許難以敵得過對方的糾纏，最終修改系統的設計和功能，並在修改系統後再次發掘對方「原系統都能」的需求。我們需要知道，在系統功能快要開發完成的當下，修改系統的成本是十分高昂的。因為對已經完成設計的功能和邏輯作修改的話可能會引致更多的問題，這樣項目必然會陷入長尾效應當中。

我十分建議項目在早期討論需求的時候，先了解他們現在是如何工作的，比了解他們的需求更加重要。除非項目團隊中已經有一位很了解客戶行業的人參與，能準確地知悉對方需要處理的資料和情況有那些，否則請先把已經被滿足了的部份先填好。

展示實際的未來

由於軟件項目的特性，它注定是以模糊的未來開始的。每一位項目參與者腦中所想的系統必然都不盡相同，即使可能他們口中描述的場景都差不多，也可能在細節的處理上不盡相同。因此在嘗試滿足使用者的需求時，把未來系統的樣貌和如何操出先展示出來，是十分重要的。

我自己習慣先使用流程圖先引導對方回顅及了解他們各部門現在處理資料的方法，再使用系統原型圖的方式展現流程圖中的每一步，說明未來他們應該如何和系統互動。以外賣APP為例．客戶是如何由選餐廳到下外賣訂單的，餐廳是如何處理收到的訂單的，送餐的是如何完成送餐等。

在這個展示的過程中，不可不向參與者說的是意外情況的處理。例如客戶點的餐點已售完、餐廳沒收到訂單、客戶希望更改已經下單的食物、送餐的人在中途受傷了不能繼續送餐意外的情況等。以上的一切都必須要在項目的前期和項目的相關方討論清楚，即系統要如何處理上述那些情況，又有那些情況是可以暫時不作處理或使用系統外的方法先處理的。當用戶能在前期了解到未來的情況是如何的話，則能降低他們的不確定性，也能收斂對方的幻想和期望。

記錄系統的能力

人的記憶力是有限的，即使在項目前期已經討論了很多東西，也難以把所有的情況一一講出來。因此通過文字和圖畫把所有沒能在會議中一一展示的功能，或在會議中沒有被對方注意的內容寫出來，讓對方能在有空的時候才檢查和回顧，這更能讓用戶在早期知道更多關於系統各方面的細節。

如果系統的能力沒有文字記錄的話，則在項目進行的過程中，人們會慢慢忘記當初所討論的內容。而且在項目進行的過程中，可能外在環境已經發生了某些變化。因此可能會影響系統應該需要的功能，所以只有具備詳細的文字記錄，才能確保軟件能被正確開發，並減少項目後期因為系統功能的缺失而引發的爭執。

後記

軟件項目的需求發掘一直是一個複雜的內容，它需要跨領域的知識和技能才能有效完成。