按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
松一点，看起来也美观一点。
图 2…12 产品需求的列表
表格中每一行是一个产品需求，而每一列描述了产品需求的一种属性。
值得一提的是，用户需求与产品需求是多对多的关系，我们可能用多个功能来满
足一个用户需求，也可能用一个功能来满足多个用户需求，甚至是用几个产品需求来
满足几个用户需求，其中并没有一一对应的关系。
对任何产品来说，只要需求采集的功夫做足了，你就会发现上面这个产品需求列
表行数超多，所以在需求转化过程中，我们也会做一轮筛选，把明显不靠谱的用户需
求直接过滤掉，不计入上述列表，当然，是否“明显不靠谱”就要由你来把握了，不
要把“没资源做”、“短期内有技术难点”的用户需求给错杀了。
小明：“我知道了，我想去火星就是明显不靠谱，而想去月球就是钱不够的问题。”
大毛：“那也是明显不靠谱……你想去欧洲玩一个月才是钱不够的问题。”
模块 子模块 Feature 任务描述 商业价值描述 商业属性 商业优先级 开发量 性价比 备注
WEB邮件 繁体中文支持 港台商家 扩展 C 高
WEB邮件 邮箱总容量可视化（用颜色表达） 扩展 B 高
WEB邮件 容量将满需自动邮件报警 扩展 B 高 短信提醒先不做
WEB邮件 可以设置每页显示邮件数 扩展 C 高
WEB邮件 可以设置邮箱皮肤 扩展 C 高
WEB邮件 邮箱设置
有邮箱各个属性的统一设置模块；
如邮件规则，文字过滤器、黑白名单、
提醒设置等；（在垃圾邮件设置）
基本 A 高
更多的是我们前台展现的设
计
WEB邮件 快捷键支持 支持键盘快捷键操作 扩展 C —
WEB邮件 邮件列表排序
可按收件时间、大小、主题、发信人等
排序
基本 A 高
WEB邮件 显示邮件属性
图形化显示邮件已读、未读、有无附件
、已回复、已转发、优先级等信息
基本 A 高
WEB邮件 HTML格式解码
支持HTML格式编辑邮件，完全所见即所
得；HTML格式邮件的自动识别及显示，
包括背景图案、插图、正文格式等，已
显示的图片不再当作附件；
基本 A 高 提供类似live邮箱的方案
WEB邮件 编辑邮件正文
包括字体、段落、贴图等较丰富的编辑
功能
基本 A 高 提供类似live邮箱的方案
WEB邮件 保存为草稿
可以将邮件保存到草稿夹，并允许多次
修改
基本 A 高
WEB邮件 邮件签名
可以设置多种签名；
写信时可以选择各类签名；
早期可单一签名 基本 B 高
WEB邮件 支持多种发送形式
支持抄送（CC）、秘密抄送（BCC）、回
复作者（Reply）、回复全部（Reply
All）、转发（Forward）
基本 A 高
WEB邮件 发件箱备份
可以选择发出的邮件在发件箱中保留一
个拷贝…已发送邮件的List
基本 A 高
WEB邮件 自动回复
可以启用/禁用自动回复；
可以设置自动回复内容；
（系统管理员可针对某域设置是否开放
该功能）
假期自动回复 扩展 B 高
WEB邮件 自动转发
用户可以设定条件，对某些邮件（与过
滤器结合）自动转发到某邮箱；
扩展 B 高
缺点：降低用户粘性
系统管理员可针对某域设置
是否开放此功能
WEB邮件
缺省提供收件箱、发件箱、草稿箱和垃
圾箱四个目录
基本 A 高
WEB邮件
有单独的未读邮件标签，方便的查看未
读邮件数
基本 A 高
WEB邮件 可以将邮件标为已读，标为未读 扩展 B 高
WEB邮件
可以自定义邮件过滤器（邮件规则）；
过滤器可与自定义邮件夹结合；
扩展 B 高
WEB邮件
可以给邮件打标记（outlook的彩色小
旗，后续标记）
标识待办事项 扩展 B 高
WEB邮件 邮件搜索
可按照信件的标题、发件人及信件内容
中的关键字搜索所需要的邮件，支持模
糊搜索
节约时间，提高效率 基本 A 高
WEB邮件 邮件删除
可对一封、多封、整页、整个邮件夹的
邮件进行删除操作
基本 A 高
WEB邮件 邮件移动
用户可以将一封、多封、整页、整个邮
件夹的邮件在不同目录间移动
基本 A 高
WEB邮件 读信提醒
发信时可设置要求回执，收件人读信
时，同意回执后，自动信件通知
扩展 C 高
WEB邮件 失败提醒
信件发送失败提醒（发不出/对方没收到
等）
扩展 C 高
WEB邮件 大附件发送 支持大附件（如》50m）发送给多人 扩展 B 高
WEB邮件 添加附件
可以从用户系统中选择文件并添加为附
件；支持添加多个附件；（目前支持3个
附件）
基本 A 高
邮件
邮件列表
邮箱容量可视化
邮件分类
确定需求的基本属性
对于产品需求列表的维护，有时候我们是在产品团队里指定一个人负责，所有的
需求都由他来录入，有时候是采取共享文档的形式，大家共同维护，更多相关话题我
会在第 3。5。1 节的“多人协作与版本管理”中和大家讨论，但不管怎样，我觉得对于每
个需求，提交人都可以独立确定一些基本属性，如表 2…4 所示，这些属性是：
表 2…4 需求的基本属性
需求属性
属性说明
编号
需求的顺序号，唯一性标识
提交人（*）
需求的录入 PD，负责解释需求
提交时间
需求的录入时间，辅助信息
模块（*）
根据产品的模块划分
名称（*）
用简洁的短语描述需求
描述（*）
需求描述：无歧义、完整性、一致性、可测试等
提出者
即需求的原始提出者，有疑惑时便于追溯
提出时间
原始需求的获得时间，辅助信息
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 倍”，这是一个可扩展需求；“此
功