本文提到的產(chǎn)品經(jīng)理工作流程，主要來源于本人在日常工作中的總結(jié)凝練，并不適用于所有公司的實際工作流程，僅供各位大佬參考，歡迎大家批評指正哦。

一個中后臺產(chǎn)品項目從最開始接到需求到最后開發(fā)完成上線，這期間產(chǎn)品經(jīng)理到底運籌帷幄了哪些事情？經(jīng)過了哪些流程？一個需求到底是怎么完成的？

本文將對產(chǎn)品經(jīng)理的大致工作流程進行闡述，因為本人做的是中后臺系統(tǒng)方向的產(chǎn)品，所以講述的流程和C端產(chǎn)品經(jīng)理的工作流程多少會有些出入，當(dāng)然我會盡量從更廣的維度上去概述產(chǎn)品經(jīng)理的工作流程，爭取把平常的工作流程都覆蓋到，后續(xù)再寫文章對各個流程做詳細(xì)的介紹。

一、需求收集

所有的產(chǎn)品需求，必定會有一個需求的來源。

常見的需求來源有：

1、業(yè)務(wù)人員提需

業(yè)務(wù)方在使用產(chǎn)品的過程中，會反饋產(chǎn)品的bug、體驗、流程等各方面的問題。

此處的業(yè)務(wù)人員，你可以將其理解為一個泛稱，它可以是客戶、老板、領(lǐng)導(dǎo)等各個使用產(chǎn)品的角色。

2、技術(shù)人員提需

技術(shù)方案的升級迭代，有時也需要產(chǎn)品的同步支持?；蛘呖赡軙屑夹g(shù)上一些解決問題的手段，需要產(chǎn)品化和平臺化，方便各部門員工的使用。

3、產(chǎn)品規(guī)劃

產(chǎn)品規(guī)劃，需要適應(yīng)公司戰(zhàn)略方向，所以當(dāng)戰(zhàn)略方向有所調(diào)整時，產(chǎn)品規(guī)劃可能也要跟著有所變動，這個時候，就會有新的產(chǎn)品需求出現(xiàn)。

二、需求記錄

產(chǎn)品經(jīng)理不可能一下子把所有需求都做完，總要有一個先后順序，所以就會涉及到需求的記錄管理。

一般產(chǎn)品經(jīng)理會將需求放到需求池中，記錄清楚需求的提出人、提出時間、需求描述/需求場景、需求類型、需求進度等信息。

做交互设计10年，我为何转岗到产品经理？

真正转岗之后，我发现很多工作还是超出了自己的想象。产品经理的工作确实比较杂。理论上，产品经理的工作包括了产品的方方面面，从市场研究、用户调研、数据分析...

查看详情 >

產(chǎn)品需求池要秉承一個寬進嚴(yán)出的原則，在需求收集階段時，可以廣泛的收集需求，不用太過于深究需求的合理性，主要就是做好需求的記錄，便于后期追溯和需求分析。

三、需求分析管理

需求分析到底分析個啥呢？主要就是弄清楚需求的真?zhèn)?、價值收益、成本、本質(zhì)、優(yōu)先級等，進而綜合考慮有哪些需求要做、什么時候做、誰來做、投入多少資源等。

四、需求評審立項

所謂評審立項，各個公司的方式更是五花八門，有的公司需要需求發(fā)布，講明需求背景、收益、成本等各個條件，各個有關(guān)部門的老板們覺得ok了，這個需求才能安排開發(fā)人力，正式提上日程；有的公司產(chǎn)品總監(jiān)一個人就能拍板做不做一個需求。

雖然立項的方式有繁有簡，各不相同，但立項這個步驟是不可省略的，這標(biāo)志著一個需求從冷冰冰的需求池中正式提了出來，踏上了即將上線的路程，所以產(chǎn)品經(jīng)理需要重視立項這個步驟。

五、需求調(diào)研

有同學(xué)可能會問了，在需求分析管理階段，不是已經(jīng)分析過需求了嗎，為什么又要有需求調(diào)研這一步，兩者有什么區(qū)別嗎？

需求分析管理，產(chǎn)品經(jīng)理解決的是要不要做一個需求的問題，而需求調(diào)研，解決的是如何做的問題。

特別是b端產(chǎn)品，涉及到較為復(fù)雜的業(yè)務(wù)場景，以及不同用戶角色間的需求差異，所以在做需求時，就需要通過調(diào)研，了解業(yè)務(wù)實際，綜合的考慮需求實現(xiàn)方式，避免需求場景遺漏，或出現(xiàn)顧此失彼，考慮不全的情況。

至于具體的需求調(diào)研方式，常見的有訪談法、問卷調(diào)研、觀察法等，產(chǎn)品經(jīng)理可以根據(jù)自身實際情況，靈活掌握并判斷使用什么方式。

六、競品分析

不管是B端產(chǎn)品還是C端產(chǎn)品，競品分析都是一個做好需求的利器，大到產(chǎn)品架構(gòu)，小到功能交互和文案，都能通過競品分析來獲取靈感。

因為很多東西，你空想的話是很難想出來的，而且還會浪費很多時間，所以要善于使用競品分析，站在巨人的肩膀上。

正所謂天下文章一大抄，就看你會抄不會抄。做競品分析肯定不是讓你原封不動的照搬人家的東西，那樣的話，一是不道德，甚至有法律風(fēng)險，二是可能并不符合需求的實際情況。所以競品分析更多的是提供方向和靈感，就算是抄，也要有差異化，做到“因地制宜”。

七、需求方案設(shè)計

對于新人產(chǎn)品經(jīng)理來說，這一步往往是最讓人期待和激動的，就好像學(xué)了好久的車，終于可以上路行駛了一樣。

不過新手上路，總會碰到一些意想不到的情況，如果沒有什么經(jīng)驗，或者考慮不周，難免會有些磕磕碰碰，出產(chǎn)品的需求方案也是一樣的道理，需要謹(jǐn)慎細(xì)致，考慮全面。

出需求方案，并不是一上來就開始畫原型寫prd，而是還有一些前置工作需要做。

需求調(diào)研清楚后，產(chǎn)品經(jīng)理需要繪制相應(yīng)的用例圖/業(yè)務(wù)流程圖/產(chǎn)品結(jié)構(gòu)圖/系統(tǒng)交互流程圖/狀態(tài)圖等各種需要的圖，不過這些也要看具體需求的復(fù)雜程度，并不是每個需求都要畫一堆圖出來，產(chǎn)品經(jīng)理可以根據(jù)實際情況，判斷是否需要以及需要繪制哪種圖。

一般較為常用的是流程圖和產(chǎn)品結(jié)構(gòu)圖，流程圖幫助產(chǎn)品經(jīng)理在動手畫原型之前，梳理清楚主干、分支和異常流程，避免遺漏關(guān)鍵場景；產(chǎn)品結(jié)構(gòu)圖一般包括了產(chǎn)品信息和功能，基本上產(chǎn)品結(jié)構(gòu)圖畫好后，產(chǎn)品原型圖就能跟著畫出來了。

不要一上來就畫原型的另一個原因，是因為在主要流程還沒有梳理流暢時，原型畫起來會很慢，而且很容易出錯，而錯了改起來又很麻煩，費時費力，還不一定能把邏輯搞清楚。

所以可以先用低成本的流程圖理清邏輯，利用流程圖跟業(yè)務(wù)和技術(shù)去溝通，如果發(fā)現(xiàn)錯誤還能及時修正，避免后續(xù)大反工。

做完前置工作，再畫原型、寫prd就會流暢很多，即使發(fā)現(xiàn)沒有考慮到的地方，也能很輕松的進行修改。

八、需求方案評審

需求方案出來后，如果沒有其他情況的話，接下來的一個大動作就是要需求評審了。

需求評審對于很多產(chǎn)品經(jīng)理，不管是新手老手，都是一座山，被懟互撕那都是常有的事情。所以產(chǎn)品經(jīng)理不僅要平時和研發(fā)同學(xué)搞好人際關(guān)系，而且要盡可能的把需求文檔寫好，在實現(xiàn)需求的同時，也要考慮研發(fā)成本。

評審前

可以把方案發(fā)給關(guān)鍵的業(yè)務(wù)和技術(shù)人員看一看，避免用一個有巨大邏輯漏洞的方案來進行評審，否則那種感覺真的會很難受。

另外，大家都很忙，召開評審之前，一定要確定好參會人員，約好大家的時間，將方案發(fā)到群里，給大家預(yù)留看文檔的時間。

評審中

對于各方提出的問題，要及時做好記錄，如果有會議錄制條件的，最好進行錄制，一是如果會后有遺忘的點，可以回溯查看，二是留下評審的證據(jù)，如果后續(xù)有甩不清的鍋，可以看看評審記錄到底當(dāng)時是咋說的。

另外，評審結(jié)束時，記得讓開發(fā)給排期，有時較為復(fù)雜的需求，技術(shù)可能還會有一個技術(shù)評審才能出排期（如果涉及到ui介入的，還要有ui設(shè)計的排期），總之，要及時跟進要排期，防止需求開發(fā)被一拖再拖。

評審后

需要將評審中提到的需要改動的點，或者是一些待辦事項總結(jié)好發(fā)給各參會方，如果有群的話也可以發(fā)到群里，并艾特全體成員。有針對某個人的待辦，也可以再單獨私發(fā)一次，防止對方遺忘。

九、跟進開發(fā)進度

ui、前后端、測試的排期給出后，接下來一段時間，產(chǎn)品經(jīng)理的主要工作就是跟進開發(fā)進度了。

跟進開發(fā)進度，除了單純的過問開發(fā)進度，保證開發(fā)按計劃進行之外，還要積極配合前后端的開發(fā)。

因為有些問題在評審中可能并不會暴露出來，對于前后端在開發(fā)中拋出的問題，產(chǎn)品經(jīng)理要及時處理，做出決策，畢竟在沒有項目經(jīng)理的情況下，產(chǎn)品經(jīng)理一般是會作為需求的主owner的，一定要對得起崗位名稱中“經(jīng)理”這兩個字，做一個負(fù)責(zé)任的產(chǎn)品經(jīng)理。

在開發(fā)過程中，原則上是不做大的需求改動的，如果有需要改動比較大的情況，只要不是本期必須要實現(xiàn)的功能，也不是碰到技術(shù)不能實現(xiàn)的功能點，都可以考慮放到下一期需求迭代中，確保當(dāng)期需求順利開發(fā)完成，避免拖泥帶水。

十、走查測試

需求開發(fā)完并聯(lián)調(diào)后，前后端一般會給出一個走查環(huán)境（也可以叫測試環(huán)境），產(chǎn)品經(jīng)理需要根據(jù)需求文檔進行走查測試，排查問題，由開發(fā)人員及時解決。

走查時也要注意，一定要細(xì)致全面，如果在走查過程中有什么新想法，或者發(fā)現(xiàn)哪里由遺漏（prd中沒寫，但是卻需要的），小改動可以跟開發(fā)人員協(xié)商直接在當(dāng)期做了，如果是大改動的話，只要當(dāng)期需求能跑的通，盡量把改動點放到下一期進行迭代。要是因為產(chǎn)品經(jīng)理執(zhí)意加需求導(dǎo)致需求開發(fā)延期，那么這鍋是絕對摘不掉的，一定要注意。

測試工程師介入測試，可以和產(chǎn)品經(jīng)理走查并行，也可以在走查之后進行，具體什么時候開始測試，可以看公司的工作習(xí)慣和需求的難易程度，一些太小太簡單的需求，可能不需要測試工程師的介入，走查沒問題即可上線。

十一、上線驗收

終于迎來了這關(guān)鍵的時刻了，激動人心啊。

但是也不要高興的太早哦，產(chǎn)品上線后，產(chǎn)品經(jīng)理也要進行線上驗收，如果涉及到灰度發(fā)布，后續(xù)還要看什么時候全量發(fā)布上線。

為什么上線前也走查了，也測試了，上線后還要再檢查一遍呢？因為產(chǎn)品上線并不是像打開一個開關(guān)一樣，點擊一下上線就上線了，在上線過程中，有可能會出現(xiàn)各種各樣的問題，這都會影響產(chǎn)品實際到線上的效果，產(chǎn)品經(jīng)理要和前后端開發(fā)人員一起，防范并處理產(chǎn)品上線后可能出現(xiàn)的風(fēng)險。

十二、撰寫操作手冊

產(chǎn)品終于成功上線了，對于中后臺產(chǎn)品，或者是B端產(chǎn)品來說，較為復(fù)雜的需求上線后，需要撰寫操作手冊，并組織相關(guān)培訓(xùn)，方便業(yè)務(wù)人員的使用。

十三、數(shù)據(jù)分析

產(chǎn)品上線后，到底能不能被用戶認(rèn)可，就要通過相應(yīng)的數(shù)據(jù)分析來體現(xiàn)了，如果產(chǎn)品上線后，壓根就沒什么人用，那么很有可能這個需求就是個偽需求，或者是缺乏相應(yīng)的運營手段支撐。