按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
一般来说产品会议一个月一次，当然这和产品性质有关，如果你们公司的产品周
期比较长，那也可以两三个月一次。
当某个产品团队开始登场亮相的时候，一般要先回顾上一次产品会议通过的项目，
现在进展如何，是否需要调整时间进度、是否需要追加资源、是否有重大需求变更，
已经发布的项目有什么问题，等等。这样一方面是为了让大老板们更新对各个项目的
信息，更重要的是为了积累经验，让今后产品会议上的决策越来越合理。
回顾之后，就是最关键的部分了，我们会拿出准备好的商业需求文档，每个产品
都会拿出三五个，占满 2~3 倍的潜在资源。这里说的潜在资源，是指相对固定的开发、
测试人员，因为技术人员有对产品的熟悉问题，所以在短时间内，不可能太多的人同
时转去做其他产品，这也就意味着潜在的人力资源数量是在一个值附近做微小浮动的，
所以我们也可以认为，在一定程度上，资源的争夺是以产品间的争夺为辅，产品内多
个项目的争夺为主。很有意思的是，这三五个商业需求文档通常是产品团队里不同的
人做出来的，所以内部也会争夺得你死我活。
接下来的重头戏是一直提到的商业需求文档。
武器：商业需求文档
我们刚刚把需求打好包，接下来就要描述一下这个包了，这就是商业需求文档，
Business Requirement Document，简称 BRD，它也是我们参加资源争夺战的武器。
先看一下几个长得很像的词：BRD、MRD21、PRD22。按顺序来讲，这几个词是从
商业的描述渐渐过渡到对技术的描述。我经历的团队在实际操作中通常只写两种文档，
一个是给大老板们看的BRD，包含了BRD，以及MRD的部分内容；另一个是在项目中
写的PRD。
下面来聊聊我们的武器——BRD 怎么写，都包含哪些内容。
项目背景：我们在哪里？为什么要做这个项目，解决什么问题，可以列出一些数
据说明项目的必要性。
商业价值：我们去哪里？最关键的重点！大老板们最感兴趣的，做了这个项目以
后有什么价值，一定要说在点子上。一般我们还会预测一下相关数字的变化，提出这
个项目的商业目标。
功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打好包的需求描述
一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会
搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚
不好意思再砍我们真正想做的东西，这有点类似谈判技巧里的玩意，大家可以试试，
但不要在这上面太花心思了。
非功能需求描述：提一下重要的非功能需求，如果有的话。
资源评估：第二个重点！大老板们要看成本，他们在了解达成项目的目标需要多
大的花费以后，才能做出决策。
风险和对策：有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并
且给出自己的对策，说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定。而
且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突，这时候
提出来也是让老板们把一下关。
从 BRD 中的“商业价值”、“资源评估”两个重点中大家可能也发现了，其实本
质上大老板们也是在追求那个词——性价比。大家都希望花费最少的资源获得最大的
商业价值。
下面通过一个 BRD 的实例，再给大家讲一点直观的认识。
21 MRD：Market Requirement Document，市场需求文档。
22 PRD：Product Requirements Document，产品需求文档，在本书第 3。3。1 节的“产品需求文档，PRD”里有详细讲述。
首页，我们会给 BRD，也意味着将来的项目，起一个有意义的名字，再配上一幅
图，这样有助于团队的归属感，比如下面这个 BRD 叫“魔方计划”（如图 2…18 所示），
是因为这个项目打算将两个老产品整合为一个新产品，有点像魔方一样，通过打散、
组合，得到一个全新的结果。
图 2…18 魔方计划 PPT 的首页
商业价值（如图 2…19 所示），给老板们看他们最关心的指标，比如魔方计划就聚
焦在“活跃用户数”上。
图 2…19 魔方计划的商业价值
功能需求描述，这里给出了业务逻辑图（如图 2…20 所示），若能给出一些简单的
Demo 更好，让老板们提前看到产品完成后的样子，很可能成为争取资源的加分因素。
资源评估（如图 2…21 所示），我们会根据团队的实际情况，重点评估主要功能对
产品设计师、用户体验师、开发工程师的人力需求。
魔方计划 BRD
——老产品1 ＋ 老产品2
****事业部 苏杰
商业价值
。 “产品1”不差人，坐拥100万用户，10万活跃
用户，外加高速自然增长。
。 “产品2”不差钱，是公司今年的重头戏，投入
XX亿。
。 产品级的强强整合，利用“老产品1”的庞大用
户基数给“老产品2”快速带来更多的活跃用户
。 截至2009年底活跃用户数
– 铜牌10万、银牌15万、金牌20万
图 2…20 魔方计划的业务逻辑图
图 2…21 魔方计划的资源评估
BRD 转化为项目也并非一一对应，很可能老板会把多个 BRD 合并为一个项目，
或者把一个 BRD 拆成多个项目，或者直接砍碎了再重新组合，这都无所谓，不管怎么
说，产品会议开完以后，我们终于确定了接下来一段时间要做哪些需求了，准备启动
项目，迎接新的开始。
等等，我们还需要先安抚一下“被砍得遍体鳞伤”的兄弟们。
资源评估
PD UE 开发 测试
功能1 10 2 22
功能2 6 18 20
功能3 5 2 10
功能4 3 10 5
功能5 2 0 6
注：测试资源有保证，暂不评估
资源单位是“人天”
2。4。2 别灰心，少做就是多做
有 100 个需求，资源只够做 10 个，是的，当时就是这样。
一直都是这样。
2007 年国庆长假回来，我在全力做网店版“自动上架”的功能，简单解释一下：
淘宝为了防止一些没人打理的商品始终在搜索结果中，稀释了有效信息，所以所有商
品会隔一段时间后自动下架，不再被搜索到，这时就需要用户重新将商品上架。而网
店版的用户都是淘宝的优质卖家，所以我们给他们提供了一个“自动上架”的功能。
这是一个确定“怎么做”的过程，当时的体会能很好地表达我的想法，借用一下。
两个礼拜，整天的 PK、评审、确认，搞得头昏脑胀，不过终于算是把需求定下来了。
一个功能的多次需求会议中，必然有这样一个过程：开始对一个功能想得不完整，
说着说着大家都想把这个功能做得再强一点，这里加一点那里加一点，但后来通常因
为技术实现、资源等原因，又把这些加上去的功能点一个又一个地砍掉，甚至会发现
砍到最后和一个月前的第一次方案是一样的。看似白搭的这个过程其实是有用的，这
是一个“见山是山，见山不是山，见山还是山”的三段过程，对于那些加上又砍掉的
功能点，在第一个阶段我们根本没有想到，第二个阶段想到了，很兴奋，那就做吧，
而第三个阶段的砍掉是权衡了利弊之后的决定，和“没想到”是完全不同的。我们无
法绕过第一阶段的无知，也千万别停在中间那个功能点“大而全”的时候，必死无疑！
而第三阶段的“少做”则是超越第二阶段“多做”的“少做”，这才是真正的“多做”。
有很多文章谈到这样的思想，用 100％的质量去实现 75％的数量，而不是反过来！
吸引用户的往往只是功能模块中的一两个点，我们一开始只要让其拥有 100％的质量其
实就够了，这样留给用户的是升级的期待，而如果反过来，功能铺得很开，但每个点
都不爽，那反而喧宾夺主，把闪光的地方给掩埋了。
情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。越来越觉得
当发现一个功能可有可无的时候，甚至只要是没有强烈的理由要做的时候，要明确的
选择：不做！现在我们可以自我安慰了——少做就是多做！
最爽就是“四两拨千斤”
做得少不如做得巧。
第 2。3。1 节中我们提到满足需求有三种方式，其实就算“改变现状”这样一种最常
用的办法，也有很多“四两拨千斤”的方案。如果机会闪现，就千万不要放过，因为
做这样的事情实在太爽了，让我对下面这个故事过目不忘。
话说某跨国日化公司，肥皂生产线上面存在包装时可能漏包肥皂的问题。
于是该公司总裁命令组成了以博士牵头的专家组对这个问题进行攻关。该研发团
队使用了世界上最高精尖的技术（如红外探测、激光照射等），在花费了大量美金和半
年的时间后终于完成了肥皂盒检测系统，探测到空的肥皂盒以后，机械手会将空盒推
出去。这一办法将肥皂盒空填率有效降低至 5％以内。
问题基本解决。
再说某乡镇肥皂企业也遇到类似问题，老板命令初中毕业的流水线工头想办法解
决之；经过半天的思考，该工头拿了一台电扇到生产线的末端对着传送带猛吹，那些没
有装填肥皂的肥皂盒由于重量轻就都被风吹下去了。
这样做得更少，但是效果更好，至少性价比更高。当然，具体情况要具体分析，任何
事情总有它的两面，上例中乡镇企业的解决方案换到跨国公司的环境中，也许并不适用，
比如会造成肥皂盒无规律地四处翻滚，引起更大的问题，但我想表达的意思是：
我们用不着觉得只有“吃苦耐劳”，做了很多事情才是贡献，而应该