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

作為一位已經做了10年產品的老司機，C端、B端（包含To G）產品都做過不少。在擁抱產業互聯網的今天，作者想為大家分享一下近幾年做To B產品的一點體會，希望可以對大家的工作帶來幫助。

首先是概述，講述什么是B端產品，分類是如何的，接下來是“策劃相關”，主要涉及產品調研和行業研究、架構設計、功能模塊設計和一些基本功能設計的通用化方案；最后會涉及長期運營和迭代涉及的體會。

一、做B端產品的總體感受

B端產品也叫“2B（Bussiness）”產品，使用對象是組織或企業。B端產品幫助企業或組織通過系統化的數據共享和協同辦公，使線下流程線上化、系統化，解決基于某個業務領域的實際問題，幫用戶提高效率、減少成本，甚至提高收入、控制風險。

我做過的B端產品算一算應該有10+個了，大體上做B端產品的感覺是：

1. 產品難以標準化，多是定制開發

B端產品一般是針對固定的企業或者組織開發的，而在不同的企業和組織里面，大家的角色分配、職責還有流程都不同，所以很難做出通用性很強的產品，就算是WMS（倉庫管理系統），這基本是每一個生產型和銷售型企業都必備的，但卻千變萬化。

2. 不懂業務，不懂技術就別做B端產品

做B端的產品經理，需要既懂業務，又要懂技術，算上騰訊，我已經在3家公司做過B端產品這個崗位，回想起來有一半是業務轉做產品經理，四分之一是開發同學轉做產品經理，而像我這樣科班做產品的也只有四分之一。確實B端產品是專門服務一個領域，如果你對這個領域不深入了解，如何抽象出系統服務這些專業人士？

設計B端產品時，整體架構、用到的相應技術等，產品經理都需要有一定的知識儲備，比如微服務、SOA，這樣才能在設計產品時少走彎路，做出最佳解決方案，也避免了未來因為無法適應業務而造成的重構。

3. 盡可能的抽象流程，做到功能可配置和通用化

作為一位B端產品經理，這是最挑戰你個人能力的地方，基于對業務的理解，把現實的流程和場景變成抽象的系統和模塊，從現實的規律變化轉為抽象的數據流。上面我提到，B端產品很難做到通用，但是如果你能盡可能的做到可配置，一個功能適應和滿足大多數場景，同時如果業務流程調整了，你通過配置，就能馬上適應，會為你節約出很多開發人力，還能快速響應業務。

4. 注重效率，放棄體驗

如果你是從To C產品經理轉成To B產品經理，這一點可能是最難適應的，尤其是我這種以前做C端，又是處女座的產品經理，但是沒辦法，就那么多人力，業務的需求應接不暇，而且每個業務都催你，認為自己的需求都是P0優先級，面對這種情況，你只能在業務目標和用戶體驗之間取一個平凡，換句話說，你不得不為快點上線而犧牲掉用戶體驗。

5. 做B端產品，沒法“抄作業”

B端產品一般都是在公司內部部署和使用的，就算是SAAS化的產品，你想體驗也要花高額代價，這就對新入行就做B端產品的同學挑戰巨大，一方面你要學習行業知識，一方面你連競品長啥樣都不知道，就算看到，也可能和你要做的適合你部門業務的系統差距甚遠；這就需要產品經理在深刻了解業務的情況下，獨立去“創造”一套適合你部門或公司的系統。

二、B端產品的分類

首頁按照用戶群體，可以劃分為3類：

1. 定制化產品：就是俗稱的外包，按客戶要求，幫客戶做一個完全定制化的產品，用戶就是所謂的“甲方”
2. 標準化產品：對外銷售的私有化部署或者SAAS化的產品，用戶是市面上有需求的公司或組織
3. 內部產品：供公司內部使用，不對外銷售的產品，用戶自然就是公司的同事

部署方式分為：

• 私有化部署：就是說軟件服務公司上門安裝，把他們的軟件安裝在客戶公司特定的主機上運行。這種安裝特點是比較安全、網速快；缺點是：軟件維護困難，成本較大。
• 云部署（SaaS化）：指把軟件部署在云服務器，客戶通過公共Web軟件體驗服務。這種安裝特點是方便、簡潔、容易維護、成本較低。缺點是：安全性較低，可能出現網絡堵塞。

技術架構可分為：

• B/S架構：即Browser/Server，瀏覽器/服務器模式，用戶通過自己電腦上的瀏覽器訪問系統體驗服務。目前市面上大部分B端產品都是這種架構方式。
• C/S架構：即Customer/Server，客戶端/服務器模式，這是早期PC軟件經常使用的架構方式，用戶需要安裝客戶端才能體驗服務，客戶端還要經常更新，非常繁瑣。

B端產品按業務方向可分為：

• 業務支撐類產品：支持企業經營管理或核心業務的開支，比如倉配系統和CRM。
• 辦公協同產品：支持企業內部辦公協同，比如OA系統、HRM系統。

三、To B產品經理的工作

我把B端產品工作大致分為3個階段：

• 立項調研及分析
• 實施上線
• 運營反饋迭代

1. 立項調研及分析

我在上文中也提及，按用戶分，把ToB產品分為3類，每一不同類型，實際上在立項調研及分析階段是不同的：

1、定制化產品：因為是甲方直接告訴你要做什么，所以通常行業、市場分析這種都不用做，最關鍵的是要對甲方做足用戶訪談，了解其真正痛點是什么，為什么要做這樣一套系統，給他們帶來什么樣的收益，甲方的要求是什么，驗收標準是是什么；了解清楚這些問題以后，競品分析是不可少的，行業多少會有類似相關產品，可以做一輪研究，看看是否有一些優秀的行業解決方案或者標準（暫不考慮投標等）

2、標準化產品：因為要對外銷售，所以行業分析、市場分析、競品分析、用戶分析和需求分析一個都少不了

3、內部產品：因為主要是公司內部使用，所以用戶分析和需求分析很重要，競品分析也是需要的

行業分析：

• 渠道來源（who）：百度指數、微信指數、艾瑞指數、易觀數據、行業論壇。
• 分析內容（what）：行業背景、行業發展、行業領軍、行業需求、行業產品、解決方案。
• 分析評估（how）：專業易讀、數據可靠、理解透徹。

市場分析：

市場分析四步走方法論：行業背景、前后市場、用戶分析、商業模式。

1. 行業背景：PEST分析、行業技術、行業預測。
2. 前后市場：市場規模、當前市場、未來市場。
3. 用戶分析：用戶需求。
4. 商業模式

競品分析：

• Why：確定競品分析的目的；確定目標，才會明確競品分析的方向。
• What：確定競品；明確哪些可以作為競品，直接競品OR間接競品。
• How：如何分析；善用SWOT分析，善建KANO模型，明確用戶需求與KANO模型之間的關系。

用戶分析：

• 調研目的：明確用戶分析的目的，為下一步工作做好準備。
• 用戶畫像：根據用戶畫像，明確目標用戶；步驟：收集-分析-驗證-優化。
• 用戶問題：對用戶和問題的分析，用戶體驗分析，DAU和轉化率。
• 得出結論：根據調研的報告輸出用戶分析的報告。

需求分析：

• 數據分析方法：多維事件分析、漏斗分析、留存分析、行為序列分析、A/B testing、用戶分群。
• 競品分析方法：上文中已經提過，不再贅述。
• 需求來源：用戶研究、用戶反饋、數據分析、競品分析、公司內部

2. 實施上線

• 整體方案設計
• 細節方案設計
• 功能原型文檔
• 需求評審
• 開發跟進
• 測試

3. 運營反饋迭代

• 產品推廣
• 跟進反饋及問題處理
• 需求管理及迭代
• 數據分析及報告

四、B端產品經理需要了解企業架構

B端產品往往涉及復雜的業務關系和場景，該如何開始著手設計和策劃一款To B產品呢？在埃森哲的時候，接到一個新Case，同事們一般會結合企業架構的方法論來出解決方案，確實，企業架構是一個很好的工具，按照現成的方法論，一步一步熟悉了解項目，最終產出解決方案，這就是我們咨詢顧問的工作。在這里，作為一個To B的產品經理接觸到新項目的時候，同樣適用。

很多同學看到這里，一定會說，我只是個小小產品經理，做個產品，咋都扯到企業架構去了？但產品經理這個詞語最初在寶潔公司誕生的時候，便是要對經營負責，與商業運營緊密相關的。

對于一個成熟的產品經理來說，快速梳理清楚自己負責或將要負責的產品的業務流程是必須能；這樣不但可以幫助你盡快融入，也可以讓你有一個清晰的業務認知，不會在面對復雜設計的產品時不至于手足無措。

并且B端產品屬于復雜系統，不是簡單地畫畫原型搞搞需求分析就能搞定，而是涉及到業務功能復用、數據共享、數據安全、互操作性、技術債等一系列復雜問題。B端產品經理需要培養一種全局觀念，通過企業架構模型將企業組織要素、業務功能要素和技術要素進行構建和鏈接，分離出不同利益相關者的關注點，構建安全的業務實施邊界，構建基于組織能力的交付解決方案。

在企業架構領域，B端產品經理應該扮演好領域專家和產品設計師的角色，和技術架構師、數據專家家一起工作，共同完成業務架構、產品架構、數據架構和技術架構的交付。

1. 什么是企業架構

企業面臨各種內外部變化，要快速響應這些變化，這就必須有一套“企業結構圖”，從企業戰略、業務能力、IT戰略、價值流、組織等不同維度描述企業的業務，以及各維度之間的關聯關系。相當于為物理世界中的企業在數字世界建立模型，從而幫助企業在此基礎上進行變化的影響評估。這就是企業架構。

企業架構（EnterpriseArchitecture），簡稱EA。是指對企業事業信息管理系統中具有體系的、普遍性的問題而提供的通用解決方案，更確切的說，是基于業務導向和驅動的架構來理解、分析、設計、構建、集成、擴展、運行和管理信息系統。

企業架構是一個業務和IT對齊的戰略執行工具，一種設計、管理、溝通的工具。通過企業架構，我們可以達到：

• 組織對企業現狀（as－is）和企業愿景（to-be）有一個整體的的理解和行動方針；
• 確保在持續交付的過程中IT建設和戰略目標對齊。
• 如果沒有一個清晰的架構，就不能保證正確的決策和好的實現，EA是理解和實現企業IT建設的保障

給大家簡單解釋一下，這里企業架構，大家不要認為企業指的就是騰訊，實際可以是你所在的部門，可以是你所屬的這個業務組織，而上面復雜難懂的定義，可以簡單理解為企業架構（業務組織架構）是關于理解所有構成業務團隊的不同元素，以及這些元素怎樣相互關聯的。

好比，人體就是一個組織，包括血液循環系統、消化系統、神經系統等等。頭痛可能是因為呼吸系統感染引起的，也可能是因為神經系統出了問題。在制訂解決方案前，醫生必須要做出全面的評估，才能確認問題出在哪里，避免“頭痛醫頭，腳痛醫腳”，而從醫生問診到最后把病治好，并且還讓你健康保健、延年益壽的全過程就是“企業架構”的方法了。

2. TOGAF架構開發方法

企業架構方法有很多，但TOGAF是最主流的，已經有超過15年的歷史。不僅有80％的福布斯（ Forbes）全球排名前50的公司在使用，而且支持開放、標準的SOA參考架構。

TOGAF 是一個架構框架，簡而言之，是一種協助開發、驗收、運行、使用和維護架構的工具。TOGAF將企業架構抽象為四個層次：

1. 業務架構（Business Architecture）定義了業務策略、治理、組織和關鍵業務過程。
2. 數據架構（Data Architecture）描述了企業的邏輯物理數據資產和數據管理資源的結構。
3. 應用架構（Application Architecture）為要部署的單個應用系統、它們之間的交互和它們與組織的核心業務流程之間的關系提供藍圖。
4. 技術架構（Technology Architecture）描述了需要支持業務、數據和應用服務的部署的邏輯軟硬件能力。

TOGAF架構開發方法（ADM）為開發架構提供經測試的可重復的過程。ADM中的各階段如下：

• 預備階段（Preliminary Phase）描述了準備滿足新企業架構業務指示所必須的準備和啟動活動，包括組織特定的架構（Organization-Specific Architectures）框架的定義和原則的定義。
• 階段A：架構愿景描述架構開發周期的初始階段。它包括關于定義范圍、識別利益相關者、創建架構愿景和獲得批準等信息。
• 階段B: 業務架構（Business Architecture）描述了業務架構的開發，以支持達成共識的架構愿景。
• 階段C：信息系統架構（Information Systems Architectures）描述了架構項目的信息系統架構的開發，包括數據和應用架構的開發。
• 階段D: 技術架構（Technology Architecture）描述了架構項目的技術架構的開發。
• 階段E: 時機和解決方案（OpportunitiesSolutions）為之前階段中定義的架構引導出初始實施規劃和交付載體的識別。
• 階段F: 遷移規劃（Migration Planning）使用一個支持的實施和遷移計劃來處理一套過度架構的詳細次序的制訂。
• 階段G：實現治理（Implementation Governance）提供一個實施的架構勘誤表。
• 階段H: 架構變更管理建立管理新架構變更的過程。
• 需求管理（需求管理）檢查管理架構需求的流程，其貫穿整個ADM。

總的來說，產品說到底是為用戶服務的，To B產品解決的是計劃性的標準化需求。而To B產品的構建，無論從產品邏輯層面，還是從產品規劃層面，都值得我們產品經理花費更多的時間和經理去探討。