產品經理作為產品/功能的第一負責人，要操盤產品的整個生命周期維護，項目中也要擔任多個角色。日常產品迭代都要經歷哪些過程？本文作者對迭代過程進行了梳理，供大家一起學習和參考。

產品迭代流程圖：

一、需求管理

1. 需求獲取

需求獲取也稱為需求收集，該過程，產品經理要面對各種角色（需求方）提的形形色色的需求，需求質量也參差不齊，一般來源于以下渠道：

1. 自己挖掘的需求；
2. BOSS、合作商、甲方；
3. 團隊成員：產品、運營、測試、開發等；
4. 用戶反饋：App商城用戶評論、貼吧、百度知道、知乎用戶評論、產品自帶的用戶反饋、問卷調查、用戶訪談等。

雖然有的需求本身可能有問題或者是不合理的，作為產品經理要以一顆平常心、換位思考、嚴謹態度對待需求方，切忌直接懟回去需求！

遇到需求，無論咋樣，都不要過于激動或發脾氣，收集需求是產品的正常工作，以一顆平常心對待需求方，以后遇到的需求還會很多，不值得動不動就激動或者發脾氣；

需求方既然提出了這樣的需求，說明也是在使用中遇到的問題，產品要學會站在對方的角度思考問題，如果是你，你會不會遇到這樣的問題，學會體諒對方，如果是不合理需求，要耐心給需求方講清楚原委，讓對方也理解你，而不是上來就評估需求不合理；

真心對待每個需求方，要對自己說的話負責，如果一時無法評估需求是否合理，一定要先自己思考，謹言慎行；如果有不確定性，一定不要立馬回絕或者立馬回復確定接受這個需求，避免謹慎評估后出現與之前結論不一致的情況。

所以，一般建議接受需求方的需求，自己獨立思考評估后，給出需求方答復，盡量不要簡簡單單思考后就拒絕或答應，避免為后期挖坑。

2. 需求管理

從收集到需求，產品就已接入需求的全生命周期管理，需求管理會貫穿產品經理的職業生涯。有的需求是有價值確定要實現的，有的需求因為無價值或不合理而被pass掉的。

• 對于有價值的需求，會繼續跟進全生命周期管理，包括產品定義、原型/交互設計、技術評審、研發、測試、上線；
• 對于無價值或者不合理的需求，就會駁回，需求的生命就此終止。

3. 需求分析

面對各種需求方提出的形形色色的需求，不是所有需求都要去設計開發的，因為不是所有的需求都是有價值的需求，產品經理要做的就是要判斷需求的真偽，這就是產品經理要掌握的需求分析的技能。

• 要駁回與產品定位相違背的需求；
• 要過濾不合理或者小眾場景的需求；

以上需求都可以稱之為“偽需求”，識別偽需求是個長期培養的能力，對于產品新人或者剛入職的產品，在自己獨立思考需求后，多與老員工或者熟悉這個模塊的同事溝通，這是一種很好的學習方式，并且會學到很多其它知識。

過濾偽需求后，基本剩下都是有價值的需求，有價值就要立馬去做嗎？當然不是，開發資源有限，先做哪些需求后做哪些需求要有明確先后順序，即產品要給需求排優先級，常見的需求優先級確定標準有：

1. 需求帶來的收益；
2. 需求的用戶數量；
3. 需求的使用頻率；

需求的收益越高，當然優先級就越高；需求的使用人數/用戶數量越多，需求的優先級就越高；需求的使用頻率越高，需求的優先級就越高。

4. 競品分析

當你確定要做某個需求時，不是直接就埋頭開搞了，而是要做競品調研，需求的解決方案會有很多種，自己想得不一定是最好的，也不一定是最適合自己產品的。

• 選擇行業內類似3-5款產品；
• 分析針對該痛點，競品是如何解決問題的，可以從用戶群體-使用場景-用戶痛點-解決方法角度思考分析；
• 對比發現競品是如何做的，思考其背后的邏輯，自己的產品能否能借鑒競品的功能，或者有自己獨特的解決方案。

其實，調研競品，是為了避免“井底之蛙”的局面。

• 避免自己一個人埋頭設計出問題，取長補短；
• 提升設計效率，如行業已有很成熟的解決方案，為啥自己還要埋頭苦想呢，可以借鑒呀；
• 培養敏銳的需求分析能力，解決方案切中要害，避免為以后挖坑。

二、產品/功能定義

需求確定要做了，就進入了產品設計階段，該階段要完成產品/功能的定義，即要完成功能設計，輸出的關鍵產物有業務流程圖、原型圖、PRD（產品需求文檔）。

1. 業務流程圖

業務流程圖是表示業務需求在系統各個模塊間流轉的圖形，有用戶、信息的流向，以及有異常情況的處理。

通過業務流程圖能清晰了解功能會涉及哪些模塊、角色，以及詳細的輸入、輸出、任務等。后續將會針對如何畫業務流程圖專門講解，本文將不再贅述。

2. 原型圖

產品原型圖是將需求轉化成產品的一個過程示意圖，通過原型來表達需求點和流程邏輯，同時向UI和技術去表達產品的概念和實現的內容。

產品原型圖常用Axure、墨刀、Skerch繪畫。個人推薦使用Axure，簡單易懂，產品主要通過原型圖表達清楚頁面元素、頁面邏輯，以最簡單的形式表達即可。

強調一下，原型圖只是表達想法的工具，能讓設計、開發易懂就好，不必要做得有多炫酷、多么逼真，炫酷的設計成本高，但是投入產出比不一定高。

3. PRD

產品需求文檔是產品經理日常工作中最重要的輸出內容，PRD的質量直接決定了需求質量及后續人員的工作效率。

設計、研發、測試的工作均要以PRD為準，PRD漏洞百出和書寫不清晰，會導致需求評審效率低下，后續設計、研發、測試會頻繁和你確認細節及邏輯，更嚴重的是因為產品考慮不清楚，導致功能出現故障。所以PRD最重要的是清楚、全面的表達功能細節及邏輯。

PRD整體要遵循“由淺入深，由粗到細”的原則。

1. 要介紹清楚需求背景、需求收益等，讓設計、研發、測試先清楚簡單的背景信息，要讓他們覺得這個需求是有價值的，有做的必要；
2. 要介紹清楚需求目標，即要完成這個需求，需要做哪些關鍵事項，給研發總覽需求涉及的功能模塊/功能點；
3. 業務流程及原型，圖形化展示功能點及邏輯，相比大段文字，圖形化展示更容易讓研發讀懂“要做什么”；
4. 功能詳述，針對業務流程所涉及的各個模塊詳細敘述功能細節，細化到文案字體大小。

以上四個模塊，整體由淺入深，一環套一環，讓設計、研發、測試輕松讀懂你的PRD。

三、交互/視覺設計

產品/功能定義完成后，要將PRD提交給交互設計師、視覺設計師，由設計師完成交互設計及視覺設計，最終會將PRD、交互設計稿、視覺設計稿統一提交給研發，由研發完成整個功能的開發工作。

交互設計師專注于界面的布局以及業務邏輯流程設計，現在多把app動效的設計也歸于交互設計師做，目的是為了更好的了解用戶心理為用戶服務，讓整個產品流程體驗順暢舒適。

視覺設計比較單純，主要會和交互設計合作共同設計界面，用色彩和樣式來滿足用戶的視覺需求和情感需求。

四、技術評審

在設計師完成交互及視覺設計后，就到了需求交付給研發的時候了，產品要將PRD、交互設計稿、視覺設計稿統一提交給研發。

交付之前，要由產品牽頭組織需求評審，邀請設計、研發、測試參與評審，產品給大家演示講解交互、視覺以及詳細的功能介紹，中間任何同事有疑問均可提出，由產品回答，遇到的爭議點由產品、設計、研發、測試一起商量確定最終方案。

評審完成后，技術負責人反饋評審結果及大致開發排期。爭議點較多、問題較大的需求，可能就評審不通過了；有個別小毛病的，可能評審通過；完全沒有問題的，當然也評審通過。評審通過后，研發進入開發流程；如果沒有評審通過，產品繼續完善需求，等待下一次評審。

針對需求評審過程中的疑問點、爭議點以及各方確定的最終方案，產品都要做好記錄，評審后，產品完成PRD內容修改，注意版本的迭代及標注。

五、研發

產品/功能進入研發，產品要做好項目管理、進度把控，其中就涉及關鍵時間點的把控及跟進，要和研發、測試共同商定開發時間、提測時間、聯調時間、上線時間，針對事先確定的時間安排做好維護及跟進工作，隨時關注各方工作進度。

如果研發過程有任何問題及風險，要及時暴露，評估是否影響工作進展；如果沒有特殊情況，建議不要頻繁變動各研發時間節點。

六、測試

1. 測試用例撰寫

研發過程中，測試人員就要根據PRD、交互稿、視覺稿完成測試用例撰寫。

測試用例是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，用于核實是否滿足某個特定軟件需求。

2. 測試用例評審

由測試人員牽頭發起，并邀請產品、設計師、研發參與，測試主導完成用例講解，過程中有任何問題，都可以提出，疑問點由各方共同商討確定最終方案。

評審完成后，測試人員要完成用例內容修改及完善，并周知各位相關人員。

3. 提測與測試

研發完成后，由研發負責人申請提測，測試人員介入。按照事先多方已達成一致的測試用例測試，過程中發現的問題要及時跟產品、研發同步，研發完成bug修復，產品要跟進bug修復；修復完成后，由測試人員繼續測試，直至沒問題為止。

4. 測試環境測試報告

測試人員完成測試后，要輸出測試報告，并周知各方人員，測試報告要體現關鍵結論、風險點、測試內容。測試報告也會作為上線申請的關鍵依據，即測試通過后，研發方可申請上線。

七、上線

1. 上線申請

由研發牽頭提出上線申請，由領導審批后方可執行上線，并周知產品、設計師、測試等相關人員。

2. 上線驗收

完成上線后，產品、設計師、測試均要參與線上測試及驗收。若完全沒有問題，則驗收通過；若發現簡單可修改的問題，由研發修改后執行二次發布；若發現有重大的業務邏輯問題，要各方確認后回退版本，即上線失敗，完成優化后，申請下次上線。

3. 生產環境測試報告

由測試人員牽頭完成，測試報告中同樣要體現關鍵結論、風險點、測試內容。測試報告作為判別上線是否成功的唯一依據，要及時周知各方人員。

4. 上線通知

上線成功或者失敗，均要及時通知需求方及利益相關方。

八、跟蹤數據及優化

產品/功能上線后，產品要及時關注生產數據，并做好數據分析工作。以數據為依據評估產品/功能是否達到預期效果，如果沒有達到預期效果，產品要牽頭做好復盤工作，即因為啥導致的，輸出完善的舉措和計劃，并切實執行，避免同類型的問題的出現。

總結

產品經理作為產品全生命周期的操盤者，要跟進產品迭代的全流程：需求管理、產品/功能定義、交互/視覺設計、技術評審、研發、測試、上線、跟蹤數據及優化。

產品經理在項目中擔任起需求管理、產品設計、項目管理、數據分析等多個角色，遇到問題，要及時復盤并完善任何問題環節，成為一名合格的產品經理。

作者：瑞陽（Rain），個人微信公眾號：產品經理的那點事兒。電商中后臺產品經理，先后負責B端營銷工具產品設計、移動分銷體系構建、派單系統產品設計及產品全生命周期管理維護。

本文由 @瑞陽（Rain）原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議