按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
名称（*）
用简洁的短语描述需求
描述（*）
需求描述：无歧义、完整性、一致性、可测试等
提出者
即需求的原始提出者，有疑惑时便于追溯
提出时间
原始需求的获得时间，辅助信息
Bug 编号
将一些 Bug 视为需求，统一管理
编号：看似作用不大，最初表格中没有这一项，但有一次大家把列表打印出来讨
论，当提到某个需求的时候，发现很难告诉大家是哪个，因为 Excel 的行号没有一并打
印出来，所以后来我们都把序号加上了，作为需求的唯一性标识。有时候在某个需求
的备注里，也会写“与 273 号需求类似，可以参考”。
提交人：必填，提交人是 PD，我们的需求管理方法比较轻量级，更多的是只管理
产品需求，而用户需求并没有很好的整理，经常只是一堆各种格式的文档，所以提交
人要负责在今后的任何时候解释这个需求的来源，提交人有义务充分理解原始的用户
需求。
提交时间：这是一个辅助信息，记录提交人是何时录入这个需求的。
模块：一般来说，根据人类记忆的特点，产品有 5±2 个模块比较合理，如果超过
7 个，你就要考虑重新划分，甚至增加一个基本属性叫“二级模块”。如果你是做网站
产品，这些模块的划分就很可能影响到网站的导航结构，这属于信息架构 16领域的知
识。当然，在设置自己电脑里的文件目录结构时，也可以遵循这个原则。
举个例子，如图 2…13 的网店版菜单结构，就可以从其产品需求列表里的“模块”
设置里看出来。
16 信息架构（Information Architecture），简称 IA。它的主要任务是为信息与用户认知之间搭建一座畅通的桥梁，是
信息直观表达的载体。通俗点讲，信息架构就是研究信息的表达和传递。
图 2…13 网店版的需求模块与菜单结构
名称：用简洁的短语描述需求，要给用户提供什么功能，比如：黑名单。
描述：这里可以具体解释一下名称里说的功能是什么意思，比如：用户可以选择
联系人并加入黑名单，或者将某联系人移出黑名单，在黑名单里的联系人无法给用户
发消息。描述只要说此功能要做什么，无须解释怎么做，注意语言的无歧义性、完整
性、一致性和可测试性等，关于具体怎么写，可以参考第 3。3。1 节中“用例文档，UC”
里的讲解。
提出者：即用户需求的提出者，有疑惑时便于更进一步追溯。
提出时间：原始需求的提出时间，区别于提交时间，这是个辅助信息。
Bug 编号：可选，这是因为我们把产品的某些 Bug 也视为需求，所以加入这个表
格统一管理。
上述基本属性只是我做过的产品中常用的，大家可以按照自己产品的不同自由定
义，原则是为了便于需求的管理。对比一些需求管理软件，这里的处理已经很简化了，
尤其是表 2…4 中标了星号（*）的几项，是产品做大、需求增多的过程中必需的。
需求种类知多少
然后，需求的提出者需要自己辨别一下这个需求的种类，为后续的商业价值判断
提供一些辅助信息。我们尝试过几个维度，如表 2…5 所示：
表 2…5 需求的种类
需求属性
属性说明
分类
新增功能、功能改进、体验提升、Bug 修复、内部需求等
层次
基础、扩展（期望需求）、增值（兴奋需求）
分类：可以分为“新增功能、功能改进、体验提升、Bug 修复、内部需求”等。
其实产品需求远非我们直接可以想到的功能需求，还包括了很多非功能需求，比
如：性能、可培训、可维护、可扩展……有很多需求不是为终端用户做的，而是为销
售、服务、测试团队的同学做的。
举几个例子，“论坛需要支持 1000 人同时在线”，这是一个性能需求；“系统功
能升级，必须在发布 2 周以前完成对客服部门的培训”，这是一个培训需求；“如果
硬件压力突增，应该有报警，具体细节是……”，这是一个运维部门的维护需求；“在
用户数增加 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 个工作日。
相对于“初评”，在项目启动之后，制定项目开发计划的时候还会有一次更精确
的评估，那时候需求怎么做已经知道、由哪位开发工程师来做也知道，所以可以