市面上寫產品的書很多，多是大佬的深切體會，對于一個想入門的產品經理來講，其實相對遙遠。本文將根據我的從業經歷，寫下日常產品工作的一般完整的流程是怎樣的。歷經哪些節點，需要做哪些判斷，以此來提高自己，也希望對諸位有所幫助。
一、為什么要做這個需求
不管是B端產品經理，還是C端產品經理，在日常的工作當中，不管接到別人的需求還是自己洞察到需求，都要反問自己為什么要做這個需求？這個需求的價值是什么？
判斷是否要做思考三個層面：
1、邏輯上是否成立？
邏輯上成立指這個需求的背景是什么？目的是什么？業務方或你自己提供的解決方案是否可以達到目的？這個過程是在了解業務的前提下，考驗產品的邏輯判斷能力。需要注意的是一定不要被業務方帶跑，業務同學僅站在自己的角度考慮問題，相對片面。
舉例：我們是向商家提供售賣商品，之前業務向我提過一個需求背景是，當前有很多商家銷售能力不強，每次需要向商家提供補貨支持。在當前運力不足的情況下，會造成很多貨放在前置倉庫無人補貨。希望做一個頁面管理每個點位的運力情況。運營自己判斷哪些點位，可降低補貨頻次。節省運力。
結合這個案例我們可以分析下，是否該做，作為產品，首先要了解當前的安排運力的邏輯是什么？在了解完成后，看是否當前的邏輯可以滿足業務方的訴求。業務方的訴求：總結一句話就是，不賣貨的上架，不該頻繁安排補貨，浪費運力。當前的邏輯實際兼容了這一點。那為啥會出現業務方所說的問題呢。經過溝通最終確定是業務在系統上設置的運營較多，導致此問題。所以解決這個問題核心點在于運營要縮減運力。
另外，假如即使問題不能靠現有系統解決，業務方提供方案是否可行？做運營頁面就要運營打理，牽扯到人工的地方就一定會出錯，一定會有延遲。這個案例也是同樣的問題，且更好的方式是系統。做了反而會對業務有差的影響。因此這個需求就是一個邏輯上并不成立的需求。
2、是否業務真有這個訴求？
在邏輯成立的基礎上在看第二層，是否真的有此訴求？很多情況下，業務方會”想當然“，他不會考慮系統的開發成本，一旦出了問題，就認為做個需求就解決了。但事實上，可能并不存在這個訴求。出了問題查問題，而不是先做需求。
舉例：當前系統的補貨邏輯，兼容了商品售罄和大補貨量。業務方反饋有的商家賣得貨多，補貨不及時，因此應該多設置一檔，優先計算補貨。但從之前的了解，不管售罄還是大補貨量都會優先考慮。因此就需要找出個例去查問題造成的原因，是否補貨系統未考慮此問題造成的。經查明，是此點位不符合其他的標準導致無法計算補貨。
從這個例子我們可以看出：運營提出的是問題，是現象。而造成此現象可能有很多問題。產品經理需要定位出問題所在后，再確定是不是通過做功能的方式解決。因此訴求的目的是解決問題，而不是非要做需求。
3、數據上需證明做的價值有多高？
當前兩點就滿足的情況下，基本可以確定這個需求應不應該做，但做的價值有多大，需要通過數據的方式衡量。這里有幾個注意點：（1）此數據完全是為此需求設立的，因此需要判斷數據口徑是否能相對準確，相對完整的評判這件事。（2）取數后的數據需要抽樣驗證。
拿到數據后就可以判斷需求的優先級了。定優先級需要考慮三方面：1、業務的緊急程度。2、影響的廣泛程度。3、影響的嚴重程度。
二、如何做這個需求？
當上面3點成立時，這個需求就到了產品經理的需求前期調研和撰寫文檔階段。
1、需求調研（B端產品）
很多情況下，產品需要做一些自己并不熟悉的業務需求。在這種情況下，前期調研就十分有必要。首先，產品當前已經明白了要在啥業務，啥系統里做啥功能？但業務與業務直接的關聯，功能與功能直接的邏輯，產品此時就需要了解清楚。需求調研：最主要的調研方式就是問人。
問什么會有助于你做這個需求？這里面需要有幾項準備
1）在問他人前，自己先理清楚本次要做的需求目的，大體的實現方式。
2）數據從哪個表里取?現有邏輯從哪個接口得到？
2）提前準備好問題，兩個通用性問題必問：
·這個需求的背景，目的，實現邏輯是XXX，你幫忙把把關，看是否有啥紕漏？
·目前的總體流程和實現邏輯是怎樣的？
2、PRD文檔撰寫
在撰寫前基本已經知道大體的實現邏輯。因此在本階段的主要目的是：為開發同學提供開發說明。需要闡述清楚，為什么做？數據為多少？如何實現等，提測前的testlist（測試前驗收清單）。在本階段的需求撰寫中，除了將上述判斷的背景，目的，數據支撐填寫填寫外，最主要的是需要將如何實現寫清楚。
撰寫的過程就是細致思考的過程。這里面有兩個方法論：
1、用流程圖梳理清楚大致業務流程、開發實現邏輯流程、用戶交互流程。
2、在根據這個框架仔細思考每個環節，使用方的操作場景（千萬不要跳流程，千萬不要跳）
最終呈現的效果：1、盡可能做到需求點不遺漏。2、盡可能做到文檔開發易于理解。
3、需求評審
這是將本需求與技術，測試、UI同學，表述，溝通，爭辯的主戰場。并最終決定實現功能，實現邏輯，排期等重要事項。
評審前需提前預設開發在評審會上提出的質疑？并提前準備應對答案。這里有個小技巧：在評審前，先和技術負責人簡單過下，讓其幫忙把關，可有效防止在需求評審會上被開發懟。
評審中，需簡潔有力的介紹清楚：
1）一句話描述清楚：背景，目的，目標（根據需求的性質決定是否需要填寫），數據支撐（根據需求的性質決定是否需要填寫）
2）先總體，后細節。先將總體實現此次需求邏輯，在細致講邏輯。在開發過程中，需要注意的點。
在評審中，可能遭遇開發各種問題挑戰，只要上述的準備做得扎實，基本不會出現大問題。但一定會出現你之前預設不到的問題，如非阻斷性問題，若在當場想不出解決方案，承諾會后確認或給出答復，先不要影響評審進度。
在這個過程中需要注意：評審時，開發可能提出更簡單的方案。此時就需權衡與你提到的有何不同，如果損害到用戶體驗，需要衡量開發節省成本和用戶體驗的缺失那個影響更大。一般情況下，站在用戶角度出發，據理力爭，盡可能的做到不妥協。實在拿不定主意的，將此信息告知上級，讓他拍板做決定。
評審結束后，第一時間解決評審中的疑問，在群里告知技術同學。當技術認可后，向技術負責人盡快確定排期：開始開發日期，聯調日期，提測日期，發布日期，灰度日期（產品定），上線日期（產品定）
4、需求開發
在確定排期，真正進入開發階段。
首先，這個過程可能存在意料之外的問題，在開發前需要告知技術同學，如果有了影響用戶體驗的問題，或影響開發進度的問題第一時間告知產品經理。而不是等到提測前告知，或上線前告知。
同時，在開發過程中，產品需清楚，各個開發在本需求中做什么功能，接口如何調用，前端向后端傳什么信息，后端向前端傳什么信息。
最后，產品應該管理開發進度，進度管理最主要方式為營造出緊迫感，關注感。譬如每天晚上詢問開發進度。如進度較慢，詢問遇到的問題，或需要協調的人員，提供開發進度，盡可能保證按排期節奏。
5、驗收前提測
當需求聯調完成后，將進入到測試階段。在測試前，需要在測試環境需要產品經理與測試同學一同驗收。驗收通過后，此需求正式進入到測試階段。
此時的驗收其實與上線前的驗收標準基本一致。驗收原則為：
1）先驗主流程，再驗其他流程。
2）驗收的case提前寫出，盡可能保證驗收的邏輯不遺漏。
6、測試完成上線
上線測試測試的內容基本與測試前驗收一致，需要提前做好上線前準備，準備的原則為：先外部，在內部。先主要，再次要。
1）因為測試環境和線上不同，可能驗收的流程涉及到各個部門。千萬不要等到上線的晚上才開始準備， 此時多數協同部門可能已經下班，麻煩別人得趁早。
2）準備線上的測試用的數據等。
3）驗收過程同提測前驗收。
7、灰度
根據需求的性質，部分需求可能需要灰度（取一部分人員先生效最新功能）。需要在評審會上和測試同學溝通灰度方案，最好在提測前根據灰度方案，確定灰度范圍。在需求待發布前一定需要提供灰度范圍，一般為灰度人員名單或灰度城市范圍。
8、什么時候全量發布
1）產品控制的全量過程
全量發布的時間取決于此次的灰度目的。若灰度目的僅為降低發布風險，功能執行方使用沒有問題后即可全量發布。若此次更新為重大更新，需要觀察執行方使用數據，則全量時間由反饋的數據結果決定。
2）非主觀控制的其他全量
小程序所有用戶可見最新功能，需要微信端審核，一般在發布的2天左右，功能會全量到所用用戶，C端APP受版本限制，需要用戶主動進入APP，才有機會被更新。
9、數據驗證
在灰度階段或全量發布后，積累一定數據量級后，需要評斷本次需求是否達到了預期的效果，因此需要出數據驗證。為這一階段出數順利，需要在需求撰寫階段就確定好數據維度，口徑，統計時間等信息。在開發階段，需要讓開發將相關數據信息存表，或記錄在工單里，方便數據取數。
數據驗證的過程有一個關鍵點：如何客觀的用數據衡量需求效果。這個比較考驗產品的數據思維能力，可以從幾個維度考慮：
1）本次需求的需求目的是什么？根據目的來確定需要衡量目的的數據字段以及每個字段的計算邏輯。思考過程遵循時間順序，樹狀圖結構等等。
2）根據此次需求使用的流程中的數據流（常見的有漏斗型）。根據此數據流來確定字段來衡量需求效果。
在完成上面9個步驟后，一個需求基本就算交付了。當然，在業務方使用過程中，可能出現各種各樣的問題，遇到問題解決問題，就不算開發需求的范疇內了。
最后，珍惜每個需求，在每個需求結束后復盤整個過程，不斷反思總結這9大階段里面的問題點，不斷總結自己做需求的思考方法論，相信你我都會是一個優秀的產品經理，加油。
