中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：目前，關于C端產品經理的文章不在少數，相比之下，對于B端產品經理的工作流程、整體方法論的討論占了少數，并且缺少從整體上進行概括的文章。本文作者作為B端產品經理，通過結合自己的工作實踐與認知，對于B端產品經理的工作流程進行了一次復盤分享。

一轉眼，我已經從事B端產品經理近兩年時間了，一直沒沉下心對自己的工作內容和所學所想進行系統總結。恰好最近身邊有不少朋友和同學想要轉行產品經理。

寫下這篇文章算是對朋友關于B端產品經理的一個簡要介紹，也作為自己兩年來的工作復盤。下文我將B端產品經理工作流程拆解，從各環節的工作內容概述、注意事項和主要產出三個方面進行介紹。

一、流程拆解

圖1、B端產品經理主要工作流程

1. 需求獲取

1）概述

產品經理以深度訪談、問卷調查、輪崗實習等方式獲取需求方的需求，其中深度訪談這個方式最為常用。

需求獲取是一個由粗略到細致的過程，從概括性的項目背景說明、價值分析，深入到目標用戶確認、業務現狀、業務問題和期望效果的梳理。視項目實際情況，可能需要和基層執行者、中層業務負責人和高層領導分別進行溝通。

2）注意事項

溝通時避免使用封閉式提問（即提問者提出的問題帶有預設的答案，回答者的回答不需要展開），封閉式提問容易忽略問題本質，停留在問題表象。

3）產出

訪談記錄、調查報告、實習總結。

2. 需求分析

1）概述

產品經理針對獲取的原始需求進行偽需求的過濾，梳理得到真實需求并匯總進項目需求池，進行優先級判斷和迭代規劃等管理。

其中優先級主要從重要/緊急程度兩個維度進行判斷；迭代規劃則是權衡工期要求和開發資源，在當期版本中刪減優先級低的需求，在后續版本中再開發。

根據確認下來的當期需求，進行業務流程、功能架構、工作流狀態定義的梳理工作——即進行框架層的需求設計，也是進行詳細需求設計前的必要步驟。

2）注意事項

需求方嘴上說的和他真實想要的很可能是兩回事?！队行枨蠓治觥分锌偨Y了這一現象：需求方往往提出“方案級需求”，需求分析則是要還原出“問題級需求”——其實就是過濾“偽需求”，得到“真實需求”的過程。

梳理出真實需求后，根據實際項目要求和資源限制，可能還需要從技術、業務、成本和收益、風險和策略等方面進行可行性分析。

3）產出

項目需求池、需求概要設計（包含業務流程圖、功能架構圖和工作流狀態定義等）。

圖2、項目需求池

圖3、業務流程圖

圖4、功能架構圖

3. 需求review

1）概述

產品經理依據需求概要設計（業務流程圖+功能架構圖+工作流狀態定義）向需求方再次確認需求內容并闡述對應的解決方案。

這個過程主要是用于確保產品經理對需求理解的正確、完備，在進行詳細需求設計前及時糾錯，同時也盡可能的避免后續環節中的需求變更。

2）注意事項

很多PM會忽略需求review這一部分的工作，或許是抱著“我在需求獲取階段已經進行了充分溝通，并基于溝通結果開展需求分析，那么需求設計就是沒有問題的”這種想法，然而最終上線的產品不能滿足需求。

主要原因就是信息在表述、理解過程中的失真，需求review則是盡可能避免信息失真。初中級PM受限于產品能力，或者需求復雜度高，需要輸出系統級解決方案，那么“再確認”的步驟是必不可少的。

3）產出

修正后的業務流程圖、功能架構圖和工作流狀態定義等需求概要設計內容。

4. 需求設計-詳細

1）概述

依據確認無誤的功能架構圖、業務流程圖等內容，產品經理進行需求文檔的編寫。需求文檔中需要說明頁面內容、交互、字段釋義和數據邏輯等產品細節。相較于內容詳實全面的PRD，我個人推薦“原型+文字/表格注釋”的形式進行需求文檔的輸出。

PRD詳實全面，也意味著又臭又長，項目組同事基本不喜歡看；在“讓人快速準確理解需求內容”這方面的確不如“原型+備注”的形式。我個人理解PRD目前最大的作用在于項目歸檔、追溯和交接，而非需求內容傳達。

2）注意事項

需求文檔作為產品經理的主要輸出物，是一個衡量其基礎能力是否牢靠的重要指標。

需求文檔的目的，是為了讓項目組成員就需求的理解達成一致，并能明確指導UI、前端、后端、測試等同事各自開展下一步工作。達成了以上目的，那么這已經是一份良好的需求文檔。

此外，需求文檔具備“規范的內容格式”也同樣重要。內容格式的標準化不僅能讓產品經理在一個清晰的框架下編寫文檔，文檔更具條理性，內容更完整詳實，而且有助于知識傳承和統一管理。對個人和團隊都十分重要。

3）產出

需求文檔：

圖5、“原型+備注”形式的需求文檔

5. 需求評審

1）概述

產品經理組織項目組成員參與并依據需求文檔進行需求宣講，讓產品、UI、前端、后端、測試等同事對需求的理解達成一致。

這個環節也是產品經理經歷各方“拷問”的重要環節，尤其是技術同事經常會在產品設計上深究，因為這往往決定后續的技術選型并左右開發難度。

2）注意事項

需求宣講需要注意語言表達的邏輯和條理，應當從“項目背景&目的、業務場景”擴展到“業務流程、功能架構”，最后再詳細展開“具體頁面和功能”——即結構性思維的應用。

人無完人，哪怕是高級產品經理也不是每個項目都能考慮到所有細節。但這并不是產品經理在進行需求設計時“大而概之”的借口，相反，產品經理需要在設計時進行深度思考，盡可能考慮到所有細節。最好能做到面對大家的疑問，都能有理有據的應答。

3）產出

依據評審結果修訂的需求文檔。

6. 項目排期&項目管理

1）概述

將整個項目從“需求對接”開始，到“項目上線”為止，各個階段的負責人以及人日消耗以表格形式羅列。目的是讓項目組同事明確各個關鍵項目節點，產品經理（或者專門的項目經理）以此為依據進行項目管理。

2）注意事項

項目管理需要定時關注各環節實際進度與預期進度的差異，及時反饋風險、協調資源。如果覺得線下管理、溝通效率低，可以采用TAPD和Teambition等協同辦公軟件。

這類軟件一般都有甘特圖和看板等管理工具，使用起來還是比較方便。

3）產出

項目排期表。

圖7、項目排期表

7. 產品審查

1）概述產

品上線之前，產品經理需要對UI和功能進行審查。

一般來說具體的界面測試、數據準確性測試和兼容性測試等會由專業的測試同事負責。產品經理只需要驗證產品主流程通暢即可。實際執行也很簡單，依據之前梳理的業務流程，發散出各個業務角色的用例，進行流程驗證即可。

2）產出

產品審查報告：

圖8、產品審查報告

8. 系統運營宣導

1）概述

一個業務系統初次上線或者版本更新，需要針對系統各角色開展相應培訓。

一般而言，企業自建自用的B端產品不會分配相應的運營人員，往往是產品經理一并負責系統的運營，需要輸出針對各個業務角色的“系統操作手冊”，并視情況召開宣導會進行業務流程和角色操作的演示。

如果該產品有向外部推廣的意愿，產品經理也會負責產品白皮書之類的編寫。

2）產出

系統操作手冊、產品白皮書。

圖9、系統操作手冊

9. 運營數據分析&迭代規劃

1）概述

產品上線后，產品經理和運營同事通過分析用戶行為數據得出產品的優化方向。常見的B端產品評價指標如下：功能完善性、系統可靠性、時效性、易用性、兼容性、數據準確性、界面排版合理、響應速度等。

一般采用問卷和訪談的形式進行收集，根據收集的數據，可分析出用戶在當前版本的痛點，結合在“需求分析”階段擬定的“迭代規劃”，共同構成最終的迭代計劃。

2）注意事項

常見的埋點事件（點擊、曝光、停留時長）對（除SaaS外的）B端產品并沒有多大的參考意義。

因為B端產品與C端產品有一個根本差異——不直接產生收益，往往是通過間接的“降本增效”來為企業助力。這些常規的埋點事件和與之對應的分析模型很難量化B端產品的效益。故采用上述評價指標進行B端產品的運營數據分析并得出迭代規劃。

3）產出

運營數據分析報告、產品迭代規劃。

二、總結

以上，我們完成了B端產品全流程的穿越。

可以看到B端產品經理除了“溝通能力、文檔整理輸出能力和項目管理能力”等通用能力外，還需要優秀的業務理解能力和方案設計能力。所以，“登山”的過程中要著重培養自己快速準確抽象業務流程，提煉通用解決方案的能力。

B端產品經理在職業生涯中會慢慢發現，業務癥結梳理到最后往往是流程問題，甚至是公司制度問題；僅僅是將線下流程線上化對解決業務癥結的作用很可能微乎其微。

總之，產品經理是一個需要不斷學習的崗位，共勉。

本文由 @伊甸東 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。