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

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

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

每一項的詳細流程如下：

01 需求設計

【工作01：當前問題收集】

動作1：將問題反饋給研發團隊。例如，用戶反饋當前缺少導出報表某字段功能，產品經理需找到研發同學解決。

動作2：接收需求，與相關項目產品經理溝通。例如，用戶提出增加某功能，產品經理與研發團隊討論可行性。

示例：某出行APP用戶反饋導航不準確，產品經理與地圖供應商溝通，尋求解決方案。

【工作02：需求池管理】    

動作1：將需求內容加入需求池。例如，用戶建議優化搜索功能，產品經理將其加入需求池。

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

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

這樣的好處是最大程度上保證了產研的節奏的穩定，這對于平穩輸出來說是非常有幫助的。

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

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

這里的流程和絕大多數產品經理工作不太一樣的是會要求需求提出方提交一個清晰且明確的BRD，也就是業務規則說明手冊，詳細的描述這個需求的范疇和范圍。

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

動作4：項目管理軟件錄入

創建迭代文件，將多個產品文檔放入該文件夾。

示例：某團隊采用meego協作工具，產品經理創建迭代號文件夾，將需求文檔、設計稿等放入其中。

動作5：周會同步

每周與團隊同步需求進度，確保各環節順利進行。

示例：某團隊每周一召開需求同步會，產品經理匯報本周需求進展，協調資源。

【工作03：需求制作】

在需求制作環節分為如下的五步。

動作1：BRD評審

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

動作2：撰寫PRD

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

動作3：PRD自查表

通過將往期需求評審中常見被開發挑戰的問題如字段聯動，正逆向流程等問題收集歸納，形成一份標準的自查表用于團隊的產品經理去進行需求評審前自測回答這些問題，從而提升質量內部評審。

動作4：正式評審

組織相關團隊進行正式評審。

動作5：復盤

評審完成后，產品經理組織復盤記錄修改點和問題點，將共性點加入自查表，提高后續需求制作質量。  

02 需求實施（絕大多數產品人未經歷的環節）

在項目實施階段，這個團隊中的產品經理還需要確保各環節順利進行，以下為具體流程：

動作1：數據遷移

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

示例：某電商平臺進行系統升級，產品經理協調數據團隊，提前制定數據遷移計劃，確保用戶在遷移過程中無感知。

動作2：用戶UAT與測試

組織用戶進行UAT測試，驗證系統是否符合用戶需求。例如，邀請典型用戶進行測試，收集反饋。

動作3：數據驗收

在UAT測試通過后，進行數據驗收，確保遷移后的數據準確無誤。

動作4：遷移過程跟進

在用戶遷移過程中，解答用戶疑問，定義相關流程。例如，制定遷移過程中的應急預案。

動作5：用戶遷移中重點內容提前培訓

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

03 琢磨為什么這么分？

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

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

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

但是這一點對每一個公司產品都是非常致命的。

那么為了避免這種情況的存在，這樣的一種團隊工作流程的安排，其實也就是要求每一位產品經理提供兩個價值：

價值1：管生還要管養

做一個產品就像生一個孩子，很多時候不是產品不好而是業務流程沒有改變，那么如何發現，或者如何幫助業務流程去進行調整？

就需要產品經理深入介入到產品上線后的實施運營過程中去進行產品運營，去不斷地修正業務的實際使用情況，去調整業務流程，從而讓業務流程與軟件功能相匹配

價值2：產品可持續迭代力

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

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

而只有這樣在技術冊與業務側兩者緊密配合，同時去進行自我迭代的情況下，這整個產品才會具備可持續迭代的能力。

最后我想來一個靈魂拷問：在你當前的公司內產品經理有提供這兩個價值嗎？