本篇目錄：

原始需求與産品需求

• 區分原始需求和産品需求
• 原始需求提報管理

産品需求的層次和價值

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

需求池管理

需求的優先級

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

需求的驗證和評估

• 通過拆解指标評估業務需求收益
• 通過NPS評估用戶需求收益
• 通過綜合方案評估技術需求收益
• 終極衡量指标：考核使用人數

叠代中的研發資源管理

• 研發資源的人力跟蹤
• 産品不同發展階段的技術資源投入

産品上線後，需要進行持續的升級、叠代和優化，産品經理要管理需求，區分優先級，決定工作計劃，選擇做什麼和不做什麼。

這篇文章，我們進一步深入的探讨B端的需求管理和叠代優化工作，首先介紹原始需求的收集和管理；其次讨論産品需求的分類、層次和價值，接下來聊一聊需求池的管理，同時還會深入探讨需求的優先級設計問題，最後分享需求驗證的一些思路，以及持續叠代中技術資源的合理分配。

原始需求與産品需求優化

原始需求和産品需求是需求分析、管理工作中最基礎重要的概念，我們首先需要明确兩者的定義和區别。

區分原始需求和産品需求

不論是産品經理通過訪談、問卷收集的，還是業務方、用戶主動提報的需求，都是原始需求，原始需求中可能夾雜了若幹混合的訴求，既可能是痛點描述，也可能是用戶提出的解決方案。原始需求是終端用戶/客戶提給産品經理的訴求描述。

産品經理通過分析挖掘原始需求，找到痛點，形成軟件産品設計方案，從而形成産品需求，産品需求是顆粒度清晰、邏輯嚴謹完整的産品訴求，是産品經理提給研發人員的軟件設計方案。

原始需求是最原生态的需求描述，充滿了不确定性；産品需求則是分析問題後的的解決方案（或初步的思路拆解），具備确定性。原始需求在處理過程有可能被拆解成多個産品需求，也可能與其他原始需求合并變成同一個産品需求，原始需求和産品需求是多對多關系，産品需求會對應多個研發任務和測試任務，邏輯關系如下圖。

原始需求和産品需求的關系

例如，M公司分銷平台業務中，業務運營同學提交了一個原始需求，希望支持品類券（針對特殊品類生效的優惠券），并且發券數量超過1000張需要觸發審批。這個原始需求裡邊包含了兩個需求，一個是增加新的營銷工具（品類券），目的是提高客單價和收入；另一個是審核規則，目的是控制風險。

果凍分析後，将這個原始需求拆解為兩個産品需求，分别是品類券需求和審批流需求，其中審批流需求合并到規劃中的流程引擎項目中，構建一套完整的審批解決方案，品類券需求提交研發後，研發根據功能feature又創建了多個研發任務，包括：

• 任務一：品類券在商城前端的展現（包括購物車、訂單、個人中心等位置）；
• 任務二：品類券在後台的管理配置功能（包括列表頁、創建編輯頁）；
• 任務三：品類券的發放提醒功能（這部分可能會調用現成消息接口）；
• 任務四：品類券在交易結算中的分攤邏輯，以及台賬和财務處理規則；

實際研發任務拆的會更細緻，以上僅僅是示意，而且以上拆分的顆粒度，依然是功能點級别，每一個功能點背後可能還要對應多條研發任務。

可見，原始需求并不直接等同于産品需求，産品經理需要完成原始需求到産品需求的轉換設計。

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

在口頭交流中，為了方便，我們往往将原始需求和産品需求混在一起讨論，不會做嚴謹的區分；例如，當我們說“這個需求優先級不高”，這句話說的既可能是原始需求，也可能是産品需求。但在正式的需求池管理中，一定要對兩者進行區分，否則會帶來管理和執行上的混亂。

原始需求提報管理

不論是甲方做對内系統的産品經理，還是乙方做商業化的産品經理，都會面臨一個比較苦惱的問題，業務方或者客戶，總是提一些一句話的拍腦袋需求，很多時候根本沒有想清楚，但也會耗費産品經理大量的時間去溝通核實。

為了避免用戶不經思考随意提需求帶來沒必要的資源損耗，可以考慮讓用戶通過填寫需求提報模闆來提交需求，促使用戶提需求前把一些關鍵事項想明白，提高需求質量，尤其适合甲方公司。（乙方公司面臨的現實情況是需要更好的主動服務客戶，如果讓客戶通過模闆提需求估計老闆也不同意啊！）

具體模闆見下表，内容很容易理解，此處不再贅述，可以根據自身情況調整後使用。再次強調的是，任何需求，都應該提前想清楚需求價值，以及上線後如何衡量價值是否實現，并依據效果做持續的閉環優化跟蹤。不論是誰發起的需求，都應該提前想清楚需求的預期收益和度量方式。

原始需求提報表

産品需求的層次和價值

産品需求，從軟件工程角度來講，可以分為功能需求、非功能需求；從需求背後的業務價值和分類的角度來講，又可以分為業務需求、用戶需求、技術需求，這也體現了B端需求的三個層次。

需求的三個層次

在C端産品設計中，常常将馬斯洛模型作為C端産品需求洞察的理論基礎，并依此推演C端産品的用戶價值，以及進一步延展出用戶旅程、KANO模型等一系列構建C端産品設計的方法論。遺憾的是，這些模型和方法論并不完全适用于B端産品設計與需求管理，主要基于以下原因。

• B端産品面向企業或組織，幫助其解決某類經營管理問題，對于機構來講，需求的本質在于業務管理，無法通過馬斯洛模型來定義描述。
• B端産品的關注對象，除了機構本身，也需要關注業務用戶，而業務用戶的需求動機也并非馬斯洛模型可以解讀。
• B端産品作為複雜系統，除了承載業務目标，還需要考慮軟件架構設計、體系構建等問題，因此需求分析管理中，對于軟件産品本身還需要有足夠的關注度。

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

實際上，我們可以将B端需求分為三大類，分别為業務需求、用戶需求、技術需求，這三個類别本身由上到下具備層次關系，每一類需求處理權衡時都有不同的考量。

業務需求

業務需求，是自頂向下的需求，往往來自于中高層管理人員（或監管、政策要求），基于業務運營管理的直接訴求和要求，例如業務規則、管理制度、業務流程、組織機構，這些都屬于業務需求。

業務需求的分析過程，往往采用了經典傳統的軟件需求分析設計思路，重點通過業務診斷分析、抽象建模（DDD設計思想）、流程再造（BPR）的方式，進行需求分析和設計工作。

業務需求，承載了B端産品的業務價值，為相關業務的運營管理助一臂之力。注意這裡所說是業務價值，而非商業價值。商業價值往往要上升到企業的層面，而B端産品多數情況是為單一業務部門服務，承載的更多是業務價值。

業務需求，多數情況下難以衡量具體的收益，例如，很難衡量設計開發了某個CRM管理模塊，就會對銷售業績有多少程度的提升；即便如此，産品經理也要盡量嘗試量化收益和價值，關于幾類需求收益價值的讨論，在本章第四節會進一步展開。

用戶需求

用戶需求，是自下向上的需求，來自于一線業務用戶和基層管理人員，更多體現着業務人員對業務規則、流程、系統操作交互上的改進訴求。

現如今SaaS形态的B端産品都更加關注用戶體驗，其交互體驗和操作流暢度要好于傳統的管理軟件。在梳理B端産品的用戶需求時，可以大量借鑒C端産品的需求管理方法論，例如客戶旅程地圖，KANO模型等。

用戶需求體現了用戶價值。互聯網思維下，即便是B端産品，也需要重視用戶體驗和用戶價值，包括了功能滿意度和操作效率等；尤其是工具型、基礎服務類産品，解決了一線用戶的痛點，就是解決了業務的痛點，産品賦能終端用戶、重視體驗就顯得更為重要。

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

技術需求

B端産品複雜程度高，建設到一定階段，甚至有些時候在建設初期，就要考慮功能複用問題，以及與其他系統的架構設計與交互問題。例如，對于業務系統的權限管理模塊，是複用基礎服務，還是獨立開發？對于消息中心和公告通知模塊，是複用基礎服務還是獨立開發？除此以外，還有類似于軟件産品功能完備性提升的訴求，例如靈活的後台配置模塊，報表引擎的配置，視圖編輯器的配置，這類需求，我們可以統稱為技術需求。

技術需求往往不具備明顯的業務價值（但可能具備用戶體驗價值，例如視圖編輯器的能力構建），但是在軟件系統結構合理性設計上，具備顯著價值。除了讓架構合理，還能節約重複開發的人力浪費。産品需求承擔了軟件的系統價值，為系統自身優化而服務，讓系統自身合理并增值。

對于技術需求的收益評估，可以考核功能複用以及架構完善，對研發人力的成本節省。

業務需求、用戶需求、技術需求，作為B端需求的三大類型，也體現出了層次關系。對于B端産品的核心目标，首先服務于業務，要滿足業務需求；其次，要關注用戶的體驗和效率，滿足用戶需求；最後，要考慮軟件結構的合理性，滿足技術需求。

【資源推薦】

關于需求層次的更多分析，推薦貝恩咨詢分别于2016年、2018年發表于哈佛商業評論（HBR）的兩篇論文，探讨了基于馬斯洛需求層次在2C領域的價值要素金字塔模型；以及借鑒馬斯洛模型，嘗試構建了2B業務的價值要素金字塔模型。

需求的四類價值

B端産品需求的價值可以從對内對外兩個視角分為商業價值、技術價值、業務價值、用戶價值四大類。

商業價值

如果是商業化售賣産品，我們首先要判斷的是需求的商業價值，是否符合産品本身的定位和規劃，是否遵循産品商業化售賣的戰略訴求和經營要求。

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

如果是對内使用的産品，商業價值是比業務價值層次更高的，從企業整體戰略經營角度帶來的價值。

例如，M公司分銷平台的設計，首先是為了實現對分銷業務支持賦能的業務價值，在更深的層面，則支撐了M公司期望實現多元化經營戰略的商業價值的。

業務價值

B端産品除了承載商業價值，更需要幫助客戶、用戶在業務上取得成功，這是B端産品的業務價值。

我們在第1章講到過，B端産品對企業來講承擔着提升收入、降低成本、提高效率、保證品質、控制風險的重任，這些都是B端産品的業務價值。

用戶價值

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

技術價值

軟件産品在構建過程中，自身也存在技術層面的優化點，比如說，我們要将列表頁進行支持自定義設置的改造，從而解決為不同客戶三天兩頭硬編碼修改列表頁的煩人工作，這類需求是為了降低研發成本，或提升産品化能力而存在的；再比如說，為了解決企業客戶重複的問題，我們需要将産品背後的應用架構進行主數據改造，這類需求是為了改善架構合理性而存在的；這些都是技術需求背後可能的價值。

以上需求的四類價值，不論是商業化軟件産品，還是對内使用的産品，業務價值、用戶價值、技術價值本質上都最終服務于商業價值；而需求的三個層次正好一一應對這三類價值。

産品規劃建設過程中，四類價值的優先級并不是一成不變的，不同的産品階段可能有不同的優先級策略。

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

小結

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

需求的類别和價值

對原始需求分析後，進行拆散或合并，形成産品需求。從軟件工程角度來講，産品需求可以分為功能需求和非功能需求，從業務角度來講，又可以分為業務需求、用戶需求和技術需求，這也體現了需求的層次，具有天然發的優先級屬性。這三層需求也分别體現着産品的業務價值、用戶價值和技術價值，最終都是為了服務于商業價值。

需求池管理

産品經理需要管理維護兩個需求池，原始需求池，和産品需求池。

原始需求池記錄了所有用戶端提報的原始需求記錄，産品需求池，是對用戶需求經過初步分析拆解後形成的需求清單。

用戶需求池體現的是從用戶提報的角度來記錄，産品需求池體現的是從産品管理的角度來記錄。用戶需求和産品需求應該有明确的關聯，可以互相追溯，一方面方便用戶從提報需求的角度理解相關工作的進展，另一方面幫助産品經理找到産品設計背後對應的原始需求軌迹。

原始需求一旦記錄在案，更多的是存檔保留，産品需求則可能被更新、調整。一旦産品需求形成産品方案投入研發，就會進入明确的項目管理周期。

有條件的話，需求池管理應該使用項目管理軟件進行，但隻要負責人用心，Excel同樣可以管理好需求池。下邊，我們來介紹一個産品需求池中典型的字段：

• 産品需求ID

需求唯一性主鍵。

• 原始需求ID

對應的原始需求編号，可以為多個。

• 産品線

描述需求所在産品線（或對應的業務線），例如CRM系統或客服系統等。

• 需求類型

需求類型應該做謹慎的設計分類，主要目的用來分析資源在不同業務方向上投入的情況。可能的需求類型包括業務需求、用戶需求、技術需求，或者純粹根據業務價值分類，包括：提升規模、降低成本、提高效率、控制風險、保障品質、體驗優化等。總之，要根據自身情況設計一個合理的分類。

• 是否插隊

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

• 主題

需求的一句話概述。

• 内容

需求的具體描述。

• 來源

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

• 需求提出日期

收到需求的日期。有些公司會要求産研團隊提高需求響應速度，可能會通過上線日期和需求提出日期的時間差來進行考核評估。

• 優先級

優先級會在下一節詳細介紹。

• 叠代版本

如果采用了敏捷開發模式，就需要标記需求排期開發時的叠代版本。

• 業務負責人

該需求業務口的唯一負責人

• 産品經理

該需求對應的産品經理。

• 研發負責人

研發負責人一定是研發的整體負責人，而不應該分成後端負責人、前端負責人，因為那樣很可能導緻兩者各自負責自己的工作，但是對于技術實現的整體方案和進度沒有把控，相當于沒有技術負責人。

• 測試負責人

如果研發負責人全權管理研發、測試工作，則不需要單獨指定測試負責人。否則，要明确安排測試負責人，對質量結果和進度負責。

• 狀态

狀态用來描述需求的生命周期，狀态值可以包括如下選項：

待跟進、需求調研中、PRD編寫中、待PRD評審、待技術評審、待排期、待開發、開發中、待測試、測試中、待驗收、待上線、已上線、暫停、終止。

這些狀态值較好地覆蓋了從需求采集到上線的完整生命周期，仔細觀察後可以發現，這些狀态的設計符合我們在介紹狀态機圖時提出的建議，即狀态應該是能持續足夠時長的，不應該是很快就結束的（所以我們沒有定義“需求評審中”這種狀态，因為需求評審隻需要開幾個小時的會議就可以完成，沒有必要在開會前改一下需求狀态，開會後再次修改）。

• 狀态變更說明

對某些狀态字段的補充解釋，例如如果狀态被修改為“暫停”，需要選擇被暫停的具體原因。

• 計劃上線日期

計劃上線日期是在技術評審結束後，研發負責人确定工時和資源投入後給出的目标上線日期。

• 實際上線日期

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

• 前端開始日期/前端結束日期

前端開發工作的開始日期和結束日期。

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

• 前端研發工作量（人日）

即前端開發工作預計投入的總工時。在敏捷開發中，可能通過基于經驗的“點數”來評估工時。

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

• 發版計劃

在移動端産品中，需求上線可能涉及發版，即需要發布新的客戶端，因此要在表格中記錄發版的版本号。

合理運用上述模闆，可以幫助産品經理将需求和項目管理得井井有條。認真填寫模闆中的各項内容，可以幫自己較好地分析需求跟進情況、研發效率、工作量投入等。

如果某個需求涉及跨端或跨團隊開發，則需要按照子項目将模闆進一步細化，例如每個子項目要安排各自的研發負責人、産品負責人，有各自的工時、工期等，然後再填寫具體字段。

在實踐中，并不一定在産品需求池中記錄管理研發狀态，有可能産品需求池隻管理産品層面的需求清單，具體的研發執行，會通過另一個研發任務池進行管理。總之，根據自己團隊的習慣和風格，或者公司的統一要求，選定一個模式或方案，持續執行，正确記錄相關字段和内容，保證可以做出11.3小節那樣的整體性分析，以便持續優化産研效率，就可以了。

需求的優先級

需求優先級的判斷，是産品經理工作的一個難點。決策先做什麼，再做什麼，決定了産品的發展路徑和節奏，甚至會決定産品在市場環境中競争的優劣。遺憾的是，優先級的判斷，在實踐中，很難通過一套理性的方法論作為客觀的執行依據，很多時候，優先級的判定是一門藝術，融合了對戰略、市場、競争态勢、業務發展、研發資源、團隊情況的綜合判斷。

即便如此，産品經理需要了解業界經典的優先級定義的方法論，在不同的場景和情況下，給自己更多的思路和啟發。

成本價值模型

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

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

需求優先級的成本價值模型

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

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

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

RICE模型

對于SaaS軟件，判斷需求的價值時，還可以将受影響客戶數量考慮進來，這就需要參考來自矽谷的RICE模型。

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

• R：Reach，需求功能觸達的客戶數量；
• I：Impact，需求的價值打分，例如可以定義1到10分；
• C：Confidence，産品經理對需求的信心程度，是一個基于主觀判斷的修正參數；
• E：Effort，需求需要投入的研發人天；

通過這四個變量，對需求進行打分，可以得到優先級RICE得分，計算公式如下：

RICE Score = Reach * Impact * Confidence / Effort

例如，下表是兩個需求通過RICE模型計算後的得分，根據分數，認為需求1優先級高于需求2。

通過RICE模型對需求優先級進行打分

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

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

其次，在商業運作中，并不能簡單的認為，在其他變量相同的情況下，需求影響的客戶數量多，優先級就高。有些需求，可能隻服務于某個頭部客戶，但卻具有标杆效應和示範效應，本身就有很高的商業價值。

因此，關于RICE模型的應用，要想清楚場景和目的。

價值範圍模型

價值範圍模型，是一個專門分析、衡量需求價值的模型，是我根據工作實踐總結而成的，在和不同的企業交流中，我發現很多團隊有着類似的思考和實踐。

我們可以将一個軟件産品所能提供的價值（即本書中多次提到的B端産品的五個典型價值，規模、成本、效率、風險、品質，再加一個産品本身的用戶體驗）列在縱軸，把業務相關的利益方都列在橫軸，就得到一個多象限矩陣，有了這個矩陣，我們可以根據當前階段業務的計劃和商業的訴求，制定一個優先級打分表。

和業務方達成一緻認知，設計好這張表格，後續所有的需求，都可以找到表格中的位置，以及對應的優先級。

例如，下圖是M公司分銷平台的範圍價值模型打分表，表格中縱軸是分銷平台對業務本身的價值，橫軸是涉及到的利益方，單元格中直接定義了優先級。

M公司領導本身也代表了業務，所以提升收入的相關需求都可以納入M公司領導和提升收入這兩個坐标定位的單元格，我們認為分銷平台核心目的是提升收入，所以這類需求優先級最高。

而針對M公司領導個人的降本增效、産品體驗類需求，優先級都比較低，因為領導本身也不常用系統，不用為了領導一個人的使用體驗而投入資源進行優化。

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

以此類推，基于對業務的判斷和理解，梳理了角色和産品本身具備的業務價值，進一步設計了完整的優先級打分表。

價值範圍模型打分表

價值範圍模型比較适合用于企業對内産品研發中的需求優先級打分，在實際應用中會有很多變化和調整，例如作為一個中台産品，可以将橫軸替換為中台産品服務的各個事業部業務線，提前規劃好對不同業務線的支持力度，作為優先級判斷的決策依據。

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

ANO模型

KANO模型，常常用來分析單一用戶視角下需求的接受度，由東京理工大學教授狩野紀昭（Noriaki Kano）發明。嚴格來講，KANO模型研究的是産品功能點和用戶滿意度之間的關系，但結論可以作為優先級的排序依據。

KANO模型雖然并不是為互聯網産品發明，但卻是互聯網圈最網紅的方法論。簡單來講，KANO模型将産品的功能點對用戶進行問卷調研，通過正反兩問來獲取用戶的感知，類似于這樣：

正向提問：如果提交訂單後馬上提示開發票，你的感受是：

A.我很喜歡 B.理應如此 C.無所謂 Ｄ.勉強接受 E.我不喜歡

反向提問問：如果提交訂單後并不提示開發票，你的感受是：

A.我很喜歡 B.理應如此 C.無所謂 Ｄ.勉強接受 E.我不喜歡

接下來，對用戶的反饋進行統計，獲得不同答案結果的占比，并統計到下表。

KANO模型統計表

拿到統計數據後，經過一系列計算，可以分析出功能點的屬性特征，具體有以下五種：

• A，魅力屬性：提供功能用戶會很喜歡，但不提供也無所謂；
• O，期望屬性：提供功能用戶很喜歡，不提供則不喜歡，用戶對功能有強烈期待；
• M，必備屬性：提供功能用戶覺得感受一般，但不提供則用戶強烈不喜歡，說明是必備功能；
• I，無差異屬性：不論是否提供功能，用戶感受都趨于平和；
• R，反向屬性：提供功能用戶不開心，不提供功能用戶反而開心；
• Q：可疑結果：結論邏輯相悖，屬于髒數據；

KANO模型的具體詳細說明，網絡上資料很多，本書不再贅述。此處需要強調的是，KANO模型并不完全适用于B端，因為B端背後面臨着多角色和多利益方，而不同利益方之間可能具有利益互反的特點。

例如，釘釘的已讀未讀功能，對老闆來講，可能是期望屬性，而對員工來講，可能是反向屬性。

再例如，銷售型CRM的拜訪錄入功能，對老闆來講，可能是必備屬性，而對一線銷售來講，可能是反向屬性。

因此，對KANO模型的使用，一定要明确場景，切勿盲目應用。

需求的驗證和評估

我們已經多次強調，作為一名産品經理，分析需求時一定要提前考慮好，上線後如何持續跟蹤，判斷功能是否達到了預期的業務效果。但是客觀的講，B端産品的功能，很多時候，難以量化收益，或者說很難衡量需求或項目的效果。因為B端産品最終要解決業務問題，而業務上的效果和效益，除了軟件産品本身的影響以外，往往還取決于業務政策，以及業務人員的能力和态度等多方面的因素。

舉個例子，針對給銷售人員使用的OCRM系統，做了若幹需求預期提高銷售的轉化率，但實際上影響轉化率的因素太多了，客戶質量，傭金政策，銷售能力，都是影響因素，這些因素互相摻雜在一起，導緻項目組很難衡量轉化率指标的變化，究竟有多少是因為産品功能影響改善的。

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

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

通過拆解指标評估業務需求收益

評估業務需求的價值，可以先找到其對企業的價值大類（無外乎規模、成本、效率、品質、風險），然後盡量将價值大類的一級業務指标拆細，嘗試找到和業務需求最相關的二級指标或三級指标，作為評估度量的核心指标。

不論是規模、成本，還是效率、品質，在業務運作中，都可以首先找到對應的一級指标，例如：

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

各個業務線或業務單元，都會有核心一級指标作為北極星指标存在，指引業務的方向和目标。通過将一級指标層層拆解，盡量找到貼合需求價值的二級或三級指标。

例如，某在線教育的OCRM産品經理在設計實現了銷售打單輔助工具，在試聽課結束後生成小孩在試聽課中的精彩片段，由銷售人員發給家長，作為銷售打單工具。該産品功能，核心目标是提高轉化率，但是轉化率作為二級指标，顆粒度依然很粗，影響因素太多。此時，我們嘗試将轉化率漏鬥進行層層拆解：

轉化率 = 試聽課邀約率 * 試聽課出席率 * 出席完課率 * 完課支付轉化率

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

因此，我們可以确定，針對該項目，考核指标選取完課支付轉化率，觀察項目上線前後指标的變化來評估項目收益。

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

然而，B端功能很多時候難以采用AB測試，例如流程類的調整，上線就是全量，是沒有辦法新舊并存局部上線的。這可能正是B端産品業務收益難以衡量的一個緻命問題，B端産品的AB測試以及小流量實驗，實施成本太高，甚至無法實施，這就導緻很難準确的比對、測量項目收益。而我們隻能盡量選取精準的相關的三級指标來嘗試衡量收益。

以上提到的逐層拆解指标來衡量項目收益的思路，實際上也是B端業務分析拆解的思路。在業務分析過程中，通過對數據指标的逐步拆解，發現問題，針對某個關鍵指标設計改進方案，落地實施。

通過NPS評估用戶需求收益

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

NPS由貝恩咨詢發明，本身是企業用來衡量消費者對産品和服務的忠誠度與口碑，在消費互聯網領域也有廣泛的應用，是一種非常容易使用的用戶忠誠度、滿意程度評估工具。

NPS的使用非常簡單，設置一道問卷題目，然後将選擇9、10分的百分比，減去選擇0到6分的百分比，就得到了NPS分數，如下圖。

NPS的使用和計算

不同領域、地區、企業規模的NPS均值并不相同；對産品功能調研NPS，得分的絕對值參考性有限，更好的使用方法，可以持續觀察NPS的變化趨勢。例如，可以針對産品的不同模塊定期調研NPS得分，判斷用戶體驗是否持續改善。

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

Retently發布的2022全球B2B業務不同領域NPS平均分

通過綜合方案評估技術需求收益

技術需求又可以細分為四類，分别是基礎能力建設、中台建設、純技術建設優化，這四類方向區别比較大，如何評估收益，需要分别探讨。

對于基礎能力建設項目，考核交付質量和時間

B端産品，作為複雜系統，一整套體系的運轉，必須是多種類型的軟件功能組合而成，例如，要有基本的權限管理，消息提醒管理，數據字典配置管理等功能，當發展到一定階段，還需要流程引擎、報表引擎、表單引擎、視圖編輯器這些組件能力。

這類對業務沒有明顯價值和收益，但對于軟件系統又非常需要的功能，屬于基礎建設功能。對于此類項目，隻需要正常考核交付質量、交付時間就可以，沒必要為了評估而非要生搬硬套某些業務價值，造成沒必要的麻煩。

對于中台建設項目，考核系統接入量以及人力節約

中台的目的是抽象建設可以複用的軟件系統或模塊，例如将各個業務系統都需要使用的消息中心、短信中心抽象成基礎服務，供多個系統使用。對于中台産品或項目，我們可以考核其接入的客戶端數量，來衡量其被複用能力的強弱，以及推廣落地的結果。

此外，中台産品很重要的一個目标，是所謂避免重複造輪子問題，那麼則可以通過其接入的客戶端數量，來估算研發人力成本的節省。

通過考核中台産品客戶端的接入數量，可以很好地倒逼中台産品經理像一個推銷員一樣去推銷自己負責的中台産品。因為多數情況下，大型企業的多部門産品線，并不在意甚至并不願意主動接入中台産品。雖然我們說中台建設需要自上而下的意志，但是更多時候也需要自下而上的倒逼推進。

對于純技術項目，考核系統穩定性、安全性、時效性

對于純技術優化需求和項目，例如微服務化、代碼重構等，都是為了保證系統能夠運行的更加穩定、高效，架構更加合理，靈活性更強，可以考慮衡量系統的穩定性、安全性等非功能性指标。當然這些工作更多屬于技術團隊決策，産品經理了解即可。

終極衡量指标：考核使用人數

我們已經講了這麼多評估的方法，但是很多時候，我們依然很難衡量某些B端産品功能對核心指标的影響程度，但兩者在邏輯上卻又有着明顯的相關性。

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

再例如，某客服系統，上線了若幹針對一線主管使用的報表，幫助其更好的監控、管理下屬團隊的服務過程和服務水平。那麼，如何衡量這些報表對客服業務服務質量和服務水平的改善作用呢？

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

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

收益難以量化評估，是B端産品共同的難點。但作為B端産品經理，依然要盡最大努力評估、分析需求，否則就沒有繼續優化叠代決策的依據，也是對公司寶貴RD資源最大的浪費。

本節給出了不同類型産品需求的評估思路，隻是供大家參考，希望給大家啟發；實際業務中情況要更加複雜，必須做出靈活調整和設計，而不要生搬硬套。

叠代中的研發資源管理

企業級軟件産品在技術上具有高度複雜性，研發人員不可能把所有精力都隻投入在功能開發上，而應該分配一定的資源在技術優化和重構上。本節，我們來探讨研發資源的有效利用，以及産品不同發展階段的技術資源投入問題。

研發資源的人力跟蹤

在叠代優化過程中，産品經理要充分調動并利用研發資源，通過對人員的合理調配，保障不同項目之間無縫銜接，避免因為時間窗口不匹配導緻研發資源閑置。

如何準确管理研發人力呢？有一種很簡單實用的辦法，也是傳統項目管理中常用的辦法，即制作一張研發人力資源安排圖，通過這張圖可以清晰地看出每個研發人員在不同需求、項目上的時間投入規劃，并據此安排後續的工作。

在工作中，研發人員、産品經理、業務人員之間總會有這樣的争執：為什麼沒有排期？你們在做什麼？人力都鋪在哪兒了？如果有這樣一張圖來清楚地呈現研發人員的工作安排，就可以避免這些争執。因此，維護好這張研發人力資源安排圖，也是對研發人員的一種保護，避免他們“蒙受”工作不飽和的懷疑和指責。

研發人力資源安排圖

産品不同發展階段的技術資源投入

軟件的代碼需要不斷地優化。如果軟件升級叠代過程中隻做産品功能需求，而不做技術優化，随着功能的積累，軟件系統會變得越來越脆弱，運行速度會越來越慢，甚至頻繁宕機。因此，在日常的叠代升級中，必須給技術優化預留足夠的資源。

應該投入多少資源做技術優化？這個問題在産品經理和研發負責人之間似乎很難達成一緻。研發負責人想多投入一些資源優化系統，而産品經理則認為應該首先解決業務需求。如何平衡業務需求和技術優化之間的資源分配問題呢？

從大的方面來說，這和系統所處的階段有很大關系，不同階段資源分配的思路完全不同。結合業務發展周期，我們将系統建設歸納為四個階段，分别是初創階段、瓶頸階段、重構階段、穩定階段。

初創階段

在初創階段，業務還處于探索試錯期，業務本身不一定能成功。在這個階段，系統從無到有地構建起來，研發團隊要開足馬力支持業務，本階段的重點在于“活下去”。構建的系統是一套全新的幹淨系統，沒有任何曆史包袱，因此，可以鉚足勁兒開發業務功能，而不用太在意代碼、架構的合理性，此時可以隻預留10%的資源做技術優化，甚至不做技術優化。隻要研發團隊的水平靠得住，一套全新的系統在全力運轉的狀态下對業務支持一年的時間，應該是綽綽有餘的，而一年正好是驗證業務是否能夠存活下去的關鍵時間點。

瓶頸階段

經過一年的探索，證明了方向是正确的，業務取得了初步成果，并繼續保持高速發展。業務對新功能的渴望持續且強勁，産品研發團隊依然開足馬力，但此時系統已經顯現出疲态，“技術債”問題出現：曾經的設計缺陷、硬編碼、架構不合理等問題逐漸凸顯出來，系統三天兩頭出問題，Bug繁出，穩定性差，與此同時，業務需求繼續井噴！

對于産品研發來說，一半的資源被修複Bug和迫在眉睫的技術優化占用，另一半資源被難以維護的老代碼拖住。産品研發團隊既不能痛快地滿足業務需求，也不能爽快地一次性解決系統結構問題。此階段可能會持續1年到1.5年的時間，可謂整個産品研發團隊的“噩夢時期”。

重構階段

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

對于瓶頸階段和重構階段分别持續多久、在什麼時候發生，這個問題很難準确回答，取決于業務情況、系統狀況、技術團隊的話語權等因素。

此外，也有“邊開飛機邊換引擎”的成功案例，即在不影響業務的情況下，持續升級系統，開發新功能的同時完成系統重構，但難度相對較大。需要結合具體的系統架構和實際情況來判斷采取什麼方案。

穩定階段

該階段業務發展穩定，系統運行平穩，Bug 少，不宕機。業務需求依然不停地提出，但此時研發工作顯得井井有條。即便如此，依然需要預留10%到20%的研發資源持續做技術優化，這是保證系統持續穩定的秘訣。

綜上所述，業務需求和技術優化的研發資源分配，要根據業務發展和系統建設的階段來合理安排。不同階段對兩者投入的資源比例可參考下表。

不同系統發展階段下技術優化資源投入比例建議

商業化産品的發展階段

以上分析和節奏适用于企業自研系統、支撐業務快速開展試錯的情況；商業化軟件産品的節奏不太一樣，雖然商業化産品一開始也不能太複雜，而應該首先快速驗證市場，但相對于自研系統，對産品和技術架構的合理性、規範性要求更高一些，因為畢竟是企業的主營售賣産品，而非某個業務的輔助支持工具，所以一開始的設計、投入需要更嚴謹，更充分，因此商業化産品本身的瓶頸期和重構期的出現時間可能會更晚一些，但發展過程同樣也會經曆以上四個階段，在技術資源的投入分配上原則是類似的。

作者：楊堃《決勝B端》作者，聊聊産品、職場。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!