在大部分人的認(rèn)知里，產(chǎn)品經(jīng)理都是與需求、原型和功能打交道的人。這樣理解確實(shí)也沒錯，不過，作者分享的這個案例模版，對產(chǎn)品經(jīng)理來說更能看到自己的價值所在。

本周我去了趟香港換證，剛好和香港網(wǎng)聊許久的一位老讀者，也是某咨詢公司的零售解決方案線的TL進(jìn)行了一次簡短“面基”，在溝通中他們的團(tuán)隊(duì)工作管理方式讓我非常有啟發(fā)，在這分享給大家。

在他們咨詢公司中也有產(chǎn)品經(jīng)理的類似崗位，但是他們對于產(chǎn)品經(jīng)理的工作，定義為三個部分：需求管理，需求制作與需求實(shí)施。

每一項(xiàng)的詳細(xì)流程如下：

01 需求設(shè)計(jì)

【工作01：當(dāng)前問題收集】

動作1：將問題反饋給研發(fā)團(tuán)隊(duì)。例如，用戶反饋當(dāng)前缺少導(dǎo)出報(bào)表某字段功能，產(chǎn)品經(jīng)理需找到研發(fā)同學(xué)解決。

動作2：接收需求，與相關(guān)項(xiàng)目產(chǎn)品經(jīng)理溝通。例如，用戶提出增加某功能，產(chǎn)品經(jīng)理與研發(fā)團(tuán)隊(duì)討論可行性。

示例：某出行APP用戶反饋導(dǎo)航不準(zhǔn)確，產(chǎn)品經(jīng)理與地圖供應(yīng)商溝通，尋求解決方案。

【工作02：需求池管理】    

動作1：將需求內(nèi)容加入需求池。例如，用戶建議優(yōu)化搜索功能，產(chǎn)品經(jīng)理將其加入需求池。

動作2：對需求進(jìn)行排期管理。例如，一個季度的需求排期/月排期等。

這里我仔細(xì)溝通了一下，在他們團(tuán)隊(duì)對于排期的管理是嚴(yán)格按照排期日歷去進(jìn)行的。如劃定了一個月是兩個周一個迭代，那么所有的需求都是按照這兩個周迭代去進(jìn)行排期的，出現(xiàn)了任何問題都是順延，以保證發(fā)版日期不變，例如出現(xiàn)了業(yè)務(wù)需要臨時導(dǎo)出數(shù)據(jù)等這種臨時插入性需求，也是等到最近的一個發(fā)版日期去進(jìn)行解決和處理。

這樣的好處是最大程度上保證了產(chǎn)研的節(jié)奏的穩(wěn)定，這對于平穩(wěn)輸出來說是非常有幫助的。

動作3： 需求制作流程：雙周/三周迭代/月迭代

完整流程：BRD提交時間-需求時間-評審時間-測試時間-UAT時間-上線時間

這里的流程和絕大多數(shù)產(chǎn)品經(jīng)理工作不太一樣的是會要求需求提出方提交一個清晰且明確的BRD，也就是業(yè)務(wù)規(guī)則說明手冊，詳細(xì)的描述這個需求的范疇和范圍。

該文檔的最大的一個作用就是幫助產(chǎn)品經(jīng)理去框定業(yè)務(wù)天馬行空的想法，同時更重要一點(diǎn)是有了這樣的一個文檔在日后上線之后，也可以杜絕業(yè)務(wù)在上線測試的環(huán)節(jié)再漫天要價，臨時加需求等等一系列不合流程的情況。

動作4：項(xiàng)目管理軟件錄入

創(chuàng)建迭代文件，將多個產(chǎn)品文檔放入該文件夾。

示例：某團(tuán)隊(duì)采用meego協(xié)作工具，產(chǎn)品經(jīng)理創(chuàng)建迭代號文件夾，將需求文檔、設(shè)計(jì)稿等放入其中。

動作5：周會同步

每周與團(tuán)隊(duì)同步需求進(jìn)度，確保各環(huán)節(jié)順利進(jìn)行。

示例：某團(tuán)隊(duì)每周一召開需求同步會，產(chǎn)品經(jīng)理匯報(bào)本周需求進(jìn)展，協(xié)調(diào)資源。

【工作03：需求制作】

在需求制作環(huán)節(jié)分為如下的五步。

動作1：BRD評審

通過的BRD納入制作，未通過的BRD不納入需求制作。

動作2：撰寫PRD

在團(tuán)隊(duì)內(nèi)部PRD形成固定模板（如：需求背景/用例圖/UML/原型），方便團(tuán)隊(duì)理解和撰寫。

動作3：PRD自查表

通過將往期需求評審中常見被開發(fā)挑戰(zhàn)的問題如字段聯(lián)動，正逆向流程等問題收集歸納，形成一份標(biāo)準(zhǔn)的自查表用于團(tuán)隊(duì)的產(chǎn)品經(jīng)理去進(jìn)行需求評審前自測回答這些問題，從而提升質(zhì)量內(nèi)部評審。

動作4：正式評審

組織相關(guān)團(tuán)隊(duì)進(jìn)行正式評審。

動作5：復(fù)盤

評審?fù)瓿珊?，產(chǎn)品經(jīng)理組織復(fù)盤記錄修改點(diǎn)和問題點(diǎn)，將共性點(diǎn)加入自查表，提高后續(xù)需求制作質(zhì)量。  

02 需求實(shí)施（絕大多數(shù)產(chǎn)品人未經(jīng)歷的環(huán)節(jié)）

在項(xiàng)目實(shí)施階段，這個團(tuán)隊(duì)中的產(chǎn)品經(jīng)理還需要確保各環(huán)節(jié)順利進(jìn)行，以下為具體流程：

動作1：數(shù)據(jù)遷移

確保新舊系統(tǒng)數(shù)據(jù)無縫對接。例如，在遷移用戶數(shù)據(jù)時，需保證用戶信息、交易記錄等完整性。

示例：某電商平臺進(jìn)行系統(tǒng)升級，產(chǎn)品經(jīng)理協(xié)調(diào)數(shù)據(jù)團(tuán)隊(duì)，提前制定數(shù)據(jù)遷移計(jì)劃，確保用戶在遷移過程中無感知。

動作2：用戶UAT與測試

組織用戶進(jìn)行UAT測試，驗(yàn)證系統(tǒng)是否符合用戶需求。例如，邀請典型用戶進(jìn)行測試，收集反饋。

動作3：數(shù)據(jù)驗(yàn)收

在UAT測試通過后，進(jìn)行數(shù)據(jù)驗(yàn)收，確保遷移后的數(shù)據(jù)準(zhǔn)確無誤。

動作4：遷移過程跟進(jìn)

在用戶遷移過程中，解答用戶疑問，定義相關(guān)流程。例如，制定遷移過程中的應(yīng)急預(yù)案。

動作5：用戶遷移中重點(diǎn)內(nèi)容提前培訓(xùn)

通知用戶當(dāng)前版本可能存在的問題及后續(xù)迭代計(jì)劃，管理用戶預(yù)期。例如主動告知用戶批量功能的錯誤提示還未完成優(yōu)化，將在下個月上線優(yōu)化，提前在產(chǎn)品交付時就將產(chǎn)品可能問題告知用戶，避免后續(xù)用戶反饋時的激烈“吐槽”   。

03 琢磨為什么這么分？

我們回想一下這樣的工作安排與流程，其實(shí)也有它內(nèi)部的道理在里面。

我們都知道在很多公司里面分工其實(shí)是非常細(xì)的，這點(diǎn)尤其在大場中非常常見，但是這種過分的細(xì)分工作也在某種意義上造成了工作的灰色地帶的空白。

最明顯的情況就是大家變成了只為自己的KPI去奮斗，而對整個產(chǎn)品的整體一致性好與壞漠不關(guān)心。

但是這一點(diǎn)對每一個公司產(chǎn)品都是非常致命的。

那么為了避免這種情況的存在，這樣的一種團(tuán)隊(duì)工作流程的安排，其實(shí)也就是要求每一位產(chǎn)品經(jīng)理提供兩個價值：

價值1：管生還要管養(yǎng)

做一個產(chǎn)品就像生一個孩子，很多時候不是產(chǎn)品不好而是業(yè)務(wù)流程沒有改變，那么如何發(fā)現(xiàn)，或者如何幫助業(yè)務(wù)流程去進(jìn)行調(diào)整？

就需要產(chǎn)品經(jīng)理深入介入到產(chǎn)品上線后的實(shí)施運(yùn)營過程中去進(jìn)行產(chǎn)品運(yùn)營，去不斷地修正業(yè)務(wù)的實(shí)際使用情況，去調(diào)整業(yè)務(wù)流程，從而讓業(yè)務(wù)流程與軟件功能相匹配

價值2：產(chǎn)品可持續(xù)迭代力

軟件急著上線，導(dǎo)致為了趕工做各種簡化很常見，但是軟件產(chǎn)品是可以迭代的，我們允許適量的問題存在，但是一定要在后續(xù)的版本中去將問題迭代掉。

那么這就需要產(chǎn)品具備可持續(xù)迭代能力，怎么具備這樣的能力呢？就需要產(chǎn)品經(jīng)理不斷的優(yōu)化需求制作的能力。例如需求自查表，以提升整體的迭代效率。但是這還不夠，還需要業(yè)務(wù)同時去約束自己的。地球提出那這就需要業(yè)務(wù)去提供對應(yīng)的BRD，來管理自己的需求及預(yù)期等。  

而只有這樣在技術(shù)冊與業(yè)務(wù)側(cè)兩者緊密配合，同時去進(jìn)行自我迭代的情況下，這整個產(chǎn)品才會具備可持續(xù)迭代的能力。

最后我想來一個靈魂拷問：在你當(dāng)前的公司內(nèi)產(chǎn)品經(jīng)理有提供這兩個價值嗎？