起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識需求管理如此重要，如何管理（上篇）
編輯導語：需求管理對于項目來說很重要，甚至會影響到項目的成功與否。一個好的項目管理流程不僅可以推動項目的進行，還可以提高項目的成功率。需求管理如此重要，那么我們應該如何進行需求管理呢？我們來看看本文作者的分析。
糟糕的需求管理流程(或者根本就沒有)，常常被認為是項目失敗的首要原因。
正如許多組織所發現的那樣，審慎設計的項目管理流程可以有效地提高項目成功率，這些研究同時指出：混亂的產品需求的管理，也是項目失敗的重要原因。
由此產生問題：什么是需求管理？需求管理流程的好壞又如何造成項目的拖延和失敗或者促進項目的發展與成功？
一、從身邊的現象說起
作為互聯網從業者，我想除了眾所周知的“996”、“35歲被優化”等老梗之外；另外為人所熟知的，就是產品經理和開發之間的矛盾了，由此誕生了“砍我可以砍需求不行”、“服務器又出故障了，該拿程序員祭天了”等其他相當知名的段子。
產品經理和開發之間的矛盾由來已久，段子和故事不可勝數，但是深究原因，其實無外乎需求經常變更或是項目發生延期。換言之，就是對于項目缺乏有效的需求管理。而最終的后果，小到項目員工日夜加班，大到項目失敗，甚至公司業務崩潰。
很多人往往將這些被可以避免的問題歸類于是其他難以避免的重大問題(資金不足，決策失誤，市場變化，政策變化等等），畢竟以上問題是所有公司都有可能遭遇的問題。它們太過普遍以至于如果將這些問題作為原因的話，我們很難得出更多有意義的結論。
事實上，根據 PMI 進行的多項需求管理調查得出：糟糕的需求管理流程常常被認為是項目失敗的首要原因。
很多甚至中小型公司(當然，也包括一些大型公司）根本就沒有成型的需求管理體系，只是通過一些簡單定義的工作規范和工作流程管理需求，有些連基本的管理規范都沒有，完全取決于大家約定俗成的簡單共識。
正如許多組織所發現的那樣，經過精密設計的項目管理流程可以有效地提高項目成功率。同時這些研究也指出：混亂的產品需求的管理，也是項目失敗的重要原因。
由此引發一系列問題：
- 什么是需求管理？
- 需求管理流程又如何造成項目的拖延和失敗或者促進項目的發展與成功？
- 以及我們應該通過怎樣的方式管理需求？
這也是我們接下來將要進行詳細講解的三個主題。
二、當我們談論需求管理時我們在談論什么？
1. 從需求定義重新出發
按照 PMI (項目管理協會，Project Management Institute) 對于產品需求的定義：
需求是指產品所必須擁有的一項功能特性，這個特性一般用于解決客戶的特定問題，或者是給客戶帶來額外的價值。
換言之，如果一個產品需求、或者說一個功能特性，既不能解決客戶的問題，也不能給客戶帶來價值，那么我們很難認為這個需求是有意義的。
即使這個需求涉及到管理層的偉大戰略，產品的精妙構思，開發的畢生絕學和相關人員的通力合作，它也是失敗的。
忽視客戶真實想法和意圖的情況并不鮮見，其中有些產品獲得偉大的成功，但大多數成為眾人皆知的笑柄。
蘋果公司：Newton PDA，又稱「喬布斯的終身噩夢」
福特公司：Edsel, 又稱「馬桶座圈之車」
雅達利：E.T 游戲, 又稱 「史上最垃圾的游戲」
這些產品之所以誕生，很多時候源于亨利·福特的一句話：
我不需要產品調研，如果我問我的客戶他想要什么，他一定會回答「一輛更快的馬車」。
顯而易見，這些失敗產品給客戶提供的是「一輛更慢的牛車」。
要想像亨利·福特和喬布斯那樣的天才一樣洞察需求是相當困難的，但是設身處地地去理解客戶的想法和訴求卻并不復雜。只需要你有同理心和謙虛的態度，充分理解客戶所關心的問題，才能創造出滿足客戶需要的產品。
所以，從這點來說，客戶的需要并不完全等同于客戶需求，只有產品設計者和相關從業者充分調研，充分了解了客戶提出需要的背景和根源，才能足夠清晰地定義出關鍵問題。而產品設計者針對該問題所設計的解決方案，才能被視為產品需求。
2. 我們應該如何區分需求
我們已經初步了解和認識到什么是產品需求，接下來要做的是對需求分類。
我們之所以要區分需求，是因為任何一個產品需求，其業務背景、目標客戶、需求來源、預期作用、重要程度、緊急程度都存在根本性的差別，而我們必須要將這些形形色色的需求納入一個相對一致的分類體系，以期實現標準化的需求管理。
簡而言之，需求的分類源于我們對需求的管理方式。
那么如何區分需求呢，常見的分類標準又分別是哪些呢？
產品需求可能來源于許多不同的場景：譬如需要遵從行業標準和監管條例所產生的監管需求；以及源于用戶業務問題和需要的業務需求；以及源于公司戰略的市場需求和競爭需求等等。
隨著需求來源的不同，我們可以根據這些來源進行分類。
而更加標準的分類方式是根據需求是否滿足特定目的(功能型）來區分：這種場景下，需求通?？梢苑譃楣δ苄托枨蠛头枪δ苄枨?。
1）功能型需求
是那些用以處理產品所必須滿足用戶需求的功能特性，功能型需求是最基礎也最核心的用戶需求，功能型需求有時也被稱為業務需求。
這些需求描述了用戶預期產品所能擁有的某些能力或功能，這些功能可以幫助客戶自動化地完成某些任務，優化業務流程，推進客戶業務的運營效率等等。
一言以蔽之，功能型需求是產品的骨架、大腦和心臟，是產品之所以存在的根本原因。
2）非功能需求
包括可用性需求，性能需求，可靠性需求和安全需求。
非功能需求是產品所需要滿足的重要屬性，我們日常所說的技術需求也是一種非功能型需求。相比功能型需求，非功能需求重要性往往略遜一籌。
但是在很多核心項目中，即使最終完成的產品已經滿足所有業務需求；如果有一項或者幾項關鍵非功能需求(性能需求)無法滿足時，這個項目也仍然會被視為失敗的項目。
而隨著用戶規模的擴大，非功能型需求的重要性也在不斷上升，例如淘寶、支付寶、微信，對于非功能型需求的重視不遜色于功能型需求。
而正是因為這些產品極好地滿足了非功能需求，保證了服務的可用性，響應的及時性，交易的可靠性和信息的安全性，才能獲得更大的市場規模。
簡單來說，非功能需求是產品的血肉、神經和皮膚，是產品能經久不息的核心動力。
此外，還存許多不同的需求分類方法：比如基于卡諾模型的需求分類方法、比如基于緊急度和重要性的艾森豪威爾需求分類方法。每種需求方法都有其適用場景，而根據公司和項目實際情況不同，對需求的分類方式也由此存在差異，不存在一種最佳的需求分類方法。
而現實往往比理想更多復雜，很多時候我們需要結合多種需求分類方式，重新構建一套完備的需求分類標準才能有效處理各種復雜需求。
但是無論如何，你需要謹記：需求分類的目的是為了便于需求管理，如果一個需求分類方法有助于提高項目需求管理的效率，那它便是最好的需求分類方法。
三、產品需求的集合：產品范圍 (Product Scope)
《項目管理知識體系手冊》(PMBOK) 所定義的產品范圍：是指那些被定義為產品、服務和成果的一些特定功能和特性的集合。
產品范圍的是否完成，取決于所包含的產品需求是否全部完成。
盡管我們已經力圖在項目開始階段就充分列舉所需要的產品需求，但是需求的新增和變更仍然難以避免。
雖然不建議在產品范圍的需求列表中加入此前未提及的新需求，但是如果缺少用戶已提出的產品需求將致使最終產品無法滿足用戶預期。
本篇文章說明了需求定義和分類方法，接下來我會陸續更新需求管理的目的和意義、以及需求管理的具體流程這兩部分內容，敬請大家關注。
本文由 @遍歷分形 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Pexels，基于 CC0 協議
本來可以寫一篇的，開始分為3篇~~！
文章太淺了，啥干貨都沒看到
同感，以為好戲馬上上演，結果開篇即巔峰