这一节主要总结一下苏杰在书中的第2.4节和2.5节的内容。
需求PK在一个互联网公司里面是再常见不过的事情了。PK赢了，那么你的产品就可以立项上马，如果输了，那么别人的产品上了。你呆一边去。
产品需求刷选主要包含：需求打包，BRD制作，产品会议，如果通过则进行立项。
1 准备出发：把需求打个包
我们 产品要实现，在公司内部是要作为一个项目来实现它的。而项目追求的是多快好省的完成任务，这个在后面的章节我们会讲到。所以，你提的需求，一般来说不会给你机会全部去实现的。所以你需要对需求进行排序，选择，打包。
做项目，终极目标就是：多快好省，就是范围大，时间短，品质高，资源省。我们需要在这四个资源上进行平衡，现在比较推崇的项目方法是敏捷开发方法。项目时间一般是固定的，专业点叫“迭代周期”，一般是2-4周；团队相对固定，所以项目资源是固定的。然后，任何时候都应该保证产品的质量。所以，最后你会发现只剩下“量”能变化----项目范围。
我们之前说过一个需求的性价比（商业价值/成本），然后根据性价比进行排序，然后确定项目执行的范围。有些需求只能在后续的版本中持续增加。我们把挑选需求出来的过程叫“需求打包”。
总体原则是按照性价比来打包，但需要注意如下节问题。
1）“需求打包”最好打包类似功能点。什么是类似的功能点，这个一般在业务逻辑上紧密相关的，根据需求的基本属性就可以识别出来。不难。
2）需求依赖。功能之间是有依赖关系的，这种情况只能是先做被依赖的，还有一种是功能对人员的依赖。比如你要写一个特别难的模块，整个项目就某个大神会，那么就有人员依赖，这个也是个需要考虑的问题。最好就是让整个开发团队能力都不断增强。
3)需求粒度的问题。一个复杂的需求总是可以不断的细分的，但是分到什么合适。一般来说一个需求的工作量不要超过5人天，否则就很难控制。
2 战场：产品会议
产品会议是一帮老大来分配资源给产品经理的会议。一般是一个月一次。会议的一开始一般是先回顾上一次产品会议通过的项目，现在的进度如何，是否需要调整时间进度，是否需要追加资源，是否有重大的需求变更，已经发布的产品遇到了什么问题。这种回顾是非常有必要的，一方面让各位老大更新对这个产品项目的认识，更重要的是积累经验，为今后产品会议上的决策越来越合理。
回顾玩之后就是拿我们的商业需求文档来将给各位大佬听，抢夺资源。。一般资源是一个产品内的不同项目进行抢夺。因为开发很少会说老在不同的产品之间切换，他需要熟悉产品呢。
3 武器：商业需求文档
BRD： Business Requirement Document，商业需求文档。
MRD： Market Requirement Document ，市场需求文档。
PRD: Product Requirement Document ，产品需求文档。
BRD怎么写？
项目背景：我们在哪里？为什么要做这个项目，解决什么问题，必要的时候列举一些数字来说明项目的必要性。
商业价值：我们去哪里？这是最重要的关键点，做了这个项目之后会产生什么价值，预测一下数字，说一下商业目标。大佬最喜欢的。
功能需求描述：我们怎么去？我们需要通过做哪些事情来达到目标。把打包好的需求描述一下，可以用“功能列表”，最好能够画出业务逻辑关系。
非功能需求描述：比如一些性能等等方面的。
资源评估：第二个重点，主要是人力，其他资源。
风险和对策：
4 一个需求的生老病死
需求状态： 待讨论，拒绝，暂缓，需求中，开发中，测试中，已完成。
需求管理，
做好各项统计工作。比如统计时间，数量等。
（完）
