《人人都是产品经理-5

“哦，这里是两个馒头（产品需求），请你吃，才 1 块钱。”“……”小明无比不爽，但没办法，真的饿，还是吃了。大毛是这样分析的，想吃猪骨头火锅，这个用户需求无非两个原因——饿了或者馋了。如果他真的是馋了，那就吃吧，不过如果是饿了，那我完全可以用一个低成本的解决方案——馒头。虽然小明眉头紧锁，但现在经济不景气，毕竟节省了 98.75%的成本啊！伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的解决方案，或者说是用户真正需要的东西，这就是本节标题的意思——我们存在的价值。说到这里有必要提一下，销售人员经常说：“用户是为想要的东西买单，而不是需要的”，用我们上面分析翻译一下，其实是“用户是为自己提出的解决方案买单，而不是我们的解决方案”。是不是很纠结？那我们还分析个什么劲啊，直接做用户要我们做的得了。其实这是短期利益和长期利益的权衡，如果是一锤子买卖，卖出以后又不用售后，那么采用实用主义，不妨用户要什么就给他什么，这样他掏钱最爽快，你回忆一下在风景区买的纪念品的情景，大多数情况下，是不是你要啥卖家就给你啥？这种情况下就要追求短期利益。但是，我们的产品通常都是希望用户长期使用的，并且后续的服务也是我们来做，所以为了长期利益，我们就有必要找到用户的真实需求，然后给他真正合适的产品了，哪怕这个过程不那么讨好。不知道你有没有帮女生买电脑的经历，帮她买也就意味着将来的售后服务、技术支持、维修都是你了，所以你才会在型号和配置上和她争吵，努力说服她不要买那些中看不中用的，而要买“真正的需求”。满足需求的三种方式我们通过产品需求来满足用户，顺着这个思路，就是要做一些用户真正需要的功能或服务，虽然这是最常用的办法，但也是最“劳民伤财”的。在甩开膀子干活前，我们有必要扩展一下思路，从问题的本质出发，寻找新路。之前我们说过，需求来源于理想与现实的差距，那么减小这个差距就有三种方式：改变现状。是我们最常用的，去开发某种产品，但也是最笨的办法。降低理想。不要忽视精神的力量，什么“打预防针”、“丑话说在前头”这类句子想必大家都经常听到。转移需求。因为人类的注意力是有限的，所以引导用户去关注其他事物，他就会觉得这个差距没那么可憎了。我们也可以说，人的行为是需求驱动的，想改变人的行为，可以寻找更强烈的需求展现给他，而让他不再纠结于原来的需求。给大家说一个写字楼电梯的故事。某写字楼可能是因为建造得比较早，考虑不周，电梯明显不够用，每天中午吃饭的时候总是很挤，最上面几层的小白领们平均要等 20 分钟才能下到 3 楼的餐厅吃饭，于是抱怨很多，他们给物业提意见，要求解决。物业公司找到了大毛，大毛帮他们分析了一下。改变现状。对现有产品做一些改进，在这个案例中就是增加电梯数目，或者加快电梯运行速度，但成本太高，直接被否定。降低理想。告诉楼里的小白领们，隔壁那个写字楼中午要等 40 分钟呢。俗话说“不患寡而患不均”，人们更在意的是相对而不是绝对，这样确实可以减少抱怨，但是一种低水平的满足需求，对产品美誉度没有帮助。转移需求。电梯门上贴一些锻炼身体的公益广告，当然内容是说爬楼有益身体健康。有效，部分用户走楼梯去餐厅了，但是刚吃过饭怎么办？爬几十层楼要得阑尾炎的。最后，采用了一个看起来很傻的方案，在电梯门旁边安装一面镜子，让等待的人们可以整理一下仪表，或者搔首弄姿一番，不至于那么无聊。我们后来发现还有其他的解决方案，比如电梯广告，不但可以转移用户注意力，减少抱怨，而且对写字楼来说，既不用花钱，又额外挣得一笔广告费；又如错开午饭时间，让人们都能更少地等待。所有这些，都是想告诉大家，满足用户的需求，不一定要做新产品或者新功能，而是更应该想想是否有“四两拨千斤”的妙招。也谈创造需求满足需求的方式，我们开阔了思路以后从一种变为了三种，但毕竟都是用户提出来的需求，我们能不能再开阔一点？不劳用户的大驾，直接达到产品设计的最高境界——创造需求！工作中典型的场景，就是老板或者产品人员的突发奇想，这些灵感在潜意识里都有一定的依据，是基于对用户、市场、产品的充分理解，也有过不少案例，这些需求最终获得了用户的认可，但更多的被证明是过于天马行空。苹果公司的乔布斯，可以说是创造需求的大师，但我不建议大家学，这是需要天赋的，但这份天赋非常值得保护，产品的进化和生物的进化一样，需要如基因突变一般的胡思乱想。更实际的，我认为需求分析的过程其实也有创造需求的成分，当一个新人真的能力不足的时候，不妨先做用户提出的需求，而不要自己去胡乱分析用户需求，而对于一个团队来说，要尽量避免“只有能力不足的需求分析人员”这种情况出现。我们刚上路，既要怀揣梦想，也要脚踏实地，所以接下来我们老老实实地开始给需求做一次 DNA 检测。2.3.2 给需求做一次 DNA 检测整个检测过程不妨用图 2-10 来表示，我们先把用户需求转化为产品需求，然后一步步确定每个产品需求的基本属性、商业价值、实现难度、性价比等。图 2-10 需求的 DNA 检测过程特别提一下，这里确定的是产品需求的各种属性，不同于之前提到的“单项需求卡片”，那张卡片里描述的是用户需求的各种属性。把用户需求转化为产品需求检测的第一步就是“需求转化”，现在我们有很多用户需求，可能记录在“单项需求卡片”里，可能记录在 Excel 里，可能是用 Word 随意写的几段话，也可能是一张思维导图，像图 2-11 这样，图看不清没关系，我只是想表达采集来的需求非常多。当然，在一个团队里，还是建议大家统一一种记录用户需求的形式。现在我们就要发挥出“我们存在的价值”，在这个阶段，团队经常举行头脑风暴 15，大家天马行空地讨论一番之后，对用户提出的需求有了比较全面的了解，对用户的内心世界有了比较统一的认识，对我们的解决方案也有了一些不成熟的想法，然后通常每个人分一块，去把它们都转化为产品需求，最后记录在一起。15 头脑风暴（Brainstorming）的发明者是现代创造学的创始人，美国学者阿历克斯·奥斯本。他于 1938 年首次提出头脑风暴法。Brainstorming 原指精神病患者头脑中短时间出现的思维紊乱现象，病人会产生大量的胡思乱想。奥斯本借用这个概念来比喻思维高度活跃，打破常规的思维方式而产生大量创造性设想的状况。图 2-11 网店版的一部分用户需求举个例子，对于我经常做的软件产品，用户需求是“删除数据之前需要我确认，以免误删”，转化分析以后，我们给出的产品需求可能是“数据回收站：删除的数据进入回收站，如果是误删，用户可以去回收站找回数据”。因为我做的几个产品都是用 Excel 来记录需求的，所以下面也以 Excel 为例来讲述，大家可以用其他工具来记录需求，但核心思路都是大同小异的。整理好的产品需求列表看起来是图 2-12 的样子，因为有商业隐私问题，所以我把具体内容弱化了。我们把它叫做 Feature List（功能列表）。一些 Excel 的简单技巧，建议大家还是学习一下，比如条件格式、筛选、单元格有效性、单元格锁定、隐藏等，可以让表格管理起来轻松一点，看起来也美观一点。图 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）、回复全部（ReplyAll）、转发（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 倍”，这是一个可扩展需求；“此功能的用户操作日志需要记录”，这是一个内部数据分析的需求。当然，对于一些边缘的需求，是列入这个表格统一管理，还是另外单独对付，这可以随机应变。通常来说“产品功能需求+产品非功能需求 = 产品需求”，而“产品需求+市场需求+开发需求+测试需求+服务需求+…… = 产品包需求”，对这些概念感兴趣的同学可以去查阅“需求管理”相关的资料。层次：把需求分成“基础、扩展（期望需求）、增值（兴奋需求）”三层，理论依据参见KANO模型 17。小明：“我想到一个手机的例子，打电话、发短信是基本功能；给电话录音是扩展功能，和基本功能相关；而如果这个电话特别结实，可以当锤子砸钉子，或者当砖头防身，那就是增值功能了。”大毛：“嗯，好多山寨手机的特点就在于满足了一些诡异的增值需求，比如可以当手电筒、当验钞机、当剃须刀……”小明：“你是在夸还是在贬呢？”大毛：“我也不知道，那些已经超出普通手机的范畴了……”对需求种类的区分其实没那么绝对，取决于很多因素，比如商业目的变了，某个功能的分类也就变了，我自己经常从“雪中送炭”还是“锦上添花”的角度去理解：雪中送炭是基本功能，对用户很有用，产品缺了这个功能根本跑不起来，比如 E-mail系统里的“收发邮件”；锦上添花的功能是指非必须的，用户有时用得到，有的话会给用户的使用带来方便，比如在发 E-mail 填写收件人的时候，系统根据你输入的内容自动提示你曾经发送过邮件的联系人，就像图 2-14。17 KANO 模型以东京理工大学教授狩野纪昭（Noriaki Kano）的名字命名，是一种对顾客需求或者说对绩效指标的分类，通常在满意度评价工作前期作为辅助研究模型，KANO 模型的目的是通过对顾客的不同需求进行区分处理，帮助企业找出提高企业顾客满意度的切入点。图 2-14 Gmail 的收件人提示功能我们在和用户接触的过程中会很明显地感受到这两种需求的不同，没有雪中送炭的功能就像系统有缺陷一样，所以应优先考虑。而当一个锦上添花的功能被用户普遍接受以后，几乎所有的产品也都拥有了，也就渐渐发提升为雪中送炭的功能了，就像现在的手机，几乎没有人能接受黑白屏一样，当初彩屏可是作为一大卖点来宣传的。分析需求的商业价值一个公司做任何产品，一个产品做任何需求，最终都是要满足一定的商业目的，所以“需求的商业价值”是最关键的内容，有条件的团队最好利用群体智慧，我们通常在这个时候举行“需求讨论会”。正因为商业价值如此重要，所以最复杂的时候我们尝试过用重要性、紧急度、持续时间 3 个指标来衡量，如表 2-6 所示。表 2-6 需求的商业价值需求属性属性说明