按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
用户数增加 10 倍的情况下，硬件投入必须小于 10 倍”，这是一个可扩展需求；“此
功能的用户操作日志需要记录”，这是一个内部数据分析的需求。
当然，对于一些边缘的需求，是列入这个表格统一管理，还是另外单独对付，这
可以随机应变。
通常来说“产品功能需求＋产品非功能需求 = 产品需求”，而“产品需求＋市场需
求＋开发需求＋测试需求＋服务需求＋…… = 产品包需求”，对这些概念感兴趣的同学
可以去查阅“需求管理”相关的资料。
层次：把需求分成“基础、扩展（期望需求）、增值（兴奋需求）”三层，理论
依据参见KANO模型 17。
小明：“我想到一个手机的例子，打电话、发短信是基本功能；给电话录音是扩
展功能，和基本功能相关；而如果这个电话特别结实，可以当锤子砸钉子，或者当砖
头防身，那就是增值功能了。”
大毛：“嗯，好多山寨手机的特点就在于满足了一些诡异的增值需求，比如可以
当手电筒、当验钞机、当剃须刀……”
小明：“你是在夸还是在贬呢？”
大毛：“我也不知道，那些已经超出普通手机的范畴了……”
对需求种类的区分其实没那么绝对，取决于很多因素，比如商业目的变了，某个
功能的分类也就变了，我自己经常从“雪中送炭”还是“锦上添花”的角度去理解：
雪中送炭是基本功能，对用户很有用，产品缺了这个功能根本跑不起来，比如 E…mail
系统里的“收发邮件”；锦上添花的功能是指非必须的，用户有时用得到，有的话会给
用户的使用带来方便，比如在发 E…mail 填写收件人的时候，系统根据你输入的内容自
动提示你曾经发送过邮件的联系人，就像图 2…14。
17 KANO 模型以东京理工大学教授狩野纪昭（Noriaki Kano）的名字命名，是一种对顾客需求或者说对绩效指标的
分类，通常在满意度评价工作前期作为辅助研究模型，KANO 模型的目的是通过对顾客的不同需求进行区分处
理，帮助企业找出提高企业顾客满意度的切入点。
图 2…14 Gmail 的收件人提示功能
我们在和用户接触的过程中会很明显地感受到这两种需求的不同，没有雪中送炭
的功能就像系统有缺陷一样，所以应优先考虑。而当一个锦上添花的功能被用户普遍
接受以后，几乎所有的产品也都拥有了，也就渐渐发提升为雪中送炭的功能了，就像
现在的手机，几乎没有人能接受黑白屏一样，当初彩屏可是作为一大卖点来宣传的。
分析需求的商业价值
一个公司做任何产品，一个产品做任何需求，最终都是要满足一定的商业目的，
所以“需求的商业价值”是最关键的内容，有条件的团队最好利用群体智慧，我们通
常在这个时候举行“需求讨论会”。
正因为商业价值如此重要，所以最复杂的时候我们尝试过用重要性、紧急度、持
续时间 3 个指标来衡量，如表 2…6 所示。
表 2…6 需求的商业价值
需求属性
属性说明
重要性
重要程度，辅助确定商业价值
紧急度
紧急程度，辅助确定商业价值
持续时间
持续时间，辅助确定商业价值
商业价值（*）
商业优先级，不考虑实现难度，群体决策
重要性：可以参考时间管理里“重要与紧急”的概念。这里的重要度又可细分为：
满足后“一般”到“非常高兴”；未实现“略感遗憾”到“非常懊恼”，更多可以学
习 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”。当然，这句话是写给自己人看的，千万别对用
户讲。
这个需求实现难度不大，但一直在功能列表里放着没动，说实话，能在列表里出
现的需求�