九味书屋 > 文学经管电子书 > 人人都是产品经理 >

第11部分

人人都是产品经理-第11部分

小说: 人人都是产品经理 字数: 每页4000字

按键盘上方向键 ← 或 → 可快速上下翻页,按键盘上的 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”来衡量。而具体讨 
论的时候,大家充分表达意见之后,安全的做法是谁官大谁负责,俗称老板拍脑袋, 
最终由会场上级别最高的人报一个数字结束,这就是现实,也是一种高效的办法。我 
曾经考虑过群体打分取均值等方式,可是实施起来成本太高

返回目录 上一页 下一页 回到顶部 0 0

你可能喜欢的