飛鴿傳書2007使用者需求就是做好需求處理

飛鴿傳書2007使用者需求就是能幫飛鴿傳書2007使用者解決實際問題的一套解決方案。在經歷過多年的企業專案之後，發現專案中最大的風險來自於飛鴿傳書2007使用者需求的變更。需求變更產生風險的最大原因在於未做好需求處理，所以在此希望和大家**下企業應用的需求處理。

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

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

需求處理中遇到的問題：

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

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

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

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

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

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

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

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

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

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

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

3：誰是真正能拍板的飛鴿傳書2007使用者。

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

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

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

需求分析的過程

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

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

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

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

需求處理

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

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