從最基礎的框架開始，拉一波節奏。

話不多說，先上圖。

---

1. 需求來源部分

不同方向的需求來源略有不同，總體來說，產品經理的需求來源有以下幾個方面：

• 業務需求：由業務方，比如 BD、編審、運營等，直接提出的業務需求；
• 數據挖掘：通過數據挖掘和分析，發現的問題或需求；
• 競對調研：通過分析競對的產品，發現競對比我們有優勢或值得學習借鑒的地方；
• 實地觀察：不論是 B 端產品還是 C 端產品，其實都有大量的機會實地觀察用戶行為。比如直接陪訪城市運營等；
• 戰略需要：俗話說「老大拍的」，這類是由公司 leader 直接安排的需求，通常表示公司未來發展方向或急需解決的關鍵問題；

其他還包括客服、商服反饋的問題，通過在線渠道或用戶訪談獲得的需求，還有微博、朋友圈吐槽等各種 SNS 途徑。不論哪種途徑獲取的需求，產品經理都應該有一個自己的需求池，統一記錄各種想法。

在不同需求來源中，最看重的產品經理自己發現/評估的需求，這是評價產品經理需求決策能力的重要指標。

2. 收集和整理需求

收集和整理需求，就是將需求統一記錄到需求池，方便團隊內/間的傳播。每個團隊建議維護自己的需求池地址。

需求池只是一個備忘，記錄下來的需求不一定都要做，也未必是值得做的需求才記錄下來。

及時維護

3. 立項審批

立項是產品流程中的第一個必要步驟，在這個階段，核心的是要確定項目的價值和目標。

3.1 確定項目的價值

確定項目價值有三個核心要素：角色、場景和目標。也就是，誰在什麼情況下要解決什麼問題（滿足什麼需求）。三個要素必須齊備，才能做出基本的價值判斷。

具備了三個要素，還需要從兩個維度去定義項目的價值。

第一個維度，是當前業務/產品階段。基於不同的業務階段(一般都是萌芽期、成長期、發展期、穩定期、衰退期），產品在戰術和戰略的打法各有不同。比如某共享單車做Growth中的17年紅包大戰，雖縱向來看不利生態循環，但橫向來看利於業務競爭。後面會另起一篇分享「業務型產品經理賦能業務的邏輯與思考」

第二個維度，是影響範圍。拋開計量談毒性，都是耍流氓。前面我們提到了用戶第一個的標準，但是，如果一個需求僅對 1000 個用戶有收益，但對 50000 個商家有收益，那麼優先順序的判斷也是不同的。影響範圍是大家日常工作中非常容易忽略的思考點，往往發現一個 badcase，就拚命想解決，說好聽點叫偏執，說難聽點就是本末倒置。

思考項目價值，推薦用5 Why 分析法，對事情不斷追問，看看一個需求，是否還有成本更低的解決方案，本質收益到底是什麼，到底會影響多少人。

3.2 確定項目目標

價值說的是對什麼有好處，目標說的是有多少好處。

制定目標必須符合 SMART 原則 ，細節看鏈接，我這裡舉個例子。

1. 我的目標是要變成瘦子；
2. 我的目標是要減肥 6 斤；
3. 我的目標是要一個月減肥 6 斤；
4. 我當前體重是 75 公斤，以我的身高計算，合理體重是 72 公斤，我希望在下個月 1 號前減重 2 公斤，3個月內達到標準體重。

上述四種描述目標的方式：

第一種，典型的沒有任何意義的目標，沒有時間點、沒有量化目標；

第二個，有了一個量化目標，但是什麼時候到達，沒有明說。還記得我說過的拋開計量談毒性麼？

第三個，有個一個時間點，但是幾乎不可能完成，即便能完成，也是以犧牲健康為代價。這就是不具備可完成性和與總體目標的相關性；

第四個，相對比較合理。首先說明瞭當前的情況，以及合理的目標值。其次，有明確的時間點和量化指標，還有相對長期的規劃。最後，相比之下，可行性也會更高一些。

3.3 如何進行立項審批？

建議組/團隊有一個立項表，其實核心就是確定價值和目標。表格填寫好以後，可以在**每週一**早上的例會上提出立項的要求，leader確認立項後會將立項**標紅**。

任何口頭承諾都是無效的，只有立項表中的項目被標紅，才說明立項成功。

• 價值描述是否清楚，價值優先順序是否足夠高；
• 項目目標是否 SMART；
• 項目主 R 是否有足夠的時間精力確保項目的質量；
• 項目投入有多大；

立項有三種結果：成功、待定和放棄。需要嚴格把控需求，以確保資源的最大利用化(切記不僅僅是研發資源)。

4. 調研、寫方案和組內評審

立項成功只是第一步，圍繞立項時確定的項目價值和目標，需要進行深入的方案設計工作。

4.1 方案調研

所謂調研，就是收集我們設計方案所需的背景信息和數據。需要遵循以下原則：

• 有明確的調研範圍，不能太窄，也不能無休止的調研；
• 一定要調研第一手資料，不能偏信二手信息。比如綜運反饋運維師傅有需求或者有問題，我們就應該直接調研運維，瞭解商家的真實需求；
• 數據調研需要足夠的樣本量；
• 實地調研。如果是系統功能，就要自己測試；如果是需求，最好直接和需求方進行面談；
• 要輸出調研報告，尤其是調研結論；

4.2 方案編寫

• 這裡不多講，需求文檔最重要/首先是講明白事、拉齊認知。後面會另起一篇分享「需求文檔編寫規範」

4.3 組內評審

評審注意事項：

• 各組 leader 必須參加組內評審；
• 所有需求必須經過組內評審；
• 評審需要輸出評審結果報告，記錄修改點、反饋和是否通過的結論；
• 根據不同需求類型，評審可以酌情邀請業務、RD、UI/UE 和 QA 參加；
• 建議方案出來以後，PM 先和需求方或自己的 leader 進行一對一溝通，對方案要點進行確認；
• 組內評審原則上不應該超過 2 次；
• 如果評審次數過多，需要評估對應 PM 是否具備完成該項目的能力，如不勝任，需要及時換人，確保項目進展和質量；

5. 項目評審

也可以叫做大組評審或正式評審，評審要點如下：

• 大組評審必須邀請 RD、QA 、UI/UE、業務方和關聯方，周知到業務 leader 和各產品 leader；
• 評審形式，以主 R PM 講產品需求文檔為主，講解過程中，盡量不要打斷陳述人，讓陳述人有機會完整表達方案；
• 避免「釣魚評審」，不能出現大家寫需求，PM 記錄的情況；
• 嚴格控制評審時間；
• 評審結果分為：重寫、修改和通過；
• 評審至少提前一天發出會議邀請

6. 技術評審

技術評審的重點是技術評估項目可行性，有以下要點：

• 技術評審也可以由 PM 發起，最好是 PM 發起；
• 技術評審後必須拿到估時；
• 按照功能列表，如果能給出每個具體功能的估時最好；
• 技術評審必須在排期會之前完成；
• 重點項目需要邀請 RD leader 參與；
• 多系統關聯項目，需要邀請關聯方 RD 參與；
• 需要 UI/UE 參加的項目，技術評審前需要完成相關交互設計；
• 原則上，進入技術評審後，需求關閉，不允許進行需求增改；
• 評審至少提前一天發出會議邀請，需帶文檔鏈接，方便相關團隊提前熟悉；

之所以需要按照功能列表進行每個功能點的估時，同時也需要給每個功能點確定優先順序，是因為在後續的排期中會用到。

7. 排期會

所有開發資源都需要排期，一般來說，後端和 FE 因為不依賴版本，可以在一個排期會進行；客戶端由於需要跟版，有自己獨立的排期會。

這裡不多闡述，每個團隊有自己的節奏，關鍵在於「嚴格執行和優化迭代」

8. Task 分解

項目排期成功後，建議 PM 給相關 RD 和 QA 創建 task。要求如下：

• Task框架最好覆蓋「需求開發流程的各節點」；
• 至少一個功能點要分拆一個 task，或一個頁面也需要一個 task；
• 測試任務也需要開 task；
• 中大型項目，或 task 數量超過10個的項目，需要創建 dashboard；
• 一個功能點，如涉及多個 RD，每個都需要創建 task；
• task 必須在開發之前創建；
• 沒有開 task 的功能點或頁面需求，RD 可以不做；
• 及時維護

9. 項目進度跟蹤

項目開始開發後，PM 不能做甩手掌櫃，還需要對項目進度進行跟蹤。一些項目進度管理方面的方法：

• 開發週期較短的項目，PM 需要每天 check task 的完成情況；
• 開發週期較長的項目，項目初期可以每兩天 check 一次 task 完成進度，臨近 deadline 需要每天 check；
• 根據項目要求，可以週期性與 RD 開項目溝通會，瞭解 RD 在項目進度中的問題和困難。比如相關方響應速度、需求理解、資源協調等；
• 重點項目或難度比較大的項目，PM 可以酌情開每日站會。站會可以在早上，5-10分鐘，溝通前日進度或 todo；
• 項目跟進過程中，要非常關注外部依賴，需要明確依賴方和依賴順序，尤其是對外部資源的依賴；
• 優先順序比較高的要求，可以每天匯總項目進度，發送給相關方和需求方；

10. 功能驗收

功能驗收指的是確保項目完成了最基本的功能實現，與 RD 一起確定項目是否達到提測需求。

需要在編寫需求文檔的時候，就確定功能的驗收標準，所以驗收環節就要嚴格按照驗收標準進行驗收。

驗收完成後，可以發出一個正式的驗收結果。但是，需要注意的是，驗收不代表項目達到上線標準，僅表示項目可以提測。

為什麼在提測前 PM 需要驗收？主要還是因為我們的 QA 資源非常緊張，希望 QA 用在更有價值的地方，而不用去操心基本的功能完整性問題。

11. 項目提測

項目開發並進行基本驗收後，由 RD 發提測郵件。

測試之前，其實在項目開發過程中，PM 需要與 QA 一起編寫測試用例。原則上來說，項目提測之後，PM 只需要與 QA 溝通測試進度，瞭解測試中出現的問題。測試中的 bug，需要 PM 和 QA 來判斷是開發 bug 還是產品設計的缺陷。

如果提測過程中有產品設計缺陷，需要分情況討論。

如果是客戶端版本，而產品設計缺陷並沒有很大的影響範圍，不會導致用戶體驗層面的 block 和太大傷害，原則上不在提測後修復產品邏輯的問題。可以將這些問題作為高優先順序的需求列入下次項目。這個判斷需要產品線 leader 來判斷。

如果是服務端需求，不存在嚴格的發版和上線時間，可以評估 bug 的影響範圍和嚴重程度，酌情進行修復。

當然，項目中出現產品邏輯 bug 屬於 PM 的嚴重失職，需要我們避免。

在項目開發過程中，如果有 delay 的風險，需要儘早發項目延期預警郵件，最好面對面周知到KP，如關聯方 RD、PM 和需求方。

測試過程中，最終 PM 還要進行一次產品上線驗收，在 QA 確保項目質量的情況下對功能完整性和可用性進行評估。並正式郵件發出。

12. 預上線與上線

項目開發並測試完成後，PM 需要先發預上線郵件，並在相關渠道進行周知。之所以要發預上線郵件，是因為考慮到項目上線對各方可能帶來的影響，需要各方提前有所準備。原則上，預上線郵件至少提前 1-2 天發出。

項目上線後也需要發正式郵件周知，注意事項如下：

• 原則上，週五和節假日前三天，不能上線。如有特殊需求要上線，需要產品線 leader 和 RD leader 確認；
• 預上線和上線郵件要發送全組，包括業務、運營、PM、RD、UI/UE、QA 等；
• 預上線郵件側重說明項目上線的影響範圍；
• 上線郵件側重說明項目的價值、目標和方案，郵件中需要明確說明上述內容；
• 上線郵件中，不僅應該包含項目的方案說明，還需要酌情考慮增加使用說明、運營計劃、FAQ 等內容；
• 上線郵件中，要說明項目上線後各方需要關注的數據和異常；

13. 項目總結評估

項目總結評估是整個項目中最重要的環節之一，有 PM 主導，主要做以下幾個事情。

第一個，寫項目總結文檔。從以下幾個方面：

• 目標完成統計（數據）
• 目標完成情況的分析，為什麼完成得好，為什麼完成不好
• 方案設計問題復盤
• 項目執行問題復盤
• 開發測試問題復盤
• 產品運營問題復盤
• 後續運營推廣方案
• 下一步產品計劃

第二個，需要基於總結文檔開項目復盤會。是否需要正式復盤會，視項目情況絕對。大中型項目一定需要復盤會，效果突出或不能達到預期目標的項目，也需要專題復盤。

第三個，將上述信息內容，簡要填入項目總結表。

希望以上內容對開卷者有所幫助，歡迎進一步交流哦。

推薦閱讀：

相關文章