編輯導(dǎo)語：產(chǎn)品管理流程是很復(fù)雜的，稍不注意就會(huì)出現(xiàn)差錯(cuò)，然而規(guī)范的流程是怎樣的？流程不規(guī)范有什么危害？需要注意些什么？可能很多人都還不知道，基于此，本文作者總結(jié)了那些踩過的坑，為大家詳細(xì)的羅列出了規(guī)范的產(chǎn)品管理流程，希望看后對(duì)你能夠有所幫助。

一、前言

1. 為何寫這系列文章

1）親身經(jīng)歷

• 產(chǎn)品流程混亂無序
• 開發(fā)直接對(duì)接業(yè)務(wù)
• 隨時(shí)插入新的開發(fā)功能
• 交接資料為零
• 接手的工作未畫流程圖
• 進(jìn)入業(yè)務(wù)之后，發(fā)現(xiàn)流程等各種產(chǎn)品文檔缺失嚴(yán)重
• 版本更新內(nèi)容未記錄
• 產(chǎn)品記錄資料中間連續(xù)斷層

在與眾多產(chǎn)品溝通的時(shí)候，發(fā)現(xiàn)這是一個(gè)很普遍的問題，我基于已經(jīng)趟過的坑，想聊一下。

2）產(chǎn)品流程管理及文檔不規(guī)范有什么害處

增加了額外的成本及問題，這些成本包括：

• 新人對(duì)項(xiàng)目的上手時(shí)間成本；
• 因資料缺失導(dǎo)致的溝通成本；
• 研發(fā)周期加長(zhǎng)導(dǎo)致的進(jìn)度問題；
• 無文本信息，問題反復(fù)，理解不一致導(dǎo)致的團(tuán)隊(duì)信任成本；
• 人員流失導(dǎo)致信息斷層的問題。

特別在業(yè)務(wù)不斷擴(kuò)張，人員團(tuán)隊(duì)擴(kuò)容，任務(wù)復(fù)雜度增加，管理及文檔的規(guī)范化將發(fā)揮巨大作用。

2. 怎樣寫這個(gè)系列文章

基于這個(gè)認(rèn)知，在我的產(chǎn)品經(jīng)理職業(yè)生涯中，逐步搭建了一套產(chǎn)品流程及規(guī)范文檔，進(jìn)行了實(shí)踐，取得了一定的效果：內(nèi)部認(rèn)知語言統(tǒng)一、溝通時(shí)間更短、各方效率提高、文檔可追溯查詢、人員變動(dòng)流失影響更小、權(quán)責(zé)清晰等。

此系列文章將對(duì)此套管理流程及規(guī)范做分享，主要約定公司產(chǎn)品從立項(xiàng)到產(chǎn)品上線的整個(gè)過程，產(chǎn)品經(jīng)理的做事流程，產(chǎn)品經(jīng)理需要完成哪些事情，需要產(chǎn)生哪些文檔以及文檔產(chǎn)出的規(guī)范。

本系列文章主要涉及方面包括：

• 產(chǎn)品需求的收集
• 產(chǎn)品需求管理
• 產(chǎn)品規(guī)劃
• 產(chǎn)品原型設(shè)計(jì)
• 產(chǎn)品需求的輸出文檔
• 產(chǎn)品驗(yàn)收
• 產(chǎn)品版本命名規(guī)則
• 產(chǎn)品發(fā)版管理

二、需求層級(jí)

1. 戰(zhàn)略性需求

為產(chǎn)品定基調(diào)，定方向的需求，比如說，我們要做一個(gè)母嬰方向的垂直電商平臺(tái)。

引起戰(zhàn)略性需求的因素可能有兩大部分：

• 一部分是由外部因素引起（如新技術(shù)趨勢(shì)、市場(chǎng)變化、社會(huì)交流方式等出現(xiàn)的新機(jī)會(huì)）；
• 一部分是內(nèi)部的技術(shù)、資源整合再利用，在原有業(yè)務(wù)方向之外的拓展（比如華為利用他的技術(shù)積累往手機(jī)方向發(fā)展，滴滴利用在出行上的數(shù)據(jù)積累做無人駕駛汽車）。

這會(huì)延伸出新增及拓展的兩類，新增比如原來做團(tuán)購，現(xiàn)在增加外賣業(yè)務(wù)。拓展比如本身做外賣業(yè)務(wù)，配送團(tuán)隊(duì)由第三方完成，現(xiàn)在外賣訂單量大之后自己做配送，拓展有橫向及縱向擴(kuò)展，縱向是上下游產(chǎn)業(yè)鏈整合，橫向是業(yè)務(wù)多元化。

此部分參與人員一般是公司最高層，至少是項(xiàng)目的最高層核心人員參與。

這涉及到商業(yè)模式的綜合分析，在本文中不做過多擴(kuò)展，后期將專門寫一些文章專門分析。本文主要還是集中在產(chǎn)品需求收集、管理流程及規(guī)范上。

2. 戰(zhàn)術(shù)需求

戰(zhàn)術(shù)需求比戰(zhàn)略需求低一層級(jí)，是對(duì)戰(zhàn)略的拆分，也即是通常意義說的產(chǎn)品實(shí)現(xiàn)路線的每個(gè)階段。

比如說：做本地生活服務(wù)平臺(tái)，前期商家體量小，盡快的實(shí)現(xiàn)業(yè)務(wù)流轉(zhuǎn)，前期合同可以線下簽訂，可以只做PC端；后期逐步的實(shí)現(xiàn)電子合同，手機(jī)APP，網(wǎng)頁適配等。

3. 戰(zhàn)役需求

戰(zhàn)役是對(duì)戰(zhàn)術(shù)的再拆分，也就是每一個(gè)階段性的具體實(shí)施。

比如：商家合同電子簽如何實(shí)現(xiàn)，登錄方式如何處理。當(dāng)然，這是簡(jiǎn)單的區(qū)分，實(shí)際中短期需求也需要考慮到后期的可擴(kuò)展性，否則做出來的東西后期改動(dòng)成本會(huì)非常大。

比如說登錄方式，如果不考慮各平臺(tái)，各渠道賬戶打通等，后期的對(duì)接，用戶數(shù)據(jù)的集中處理將會(huì)面臨很大的問題。

二、需求的來源

1. 內(nèi)部客戶

簡(jiǎn)單說就是公司內(nèi)部決策高層及各部門具體使用人員，對(duì)產(chǎn)品在使用中發(fā)現(xiàn)的問題，提出的優(yōu)化改善運(yùn)營(yíng)策劃方案。

如運(yùn)營(yíng)使用頻率最高，客服部與用戶溝通頻率最高，都能發(fā)現(xiàn)很多需求及問題。

此部分需求，具體使用部門一般主要集中在對(duì)現(xiàn)有產(chǎn)品的優(yōu)化迭代，在流程的優(yōu)化、體驗(yàn)的優(yōu)化，業(yè)務(wù)線的深化拓展。

內(nèi)部客戶的需求收集整個(gè)流程：

由內(nèi)部用戶填寫需求功能收集表，按照一定的周期提交產(chǎn)品經(jīng)理，并進(jìn)行溝通討論，根據(jù)商業(yè)價(jià)值、技術(shù)可實(shí)現(xiàn)度、優(yōu)先級(jí)、產(chǎn)品路線節(jié)奏規(guī)劃等考慮點(diǎn)判斷是否要做，及做的安排。短期內(nèi)不做，或者有其它方法可解決的情況下，與需求提出方溝通其它解決方案（如：在項(xiàng)目的早期，以MVP方式做，則很多分析類的需求，在數(shù)據(jù)量較小，工作復(fù)雜程度較小的時(shí)候，是可以通過將相關(guān)數(shù)據(jù)埋點(diǎn)進(jìn)行導(dǎo)出手動(dòng)分析，則這個(gè)時(shí)候做大量的系統(tǒng)數(shù)據(jù)分析需求及實(shí)用性不大）。

如果需求溝通之后確認(rèn)要做，則將需求放入排期中，并將需求對(duì)接清楚，各方通過簽字或其它方式進(jìn)行確認(rèn)。

一般來說，如果不是非常緊急的需求及bug修復(fù)等，按照一周一次的提交頻率進(jìn)行是一種較好的方式，因?yàn)楫a(chǎn)品進(jìn)展到一定的程度之后，大概率也是按照一定的固定頻率進(jìn)行更新。

這樣一方面給產(chǎn)品經(jīng)理可以留下其它時(shí)間來完成手上的工作，不至于經(jīng)常打亂節(jié)奏，另一方面可以給需求提出方一定的思考完善時(shí)間，補(bǔ)足一些明顯的業(yè)務(wù)邏輯漏洞。

但這個(gè)需要前期進(jìn)行部門之間的溝通，形成一定的機(jī)制。

其它部門很容易出現(xiàn)的狀況是，有一個(gè)想法就想立即與產(chǎn)品經(jīng)理進(jìn)行溝通，這是人的一種本能，有任何問題及疑問，想法就想立即溝通。但產(chǎn)品及業(yè)務(wù)的工作，是屬于較為復(fù)雜的知識(shí)性工作，這種工作的方式是要進(jìn)行大量的決策及權(quán)衡，不如一些潛意識(shí)的行為方式，直覺的判斷。

要克服這一點(diǎn)，只有各部門之間達(dá)成一個(gè)溝通機(jī)制，做一定的固化。

內(nèi)部需求收集的整體流程如下：

2. 外部客戶

外部客戶的調(diào)研，這要看產(chǎn)品是針對(duì)的B端用戶還是C端用戶，B端用戶的目標(biāo)客戶群較為清晰。

B端用戶要分決策購買人和使用者，最好的方式是同時(shí)滿足兩者的需求。

這兩者有不同點(diǎn)，比如決策者的依據(jù)是對(duì)企業(yè)好（其它目的不進(jìn)行討論），比如員工行為數(shù)據(jù)可視化、流程線上化。這樣可以對(duì)員工進(jìn)行監(jiān)管，同時(shí)數(shù)據(jù)更為實(shí)時(shí)，后期商業(yè)決策更加有依據(jù)。

實(shí)際在做的時(shí)候，需要深入業(yè)務(wù)中調(diào)研，也需要對(duì)流程進(jìn)行優(yōu)化，不能只是簡(jiǎn)單的將原有的流程完全搬到線上，或者簡(jiǎn)單的搞高大上的可視化顯示，因?yàn)檫@樣會(huì)增加實(shí)際操作人員的成本，并未能提高效率，縮減成本。

一般B端業(yè)務(wù)，深入業(yè)務(wù)，對(duì)相關(guān)關(guān)系人進(jìn)行足夠的溝通，則需求將比較明顯能夠提煉出來。

C端的用戶，業(yè)務(wù)縱深一般沒有B端的程度深，但目標(biāo)用戶的明確性，用戶的需求會(huì)不這么明顯，需求調(diào)研所花費(fèi)的工作將會(huì)更多。

總體來說，B、C都采用線上及線下的方式進(jìn)行調(diào)研。線上調(diào)研一般是調(diào)研問卷的方式，以及參考行業(yè)相關(guān)資料，競(jìng)對(duì)資料，線下一般采用拜訪（預(yù)設(shè)或不預(yù)設(shè)問題），邀請(qǐng)用戶集中溝通，頭腦風(fēng)暴等方式。

不同的調(diào)研方式適用的階段，操作的方式都不一樣，這一方面要多注意。具體的調(diào)研方式，大家可以進(jìn)行網(wǎng)絡(luò)搜索查看詳情，后期我也可以針對(duì)不同階段，不同類型業(yè)務(wù)采用何種調(diào)研方法寫文章闡述。

以下為外部需求收集的流程：

三、需求收集標(biāo)準(zhǔn)化文檔

產(chǎn)品需求收集表：以下為需求收集表的樣式，需要說明需求提出方，需求的名稱，將需求描述清楚（主要解決為什么做，做什么，怎么做這幾個(gè)問題，特別是解決為什么及做什么的問題），需求的類型是新增、改進(jìn)，緊急重要程度（判斷排期得重要標(biāo)準(zhǔn)），對(duì)接的產(chǎn)品經(jīng)理，對(duì)接的時(shí)間（收到需求的時(shí)間）

四、需求管理

1. 需求池

需求收集之后進(jìn)入進(jìn)入正式的需求池進(jìn)行管理，可以按照一定的時(shí)間比如每周一次從各方收集需求，并進(jìn)行初步溝通之后，放進(jìn)需求池。并根據(jù)需求本身的變動(dòng)，調(diào)整需求池中的相關(guān)狀態(tài)，標(biāo)注相關(guān)的記錄，批注。

• ID——需求的唯一ID號(hào)，需求身份標(biāo)識(shí)，增加一個(gè)需求ID增加1。
• 端口——需求所涉及的端口，前端如—安卓、iOS、小程序，后臺(tái)—平臺(tái)、供應(yīng)商、商家，這是對(duì)需求做初步劃分，如果涉及到多端，一般記為綜合或拆分成多條子需求對(duì)應(yīng)到各端口。
• 模塊——需求所涉及到的模塊，例如會(huì)員管理、用戶管理、商品管理等。
• 需求名稱——簡(jiǎn)單描述需求是做什么的
• 需求描述——更詳細(xì)描述需求的相關(guān)信息，例如需求提出的背景、需求要達(dá)成什么目的、需求的詳細(xì)說明等。
• 需求來源——記錄需求的來源方，例如產(chǎn)品、市場(chǎng)、運(yùn)營(yíng)。
• 類型——記錄當(dāng)前需求的類型，a、新功能；b、功能優(yōu)化；c、bug修復(fù)。
• 優(yōu)先級(jí)——記錄需求的優(yōu)先級(jí)，a、一般用高中低；b、數(shù)字表達(dá)；c、需求的優(yōu)先級(jí)是動(dòng)態(tài)的，會(huì)隨著戰(zhàn)略、業(yè)務(wù)目標(biāo)的變化而調(diào)整。
• 提出時(shí)間——記錄需求被提出的時(shí)間
• 提出人——提出這個(gè)需求的人及聯(lián)系方式，有助于在需求詳細(xì)設(shè)計(jì)時(shí)追蹤到原始需求。
• 狀態(tài)——需求當(dāng)前的狀態(tài)，根據(jù)不同的階段，可以大致分為：a、記錄——進(jìn)入需求池（初始狀態(tài)）；b、論證——需求開始評(píng)估論證；c、待設(shè)計(jì)——論證完成后有價(jià)值并決定近期開展后續(xù)工作；d、設(shè)計(jì)中——正在進(jìn)行詳細(xì)設(shè)計(jì)；e、設(shè)計(jì)完成——原型及UI已經(jīng)設(shè)計(jì)完成；f、研發(fā)中——已正式安排研發(fā)周期；g、已上線——需求正式上線；h、已關(guān)閉——針對(duì)需求因各種原因提前終止其生命周期；
• 預(yù)計(jì)版本——對(duì)需求計(jì)劃上線的版本進(jìn)行規(guī)劃，產(chǎn)品部門規(guī)劃的實(shí)現(xiàn)版本往往會(huì)超前正在研發(fā)版本
• 實(shí)際完成版本——版本上線后，更新需求實(shí)現(xiàn)的實(shí)際版本號(hào)
• 上線時(shí)間——記錄版本實(shí)際上線的日期
• 備注——各種情況的補(bǔ)充說明，例如需求關(guān)閉的原因，需求優(yōu)先級(jí)變動(dòng)原因，版本規(guī)劃變動(dòng)

2. 需求優(yōu)先級(jí)

需求優(yōu)先級(jí)的分析可以采用KANO模型、四象限法則、權(quán)重加權(quán)三種方式進(jìn)行：

2.1 KANO模型

以分析用戶需求對(duì)用戶滿意的影響為基礎(chǔ)，選擇了兩個(gè)維度：需求實(shí)現(xiàn)度、用戶滿意度。

用這兩個(gè)維度將需求區(qū)分，將需求分為5種，分別是：

• 興奮型需求——也稱魅力型需求：隨著滿足用戶期望程度的增加，用戶滿意度也會(huì)急劇上升，但一旦得到滿足，即使表現(xiàn)并不完善，用戶表現(xiàn)出的滿意狀況則也是非常高的。反之，即使在期望不滿足時(shí)，用戶也不會(huì)因而表現(xiàn)出明顯的不滿意。
• 期望型需求——也稱為意愿型需求：是指顧客的滿意狀況與需求的滿足程度成比例關(guān)系的需求，此類需求得到滿足或表現(xiàn)良好的話，客戶滿意度會(huì)顯著增加，企業(yè)提供的產(chǎn)品和服務(wù)水平超出顧客期望越多，顧客的滿意狀況越好。比如說，支付方式，相對(duì)來說，是越多越好，這樣用戶會(huì)有更多選擇，當(dāng)沒有一種支付或是其中一種沒有資金的時(shí)候還有別的可供選擇，能覆蓋更多的用戶。
• 無差異需求——不論提供與否，對(duì)用戶體驗(yàn)無影響，比如現(xiàn)在各平臺(tái)都有的簽到，打卡功能。
• 基本型需求——也稱為必備型需求、理所當(dāng)然需求：是用戶對(duì)企業(yè)提供的產(chǎn)品或服務(wù)因素的基本要求，比如現(xiàn)在互聯(lián)網(wǎng)基本都有的客服功能。
• 反向需求——又稱逆向型需求：指引起強(qiáng)烈不滿的導(dǎo)致低水平滿意的需求，比如將產(chǎn)品流程設(shè)計(jì)的非常復(fù)雜，引起用戶反感。

針對(duì)不同類型的需求，采取不同的措施。

2.2 四象限法則

四象限法則將需求分為：重要且緊急、重要不緊急、不重要但緊急、不重要也不緊急四類，兩個(gè)選擇維度是：緊急和重要。

• 第一象限——包含一些緊急而重要的需求，這類需求具有時(shí)間的緊迫性和影響的重要性，無法回避也不能拖延，必須首先處理優(yōu)先解決，比如支付功能出問題。
• 第二象限——需求不具有時(shí)間上的緊迫性，但它具有重大的影響，需要ｗｂｓ方法分解任務(wù)、提前進(jìn)行規(guī)劃，按照計(jì)劃逐步制性，比如數(shù)據(jù)埋點(diǎn)統(tǒng)計(jì)分析。
• 第三象限——需求大多是些瑣碎的雜事，沒有時(shí)間的緊迫性，沒有任何的重要性，這種需求的提出本身就存在一定問題，沒有考慮清楚，可能是頭腦發(fā)熱，也可能是看著別人有就想做，與本身產(chǎn)品沒有任何關(guān)聯(lián)性，對(duì)這類需求可以放任不管，比如后臺(tái)標(biāo)題欄的顏色美觀性
• 第四象限——是那些緊急但不重要的需求，這些事情很緊急但并不重要，比如由于商品圖片過大導(dǎo)致的加載慢（可以通過優(yōu)化壓縮上傳圖片解決）等，可以先采用替代方案執(zhí)行

2.3 權(quán)重衡量

對(duì)需求賦予一定的指標(biāo)，進(jìn)行量化分析，如工作量大小、對(duì)用戶價(jià)值大小，對(duì)公司價(jià)值大小、緊迫程度、與核心流程相關(guān)性，可以將各指標(biāo)賦予一定的權(quán)重（所有指標(biāo)項(xiàng)權(quán)重相加為1，各指標(biāo)項(xiàng)確定各自的程度數(shù)值，工作量按天計(jì)算時(shí)間越大，賦值越低）進(jìn)行加權(quán)，得出綜合值大的，則優(yōu)先級(jí)高。

如下圖，需求2的綜合得分為6.8》需求2的綜合得分5.6，先做需求2：

五、迭代規(guī)劃

1. 固定任務(wù)

任務(wù)量固定，時(shí)間上可以進(jìn)行調(diào)整，比如一個(gè)大的版本上線，新開的功能模塊上線，即使采用MVP的方式，也會(huì)超出一般迭代的周期。

這種方式一定是以保證業(yè)務(wù)、功能需求的完整性，系統(tǒng)性為主，不能完全按照時(shí)間來。

否則的話，功能邏輯的完整性和鏈條就會(huì)缺失，上線之后會(huì)帶來極壞的影響，如果功能不完整還不如不上線的好。

2. 固定周期

當(dāng)產(chǎn)品進(jìn)入穩(wěn)定期之后，業(yè)務(wù)也較為穩(wěn)定順暢，則按照固定周期進(jìn)行迭代，比如兩周時(shí)間上新一個(gè)版本，則以時(shí)間為準(zhǔn)，固定時(shí)間端，按照優(yōu)先級(jí)并考慮工作量合理安排需求。

3. 緊急需求

在上一個(gè)版本發(fā)布之后，發(fā)現(xiàn)重大bug，需要緊急修復(fù)上線，這種肯定不能按照常規(guī)方式處理，直接將優(yōu)先級(jí)提高，修復(fù)上線。

4. 插入需求的處理

緊急需求與插入需求有些類似，均是常規(guī)計(jì)劃之外的。兩者又有不同之處，緊急需求是不得不做的，不做將會(huì)帶來嚴(yán)重影響的。

插入式需求是計(jì)劃已經(jīng)排定，但又有新的需求進(jìn)來，比如業(yè)務(wù)部門，上級(jí)領(lǐng)導(dǎo)等。

這個(gè)時(shí)候從幾個(gè)方面進(jìn)行處理：

1. 先不急著拒絕，先分析需求的優(yōu)先級(jí)，如果需求確實(shí)優(yōu)先級(jí)高，看需求規(guī)模，工作量大小，人力資源，是否能不動(dòng)本次版本需求的基礎(chǔ)上進(jìn)行增加。如果可以則直接增加進(jìn)去，如果不行，則將優(yōu)先級(jí)低的需求進(jìn)行刪減。
2. 需求優(yōu)先級(jí)不高，則溝通安排到之后的迭代，并講明原因

六、總結(jié)

本文主要對(duì)需求的層級(jí)、需求來源、需求收集方法、需求管理池、優(yōu)先級(jí)的確定及需求迭代進(jìn)行了分析，產(chǎn)品管理流程及規(guī)范系列文章地址為：

產(chǎn)品管理流程及規(guī)范2——產(chǎn)品規(guī)劃及相關(guān)文檔

產(chǎn)品管理流程及規(guī)范3：產(chǎn)品原型設(shè)計(jì)

產(chǎn)品管理流程及規(guī)范4：PRD文檔撰寫

產(chǎn)品管理流程及規(guī)范5——版本命名、驗(yàn)收規(guī)范、發(fā)版管理

本文由 @markzou 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。