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

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

一、項目背景

公司介紹：一家互聯網房產平臺公司，主要的客戶群體是房產中介。

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

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

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

二、項目過程回顧

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

下面的內容就是項目過程的具體回顧。?

三、項目啟動

1. 戰略層調研

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

本項目的戰略層調研結果：

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

產品期望：

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

2. 產品現狀梳理

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

本項目的產品現狀梳理結果：

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

3. 競品學習

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

注意：

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

4. 項目規劃方案

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

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

5. 項目啟動會

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

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

四、需求調研

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

1. 業務調研

目的：了解實際的業務場景和需求。

對象：業務環節上的所有角色，例如本項目需要調研一線銷售、銷售主管、銷售經理、銷售運營支持、客戶（中介經紀人）等。

內容：包含但不限于以下幾點：

1. 組織架構及崗位權責
2. 工作流程及規范
3. 績效考核規范
4. 核心數據指標
5. 當前的業務執行痛點和需求

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

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

2. 業務調研總結匯報

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

五、概要設計

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

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

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

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

下面講講在概要設計環節，我們具體要做什么。

1. 系統用例圖設計

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

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

2. 功能架構圖設計

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

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

3. 產品演進藍圖

• 目的：梳理產品功能優先級，以明確后續產品設計和開發的節奏。
• 方法：分析業務發展階段，投入產出比和前后依賴關系，然后優先當前業務需求且ROI高且必須前置開發的功能。
• 本項目的優先級，我們經過跟業務側的溝通明確如下。

第一階段目標：實現Do和check的管理線上化

第二階段目標：實現Plan管理線上化

第三階段目標：實現Goal管理線上化

第四階段目標：實現銷售賦能智能化

最后明確了整體的產品演進藍圖，如下：

六、詳細方案設計

1. 實體建模

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

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

2. 信息架構圖

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

方法：

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

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

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

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

3. 原型圖

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

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

4. 交互設計圖

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

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

5. 角色及權限體系

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

6. 產品方案PRD

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

7. 產品方案評審

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

后面的開發測試及上線驗收環節，都是常規的項目管理工作，這里就不細講了。

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

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

題圖來自 Unsplash ，基于 CC0 協議