需求池管理你不知道的事儿

作者 | 小黑

来源 | 张晨雨曦 （公众号：PMJadores)

提到需要池，相信很多的产品小伙伴们，并不会感到陌生。

需求池是每个产品经理工作中很熟悉的一部分。

那么需求池会在什么样的场景下使用呢？

如果有一天你是以产品经理的角色入职某一家公司的话，那么你的主要工作内容可能是完善已有的产品P1或者创造新的产品P2。

有很大的概率，你会经历长久的完善P1的时期，20%概率，可能幸运地获得创造P2的机遇。

或许这样的工作实际会与你改变世界的预期大相径庭，但是对优化完善一款产品又总是保有持久的热情。产品经理脑子里可能始终存在2个问题：还有谁的需求没有满足？

怎么说服研发同学们按照自己的设计去满足需求？

一方面需要的来源又很广泛，信息载体形式多种多样，文字、音频、视频、图片等；产品经理如果仅仅凭借大脑记住信息，记忆随着时间逐渐模糊甚至消失，导致信息偏差或者遗失。

需求信息获取的过程是随机的不连续的，在大脑中的信息也是分散的，进行需求分析很不方便。

即使产品同学能够记住所有的东西，但是给研发团队输出需求也不方便。

其他人不能直接获取产品经理大脑的信息，即便是通过口头表述传达信息，叙述过程可能遗漏重要信息，实际接收也存在信息损耗，最终很可能导致需求变形甚至错误。

想摆脱这些困境，不妨试一试求助需求池帮忙。

那么需求池能够解决什么问题呢？

简单的来说需求池就像产品经理的一本关于需求的电子台账，是重要的生产工具，它可以至少帮助产品经理解决很多的问题。

一方面原始需求可能是来自邮件、会议、电话交流、聊天、测试等过程中。

信息是分散的，但是需求一般不能直接提交研发团队进行处理，产品经理需要对需求进行梳理分析，这个过程需要多次回顾查看原始需求。

假设现在有5项需求，一个需求完成分析输出需要3次查看需求。

分散状态当我们处理需求时，总计需要花费在获取需求路上的时间为：

Tf 1=(T1+T2+T3+T4+T5)*3

但是产品经理需要更高效的处理需求，如果我们尝试把需求汇总到一起，汇集状态当我们处理需求时，总计需要花费在获取需求路上的时间为：

Tf 2=T0*3

T0的时长存在下表所述的几种情况：

假设：T1

按照上表推演，可以预见随着需求越来越多，获取路径就越多，Tf 1时长将持续增加，Tf 2则趋近于一个不变的常数，因此，为了节省产品经理需求输出的处理时间，将需求实现汇集是一个优化工作效率的可取选项。

再者原始需求可能是文档中的文字、图片、视频、线上或线下交流的语音等形式，当我们去分析一项项需求时，我们需要去切换不同的信息解析和展示工具。

很多的需求可能就是一段文字，一张图片，一段视频，获取这些载体中信息的过程需要切换3种工具（包括，公文办公软件，图片查看软件，视频播放器）我们才能提取到信息，这期间会有时间的损耗。

如果我们用一个工具就能提取到所有需求信息，那么就可以节省需求处理时间，而用一款工具能够实现所有信息的获取就需要信息具有统一的标准才能实现解析。

当然好的需求池也能够很好的避免信息的遗漏。

我们的产品同学通过解读原始需求获取到的信息首先会在大脑中留存，这些信息提供给大脑思考的基础原料，大脑会根据输入的信息输出思考结果，随着对需求的思考分析越充分，输出结果也会越接近准确。

这个思考输出的过程是一个逐步成熟完善的过程，可能是一天、一周、一月或者更长。

如果不将这些思考所得记录下来，按照人类的生物规律，靠记忆保存的信息会随着时间逐渐消失，进而导致重复去思考一个没有结果输出的需求，造成时间浪费。

用需求池将思考的成果记录下来可以帮助我们避免思考成果信息遗漏。

当然做好需求以后是要共享给开发同学 或者其他的人。

产品经理是最了解需求的人，但是需求满足最终还是需要研发团队来进行落地实现。

因此，产品经理需要把需求信息传达给大家。研发团队是多人多角色间进行协作的，如果信息不能便捷的获取可能会导致团队任务完成延时，或者对于变更等信息不能及时获知，导致研发资源浪费。

使用需求池提供团队间信息共享的媒介，帮助大家协同工作。

那么我们应该怎样去管理需求池呢？

产品经理是需求池的管理员，具有对资源的使用和维护的职责。

原始需求信息是后续需求处理的基础，需要产品经理尽可能的按照原始信息客观记录，避免先入为主的加入主观判断。

为了辨识各项需求，给每项需求一个唯一的编号。原始需求信息可能存在不完善或歧义的情况，因此需要保留对原始需求信息的可追溯路径，留存需求提出人及其联系方式等等

另外原始需求承载的需求信息经过产品经理梳理分析，定位到需求对应的问题本质并提出解决方案，根据需求分析结果综合评估需求满足策略及实现的优先级的。

当然需求经过分析获得问题解决方案，为满足需求提供了可能。

接下来需要研发团队如UI/UE设计师，开发工程师，测试工程师等协作将方案进行实现。

产品经理通过任务责任到人，约定完成时间进行过程进度管理和需求成果验收。

为了统一一个时间周期内需求处理的范围，我们拟定一个唯一的版本编号，保证版本的需求范围信息一致。如果需求还有相关的其他补充信息，我们预留备注信息栏，保证信息留存。

总的来说，需求池管理要注意信息源头可追溯，分析过程留记录，实现状态有跟踪，保证需求始终有一本台账。