给需求做一次 DNA 检测

整个检测过程不妨用图 2-10 来表示，我们先把用户需求转化为产品需求，然后一 步步确定每个产品需求的基本属性、商业价值、实现难度、性价比等。

图 2-10 需求的 DNA 检测过程

特别提一下，这里确定的是产品需求的各种属性，不同于之前提到的“单项需求 卡片”，那张卡片里描述的是用户需求的各种属性。

把用户需求转化为产品需求

检测的第一步就是“需求转化”，现在我们有很多用户需求，可能记录在“单项需 求卡片”里，可能记录在 Excel 里，可能是用 Word 随意写的几段话，也可能是一张思 维导图，像图 2-11 这样，图看不清没关系，我只是想表达采集来的需求非常多。当然，

在一个团队里，还是建议大家统一一种记录用户需求的形式。

现在我们就要发挥出“我们存在的价值”，在这个阶段，团队经常举行头脑风暴¹⁵

15 头脑风暴（Brainstorming）的发明者是现代创造学的创始人，美国学者阿历克斯·奥斯本。他于 1938 年首次提 出头脑风暴法。Brainstorming 原指精神病患者头脑中短时间出现的思维紊乱现象，病人会产生大量的胡思乱想。

奥斯本借用这个概念来比喻思维高度活跃，打破常规的思维方式而产生大量创造性设想的状况。

， 大家天马行空地讨论一番之后，对用户提出的需求有了比较全面的了解，对用户的内 心世界有了比较统一的认识，对我们的解决方案也有了一些不成熟的想法，然后通常 每个人分一块，去把它们都转化为产品需求，最后记录在一起。

图 2-11 网店版的一部分用户需求

举个例子，对于我经常做的软件产品，用户需求是“删除数据之前需要我确认，

以免误删”，转化分析以后，我们给出的产品需求可能是“数据回收站：删除的数据 进入回收站，如果是误删，用户可以去回收站找回数据”。

因为我做的几个产品都是用 Excel 来记录需求的，所以下面也以 Excel 为例来讲述，

大家可以用其他工具来记录需求，但核心思路都是大同小异的。整理好的产品需求列 表看起来是图 2-12 的样子，因为有商业隐私问题，所以我把具体内容弱化了。我们把 它叫做 Feature List（功能列表）。一些 Excel 的简单技巧，建议大家还是学习一下，

比如条件格式、筛选、单元格有效性、单元格锁定、隐藏等，可以让表格管理起来轻 松一点，看起来也美观一点。

模块 子模块 Feature 任务描述 商业价值描述 商业属性 商业优先级 开发量 性价比 备注

WEB邮件 HTML格式解码

支持HTML格式编辑邮件，完全所见即所

WEB邮件 可以给邮件打标记（outlook的彩色小

旗，后续标记） 标识待办事项 扩展 B 高

表 2-4 需求的基本属性

16 信息架构（Information Architecture），简称 IA。它的主要任务是为信息与用户认知之间搭建一座畅通的桥梁，是 信息直观表达的载体。通俗点讲，信息架构就是研究信息的表达和传递。

领域的知 识。当然，在设置自己电脑里的文件目录结构时，也可以遵循这个原则。

举个例子，如图 2-13 的网店版菜单结构，就可以从其产品需求列表里的“模块”

设置里看出来。

图 2-13 网店版的需求模块与菜单结构

名称：用简洁的短语描述需求，要给用户提供什么功能，比如：黑名单。

描述：这里可以具体解释一下名称里说的功能是什么意思，比如：用户可以选择 联系人并加入黑名单，或者将某联系人移出黑名单，在黑名单里的联系人无法给用户 发消息。描述只要说此功能要做什么，无须解释怎么做，注意语言的无歧义性、完整 性、一致性和可测试性等，关于具体怎么写，可以参考第 3.3.1 节中“用例文档，UC”

里的讲解。

提出者：即用户需求的提出者，有疑惑时便于更进一步追溯。

提出时间：原始需求的提出时间，区别于提交时间，这是个辅助信息。

Bug 编号：可选，这是因为我们把产品的某些 Bug 也视为需求，所以加入这个表 格统一管理。

上述基本属性只是我做过的产品中常用的，大家可以按照自己产品的不同自由定 义，原则是为了便于需求的管理。对比一些需求管理软件，这里的处理已经很简化了，

尤其是表 2-4 中标了星号（*）的几项，是产品做大、需求增多的过程中必需的。

需求种类知多少

然后，需求的提出者需要自己辨别一下这个需求的种类，为后续的商业价值判断 提供一些辅助信息。我们尝试过几个维度，如表 2-5 所示：

表 2-5 需求的种类

需求属性 属性说明

分类 新增功能、功能改进、体验提升、Bug 修复、内部需求等 层次 基础、扩展（期望需求）、增值（兴奋需求）

分类：可以分为“新增功能、功能改进、体验提升、Bug 修复、内部需求”等。

其实产品需求远非我们直接可以想到的功能需求，还包括了很多非功能需求，比 如：性能、可培训、可维护、可扩展……有很多需求不是为终端用户做的，而是为销 售、服务、测试团队的同学做的。

举几个例子，“论坛需要支持 1000 人同时在线”，这是一个性能需求；“系统功 依据参见KANO模型¹⁷

17 KANO模型以东京理工大学教授狩野纪昭（Noriaki Kano）的名字命名，是一种对顾客需求或者说对绩效指标的 分类，通常在满意度评价工作前期作为辅助研究模型，KANO 模型的目的是通过对顾客的不同需求进行区分处

图 2-14 Gmail 的收件人提示功能

我们在和用户接触的过程中会很明显地感受到这两种需求的不同，没有雪中送炭 的功能就像系统有缺陷一样，所以应优先考虑。而当一个锦上添花的功能被用户普遍 接受以后，几乎所有的产品也都拥有了，也就渐渐发提升为雪中送炭的功能了，就像 现在的手机，几乎没有人能接受黑白屏一样，当初彩屏可是作为一大卖点来宣传的。

分析需求的商业价值

一个公司做任何产品，一个产品做任何需求，最终都是要满足一定的商业目的，

所以“需求的商业价值”是最关键的内容，有条件的团队最好利用群体智慧，我们通 常在这个时候举行“需求讨论会”。

正因为商业价值如此重要，所以最复杂的时候我们尝试过用重要性、紧急度、持 续时间 3 个指标来衡量，如表 2-6 所示。

表 2-6 需求的商业价值

需求属性 属性说明

重要性 重要程度，辅助确定商业价值 紧急度 紧急程度，辅助确定商业价值 持续时间 持续时间，辅助确定商业价值

商业价值(*) 商业优先级，不考虑实现难度，群体决策

重要性：可以参考时间管理里“重要与紧急”的概念。这里的重要度又可细分为：

满足后“一般”到“非常高兴”；未实现“略感遗憾”到“非常懊恼”，更多可以学 习 KANO 模型加深理解。

紧急度：在时间维度上判断这个需求是否迫切，紧急不重要的需求通常表现为解

决了短期的问题，如果熬过去没做，对长期影响不大；或者解决了局部的问题，如果

其次，我们把工作量再简化为开发量。我经历的项目，各类人力资源有：产品、

开发、测试、服务等。但一般情况下，团队里产品人员资源相对富裕，测试资源可以 调配，服务资源可以临时补充，所以开发资源经常成为瓶颈。于是，我们一般评估每 个需求的开发工程师工作量来表征其实现难度，这背后的道理是以团队里的瓶颈资源 为评估基准（如表 2-7 所示），大家视自己团队的情况灵活应用。

表 2-7 需求的开发量

需求属性 属性说明

开发量(*) 需求的开发工作量，表征实现难度

在这个时候，需求其实并不明确，只知道要做哪些，还是比较粗略的要点，而具 体怎么做根本还没有考虑，所以有的技术人员会觉得无法评估开发量，这很正常，这 个问题我们和技术人员纠结过许多次。他们说你们不明确每个需求怎么做，他们就无 法准确评估开发量，我们说没那么多时间明确每个需求该怎么做，你们不评估每个需 求的开发量，我们就不知道哪些值得进一步分析怎么做，而哪些又不值……于是就死 循环了。这类先有鸡还是先有蛋的问题也无须纠缠，我们继续讲实际的。

开发量是非评估不可的，我把它叫做“初评”，允许误差，并且会要经验丰富的 人来评估，通常是技术经理，或者系统分析师、架构师。他们做出简单的评估，并且 靠不断的实践来反复修正，评估者通常估计自己做这个需求要多少时间，然后乘以一 个系数，这个系数大于 1，反映着相应技术团队的平均技术能力。这里的评估一般用“人 天”作为单位，某个需求需要“1 人天”意味着需要 1 个人做 1 个工作日。

相对于“初评”，在项目启动之后，制定项目开发计划的时候还会有一次更精确 的评估，那时候需求怎么做已经知道、由哪位开发工程师来做也知道，所以可以推算 出相对准确的工期，工期和工作量是有很大区别的，比如生一个小孩，需要 1 个女人 10个月的时间，工作量可以说“10 人月”，但 10 个女人 1 个月的时间，同样“10 人 月”是绝对完成不了这个任务的，不管几个人，工期都只能是 10 个月……这个话题在 第 3 章还有机会慢慢谈。

性价比啊性价比

我们已经做了需求采集，把用户需求转化为产品需求 ，知道了某个需求的基本属 性、种类、商业价值、开发量，现在似乎应该开始写文档、干活了，但经验告诉我们 不是这样的：

绝对不能因为某个需求的实现难度很小就马上去做，也不能因为另一个需求的实 现难度大就不做。

一个实际的例子：

我做过的某个产品页面的访客，在 2009 年某段时间内使用各种网页浏览器的比例

我做过的某个产品页面的访客，在 2009 年某段时间内使用各种网页浏览器的比例