永远忘不掉的那场战争

时期少，或者说没那么急，那么各种资源就显得有富裕，可以更加的稳扎稳打，所以

19 “多快好省”对比经典的项目 TRQ：项目时间（Time）、项目资源（Resource）、项目质量（品质 Quality 和数量 Quantity），大同小异。

20 敏捷方法，一种项目管理方法，在本书第 3.5.3 节“敏捷更是手段”里有相关描述。

第一，“需求打包”最好打包类似的功能点。是否类似取决于需求的基本属性，

这是“确定需求的基本属性”那一节里做的事情。一般来说业务上逻辑关系密切的需 求才会包含在一个项目里，这也很好理解，否则就是一个纯粹修修补补的“小需求项 目”了。实际操作中打包多大，更多的是取决于这一点。更好的方式是，需求在打包 以后，通过业务逻辑图的方式可视化，可以更直观地给别人讲解

如图 2-17 所示，是我在 2009 年春做的一个项目的业务逻辑图，因为涉及一些商 业问题，所以图中有些关键词隐去了。

图 2-17 魔方计划的业务逻辑图

第二，需求依赖，功能互相之间有依赖关系。那些只能先做的功能，应该在产品 需求列表里注明；功能与人力资源之间的依赖关系也会经常存在，比如有些功能只能 由团队里的特定成员来做。在这里评估工作量的时候不会考虑“谁来做”的问题，在 正式立项以后，组建团队的时候会重点考虑，当然长期来说，为了避免这类风险，提 升与平衡团队成员的能力是王道。

第三，需求的粒度大小问题。商业价值很高的功能，如果细分的话，我们会发现 其中也有价值相对低的部分，所以需求的粒度应该尽量细，前提是细化引起的管理成 本上升在可接受的范围内，给个生活中的例子帮助理解：大开间办公区域里的灯，不 可能用一个开关控制，也不可能每一个开关只控制一盏灯。具体细到多少，要根据具 体情况具体分析。我们的经验是，在需求列表里出现的任意一行，工作量最好不要超 过“5 人天”。

战场：产品会议

需求打包完成了，战争就要打响了。

某天，各个部门的老板们都聚集到一个大会议室，准备待上一整天。各个产品的 产品经理和设计师们等着被轮流召唤，当然如果你有空且愿意，也可以旁听一整天。

其实对资源的争夺，在部门内讨论商业价值的时候已经预演过了，通常来说每个人都 会尽力为自己提出的需求说好话，毕竟实现自己想法的感觉总是好过帮别人实现想法。

一般来说产品会议一个月一次，当然这和产品性质有关，如果你们公司的产品周 期比较长，那也可以两三个月一次。

当某个产品团队开始登场亮相的时候，一般要先回顾上一次产品会议通过的项目，

现在进展如何，是否需要调整时间进度、是否需要追加资源、是否有重大需求变更，

已经发布的项目有什么问题，等等。这样一方面是为了让大老板们更新对各个项目的 信息，更重要的是为了积累经验，让今后产品会议上的决策越来越合理。

回顾之后，就是最关键的部分了，我们会拿出准备好的商业需求文档，每个产品 都会拿出三五个，占满 2~3 倍的潜在资源。这里说的潜在资源，是指相对固定的开发、

测试人员，因为技术人员有对产品的熟悉问题，所以在短时间内，不可能太多的人同 时转去做其他产品，这也就意味着潜在的人力资源数量是在一个值附近做微小浮动的，

所以我们也可以认为，在一定程度上，资源的争夺是以产品间的争夺为辅，产品内多 个项目的争夺为主。很有意思的是，这三五个商业需求文档通常是产品团队里不同的 人做出来的，所以内部也会争夺得你死我活。

接下来的重头戏是一直提到的商业需求文档。

武器：商业需求文档

我们刚刚把需求打好包，接下来就要描述一下这个包了，这就是商业需求文档，

Business Requirement Document，简称 BRD，它也是我们参加资源争夺战的武器。

先看一下几个长得很像的词：BRD、MRD²¹、PRD²²

21 MRD：Market Requirement Document，市场需求文档。

22 PRD：Product Requirements Document，产品需求文档，在本书第 3.3.1 节的“产品需求文档，PRD”里有详细讲述。

。按顺序来讲，这几个词是从

首页，我们会给 BRD，也意味着将来的项目，起一个有意义的名字，再配上一幅 图，这样有助于团队的归属感，比如下面这个 BRD 叫“魔方计划”（如图 2-18 所示），

是因为这个项目打算将两个老产品整合为一个新产品，有点像魔方一样，通过打散、

组合，得到一个全新的结果。