前面的博客中说到了需求分析，但往往经过需求采集、需求分析后的产品需求是很多的。
综合产品发布时间、人力资源、实现难度等各方面的因素，确认哪些需求做，哪些不做，哪些在本次发布版本中做，哪些在后续的版本迭代中做，就显得至关重要。
简单来说，就是确认需求的优先级；用一句话来讲：活下来的需求永远是少数。
首先，让我们给需求打个包吧。。。
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，最基本的素质就是：热爱产品。。。