产品日常工作规范之需求收集（第一篇）

写作是一个快乐的事情，但是带着目的性去写作是痛苦的。同样的，工作也可以是一个快乐的事情，但是带着目的性去工作也会是痛苦的。但是没有目的的写作和工作就跟游泳一样，只是为了玩水，解暑，放松罢了，想学会游泳，还是得有目的性的，有章法的练习才能成为最后的浪里白条。

产品行业亦是如此，很多时候我也曾怀疑自己是否就如网上大家所说的「野生产品」，全是野路子。但是鲁迅也曾说过：“世界上本没有路，走的人多了，也便成了路”。

现实中也没有野生产品，遵循的规则多了，也便不野生了。这些规则不仅仅为约束自己，也为团队其他人负责，希望他们能比我走的更加顺畅，更加科学和规范，因为产品之路对于他们来说才刚刚开始。

本文是第一篇，需求管理模块下的需求收集，它结合了我这两年多工作的一些思考和总结，其中有些内容可能也没有很经验老道或者推陈出新，请大家指点，斧正。毕竟，网上是真的找不到太多产品团队管理方面的内容和指导了。

在此，我将需求收集分为几种类型：

BUG类需求；

功能缺失类需求；

优化型需求；

以上的分类可能不一定准确，但是基本是以日常工作中常见的需求为基础，从中抽取一些稍微明显的分解的特征，用来进行分类。

测试或者是用户在日常使用中反馈的一些需求，此类需求一般会让运维团队和测试团队进行单独的记录，然后每周会与产品和开发组长等人一起召开会议讨论。这种需求有时会也会记录在相应的产品经理的日常工作记录中，有些需求是没有提出人的，所以产品经理在应对这种需求的时候尽量用Excel表的形式记录，同时备注相关的需求来源是因为测试或者用户反馈的。

此类需求一般不需要填写相关的需求反馈表，只需要自己有相应的Excel或者文档记录即可，如果处理完了就要及时更新状态，同时最好能记录在TAPD中。

功能缺失类的需求意思是指系统不支持某些客户的需求，有可能是历史原因造成也有可能是因为业务或者产品没有想到要做此功能，所以此类需求一般是大需求或者是涉及部门和干系人较多的需求。

此类需求需要让提出者，一般是业务部门的人，填写相应的需求反馈表，然后邮件通知给相关的产品负责人。IT部产品组每个人会专项负责某些系统、产品模块，所以如果业务部门不清楚此需求应该提交反馈给谁，可以直接通知抄送给@vitamin，进行需求的提出。

当然，提需求对于业务部门是一个简单的事情，但是一般地我们往往会设置一些门槛来阻碍业务部门提出需求。因为需求的接收，调研，评审，还有一系列的规划筹备都会花费很多时间，设置门槛和繁琐步骤的目的是希望业务部门在提出需求前先形成自我的闭环思考，结合自己已知的信息和掌握的业务流程进行一个前期的梳理，将一些不确定的，未定义清楚的内容提前准备好，再向产品组提出相关的需求。

优化型需求一般是随着业务的变化和迭代的推移而出现的，可能是业务流程改变了，也可能是当时有些没注意到的点被人发现了（但不是BUG），也有可能随着技术的发展有了更好的解决方案等……

优化型需求一般属于可做可不做型，做了会提升产品的用户体验，但是不做也能满足用户日常的一些需求，所以优化型需求的收集需要多考虑成本和收益。

如果此需求做了，成本很低，例如文案错误，去除首尾空格，UI调整，增加某个字段，增加一个导出字段，优化某些加载速度等等，它带来的收益可能不好估算但是肯定是具有积极意义的，那么这种需求可以当做第一种“BUG类需求”来简单处理，将相关的需求记录在Excel表中，然后统一规划推送给到开发和测试，同时如果此需求调整完成上线之后，要及时更新状态，如有必要，需要进行功能广播。广播的方式：邮件，微信群通知，私聊等。

如果此需求做了，成本很高，例如需要联动多方系统，多方部门；有些改动与原来的操作方式相比，增加了用户的学习成本；有些调整可能会带来不可预估的后果等。这个时候需要将需求列入需求池，如果提出的需求是其他业务部门，最好是让业务部门提交需求反馈表，当然如果内容不太复杂也可以直接由产品经理将需求列入需求池中。

此类需求列入了需求池之后，需要在每个迭代的需求收集时间结束之后进行需求排期评审会。

需求排期评审会主要的目的是将需求池中的需求进行优先级和重量性的排期，当然前提还得对需求的可行性和大逻辑进行判断。意味着，需求进入需求池，是会在此阶段进行打回或者枪毙的，有些需求的可行性仅靠产品一人无法解决，所以产品会先将此类需求当成可行性产品，然后在需求排期评审会上邀请开发，测试，业务等进行众评。评审本个迭代收集到的需求，然后将可行的，优先级高的，重要度高的列入到需求设计阶段。

输出需求池，需求池可以以月度或者季度等作为分隔，已完成的需求不会以一个已完成的状态持续在所有的需求池列表中；

需求排期计划，例如优先级A，重要性9的需求大概会在什么迭代进行需求设计，进行需求开发，什么迭代会上线等；

输出评审结果，将相关的进度和结论进行广播，让开发，测试，业务等干系人知道目前的进度和将来的安排；

以上需求的分类只是结合目前公司当下的业务和场景进行的，未来可能也会有相关的调整，同样也会有一些需求可能并不属于上面三种，如果未来这种需求多了，再以实际情况来进行二次分类吧。

至此，需求的收集流程和分类，似乎和网上各个大神、前辈发表的内容都差不多，但是我在进行相关写作的时候却想起来一个很实际的问题。那就是：

业务冷不丁的给你发了一个「需求反馈表」，但是你却没有看到或者你选择了无视怎么办？

这其实就是给未来的矛盾埋下了雷，业务过了不久跟你说我上次给你提的需求你做了吗？客户好像马上就要用这个了？系统能尽快上线吗？

所以这里我的建议和方案是：

业务提出的「需求反馈表」你很难要求他真的进行了所谓的“闭环思考”，或者他进行了“闭环思考”但是其实他自身认知有限，给出的东西还是如隔靴搔痒一样，仅仅是充当一个传话筒。所以接到需求邮件的第一件事就是回复邮件：需求已入需求池，我们将在xx日之前邀请您进行需求排期评审会，届时请准时参加。或者你可以直接性质的指出此需求有问题，还缺少什么，那么就在24小时内进行反馈，告知业务部门缺少的东西是什么，你要的东西是什么。

以上仅仅是第一步，但是也告诉我们，反馈是必须的且及时的。

以上内容都我先写在公司内部的WIKI中，然后再摘抄到本文中，所以其中提到的需求反馈表，TAPD等如果是内部人士都应该懂，如果不懂的可以自己百度或者自行理解。

上述的内容当然也有部分过分理想化，毕竟想让任何事情都能跟制定的规则一样发展是太奢侈了，所以以上内容随时会调整，这里只做一个抛砖引玉的功效。最后，不得不感慨一下，类似于这样的不确定的规章制度等，用WIKI写是真的最优解了。

如果你有更好的解决办法也欢迎留言指点，感谢阅读。