重要性重要程度，辅助确定商业价值紧急度紧急程度，辅助确定商业价值持续时间持续时间，辅助确定商业价值商业价值(*)商业优先级，不考虑实现难度，群体决策重要性：可以参考时间管理里“重要与紧急”的概念。这里的重要度又可细分为：满足后“一般”到“非常高兴”；未实现“略感遗憾”到“非常懊恼”，更多可以学习 KANO 模型加深理解。紧急度：在时间维度上判断这个需求是否迫切，紧急不重要的需求通常表现为解决了短期的问题，如果熬过去没做，对长期影响不大；或者解决了局部的问题，如果不做对于大多数用户没有影响。比如某个用户是大老板的朋友，通过大老板“天外飞仙”地提过来一个需求，就很可能是一个超级紧急的需求，但重要性未必很高。持续时间：需求是有生命的，有的长寿有的短寿，比如迎合过年过节的运营活动需求，一般就比较短寿。试想 8 月我们录入了一个庆国庆的主题运营活动，如果到了 9月底还没资源做，那一年内也就不用再考虑这个需求了。商业价值，或者叫商业优先级，是对上述几种商业价值指标的综合评判。这一条是整个需求列表中最核心的部分，这里的判断直接影响着产品未来的方向。有时候我们还在列表里增加一列“商业价值描述”，通俗点就是这个需求的卖点是什么，可以给用户提供什么价值，对公司又有什么帮助。如此重要的商业价值评估，我们的做法是在需求讨论会上由产品团队集体讨论，再叫上有必要的干系人，比如销售、服务等。对于某个需求，需求提交人是对它最熟悉的，提交人先基于自己对商业目标的理解，做一番陈述，主观定个级别，比如高中低。然后大家讨论，所以在这个讨论会之前，每个人都应该做好功课。上述那么多的维度，可以加权平均得到综合的商业价值，我们甚至还尝试过在列表中增加“某关键人物的打分”一列，但绝大多数实际操作中，我们都是直接把商业价值抽象为一个指标，用“高、中、低”，或者“5、4、3、2、1”来衡量。而具体讨论的时候，大家充分表达意见之后，安全的做法是谁官大谁负责，俗称老板拍脑袋，最终由会场上级别最高的人报一个数字结束，这就是现实，也是一种高效的办法。我曾经考虑过群体打分取均值等方式，可是实施起来成本太高，很难推动，也不是很有必要。初评需求的实现难度绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做。我们现在知道了每个需求的商业价值，接下来决定做哪个还需要另一个关键指标，那就是——实现难度。有时候我们会叫上技术人员代表参与需求讨论会，当场确定这个指标，但更多的情况是留给做技术的同学一点时间，会后与相关的 PD 讨论确定。但实现难度这个词太难量化，所以在实际操作中我们会对它进行大刀阔斧的简化。首先简化为人力成本，即工作量，其他资源的消耗，比如额外的硬件成本，我们会发现只有极少数的需求会有这样的问题，不具有普遍性，所以碰到的时候都做特例处理。其次，我们把工作量再简化为开发量。我经历的项目，各类人力资源有：产品、开发、测试、服务等。但一般情况下，团队里产品人员资源相对富裕，测试资源可以调配，服务资源可以临时补充，所以开发资源经常成为瓶颈。于是，我们一般评估每个需求的开发工程师工作量来表征其实现难度，这背后的道理是以团队里的瓶颈资源为评估基准（如表 2-7 所示），大家视自己团队的情况灵活应用。表 2-7 需求的开发量需求属性属性说明开发量(*)需求的开发工作量，表征实现难度在这个时候，需求其实并不明确，只知道要做哪些，还是比较粗略的要点，而具体怎么做根本还没有考虑，所以有的技术人员会觉得无法评估开发量，这很正常，这个问题我们和技术人员纠结过许多次。他们说你们不明确每个需求怎么做，他们就无法准确评估开发量，我们说没那么多时间明确每个需求该怎么做，你们不评估每个需求的开发量，我们就不知道哪些值得进一步分析怎么做，而哪些又不值……于是就死循环了。这类先有鸡还是先有蛋的问题也无须纠缠，我们继续讲实际的。开发量是非评估不可的，我把它叫做“初评”，允许误差，并且会要经验丰富的人来评估，通常是技术经理，或者系统分析师、架构师。他们做出简单的评估，并且靠不断的实践来反复修正，评估者通常估计自己做这个需求要多少时间，然后乘以一个系数，这个系数大于 1，反映着相应技术团队的平均技术能力。这里的评估一般用“人天”作为单位，某个需求需要“1 人天”意味着需要 1 个人做 1 个工作日。相对于“初评”，在项目启动之后，制定项目开发计划的时候还会有一次更精确的评估，那时候需求怎么做已经知道、由哪位开发工程师来做也知道，所以可以推算出相对准确的工期，工期和工作量是有很大区别的，比如生一个小孩，需要 1 个女人10 个月的时间，工作量可以说“10 人月”，但 10 个女人 1 个月的时间，同样“10 人月”是绝对完成不了这个任务的，不管几个人，工期都只能是 10 个月……这个话题在第 3 章还有机会慢慢谈。性价比啊性价比我们已经做了需求采集，把用户需求转化为产品需求 ，知道了某个需求的基本属性、种类、商业价值、开发量，现在似乎应该开始写文档、干活了，但经验告诉我们不是这样的：绝对不能因为某个需求的实现难度很小就马上去做，也不能因为另一个需求的实现难度大就不做。一个实际的例子：我做过的某个产品页面的访客，在 2009 年某段时间内使用各种网页浏览器的比例如图 2-15 所示：第一名是微软的 IE，99.14%（其中 IE6.0 又占 75%）；第二名 Firefox，0.45%……图 2-15 某产品页面的浏览器使用情况对应的需求是：“产品页面在 Firefox 下显示有问题，比如……”，而我在注释里写道“对不起，我们就是不支持 Firefox”。当然，这句话是写给自己人看的，千万别对用户讲。这个需求实现难度不大，但一直在功能列表里放着没动，说实话，能在列表里出现的需求，严格意义上讲，没有任何一个是没有价值的，也没有任何一个是做不了的，那么到底先做哪个，后做哪个？就像早在第 2.1.1 节中就谈到的“不要试图满足所有用户”，一切皆看性价比。有了那么多的准备，现在我们只要做一道简单的小学算术题就可以回答上面的问题了。性价比 = 商业价值÷实现难度（简化为开发量）现在可以做决定了，我们把产品需求列表按照“性价比”一列从大到小排序，先做排在上面的就可以了（如表 2-8 所示）。表 2-8 需求的性价比需求属性属性说明性价比(*)“商业价值/开发量”，用于决定先做哪个但是工作中对“性价比”的判断还是会经常有偏差，很实际的一个原因，是自己经常和哪类人接触。2007 年下半年的工作中，由于一直和工程师直接接触，经常听到他们抱怨某个需求太麻烦之类的，所以综合考虑时有点倾向于做实现难度小的；而如果经常和销售、运营的同学一起开会，就会倾向于更多的考虑商业价值，这点与大家共勉，时刻注意。道理说完了，对需求的 DNA 检测也暂告一个段落，接下来我们将迎来一场残酷的“战争”。2.4 活下来的永远是少数2008 年春。每个月来一次的，除了账单，还有那场“战争”。虽然活下来的永远是少数，但我越来越觉得，为了我们的产品，有些需求死得其所。这是一场公司内部的战争，每个产品的产品经理都要上场，打仗总是为了抢点什么，我们争夺的是下个月的人力资源，即总是不够用的开发工程师、测试工程师等。战场就是闻之色变的产品会议，而我们手上的武器，则是精心准备的商业需求文档。这个过程，就是需求筛选，如图 2-16 所示，也有个很传神的说法：需求 PK。图 2-16 需求筛选2.4.1 永远忘不掉的那场战争为什么原来没有这样的战争？我没找到理论支撑，但就个人经历和与同事的交流来说，下面是一个因素：更早的时候，公司是按照产品线划分部门的，对于某个产品来说，有自己的产品设计师、开发与测试等，下一段时间要做哪些需求，完全可以在产品经理的层面上决定，所以就算有战争也是部门内部的，比较温和，基本上在分析商业价值的需求讨论会上，也就顺带着确定了下一段时间做哪些。为什么现在有战争了？2008 年初，公司组织结构调整，变成了按职能线划分团队，有了统一的产品中心，包括所有的产品经理和设计师；研发中心，包括所有的开发工程师、架构师等；质控中心，包括所有的测试工程师……这样的话，每个产品还是由原来的产品人员做，但是开发与测试资源在一定程度上就有了流动的可能。每个产品想做的需求都很多，所以都想尽可能多地抢到开发与测试的资源，然而人力资源总是严重不足的，所以最终把资源投给哪个产品，就必须上升到几个中心的大老板层面来决定了，而大老板的决策依据就是各个产品团队制作的商业需求文档。其实，后来我们又经历过几次反复，部门总是一会按产品线划分、一会按职能线划分，这让我忍不住也对这个问题给出点自己的解释。按产品线划分的团队对产品本身是有利的，产品经理权力更大，可以按照自己的想法做，资源有保证，产品规划不容易被动改变。此外，各种职能的员工之间沟通顺畅，单线领导，开发的头、测试的头等都向产品经理负责。按职能线划分的团队对多个产品间的资源共享有利，可以让资源流向更需要的地方，保证对核心产品的投入，但是效率不高，由于产品规划的决策需要在更高层面上敲定，单个产品的发展速度会有所降低。此外，资源战争可以把“鲶鱼效应 18”从产品内部扩大到公司层面，使产品经理和设计师们更抓狂地为产品的发展而苦苦思索，这是一件好事。18 鲶鱼效应即采取一种手段或措施，刺激一些企业活跃起来投入到市场中积极参与竞争，从而激活市场中的同行业企业。其实质是一种负向激励，是激活员工队伍之奥秘。两种组织结构，给我“一攻一守”的感觉，产品在创业期的时候，需要全速发展，必然是产品线结构，产品经理带头往前冲。而当公司里有多个产品慢慢成熟之后，就多用职能线来更充分地利用资源，因为在成熟的产品团队中，要做的事情通常比创业时期少，或者说没那么急，那么各种资源就显得有富裕，可以更加的稳扎稳打，所以按职能线划分以实现资源共享，同时还可以促进不同产品团队之间的互相学习，让员工的个人能力得到更多的提升。更多有关组织结构的话题，将在第 4.1.3 节“团队之大”与大家讨论，到时候再见。准备出发：把需求打个包上战场之前，就像战士要把自己的物品打包一样，需求也要打包。我们现在来解决这个包有多大的问题，即某个将来的潜在项目里，到底应该包括多少需求的问题。这里不得不提前谈一点项目管理的内容了。做项目，终极目标就是：多快好省 19，即范围大、时间短、品质高、资源省。19 “多快好省”对比经典的项目 TRQ：项目时间（Time）、项目资源（Resource）、项目质量（品质 Quality 和数量Quantity），大同小异。20 敏捷方法，一种项目管理方法，在本书第 3.5.3 节“敏捷更是手段”里有相关描述。但又要马儿跑又想马儿不吃草的事情是没有的，所以我们通常是在上述 4 个要求中做平衡。我经历的互联网、软件项目，比较推崇敏捷方法 20，所以有比较固定的项目时间，专业点叫“迭代周期”，一般是 2~4 周。然后有一个人员相对固定的团队，意味着项目资源确定，此外任何时候都要保证项目品质，最后能变的只能是量——项目范围。继续，我们有了项目时间长短，也就意味着可以按经验的比例估计出留给开发的时间有几天，然后团队里有多少开发工程师也是知道的，所以我们可以直接算出有多少“可用工作量”，同样以“人天”为单位。还记得我们把产品需求列表按照“性价比”从大到小排序过了么？从上往下看，每一行后面都还对应着一个“工作量”，现在我们只要做一个简单的加法，一行又一行地从上到下依次纳入项目，能做多少，一目了然，我们把这个动作叫“需求打包”，而对这些需求的整体描述，也就是商业需求文档里的功能说明了。当然，这只是一个基准，可变因素很多。我们每次产品会议都要准备好几个项目让大老板们选，每个项目也有可能在产品会议上被砍掉部分需求，所以可以先相对随意地超出“可用工作量”。这个过程完全定量地回答了“做多少”的问题。但，真实情况哪会这么简单明了，就像课本里总是给出一个简单到不真实的例子，然后再告诉你还有很多特例，而到了实际操作中，你会发现又要复杂很多，没办法，大家都尽力吧，让每个项目的大小相对靠谱，下面说几个需要注意的地方。第一，“需求打包”最好打包类似的功能点。是否类似取决于需求的基本属性，这是“确定需求的基本属性”那一节里做的事情。一般来说业务上逻辑关系密切的需求才会包含在一个项目里，这也很好理解，否则就是一个纯粹修修补补的“小需求项目”了。实际操作中打包多大，更多的是取决于这一点。更好的方式是，需求在打包以后，通过业务逻辑图的方式可视化，可以更直观地给别人讲解如图 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 节中我们提到满足需求有三种方式，其实就算“改变现状”这样一种最常用的办法，也有很多“四两拨千斤”的方案。如果机会闪现，就千万不要放过，因为做这样的事情实在太爽了，让我对下面这个故事过目不忘。话说某跨国日化公司，肥皂生产线上面存在包装时可能漏包肥皂的问题。于是该公司总裁命令组成了以博士牵头的专家组对这个问题进行攻关。该研发团队使用了世界上最高精尖的技术（如红外探测、激光照射等），在花费了大量美金和半年的时间后终于完成了肥皂盒检测系统，探测到空的肥皂盒以后，机械手会将空盒推出去。这一办法将肥皂盒空填率有效降低至 5%以内。问题基本解决。再说某乡镇肥皂企业也遇到类似问题，老板命令初中毕业的流水线工头想办法解决之,经过半天的思考，该工头拿了一台电扇到生产线的末端对着传送带猛吹，那些没