編輯導語：產品管理流程是很複雜的，稍不注意就會出現差錯，然而規範的流程是怎樣的？流程不規範有什麼危害？需要注意些什麼？可能很多人都還不知道，基於此，本文作者總結了那些踩過的坑，為大家詳細的羅列出了規範的產品管理流程，希望看後對你能夠有所幫助。
1. 為何寫這系列文章
1）親身經歷
產品流程混亂無序
開發直接對接業務
隨時插入新的開發功能
交接資料為零
接手的工作未畫流程圖
進入業務之後，發現流程等各種產品文檔缺失嚴重
版本更新內容未記錄
產品記錄資料中間連續斷層
在與眾多產品溝通的時候，發現這是一個很普遍的問題，我基於已經趟過的坑，想聊一下。
2）產品流程管理及文檔不規範有什麼害處
增加了額外的成本及問題，這些成本包括：
新人對項目的上手時間成本；
因資料缺失導致的溝通成本；
研發週期加長導致的進度問題；
無文本信息，問題反覆，理解不一致導致的團隊信任成本；
人員流失導致信息斷層的問題。
特別在業務不斷擴張，人員團隊擴容，任務複雜度增加，管理及文檔的規範化將發揮巨大作用。
2. 怎樣寫這個系列文章
基於這個認知，在我的產品經理職業生涯中，逐步搭建了一套產品流程及規範文檔，進行了實踐，取得了一定的效果：內部認知語言統一、溝通時間更短、各方效率提高、文檔可追溯查詢、人員變動流失影響更小、權責清晰等。
此係列文章將對此套管理流程及規範做分享，主要約定公司產品從立項到產品上線的整個過程，產品經理的做事流程，產品經理需要完成哪些事情，需要產生哪些文檔以及文檔產出的規範。
本系列文章主要涉及方面包括：
產品需求的收集
產品需求管理
產品規劃
產品原型設計
產品需求的輸出文檔
產品驗收
產品版本命名規則
產品發版管理
二、需求層級
1. 戰略性需求
為產品定基調，定方向的需求，比如説，我們要做一個母嬰方向的垂直電商平台。
引起戰略性需求的因素可能有兩大部分：
一部分是由外部因素引起（如新技術趨勢、市場變化、社會交流方式等出現的新機會）；
一部分是內部的技術、資源整合再利用，在原有業務方向之外的拓展（比如華為利用他的技術積累往手機方向發展，滴滴利用在出行上的數據積累做無人駕駛汽車）。
這會延伸出新增及拓展的兩類，新增比如原來做團購，現在增加外賣業務。拓展比如本身做外賣業務，配送團隊由第三方完成，現在外賣訂單量大之後自己做配送，拓展有橫向及縱向擴展，縱向是上下游產業鏈整合，橫向是業務多元化。
此部分參與人員一般是公司最高層，至少是項目的最高層核心人員參與。
這涉及到商業模式的綜合分析，在本文中不做過多擴展，後期將專門寫一些文章專門分析。本文主要還是集中在產品需求收集、管理流程及規範上。
2. 戰術需求
戰術需求比戰略需求低一層級，是對戰略的拆分，也即是通常意義説的產品實現路線的每個階段。
比如説：做本地生活服務平台，前期商家體量小，儘快的實現業務流轉，前期合同可以線下籤訂，可以只做PC端；後期逐步的實現電子合同，手機APP，網頁適配等。
3. 戰役需求
戰役是對戰術的再拆分，也就是每一個階段性的具體實施。
比如：商家合同電子籤如何實現，登錄方式如何處理。當然，這是簡單的區分，實際中短期需求也需要考慮到後期的可擴展性，否則做出來的東西后期改動成本會非常大。
比如説登錄方式，如果不考慮各平台，各渠道賬户打通等，後期的對接，用户數據的集中處理將會面臨很大的問題。
二、需求的來源
1. 內部客户
簡單説就是公司內部決策高層及各部門具體使用人員，對產品在使用中發現的問題，提出的優化改善運營策劃方案。
如運營使用頻率最高，客服部與用户溝通頻率最高，都能發現很多需求及問題。
此部分需求，具體使用部門一般主要集中在對現有產品的優化迭代，在流程的優化、體驗的優化，業務線的深化拓展。
內部客户的需求收集整個流程：
由內部用户填寫需求功能收集表，按照一定的週期提交產品經理，並進行溝通討論，根據商業價值、技術可實現度、優先級、產品路線節奏規劃等考慮點判斷是否要做，及做的安排。短期內不做，或者有其它方法可解決的情況下，與需求提出方溝通其它解決方案（如：在項目的早期，以MVP方式做，則很多分析類的需求，在數據量較小，工作複雜程度較小的時候，是可以通過將相關數據埋點進行導出手動分析，則這個時候做大量的系統數據分析需求及實用性不大）。
如果需求溝通之後確認要做，則將需求放入排期中，並將需求對接清楚，各方通過簽字或其它方式進行確認。
一般來説，如果不是非常緊急的需求及bug修復等，按照一週一次的提交頻率進行是一種較好的方式，因為產品進展到一定的程度之後，大概率也是按照一定的固定頻率進行更新。
這樣一方面給產品經理可以留下其它時間來完成手上的工作，不至於經常打亂節奏，另一方面可以給需求提出方一定的思考完善時間，補足一些明顯的業務邏輯漏洞。
但這個需要前期進行部門之間的溝通，形成一定的機制。
其它部門很容易出現的狀況是，有一個想法就想立即與產品經理進行溝通，這是人的一種本能，有任何問題及疑問，想法就想立即溝通。但產品及業務的工作，是屬於較為複雜的知識性工作，這種工作的方式是要進行大量的決策及權衡，不如一些潛意識的行為方式，直覺的判斷。
要克服這一點，只有各部門之間達成一個溝通機制，做一定的固化。
內部需求收集的整體流程如下：
外部客户的調研，這要看產品是針對的B端用户還是C端用户，B端用户的目標客户羣較為清晰。
B端用户要分決策購買人和使用者，最好的方式是同時滿足兩者的需求。
這兩者有不同點，比如決策者的依據是對企業好（其它目的不進行討論），比如員工行為數據可視化、流程線上化。這樣可以對員工進行監管，同時數據更為實時，後期商業決策更加有依據。
實際在做的時候，需要深入業務中調研，也需要對流程進行優化，不能只是簡單的將原有的流程完全搬到線上，或者簡單的搞高大上的可視化顯示，因為這樣會增加實際操作人員的成本，並未能提高效率，縮減成本。
一般B端業務，深入業務，對相關關係人進行足夠的溝通，則需求將比較明顯能夠提煉出來。
C端的用户，業務縱深一般沒有B端的程度深，但目標用户的明確性，用户的需求會不這麼明顯，需求調研所花費的工作將會更多。
總體來説，B、C都採用線上及線下的方式進行調研。線上調研一般是調研問卷的方式，以及參考行業相關資料，競對資料，線下一般採用拜訪（預設或不預設問題），邀請用户集中溝通，頭腦風暴等方式。
不同的調研方式適用的階段，操作的方式都不一樣，這一方面要多注意。具體的調研方式，大家可以進行網絡搜索查看詳情，後期我也可以針對不同階段，不同類型業務採用何種調研方法寫文章闡述。
以下為外部需求收集的流程：
產品需求收集表：以下為需求收集表的樣式，需要説明需求提出方，需求的名稱，將需求描述清楚（主要解決為什麼做，做什麼，怎麼做這幾個問題，特別是解決為什麼及做什麼的問題），需求的類型是新增、改進，緊急重要程度（判斷排期得重要標準），對接的產品經理，對接的時間（收到需求的時間）
四、需求管理
1. 需求池
需求收集之後進入進入正式的需求池進行管理，可以按照一定的時間比如每週一次從各方收集需求，並進行初步溝通之後，放進需求池。並根據需求本身的變動，調整需求池中的相關狀態，標註相關的記錄，批註。
端口——需求所涉及的端口，前端如—安卓、iOS、小程序，後台—平台、供應商、商家，這是對需求做初步劃分，如果涉及到多端，一般記為綜合或拆分成多條子需求對應到各端口。
模塊——需求所涉及到的模塊，例如會員管理、用户管理、商品管理等。
需求名稱——簡單描述需求是做什麼的
需求描述——更詳細描述需求的相關信息，例如需求提出的背景、需求要達成什麼目的、需求的詳細説明等。
需求來源——記錄需求的來源方，例如產品、市場、運營。
類型——記錄當前需求的類型，a、新功能；b、功能優化；c、bug修復。
優先級——記錄需求的優先級，a、一般用高中低；b、數字表達；c、需求的優先級是動態的，會隨着戰略、業務目標的變化而調整。
提出時間——記錄需求被提出的時間
提出人——提出這個需求的人及聯繫方式，有助於在需求詳細設計時追蹤到原始需求。
狀態——需求當前的狀態，根據不同的階段，可以大致分為：a、記錄——進入需求池（初始狀態）；b、論證——需求開始評估論證；c、待設計——論證完成後有價值並決定近期開展後續工作；d、設計中——正在進行詳細設計；e、設計完成——原型及UI已經設計完成；f、研發中——已正式安排研發週期；g、已上線——需求正式上線；h、已關閉——針對需求因各種原因提前終止其生命週期；
預計版本——對需求計劃上線的版本進行規劃，產品部門規劃的實現版本往往會超前正在研發版本
實際完成版本——版本上線後，更新需求實現的實際版本號
上線時間——記錄版本實際上線的日期
備註——各種情況的補充説明，例如需求關閉的原因，需求優先級變動原因，版本規劃變動
2. 需求優先級
需求優先級的分析可以採用KANO模型、四象限法則、權重加權三種方式進行：
2.1 KANO模型
用這兩個維度將需求區分，將需求分為5種，分別是：
興奮型需求——也稱魅力型需求：隨着滿足用户期望程度的增加，用户滿意度也會急劇上升，但一旦得到滿足，即使表現並不完善，用户表現出的滿意狀況則也是非常高的。反之，即使在期望不滿足時，用户也不會因而表現出明顯的不滿意。
期望型需求——也稱為意願型需求：是指顧客的滿意狀況與需求的滿足程度成比例關係的需求，此類需求得到滿足或表現良好的話，客户滿意度會顯著增加，企業提供的產品和服務水平超出顧客期望越多，顧客的滿意狀況越好。比如説，支付方式，相對來説，是越多越好，這樣用户會有更多選擇，當沒有一種支付或是其中一種沒有資金的時候還有別的可供選擇，能覆蓋更多的用户。
無差異需求——不論提供與否，對用户體驗無影響，比如現在各平台都有的簽到，打卡功能。
基本型需求——也稱為必備型需求、理所當然需求：是用户對企業提供的產品或服務因素的基本要求，比如現在互聯網基本都有的客服功能。
反向需求——又稱逆向型需求：指引起強烈不滿的導致低水平滿意的需求，比如將產品流程設計的非常複雜，引起用户反感。
針對不同類型的需求，採取不同的措施。
2.2 四象限法則
第一象限——包含一些緊急而重要的需求，這類需求具有時間的緊迫性和影響的重要性，無法迴避也不能拖延，必須首先處理優先解決，比如支付功能出問題。
第二象限——需求不具有時間上的緊迫性，但它具有重大的影響，需要ｗｂｓ方法分解任務、提前進行規劃，按照計劃逐步制性，比如數據埋點統計分析。
第三象限——需求大多是些瑣碎的雜事，沒有時間的緊迫性，沒有任何的重要性，這種需求的提出本身就存在一定問題，沒有考慮清楚，可能是頭腦發熱，也可能是看着別人有就想做，與本身產品沒有任何關聯性，對這類需求可以放任不管，比如後台標題欄的顏色美觀性
第四象限——是那些緊急但不重要的需求，這些事情很緊急但並不重要，比如由於商品圖片過大導致的加載慢（可以通過優化壓縮上傳圖片解決）等，可以先採用替代方案執行
2.3 權重衡量
對需求賦予一定的指標，進行量化分析，如工作量大小、對用户價值大小，對公司價值大小、緊迫程度、與核心流程相關性，可以將各指標賦予一定的權重（所有指標項權重相加為1，各指標項確定各自的程度數值，工作量按天計算時間越大，賦值越低）進行加權，得出綜合值大的，則優先級高。
如下圖，需求2的綜合得分為6.8》需求2的綜合得分5.6，先做需求2：
1. 固定任務
任務量固定，時間上可以進行調整，比如一個大的版本上線，新開的功能模塊上線，即使採用MVP的方式，也會超出一般迭代的週期。
這種方式一定是以保證業務、功能需求的完整性，系統性為主，不能完全按照時間來。
否則的話，功能邏輯的完整性和鏈條就會缺失，上線之後會帶來極壞的影響，如果功能不完整還不如不上線的好。
2. 固定週期
當產品進入穩定期之後，業務也較為穩定順暢，則按照固定週期進行迭代，比如兩週時間上新一個版本，則以時間為準，固定時間端，按照優先級並考慮工作量合理安排需求。
3. 緊急需求
在上一個版本發佈之後，發現重大bug，需要緊急修復上線，這種肯定不能按照常規方式處理，直接將優先級提高，修復上線。
4. 插入需求的處理
緊急需求與插入需求有些類似，均是常規計劃之外的。兩者又有不同之處，緊急需求是不得不做的，不做將會帶來嚴重影響的。
插入式需求是計劃已經排定，但又有新的需求進來，比如業務部門，上級領導等。
這個時候從幾個方面進行處理：
先不急着拒絕，先分析需求的優先級，如果需求確實優先級高，看需求規模，工作量大小，人力資源，是否能不動本次版本需求的基礎上進行增加。如果可以則直接增加進去，如果不行，則將優先級低的需求進行刪減。
需求優先級不高，則溝通安排到之後的迭代，並講明原因
六、總結
本文主要對需求的層級、需求來源、需求收集方法、需求管理池、優先級的確定及需求迭代進行了分析，產品管理流程及規範系列文章地址為：
產品管理流程及規範2——產品規劃及相關文檔
產品管理流程及規範3：產品原型設計
產品管理流程及規範4：PRD文檔撰寫
產品管理流程及規範5——版本命名、驗收規範、發版管理
本文由 @markzou 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。