按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
能，以免增加服务部门的压力……所以在公司层面上看，我觉得产品部门至少应该和
销售、服务等部门有平等的地位，坚持不断的从终端用户那里直接获得需求，才能保
证产品的可持续发展。
但二手需求毕竟是常态，我们经常接到的就是口头上的几句话，或者一封邮件的
几行说明，这中间理解的偏差只能靠我们主动的、反复的沟通来弥补，那么有没有什
么办法解决呢？下面我就介绍一种简单的二手需求采集工具——单项需求卡片。
单项需求卡片
单项需求卡片的理念就是：产品的需求工作不只是需求分析人员的事，而是涉及
产品的每个干系人的义务，至少得参与“采集”的过程，理想的状态是产品的所有干
系人都参加过“需求采集”的培训，然后在日常工作中养成主动提交需求给产品人员
的习惯，但实际很难做到，所以作为专业的需求分析人员，就应该尽量降低同事们，
比如销售、服务、技术人员提交需求的成本，也是节省我们自己的时间。
一张单项需求卡片描述了一个用户需求到底包含哪些内容，重点是描述用户场景，
谁在什么时间、地点产生了何种需求，先看一个模板，如表 2…3 所示。
表 2…3 单项需求卡片模板
需求编号（可由需求人员填写）
需求类型（可由需求人员填写）
包含“采集时刻 ＋ 采集者”信息
功能需求、非功能需求等
来源（Who）（重要信息，方便追根溯源）
产生需求的用户：最好有该用户的联系方式等信息
用户背景资料：受教育程度、岗位经验，以及其他与本单项需求相关经验
场景（Where、When）（重要信息，用来理解需求发生的场景）
产生该需求的特定的时间、地理、环境等
描述（What）（最重要的信息）
尽量用（主语＋谓语＋宾语）的语法结构，不要加入主观的修饰语句
原因（Why）（需求人员要保持怀疑的心，很多时候理由是假想出来的）
为什么会有这样的需求，以及采集者的解释
验收标准（How）
需求重要性权重（How much）：
（如何确认这个需求被满足了）
1。 尽量用量化的语言
2。 无法量化的举例解释
满足后（“1：一般”到“5：非常高兴”）
未实现（“1：略感遗憾”到“5：非常懊恼”）
需求生命特征（When）
需求关联（Which）
1。 需求的紧急度
2。 时间持续性
1。 人：和此需求关联的任何人
2。 事：和此需求关联的用户业务与其他需求
3。 物：和此需求关联的用户系统、设备，以及其
他产品等
参考材料
竞争者对比
在需求采集活动中的输入材料，只要引用
一下，能找到即可
按照“1 分：差”到“10 分：好”进行评估：
1。 竞争者对该需求的满足方式
2。 用户、客户对竞争者及公司在该需求上的评价
由于填写卡片的人经常不是专业的需求人员，所以卡片的质量无法保证，比如下
面这个例子就是一个典型（如图 2…9 所示）。
图 2…9 单项需求卡片实例
上图是工程师提的一个需求，就像我们永远无法猜到用户会怎么使用我们的产品
一样，“单向需求卡片”原本是让大家给产品提需求，而工程师却拿它来给产品经理提
意见，很有意思。从表格的填写就可以看出来，实际工作中我们能拿到的都是填写不
完整的，甚至是字迹难以辨认的，当然，也可以尝试电子版，那样我们整理的成本低
一些，不过很可能愿意填的人就少了。但我们心里得有个底线，一张有价值的单项需
求卡片，至少得有“需求描述”，需求编号、来源、场景最好也能有，其他的，其实很
少有人愿意填写了。
回到这张卡片，工程师描述的一个需求也很有意思，值得我们共勉——“PD 慎重
地考虑一些细节的改变，在没有大影响的前提下，不要对稳定的版本做一些鸡毛蒜皮
的动作”。工程师们也希望自己做的事情都能产生商业价值啊。
每当我们拿到这样的卡片，就需要主动去和提交人交流，完善卡片的内容。真实
的工作中你能体会到，这张卡片只是需求过程的中间产物，所以我们在这上面花费的
精力也是尽量缩减，单向需求卡片所描述的用户需求，最终要转化为产品需求才有真
正的价值。
尽可能多地采集
需求采集，并不是产品设计之前的工作，而是一个贯穿始终的过程；它并不是产
品人员的事情，而是所有人的责任；它没有特定的方法，不管白猫黑猫，抓到老鼠就
是好猫；它并不怕发现什么荒谬的需求，而是怕遗漏合理的需求……这才是需求采集
的大生产运动。
最后再简单分享几个有特点的需求采集方法，希望大家能灵活应用，尽可能多地
采集。
现场调查。说简单一点就是打入“敌人”内部，和客户一起工作一段时间，深度
了解需求。它是一种典型的定性分析，持续时间长，从几小时到几个月，既能听到用
户怎么说，也能看到用户怎么做，不过受众面极其狭窄，一次只有一个，要特别小心
被“非典型”用户带到沟里去。
AB 测试。基于大用户量比较合适，比如有一个按钮不知道是放页面的左边好，还
是右边好，而我们有 10 万用户，那就先随机挑选少量的用户发布这个按钮，1000 人放
左边，另外 1000 人放右边，然后过一段时间分析结果，再决定剩下的 98％用户该怎么
办。很明显，这也是让用户直接参与了设计，这样低成本的方法让很多传统行业的同
学羡慕不已。
日记研究。互联网新兴的个人应用比较适合，某个新产品出来以后，很多业内的
朋友都会去尝试，然后写一些使用体会，但作为产品设计者在看这些日记的时候，要
明白日记的作者往往是同行，而不是主流用户。
卡片分类法。我们把产品的各种需求写在便利贴上，让用户一起讨论并完成分类。
这能让你深入了解用户是怎么给产品划分模块的，用户认为这个网站应该是什么结构。
因为产品设计人员的思维和用户的思维通常不一样，这也就导致了如果是产品设计师
来单方面决定网站结构的话，很可能导致用户理解的困难，所以卡片分类法能让最终
的产品更加符合用户的心理模型。
自己提需求。这是最简单的方法。每一个靠谱的产品都会有一群粉丝用户，不用
你去找他们采集需求，他们也会给我们惊喜，主动提出很多需求，作为产品的主人，
我们好意思还没有用户了解产品么？产品要用才能感觉出好坏，特别是自己做的产品。
产品做多了，我们随便看看别人做的产品，总能一下子挑出很多问题，提出很多需求，
反过来看自己的产品越看越完美，这一定有问题，所以必须用自己的产品，最好是发
动认识的人都来用。
需求采集的各种新方法层出不穷。和学习任何领域的知识一样，建议大家在了解
知识框架后，坚持“需求驱动学习”。
2。3 听用户的但不要照着做
采集了很多需求，但是一团乱麻，从哪里着手？
用户都帮我们想好该怎么做了，照他说的做么？
在开始需求分析之前，我们先回到 2007 年 7 月——我写了一篇里程碑意义的博文，
是《产品设计体会》的第一篇，也可以看作是为这本书写的第一笔。
2007 年 6 月 28 日，网店版 2。0 上线，这是我主导的第一个付费产品，之后的三周
我基本天天都会在淘宝论坛上泡不少时间，最大的体会就是：要听用户的意见，但不
要照着做。
有的用户很“危险”，在提意见的同时还说你们应该做成什么样子，这时候产品经
理一定要头脑清醒了，用户提的解决方案往往是站在自己的立场上的考虑的。比如对
“快递单打印”的功能，用户提出要添加一个他经常用的小快递公司的快递单模板，
而我们会发现，这家快递公司可能只是一个区域性的快递，最终的解决方案是做了一
个“自定义快递单”的功能。
有时候，用户给出的做法存在明显的逻辑矛盾，就算他给出的解决方案合理，也
要再深挖用户内心根本的需求，比如用户描述“新建非支付宝交易订单的时候必须要
选择用户不合理，希望能自己填写客户”。这里更深层的需求就可能是他需要把线下客
户也管理起来，所以我们或许更应该做一个新增线下客户的功能，而不是在新建非支
付宝交易的时候让用户自己填写客户姓名。
我们是产品经理、产品设计师，最终怎么做应该由我们决定。
2。3。1 明确我们存在的价值
用户跟福特要一匹更快的马，福特却给了用户一辆车。
这就是我们存在的价值。还记得小明么？
他说他需要一个电钻，这是他提出的解决方案，但在大毛的刨根问底之下，发现
小明其实想要的是一种温馨的家的感觉，有了这个认识，我们就可以给出很多产品来
满足。比如卖他一套实施方案，带着电钻、油画，上门安装；比如用背面有强力胶的
钩子挂画；比如直接把画黏在墙上；比如直接在墙上画，并且让小明自己画；再比如
放一组书架在那里……经过我们分析得到的解决方案，比起小明自己说的，优势就在
于可能省了钱、省了时间、更温馨，等等。
对同一个问题，这两套解决方案的区别就是，一个是用户需求，一个是产品需求。
而这中间的转化过程，就是这节的主题——需求分析。
用户需求 VS。产品需求
用户需求：用户自以为的需求，并且经常表达为用户的解决方案。
产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。
需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需
求的过程。
听到过一个说法，说需求分析与常见的技术分析最大不同是思路的本质差异，技
术分析是“树干——树枝——树叶”的任务分解过程，技术人员很适应并乐于用这种
方式思考，可以把大问题分解成小问题，发现难点逐一攻克。不少需求人员都是做技
术出身的，所以开始往往会用这种思路做需求，听到客户提出的功能点，直接想怎么
做系统设计了，这导致有时候需求分析甚至已经越俎代庖到“详细设计”的职责了。
大多数人在生活中也习惯于用这样的思路来对付问题，而真实情况是，需求分析是“首
先：树叶——树枝——树干，其次：树干——树枝——树叶”的分析过程，所以说完
整的需求分析是一个“分…总…分”的过程。一方面不能漏掉提炼用户需求的这个过程，
目的是透过现象看本质，另一方面也不能停在本质上，试想如果做到“树干”就结束，
后端的执行人员可能还是不知道要做什么东西，所以我们还要继续把树干再重新分解
成树枝、树叶。
小明又出现了，这次他说要吃猪骨头火锅（用户需求），80 块吧，但没想到又碰到
了大毛。
“真的想吃？”
“想吃！”
“为什么？”
“我饿了……”（找到了本质！）
“哦，这里是两个馒头（产品需求），请你吃，才 1 块钱。”
“……”
小明无比不爽，但没办法，真的饿，还是吃了。
大毛是这样分析的，想吃猪骨头火锅，这个用户需求无非两个原因——饿了或者
馋了。如果他真的是馋了，那就吃吧，不过如果是饿了，那我完全可以用一个低成本
的解决方案——馒头。虽然小明眉头紧锁，但现在经济不景气，毕竟节省了 98。75％的
成本啊！
伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给
出更好的解决方案，或者说是用户真正需要的东西，这就是本节标题的意思——我们
存在的价值。
说到这里有必要提一下，销售人员经常说：“用户是为想要的东西买单，而不是需
要的”，用我们上面分析翻译一下，其实是“用户是为自己提出的解决方案买单，而不
是我们的解决方案”。是不是很纠结？那我们还分析个什么劲啊，直接做用户要我们做
的得了。
其实这是短期利益和长期利益的权衡，如果是一锤子买卖，卖出以后又不用售后，
那么采用实用主义，不妨用户要什么就给他什么，这样他掏钱最爽快，你回忆一下在
风景区买的纪念品的情景，大多数情况下，是不是你要啥卖家就给你啥？这种情况下