需求采集人人有责

上面用很大篇幅说了一些常用的需求采集方法，这一节，我想先抛出一个“一手 需求与二手需求”的概念，有个很形象的比喻就是“生孩子与养孩子”，话糙理不糙，

我们内部经常这么说。

我们首先把“生孩子”——需求采集视为己任，人人有责，希望所有人都参与，

都来“生孩子”，我们帮大家养，这就要给他们一个简单的“生孩子”的工具——“单 项需求卡片”，最后，简单介绍一下其他常用的方法，这样才能做到“尽可能多地采集”。

生孩子与养孩子

之前所述的各种方法，都是直接从用户那里得到需求，我称之为一手需求，就像

“生孩子”。其实很多时候，我们还会接受二手需求，比如老板说要给用户做个××功 能、销售人员说用户哪里用起来不顺等，这些需求和一手需求比起来，就像“养孩子”。

“生孩子”，更多的时候发生于新产品诞生前，这时候外部没有用户、内部没有运

营、销售、服务等，所以对于需求而言，更多的是产品人员驱动，去主动采集需求，

一张单项需求卡片描述了一个用户需求到底包含哪些内容，重点是描述用户场景， 场景（Where、When）（重要信息，用来理解需求发生的场景）

产生该需求的特定的时间、地理、环境等

图 2-9 单项需求卡片实例

上图是工程师提的一个需求，就像我们永远无法猜到用户会怎么使用我们的产品 一样，“单向需求卡片”原本是让大家给产品提需求，而工程师却拿它来给产品经理提 意见，很有意思。从表格的填写就可以看出来，实际工作中我们能拿到的都是填写不 完整的，甚至是字迹难以辨认的，当然，也可以尝试电子版，那样我们整理的成本低 一些，不过很可能愿意填的人就少了。但我们心里得有个底线，一张有价值的单项需 求卡片，至少得有“需求描述”，需求编号、来源、场景最好也能有，其他的，其实很 少有人愿意填写了。

回到这张卡片，工程师描述的一个需求也很有意思，值得我们共勉——“PD 慎重 地考虑一些细节的改变，在没有大影响的前提下，不要对稳定的版本做一些鸡毛蒜皮 的动作”。工程师们也希望自己做的事情都能产生商业价值啊。

每当我们拿到这样的卡片，就需要主动去和提交人交流，完善卡片的内容。真实 的工作中你能体会到，这张卡片只是需求过程的中间产物，所以我们在这上面花费的 精力也是尽量缩减，单向需求卡片所描述的用户需求，最终要转化为产品需求才有真 正的价值。

尽可能多地采集

需求采集的各种新方法层出不穷。和学习任何领域的知识一样，建议大家在了解 知识框架后，坚持“需求驱动学习”。