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