公司剛剛接到一個軟件項目，小明被任命為項目經理。在制定了項目章程后。他開始按照一哥給的項目計劃編制流程圖來收集客戶的需求了。并根據客戶的需求開發了第一版，提交給了客戶，客戶搖搖頭說這不是我想要的；小明虛心聽取了客戶以及同事們的意見和建議后，再次和團隊一起開發了第二版，提交給了客戶，客戶還是搖搖頭說這也不是我想要了。如此往復到了第五版，客戶仍然搖頭。此時小明憋了很久的怒火終于壓抑不住了，朝著客戶發飆了，說“你究竟想要什么？”客戶也怒吼著來了一句“我也不知道我想要什么，我只知道你做的都不是我想要的”。
不知道上述場景你是否遇到過？如果有，就說明你沒有真正弄清楚客戶的需求是什么。
那么什么是需求？先引入兩個英文單詞，need和want，兩者是否有區別？當然有，need是必需的，want是想要的。比如一個人渴了，你給他一瓶水，就滿足了他的need。一個人餓了，你給他一碗飯，也滿足了他的need；但是你此時不僅給你他一碗飯還給了他一碗湯，那就滿足了他的want。
結合到項目當中來，根據PMBOK的定義：需求是指根據特定協議或其他強制性規范，產品、服務或成果必須具備的條件或能力。它包括發起人、客戶和其他干系人的已量化且書面記錄的需要和期望。
在項目中常見的需求類型如下：
業務需求。整個組織的戰略要求我們必須去做什么樣的項目才能抓住市場機遇，進而提高公司的盈利能力等。比如，我們要實行工業化4.0項目來滿足客戶多種類，小訂單的需要，來提升公司市場占有率。
干系人需求。特別要注意干系人背后的或者私人的需求，你懂的。這種最好在非正式場合下去進行了解。
解決方案需求。為滿足業務需求和相關方需求，產品、服務或成果必須具備的特性、功能和特征。分為功能需求和非功能需求：
功能需求。例如，智能手機內存要有4G，跑分要達到多少分等。
非功能需求。例如，保密性、安全性等。
過渡需求。當前要做到最優可能不太現實，那么可以考慮做一個過渡的產品。等到條件成熟再進行更新換代。
項目需求。例如客戶期望的交付里程碑日期、合同責任義務等。
質量需求。例如質量標準、測試方法、CCC認證、ISO取證等。
收集需求的時候要考慮各種各樣的方法，包括但是不限于：
頭腦風暴。集思廣益，群策群力。
訪談。經常是一個訪談者和一個被訪者之間的“一對一”談話，對于一些私密的，私人的需求可以通過私底下的非正式溝通來獲取。
問卷調查。設計書面的問題，來完成受眾廣，快速得出結果，受訪者地理位置分散的需求分析。并可以使用統計方法來獲得結果，比如使用餅圖或者帕累托圖得出比例最高的那部分。建議使用微信中的小程序。
標桿對照。同業對標，或者企業內部的經驗交流會。
觀察。很多行業會有相應的潛規則，當事人不愿意明確提出他們的需求。當然有時候也有那種只可意會不可言傳的東西，就可以旁站觀察得到相關需求。
當通過以上方法收集到了相應的需求后，就可以使用以下方法來確定，哪些是need，哪些是want。或者哪些應該要滿足，哪些可以不用或者不用現在就滿足。
投票表決。
一致同意。都同意。
大多數同意。超過 50%。
相對多數同意。比如三個或者三個以上選項時，A占40%，B占35%，C占25%，那就選擇A。
獨裁決策。一個人或者一小部分人做決定。
多標準決策。考慮多方面的因素，比如性價比等。
由于項目資源的稀缺性，你時刻都面臨著事多、錢少、時間緊的狀況。那項目經理在需求管理中該如何去做呢？首先要滿足干系人的need，并且是關鍵干系人的need。
給大家推薦一個非常簡單卻行之有效的工具：其實就是兩個同心圓，當你在收集需求的時候，就可以把所有的need寫在內圓中，want寫在兩個圓圈之間，而外圓之外就是除外責任。
在了解到了干系人的相關需求，并進行了相關的后，就需要記錄下來，形成需求文件。并作為后期定義范圍的輸入。
當然，咱們雖然在前面講過，說項目資源有限，只能滿足關鍵干系人的need。但是一哥想給大家說的是，在實戰中不僅要滿足need，還要盡可能的、有選擇性的滿足一小部分最關鍵的干系人的want（有可能是私利，不，應該是大多數情況下都是私利。你懂的），也就是超出他們的期望。只有這樣你的項目才能夠有更大的幾率取得成功。也希望今天的文章對你有幫助哦。
