查字典图书网
查字典图书网
上面用很大篇幅说了一些常用的需求采集方法，这一节，我想先抛出一个“一手需求与二手需求”的概念，有个很形象的比喻就是“生孩子与养孩子”，话糙理不糙，我们内部经常这么说。 我们首先把“生孩子”――需求采集视为己任，人人有责，希望所有人都参与，都来“生孩子”，我们帮大家养，这就要给他们一个简单的“生孩子”的工具――“单项需求卡片”，最后，简单介绍一下其他常用的方法，这样才能做到“尽可能多地采集”。 生孩子与养孩子 之前所述的各种方法，都是直接从用户那里得到需求，我称之为一手需求，就像“生孩子”。其实很多时候，我们还会接受二手需求，比如老板说要给用户做个××功能、销售人员说用户哪里用起来不顺等，这些需求和一手需求比起来，就像“养孩子”。 “生孩子”，更多的时候发生于新产品诞生前，这时候外部没有用户、内部没有运营、销售、服务等，所以对于需求而言，更多的是产品人员驱动，去主动采集需求，比较常见的就是直接去潜在的目标用户那里采集。这个从无到有的过程，个人觉得发挥的空间最大，是最有成就感的。 小明：“还是‘生孩子’好啊，痛并快乐着……” 而“养孩子”，通常是产品已经运行了一段时间以后，用户也有了，公司内部也多了很多相关的人员，比如销售和服务。虽然产品部门与用户的直接接触变少，但多了很多间接来源，即与终端用户接触的干系人，他们会向你反馈很多需求，而用户也开始主动提出需求了。 对比一下，生孩子的时候，我们去主动“拉”需求的比例较高，需求都是直接从用户那里得到的，有点“进攻”的感觉，而孩子生出来以后，就不再是你一个人的孩子了，必然是大家一起养，所以我们需要照顾的各方各面也会更多，我们会收到很多“推”过来的需求，比较像“防守”的感觉。 有很多同学从一开始工作接触的就是已经存在的老产品，需求始终堆积如山，如果碰上销售强势的产品，那更是连响应销售提过来的需求都来不及，也许做了半年一年，突然回想，发现自己连真正的用户都从来没接触过，而是始终在满足销售的需求。个人感觉，这种二手需求，或多或少有扭曲，以销售为例，他们的考核指标决定了会比较注重眼前，希望产品的卖点越多越好，而之后用户用得如何，就不那么关心了。比如我就经历过一些让人很抓狂的二手需求，销售希望产品增加一个功能，这个功能在说服客户购买产品时有“临门一脚”的作用；而用户买完以后，最好又别用这个功能，以免增加服务部门的压力……所以在公司层面上看，我觉得产品部门至少应该和销售、服务等部门有平等的地位，坚持不断的从终端用户那里直接获得需求，才能保证产品的可持续发展。 但二手需求毕竟是常态，我们经常接到的就是口头上的几句话，或者一封邮件的几行说明，这中间理解的偏差只能靠我们主动的、反复的沟通来弥补，那么有没有什么办法解决呢？下面我就介绍一种简单的二手需求采集工具――单项需求卡片。 单项需求卡片 单项需求卡片的理念就是：产品的需求工作不只是需求分析人员的事，而是涉及产品的每个干系人的义务，至少得参与“采集”的过程，理想的状态是产品的所有干系人都参加过“需求采集”的培训，然后在日常工作中养成主动提交需求给产品人员的习惯，但实际很难做到，所以作为专业的需求分析人员，就应该尽量降低同事们，比如销售、服务、技术人员提交需求的成本，也是节省我们自己的时间。 一张单项需求卡片描述了一个用户需求到底包含哪些内容，重点是描述用户场景，谁在什么时间、地点产生了何种需求。 需求编号（可由需求人员填写） 需求类型（可由需求人员填写） 包含“采集时刻+ 采集者”信息 功能需求、非功能需求等 来源（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. 用户、客户对竞争者及公司在该需求上的评价 由于填写卡片的人经常不是专业的需求人员，所以卡片的质量无法保证。 就像我们永远无法猜到用户会怎么使用我们的产品一样，“单向需求卡片”原本是让大家给产品提需求，而工程师却拿它来给产品经理提意见，很有意思。从表格的填写就可以看出来，实际工作中我们能拿到的都是填写不完整的，甚至是字迹难以辨认的，当然，也可以尝试电子版，那样我们整理的成本低一些，不过很可能愿意填的人就少了。但我们心里得有个底线，一张有价值的单项需求卡片，至少得有“需求描述”，需求编号、来源、场景最好也能有，其他的，其实很少有人愿意填写了。 回到这张卡片，工程师描述的一个需求也很有意思，值得我们共勉――“PD慎重地考虑一些细节的改变，在没有大影响的前提下，不要对稳定的版本做一些鸡毛蒜皮的动作”。工程师们也希望自己做的事情都能产生商业价值啊。 每当我们拿到这样的卡片，就需要主动去和提交人交流，完善卡片的内容。真实的工作中你能体会到，这张卡片只是需求过程的中间产物，所以我们在这上面花费的精力也是尽量缩减，单向需求卡片所描述的用户需求，最终要转化为产品需求才有真正的价值。 尽可能多地采集 需求采集，并不是产品设计之前的工作，而是一个贯穿始终的过程；它并不是产品人员的事情，而是所有人的责任；它没有特定的方法，不管白猫黑猫，抓到老鼠就是好猫；它并不怕发现什么荒谬的需求，而是怕遗漏合理的需求……这才是需求采集的大生产运动。 最后再简单分享几个有特点的需求采集方法，希望大家能灵活应用，尽可能多地采集。 现场调查。说简单一点就是打入“敌人”内部，和客户一起工作一段时间，深度了解需求。它是一种典型的定性分析，持续时间长，从几小时到几个月，既能听到用户怎么说，也能看到用户怎么做，不过受众面极其狭窄，一次只有一个，要特别小心被“非典型”用户带到沟里去。 AB测试。基于大用户量比较合适，比如有一个按钮不知道是放页面的左边好，还是右边好，而我们有10万用户，那就先随机挑选少量的用户发布这个按钮，1000人放左边，另外1000人放右边，然后过一段时间分析结果，再决定剩下的98%用户该怎么办。很明显，这也是让用户直接参与了设计，这样低成本的方法让很多传统行业的同学羡慕不已。 日记研究。互联网新兴的个人应用比较适合，某个新产品出来以后，很多业内的朋友都会去尝试，然后写一些使用体会，但作为产品设计者在看这些日记的时候，要明白日记的作者往往是同行，而不是主流用户。 卡片分类法。我们把产品的各种需求写在便利贴上，让用户一起讨论并完成分类。这能让你深入了解用户是怎么给产品划分模块的，用户认为这个网站应该是什么结构。因为产品设计人员的思维和用户的思维通常不一样，这也就导致了如果是产品设计师来单方面决定网站结构的话，很可能导致用户理解的困难，所以卡片分类法能让最终的产品更加符合用户的心理模型。 自己提需求。这是最简单的方法。每一个靠谱的产品都会有一群粉丝用户，不用你去找他们采集需求，他们也会给我们惊喜，主动提出很多需求，作为产品的主人，我们好意思还没有用户了解产品么？产品要用才能感觉出好坏，特别是自己做的产品。产品做多了，我们随便看看别人做的产品，总能一下子挑出很多问题，提出很多需求，反过来看自己的产品越看越完美，这一定有问题，所以必须用自己的产品，最好是发动认识的人都来用。 需求采集的各种新方法层出不穷。和学习任何领域的知识一样，建议大家在了解知识框架后，坚持“需求驱动学习”。