楊堃：B端產(chǎn)品的需求管理與迭代優(yōu)化

本篇目錄：

原始需求與產(chǎn)品需求

• 區(qū)分原始需求和產(chǎn)品需求
• 原始需求提報管理

產(chǎn)品需求的層次和價值

• 需求的三個層次
• 需求的四類價值

需求池管理

需求的優(yōu)先級

• 成本價值模型
• RICE模型
• 價值范圍模型
• KANO模型

需求的驗證和評估

• 通過拆解指標(biāo)評估業(yè)務(wù)需求收益
• 通過NPS評估用戶需求收益
• 通過綜合方案評估技術(shù)需求收益
• 終極衡量指標(biāo)：考核使用人數(shù)

迭代中的研發(fā)資源管理

• 研發(fā)資源的人力跟蹤
• 產(chǎn)品不同發(fā)展階段的技術(shù)資源投入

產(chǎn)品上線后，需要進(jìn)行持續(xù)的升級、迭代和優(yōu)化，產(chǎn)品經(jīng)理要管理需求，區(qū)分優(yōu)先級，決定工作計劃，選擇做什么和不做什么。

這篇文章，我們進(jìn)一步深入的探討B端的需求管理和迭代優(yōu)化工作，首先介紹原始需求的收集和管理；其次討論產(chǎn)品需求的分類、層次和價值，接下來聊一聊需求池的管理，同時還會深入探討需求的優(yōu)先級設(shè)計問題，最后分享需求驗證的一些思路，以及持續(xù)迭代中技術(shù)資源的合理分配。

原始需求與產(chǎn)品需求優(yōu)化

原始需求和產(chǎn)品需求是需求分析、管理工作中最基礎(chǔ)重要的概念，我們首先需要明確兩者的定義和區(qū)別。

區(qū)分原始需求和產(chǎn)品需求

不論是產(chǎn)品經(jīng)理通過訪談、問卷收集的，還是業(yè)務(wù)方、用戶主動提報的需求，都是原始需求，原始需求中可能夾雜了若干混合的訴求，既可能是痛點(diǎn)描述，也可能是用戶提出的解決方案。原始需求是終端用戶/客戶提給產(chǎn)品經(jīng)理的訴求描述。

產(chǎn)品經(jīng)理通過分析挖掘原始需求，找到痛點(diǎn)，形成軟件產(chǎn)品設(shè)計方案，從而形成產(chǎn)品需求，產(chǎn)品需求是顆粒度清晰、邏輯嚴(yán)謹(jǐn)完整的產(chǎn)品訴求，是產(chǎn)品經(jīng)理提給研發(fā)人員的軟件設(shè)計方案。

原始需求是最原生態(tài)的需求描述，充滿了不確定性；產(chǎn)品需求則是分析問題后的的解決方案（或初步的思路拆解），具備確定性。原始需求在處理過程有可能被拆解成多個產(chǎn)品需求，也可能與其他原始需求合并變成同一個產(chǎn)品需求，原始需求和產(chǎn)品需求是多對多關(guān)系，產(chǎn)品需求會對應(yīng)多個研發(fā)任務(wù)和測試任務(wù)，邏輯關(guān)系如下圖。

原始需求和產(chǎn)品需求的關(guān)系

例如，M公司分銷平臺業(yè)務(wù)中，業(yè)務(wù)運(yùn)營同學(xué)提交了一個原始需求，希望支持品類券（針對特殊品類生效的優(yōu)惠券），并且發(fā)券數(shù)量超過1000張需要觸發(fā)審批。這個原始需求里邊包含了兩個需求，一個是增加新的營銷工具（品類券），目的是提高客單價和收入；另一個是審核規(guī)則，目的是控制風(fēng)險。

果凍分析后，將這個原始需求拆解為兩個產(chǎn)品需求，分別是品類券需求和審批流需求，其中審批流需求合并到規(guī)劃中的流程引擎項目中，構(gòu)建一套完整的審批解決方案，品類券需求提交研發(fā)后，研發(fā)根據(jù)功能feature又創(chuàng)建了多個研發(fā)任務(wù)，包括：

• 任務(wù)一：品類券在商城前端的展現(xiàn)（包括購物車、訂單、個人中心等位置）；
• 任務(wù)二：品類券在后臺的管理配置功能（包括列表頁、創(chuàng)建編輯頁）；
• 任務(wù)三：品類券的發(fā)放提醒功能（這部分可能會調(diào)用現(xiàn)成消息接口）；
• 任務(wù)四：品類券在交易結(jié)算中的分?jǐn)傔壿?，以及臺賬和財務(wù)處理規(guī)則；

實際研發(fā)任務(wù)拆的會更細(xì)致，以上僅僅是示意，而且以上拆分的顆粒度，依然是功能點(diǎn)級別，每一個功能點(diǎn)背后可能還要對應(yīng)多條研發(fā)任務(wù)。

可見，原始需求并不直接等同于產(chǎn)品需求，產(chǎn)品經(jīng)理需要完成原始需求到產(chǎn)品需求的轉(zhuǎn)換設(shè)計。

我們在前面文章介紹的需求分析十三要素五步法，就是對原始需求的分析過程，而其中第五步設(shè)計產(chǎn)品方案，輸出產(chǎn)物就是產(chǎn)品需求。

在口頭交流中，為了方便，我們往往將原始需求和產(chǎn)品需求混在一起討論，不會做嚴(yán)謹(jǐn)?shù)膮^(qū)分；例如，當(dāng)我們說“這個需求優(yōu)先級不高”，這句話說的既可能是原始需求，也可能是產(chǎn)品需求。但在正式的需求池管理中，一定要對兩者進(jìn)行區(qū)分，否則會帶來管理和執(zhí)行上的混亂。

原始需求提報管理

不論是甲方做對內(nèi)系統(tǒng)的產(chǎn)品經(jīng)理，還是乙方做商業(yè)化的產(chǎn)品經(jīng)理，都會面臨一個比較苦惱的問題，業(yè)務(wù)方或者客戶，總是提一些一句話的拍腦袋需求，很多時候根本沒有想清楚，但也會耗費(fèi)產(chǎn)品經(jīng)理大量的時間去溝通核實。

為了避免用戶不經(jīng)思考隨意提需求帶來沒必要的資源損耗，可以考慮讓用戶通過填寫需求提報模板來提交需求，促使用戶提需求前把一些關(guān)鍵事項想明白，提高需求質(zhì)量，尤其適合甲方公司。（乙方公司面臨的現(xiàn)實情況是需要更好的主動服務(wù)客戶，如果讓客戶通過模板提需求估計老板也不同意啊?。?/p>

具體模板見下表，內(nèi)容很容易理解，此處不再贅述，可以根據(jù)自身情況調(diào)整后使用。再次強(qiáng)調(diào)的是，任何需求，都應(yīng)該提前想清楚需求價值，以及上線后如何衡量價值是否實現(xiàn)，并依據(jù)效果做持續(xù)的閉環(huán)優(yōu)化跟蹤。不論是誰發(fā)起的需求，都應(yīng)該提前想清楚需求的預(yù)期收益和度量方式。

原始需求提報表

產(chǎn)品需求的層次和價值

產(chǎn)品需求，從軟件工程角度來講，可以分為功能需求、非功能需求；從需求背后的業(yè)務(wù)價值和分類的角度來講，又可以分為業(yè)務(wù)需求、用戶需求、技術(shù)需求，這也體現(xiàn)了B端需求的三個層次。

需求的三個層次

在C端產(chǎn)品設(shè)計中，常常將馬斯洛模型作為C端產(chǎn)品需求洞察的理論基礎(chǔ)，并依此推演C端產(chǎn)品的用戶價值，以及進(jìn)一步延展出用戶旅程、KANO模型等一系列構(gòu)建C端產(chǎn)品設(shè)計的方法論。遺憾的是，這些模型和方法論并不完全適用于B端產(chǎn)品設(shè)計與需求管理，主要基于以下原因。

• B端產(chǎn)品面向企業(yè)或組織，幫助其解決某類經(jīng)營管理問題，對于機(jī)構(gòu)來講，需求的本質(zhì)在于業(yè)務(wù)管理，無法通過馬斯洛模型來定義描述。
• B端產(chǎn)品的關(guān)注對象，除了機(jī)構(gòu)本身，也需要關(guān)注業(yè)務(wù)用戶，而業(yè)務(wù)用戶的需求動機(jī)也并非馬斯洛模型可以解讀。
• B端產(chǎn)品作為復(fù)雜系統(tǒng)，除了承載業(yè)務(wù)目標(biāo)，還需要考慮軟件架構(gòu)設(shè)計、體系構(gòu)建等問題，因此需求分析管理中，對于軟件產(chǎn)品本身還需要有足夠的關(guān)注度。

基于以上所述，可以發(fā)現(xiàn)，B端產(chǎn)品的需求來源和場景復(fù)雜，很難像C端產(chǎn)品那樣基于馬斯洛模型從單一維度去覆蓋需求洞察的工作，而需要從幾個維度分開來審視B端的需求類型和層次。

實際上，我們可以將B端需求分為三大類，分別為業(yè)務(wù)需求、用戶需求、技術(shù)需求，這三個類別本身由上到下具備層次關(guān)系，每一類需求處理權(quán)衡時都有不同的考量。

業(yè)務(wù)需求

業(yè)務(wù)需求，是自頂向下的需求，往往來自于中高層管理人員（或監(jiān)管、政策要求），基于業(yè)務(wù)運(yùn)營管理的直接訴求和要求，例如業(yè)務(wù)規(guī)則、管理制度、業(yè)務(wù)流程、組織機(jī)構(gòu)，這些都屬于業(yè)務(wù)需求。

業(yè)務(wù)需求的分析過程，往往采用了經(jīng)典傳統(tǒng)的軟件需求分析設(shè)計思路，重點(diǎn)通過業(yè)務(wù)診斷分析、抽象建模（DDD設(shè)計思想）、流程再造（BPR）的方式，進(jìn)行需求分析和設(shè)計工作。

業(yè)務(wù)需求，承載了B端產(chǎn)品的業(yè)務(wù)價值，為相關(guān)業(yè)務(wù)的運(yùn)營管理助一臂之力。注意這里所說是業(yè)務(wù)價值，而非商業(yè)價值。商業(yè)價值往往要上升到企業(yè)的層面，而B端產(chǎn)品多數(shù)情況是為單一業(yè)務(wù)部門服務(wù)，承載的更多是業(yè)務(wù)價值。

業(yè)務(wù)需求，多數(shù)情況下難以衡量具體的收益，例如，很難衡量設(shè)計開發(fā)了某個CRM管理模塊，就會對銷售業(yè)績有多少程度的提升；即便如此，產(chǎn)品經(jīng)理也要盡量嘗試量化收益和價值，關(guān)于幾類需求收益價值的討論，在本章第四節(jié)會進(jìn)一步展開。

用戶需求

用戶需求，是自下向上的需求，來自于一線業(yè)務(wù)用戶和基層管理人員，更多體現(xiàn)著業(yè)務(wù)人員對業(yè)務(wù)規(guī)則、流程、系統(tǒng)操作交互上的改進(jìn)訴求。

現(xiàn)如今SaaS形態(tài)的B端產(chǎn)品都更加關(guān)注用戶體驗，其交互體驗和操作流暢度要好于傳統(tǒng)的管理軟件。在梳理B端產(chǎn)品的用戶需求時，可以大量借鑒C端產(chǎn)品的需求管理方法論，例如客戶旅程地圖，KANO模型等。

用戶需求體現(xiàn)了用戶價值?；ヂ?lián)網(wǎng)思維下，即便是B端產(chǎn)品，也需要重視用戶體驗和用戶價值，包括了功能滿意度和操作效率等；尤其是工具型、基礎(chǔ)服務(wù)類產(chǎn)品，解決了一線用戶的痛點(diǎn)，就是解決了業(yè)務(wù)的痛點(diǎn)，產(chǎn)品賦能終端用戶、重視體驗就顯得更為重要。

通過針對功能模塊定期的滿意度調(diào)研（NPS）可以較好的度量用戶需求的滿足情況。另外也可以從效率提升、時間節(jié)約的角度去衡量、評估收益。

技術(shù)需求

B端產(chǎn)品復(fù)雜程度高，建設(shè)到一定階段，甚至有些時候在建設(shè)初期，就要考慮功能復(fù)用問題，以及與其他系統(tǒng)的架構(gòu)設(shè)計與交互問題。例如，對于業(yè)務(wù)系統(tǒng)的權(quán)限管理模塊，是復(fù)用基礎(chǔ)服務(wù)，還是獨(dú)立開發(fā)？對于消息中心和公告通知模塊，是復(fù)用基礎(chǔ)服務(wù)還是獨(dú)立開發(fā)？除此以外，還有類似于軟件產(chǎn)品功能完備性提升的訴求，例如靈活的后臺配置模塊，報表引擎的配置，視圖編輯器的配置，這類需求，我們可以統(tǒng)稱為技術(shù)需求。

技術(shù)需求往往不具備明顯的業(yè)務(wù)價值（但可能具備用戶體驗價值，例如視圖編輯器的能力構(gòu)建），但是在軟件系統(tǒng)結(jié)構(gòu)合理性設(shè)計上，具備顯著價值。除了讓架構(gòu)合理，還能節(jié)約重復(fù)開發(fā)的人力浪費(fèi)。產(chǎn)品需求承擔(dān)了軟件的系統(tǒng)價值，為系統(tǒng)自身優(yōu)化而服務(wù)，讓系統(tǒng)自身合理并增值。

對于技術(shù)需求的收益評估，可以考核功能復(fù)用以及架構(gòu)完善，對研發(fā)人力的成本節(jié)省。

業(yè)務(wù)需求、用戶需求、技術(shù)需求，作為B端需求的三大類型，也體現(xiàn)出了層次關(guān)系。對于B端產(chǎn)品的核心目標(biāo)，首先服務(wù)于業(yè)務(wù)，要滿足業(yè)務(wù)需求；其次，要關(guān)注用戶的體驗和效率，滿足用戶需求；最后，要考慮軟件結(jié)構(gòu)的合理性，滿足技術(shù)需求。

【資源推薦】

關(guān)于需求層次的更多分析，推薦貝恩咨詢分別于2016年、2018年發(fā)表于哈佛商業(yè)評論（HBR）的兩篇論文，探討了基于馬斯洛需求層次在2C領(lǐng)域的價值要素金字塔模型；以及借鑒馬斯洛模型，嘗試構(gòu)建了2B業(yè)務(wù)的價值要素金字塔模型。

需求的四類價值

B端產(chǎn)品需求的價值可以從對內(nèi)對外兩個視角分為商業(yè)價值、技術(shù)價值、業(yè)務(wù)價值、用戶價值四大類。

商業(yè)價值

如果是商業(yè)化售賣產(chǎn)品，我們首先要判斷的是需求的商業(yè)價值，是否符合產(chǎn)品本身的定位和規(guī)劃，是否遵循產(chǎn)品商業(yè)化售賣的戰(zhàn)略訴求和經(jīng)營要求。

例如，在M公司分銷平臺的SaaS化設(shè)計中，是否要實現(xiàn)銷售型CRM模塊，這就是一個涉及商業(yè)價值判定的決策，而非基于客戶的業(yè)務(wù)訴求；從業(yè)務(wù)價值來看，銷售管理對客戶的業(yè)務(wù)是有益的，但從商業(yè)價值來看，該模塊不符合產(chǎn)品定位，并且會泛化產(chǎn)品邊界，擴(kuò)大研發(fā)成本，稀釋商業(yè)競爭力，因此我們不考慮實現(xiàn)它。

如果是對內(nèi)使用的產(chǎn)品，商業(yè)價值是比業(yè)務(wù)價值層次更高的，從企業(yè)整體戰(zhàn)略經(jīng)營角度帶來的價值。

例如，M公司分銷平臺的設(shè)計，首先是為了實現(xiàn)對分銷業(yè)務(wù)支持賦能的業(yè)務(wù)價值，在更深的層面，則支撐了M公司期望實現(xiàn)多元化經(jīng)營戰(zhàn)略的商業(yè)價值的。

業(yè)務(wù)價值

B端產(chǎn)品除了承載商業(yè)價值，更需要幫助客戶、用戶在業(yè)務(wù)上取得成功，這是B端產(chǎn)品的業(yè)務(wù)價值。

我們在第1章講到過，B端產(chǎn)品對企業(yè)來講承擔(dān)著提升收入、降低成本、提高效率、保證品質(zhì)、控制風(fēng)險的重任，這些都是B端產(chǎn)品的業(yè)務(wù)價值。

用戶價值

B端產(chǎn)品本質(zhì)上是為了解決業(yè)務(wù)問題而存在的，但設(shè)計過程中也要考慮終端用戶的體驗問題，包括是否能夠提升一線效率和滿意度，這是產(chǎn)品的用戶價值。有些時候，賦能用戶，其實也是賦能業(yè)務(wù)，提升了用戶價值，也就提升了業(yè)務(wù)價值；例如針對協(xié)同辦公類產(chǎn)品，提升整體使用體驗，可以提高員工的工作效率，實際上也提升了企業(yè)整體的運(yùn)作效率。尤其是針對工具型、基礎(chǔ)服務(wù)型產(chǎn)品，提升了用戶價值，也就提升了業(yè)務(wù)價值。

技術(shù)價值

軟件產(chǎn)品在構(gòu)建過程中，自身也存在技術(shù)層面的優(yōu)化點(diǎn)，比如說，我們要將列表頁進(jìn)行支持自定義設(shè)置的改造，從而解決為不同客戶三天兩頭硬編碼修改列表頁的煩人工作，這類需求是為了降低研發(fā)成本，或提升產(chǎn)品化能力而存在的；再比如說，為了解決企業(yè)客戶重復(fù)的問題，我們需要將產(chǎn)品背后的應(yīng)用架構(gòu)進(jìn)行主數(shù)據(jù)改造，這類需求是為了改善架構(gòu)合理性而存在的；這些都是技術(shù)需求背后可能的價值。

以上需求的四類價值，不論是商業(yè)化軟件產(chǎn)品，還是對內(nèi)使用的產(chǎn)品，業(yè)務(wù)價值、用戶價值、技術(shù)價值本質(zhì)上都最終服務(wù)于商業(yè)價值；而需求的三個層次正好一一應(yīng)對這三類價值。

產(chǎn)品規(guī)劃建設(shè)過程中，四類價值的優(yōu)先級并不是一成不變的，不同的產(chǎn)品階段可能有不同的優(yōu)先級策略。

例如，M公司分銷平SaaS商業(yè)化的初期，要先解決客戶的業(yè)務(wù)問題，需求的業(yè)務(wù)價值優(yōu)先級高于技術(shù)價值。但隨著客戶數(shù)量的增大，一些交互層面的定制化需求越來越多，不支持，傷害用戶體驗；硬編碼支持，又浪費(fèi)研發(fā)資源。此時，技術(shù)需求的優(yōu)先級可能就會提高，類似于自定義視圖編輯器這種組件的設(shè)計需要被采納執(zhí)行，而這么做，是因為產(chǎn)品對業(yè)務(wù)的支持已經(jīng)有很好的成熟度，需要加大產(chǎn)品化能力，強(qiáng)化配置能力，核心目的也是為了服務(wù)產(chǎn)品的商業(yè)價值。

小結(jié)

最后，我們通過一張圖，來總結(jié)回顧需求的類型、層次和價值，如下圖。

需求的類別和價值

對原始需求分析后，進(jìn)行拆散或合并，形成產(chǎn)品需求。從軟件工程角度來講，產(chǎn)品需求可以分為功能需求和非功能需求，從業(yè)務(wù)角度來講，又可以分為業(yè)務(wù)需求、用戶需求和技術(shù)需求，這也體現(xiàn)了需求的層次，具有天然發(fā)的優(yōu)先級屬性。這三層需求也分別體現(xiàn)著產(chǎn)品的業(yè)務(wù)價值、用戶價值和技術(shù)價值，最終都是為了服務(wù)于商業(yè)價值。

需求池管理

產(chǎn)品經(jīng)理需要管理維護(hù)兩個需求池，原始需求池，和產(chǎn)品需求池。

原始需求池記錄了所有用戶端提報的原始需求記錄，產(chǎn)品需求池，是對用戶需求經(jīng)過初步分析拆解后形成的需求清單。

用戶需求池體現(xiàn)的是從用戶提報的角度來記錄，產(chǎn)品需求池體現(xiàn)的是從產(chǎn)品管理的角度來記錄。用戶需求和產(chǎn)品需求應(yīng)該有明確的關(guān)聯(lián)，可以互相追溯，一方面方便用戶從提報需求的角度理解相關(guān)工作的進(jìn)展，另一方面幫助產(chǎn)品經(jīng)理找到產(chǎn)品設(shè)計背后對應(yīng)的原始需求軌跡。

原始需求一旦記錄在案，更多的是存檔保留，產(chǎn)品需求則可能被更新、調(diào)整。一旦產(chǎn)品需求形成產(chǎn)品方案投入研發(fā)，就會進(jìn)入明確的項目管理周期。

有條件的話，需求池管理應(yīng)該使用項目管理軟件進(jìn)行，但只要負(fù)責(zé)人用心，Excel同樣可以管理好需求池。下邊，我們來介紹一個產(chǎn)品需求池中典型的字段：

• 產(chǎn)品需求ID

需求唯一性主鍵。

• 原始需求ID

對應(yīng)的原始需求編號，可以為多個。

• 產(chǎn)品線

描述需求所在產(chǎn)品線（或?qū)?yīng)的業(yè)務(wù)線），例如CRM系統(tǒng)或客服系統(tǒng)等。

• 需求類型

需求類型應(yīng)該做謹(jǐn)慎的設(shè)計分類，主要目的用來分析資源在不同業(yè)務(wù)方向上投入的情況?？赡艿男枨箢愋桶I(yè)務(wù)需求、用戶需求、技術(shù)需求，或者純粹根據(jù)業(yè)務(wù)價值分類，包括：提升規(guī)模、降低成本、提高效率、控制風(fēng)險、保障品質(zhì)、體驗優(yōu)化等?？傊?，要根據(jù)自身情況設(shè)計一個合理的分類。

• 是否插隊

用來專門記錄需求是否在項目執(zhí)行中做了插隊執(zhí)行的字段。

• 主題

需求的一句話概述。

• 內(nèi)容

需求的具體描述。

• 來源

需求的提出人，或提出部門。這個數(shù)據(jù)可以來自于原始需求。

• 需求提出日期

收到需求的日期。有些公司會要求產(chǎn)研團(tuán)隊提高需求響應(yīng)速度，可能會通過上線日期和需求提出日期的時間差來進(jìn)行考核評估。

• 優(yōu)先級

優(yōu)先級會在下一節(jié)詳細(xì)介紹。

• 迭代版本

如果采用了敏捷開發(fā)模式，就需要標(biāo)記需求排期開發(fā)時的迭代版本。

• 業(yè)務(wù)負(fù)責(zé)人

該需求業(yè)務(wù)口的唯一負(fù)責(zé)人

• 產(chǎn)品經(jīng)理

該需求對應(yīng)的產(chǎn)品經(jīng)理。

• 研發(fā)負(fù)責(zé)人

研發(fā)負(fù)責(zé)人一定是研發(fā)的整體負(fù)責(zé)人，而不應(yīng)該分成后端負(fù)責(zé)人、前端負(fù)責(zé)人，因為那樣很可能導(dǎo)致兩者各自負(fù)責(zé)自己的工作，但是對于技術(shù)實現(xiàn)的整體方案和進(jìn)度沒有把控，相當(dāng)于沒有技術(shù)負(fù)責(zé)人。

• 測試負(fù)責(zé)人

如果研發(fā)負(fù)責(zé)人全權(quán)管理研發(fā)、測試工作，則不需要單獨(dú)指定測試負(fù)責(zé)人。否則，要明確安排測試負(fù)責(zé)人，對質(zhì)量結(jié)果和進(jìn)度負(fù)責(zé)。

• 狀態(tài)

狀態(tài)用來描述需求的生命周期，狀態(tài)值可以包括如下選項：

待跟進(jìn)、需求調(diào)研中、PRD編寫中、待PRD評審、待技術(shù)評審、待排期、待開發(fā)、開發(fā)中、待測試、測試中、待驗收、待上線、已上線、暫停、終止。

這些狀態(tài)值較好地覆蓋了從需求采集到上線的完整生命周期，仔細(xì)觀察后可以發(fā)現(xiàn)，這些狀態(tài)的設(shè)計符合我們在介紹狀態(tài)機(jī)圖時提出的建議，即狀態(tài)應(yīng)該是能持續(xù)足夠時長的，不應(yīng)該是很快就結(jié)束的（所以我們沒有定義“需求評審中”這種狀態(tài)，因為需求評審只需要開幾個小時的會議就可以完成，沒有必要在開會前改一下需求狀態(tài)，開會后再次修改）。

• 狀態(tài)變更說明

對某些狀態(tài)字段的補(bǔ)充解釋，例如如果狀態(tài)被修改為“暫?！?，需要選擇被暫停的具體原因。

• 計劃上線日期

計劃上線日期是在技術(shù)評審結(jié)束后，研發(fā)負(fù)責(zé)人確定工時和資源投入后給出的目標(biāo)上線日期。

• 實際上線日期

實際上線日期是系統(tǒng)的真正上線時間。通過對比實際上線日期和計劃上線日期，可以統(tǒng)計項目的延期情況，并進(jìn)一步分析延期原因。

• 前端開始日期/前端結(jié)束日期

前端開發(fā)工作的開始日期和結(jié)束日期。

注意，工期和工時是兩個完全不同的概念，工期是指開發(fā)時長，工時是指工作量。例如，為了開發(fā)某功能，安排了2名研發(fā)人員，從9月1日開始開發(fā)，到9月5日提測，則工期是5天，工時是10人日。如果這兩名研發(fā)人員并不是同時介入的，其中一名研發(fā)人員是9月1日介入的，另一名在9月3日才介入，到9月7日提測，則整體工期是7天，但工時依然是10人日。

• 前端研發(fā)工作量（人日）

即前端開發(fā)工作預(yù)計投入的總工時。在敏捷開發(fā)中，可能通過基于經(jīng)驗的“點(diǎn)數(shù)”來評估工時。

此外，后端開發(fā)及測試的開始時間、結(jié)束時間、工作量，這些字段的含義與前面所講的類似，不再贅述。

• 發(fā)版計劃

在移動端產(chǎn)品中，需求上線可能涉及發(fā)版，即需要發(fā)布新的客戶端，因此要在表格中記錄發(fā)版的版本號。

合理運(yùn)用上述模板，可以幫助產(chǎn)品經(jīng)理將需求和項目管理得井井有條。認(rèn)真填寫模板中的各項內(nèi)容，可以幫自己較好地分析需求跟進(jìn)情況、研發(fā)效率、工作量投入等。

如果某個需求涉及跨端或跨團(tuán)隊開發(fā)，則需要按照子項目將模板進(jìn)一步細(xì)化，例如每個子項目要安排各自的研發(fā)負(fù)責(zé)人、產(chǎn)品負(fù)責(zé)人，有各自的工時、工期等，然后再填寫具體字段。

在實踐中，并不一定在產(chǎn)品需求池中記錄管理研發(fā)狀態(tài)，有可能產(chǎn)品需求池只管理產(chǎn)品層面的需求清單，具體的研發(fā)執(zhí)行，會通過另一個研發(fā)任務(wù)池進(jìn)行管理。總之，根據(jù)自己團(tuán)隊的習(xí)慣和風(fēng)格，或者公司的統(tǒng)一要求，選定一個模式或方案，持續(xù)執(zhí)行，正確記錄相關(guān)字段和內(nèi)容，保證可以做出11.3小節(jié)那樣的整體性分析，以便持續(xù)優(yōu)化產(chǎn)研效率，就可以了。

需求的優(yōu)先級

需求優(yōu)先級的判斷，是產(chǎn)品經(jīng)理工作的一個難點(diǎn)。決策先做什么，再做什么，決定了產(chǎn)品的發(fā)展路徑和節(jié)奏，甚至?xí)Q定產(chǎn)品在市場環(huán)境中競爭的優(yōu)劣。遺憾的是，優(yōu)先級的判斷，在實踐中，很難通過一套理性的方法論作為客觀的執(zhí)行依據(jù)，很多時候，優(yōu)先級的判定是一門藝術(shù)，融合了對戰(zhàn)略、市場、競爭態(tài)勢、業(yè)務(wù)發(fā)展、研發(fā)資源、團(tuán)隊情況的綜合判斷。

即便如此，產(chǎn)品經(jīng)理需要了解業(yè)界經(jīng)典的優(yōu)先級定義的方法論，在不同的場景和情況下，給自己更多的思路和啟發(fā)。

成本價值模型

成本價值模型，是優(yōu)先級判定最基本的、最通用的方法論，也是其他理論的核心基礎(chǔ)。

如果通過研發(fā)成本和需求價值這兩個維度劃分出四個象限，可以將需求放置在某個象限之中，根據(jù)需求所在不同象限，可以得到優(yōu)先級的劃分策略，這就是成本價值模型。

需求優(yōu)先級的成本價值模型

• 第一象限中的需求，價值巨大，但成本投入也比較大，理性的做法，應(yīng)該是規(guī)劃并持續(xù)關(guān)注。
• 第二象限中的需求，價值巨大，實現(xiàn)成本又很低，當(dāng)然要快速拿下，所以我們應(yīng)該迅速投入。
• 第三象限中的需求，價值和成本都很低，這就有點(diǎn)像雞肋，食之無味，棄之有肉。處理的策略可以是關(guān)注并抽空實現(xiàn)。
• 第四象限中的需求，價值很低，實現(xiàn)成本反而很大，這種需求沒有做的必要哦了，我們應(yīng)該忘掉他們。

綜上可以給出，位于不同象限需求的優(yōu)先級，即II > I > III > IV。

然而，需求的實現(xiàn)成本相對容易衡量，需求的價值卻很難量化評估！

RICE模型

對于SaaS軟件，判斷需求的價值時，還可以將受影響客戶數(shù)量考慮進(jìn)來，這就需要參考來自硅谷的RICE模型。

RICE是四個單詞的縮寫，分別代表：

• R：Reach，需求功能觸達(dá)的客戶數(shù)量；
• I：Impact，需求的價值打分，例如可以定義1到10分；
• C：Confidence，產(chǎn)品經(jīng)理對需求的信心程度，是一個基于主觀判斷的修正參數(shù)；
• E：Effort，需求需要投入的研發(fā)人天；

通過這四個變量，對需求進(jìn)行打分，可以得到優(yōu)先級RICE得分，計算公式如下：

RICE Score = Reach * Impact * Confidence / Effort

例如，下表是兩個需求通過RICE模型計算后的得分，根據(jù)分?jǐn)?shù)，認(rèn)為需求1優(yōu)先級高于需求2。

通過RICE模型對需求優(yōu)先級進(jìn)行打分

RICE模型很好地納入了受影響客戶數(shù)量這個因素，但也有其局限性。

首先，關(guān)于Impact產(chǎn)品價值，本身就是很難量化的一個引子，所以RICE模型并不能解決成本價值模型中面臨的困境，如何定義需求的價值？

其次，在商業(yè)運(yùn)作中，并不能簡單的認(rèn)為，在其他變量相同的情況下，需求影響的客戶數(shù)量多，優(yōu)先級就高。有些需求，可能只服務(wù)于某個頭部客戶，但卻具有標(biāo)桿效應(yīng)和示范效應(yīng)，本身就有很高的商業(yè)價值。

因此，關(guān)于RICE模型的應(yīng)用，要想清楚場景和目的。

價值范圍模型

價值范圍模型，是一個專門分析、衡量需求價值的模型，是我根據(jù)工作實踐總結(jié)而成的，在和不同的企業(yè)交流中，我發(fā)現(xiàn)很多團(tuán)隊有著類似的思考和實踐。

我們可以將一個軟件產(chǎn)品所能提供的價值（即本書中多次提到的B端產(chǎn)品的五個典型價值，規(guī)模、成本、效率、風(fēng)險、品質(zhì)，再加一個產(chǎn)品本身的用戶體驗）列在縱軸，把業(yè)務(wù)相關(guān)的利益方都列在橫軸，就得到一個多象限矩陣，有了這個矩陣，我們可以根據(jù)當(dāng)前階段業(yè)務(wù)的計劃和商業(yè)的訴求，制定一個優(yōu)先級打分表。

和業(yè)務(wù)方達(dá)成一致認(rèn)知，設(shè)計好這張表格，后續(xù)所有的需求，都可以找到表格中的位置，以及對應(yīng)的優(yōu)先級。

例如，下圖是M公司分銷平臺的范圍價值模型打分表，表格中縱軸是分銷平臺對業(yè)務(wù)本身的價值，橫軸是涉及到的利益方，單元格中直接定義了優(yōu)先級。

M公司領(lǐng)導(dǎo)本身也代表了業(yè)務(wù)，所以提升收入的相關(guān)需求都可以納入M公司領(lǐng)導(dǎo)和提升收入這兩個坐標(biāo)定位的單元格，我們認(rèn)為分銷平臺核心目的是提升收入，所以這類需求優(yōu)先級最高。

而針對M公司領(lǐng)導(dǎo)個人的降本增效、產(chǎn)品體驗類需求，優(yōu)先級都比較低，因為領(lǐng)導(dǎo)本身也不常用系統(tǒng)，不用為了領(lǐng)導(dǎo)一個人的使用體驗而投入資源進(jìn)行優(yōu)化。

我們再來看看客戶采購人員，對于他們來講，不存在提升收入的業(yè)務(wù)價值，所以單元格用橫線填充；而操作效率、交互體驗，防錯控制更重要一些，所以產(chǎn)品體驗和控制風(fēng)險兩個單元格的優(yōu)先級定義為Medium。

以此類推，基于對業(yè)務(wù)的判斷和理解，梳理了角色和產(chǎn)品本身具備的業(yè)務(wù)價值，進(jìn)一步設(shè)計了完整的優(yōu)先級打分表。

價值范圍模型打分表

價值范圍模型比較適合用于企業(yè)對內(nèi)產(chǎn)品研發(fā)中的需求優(yōu)先級打分，在實際應(yīng)用中會有很多變化和調(diào)整，例如作為一個中臺產(chǎn)品，可以將橫軸替換為中臺產(chǎn)品服務(wù)的各個事業(yè)部業(yè)務(wù)線，提前規(guī)劃好對不同業(yè)務(wù)線的支持力度，作為優(yōu)先級判斷的決策依據(jù)。

設(shè)計一張得到所有人認(rèn)可、意見統(tǒng)一的價值范圍模型打分表，還能避免未來和業(yè)務(wù)方扯皮的問題。任何需求都能在提前定義的表格中找到優(yōu)先級的位置，不用再根據(jù)誰的嗓門大來做決策。

ANO模型

KANO模型，常常用來分析單一用戶視角下需求的接受度，由東京理工大學(xué)教授狩野紀(jì)昭（Noriaki Kano）發(fā)明。嚴(yán)格來講，KANO模型研究的是產(chǎn)品功能點(diǎn)和用戶滿意度之間的關(guān)系，但結(jié)論可以作為優(yōu)先級的排序依據(jù)。

KANO模型雖然并不是為互聯(lián)網(wǎng)產(chǎn)品發(fā)明，但卻是互聯(lián)網(wǎng)圈最網(wǎng)紅的方法論。簡單來講，KANO模型將產(chǎn)品的功能點(diǎn)對用戶進(jìn)行問卷調(diào)研，通過正反兩問來獲取用戶的感知，類似于這樣：

正向提問：如果提交訂單后馬上提示開發(fā)票，你的感受是：

A.我很喜歡 B.理應(yīng)如此 C.無所謂 Ｄ.勉強(qiáng)接受 E.我不喜歡

反向提問問：如果提交訂單后并不提示開發(fā)票，你的感受是：

A.我很喜歡 B.理應(yīng)如此 C.無所謂 Ｄ.勉強(qiáng)接受 E.我不喜歡

接下來，對用戶的反饋進(jìn)行統(tǒng)計，獲得不同答案結(jié)果的占比，并統(tǒng)計到下表。

KANO模型統(tǒng)計表

拿到統(tǒng)計數(shù)據(jù)后，經(jīng)過一系列計算，可以分析出功能點(diǎn)的屬性特征，具體有以下五種：

• A，魅力屬性：提供功能用戶會很喜歡，但不提供也無所謂；
• O，期望屬性：提供功能用戶很喜歡，不提供則不喜歡，用戶對功能有強(qiáng)烈期待；
• M，必備屬性：提供功能用戶覺得感受一般，但不提供則用戶強(qiáng)烈不喜歡，說明是必備功能；
• I，無差異屬性：不論是否提供功能，用戶感受都趨于平和；
• R，反向?qū)傩裕禾峁┕δ苡脩舨婚_心，不提供功能用戶反而開心；
• Q：可疑結(jié)果：結(jié)論邏輯相悖，屬于臟數(shù)據(jù)；

KANO模型的具體詳細(xì)說明，網(wǎng)絡(luò)上資料很多，本書不再贅述。此處需要強(qiáng)調(diào)的是，KANO模型并不完全適用于B端，因為B端背后面臨著多角色和多利益方，而不同利益方之間可能具有利益互反的特點(diǎn)。

例如，釘釘?shù)囊炎x未讀功能，對老板來講，可能是期望屬性，而對員工來講，可能是反向?qū)傩浴?/p>

再例如，銷售型CRM的拜訪錄入功能，對老板來講，可能是必備屬性，而對一線銷售來講，可能是反向?qū)傩浴?/p>

因此，對KANO模型的使用，一定要明確場景，切勿盲目應(yīng)用。

需求的驗證和評估

我們已經(jīng)多次強(qiáng)調(diào)，作為一名產(chǎn)品經(jīng)理，分析需求時一定要提前考慮好，上線后如何持續(xù)跟蹤，判斷功能是否達(dá)到了預(yù)期的業(yè)務(wù)效果。但是客觀的講，B端產(chǎn)品的功能，很多時候，難以量化收益，或者說很難衡量需求或項目的效果。因為B端產(chǎn)品最終要解決業(yè)務(wù)問題，而業(yè)務(wù)上的效果和效益，除了軟件產(chǎn)品本身的影響以外，往往還取決于業(yè)務(wù)政策，以及業(yè)務(wù)人員的能力和態(tài)度等多方面的因素。

舉個例子，針對給銷售人員使用的OCRM系統(tǒng)，做了若干需求預(yù)期提高銷售的轉(zhuǎn)化率，但實際上影響轉(zhuǎn)化率的因素太多了，客戶質(zhì)量，傭金政策，銷售能力，都是影響因素，這些因素互相摻雜在一起，導(dǎo)致項目組很難衡量轉(zhuǎn)化率指標(biāo)的變化，究竟有多少是因為產(chǎn)品功能影響改善的。

即便B端產(chǎn)品很多時候收益和效果難以量化，在我們的日常工作中，團(tuán)隊管理和要求中，依然要保持?jǐn)?shù)據(jù)評估工作的持續(xù)性和嚴(yán)謹(jǐn)性，思考項目收益如何衡量的過程，本身也是對需求和項目更深層次的分析論證的過程。如果你不能度量一件事情，那么你一定要謹(jǐn)慎思考到底該不該去做。

根據(jù)B端需求的三個層次具有天然的區(qū)別，我們可以針對三類需求分別思考如何衡量其收益。

通過拆解指標(biāo)評估業(yè)務(wù)需求收益

評估業(yè)務(wù)需求的價值，可以先找到其對企業(yè)的價值大類（無外乎規(guī)模、成本、效率、品質(zhì)、風(fēng)險），然后盡量將價值大類的一級業(yè)務(wù)指標(biāo)拆細(xì)，嘗試找到和業(yè)務(wù)需求最相關(guān)的二級指標(biāo)或三級指標(biāo)，作為評估度量的核心指標(biāo)。

不論是規(guī)模、成本，還是效率、品質(zhì)，在業(yè)務(wù)運(yùn)作中，都可以首先找到對應(yīng)的一級指標(biāo)，例如：

• 針對銷售部門，規(guī)模的一級指標(biāo)可能是“簽單交易額”；
• 針對客服部門，成本的一級指標(biāo)可能是“每千人客戶的客服人力成本”；
• 針對配送部門，效率的一級指標(biāo)可能是“配送及時率”；
• 針對采購部門，品質(zhì)的一級指標(biāo)可能是“采購質(zhì)量合格率”；

各個業(yè)務(wù)線或業(yè)務(wù)單元，都會有核心一級指標(biāo)作為北極星指標(biāo)存在，指引業(yè)務(wù)的方向和目標(biāo)。通過將一級指標(biāo)層層拆解，盡量找到貼合需求價值的二級或三級指標(biāo)。

例如，某在線教育的OCRM產(chǎn)品經(jīng)理在設(shè)計實現(xiàn)了銷售打單輔助工具，在試聽課結(jié)束后生成小孩在試聽課中的精彩片段，由銷售人員發(fā)給家長，作為銷售打單工具。該產(chǎn)品功能，核心目標(biāo)是提高轉(zhuǎn)化率，但是轉(zhuǎn)化率作為二級指標(biāo)，顆粒度依然很粗，影響因素太多。此時，我們嘗試將轉(zhuǎn)化率漏斗進(jìn)行層層拆解：

轉(zhuǎn)化率 = 試聽課邀約率 * 試聽課出席率 * 出席完課率 * 完課支付轉(zhuǎn)化率

此時，轉(zhuǎn)化率二級指標(biāo)被拆解成了更細(xì)的四個三級指標(biāo)。而上述案例中提到的產(chǎn)品功能，顯然目的不是提高試聽課約課率，也不是試聽課出席率，更不是出席完課率，而是在小孩上完試聽課之后，幫助銷售完成臨門一腳的拍單工作，顯然，該產(chǎn)品功能最能影響的三級指標(biāo)，是完課支付轉(zhuǎn)化率。

因此，我們可以確定，針對該項目，考核指標(biāo)選取完課支付轉(zhuǎn)化率，觀察項目上線前后指標(biāo)的變化來評估項目收益。

但是，這個評估方法依然是不完美的，即使到了很細(xì)節(jié)的三級指標(biāo)，在業(yè)務(wù)上的影響因素依然非常多，以完課支付率為例，該指標(biāo)依然受到潛在客戶的質(zhì)量，以及銷售個人能力的外部因素影響。為了更加客觀的分析，需要采用AB測試的辦法，選取兩批特征完全相同的銷售線索，一組作為實驗組，提供精彩視頻功能，一組作為對照組，不提供精彩視頻功能，從而觀察兩者在完課支付轉(zhuǎn)化率上的對比，來評估項目收益。

然而，B端功能很多時候難以采用AB測試，例如流程類的調(diào)整，上線就是全量，是沒有辦法新舊并存局部上線的。這可能正是B端產(chǎn)品業(yè)務(wù)收益難以衡量的一個致命問題，B端產(chǎn)品的AB測試以及小流量實驗，實施成本太高，甚至無法實施，這就導(dǎo)致很難準(zhǔn)確的比對、測量項目收益。而我們只能盡量選取精準(zhǔn)的相關(guān)的三級指標(biāo)來嘗試衡量收益。

以上提到的逐層拆解指標(biāo)來衡量項目收益的思路，實際上也是B端業(yè)務(wù)分析拆解的思路。在業(yè)務(wù)分析過程中，通過對數(shù)據(jù)指標(biāo)的逐步拆解，發(fā)現(xiàn)問題，針對某個關(guān)鍵指標(biāo)設(shè)計改進(jìn)方案，落地實施。

通過NPS評估用戶需求收益

用戶需求來自終端用戶，可能包括業(yè)務(wù)訴求，但更多的是體驗優(yōu)化。如果是業(yè)務(wù)類訴求，評估方式見上一節(jié)，如果是體驗優(yōu)化類訴求，一方面可以衡量操作效率的提升，另一方面還可以通過凈推薦值NPS（Net Promoter Score）來考核用戶對功能優(yōu)化的滿意度變化情況。

NPS由貝恩咨詢發(fā)明，本身是企業(yè)用來衡量消費(fèi)者對產(chǎn)品和服務(wù)的忠誠度與口碑，在消費(fèi)互聯(lián)網(wǎng)領(lǐng)域也有廣泛的應(yīng)用，是一種非常容易使用的用戶忠誠度、滿意程度評估工具。

NPS的使用非常簡單，設(shè)置一道問卷題目，然后將選擇9、10分的百分比，減去選擇0到6分的百分比，就得到了NPS分?jǐn)?shù)，如下圖。

NPS的使用和計算

不同領(lǐng)域、地區(qū)、企業(yè)規(guī)模的NPS均值并不相同；對產(chǎn)品功能調(diào)研NPS，得分的絕對值參考性有限，更好的使用方法，可以持續(xù)觀察NPS的變化趨勢。例如，可以針對產(chǎn)品的不同模塊定期調(diào)研NPS得分，判斷用戶體驗是否持續(xù)改善。

下圖是來自咨詢公司Retently的分析報告，展示了全球B2B業(yè)務(wù)不同領(lǐng)域的NPS得分情況（數(shù)據(jù)樣本來自于該公司的客戶資源庫），其中軟件行業(yè)的2022年NPS均值大概在40%，供大家參考。

Retently發(fā)布的2022全球B2B業(yè)務(wù)不同領(lǐng)域NPS平均分

通過綜合方案評估技術(shù)需求收益

技術(shù)需求又可以細(xì)分為四類，分別是基礎(chǔ)能力建設(shè)、中臺建設(shè)、純技術(shù)建設(shè)優(yōu)化，這四類方向區(qū)別比較大，如何評估收益，需要分別探討。

對于基礎(chǔ)能力建設(shè)項目，考核交付質(zhì)量和時間

B端產(chǎn)品，作為復(fù)雜系統(tǒng)，一整套體系的運(yùn)轉(zhuǎn)，必須是多種類型的軟件功能組合而成，例如，要有基本的權(quán)限管理，消息提醒管理，數(shù)據(jù)字典配置管理等功能，當(dāng)發(fā)展到一定階段，還需要流程引擎、報表引擎、表單引擎、視圖編輯器這些組件能力。

這類對業(yè)務(wù)沒有明顯價值和收益，但對于軟件系統(tǒng)又非常需要的功能，屬于基礎(chǔ)建設(shè)功能。對于此類項目，只需要正?？己私桓顿|(zhì)量、交付時間就可以，沒必要為了評估而非要生搬硬套某些業(yè)務(wù)價值，造成沒必要的麻煩。

對于中臺建設(shè)項目，考核系統(tǒng)接入量以及人力節(jié)約

中臺的目的是抽象建設(shè)可以復(fù)用的軟件系統(tǒng)或模塊，例如將各個業(yè)務(wù)系統(tǒng)都需要使用的消息中心、短信中心抽象成基礎(chǔ)服務(wù)，供多個系統(tǒng)使用。對于中臺產(chǎn)品或項目，我們可以考核其接入的客戶端數(shù)量，來衡量其被復(fù)用能力的強(qiáng)弱，以及推廣落地的結(jié)果。

此外，中臺產(chǎn)品很重要的一個目標(biāo)，是所謂避免重復(fù)造輪子問題，那么則可以通過其接入的客戶端數(shù)量，來估算研發(fā)人力成本的節(jié)省。

通過考核中臺產(chǎn)品客戶端的接入數(shù)量，可以很好地倒逼中臺產(chǎn)品經(jīng)理像一個推銷員一樣去推銷自己負(fù)責(zé)的中臺產(chǎn)品。因為多數(shù)情況下，大型企業(yè)的多部門產(chǎn)品線，并不在意甚至并不愿意主動接入中臺產(chǎn)品。雖然我們說中臺建設(shè)需要自上而下的意志，但是更多時候也需要自下而上的倒逼推進(jìn)。

對于純技術(shù)項目，考核系統(tǒng)穩(wěn)定性、安全性、時效性

對于純技術(shù)優(yōu)化需求和項目，例如微服務(wù)化、代碼重構(gòu)等，都是為了保證系統(tǒng)能夠運(yùn)行的更加穩(wěn)定、高效，架構(gòu)更加合理，靈活性更強(qiáng)，可以考慮衡量系統(tǒng)的穩(wěn)定性、安全性等非功能性指標(biāo)。當(dāng)然這些工作更多屬于技術(shù)團(tuán)隊決策，產(chǎn)品經(jīng)理了解即可。

終極衡量指標(biāo)：考核使用人數(shù)

我們已經(jīng)講了這么多評估的方法，但是很多時候，我們依然很難衡量某些B端產(chǎn)品功能對核心指標(biāo)的影響程度，但兩者在邏輯上卻又有著明顯的相關(guān)性。

例如，某銷售人員使用的OCRM系統(tǒng)，產(chǎn)品經(jīng)理對客戶詳情頁做了全面的升級，提供了豐富的視圖，可以讓銷售人員了解潛在客戶的所有重要信息，通過對其進(jìn)行畫像標(biāo)記，剖析其潛在需求和興趣點(diǎn)，幫助銷售人員更好的了解客戶，從而成功轉(zhuǎn)化。那么，如何衡量這套全新的“客戶詳情頁”的價值和收益呢？

再例如，某客服系統(tǒng)，上線了若干針對一線主管使用的報表，幫助其更好的監(jiān)控、管理下屬團(tuán)隊的服務(wù)過程和服務(wù)水平。那么，如何衡量這些報表對客服業(yè)務(wù)服務(wù)質(zhì)量和服務(wù)水平的改善作用呢？

如果你不能明確你的產(chǎn)品對業(yè)務(wù)產(chǎn)生的收益是什么，那么至少你可以評估有沒有人使用這些功能。這是非常具備實操性的一種評估方法，如果你設(shè)計了新的功能，那么，保留老功能的入口，讓用戶用腳投票，看看到底哪一套更受歡迎。當(dāng)然，有些新功能的推廣是需要培育的過程，讓用戶慢慢適應(yīng)接受。但是，如果沒有明確的策略要求，完全可以讓新老功能并存，看看到底哪套功能做的好。如果上線的功能沒有人用，那么一定是哪里出了問題！

前邊提到的詳情頁以及報表的案例，都可以考核用戶使用的UV、PV，來衡量產(chǎn)品的價值，以及是否成功。

收益難以量化評估，是B端產(chǎn)品共同的難點(diǎn)。但作為B端產(chǎn)品經(jīng)理，依然要盡最大努力評估、分析需求，否則就沒有繼續(xù)優(yōu)化迭代決策的依據(jù)，也是對公司寶貴RD資源最大的浪費(fèi)。

本節(jié)給出了不同類型產(chǎn)品需求的評估思路，只是供大家參考，希望給大家啟發(fā)；實際業(yè)務(wù)中情況要更加復(fù)雜，必須做出靈活調(diào)整和設(shè)計，而不要生搬硬套。

迭代中的研發(fā)資源管理

企業(yè)級軟件產(chǎn)品在技術(shù)上具有高度復(fù)雜性，研發(fā)人員不可能把所有精力都只投入在功能開發(fā)上，而應(yīng)該分配一定的資源在技術(shù)優(yōu)化和重構(gòu)上。本節(jié)，我們來探討研發(fā)資源的有效利用，以及產(chǎn)品不同發(fā)展階段的技術(shù)資源投入問題。

研發(fā)資源的人力跟蹤

在迭代優(yōu)化過程中，產(chǎn)品經(jīng)理要充分調(diào)動并利用研發(fā)資源，通過對人員的合理調(diào)配，保障不同項目之間無縫銜接，避免因為時間窗口不匹配導(dǎo)致研發(fā)資源閑置。

如何準(zhǔn)確管理研發(fā)人力呢？有一種很簡單實用的辦法，也是傳統(tǒng)項目管理中常用的辦法，即制作一張研發(fā)人力資源安排圖，通過這張圖可以清晰地看出每個研發(fā)人員在不同需求、項目上的時間投入規(guī)劃，并據(jù)此安排后續(xù)的工作。

在工作中，研發(fā)人員、產(chǎn)品經(jīng)理、業(yè)務(wù)人員之間總會有這樣的爭執(zhí)：為什么沒有排期？你們在做什么？人力都鋪在哪兒了？如果有這樣一張圖來清楚地呈現(xiàn)研發(fā)人員的工作安排，就可以避免這些爭執(zhí)。因此，維護(hù)好這張研發(fā)人力資源安排圖，也是對研發(fā)人員的一種保護(hù)，避免他們“蒙受”工作不飽和的懷疑和指責(zé)。

研發(fā)人力資源安排圖

產(chǎn)品不同發(fā)展階段的技術(shù)資源投入

軟件的代碼需要不斷地優(yōu)化。如果軟件升級迭代過程中只做產(chǎn)品功能需求，而不做技術(shù)優(yōu)化，隨著功能的積累，軟件系統(tǒng)會變得越來越脆弱，運(yùn)行速度會越來越慢，甚至頻繁宕機(jī)。因此，在日常的迭代升級中，必須給技術(shù)優(yōu)化預(yù)留足夠的資源。

應(yīng)該投入多少資源做技術(shù)優(yōu)化？這個問題在產(chǎn)品經(jīng)理和研發(fā)負(fù)責(zé)人之間似乎很難達(dá)成一致。研發(fā)負(fù)責(zé)人想多投入一些資源優(yōu)化系統(tǒng)，而產(chǎn)品經(jīng)理則認(rèn)為應(yīng)該首先解決業(yè)務(wù)需求。如何平衡業(yè)務(wù)需求和技術(shù)優(yōu)化之間的資源分配問題呢？

從大的方面來說，這和系統(tǒng)所處的階段有很大關(guān)系，不同階段資源分配的思路完全不同。結(jié)合業(yè)務(wù)發(fā)展周期，我們將系統(tǒng)建設(shè)歸納為四個階段，分別是初創(chuàng)階段、瓶頸階段、重構(gòu)階段、穩(wěn)定階段。

初創(chuàng)階段

在初創(chuàng)階段，業(yè)務(wù)還處于探索試錯期，業(yè)務(wù)本身不一定能成功。在這個階段，系統(tǒng)從無到有地構(gòu)建起來，研發(fā)團(tuán)隊要開足馬力支持業(yè)務(wù)，本階段的重點(diǎn)在于“活下去”。構(gòu)建的系統(tǒng)是一套全新的干凈系統(tǒng)，沒有任何歷史包袱，因此，可以鉚足勁兒開發(fā)業(yè)務(wù)功能，而不用太在意代碼、架構(gòu)的合理性，此時可以只預(yù)留10%的資源做技術(shù)優(yōu)化，甚至不做技術(shù)優(yōu)化。只要研發(fā)團(tuán)隊的水平靠得住，一套全新的系統(tǒng)在全力運(yùn)轉(zhuǎn)的狀態(tài)下對業(yè)務(wù)支持一年的時間，應(yīng)該是綽綽有余的，而一年正好是驗證業(yè)務(wù)是否能夠存活下去的關(guān)鍵時間點(diǎn)。

瓶頸階段

經(jīng)過一年的探索，證明了方向是正確的，業(yè)務(wù)取得了初步成果，并繼續(xù)保持高速發(fā)展。業(yè)務(wù)對新功能的渴望持續(xù)且強(qiáng)勁，產(chǎn)品研發(fā)團(tuán)隊依然開足馬力，但此時系統(tǒng)已經(jīng)顯現(xiàn)出疲態(tài)，“技術(shù)債”問題出現(xiàn)：曾經(jīng)的設(shè)計缺陷、硬編碼、架構(gòu)不合理等問題逐漸凸顯出來，系統(tǒng)三天兩頭出問題，Bug繁出，穩(wěn)定性差，與此同時，業(yè)務(wù)需求繼續(xù)井噴！

對于產(chǎn)品研發(fā)來說，一半的資源被修復(fù)Bug和迫在眉睫的技術(shù)優(yōu)化占用，另一半資源被難以維護(hù)的老代碼拖住。產(chǎn)品研發(fā)團(tuán)隊既不能痛快地滿足業(yè)務(wù)需求，也不能爽快地一次性解決系統(tǒng)結(jié)構(gòu)問題。此階段可能會持續(xù)1年到1.5年的時間，可謂整個產(chǎn)品研發(fā)團(tuán)隊的“噩夢時期”。

重構(gòu)階段

業(yè)務(wù)繼續(xù)發(fā)展且相對穩(wěn)定，業(yè)務(wù)需求依然絡(luò)繹不絕，但系統(tǒng)已瀕臨崩潰的邊緣。所有人都明白，償還技術(shù)債的終極時刻來臨了：公司層面決定，業(yè)務(wù)需求給技術(shù)重構(gòu)讓路，留給研發(fā)團(tuán)隊充足的時間重構(gòu)系統(tǒng)，一次性解決歷史問題。此階段可能會安排80%的資源做技術(shù)優(yōu)化重構(gòu)工作，包括代碼解耦、拆庫拆表、中間件升級、接口化、服務(wù)化等。

對于瓶頸階段和重構(gòu)階段分別持續(xù)多久、在什么時候發(fā)生，這個問題很難準(zhǔn)確回答，取決于業(yè)務(wù)情況、系統(tǒng)狀況、技術(shù)團(tuán)隊的話語權(quán)等因素。

此外，也有“邊開飛機(jī)邊換引擎”的成功案例，即在不影響業(yè)務(wù)的情況下，持續(xù)升級系統(tǒng)，開發(fā)新功能的同時完成系統(tǒng)重構(gòu)，但難度相對較大。需要結(jié)合具體的系統(tǒng)架構(gòu)和實際情況來判斷采取什么方案。

穩(wěn)定階段

該階段業(yè)務(wù)發(fā)展穩(wěn)定，系統(tǒng)運(yùn)行平穩(wěn)，Bug 少，不宕機(jī)。業(yè)務(wù)需求依然不停地提出，但此時研發(fā)工作顯得井井有條。即便如此，依然需要預(yù)留10%到20%的研發(fā)資源持續(xù)做技術(shù)優(yōu)化，這是保證系統(tǒng)持續(xù)穩(wěn)定的秘訣。

綜上所述，業(yè)務(wù)需求和技術(shù)優(yōu)化的研發(fā)資源分配，要根據(jù)業(yè)務(wù)發(fā)展和系統(tǒng)建設(shè)的階段來合理安排。不同階段對兩者投入的資源比例可參考下表。

不同系統(tǒng)發(fā)展階段下技術(shù)優(yōu)化資源投入比例建議

商業(yè)化產(chǎn)品的發(fā)展階段

以上分析和節(jié)奏適用于企業(yè)自研系統(tǒng)、支撐業(yè)務(wù)快速開展試錯的情況；商業(yè)化軟件產(chǎn)品的節(jié)奏不太一樣，雖然商業(yè)化產(chǎn)品一開始也不能太復(fù)雜，而應(yīng)該首先快速驗證市場，但相對于自研系統(tǒng)，對產(chǎn)品和技術(shù)架構(gòu)的合理性、規(guī)范性要求更高一些，因為畢竟是企業(yè)的主營售賣產(chǎn)品，而非某個業(yè)務(wù)的輔助支持工具，所以一開始的設(shè)計、投入需要更嚴(yán)謹(jǐn)，更充分，因此商業(yè)化產(chǎn)品本身的瓶頸期和重構(gòu)期的出現(xiàn)時間可能會更晚一些，但發(fā)展過程同樣也會經(jīng)歷以上四個階段，在技術(shù)資源的投入分配上原則是類似的。

作者：楊堃《決勝B端》作者，聊聊產(chǎn)品、職場。