做好需求處理
用戶需求就是能幫用戶解決實際問題的一套解決方案。
在經歷過多年的企業項目之後，發現項目中最大的風險來自於用戶需求的變更。需求變更產生風險的最大原因在於未做好需求處理，所以在此希望和大家探討下企業應用的需求處理。
先給大家舉一個未處理好需求的例子：用戶說要做一個實時監控的功能，要監控網絡中實時發生的問題，等我們做完之後，用戶才發現實時監控發生的問題數據量太大太多，根本看不過來，也不知道什麼問題是重點，然後用戶要求修改爲監控統計數據，然後我們就又重新做了一遍。
需求處理中遇到的問題：
需求不斷：用戶往往今天說要這明天說要那，你不知道用戶的需求何時是個盡頭？也不知道應不應該滿足客戶提出的需求？
需求總變：你埋怨客戶總是變更需求，用戶說你是專業人士你應該能分析出我想要的，怎麼一個需求搞這麼久都搞不定呢？
所以需求處理人員需要具備：
1：對產品的理解以及對對產品功能的熟悉。
2：對項目的理解以及對項目範圍和邊界的把握。
3：站在比用戶更高的層次思考需求，因此你必須具備用戶的業務知識。
4：善於引導用戶，我們做項目目的是爲給客戶帶來價值，而不是滿足客戶的需求。
5：分析用戶：用戶是技術型，管理型還是飯桶型的，技術性的喜歡抓細節，管理型的喜歡抓整體，飯桶型提不出什麼需求，都會說界面不好看。
需求處理人員必須得清楚：
1：用戶描述需求時表述的那些話不一定是用戶需求。
2：用戶所說的需求不一定是用戶想要的需求，描述和想象始終會存在差距。
3：誰是真正能拍板的用戶。
4：需求的滿足需要一個過程。
5：用戶的需求基本都是拍腦門說出來的，很少是冥思苦想了很久。
6：大多數情況下，需求沒有變，而是你沒理解用戶真正的需求。
需求分析的過程
將用戶的所提出的需求，放到用戶的業務場景中去分析，分析用戶是想解決一個什麼問題，是否能爲用戶帶來價值。這個需求到時候是否能真正用起來，這需要考慮用戶的組織結構，部門角色，用戶的推動力。
此需求是否屬於項目和產品範圍之內，不是則不做。
確認需求之後，思考該需求是否會存在衍生需求，然後思考下是否能否那我們產品中已有的功能變相的來滿足客戶的需求。
如果確認需要開發，需要鑑定該需求我們是否能做，做多久，做初步的可行性分析。
需求處理
將分析出來的需求，同用戶確認，有界面的最好用原型法，假如用戶不和你確認（我遇到的大多數情況是這樣的），你可以發一封郵件給用戶，並說請您確認下需求，假如沒有異議，我們後天就按照這個開始做了。不回你就表示用戶默認了。
需求歸類：該需求是項目需求還是產品需求，是否能產品化？劃分到產品的哪一個版本里？