產(chǎn)品規(guī)劃是一件說難不難、說簡單不簡單的事情，筆者復盤了一次CRM系統(tǒng)的產(chǎn)品規(guī)劃，分享了其中對于關鍵節(jié)點的把握，以及做好一次產(chǎn)品規(guī)劃都要注意些什么事情。
目前在一家互聯(lián)網(wǎng)財稅公司負責核心業(yè)務產(chǎn)品，手頭主要三大產(chǎn)品線：財務線、稅務線以及CRM線。最近帶著各產(chǎn)品線負責人完成了三大產(chǎn)品線的產(chǎn)品規(guī)劃，有些產(chǎn)品線是一直在持續(xù)迭代，有些產(chǎn)品線則是停滯了一段時間，換了產(chǎn)品線負責人重新上手，整體上來說已經(jīng)整理的七七八八了。
過程中深感對于一名產(chǎn)品經(jīng)理來說，產(chǎn)品規(guī)劃能力的重要。而很多基本能力較為扎實的產(chǎn)品經(jīng)理在做產(chǎn)品規(guī)劃的時候也會陷入盲目堆需求、直接設計細節(jié)、優(yōu)先級排期混亂等問題上來。
在此將自己的一些實操經(jīng)驗拿出來與大家分享。
做產(chǎn)品規(guī)劃，說簡單也很簡單，把握關鍵節(jié)點，整理梳理出需求的輕重緩急即可。說難也很難，系統(tǒng)的現(xiàn)狀、市場的訴求、研發(fā)的資源、需求類型劃分、排期優(yōu)先級無一不是要納入考慮的要素。
如何在千絲萬縷的線索中抽出一條清晰的脈絡，我的理解，最為關鍵的一點在于做好業(yè)務深入理解和業(yè)務到系統(tǒng)的抽象。做好這一步，產(chǎn)品規(guī)劃和需求排期最終不過是水到渠成的事情。
本文我們以外呼型CRM系統(tǒng)為例（CRM較為普遍同時業(yè)務較為簡單），進行一次產(chǎn)品規(guī)劃的復盤。
第一步：理解業(yè)務本質
這一步先不要看任何系統(tǒng)，清空一切系統(tǒng)的影像。
首先，我們先思考，CRM業(yè)務的核心是什么？
CRM的核心很簡單，就是銷售用來挖掘跟進銷售線索并最終實現(xiàn)到成交客戶轉化的過程。
這就是CRM的核心，圍繞這個流程，用戶（主要為市場銷售人員）有哪些行為和場景？
在銷售線索階段，用戶主要行為就是挖掘驗證線索，最典型的行為就是打電話；
在潛在客戶階段，用戶主要行為就是對銷售線索轉化而來的客戶進行跟進，方式包括不限于電話溝通、上門拜訪等；
在成交客戶階段，客戶基本確認了購買意向，用戶需要完成合同簽署、收款等行為。
從上面的一段場景描述中，我們發(fā)現(xiàn)涉及的用戶行為包括溝通工具的使用（電話、短信、微信、QQ等）、用戶跟進動作的記錄（打電話、上門拜訪等）、交易達成必要手續(xù)（合同簽署、收付款等）。
至此，我們可以總結下，CRM的本質是：通過溝通工具的使用、跟進動作的記錄、交易達成必要手續(xù)來推動銷售線索到成交客戶轉化完成。
第二步：業(yè)務到系統(tǒng)的抽象
這一步還是不要看任何系統(tǒng)，清空一切系統(tǒng)的影像。
通過上面對業(yè)務的梳理，我們可以開始思考一個問題，要完成上述的業(yè)務，我們需要怎樣的一個系統(tǒng)。
第一，這個系統(tǒng)需要幫我們完成流程的流轉。而流程的流轉，無非要完成兩件事，在流程節(jié)點信息以及節(jié)點到節(jié)點之間的流轉。
流程節(jié)點信息是什么？
節(jié)點就是客戶所處的不同階段，即銷售線索、潛在客戶以及成交客戶三大客戶階段，流程節(jié)點信息具化開來就是每個客戶階段客戶列表頁以及客戶詳情頁/客戶卡片。
流程節(jié)點到節(jié)點之間的流轉要做什么？
需要制定流轉的前提條件（如需要添加哪些信息、上傳哪些文檔，生成哪些記錄等）以及流轉后的限制（只能哪個節(jié)點到哪個節(jié)點、流轉是否可逆等）。
第二，流程不會自我流轉，而是通過一些核心功能模塊，來驅動流程的流轉。
對照上圖，我們很容易拆分出溝通工具模塊（電話功能、短信功能、QQ等）、跟進動作的記錄（跟進動態(tài)、電話錄音、短信記錄、外勤簽到等）、交易達成手續(xù)（合同模塊、收費管理模塊、產(chǎn)品/服務管理等）。
第三，作為一個系統(tǒng)，還需要一些通用功能來支撐用戶的基本操作和管理。
我們可以把常用的系統(tǒng)功能拉出來看看是否我們系統(tǒng)都會用到，如用戶管理、權限管理、消息管理、基礎設置、幫助中心、數(shù)據(jù)統(tǒng)計……我們似乎發(fā)現(xiàn)了一個不太一樣的通用模塊——數(shù)據(jù)統(tǒng)計。
數(shù)據(jù)統(tǒng)計對很多系統(tǒng)來說，是一個通用的管理功能。但是對于CRM來說，數(shù)據(jù)統(tǒng)計不僅是對業(yè)務數(shù)據(jù)結果的分析，還會應用到對用戶工作的規(guī)劃統(tǒng)計和推動，即計劃模塊。所以，我們要把計劃管理放到推動流程流轉的核心功能中。
我們對上述功能抽象的結果做一個整理，如下：
至此，我們完成了對業(yè)務到系統(tǒng)功能的抽象，可以看到的是我們對功能的拆解，完全是基于我們對業(yè)務抽象的思考。同時，也有一些功能是我們在做功能拆解的過程中衍生出來的功能，比如數(shù)據(jù)公海以及銷售線索的領取與回收。
在此有個小插曲，我們是如何衍生出銷售線索的導入這一功能的呢？
我們把銷售線索、潛在客戶、成交客戶編個號1、2、3。大家都知道程序員的一個梗說的是同樣是數(shù)數(shù)，正常人都是1、2、3，而程序員則會0、1、2、3。
回到我們的設計，我們也會想，客戶是怎么就到了銷售線索這個階段（編號1）的？我們很容易就想到銷售線索從0到1的過程實際就是銷售線索導入的過程，從而衍生出銷售線索導入這個功能。
其實，實際CRM系統(tǒng)設計中還存在非常多的細節(jié)。例如數(shù)據(jù)回收機制、訂單流轉、財務對接、移動設備功能……展開來能講三天三夜。
但之前我們也說了，本文僅探討產(chǎn)品規(guī)劃的方法，而非CRM設計。在此再次聲明需要非常強調(diào)的一點：功能的拆解不代表的系統(tǒng)菜單的劃分，更不代表的頁面的設計層級，所以我們還需要根據(jù)功能之間相互依賴的關系，來進行頁面模塊的拆分重組。
關于功能的拆解到頁面功能模塊的收斂、合并、拆分、嵌入，我們在此不做贅述。
第三步：從功能清單到產(chǎn)品規(guī)劃
這一步，我們需要開始看系統(tǒng)了，畢竟這都已經(jīng)是最后一步了。
在這一步，我們首先需要得出功能清單。如果現(xiàn)在什么系統(tǒng)都沒有，可能上述的功能拆解就是功能清單了。而如果我們是在已有系統(tǒng)上做迭代，那我們需要拿著上述的功能清單，比對已有的系統(tǒng)功能，分析哪些功能我們?nèi)鄙俚模男┕δ苁切枰獌?yōu)化的。最終得出一個功能清單，或者就是我們通常所說的需求池。
而下面，我們就要對需求池進行規(guī)劃了。
對需求的規(guī)劃，我們依賴于三個指標：需求類型、需求重要程度、需求緊急程度。三大指標間相互獨立，單一指標內(nèi)部存在優(yōu)先級排序。
緊急度通常作為版本規(guī)劃依據(jù)；需求重要性作為同一緊急度下（或者同一版本內(nèi)）需求優(yōu)先級依據(jù)；同一緊急度同一重要性下需求類型作為需求優(yōu)先級依據(jù)。
具體來說：所有緊急度高需求構成最近一個版本需求，緊急度中需求作為下一版本需求，緊急度低需求作為未來版本需求；同一版本需求中，按照需求重要性從高到低排序；同樣重要性需求中，通常優(yōu)先處理線上Bug，其他需求類型次之。
需求類型通?？梢宰鋈缦聞澐郑壕€上Bug、新功能、功能優(yōu)化、技術需求。
需求重要性劃分通?？紤]如下因素：企業(yè)戰(zhàn)略、市場反饋、系統(tǒng)完整性、系統(tǒng)健壯性等。
需求緊急度劃分通?？紤]如下因素：是否位于主流程/關鍵路徑、是否存在外部依賴、是否存在時間窗口、用戶操作頻次、覆蓋用戶范圍等。
當然，每個系統(tǒng)需求類型、需求重要性、需求緊急度劃分需要根據(jù)各個公司的業(yè)務與產(chǎn)品自行定義，并不存在同一標準或者固定的公式。
通過以上步驟，基本我們也就完成了初步的產(chǎn)品規(guī)劃。當然，產(chǎn)品規(guī)劃的最終定稿還要和開發(fā)、測試團隊進行溝通，結合團隊研發(fā)資源進行綜合考慮，最終和業(yè)務部門確認定稿，該過程我們在此不做贅述。
結語
在產(chǎn)品工作中，我一直認為，產(chǎn)品設計絕不是一個依據(jù)個人感覺或者一個人的主觀判斷完成的工作。
產(chǎn)品設計、產(chǎn)品規(guī)劃、產(chǎn)品溝通、項目跟蹤以及產(chǎn)品日常工作的方方面面，都需要有方法論來支持工作的進行，有時候甚至像數(shù)學公式一樣，需要經(jīng)過嚴謹?shù)恼撟C與推導。
每個人的方法論可能不盡相同甚至大相徑庭，同一個人的方法論也并不是一成不變。但只有通過方法論的支撐，才能推動產(chǎn)品設計工作高效高質的完成，進而推動業(yè)務的落地與戰(zhàn)略目標的達成。
