基于需求的重要性和關聯(lián)性，本文作者將需求池類型分為重點OKR、項目需求集和零碎需求池這三種，并對這三種需求管理方法進行了介紹，一起來學習一下吧。

在之前的文章，我介紹了B端產品運營方法《適合新人：企業(yè)內B端產品的調研和運營方法》，接下來著重給大家介紹自己【需求池管理】的思路。

一、適合產品類型說明

適用性基于實踐本身，我所處的環(huán)境和業(yè)務，才形成了我自己的方法，以下簡要說明我的業(yè)務性質：

1. 企業(yè)內B端產品和流程：主要用戶在公司內部，可以與業(yè)務和研發(fā)進行快速調整和溝通；個人同時覆蓋好幾條產品線，需要應對不同的流程的并行需求；
2. 業(yè)務型需求、功能型需求：對業(yè)務的操作改變、感知比較大的，而非技術性、底層邏輯改造；
3. 需求量大、需要快速響應業(yè)務：平均每日接收2個以上小需求，需要快速響應和跟進；

二、不同類型的需求管理

我將需求池類型分為三種，這三種類型的分類方法，主要是基于需求的重要性和關聯(lián)性。

1. 重點OKR：對自身&相關方崗位產出有較高要求的關鍵績效結果，一般都是季度性的關鍵結果。主要在 [流程1：發(fā)掘和接受需求] 階段用到；
2. 項目需求集：單個重點項目上線前后強相關的需求集合，需求不穩(wěn)定性高。在 [流程2~流程5] 階段用到，貫穿單個項目上線前后的歷程；
3. 零碎需求池：日常小優(yōu)化，需求之間關聯(lián)程度不高，且該模塊基礎流程已較穩(wěn)定，不是重大變更。于我主要是用來做零碎備忘錄；

[流程1~5具體內容可以查看《適合新人：企業(yè)內B端產品的調研和運營方法》

三、管理方式介紹

下面我將就不同類型的需求池展開我的管理方式介紹。

1. 重點OKR

流程：

1）搜集相關方和自己的重點產出結果

一般是在每個季度結尾，要開始約相關方制定下個季度的需求，并讓對方排好優(yōu)先級及期望上線時間。

2）預期上線時間和優(yōu)先級溝通

相關方產出需求列表后，與其修訂優(yōu)先級和時間要求的合理性。時間的安排，可以自己根據(jù)經驗先拍出一版預估上架時間，但告知業(yè)務方可能會進行修改。

3）每個OKR的生命周期安排

隨后根據(jù)預計上線時間，倒推需求調研、開發(fā)測試的時間。然后就可以約研發(fā)團隊溝通了。和研發(fā)溝通之后會得到一版新的相對合理的時間。

4）生命周期階段記錄

需要記錄每個需求最新的狀態(tài)，是否已進入調研、開發(fā)。

5）計劃和完成度復盤

記錄和計劃當差異比較大的時候，要及時的跟業(yè)務溝通，跟產研協(xié)調資源。沖突無法自己處理時，要盡快告知上級風險和應對方案。

工具：OKR計劃表和公示：https://docs.qq.com/sheet/DQ0xabEx2SG1jUkpT?tab=BB08J2

*我的OKR表格示例（許多公司也有線上工具記錄）：

思路：

1）明確自己在急流中的錨點

一定要從公司和部門的目標出發(fā)，對齊自己的定位，才能抓住最核心點。作為運營和產品很容易被眼前看到的工作吸引，容易忽略這到底是不是公司需要的。

比如基層業(yè)務要求你為一個流程做時效統(tǒng)計，但結合大部門的規(guī)劃，下階段重點是做精細化管理，意味著流程節(jié)點還會再細拆，此時如果做了時效統(tǒng)計未來必定還要調整，就做了無用功。

2）孰輕孰重

業(yè)務總會給你提一大堆需求，你需要讓他自己先想清楚重點，這樣雙方才能達成優(yōu)先級共識，避免未來“這也想要那也想要”的局面。以及最重點的需求細節(jié)必須跟進到位，而次之的需求細節(jié)可以相對粗糙，只有心中有把清晰的秤，才知道在什么場景需要放棄什么。

我們容易在很忙的時候，讓自己做一些無關緊要的小事，以此逃避真正的重點，需要時常讓自己復盤“什么是重點”，及時把自己的舵擺正。

3）上下游聯(lián)動

要把自己當成一個”管子“，從業(yè)務同步過來的優(yōu)先級，也要與下游你的研發(fā)團隊同步，提前告知大家背景和需求，達到三個目的：提前預約資源、讓研發(fā)做好心里準備、提前了解產研疑問做好業(yè)務問題反向修正。

4）動態(tài)調整

表格只是個工具，表格不是一次性的，是可能每月每周都要調整的。在互聯(lián)網和電商行業(yè)，重點可能隨時在調整，資源隨時可能被重點項目抽走，你需要動態(tài)地和業(yè)務、研發(fā)對齊當前進度。

2. 項目需求集

流程：

1）業(yè)務調研和功能需求整理

有一套框架，我的個人框架在下方模板里。

2）業(yè)務方流程拉通&產研側功能討論會

記得做好會議紀要。

3）上線前確認好準備工作

歷史數(shù)據(jù)處理、驗收用例場景整理、業(yè)務培訓通知、上線通知。

4）上線后提供登記表用于業(yè)務異常登記

上線后一般異常會集體爆發(fā)，業(yè)務會集中反饋，導致信息霸屏，且業(yè)務只習慣截圖和抱怨，容易忽略提供數(shù)據(jù)。此時在線登記表是個解決問題的好方法，既能清晰記錄和追蹤問題，也能匯總分析異常量。

5）業(yè)務需求需要進一步篩成具體的需求，和研發(fā)團隊討論

此時需要另一個張表單獨記錄。

工具：項目需求集登記：https://docs.qq.com/sheet/DQ0JQZnBEWnB1dG11?tab=s54h4t

思路：

1）一切實物，皆可追蹤

你的需求點記錄清晰，可用于未來和業(yè)務產研battle，畢竟細節(jié)才是最容易漏掉的。上線后的問題提供字段讓業(yè)務記錄清晰，才可真正最高效地解決問題，讓問題止于抱怨和混亂。

2）落地不在心，在筆下

做計劃的目的是為了執(zhí)行時更井然有序，我相信每個人不乏把事情做好的能力，但是如果不做好清晰計劃，就很容易在上線前手忙腳亂。有清晰的todolist，才能最高效地把流程細節(jié)跑順，保證順利上線。

3）前人栽樹、后人乘涼

這些資料和文件，在項目結束后都可以整理成文件歸檔，便于后人翻閱當時的邏輯設置原理、當時的會議紀要、當時異常的成因。當然每個公司不一定都用在線文檔記錄，可以記錄到自己內部的流程文件里。

3. 零碎需求池

介紹：這應該是每個產品/運營人都會用到的最基本的需求池格式，不贅述。我一直用這個需求池記錄了好多年，發(fā)現(xiàn)每次項目上線記錄混亂后，才單獨抽出項目內的需求到《項目需求集》的池子了。所以目前零碎需求池，更多是用來做備忘。

工具：https://docs.qq.com/sheet/DQ2ZJYk12T0l2aEFa?tab=BB08J2

思路：

1）Always Break

唯一在這里重點想提的，就是“反復打破”這個概念。零碎需求池的用法，很多人是按時間記錄。而我會每周將它以“模塊”為維度重新排列一次，觀察需求的聯(lián)動性，如果關聯(lián)性高的不一定按照時間先后做，而是綁在一起做。這是一個觀察方法，也是一個更高效的處理方法，它能讓你對模塊的聯(lián)動更敏銳。

以上是我目前需求池的管理實踐，會時新時更，方法要隨著實踐變化。