起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品汪的“野蠻生長”復盤（2）：產品上線前的工作流程
公司往往有不同的工作安排。有些公司流程比較精細化，而像筆者目前這家公司，則偏向以結果為導向，具體內容自行安排。于是有了這篇文章，來總結自己的部分工作流程。
當前公司里，產品經理在產品上線前的工作流程分為五個階段：
- 立項：什么事？
- 需求：做哪些？
- 設計：怎么做？
- 開發：做到哪步了？
- 驗收：做成什么樣？
一、立項
公司流程：由高層發起會議，給各部門負責人講解項目起因、市場情況和商業目標，由各方負責人進行評估和討論。
由于部門原因，筆者往往當天或者前一天才得知會議，對項目本身處于一臉蒙的情況，只能在會議期間整理基本信息。高層之間的信息討論往往較為散亂，因此會按照下圖所示的分類進行逐個整理。
立項會議結束后，領導基本會留下一句“熟悉下項目，或者相關產品”后，直至具體任務下達前，會有一段2天左右的空白期。這段期間筆者會根據之前整理的會議信息進行“桌面研究”——在網上尋找項目相關內容。
桌面研究
在“桌面研究”中，尤其針對2B的產品，往往有以下三個難點：
- 信息量多且雜，全面收集極為困難；搜索渠道是否足夠、信息是否有用以及信息是否準確；
- 信息提煉和整合費時費力：大量的信息堆積起來，需要篩選、提煉和歸納整合；
- 2B的產品很難接觸到，往往需要提交信息進行申請，等待產品所屬公司經過一系列的審核（查看訪問ip、天眼查公司信息以及電話溝通）。即使拿到試用賬號后，里面的功能也都是閹割版。
因此可以嘗試按照以下流程進行：
（1）明確目的
- 將“立項會議信息整理”細化成若干個問題，即可作為目的。例如：項目涉及哪些業務？業務的目前發展情況？業務涉及的企業機構構成如何？
- 類似的項目解決方案有哪些？項目的落地場景是什么？有哪些公司參與進來，怎么推行的？
- 市面上有哪些相關產品？面對的用戶群體是哪些？相關公司重點宣傳了他們產品的哪些功能及解決了哪些業務需求？產品如何收費的？
（2）確定渠道
常用的信息渠道有：
- 研報渠道：艾瑞、易觀、發現報告以及一些垂直行業論壇網站；
- 媒體渠道：常見的媒體新聞網站、搜狗微信搜索（搜索訂閱號的相關文章）；
- 官方渠道：官方網站、微信公眾號；
- 其他來源：百度、谷歌和天眼查（里面的競品信息）等。
（3）信息挖掘
根據自己對項目及業務的熟悉程度，基于上述渠道逐個查詢并記錄相關內容；
（4）篩選整理
對于所挖掘的信息，按照最初的目的進行劃分整理到文檔里。有時間或者精力的話，可以對信息分門別類進行提煉（這步如果沒時間做，會留至競品分析時進行）。
（5）輸出文檔
無論領導有沒有要求，都需要做成簡略的PPT或者pdf報告文檔，給領導查閱。有必要的話，說明自己對項目的理解，這一步的目的在于：
- 所整理的信息內容是否正確；
- 對項目的理解是否和領導保持一致；
- 收集領導的建議和想法。
和領導溝通后，即可適當修改，作為自己進行后續工作的一個參考基準，并進入“需求”環節。
二、需求
公司流程：公司開始安排產品經理和其他同事完成用戶調研、競品分析和搭建需求池。
用戶調研
首先說一下用戶調研，公司產品基本為銀行機構人員服務，因此用戶調研往往以登門拜訪為主。由于各家機構的地理位置不一樣，所以由和客戶打交道較多的市場人員在1-2周內分別拜訪不同的機構。作為產品經理，一方面需要準備完整的調研方案，另一方面要和市場人員溝通，讓他們知道“項目要做什么”以及“調研方案寫的是什么”。
關于調研方案，筆者常用的格式如下：
調研方案評審通過后，立刻召開會議，根據需要講解的內容，結合具體場景給相關同事講解，最后由領導推動調研的完成。而在同事調研的過程中，筆者則需要進行競品分析。關于B端產品的競品分析，難度較大，原因在上述的“桌面分析”里提到。除了“桌面分析”里的渠道外，筆者其他的方法有：
- 自己申請或者利用公司其他資源來獲得相關產品的試用賬號體驗“閹割版”；
- 查找相關的使用手冊或者操作視頻。有些官網就可以找到，有些則需要去公眾號或者論壇等平臺，查看官方號發布的相關文章。
至于競品分析怎么寫，這里不再贅述，網上相關文章很多。需要強調的一點是，競品分析一定是抱著某些問題來分析，并最終得到了有效的解答以支撐后續的產品設計，例如：需求驗證、業務流程梳理、尋找市場方向或者功能交互設計。
需求池
在完成對調研結果和競品的分析后，可分析整理出初步的需求，常見的需求來源如下所示：
需求池可用excel初步整理，筆者格式如下：
優先級：一般用于衡量需求的開發優先程度，常見的方式是用類似kano法等方法來定性分級，也可以基于不同維度來定量分析。這里介紹一下2種定量分析的方法可供參考：
（1）筆者公司產品以用戶需求為導向，在基礎版上會根據不同機構要求進行定制開發，因此需求優先級會根據帶來的收益情況分級，例如影響因素有：客戶需求數、客戶重要性、客戶付費情況以及開發成本。
優先級 = （需求數*重要性*付費情況）/開發成本”
其中需求數為真實數量，重要性通過“客戶分級”量化（關于客戶分級，先埋個坑，日后再填），付費情況根據需求客戶的實際付費情況量化，開發成本用總天數量化。
（2）只從功能本身進行考慮時，影響因素有：符合迭代目標程度、客戶數量、體驗提高、性能優化、開發成本； 根據階段目標賦予每個正面因素不同的權重，例如50%、20%、15%、15%；對單個需求，進行不同因素的評分（1-10）
優先級 = （迭代目標分*50% + 客戶數量分*20% + 性能優化分*15% + 體驗提高分*15%）/開發成本。
- 需求類別：界面、功能以及數據等
- 需求描述：一句話描述需求
- 場景描述：一句話描述需求的來源場景
- 需求來源：見需求來源圖
需求池里一些地方可以留空，等待評審后確認和填寫。
輸出需求池后，即可進行評審，和相關領導同事逐個確認，基于風險、難點和資源等方面討論，完善表格內容，并確定下來。理論上這一步的時候即可封閉需求池（想的很美好，實際上，開發過程中甚至開發結束時都存在甲方臨時改需求的情況），進入下一階段“設計”。
三、設計
公司流程：項目負責人要求產品經理輸出prd文檔及原型圖。
到了這一環節，需要根據需求池，整理產品信息結構和業務流程，輸出原型圖和Prd文檔。
原型圖
筆者常輸出高保真原型圖，因為可以在企業機構演示、給高層領導講解和給內部同事描述上起到試錯的作用，作為早期的可行性驗證，進而優化。如果不進行這一步，很有可能導致最終方案偏離用戶實際需求（關于這點，筆者在某個項目里被坑慘了，埋個坑，之后復盤項目時填上），一旦偏離，后續彌補代價極高。
PRD 文檔
關于PRD文檔，是用于給設計師、工程師及測試對照實現的重要文檔，包括但不限于：
- 修訂歷史：記錄版本變更，便于追溯修改與管理；
- 信息結構圖：用于梳理產品每個模塊的功能架構，使用腦圖完成；
- 業務流程圖：用于梳理每個業務的閉環、輸入及輸出，可用流程圖或者泳道圖完成；
- 功能描述與邏輯：描述功能作用和內在運行邏輯；
- 功能邊界條件：描述功能的各類邊界情況，進行條件約束；
- 數據埋點：描述埋點觸發、事件名稱和ID；
- 功能交互：描述交互邏輯；
- 性能要求：平臺系統的各類功能性能預期。
Prd文檔是整個項目開發過程中的參考文檔，因此需要詳細記錄更迭情況，并且通知到所有人。會進行不斷的更新迭代，需要由產品經理嚴格把控，避免出現多個崗位對需求認知不一致的情況。
四、開發
公司流程：協同UI、開發、測試同事推動項目產品的展開。
在進入開發階段后，產品經理主要負責開發工作的協同與產品的迭代規劃。
工作協同
具體的協同內容有：
- 配合UI完成頁面設計和功能交互，產品經理以輔助評審為主，相信設計師的專業性；
- 解答來自開發同事的各類問題，配合Prd文檔并結合業務場景，讓開發們知道你想要什么；
- 配合測試同事輸出測試用例。
協同期間，會接到來自各個崗位的問題。不要指望各類會議和Prd文檔能夠讓同事們的思維和自己保持一致，因為崗位的不同，對于業務和功能邏輯的理解也會不同，甚至他們會發現一些筆者沒注意的問題。
產品經理需要隨時及時的解答各方疑惑，并跟進各個需求。同時，可以建立一份Q&A表，避免同事們的反復提問。如果該過程中發現任何細節問題，需要及時與各負責人溝通，如果影響到項目的排期更需要告知項目經理。
版本規劃
由于某些產品會保持小版本的快速迭代，因此產品經理需要在上一批優先級高的需求進入開發周期后開始考慮下一個小版本的迭代內容，而需求來源于需求池里沒有劃入本次開發的各類需求。
五、驗收
公司流程：測試人員根據測試用例測試完畢后，由產品經理驗收。
驗收標準即產品正常使用無嚴重的bug問題，各類功能按照需求文檔實現。完成驗收后，產品經理則需要制作產品使用手冊、操作視頻以及宣傳視頻，同時給內部員工進行產品培訓，讓市場和運營同事學習使用產品。
如果對于培訓材料沒有嚴格的要求，可以像筆者一樣，使用手冊用word找模板寫，最后輸出pdf版。視頻先用excel寫視頻腳本，之后用Ae制作，Au錄音，Pr剪輯。
最后對各類資料歸檔，如果是外部項目，把產品和資料交付甲方并進行培訓。如果是內部項目則交付運營市場團隊。
結語
上述的流程會因為公司的不同而有所差異，但最重要的一點“溝通”是不變的：
- 和外部需求方溝通，保證項目的方向和需求方的要求一致；
- 和內部各職能的負責人溝通，保證項目的協調統一，共同推進；
- 和領導層溝通，讓領導知道項目的進度情況、所遇問題和解決情況；
而每個階段的輸出文檔作為溝通的材料，不用拘泥于形式，保證效率和理解即可。也歡迎大佬們指出本文的不足之處，提出自己的見解。
本文由 @jojo_saw 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
終于有一篇實在的了