產(chǎn)品經(jīng)理作為產(chǎn)品/功能的第一負(fù)責(zé)人，要操盤產(chǎn)品的整個(gè)生命周期維護(hù)，項(xiàng)目中也要擔(dān)任多個(gè)角色。日常產(chǎn)品迭代都要經(jīng)歷哪些過程？本文作者對(duì)迭代過程進(jìn)行了梳理，供大家一起學(xué)習(xí)和參考。

產(chǎn)品迭代流程圖：

一、需求管理

1. 需求獲取

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

1. 自己挖掘的需求；
2. BOSS、合作商、甲方；
3. 團(tuán)隊(duì)成員：產(chǎn)品、運(yùn)營、測試、開發(fā)等；
4. 用戶反饋：App商城用戶評(píng)論、貼吧、百度知道、知乎用戶評(píng)論、產(chǎn)品自帶的用戶反饋、問卷調(diào)查、用戶訪談等。

雖然有的需求本身可能有問題或者是不合理的，作為產(chǎn)品經(jīng)理要以一顆平常心、換位思考、嚴(yán)謹(jǐn)態(tài)度對(duì)待需求方，切忌直接懟回去需求！

遇到需求，無論咋樣，都不要過于激動(dòng)或發(fā)脾氣，收集需求是產(chǎn)品的正常工作，以一顆平常心對(duì)待需求方，以后遇到的需求還會(huì)很多，不值得動(dòng)不動(dòng)就激動(dòng)或者發(fā)脾氣；

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

真心對(duì)待每個(gè)需求方，要對(duì)自己說的話負(fù)責(zé)，如果一時(shí)無法評(píng)估需求是否合理，一定要先自己思考，謹(jǐn)言慎行；如果有不確定性，一定不要立馬回絕或者立馬回復(fù)確定接受這個(gè)需求，避免謹(jǐn)慎評(píng)估后出現(xiàn)與之前結(jié)論不一致的情況。

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

2. 需求管理

從收集到需求，產(chǎn)品就已接入需求的全生命周期管理，需求管理會(huì)貫穿產(chǎn)品經(jīng)理的職業(yè)生涯。有的需求是有價(jià)值確定要實(shí)現(xiàn)的，有的需求因?yàn)闊o價(jià)值或不合理而被pass掉的。

• 對(duì)于有價(jià)值的需求，會(huì)繼續(xù)跟進(jìn)全生命周期管理，包括產(chǎn)品定義、原型/交互設(shè)計(jì)、技術(shù)評(píng)審、研發(fā)、測試、上線；
• 對(duì)于無價(jià)值或者不合理的需求，就會(huì)駁回，需求的生命就此終止。

3. 需求分析

面對(duì)各種需求方提出的形形色色的需求，不是所有需求都要去設(shè)計(jì)開發(fā)的，因?yàn)椴皇撬械男枨蠖际怯袃r(jià)值的需求，產(chǎn)品經(jīng)理要做的就是要判斷需求的真?zhèn)?，這就是產(chǎn)品經(jīng)理要掌握的需求分析的技能。

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

以上需求都可以稱之為“偽需求”，識(shí)別偽需求是個(gè)長期培養(yǎng)的能力，對(duì)于產(chǎn)品新人或者剛?cè)肼毜漠a(chǎn)品，在自己獨(dú)立思考需求后，多與老員工或者熟悉這個(gè)模塊的同事溝通，這是一種很好的學(xué)習(xí)方式，并且會(huì)學(xué)到很多其它知識(shí)。

過濾偽需求后，基本剩下都是有價(jià)值的需求，有價(jià)值就要立馬去做嗎？當(dāng)然不是，開發(fā)資源有限，先做哪些需求后做哪些需求要有明確先后順序，即產(chǎn)品要給需求排優(yōu)先級(jí)，常見的需求優(yōu)先級(jí)確定標(biāo)準(zhǔn)有：

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

需求的收益越高，當(dāng)然優(yōu)先級(jí)就越高；需求的使用人數(shù)/用戶數(shù)量越多，需求的優(yōu)先級(jí)就越高；需求的使用頻率越高，需求的優(yōu)先級(jí)就越高。

4. 競品分析

當(dāng)你確定要做某個(gè)需求時(shí)，不是直接就埋頭開搞了，而是要做競品調(diào)研，需求的解決方案會(huì)有很多種，自己想得不一定是最好的，也不一定是最適合自己產(chǎn)品的。

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

其實(shí)，調(diào)研競品，是為了避免“井底之蛙”的局面。

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

二、產(chǎn)品/功能定義

需求確定要做了，就進(jìn)入了產(chǎn)品設(shè)計(jì)階段，該階段要完成產(chǎn)品/功能的定義，即要完成功能設(shè)計(jì)，輸出的關(guān)鍵產(chǎn)物有業(yè)務(wù)流程圖、原型圖、PRD（產(chǎn)品需求文檔）。

1. 業(yè)務(wù)流程圖

業(yè)務(wù)流程圖是表示業(yè)務(wù)需求在系統(tǒng)各個(gè)模塊間流轉(zhuǎn)的圖形，有用戶、信息的流向，以及有異常情況的處理。

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

2. 原型圖

產(chǎn)品原型圖是將需求轉(zhuǎn)化成產(chǎn)品的一個(gè)過程示意圖，通過原型來表達(dá)需求點(diǎn)和流程邏輯，同時(shí)向UI和技術(shù)去表達(dá)產(chǎn)品的概念和實(shí)現(xiàn)的內(nèi)容。

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

強(qiáng)調(diào)一下，原型圖只是表達(dá)想法的工具，能讓設(shè)計(jì)、開發(fā)易懂就好，不必要做得有多炫酷、多么逼真，炫酷的設(shè)計(jì)成本高，但是投入產(chǎn)出比不一定高。

3. PRD

產(chǎn)品需求文檔是產(chǎn)品經(jīng)理日常工作中最重要的輸出內(nèi)容，PRD的質(zhì)量直接決定了需求質(zhì)量及后續(xù)人員的工作效率。

設(shè)計(jì)、研發(fā)、測試的工作均要以PRD為準(zhǔn)，PRD漏洞百出和書寫不清晰，會(huì)導(dǎo)致需求評(píng)審效率低下，后續(xù)設(shè)計(jì)、研發(fā)、測試會(huì)頻繁和你確認(rèn)細(xì)節(jié)及邏輯，更嚴(yán)重的是因?yàn)楫a(chǎn)品考慮不清楚，導(dǎo)致功能出現(xiàn)故障。所以PRD最重要的是清楚、全面的表達(dá)功能細(xì)節(jié)及邏輯。

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

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

以上四個(gè)模塊，整體由淺入深，一環(huán)套一環(huán)，讓設(shè)計(jì)、研發(fā)、測試輕松讀懂你的PRD。

三、交互/視覺設(shè)計(jì)

產(chǎn)品/功能定義完成后，要將PRD提交給交互設(shè)計(jì)師、視覺設(shè)計(jì)師，由設(shè)計(jì)師完成交互設(shè)計(jì)及視覺設(shè)計(jì)，最終會(huì)將PRD、交互設(shè)計(jì)稿、視覺設(shè)計(jì)稿統(tǒng)一提交給研發(fā)，由研發(fā)完成整個(gè)功能的開發(fā)工作。

交互設(shè)計(jì)師專注于界面的布局以及業(yè)務(wù)邏輯流程設(shè)計(jì)，現(xiàn)在多把a(bǔ)pp動(dòng)效的設(shè)計(jì)也歸于交互設(shè)計(jì)師做，目的是為了更好的了解用戶心理為用戶服務(wù)，讓整個(gè)產(chǎn)品流程體驗(yàn)順暢舒適。

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

四、技術(shù)評(píng)審

在設(shè)計(jì)師完成交互及視覺設(shè)計(jì)后，就到了需求交付給研發(fā)的時(shí)候了，產(chǎn)品要將PRD、交互設(shè)計(jì)稿、視覺設(shè)計(jì)稿統(tǒng)一提交給研發(fā)。

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

評(píng)審?fù)瓿珊螅夹g(shù)負(fù)責(zé)人反饋評(píng)審結(jié)果及大致開發(fā)排期。爭議點(diǎn)較多、問題較大的需求，可能就評(píng)審不通過了；有個(gè)別小毛病的，可能評(píng)審?fù)ㄟ^；完全沒有問題的，當(dāng)然也評(píng)審?fù)ㄟ^。評(píng)審?fù)ㄟ^后，研發(fā)進(jìn)入開發(fā)流程；如果沒有評(píng)審?fù)ㄟ^，產(chǎn)品繼續(xù)完善需求，等待下一次評(píng)審。

針對(duì)需求評(píng)審過程中的疑問點(diǎn)、爭議點(diǎn)以及各方確定的最終方案，產(chǎn)品都要做好記錄，評(píng)審后，產(chǎn)品完成PRD內(nèi)容修改，注意版本的迭代及標(biāo)注。

五、研發(fā)

產(chǎn)品/功能進(jìn)入研發(fā)，產(chǎn)品要做好項(xiàng)目管理、進(jìn)度把控，其中就涉及關(guān)鍵時(shí)間點(diǎn)的把控及跟進(jìn)，要和研發(fā)、測試共同商定開發(fā)時(shí)間、提測時(shí)間、聯(lián)調(diào)時(shí)間、上線時(shí)間，針對(duì)事先確定的時(shí)間安排做好維護(hù)及跟進(jìn)工作，隨時(shí)關(guān)注各方工作進(jìn)度。

如果研發(fā)過程有任何問題及風(fēng)險(xiǎn)，要及時(shí)暴露，評(píng)估是否影響工作進(jìn)展；如果沒有特殊情況，建議不要頻繁變動(dòng)各研發(fā)時(shí)間節(jié)點(diǎn)。

六、測試

1. 測試用例撰寫

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

測試用例是為某個(gè)特殊目標(biāo)而編制的一組測試輸入、執(zhí)行條件以及預(yù)期結(jié)果，用于核實(shí)是否滿足某個(gè)特定軟件需求。

2. 測試用例評(píng)審

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

評(píng)審?fù)瓿珊螅瑴y試人員要完成用例內(nèi)容修改及完善，并周知各位相關(guān)人員。

3. 提測與測試

研發(fā)完成后，由研發(fā)負(fù)責(zé)人申請?zhí)釡y，測試人員介入。按照事先多方已達(dá)成一致的測試用例測試，過程中發(fā)現(xiàn)的問題要及時(shí)跟產(chǎn)品、研發(fā)同步，研發(fā)完成bug修復(fù)，產(chǎn)品要跟進(jìn)bug修復(fù)；修復(fù)完成后，由測試人員繼續(xù)測試，直至沒問題為止。

4. 測試環(huán)境測試報(bào)告

測試人員完成測試后，要輸出測試報(bào)告，并周知各方人員，測試報(bào)告要體現(xiàn)關(guān)鍵結(jié)論、風(fēng)險(xiǎn)點(diǎn)、測試內(nèi)容。測試報(bào)告也會(huì)作為上線申請的關(guān)鍵依據(jù)，即測試通過后，研發(fā)方可申請上線。

七、上線

1. 上線申請

由研發(fā)牽頭提出上線申請，由領(lǐng)導(dǎo)審批后方可執(zhí)行上線，并周知產(chǎn)品、設(shè)計(jì)師、測試等相關(guān)人員。

2. 上線驗(yàn)收

完成上線后，產(chǎn)品、設(shè)計(jì)師、測試均要參與線上測試及驗(yàn)收。若完全沒有問題，則驗(yàn)收通過；若發(fā)現(xiàn)簡單可修改的問題，由研發(fā)修改后執(zhí)行二次發(fā)布；若發(fā)現(xiàn)有重大的業(yè)務(wù)邏輯問題，要各方確認(rèn)后回退版本，即上線失敗，完成優(yōu)化后，申請下次上線。

3. 生產(chǎn)環(huán)境測試報(bào)告

由測試人員牽頭完成，測試報(bào)告中同樣要體現(xiàn)關(guān)鍵結(jié)論、風(fēng)險(xiǎn)點(diǎn)、測試內(nèi)容。測試報(bào)告作為判別上線是否成功的唯一依據(jù)，要及時(shí)周知各方人員。

4. 上線通知

上線成功或者失敗，均要及時(shí)通知需求方及利益相關(guān)方。

八、跟蹤數(shù)據(jù)及優(yōu)化

產(chǎn)品/功能上線后，產(chǎn)品要及時(shí)關(guān)注生產(chǎn)數(shù)據(jù)，并做好數(shù)據(jù)分析工作。以數(shù)據(jù)為依據(jù)評(píng)估產(chǎn)品/功能是否達(dá)到預(yù)期效果，如果沒有達(dá)到預(yù)期效果，產(chǎn)品要牽頭做好復(fù)盤工作，即因?yàn)樯秾?dǎo)致的，輸出完善的舉措和計(jì)劃，并切實(shí)執(zhí)行，避免同類型的問題的出現(xiàn)。

總結(jié)

產(chǎn)品經(jīng)理作為產(chǎn)品全生命周期的操盤者，要跟進(jìn)產(chǎn)品迭代的全流程：需求管理、產(chǎn)品/功能定義、交互/視覺設(shè)計(jì)、技術(shù)評(píng)審、研發(fā)、測試、上線、跟蹤數(shù)據(jù)及優(yōu)化。

產(chǎn)品經(jīng)理在項(xiàng)目中擔(dān)任起需求管理、產(chǎn)品設(shè)計(jì)、項(xiàng)目管理、數(shù)據(jù)分析等多個(gè)角色，遇到問題，要及時(shí)復(fù)盤并完善任何問題環(huán)節(jié)，成為一名合格的產(chǎn)品經(jīng)理。

作者：瑞陽（Rain），個(gè)人微信公眾號(hào)：產(chǎn)品經(jīng)理的那點(diǎn)事兒。電商中后臺(tái)產(chǎn)品經(jīng)理，先后負(fù)責(zé)B端營銷工具產(chǎn)品設(shè)計(jì)、移動(dòng)分銷體系構(gòu)建、派單系統(tǒng)產(chǎn)品設(shè)計(jì)及產(chǎn)品全生命周期管理維護(hù)。

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

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