專案經驗總結

使用者需求就是能幫使用者解決實際問題的一套解決方案。

在經歷過多年的企業專案之後，發現專案中最大的風險來自於使用者需求的變更。需求變更產生風險的最大原因在於未做好需求處理，所以在此希望和大家**下企業應用的需求處理。

先給大家舉乙個未處理好需求的例子：使用者說要做乙個實時監控的功能，要監控網路中實時發生的問題，等我們做完之後，使用者才發現實時監控發生的問題資料量太大太多，根本看不過來，也不知道什麼問題是重點，然後使用者要求修改為監控統計資料，然後我們就又重新做了一遍。

沉思一下。。。。。。。。

需求處理中遇到的問題：

需求不斷：使用者往往今天說要這明天說要那，你不知道使用者的需求何時是個盡頭？也不知道應不應該滿足客戶提出的需求？

需求總變：你埋怨客戶總是變更需求，使用者說你是專業人士你應該能分析出我想要的，怎麼乙個需求搞這麼久都搞不定呢？

所以需求處理人員需要具備：

1：對產品的理解以及對對產品功能的熟悉。

2：對專案的理解以及對專案範圍和邊界的把握。

3：站在比使用者更高的層次思考需求，因此你必須具備使用者的業務知識。

4：善於引導使用者，我們做專案目的是為給客戶帶來價值，而不是滿足客戶的需求。

5：分析使用者：使用者是技術型，管理型還是飯桶型的，技術性的喜歡抓細節，管理型的喜歡抓整體，飯桶型提不出什麼需求，都會說介面不好看。

需求處理人員必須得清楚：

1：使用者描述需求時表述的那些話不一定是使用者需求。

2：使用者所說的需求不一定是使用者想要的需求，描述和想象始終會存在差距。

3：誰是真正能拍板的使用者。

4：需求的滿足需要乙個過程。

5：使用者的需求基本都是拍腦門說出來的，很少是冥思苦想了很久。

6：大多數情況下，需求沒有變，而是你沒理解使用者真正的需求。

需求分析的過程

將使用者的所提出的需求，放到使用者的業務場景中去分析，分析使用者是想解決乙個什麼問題，是否能為使用者帶來價值。這個需求到時候是否能真正用起來，這需要考慮使用者的組織結構，部門角色，使用者的推動力。

此需求是否屬於專案和產品範圍之內，不是則不做。

確認需求之後，思考該需求是否會存在衍生需求，然後思考下是否能否那我們產品中已有的功能變相的來滿足客戶的需求。

如果確認需要開發，需要鑑定該需求我們是否能做，做多久，做初步的可行性分析。

需求處理

將分析出來的需求，同使用者確認，有介面的最好用原型法，假如使用者不和你確認（我遇到的大多數情況是這樣的），你可以發一封郵件給使用者，並說請您確認下需求，假如沒有異議，我們後天就按照這個開始做了。不回你就表示使用者預設了。

需求歸類：該需求是專案需求還是產品需求，是否能產品化？劃分到產品的哪乙個版本裡？