在之前的文章中，我們談到以項目交付作為商業模型的公司，要想業務規模做大做強、又要賺錢要利潤，就一定要做KA大客戶、百萬以上大項目。而越大的項目，風險又越大，這既是一個殘酷的事實又是一個充滿矛盾的命題。
其實不只是百萬以上級別的項目才會出現風險，只要脫離了【標準產品】實施的范疇，或是基于標品定制開發，都會存在一定的風險，從腦海中的需求到開發出來的產品，需要以項目化的方式進行管控，否則就會以失敗告終。
分析報告指出，多達76%的項目失敗是因為差勁的需求管理，這個是項目失敗的最主要原因，比技術、進度失控或者混亂的變更管理還要關鍵。很多項目經理或客戶成功經理并沒有把需求管理重視起來，甚至認為這只是產品經理的事情，自己只做交付和統籌即可，俗話說：好的開始是成功的一半，一開始就沒有管理好，注定為后續埋下了很多坑。
百萬級項目可能考驗的是綜合項目管理能力，那么"短平快"的中小項目，如幾十萬、十幾萬甚至幾萬元的開發任務，就更加聚焦對于【定制需求】的管理管控與落地交付能力了，但這也是項目管理中最難得一點，項目的全生命周期絕對不是到了需求給我們才是項目管理的開始，越往前參與越深，我們的價值就越大。
01 為什么要做好需求管理？
為什么需求管理是項目管理中的一大難點呢？我們先看看這些場景是不是都很熟悉：
1）產品提的期望是A ，結果做出來演示的是B，實際出現很大的偏差，從期望到真正可落地的需求千差萬別；
2）老板和產品負責人對需求的理解不一致，經常出現已經定好的目標，產品負責人要變更，但老板覺得沒必要，項目經理受夾板氣；
3）老板經常性的插入需求，導致變更率居高不下，需求變更流程形同虛設；
4）需求落地執行的過程中，一切都看上去挺順利的，都在按計劃執行，結果到驗收階段，各種問題頻出，不是功能缺失，就是進度延遲，功能看著像是做完了，但各種小問題一大堆；
5）多方不斷地插入需求，但時間又不允許增加，還要求按原計劃完成，導致團隊怨聲載道，滿意度很低。
以上這些場景，是不是都不陌生。事實上，可能遠不止這些問題。
就我們項目管理日常的一些場景來分析，需求管理的難點在于：
1）需求管理本身，因為項目的特點是漸進明晰，不確定性是貫穿整個周期的，而需求是源頭，一旦源頭有問題，對整個項目全流程都有很大的影響；
2）需求管理“背后”，需求輸出、實現、交付、完成，都是由人來參與的，有人參與的地方，人的復雜性，就使得整個鏈路都不會太簡單。比如對需求方期望的真正理解、對老板變更預期的理解、對團隊執行過程中的跟進與監控、還有團隊執行的滿意度。 作為一名項目經理，或是說一個需求任務的管理者，在我們日常項目管控中非常重要的一項工作，就是需求管理。如何做好需求管理，非常考驗項目經理能力。
下面就需求管理進行系統性拆解。
02 如何做好需求管理？
1、【了解背景】
我們在負責一個項目或接到某個需求任務之初時，需要花大量的時間了解清楚項目/需求的背景，這是一個非常重要的前提。何謂項目的背景，簡單來說，就是這是一款什么樣的產品？是什么類型的產品？市場上是否已經有類似的競品？和競品相比，產品的優勢和亮點體現在哪里？項目的主要干系人有哪些？項目發起人，項目核心管理層的預期是什么？
除了這些以外，還有必要了解清楚，我們為什么要做這個項目？做這個項目能帶來的價值是什么？再更深入一點的，這個項目主要要針對的是哪些用戶？這些目標用戶，我們的項目交付成果是否可以滿足他們的期望和訴求？我們項目將圍繞怎樣的目標來展開，以便滿足這些用戶的期望和訴求。 當了解項目的背景之后，會有助于我們真正理解需求方/客戶方的業務。
2、【明確目標】
當了解了項目背景之后，接著就要進一步明確項目的目標，從項目階段來說可分為：短期目標、中期目標和遠期目標。從產品本身來說，項目目標分為：最直接的目標、業務目標和戰略目標。不論項目內部自己怎么劃分，重點是需要明確項目的目標。
以最直接的目標為例，其實就是弄清楚時間、成本（人力）、范圍和質量這四要素。要做這個項目，預計是在什么時間，投入多少人力資源，做多少需求，達到怎樣的質量標準，這是必須要確定且非常具象化的。比如我們常常會去界定，項目在某個時間節點必須上線，這就是最直接的目標。 一個項目（無論大小）都必須有一個固定點"關門"時間，因為"鑼鼓長了沒好戲"，特別是在這樣一個VUCA時代。
3、【界定范圍】
在目標明確之后，要落地好目標需求，就必然要界定清楚需求交付的范圍。這個需求范圍通常可以按照MoSCoW的簡潔法則來界定即：Must have（一定有） 、Should have（應該有）、Could have（可以有） or Won't have for now（現在沒有）。
以一個為期半年的項目為例：
1）項目最直接的目標是，一年后要達成上線運行；
2）為期半年的項目，說長不長，說短也不短。界定范圍時，得先有一個整體的需求框架，這個是整個項目的大范圍。梳理需求框架的目的不言而喻，就是我們要做一款產品/系統，會涉及到哪些功能模塊。如下圖表格所呈現的模式，把要做的需求先都界定清楚。
3）有了整體的需求框架之后，如果這是一個拆分版本迭代交付的項目，此時則需要進行版本的整體規劃，我們不能完全憑靠拍腦袋做一份規劃或計劃，需要和產品/用戶負責人進行深入的溝通和交流，確保彼此的理解一致。 進行需求優先級的劃分更有利于需求的落地執行，同時定要預留時間緩沖期，以便可以應對各種突發情況。
4、【確認需求】
范圍確定之后，接下來就是確定需求。需求管理，最根本在于對需求源頭的管理，只有源頭抓好了，后面的每個環節才會更順。所以，具體到每個需求在正式開始落地之前，一定要經過確認。
特別是對于甲乙方視角的合同交付項目，很多時候客戶提出的不一定是真需求，可能是某一個期望。這種情況下，從期望到真正落地的需求，項目經理是需要花費更多的時間來對齊確認的。這也是定制化需求開發落地比較難管理的點之一，確實有時依賴項目負責人的專業經驗甚至風格魅力。
所以，需求是一定需要經過確認的，只有經過需求提出方/用戶方確認過的需求，包括甲方項目負責人/業務部門Leader等一并確認過的需求，才會被提到需求開發List中來。這也是項目需求范圍管理的最基本的原則之一。 一旦沒有經過確認的需求進入開發，項目的風險和問題就會"涌現"出來。
5、【需求開發】
近年來很多甲方客戶會提出敏捷開發的概念，但真正的敏捷開發方法論和大眾所理解的敏捷卻有所不同，敏捷提倡我們小步快跑，快速迭代，但并不代表著對需求的輸出質量和時間沒有要求。傳統瀑布式開發往往甲方客戶希望在保證質量的前提下，實現的功能越多越好且越快越好，還不能追加成本。而現代敏捷開發推崇的是迭代周期和資源負荷是恒定不能改變的，但需求功能是可以隨時變化的。
需求的源頭確認了，那么在需求進入開發階段的伊始，也需要多次核對并確認。正所謂磨刀不誤砍柴工，千萬不要認為這個時間花了，還不如提前介入寫幾行代碼，試想，如果為了省這個幾天的時間，結果導致需求開發完成之后，出現一堆bug，最后驗收效果不好，測試過程坎坷，看著前面省了一點時間，但其實整個需求的開發周期都拉長了。 在軟件開發行業里面有一句話：質量是設計出來的。項目經理或測試人員通常是質量最后的“守門員”，但不應把所有的質量問題都留在最后測試環節。
6、【搭建可視化】
需求管理的過程需要透明化，可視化。市面上有很多好用的工具，可以借助工具來搭建搭建可視化，建立需求自動化運轉流程。一個好的工具，可以讓我們在對需求管理時事半功倍。如果是內部產研型組織的項目，成熟的TAPD工具就已經非常強大了。
因為每個公司的項目管理工具可能不一樣，但利用工具的目的都是為了更好的提升效率，讓整個項目管理過程更加的可視化，透明化，想盡一切辦法讓能夠可視化的都盡量可視化，這也是項目管理的核心價值之一。
7、【應對變更】
我們在交付項目的過程中，需要有一個認知：市場驅動型的項目，唯獨不變的就是變化本身。面對變化，我們需要擁抱變化，宜疏不宜堵。不否認的是，需求變更對定制化開發項目交付帶來了不同程度的風險與問題，項目管理方（甲方/乙方）想方設法制定各種流程，試圖來控制變更對甲乙雙方的影響。
制定再詳盡的需求功能和開發費計劃，也阻止不了需求上的變更事件，但是我們需要清楚一點，發生變更要第一時間展開需求范圍的重新梳理和重新界定，然后重新制定計劃或進入商務流程。 下面就變更請求的類型及變更控制流程做簡要示意： 圖片 圖片 圖片 當項目出現關鍵需求甚至目標變化時，我們需要果斷的叫停一些已經正在開發的需求，哪怕是這個需求即將做完。
8、【產品能力】
最后一個要點，產品能力，是說項目經理或是被委派作為項目的負責人需要具備一定的產品能力。互聯網PC端或移動端的項目，我們可以不懂技術代碼，但需要用產品思維去深入了解業務。當項目經理能夠更充分地理解需求，把握產品意圖，讓項目的推進能夠更加貼合產品的最終形態，這樣更有利于對項目的把控。
所以，項目經理絕不僅僅只是排排計劃，管管風險，和管理層溝通溝通。產品能力包括但不限于對需求的理解和分析能力、產品意識（產品體驗和競品分析）、運營數據分析能力、用戶思維等等。 之所以把項目經理稱為一個項目的"CEO"，是因為他/她一定是個多面手，既可邀功也可"背鍋"。
【客戶滿意度】 定制化系統開發，需求的管理從合同還未簽約的售前階段其實就開始了，項目管理的最終目的是在各種約束下實現項目目標，所以必須對項目全周期端到端進行管理。
此外，需求通常來自于客戶不同類型的人，從前到后管理客戶的期望本身就屬于需求管理的一部分，如下面的公式所表達，一般來說開發團隊的預期水平是比較穩定的，那么客戶的期望值越高，交付后的客戶滿意度一定不會很高。 圖片 在定制化系統開發項目中，把項目"做完"到幫助客戶“做成”，方能達成客戶價值交付。
