做好產品規劃的3個步驟 如何做好產品規劃( 二 )


至此 , 我們完成了對業務到系統功能的抽象 , 可以看到的是我們對功能的拆解 , 完全是基于我們對業務抽象的思考 。 同時 , 也有一些功能是我們在做功能拆解的過程中衍生出來的功能 , 比如數據公海以及銷售線索的領取與回收 。
在此有個小插曲 , 我們是如何衍生出銷售線索的導入這一功能的呢?
我們把銷售線索、潛在客戶、成交客戶編個號1、2、3 。 大家都知道程序員的一個梗說的是同樣是數數 , 正常人都是1、2、3 , 而程序員則會0、1、2、3 。
回到我們的設計 , 我們也會想 , 客戶是怎么就到了銷售線索這個階段(編號1)的?我們很容易就想到銷售線索從0到1的過程實際就是銷售線索導入的過程 , 從而衍生出銷售線索導入這個功能 。
其實 , 實際CRM系統設計中還存在非常多的細節 。 例如數據回收機制、訂單流轉、財務對接、移動設備功能……展開來能講三天三夜 。
【做好產品規劃的3個步驟 如何做好產品規劃】但之前我們也說了 , 本文僅探討產品規劃的方法 , 而非CRM設計 。 在此再次聲明需要非常強調的一點:功能的拆解不代表的系統菜單的劃分 , 更不代表的頁面的設計層級 , 所以我們還需要根據功能之間相互依賴的關系 , 來進行頁面模塊的拆分重組 。
關于功能的拆解到頁面功能模塊的收斂、合并、拆分、嵌入 , 我們在此不做贅述 。
第三步:從功能清單到產品規劃這一步 , 我們需要開始看系統了 , 畢竟這都已經是最后一步了 。
在這一步 , 我們首先需要得出功能清單 。 如果現在什么系統都沒有 , 可能上述的功能拆解就是功能清單了 。 而如果我們是在已有系統上做迭代 , 那我們需要拿著上述的功能清單 , 比對已有的系統功能 , 分析哪些功能我們缺少的 , 哪些功能是需要優化的 。 最終得出一個功能清單 , 或者就是我們通常所說的需求池 。
而下面 , 我們就要對需求池進行規劃了 。
對需求的規劃 , 我們依賴于三個指標:需求類型、需求重要程度、需求緊急程度 。 三大指標間相互獨立 , 單一指標內部存在優先級排序 。
緊急度通常作為版本規劃依據;需求重要性作為同一緊急度下(或者同一版本內)需求優先級依據;同一緊急度同一重要性下需求類型作為需求優先級依據 。
具體來說:所有緊急度高需求構成最近一個版本需求 , 緊急度中需求作為下一版本需求 , 緊急度低需求作為未來版本需求;同一版本需求中 , 按照需求重要性從高到低排序;同樣重要性需求中 , 通常優先處理線上Bug , 其他需求類型次之 。

  • 需求類型通??梢宰鋈缦聞澐郑壕€上Bug、新功能、功能優化、技術需求 。
  • 需求重要性劃分通常考慮如下因素:企業戰略、市場反饋、系統完整性、系統健壯性等 。
  • 需求緊急度劃分通??紤]如下因素:是否位于主流程/關鍵路徑、是否存在外部依賴、是否存在時間窗口、用戶操作頻次、覆蓋用戶范圍等 。
當然 , 每個系統需求類型、需求重要性、需求緊急度劃分需要根據各個公司的業務與產品自行定義 , 并不存在同一標準或者固定的公式 。
通過以上步驟 , 基本我們也就完成了初步的產品規劃 。 當然 , 產品規劃的最終定稿還要和開發、測試團隊進行溝通 , 結合團隊研發資源進行綜合考慮 , 最終和業務部門確認定稿 , 該過程我們在此不做贅述 。
結語在產品工作中 , 我一直認為 , 產品設計絕不是一個依據個人感覺或者一個人的主觀判斷完成的工作 。
產品設計、產品規劃、產品溝通、項目跟蹤以及產品日常工作的方方面面 , 都需要有方法論來支持工作的進行 , 有時候甚至像數學公式一樣 , 需要經過嚴謹的論證與推導 。
每個人的方法論可能不盡相同甚至大相徑庭 , 同一個人的方法論也并不是一成不變 。 但只有通過方法論的支撐 , 才能推動產品設計工作高效高質的完成 , 進而推動業務的落地與戰略目標的達成 。

推薦閱讀