編輯導讀：現(xiàn)在很多B端產(chǎn)品招聘要求有從0到1的建設經(jīng)歷，但是當我們有機會主導一款全新的產(chǎn)品時，應該如何從容地完成從0到1的過程呢？本文作者正好從0到1主導設計過一款CRM銷售過程管理產(chǎn)品，希望通過項目復盤給到大家一些幫助。

一、項目背景

公司介紹：一家互聯(lián)網(wǎng)房產(chǎn)平臺公司，主要的客戶群體是房產(chǎn)中介。

銷售模式：地推模式，需要每天到各個中介門店拜訪溝通。

業(yè)務背景：隨著房產(chǎn)市場降溫和競對公司發(fā)展，公司業(yè)績急速下滑。?為了提升銷售業(yè)績，所以公司老板要求一方面加大產(chǎn)品創(chuàng)新投入，另一方面強抓銷售過程管理。

業(yè)務現(xiàn)狀：目前對于整個銷售過程管理沒有線上化，全部依賴于銷售每日線下反饋的拜訪日報，所以存在大量虛報拜訪的情況。

二、項目過程回顧

這種從0到1的項目，大多工期很緊。幸好筆者之前整理了一套產(chǎn)品過程管理的模板，快速梳理了產(chǎn)品的工作任務及粗略的時間計劃。這個模板能適用各類從0到1 或者重構項目，建議大家收藏。

下面的內(nèi)容就是項目過程的具體回顧。?

三、項目啟動

1. 戰(zhàn)略層調研

• 調研目的：明確產(chǎn)品建設目標。業(yè)務系統(tǒng)是為了支持業(yè)務目標的達成，所以第一步要梳理清楚頂層管理者的戰(zhàn)略目標，進而明確產(chǎn)品的目標。
• 調研內(nèi)容：戰(zhàn)略目標、核心客戶、業(yè)務模式、盈利模式、核心策略、產(chǎn)品期望等。
• 調研對象：頂層管理者（包含不限于：老板、業(yè)務線負責人等）。
• 調研方式：面對面訪談。

本項目的戰(zhàn)略層調研結果：

• 調研對象：集團總經(jīng)理、銷售副總
• 戰(zhàn)略目標：銷售額同比去年增長30%，突破XX億
• 核心客戶：房地產(chǎn)中介經(jīng)紀人
• 業(yè)務模式：定位還是房產(chǎn)信息平臺，中介經(jīng)紀人入駐平臺后可發(fā)布房源信息，C端通過平臺獲取房源信息，然后通過平臺產(chǎn)品連接，再切換到線下溝通交易
• 盈利模式：向經(jīng)紀人收取平臺入駐費用，同時提供相關的付費廣告服務
• 核心策略：維持我愛我家、鏈家這些大型房產(chǎn)中介公司，但今年要進一步覆蓋中小型社區(qū)門店。為此要加大對銷售過程的管理，加強銷售覆蓋量和提升銷售轉化

產(chǎn)品期望：

• 將整個拜訪過程線上化，能實時監(jiān)控到銷售的拜訪情況。徹底規(guī)避虛假拜訪的情況，保證拜訪動作的有效執(zhí)行。
• 能通過數(shù)據(jù)分析，能銷售提供智能的拜訪建議。

2. 產(chǎn)品現(xiàn)狀梳理

• 目的：明確產(chǎn)品的邊界和對上下游的依賴。因為業(yè)務系統(tǒng)的上下游眾多，所以即使是從0到1設計一款業(yè)務系統(tǒng)，前期也需要把相關的產(chǎn)品現(xiàn)狀梳理清楚。
• 內(nèi)容：相關產(chǎn)品的功能架構、實體關系等等
• 方法：找到對應的產(chǎn)品和開發(fā)，梳理相應的產(chǎn)品功能架構圖和ER實體關系圖。

本項目的產(chǎn)品現(xiàn)狀梳理結果：

相關系統(tǒng)：只有3套系統(tǒng)，一套是簡易的客戶信息系統(tǒng)，一套是供應鏈管理系統(tǒng)，最后就是C端房產(chǎn)前臺。 其中客戶信息管理了 公司-門店-經(jīng)紀人這3層的信息；供應鏈系統(tǒng)管理了產(chǎn)品、訂單、收款、履約等信息。C端就是大家熟悉的房產(chǎn)平臺，展示經(jīng)紀人的房源信息。具體的內(nèi)容就不再展開了，大家了解這個環(huán)節(jié)主要做什么就行。

3. 競品學習

• 目的：借鑒競品好的設計，加快產(chǎn)品建設的效率。同時通過對競對的研究，規(guī)避一些因考慮不全導致的設計漏洞。 ?
• 方法：就是競對研究的常用方法，不贅述。

注意：

• 盡可能選擇業(yè)務模式相近的產(chǎn)品作為競品。
• 不要停留于產(chǎn)品功能的研究，更要深入了解背后的設計思路和業(yè)務策略。

4. 項目規(guī)劃方案

• 目的：對整體項目有大致的規(guī)劃，用于指導后面具體的項目工作。
• 內(nèi)容：背景、目標、方案概述、項目團隊、里程碑節(jié)點、溝通機制等等。

這部分不做展開，基本大家把上面幾部分的內(nèi)容梳理清楚就可以了。

5. 項目啟動會

• 目的：上下同欲，拉著項目成員一起把目標確定下來，任務分配下去，正式開工。
• 內(nèi)容：項目規(guī)劃方案里的內(nèi)容，加上領導們致辭。
• 參會人：領導+全體項目成員

這一步非常重要，千萬不能省略。因為筆者見過太多沒開啟動會就開始干，大家目標都沒有對齊，過程中各種撕逼，最終項目以失敗收場。

四、需求調研

調研結果將直接決定后面的產(chǎn)品架構設計，筆者剛做產(chǎn)品那會兒曾經(jīng)因前期調研不到位，花費大量資源開發(fā)出來的產(chǎn)品被用戶吐槽、甚至是被用戶棄用。?所以千萬不要因為項目工期緊張，而潦草應付這個環(huán)節(jié)。整個過程一定要詳細調研，力求獲得真實全面有效的信息。

1. 業(yè)務調研

目的：了解實際的業(yè)務場景和需求。

對象：業(yè)務環(huán)節(jié)上的所有角色，例如本項目需要調研一線銷售、銷售主管、銷售經(jīng)理、銷售運營支持、客戶（中介經(jīng)紀人）等。

內(nèi)容：包含但不限于以下幾點：

1. 組織架構及崗位權責
2. 工作流程及規(guī)范
3. 績效考核規(guī)范
4. 核心數(shù)據(jù)指標
5. 當前的業(yè)務執(zhí)行痛點和需求

方法：面對面訪談、親自參與體驗工作流程。

強烈建議B端產(chǎn)品經(jīng)理能親自體驗核心用戶的日常工作流程，因為大部分用戶難以清楚表達自己的需求，很多時候用戶說出來的其實是他們認為有效的產(chǎn)品方案，但卻不一定是最佳方案。只有產(chǎn)品將自己放到用戶的角色中去體驗，才能設計出真正有效且好用的產(chǎn)品。

2. 業(yè)務調研總結匯報

• 目的：進一步確認業(yè)務場景和需求
• 內(nèi)容：前期調研結果的匯總分析
• 方法：組織各個角色的核心代表一起進行調研結果，尤其是對核心場景和流程再次進行確認

五、概要設計

接下來我們正式開始產(chǎn)品的設計工作，首先把主體框架設計出來，確認主體設計沒問題后，再做進一步細節(jié)設計。

千萬不要一上來就畫原型、摳UI，這樣不僅會嚴重影響項目進度，甚至會因為陷入細節(jié)而忽視全局，導致項目最終失敗。

筆者曾經(jīng)跟過一個對UI要求極高的產(chǎn)品leader，當時也是做一個重要系統(tǒng)的重構。前期就是跟老板簡單溝通了之后，就開始要求畫高保真原型圖，然后一遍一遍扣細節(jié)。結果最后通宵達旦的加了2個月班，雖然出來的產(chǎn)品頁面樣式精美且交互流暢，但是用戶實際應用過程中整個環(huán)節(jié)跑不通，使用起來極其不方便。最后整個項目團隊被老板拉到一個超大的會議室足足罵了一個小時，半年度績效工資也基本都沒了。

通過上面這個case，筆者深刻意識到作為產(chǎn)品需要有極大的責任感及使命感。因為產(chǎn)品是帶領開發(fā)測試設計等團隊成員拿結果的人，如果我們工作不到位，極有可能讓整個項目成員的努力付之東流。希望看到這里的同學，能自省共勉。

下面講講在概要設計環(huán)節(jié)，我們具體要做什么。

1. 系統(tǒng)用例圖設計

• 目的：清晰的定義出系統(tǒng)邊界，即服務哪些用戶及并提供哪些功能。
• 方法：具體用例圖的設計方法，大家可以網(wǎng)上搜索下UML了解。

下面放一張本項目的拜訪計劃模塊用例圖，大家參考下。?

2. 功能架構圖設計

• 目的：進一步明確產(chǎn)品的功能范圍，為下一步產(chǎn)品演進藍圖做準備。
• 方法：分角色將線下的業(yè)務動作，分場景梳理拆分就可以了。

下面是本項目的銷售過程管理功能架構圖，大家可以參考。

3. 產(chǎn)品演進藍圖

• 目的：梳理產(chǎn)品功能優(yōu)先級，以明確后續(xù)產(chǎn)品設計和開發(fā)的節(jié)奏。
• 方法：分析業(yè)務發(fā)展階段，投入產(chǎn)出比和前后依賴關系，然后優(yōu)先當前業(yè)務需求且ROI高且必須前置開發(fā)的功能。
• 本項目的優(yōu)先級，我們經(jīng)過跟業(yè)務側的溝通明確如下。

第一階段目標：實現(xiàn)Do和check的管理線上化

第二階段目標：實現(xiàn)Plan管理線上化

第三階段目標：實現(xiàn)Goal管理線上化

第四階段目標：實現(xiàn)銷售賦能智能化

最后明確了整體的產(chǎn)品演進藍圖，如下：

六、詳細方案設計

1. 實體建模

• 目的：這一步相當于打地基，把系統(tǒng)內(nèi)各個實體的關系明確下來。例如 門店、拜訪計劃、拜訪記錄等各個實體的對應關系。這一步如果設計不到位，后面會非常痛苦。
• 方法：從實際業(yè)務場景和未來業(yè)務發(fā)展的角度來梳理，要同時兼顧當前開發(fā)成本和未來擴展性。這里強烈推薦 大家看這篇文章http://www.codemsi.com/pmd/4079449.html

本項目的E-R關系圖，筆者找不到了，所以就不展示了。大家重點關注此環(huán)節(jié)的設計方法。

2. 信息架構圖

目的：進行產(chǎn)品的頁面劃分及信息梳理，為下一步原型圖設計打基礎。

方法：

1. 按業(yè)務場景和產(chǎn)品功能進行頁面的梳理，明確整體有多少個頁面，彼此之間如何交互流轉，如何組合分類。
2. 分頁面梳理每個頁面的展示信息和操作信息。

其實業(yè)務系統(tǒng)單個頁面的梳理相對簡單基本都是基于實體的列表頁和詳情頁，然后配合增刪改查的操作。難點在于頁面組合分類，例如PC端的菜單應該如何設計，才能能保證用戶快速找到對應頁面。這部分相對復雜，筆者也沒有找到有關這部分的好文章。所以立個flag，后期筆者好好梳理下再給大家分享。

下面是本項目的部分信息架構的截圖，大家可以參考。

因為調整原型圖的成本比這一步大很多，所以建議大家在信息架構圖梳理完成后先做一輪內(nèi)部的產(chǎn)品評審。保證頁面間的流轉是順暢的，同時產(chǎn)品上的信息和操作能滿足業(yè)務需求，再進入原型設計的環(huán)節(jié)。

3. 原型圖

原型圖應該是大家最熟悉的一個環(huán)節(jié)，其實如果前面的信息架構圖梳理的好，這一步基本就是拼圖。這個環(huán)節(jié)就不做太多說明了，主要分享幾個原型圖設計的注意點。

1. 提前準備好通用模塊，例如彈窗等等能提高原型圖設計效率
2. 設計過程中考慮各種異常情況，例如沒有數(shù)據(jù)時的呈現(xiàn)樣式、數(shù)據(jù)返回超時的樣式等等
3. 注意按版本保存原型圖，不要在原有頁面上直接調整。因為很有可能改了好幾稿，發(fā)現(xiàn)之前的那稿更合適。

4. 交互設計圖

這個環(huán)節(jié)雖然主要是交互與UI設計師負責，但產(chǎn)品在設計前需要跟他們講清楚業(yè)務場景，便于他們更好的理解業(yè)務和產(chǎn)品。

同時在設計中，產(chǎn)品要承擔起交互設計圖的審核工作。雖然是業(yè)務系統(tǒng)但也要注意用戶體驗，不然會被內(nèi)部員工狂吐槽。

5. 角色及權限體系

• 目的：業(yè)務系統(tǒng)的數(shù)據(jù)多為公司內(nèi)部敏感數(shù)據(jù)和操作，所以權限體系設計可以有效控制風險。
• 方法：權限方面我一般會拆分出菜單權限、數(shù)據(jù)權限、操作權限這3類。至于具體如何設計角色及權限體系，大家可以多看看RBAC相關的資料。

6. 產(chǎn)品方案PRD

• 目的：通過文檔讓開發(fā)理解整個業(yè)務和產(chǎn)品邏輯，保證開發(fā)成果能滿足需求。
• 方法：大家都比較了解，不細說。重點在于PRD的內(nèi)容及順序，建議按前面的梳理步驟，先介紹整體的業(yè)務背景和產(chǎn)品架構，然后再分模塊詳細說明產(chǎn)品邏輯。
• 注意：文檔一定要盡可能詳細，免得開發(fā)出問題時界定不清楚責任。

7. 產(chǎn)品方案評審

• 目的：對PRD的內(nèi)容做進一步說明。
• 注意：針對評審過程中的問題及事后的調整一定要詳細記錄在PRD的修訂記錄里。

后面的開發(fā)測試及上線驗收環(huán)節(jié)，都是常規(guī)的項目管理工作，這里就不細講了。

最后希望本文對大家有幫助~~歡迎大家在下方評論區(qū)留言交流~

本文由作者@水問 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉載

題圖來自 Unsplash ，基于 CC0 協(xié)議