如何处理需求池？管理需求池的内容

需求从四面八方，纷至沓来，并不是什么都收，或者会落地到产品中，转化为一个功能，或者是可见的一个界面。产品经理除了需求的工作之外，还需要对产品定义，对产品落地的过程进行管理，还要对产品成长的过程进行监督。我们要把收集过来的需求，统一管理起来，来自哪里，是谁的需求，需求是什么，具象到产品哪里，需要什么资源来实现，谁来实现，最后要把需求落地后的效果反馈。

时间(节奏)

2012 年，入职一家基于地图做本地生活的公司，主要做的事情，可划归为打杂，工具运用，职场历练。1、调整修改产品介绍的 PPT；2、申报产品的知识产权；3、帮忙打印五一活动的材料，横幅、传单等等之类的；4、给地图上增加一个全景的功能。这是第一份关于产品的工作，这也是产品工作琐碎的体现，文档、人际关系、工具运用。对于需求是什么？如何收集需求？什么时候去收集？从哪里收集需求？没有系统的了解，更多的是项目上的事情。

经过半年多的时间，在一家经纪公司做网络工程，场工，2013 年，再次从事产品的工作，终于有了一个 title，产品助理，公司另外还有一个从运营岗转过来的产品助理。产品部门的组织结构是产品总监，一个产品经理，两个产品助理，还有两个 UI。在这家公司，才真正开始系统的了解产品相关工作的流程，过程，其中有个很重要的工作就是处理需求。

我们处理的方式，本周四到下周二是收集需求的过程，周三会汇总成需求池，并把大家召集在一起，将需求转换为产品终端的某个功能点，并和产品经理确定下来，那些做，那些不做，那些后座，那些先做，再和技术经理，确定资源，也就是谁来做，多久交付。周五会发一个版本，周四会集中处理一些能够马上就改好的，或者是这一周改好的，周五进行测试，验证确认，最后周五晚上发版。

时间，其实也就是节奏。每天都会收到各个部门，老板们的需求，“我觉得这个不好用”；也会受到各个部门，老板们的追问，“我提的需求，什么时候才能交付使用”，“怎么要那么久”，“不就是…”,疲于应付，那你就没有时间去做其他的事情了。确定好节奏，每周什么时候，做一个节点，后面来的需求顺延到下周的计划；还要考虑开发团队的节奏，他们不仅仅是每周就处理你的这些需求，还需要应付产品经理的需求内容，那些是长期的，当然在我待过的团队里面，也有专门留出来一两个开发人员机动，有事就去支持主线任务开发，无事就来处理这些琐碎的需求；需要及时反馈需求处理的结果，以及跟踪改动后达到的效果。

内容

需求采集文档，里面是一个表格，平常的时候，就丢给所有人去填，周三统一收集一次；需求池表格，一个表头特别长的 Excel，几乎囊括了需求的一生，你可以看到需求谁提的，是什么，做在那里，谁做的，做不做，什么时候做，为什么等等这些内容。在 2021 年末到 2022 年初这段时间里面，待的一家公司，他把这种追溯做了一个升级，另外还有一个功能序号。他几乎是什么需求都做，只是会把这个需求落地的功能，都转换为公共的功能，或者是某个项目的功能，对需求来源也做了控制，只有自己的客户才能提出相关的业务需求。这几乎就是一个需求机器。

首先是“需求采集文档”，分为两个部分，其一是反馈，其二是具体的内容。反馈主要是处理该需求的内容，进行需求基本信息登记，需求判定结果，处理结果的回复。需求来源部门，填报人、日期，产品名称(最终在那里进行落地实现的)，受理部门，需求类型，优先级判定及处理意见，还包括各方的签字确认。

需求具体内容是“需求采集文档”的主要内容，需求基本信息、需求用户画像、需求内容描述、需求定义及其处理方式。需求基本信息，需要进行说明的是产品名称，用户所使用的产品名称，2013 年，yiyacare,我们主要指的是健康大管家，健康小秘书这两款 APP、wap 页面。专注在大健康领域，健康大管家做软件服务，健康小秘书做内容服务，我当时在 yiyacare 主要做的是软件服务。某些公司，产品体系庞杂，业务相互牵连，产品和项目混搭，可能自己公司内部都搞不清楚自己要反馈的需求是那个产品的，更不要说公司内部，或者是用户反馈了。所以在这里，产品名称是泛指，你可以是任何产品，公司自己的产品，项目，或者是市面上其他的 APP，网页都可以，当你找不到产品所对应的时候，那就填一个线下产品，我个人觉得都是可以的。你可以把产品名称定义为需求来源，也就是你从什么地方看到，或者是想到的这个需求即可。

需求类型，我们将其划分为了功能需求、非功能需求。按照用户习惯去定义的，以便所有人去填的时候，能够理解。功能需求分为了新增需求、bug 修改、优化建议；非功能需求分为了客户意见、用户投诉和其他。内部需求，还需要考虑运营的数据反馈，工程师和运维同事对性能，执行效率的反馈，内部需求进行内部处理和探讨。表格在落地执行的时候，很多人都不知道怎么填，大部分都会把功能需求勾上优化建议，对非功能需求填上了其他，这也是灵活应用把。

需求用户画像，绝大部分都不会填，也不是常规，或者是每个公司的模板里面都会有的一个模块，这部分算是辅助信息，场外信息，去帮助产品经理来理解需求本身，需求为什么会产生。yiyacare，做的是大健康领域，肯定也会涉及到医疗的内容，例如我们在健康大管家里面就有医院的每日清单，各个公司或社区的体检机构产出的体检报告，医患沟通等等。用户画像相对 yiyacare，可以看到这个需求是来自医生，还是来自个人，人不一样，他们考虑的角度也会不一样。还有用户的年龄段，主要是考虑有些年龄比较大的医生或患者，他们不太会操作手机的角度。心理治疗中，“现实治疗疗法”中，对真实世界的定义是，人、场景和客观存在的事实。在用户画像里面，还有场景的描述，用户在什么场景下，做了什么。我们最终落地这个表格的时候，也偷懒了，主要还是不想拔高填写表格的难度，所以就把场景具象成了，Android、iOS 手机或 pad(平板)、wap 网页，还有他们当前应用的版本。放到现在的大环境下，那就是要看浏览器、第三方平台(H5 页面会在第三方平台上呈现)、设备(电视机、手表)等等。

需求内容描述，我们在前一章节就提到过，很多需求的描述具有非常强的引导性。大部分人不知道怎么去描述一个需求，但是我们又不能去划定一个固定句式，让所有人根据这个来填，这样就失去了需求收集的意义。有一本书叫《学会提问》，通过提问，去反推他们的表达是一种方式。我翻看我们之前的“需求采集文档”的模板里面，举的例子，“面向此 600 人提供产品侧 VIP 服务的定向群发短信、彩信功能”，它在“使用场景”里面前置了“600 人”的定义，“短信和彩信”的内容是“健康大管家”的关怀短信、“健康小秘书”的资讯短信。本身就有产品特性，项目背景的特点，yiyacare 当时做的体检类的项目，它是以“中国移动”整个单位的员工福利，每年都去体检，然后把体检通知及结果推送给所有员工，我们还有一个技术类的产品“willi”进行相关的支持。(补充一下，十年前的产品，应该不会有商业泄密的风险吧，叠个甲，申明一下，我只做分析，不做结论)。

需求定义及处理方式，按照上面的需求内容描述，如果我们只做甲方需求，那就提供短信模板的修改，对那 600 个人做群发短信推送就好了。用户收不到消息，不愿意看消息的原因，我们还可以深层次的思考一下。消息过于频繁，条数太多，淹没了，沉底，甚至是被消息通道的渠道商给拦截了，你消息发的太勤，它把你给封了。对消息进行分类，系统消息、个人消息，或根据业务进行分类，来自那个业务的消息推送，或在每个业务下面都弄一个消息模块，只负责接受这个业务的消息推送。我们现在的消息推送通道太多了，产品/系统本身就有消息推送，一般在网页端的右上角就会带个“信封 icon”的图标，对一些需要进行处理/操作的消息，例如审核，还会在右下角，跟随页面，悬浮一个按钮；App 上，如果产品/应用本身有很强的社交/社区属性，那就可能会把消息模快，单独的做一个导航栏的图标放在底部，还需要引导用户之间的话题；短信和彩信的渠道已经没落了，现在第三方平台的消息推送才是风头正劲的时候，例如“微信公众平台”的消息推送，直接把消息推送到微信上面；还有一些企业内部需求的消息推送，例如前面，提到的“审核”“消息模板的修改(我们不能把短信局限，而是要通用到消息模板，虽然他们可能更改的项是不一样的)”，通过企业沟通软件，钉钉、企业微信、飞书等直接推送给需要处理的人哪里，用户界面都不需要了，只要一个 api 推送就可实现。

需求定义和处理的时候，需要去考虑需求急切程度，如果是他规定了类似案例中的这种非常具体，具象的需求，那就一定要问他，他可接受的最晚交付时间是什么时候？他要的很急，那就把已有的类似的业务，改动一下功能，交付给他。如果没有，那就做个最小可交付的业务，也就是包括他所描述的所有必要的，相同的内容，保证可运行。时间充足的情况下，我们就做好产品预研，以他的需求描述为案例，规划整个产品的消息系统，以便后续需求的变动，拓展，延伸。例如他后面又想推送体检报告，例如他后面又想在体检的项目中，增加一个系统消息推送，或者是单独做一个业务消息，或者是直接把入职体检报告推送给用人单位和他本人，或者是把老年人的体检报告推送给他的医生，他的子女或保姆之类的。要以不变应对万变，把他后面可能得“幺蛾子”搞清楚，当然这些定义，你不能和他讲，或者是和开发团队说呀，如果你说了，他真的要你这么干的时候，你就被动了，没时间来安排了；也不能和开发团队说，他们会说，你想多了，又给“老子”画饼，增加工作量。你把事情规划好，再一步步的和开发团队做推进。

做好需求定义后，接着就是和开发团队确定开发资源，包括人员和物的资源，确定测试时间，验证时间，交付时间。几个人来做，是否需要运维支持数据库，服务器资源调整等。测试人员也必须介入进来，他得知道是什么事情。