做项目的终极目标就是多快好省，即范围大、时间短、品质高、资源省。但又要马儿跑，又要马儿不吃草的事情是没有的，所以我们通常是在上述四个要求中做平衡。一般采取敏捷方法，有比较固定的迭代周期，一般是二到四周；有一个人员相对固定的团队，即项目资源确定；此外任何时候都要保证项目品质，最后能变的只能是量，项目范围。
当有了项目时间长短，可以按经验的比例，估计出留给开发的时间有几天，团队里有多少开发工程师也是知道的，所以可以直接算出有多少可用工作量，同样以人天为单位。之前把产品需求列表按照性价比从大到小排序过，从上往下看每一行后面还都对应着一个工作量，现在只要做一个简单的加法，一行又一行的从上到下，依次纳入项目，能做多少一目了然。这个动作叫做需求打包。
而对这些需求的整体描述，也就是商业需求文档里的功能说明。当然了这只是一个基准，可变因素非常的多，所以每次产品会议都要准备好几个项目让大老板们选，每个项目也有可能在产品会议，被砍掉部分需求，所以可以先相对随意的超出可用工作量。
需求打包几个需要注意的地方：
第一，需求打包最好打包类似的功能点，是否类似取决于需求的基本属性，一般来说，业务上的逻辑关系密切的需求才会包含在一个项目里，这也很好理解啊，否则就是一个纯粹修修补补的小需求项目了。实际操作中，打包多大，更多的是取决于这一点。更好的方法是需求在打包以后通过业务逻辑图的方式实现可视化，可以更直观的给别人讲解。
第二，需求依赖，功能之间互相有依赖关系，那些只能先做的功能，应该在产品需求列表里注明，功能与人力资源之间的依赖关系，也会经常存在。比如有些功能只能由团队里的特定人员来做，在这里评估工作量的时候不会考虑谁来做的问题，在正式立项以后，组建团队的时，候会重点考虑，当然长期来说为了避免这类风险，提升与平衡团队成员的力才是王道。
第三，需求的力度大小问题。
商业价值很高的功能，如果细分的话，会发现其中也有价值相对低的部分，所以需求的力度应该尽量细，前提是细化引起的管理成本上升，也在可接受的范围内。比如大开间办公区里的灯，不太可能用一个开关控制，也不可能每个开关只能控制一盏灯，具体细掉多少要根据具体情况具体分析，在需求列表里出现的任意一行，工作量最好不要超过五人天。
一般来说，产品会议一个月一次，当然这和产品性质有关。如果产品周期比较长，那也可以两三个月一次。当某个产品团队开始登场亮相的时候，一般要回顾上一次的产品会议通过的项目现在进展如何，是否需要调整时间进度，是否需要追加资源，是否有重大需求变更，已经发布的项目有什么问题？这样一方面是为了让大老板们更新对各个项目的信息，更重要的是为了积累经验，让今后产品会议上的决策越来越合理，回顾之后就是最关键的部分，拿出准备好的商业需求文档。每个产品都会拿出三五个，占满二到三倍的潜在资源，这里说的潜在资源是指相对固定的开发测试人员，因为技术人员有对产品的熟悉问题，所以在短时间内，不可能太多的人同时转去做其他产品，这也就意味着潜在的人力资源数量是在一个值附近做微小浮动的。所以我们也可以认为，在一定程度上，资源的争夺是以产品间的争夺为辅，产品内多个项目的争夺为主。很有意思的是，这三五个商业需求文档，通常是产品团队里不同的人做出来的，所以内部也会争夺的你死我活。
接下来的重头戏是一直提到的商业需求文档，刚刚把需求打好包，接下来就要描述一下这个包了。这就是商业需求文BRD。它是参加资源争夺战的武器。BRD、MRD、PRD这几个词是从商业的描述，渐渐过渡到对技术的描述。我经历的团队在实际操作中通常只写两种文档，一个是给大老板们看的BRD，包含了BRD以及MRD的部分内容。另一个是在项目中写的PRD。
BRD怎么写都包含哪些内容呢？项目背景、我们在哪里？为什么要做这个项目？解决了一个什么问题，可以列出一些数据说明项目的必要性、商业价值，我们去哪里。最关键的重点，做这个项目有什么价值，预测一下相关数字的变化，提出这个项目的商业目标功能需求描述。（非功能需求描述：通过做哪些事情来达到目标，把打包好的需求描述一下，可以通过功能列表的形式表达，但最好画出业务逻辑关系。）
资源评估第二个重点，大老板们要看成本，他们在了解达成项目的目标需要多大的花费以后才能做出决策。有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并且给出自己的对策。说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定了。而且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突。这时候提出来也是让老板们把下关。
BRD转化为项目也并非一一对应，很可能老板会把多个BRD合并为一个项目。或者把一个BRD拆成多个项目，或者直接砍碎了再重新组合，这都无所谓。不管怎么说产品会议开完以后，终于确定了接下来一段时间要做哪些需求了，准备启动项目迎接新的开始等等啊。当发现一个功能可有可无的时候，甚至只要没有强烈的理由要做的时候，要明确的选择不做。如果不放弃最终会被自己折腾死。比如，一个最简单的评论功能，既然可以发评论，那么是不是需要改评论？删评论？发的权限是否要管理员设置？那么改的权限呢？删的权限呢？是否可以引用别人的评论？评论被人引用了，是否可以再改？如果可以改，那么是不是要保留修改记录。如果管理员改了一个评论，那么作者是不是不能再改，评论是否要有数量和时间限制？评论要不要翻页？如果要翻页，是在本页翻，还是打开新页？评论能不能带图片？带了图片，那么是不是能上传？能上传之后是不是要删除？是不是要提供自定义评论顺序？需求越来越多让人崩溃。