企业内B端需求池管理分享

基于需求的重要性和关联性，本文作者将需求池类型分为重点OKR、项目需求集和零碎需求池这三种，并对这三种需求管理方法进行了介绍，一起来学习一下吧。

在之前的文章，我介绍了B端产品运营方法《适合新人：企业内B端产品的调研和运营方法》，接下来着重给大家介绍自己【需求池管理】的思路。

一、适合产品类型说明

适用性基于实践本身，我所处的环境和业务，才形成了我自己的方法，以下简要说明我的业务性质：

企业内B端产品和流程：主要用户在公司内部，可以与业务和研发进行快速调整和沟通；个人同时覆盖好几条产品线，需要应对不同的流程的并行需求；业务型需求、功能型需求：对业务的操作改变、感知比较大的，而非技术性、底层逻辑改造；需求量大、需要快速响应业务：平均每日接收2个以上小需求，需要快速响应和跟进；

二、不同类型的需求管理

我将需求池类型分为三种，这三种类型的分类方法，主要是基于需求的重要性和关联性。

重点OKR：对自身&相关方岗位产出有较高要求的关键绩效结果，一般都是季度性的关键结果。主要在 [流程1：发掘和接受需求] 阶段用到；项目需求集：单个重点项目上线前后强相关的需求集合，需求不稳定性高。在 [流程2~流程5] 阶段用到，贯穿单个项目上线前后的历程；零碎需求池：日常小优化，需求之间关联程度不高，且该模块基础流程已较稳定，不是重大变更。于我主要是用来做零碎备忘录；

三、管理方式介绍

下面我将就不同类型的需求池展开我的管理方式介绍。

1. 重点OKR

流程：

1）搜集相关方和自己的重点产出结果

一般是在每个季度结尾，要开始约相关方制定下个季度的需求，并让对方排好优先级及期望上线时间。

2）预期上线时间和优先级沟通

相关方产出需求列表后，与其修订优先级和时间要求的合理性。时间的安排，可以自己根据经验先拍出一版预估上架时间，但告知业务方可能会进行修改。

）每个OKR的生命周期安排

随后根据预计上线时间，倒推需求调研、开发测试的时间。然后就可以约研发团队沟通了。和研发沟通之后会得到一版新的相对合理的时间。

4）生命周期阶段记录

需要记录每个需求最新的状态，是否已进入调研、开发。

5）计划和完成度复盘

记录和计划当差异比较大的时候，要及时的跟业务沟通，跟产研协调资源。冲突无法自己处理时，要尽快告知上级风险和应对方案。

工具：OKR计划表和公示：https://docs./sheet/DQ0xabEx2SG1jUkpT?tab=BB08J2

*我的OKR表格示例（许多公司也有线上工具记录）：

思路：

1）明确自己在急流中的锚点

一定要从公司和部门的目标出发，对齐自己的定位，才能抓住最核心点。作为运营和产品很容易被眼前看到的工作吸引，容易忽略这到底是不是公司需要的。

比如基层业务要求你为一个流程做时效统计，但结合大部门的规划，下阶段重点是做精细化管理，意味着流程节点还会再细拆，此时如果做了时效统计未来必定还要调整，就做了无用功。

2）孰轻孰重

业务总会给你提一大堆需求，你需要让他自己先想清楚重点，这样双方才能达成优先级共识，避免未来“这也想要那也想要”的局面。以及最重点的需求细节必须跟进到位，而次之的需求细节可以相对粗糙，只有心中有把清晰的秤，才知道在什么场景需要放弃什么。

我们容易在很忙的时候，让自己做一些无关紧要的小事，以此逃避真正的重点，需要时常让自己复盘“什么是重点”，及时把自己的舵摆正。

）上下游联动

要把自己当成一个”管子“，从业务同步过来的优先级，也要与下游你的研发团队同步，提前告知大家背景和需求，达到三个目的：提前预约资源、让研发做好心里准备、提前了解产研疑问做好业务问题反向修正。

4）动态调整

表格只是个工具，表格不是一次性的，是可能每月每周都要调整的。在互联网和电商行业，重点可能随时在调整，资源随时可能被重点项目抽走，你需要动态地和业务、研发对齐当前进度。

2. 项目需求集

流程：

1）业务调研和功能需求整理

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

2）业务方流程拉通&产研侧功能讨论会

记得做好会议纪要。

）上线前确认好准备工作

历史数据处理、验收用例场景整理、业务培训通知、上线通知。

4）上线后提供登记表用于业务异常登记

上线后一般异常会集体爆发，业务会集中反馈，导致信息霸屏，且业务只习惯截和抱怨，容易忽略提供数据。此时在线登记表是个解决问题的好方法，既能清晰记录和追踪问题，也能汇总分析异常量。

5）业务需求需要进一步筛成具体的需求，和研发团队讨论

此时需要另一个张表单独记录。

工具：项目需求集登记：https://docs./sheet/DQ0JQZnBEWnB1dG11?tab=s54h4t

思路：

1）一切实物，皆可追踪

你的需求点记录清晰，可用于未来和业务产研battle，毕竟细节才是最容易漏掉的。上线后的问题提供字段让业务记录清晰，才可真正最高效地解决问题，让问题止于抱怨和混乱。

2）落地不在心，在笔下

做计划的目的是为了执行时更井然有序，我相信每个人不乏把事情做好的能力，但是如果不做好清晰计划，就很容易在上线前手忙脚乱。有清晰的todolist，才能最高效地把流程细节跑顺，保证顺利上线。

）前人栽树、后人乘凉

这些资料和文件，在项目结束后都可以整理成文件归档，便于后人翻阅当时的逻辑设置原理、当时的会议纪要、当时异常的成因。当然每个公司不一定都用在线文档记录，可以记录到自己内部的流程文件里。

. 零碎需求池

介绍：这应该是每个产品/运营人都会用到的最基本的需求池格式，不赘述。我一直用这个需求池记录了好多年，发现每次项目上线记录混乱后，才单独抽出项目内的需求到《项目需求集》的池子了。所以目前零碎需求池，更多是用来做备忘。

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

思路：

1）Always Break

唯一在这里重点想提的，就是“反复打破”这个概念。零碎需求池的用法，很多人是按时间记录。而我会每周将它以“模块”为维度重新排列一次，观察需求的联动性，如果关联性高的不一定按照时间先后做，而是绑在一起做。这是一个观察方法，也是一个更高效的处理方法，它能让你对模块的联动更敏锐。

以上是我目前需求池的管理实践，会时新时更，方法要随着实践变化。

本文由 @我叫更更 原创发布于人人都是产品经理，未经许可，禁止转载

题来自 Unsplash，基于 CC0 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。