人人都是产品经理-第11部分
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
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 倍”，这是一个可扩展需求；“此
功能的用户操作日志需要记录”，这是一个内部数据分析的需求。
当然，对于一些边缘的需求，是列入这个表格统一管理，还是另外单独对付，这
可以随机应变。
通常来说“产品功能需求＋产品非功能需求 = 产品需求”，而“产品需求＋市场需
求＋开发需求＋测试需求＋服务需求＋…… = 产品包需求”，对这些概念感兴趣的同学
可以去查阅“需求管理”相关的资料。
层次：把需求分成“基础、扩展（期望需求）、增值（兴奋需求）”三层，理论
依据参见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”来衡量。而具体讨
论的时候，大家充分表达意见之后，安全的做法是谁官大谁负责，俗称老板拍脑袋，
最终由会场上级别最高的人报一个数字结束，这就是现实，也是一种高效的办法。我
曾经考虑过群体打分取均值等方式，可是实施起来成本太高
