前言

企業系統紛繁復雜，獨立負責一款這樣的產品，我們需要有一套邏輯章法支撐，一步一步把產品搭建起來。

什么是企業系統產品

什么是企業系統產品？首先在我的認知體系中，將產品的類型進行了如下劃分。

以主體維度劃分——

產品類型可分為“消費級產品”和“企業級產品”，也就是我們常說的“C端產品”和“B端產品”。

消費級產品和企業級產品的區分特征在于，產品的客戶和用戶是否為同一主體。所謂客戶，就是付費的那類人；所謂用戶，就是使用的那類人。

消費級產品，付費的和使用的都是同一類人；而企業級產品，付費的和使用的不是同一類人?；谝陨系年U釋，我們可以給出書面的定義——

消費級產品，是指客戶和用戶為同一主體的產品。

企業級產品，是指客戶和用戶非同一主體的產品。

以需求維度劃分——

產品類型可分為“工具類“、“社交類”、“生活類“、“信息類”、“娛樂類”、“游戲類“六種。

具體的類型定義我就不做冗余闡述了，這些類型還是比較好理解的。

回到文章開頭提到的問題，那什么是企業系統產品呢？

所謂企業系統產品，根據上述的分類，就是指企業級的工具類產品。傳統概念的企業系統包括ERP、CRM、OA等等，這類產品旨在面向各類業務角色解決企業內部管理線上化的問題。在我看來，企業系統的概念不應局限在內部管理上，而應該還要涵蓋外部管理，并且要以核心企業為出發點，所以我認為例如開放平臺這類產品也應該屬于企業系統的范疇。

綜上，我們可以給出企業系統產品的概念，即企業系統產品是企業級的工具類產品，面向各類業務角色，為企業內外部管理線上化提供服務。

0到1的必經步驟

1 評估產品的投入和產出

在建設任何一個產品或功能前，首先都需要考量建設的必要性，企業系統產品更不能例外。對于必要性的考量，無非就是要回答以下幾個問題：

①能帶來什么價值？

這個問題是產品的基石，實際是在思考用戶的本質需求。在這個階段我們很容易犯的錯誤就是把解決方案當成是價值本身。

用個大家爛熟于心的例子，用戶說想要一匹馬，但用戶的本質需求其實是想要提高通勤效率。那么我們在回答這個問題時，就不能淺顯的認為答案是“我可以給用戶提供一匹汗血寶馬”，“提供馬”只是帶來價值的一種解決方案，并不是價值本身。

②價值怎么量化？

一般工具類產品的價值就是降本或增效，那到底能降多少本、能增多少效，是需要給出量化評估的。成本一般可用人力成本、硬件成本來評估，效率一般可用耗時來評估。

這里給出的量化評估，細化后就是后續產品的關鍵指標和目標。

③影響范圍有多大？

影響范圍其實可以歸入到價值量化的問題中，這里單拎出來的原因是因為這一點很多時候會被我們忽略。在企業系統產品中，影響范圍一般可通過角色數、用戶數來進行評估。

同樣的，影響范圍也是后續產品的關鍵指標和目標。

④需要投入多少資源？

作為產品經理，需要具備一定的成本意識。對于產品開發的投入，一般會通過工時（人日）、硬件、外部采購這三個緯度來評估顯性成本。同時，從經濟學的角度看，人力資源、部門預算屬于私用品，有時我們還需要考量其他產品因未能使用到資源而產生的價值損失等這類隱性成本。

TIPS：前三個問題是從“產出”的角度出發，第四個問題是從“投入”的角度出發。正如微觀經濟學的廠商理論中，會分為生產理論和成本理論兩個方向來研究。

2 業務流程與產品架構

當驗證完產品建設的必要性，決定要開發這款產品后，就該進入到業務流程的梳理和產品架構的設計階段。這是產品從0到1建設時獨有的一個必經階段，我們必須嚴肅、認真、敬畏。

業務流程，包括了業務流、狀態流、數據流，涉及錢的系統還會有資金流。產品架構，是指產品中的功能模塊或子系統組合。

對于復雜的企業系統，一般需要先梳理業務流程，再設計產品架構。產品架構會隨著業務流程的梳理而逐步呈現，這是一個很自然而然的過程。

在這個階段，我們會需要借助一些圖工具，包括業務流程圖、狀態圖、數據流程圖、時序圖。

業務流程圖主要描述的是業務需要經歷的主步驟，是狀態圖、數據流程圖的基石。

狀態圖主要描述的是業務步驟中存在的各種狀態，是梳理異常業務流的強有力的工具。

數據流程圖主要描述的是業務系統中會存在哪些數據，這些數據在每個業務步驟中如何流轉、如何存儲、如何關聯。在數據流程圖中，功能模塊已經可以得到體現，產品架構其實已經初見雛形。

時序圖主要描述的是功能模塊間的業務、數據、信息、資金的流轉，是基于數據流程圖對產品架構的最終呈現。

TIPS：注意“這是產品從0到1建設時獨有的一個必經階段”的理解。這個階段雖然在后續產品迭代（從1到100）的建設中不是必須經歷，但是并不意味著就完全不會經歷。一切都在變化之中，產品架構也會跟隨業務變化發生調整。這并不是鼓勵我們可以隨隨便便的在迭代中重啟產品架構設計，架構設計一旦重啟，就意味著業務主流程的缺失或冗余，隨之而來的就是整個系統問題。這個時候，就提頭去見開發哥哥吧。

3 優先級的考量

經濟學家說，社會的資源總是不夠的，人類的欲望總是多樣的。同樣的，完成了產品架構的建立，我們對產品所要具備的功能模塊或子系統已經了然于胸，但開發資源是有限的。這個時候就需要一套機制或一種邏輯支撐我們做抉擇，決定哪些功能要先開發，哪些功能可以后面慢慢迭代。優先級是產品工作中常常掛在嘴邊且永遠繞不開的話題。

優先級本質上是對功能或需求的一種分類維度，而分類標準可以有兩種：用戶價值標準、企業價值標準。

以用戶價值為標準對優先級進行考量，最經典的就是Google的“牙刷理論”。牙刷理論把功能分為三個層次：很多人用、很多人經常用、很多人不僅經常用而且必須用。

以企業價值為標準對優先級進行考量，可以把功能分為三種：生死功能、特性功能、擴展功能。生死功能是指剛性、痛點、決定產品生死的功能，如數據分析產品的準確性；特性功能是指為了契合用戶、提高收入的功能，如數據分析產品的美觀性；擴展功能是指不決定生死、不決定定位、不決定體驗、但又不可缺少的功能。

通過以上兩種標準綜合考量，功能模塊或子系統的優先級基本也可以梳理出來了。

4 概念模型與操作

接下來，我們就要開始進入具體功能模塊的策劃。誒，先別急著畫原型。在這個階段，我們需要思考，如何讓用戶理解系統功能的運作方式，這個過程就是在建立概念模型。

舉個栗子，我們常用的電腦，無論是Windows還是macOS，在對文件進行歸檔時，我們會直接拖動文件到相應的文件夾中。這就是電腦給我們建立的一個概念模型，而且是非常棒的一個模型，基本不用學習，我們就知道要怎么操作文件歸檔并可在需要的時候快速找到這份文件。但實際在電腦的存儲中，這份文件并不是如我們表面看到的那樣存放在了具體某一個位置，而是被分散的存放在了許多不同的儲存區域。文件和文件夾，以及這種拖動存放，是一種方便用戶理解電腦系統在存儲方面如何運作的概念模型。試想，如果電腦系統直白的將它原本的運作方式呈現給我們使用，估計我們很多人要燒腦的學習半天才能掌握，并且每次操作都會十分繁瑣。

看完這個栗子相信大家應該對概念模型這個東西有點感覺了。概念模型幫助我們把復雜的自然現象轉化成可用的、可理解的心理模型，它是組織和理解復雜事物的非常重要的工具。一個好的概念模型，可以化繁為簡，減少用戶的學習成本，這也是概念模型的意義所在。

完成了概念模型的選型和建立，用戶在這個功能模塊中需要執行哪些操作以及操作的步驟都將很自然的呈現出來。正如上述電腦的栗子，確定了“文件和文件夾”概念模型，用戶要執行的操作就是打開某個文件夾、選中某個文件、拖動文件到另外的文件夾。

TIPS：根據復雜度守恒定律（Tesler's Law）， 無論在產品開發環節還是在用戶與產品的交互環節，這一固有的復雜度都無法依照我們的意愿去除，只能設法調整、平衡。所以在建立概念模型時，產品經理不能僅僅關注用戶使用的復雜度，還需要考慮當前概念模型的技術可行性，要多和開發哥哥交流。

5 信息架構與頁面交互

這個階段處理的是用戶體驗要素中“框架層”和“表現層”的事物，相關的理論和方法有很多，我這邊就不贅述了，給大家回顧一下交互十大可用性原則吧。

6 關鍵指標制定

產品的效果必須要有可量化的指標來衡量，而且在產品的不同階段，需要關注的指標也會有所差異。關鍵指標的制定需要遵循以下3個步驟：

①明確產品階段；

②明確每個階段需要關注或突破的問題；

③針對問題制定有效反饋指標。

根據以上步驟，對于企業系統產品，我們可以梳理出以下關鍵指標：

其中，“系統觸達業務”是指使用系統功能完成了某個業務任務，“系統觸達業務數”是指使用系統功能完成了某個業務任務的數量。這個指標主要反映的是，用戶是在使用系統功能來處理業務，還是仍然按照傳統方法在處理業務。

7 發布計劃制定

這個階段要解決的問題，是如何讓用戶更快更好更容易的接受產品新功能。我們可以用一句話來描述：在什么時間點，針對哪些角色，針對哪些用戶，灰度或全量發布什么產品內容，發布后通過哪些方式教育用戶。

總結一下就形成以下的表格：

其中發布策略包括：灰度、全量。教育方式包括：培訓、頁面指引、頁面宣傳等。

8 反饋的收集與分析

在這個階段的指導思路，我們可以采用望、聞、問、切。

望，觀察用戶的操作。

聞，聽用戶的吐槽、抱怨、建議。

問，向用戶提問，注意要區分目的性提問和探索性提問。

切，分析指標數據，注意要對數據進行清洗和修正。

反饋的收集和分析是一門很深且很有意思的學問，我自己也還在研究積累中，后面會為這個階段的詳細方法單獨寫一篇文章。

TIPS：問題的答案不是重點，重點是問題背后的意義。不了解問題背后的意義，即使知道答案，也只是照貓畫虎、東施效顰。

最后想說的

產品搭建的套路是相通的，以上的8個步驟其實也可以應用到其他類型產品的搭建中。

產品搭建的套路又是不通用的，方法的適合度總是因人而異。所以，試著在你目前的產品建設中對以上套路實踐一番，你或許能理解的更到位，同時還能改造優化成更適合你自己的一套方法論。

認知淺薄，歡迎討論。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? copyright ?? 山雞Samson?版權所有