人人都是产品经理-第9章
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
曾经考虑过群体打分取均值等方式，可是实施起来成本太高，很难推动，也不是很有
必要。
初评需求的实现难度
绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商
业价值不大就不做。
我们现在知道了每个需求的商业价值，接下来决定做哪个还需要另一个关键指标，
那就是——实现难度。有时候我们会叫上技术人员代表参与需求讨论会，当场确定这
个指标，但更多的情况是留给做技术的同学一点时间，会后与相关的 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�
