人人都是产品经理-第13部分

按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！


让大老板们选，每个项目也有可能在产品会议上被砍掉部分需求，所以可以先相对随　
意地超出“可用工作量”。　
这个过程完全定量地回答了“做多少”的问题。但，真实情况哪会这么简单明了，　
就像课本里总是给出一个简单到不真实的例子，然后再告诉你还有很多特例，而到了　
实际操作中，你会发现又要复杂很多，没办法，大家都尽力吧，让每个项目的大小相　
对靠谱，下面说几个需要注意的地方。　


第一，“需求打包”最好打包类似的功能点。是否类似取决于需求的基本属性，　
这是“确定需求的基本属性”那一节里做的事情。一般来说业务上逻辑关系密切的需　
求才会包含在一个项目里，这也很好理解，否则就是一个纯粹修修补补的“小需求项　
目”了。实际操作中打包多大，更多的是取决于这一点。更好的方式是，需求在打包　
以后，通过业务逻辑图的方式可视化，可以更直观地给别人讲解　
如图　2…17　所示，是我在　2009　年春做的一个项目的业务逻辑图，因为涉及一些商　
业问题，所以图中有些关键词隐去了。　
图　2…17　魔方计划的业务逻辑图　
第二，需求依赖，功能互相之间有依赖关系。那些只能先做的功能，应该在产品　
需求列表里注明；功能与人力资源之间的依赖关系也会经常存在，比如有些功能只能　
由团队里的特定成员来做。在这里评估工作量的时候不会考虑“谁来做”的问题，在　
正式立项以后，组建团队的时候会重点考虑，当然长期来说，为了避免这类风险，提　
升与平衡团队成员的能力是王道。　

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

战场：产品会议　

需求打包完成了，战争就要打响了。　
某天，各个部门的老板们都聚集到一个大会议室，准备待上一整天。各个产品的　
产品经理和设计师们等着被轮流召唤，当然如果你有空且愿意，也可以旁听一整天。　
其实对资源的争夺，在部门内讨论商业价值的时候已经预演过了，通常来说每个人都　
会尽力为自己提出的需求说好话，毕竟实现自己想法的感觉总是好过帮别人实现想法。　
一般来说产品会议一个月一次，当然这和产品性质有关，如果你们公司的产品周　
期比较长，那也可以两三个月一次。　
当某个产品团队开始登场亮相的时候，一般要先回顾上一次产品会议通过的项目，　
现在进展如何，是否需要调整时间进度、是否需要追加资源、是否有重大需求变更，　
已经发布的项目有什么问题，等等。这样一方面是为了让大老板们更新对各个项目的　
信息，更重要的是为了积累经验，让今后产品会议上的决策越来越合理。　
回顾之后，就是最关键的部分了，我们会拿出准备好的商业需求文档，每个产品　
都会拿出三五个，占满　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　节中我们提到满足需求有三种方式，其实就算“改变现状”这样一种最常　
用的办法，也有很多“四两拨千斤”