需求是什麼呢？很多時候，開發人員只會接觸到規格，雖然僅有規格但是對於很多工作環境來說，已經是非常好的了，很多時候，只是需求提供的相關人員以口頭傳達。

開發人員真心難以接觸到需求，當然就不太可能了解什麼是需求。

如果以一個現實世界中的例子來說明需求是什麼：肚子餓。還有沒有其他的呢？令人沉迷、讓人感到滿意、讓人感到驚喜。

從上面的例子來分析，可以拆解成為:

• 痛點：令人感到不舒服，甚至產生真實疼痛的項目。
• 癢點：令人沉迷而無法擺脫，每每遇到類似的資訊，就會想到它。
• 爽點：令人驚喜的，雖然當前已經感到滿足，但是有了這些項目之後，就令人感到更滿意了。

我知道上面的用詞有那麼一點不學術，但是真的是太寫實，實在是讓我很難放棄使用它們。不過，我們該怎麼挖掘出利害關係人的需求呢？

按照團隊對於系統的利害關係人的了解程度，從初步的認識，理解結構和關係，洞悉行為背後的緣由。這三個層次的選擇，需要先盤點開發團隊自己在什麼樣的程度，正如孫子兵法所說：知己知彼，百戰不殆。

初步認識

當開發團隊對於利害關係人僅有初步的認識，甚至是不甚了解僅停留在盲猜或是自行強加定義說明和解釋。有以上狀況，團隊就是處於初步認識的階段。在這個階段，要加強團隊對於利害關係人的組織結構的了解。可以利用組織圖來加強說明利害關係人彼此之間的關係。有了組織圖之後，就能快速判斷哪些利害關係人該怎麼規劃「溝通計畫」。

溝通計畫讓團隊知道發生什麼事情的時候，在溝通這個維度的處理方式 (SOP) 是什麼？畢竟溝通對於執行力是有絕對的直接關係。

理解結構和關係

有了上一階段的組織圖之後，開發團隊會知道該訪談那些利害關係人，因為訪談本身就是一項成本較高的專案活動之一，因此，基於把錢花在刀口上的思維，選擇正確的訪談人就是需求探索成功的第一大步！

需要針對訪談人設定「訪談綱要」，不能是毫無方向和目的詢問，更甚至有可能無意間引導訪談者回答自己期望的答案。

該如何設計訪綱呢？從當前開發團隊的需要為出發點。開發團隊對於某些腳色感興趣，為了能夠順利製作出這些腳色的畫像 (Profiling)，開發團隊可以先臆測腳色的特色和特性，以及它們的：痛、癢、爽點。並且標記那些項目是需要優先獲得的資訊，這些就會被列在必要詢問的問題。

蒐集完訪談者的資訊，接下來就可以使用：觀點 (Point of View) 和解決方案 (How My We) 進行團隊內的思考。團隊集體思考是重要的，在這個過程中，開發團隊會對於需求有更多的參與和認識。

將問題和解決方案的關係展開之後，開發團隊就理解了需求的結構和問題以及對應的解決方案兩者之間的關係。

洞悉緣由

人們常說，山不轉路轉。人也是這樣的，當遇到困難或是與預期的差異，人們會有應對的方式，而這些可行的解決方案就會慢慢成為習慣。想要洞悉利害關係人為什麼會有某些行為，其背後的思考和遇到的問題，可以採用「逆向工程」，從知道解決方案不斷地回推，就能逐漸洞悉緣由。

開發團隊為什麼要進行需求探索呢？因為對於開發團隊來說，最慘痛的惡夢就是開發出沒人要使用的功能，或者是說，沒人要掏腰包的功能。畢竟功能已經開發了，也上線推廣了，成本已經花出去了，實在是讓開發團隊感到意冷心灰。

如果開發團隊能夠幫利害關係人做決定就好了。這正是需求探索真正的價值。為什麼要花力氣在需求探索上，不為什麼，要得就是每次開發花出去的成本，都能獲得可觀的利益。

結語

需求探索可以視為是開發團隊一項很重要的專案項目，在開發的初期，需求探索的活動會較為頻繁，到了後期之後，預期開發團隊對於需求的理解已經有一定的程度了，自然就會降低需求探索的活動次數。

需求探索最終期望能夠讓開發團隊具備：幫利害關係人做決定。