需求筛选

前面的博客中说到了需求分析，但往往经过需求采集、需求分析后的产品需求是很多的。

综合产品发布时间、人力资源、实现难度等各方面的因素，确认哪些需求做，哪些不做，哪些在本次发布版本中做，哪些在后续的版本迭代中做，就显得至关重要。

简单来说，就是确认需求的优先级；用一句话来讲：活下来的需求永远是少数。

首先，让我们给需求打个包吧。。。

 

1、需求打包

做项目，终极目标就是：多快好省，对比经典的项目TRQ：项目时间Time、项目资源Resource、项目质量（品质Quality和数量Quantily）。

即：范围大、时间短、品质高、资源省。

但通常都需要在上面的四个要求中做平衡，一般的互联网产品，比较推崇敏捷方法，都有比较固定的“迭代周期”。

那么问题来了：本次的版本迭代，迭代范围是什么？可以从以下三个方面考虑：

①最好打包成类似的功能点

是否类似取决于需求的基本属性，一般来说业务逻辑关系密切的需求会包含在一个项目里；打包之后，可以通过业务逻辑图的方式可视化，更好的给别人讲解。

PS：这里所说的“业务逻辑图”，可以理解为我们常说的思维导图。

②需求依赖，功能之间有依赖关系

哪些功能点需要优先去做，需要在需求列表中注明。功能与人力资源之间的依赖关系也会经常存在，比如某个功能只有团队中某个人才能实现。

在项目立项后就需要评估工作量，最好的方式组建项目团队时候就重点考虑，或者提前培养提升团队成员的能力才是王道。

③需求的粒度

之前说过每个产品都有自己的价值，需求商业价值很高的功能，如果细分会发现其中也有价值相对较低的部分，所以需求的粒度要尽量细，前提是细化引起的管理成本在可接受范围内。

具体来说，需求的粒度大小，需要根据具体情况来划分，前提是在资源成本等的可接受范围内。

然后，就要开始产品会议了，或者换个词语来说，产品立项，这个词比较合适（决定做或者不做，做什么）。。。

 

2、需求文档

说到需求文档，这个对我个人来说是个痛点，因为之前甚至现在的公司，不靠谱的产品经理+没头绪的需求文档，让人欲仙欲死。。。

需求文档的作用，就是在产品会议这种决定生死的战场上的武器，需求文档，常见的有以下几种：

BRD：Business Requirement Document，商业需求文档，这种文档一般都是给BOSS看的。

MRD：Market Requirement Document，市场需求文档，一般是交给运营、市场、营销等部门的。

PRD：Product Requirement Document，产品需求文档，也就是产品、技术部门需要的文档，一般都是产品、技术部门的一起做需求讲解、需求评审等。

这三种文档，也是从商业的描述渐渐过渡到技术的描述。

下面说说BRD的一些内容：

项目背景：为什么做这个项目，解决什么问题（可以罗列一些数据说明项目的必要性）；

商业价值：这个项目的价值是什么？商业目标是什么？

功能需求描述：通过作哪些事情达到目标，把打包好的需求描述一下，可以用功能列表的形式表达，最好能画出业务逻辑关系等；

非功能性需求描述：可以提及一下重要的非功能性描述；

资源评估：人力成本、时间成本、资金成本等，这也是最重要最实质的东西；

风险和对策：任何项目都存在风险，所以需要提出来，从不同的角度层次来讨论解决；

上面几点中，商业价值和资源评估，本质上就是所有人追求的一个词——性价比。

 

3、少做就是多做

①少做就是多做

产品立项后，往往面临这样一个问题：有100个需求，资源只够做10个，现实往往就是如此残酷。

所以，宁愿把做了一半的功能尽可能做完美，也不要把全部功能做的半吊子；要学会安慰自己——少做就是多做！

②学会四两拨千斤

之前的博客中提到过满足需求的三种方式，其中有“提高现实”这个方式，想办法少做，做好，使性价比更高。

但大多数产品经理都会犯的一个错误就是：很努力的做错误的事情！

有句话这么说：内部（偏技术）的大改动往往是外部（偏商业）的小改动，反之亦然；应该在动手前找找成本更低、效果更好的解决方案，学会四两拨千斤。

③尽可能多的放弃

之前在需求采集的模块中，说到了“尽可能多的采集”，而在需求筛选和立项时候，要“尽可能多的放弃”。

看似矛盾，实际上正反映了认知事物的过程。只有在需求采集阶段没有遗漏，才可能完整的看到事物的全貌，有大局观，放弃的时候材质奥孰重孰轻，下得了手。

前支付宝产品设计师白鸦曾经写过一个例子：如果不能做到放弃，最终会被自己折腾死，感兴趣的童鞋可以去白鸦的博客看看。

 

4、一个需求的生老病死

没有完美的产品，在产品的声明周期中，其一直重复着需求采集、需求分析、需求筛选的过程，不断进化。所以需要谨记一点：心急吃不了热豆腐。

上篇博客有说到，给需求做一个：“DNA检测”，一个需求必备的DNA属性，有如下几点：

需求状态：通常有待讨论、拒绝、暂缓、需求中、开发中、已完成几个状态，可根据实际情况有所增减；

负责PD：在需求状态变为“需求中”时指定，是此需求的提交人，在需求的声明周期中，此人要一直跟进，是这个需求的主人；

开发工程师：负责这个需求的技术实现，以及将来可能的缺陷解决；其他如测试工程师、项目经理，可视情况决定是否填写；

项目名称：辅助信息，用来筛选某个项目的需求；

发布时间：辅助信息，用来查看某段时间发布的需求；

备注：其他任何信息都可以填入这里，如：需求被暂缓、拒绝的理由和重启条件，其他相关内容等；

PS：需求的生老病死，可以参考下图：

 

到这里，关于需求的内容告一段落，接下来，会记录一些关于项目管理等方面的内容；最后，作为一个PM，最基本的素质就是：热爱产品。。。