需求调研

要想设计适合用户的产品，你需要了解你的用户。有一些工具可以协助你完成这项任务，有些则会误导你。你需要学会辨别它们。——《亲爱的界面》01今天咱不聊如何做用户调研，咱们来聊聊在需求调研的时候那些曾经踩过的坑吧。关于如何做调研，我之前写过一些文，有需要的可以点：需求调研的粗浅分享来，聊聊用户访谈吧！02不知道有没有人有过类似的经历：路过一家正在打折的服装店，进去逛逛。导购MM非常热情的迎了上来：“您好，想要买点什么？”你内心的OS是：我也不知道……做需求调研时一上来就问用户：“请问，你有什么需求？”估计对方内心的OS也是：我不知道……曾经的我很疑惑，为什么用户会不知道自己需要什么。后来我发现，用户真的不知道自己需要什么。就算用户真的知道自己需要什么，也未必想过自己为什么需要这个。人们不但不能告诉我们如何解决他们的问题，甚至可能连问题都描述不清楚。——《亲爱的界面》正如亨利 福特曾经说过：如果当年我去问消费者需要什么，他们肯定会回答“一匹更快的马”。03有个非常有启发的案例是关于可乐的。上个世纪七八十年代，百事可乐发布了一个匿名品尝可乐的广告：顾客喝了两杯没有品牌标志的可乐，然后让顾客评定一下哪个更好喝，结果80%的顾客选择了百事可乐。这个广告极大幅度的提升了百事可乐的市场占有率。于是可口可乐坐不下去了，找了好多专家进行头脑风暴后，决定要改变可口可乐的配方。花了两年时间完成了新口味的研发，并且花了400万重金进行口味测试。结果是：有60%的消费者认为新口味要比原味好，52%的人认为新可乐比百事好。于是新口味的可口可乐上市。而上市后的结果呢？差点让可口可乐亏掉了底裤。用户不知道自己的需求和问题倒还正常，最糟糕的是，即便我们打算为他们开发一款产品，他们也无法预测自己是否会使用，以及如何使用该产品。在智能手机出现前，人们对手机的诉求是：能打电话、发消息、结实耐摔、续航能力强（可以换电池）。诺基亚对这些需求的满足程度高达80%以上，而iphone估计只能达到50%，可能还不到。正如诺基亚的高层说：“我们并没有做错什么，但是不知道为什么，我们输了。”04见识过可口可乐、诺基亚这样的巨头在面对需求调研的时候都惨遭滑铁卢的我们，应该怎么办呢？坐以待毙？无计可施？我倒是觉得，挺好的。我们工作最大的乐趣就在于此，我们要去挖掘需求，定义真正的问题。如果人人都知道自己的需要是什么，知道自己待解决的问题是什么，估计我们也就失业了。05那有没有什么方法可以在需求调研中使用呢？方法很多，但是我觉得不能偏信，我们还需要多关注一些细节问题，比如以下几个。了解人们目前在做什么了解现状是为了发现问题，为了找出可以使他们正在做的事情变得更加容易、更加高效的方案。可以使用的方法包括：观察用户的工作流程和场景等。比如，我们发现用户在做文件更新归档的时候，需要参照一份纸质清单，逐一核对，再去档案室的架子上找到之前版本的档案进行归档。我们是否能想出能够让他的工作变得轻松、容易、高效的方案呢？比如，一位妈妈在翻阅了食谱后决定要给宝宝做一顿营养丰富的晚餐，但是她需要把每样菜用到的食材及数量列出来后再带着单子去超市采购。我们是否能想出相应的解决方案呢？查明人们不想做却不得不做的事情什么叫做不想做却不得不做的事情？以填工时为例，每天工作都忙不过来，还需要非常仔细的去填工时。更让人挠头的是，往往会想不起来自己这一天或者这一周具体做了哪些事情，用了几个小时。填报销单、贴发票也是类似的烦恼。那我们有没有办法，让他们免于这些琐事的烦扰，或者至少让事情变得更有趣？了解人们想做的事情有的时候，用户的脑海里会想“要是能这样就好了”。那我们就应该想办法让他们有机会做想做的事情。比如，我在发邮件的时候忘记加附件了，我会想“要是有人提醒我一下就好了”，现在Outlook等已经有类似“你似乎忘了添加附件……”的提示了。要是不用出门就可以吃到小龙虾就好了，要是能知道公交车什么时候来就好了……06我来举个例子来简单的说明一下，这三个问题的应用。比如我们现在准备做一个“日程管理”的软件需求调研，我们可以思考以下问题，关注以下信息：用户现在是怎么管理日程的？具体如何使用的（时间、地点、过程……）？对于一些特别的（突发或者重复性的）活动是如何管理的？对日程管理有没有其他的期望（比如和别的app进行关联，或者可以分享、统计等）……在进行需求调研的时候，我们多思考一下：用户目前在做的事情哪些部分是低效的，是不想做又不得不做的，是可以提供便利的。这样做，是有助于我们去发现需求和定义真正要解决的问题的。很多时候，我们的解决方案解决是不是用户的痛点，只是痒点，甚至只能做到隔靴搔痒。在这个方面，确实还有很长的路要走……第五空间学习中心PBA培训下期开课时间：具体课程大纲，请联系第五空间学习中心索取

一、后端需求调研二、需求调研的落地方法三、后端需求类型与策略前后端分离的实现方式，使得每一个完整的产品体系都包含了前端和后端部分。相对而言,B端产品更依赖于后端部分的支撑。一些公司也习惯于将这些后端提供支撑的部分，称为“后端产品”。后端产品甚至不具有视觉化，而仅仅是一些中间件等。后端产品如冰山之下，却承担相当重要的幕后工作：支撑、运算、监控、调度、分配、统计分析、决策……由于后端产品部分的复杂性，因此负责这部分的产品经理，需要做更多、更深入的需求调研工作，才能完成方案设计。 一、后端需求调研需求调研，是需求分析的前题。需求分析，是产品方案决策的前题。从需求调研到产品决策，占据了产品经理80%的工作精力。由于调研和分析往往一起完成，所以在本文中我门统一将二者以“需求调研”代替。按通用的模型表达方式，我们可以简单画下：如上图：需求调研是一个过程，其产物是解决方案。后端需求研调，与前端需求调研很大的区别。比如用户的角色化、业务的全还原、场景的穷举、新旧逻辑兼容等。我们简单说下期中的用户、业务和兼容性的话题：1、用户后端产品的用户非最终的价值用户，而是服务人员（如客服、运营）。因此这些用户具有业务垂直性，是格式化的“人”，具有戒色性和行业属性。不同职位不同权重，关心的价值目标、决策权、使用人数不同。不同用户的具体使用场景不同。可以较容易的获取前端产品用户画像，因为我们自身或者所熟悉的人都在扮演着 前 端的角色，也就意味着设计过程中也很容易进行角色代入。而后端用户画像的获取往往艰难得多，最快捷的方式就是和公司的业务层交流，业务部门是最直接与客户打交道的，他们熟知大量的典型客户案例，可以帮助我们快速高效的描绘出用户画像。由于我们自身与后端用户的相剥离性，用户画像的作用显得尤为关键，可以时刻提醒我们是在为谁做设计，每一个关键诉求都在产品设计中有对应的抓手。2、业务业务目标——>诉求——>用户需求。业务手段——>途径——>产品功能。了解业务最好的方法，是轮岗参与业务环节中去。此外，更加便捷快速的方法，是调研访谈。调研之前，最好对业务能有大体的认知，安排好访谈的对象，提前准备好问题，让访谈更加高效。调研方式：访谈、数据分析、问卷调查、头脑风暴、德尔菲、观察，完成用户需求的收集；通过亲和图、提示清单等，整合需求信息。调研目标： 了解业务模式和业务特点 了解业务目标和业务规划 了解当前业务运转方式 挖掘当前问题与痛点对于后端产品，场景往往是很多的，需求的逻辑性大于故事性，需要由远及近规划处业务场景地图，才能勾画出业务架构，最终聚合出产品生态。在这个过程中，可以借助用户故事地图等等手段。通过整个业务的架构，厘清整个平台的用户对象、业务关系，也就确定了整个产品的业务边界范围，确定了整个团队内的业务语言。3、新旧逻辑兼容掌握后端产品逻辑真相的密码通常在开发手里，但是开发常常也需要临时查代码。在这种情况下，所有对旧功能的迭代都充满着风险。于此同时，无论是集成的大系统，还是拆开的烟囱林立服务，各个体系之间总是有逻辑调用。比如接口、公共数据等。后端产品大约60%的bug都是来自于这种牵一发而动全身的逻辑耦合。唯一能确保系统安全的办法就是做深入的可能影响的调研。为了避免空谈，我们结合《后端产品经理宝典》一书，介绍需求调研落地的常用方法，和需求的类型。 二、需求调研的落地方法1、过滤需求的方法做后端系统，要学会的第一个技能就是砍需求。也就是过滤需求。这不是一个贬义词，反而是体现后端产品价值判断的基础。过滤需求的方法，就是通过一定的手段判断需求是否是伪需求，应该被过滤掉。（1）用户场景模拟法后端产品的出发点就是帮助业务用户，因此在调研需求的时候要模拟业务的场景，分析业务用户提到的需求是否能解决他的问题。如果不能帮助用户，那么这个需求就可能是伪需求。以下面的案例说明：背景：“货到付款”类型的订单会因为缺货而无法发出，如果超过一定的时间，客服就会跟顾客沟通，帮顾客取消订单。需求：由于这种订单的数量还是蛮多的，逐个取消太费时间，因此业务用户要求在“缺货订单”列表页增加“批量取消订单”按钮。分析：调研到业务操作场景,是先找到该类缺货订单，然后和顾客沟通，顾客同意删除，才进行删除。也就是逐个沟通确认，再逐个取消订单的，所以“批量取消订单”无法被有效使用。因此，该需求是个伪需求，应该被过滤掉。（2）功能归属分析专门的系统做专职功能，有助于合理的产品体系建设。因此需求调研的时候，可以通过系统的定位，判断需求是否应该在该系统完成。如果不属于该系统范畴，那么直接说服需求方更换方案。以下面的案例说明：背景：CRM系统（顾客关系管理系统）有一个顾客标签生成功能，就是根据顾客的消费行为数据，自动对应关联上标签，如优质顾客、高潜力顾客、欺诈顾客等。需求：业务用户提出需求，除了做上述的基础标签之外，还要做出英语版本的标签（就是把标签文案翻译成英文），这样欧美员工可以在英语版本的系统下使用。分析：调研到翻译之后的标签不是在CRM系统使用的，而是给到SMS（客服系统）使用的。所以应该由SMS根据CMS提供的基础标签数据，自己做二次的衍生。之所以这样，首先是为了避免未来更多语言版本的扩展需求或更多系统提出类似的需求；其次，CRM系统已经完成了“接力赛”的第一棒，创造了基础数据，那么其他系统要特殊化使用，完全可以自行进行特殊化处理，无需耦合回CRM系统。结论：案例的需求本身是真需求，并且实现上也没难度，但是该功能的定位超出了本系统范畴，专门系统做专职功能，化衍生需求应该在下游执行。否则，耦合性过高只会增加系统的复杂程度，难以维护和扩展。2、拆分和聚合的方法（1） 拆分需求法收到的需求，很可能只是短短的一段话。但是不要高兴太早，可能这一句话暗含了很多线索，因此要善于拆分：先找他要解决的核心问题，再围绕核心点，理清前、后、左、右、上、下的旁系需求点。每个需求点再当做一个子需求进行调研，最后再聚合在一起。以下面的案例说明：背景：订单业务的类型很多，订单退货之后需要创建售后单据，但是因为数量大，所以花费很多人力，且手动创建有出错的风险。需求：业务提出的需求是“增加退货订单自动创建售后单的功能”，这是个一句话需求。分析：该一句话需求，其实包含了多种具体的订单类型和场景，那么我们就要拆分调研，拆分的维度比如：自营订单、第三方订单、货到付款订单、先款后货订单、部分退货订单、完全退货订单、服装事业部订单、电子事业部订单等，其中每一个维度就相当于一个小需求。这里不一一展开。（2）聚合需求法拆分法是对单个需求分解成若干小需求进行调研，聚合法相反，是找到许多个相互关联的小需求的共性，然后统筹成一个大需求去完成。例如：由于业务用户分散在不同的部门，各自为政，于是张三、李四可能都对一个业务流程有相同的需求，或者对同一个功能有相同的优化期望，结果俩人分别提了需求过来。那么产品经理就要找到二者背后的相关性和交叉区。然后统筹规划，聚合在一起当作一个需求来调研，最终输出一个整体的需求调研结果。3、利用辅助功能调研需求调研产品现有功能，可以用来确认原有功能的逻辑，或者确定新需求方案是否可行。比如业务用户需要更新一个功能，为了避免更新出错或遗漏，产品经理需要知道修改前和修改后是否会能正常运行。最基础的办法就是自己设计一个测试用例，记录操作方式、状态变化、数据流向等。看看下面的例子：背景：从销售网站获取到OMS系统（订单管理系统）的订单信息中带着顾客的邮箱。顾客下完单，可能会在销售网站修改邮箱，而此时已经获取到OMS的历史订单中的邮箱是不变的。需求：顾客若在销售网站修改邮箱，要求已获取到OMS的该顾客的订单中的邮箱也要同步修改。分析：需求是很明白的，也有它的意义，但有风险。因为我们知道订单信息贯穿于整个订单流转过程中，牵扯到订单编辑、审核、取消、配货、发货等，而这些环节跳转的触发条件可能就是某个信息更新（这里面就可能包括有邮箱更新）。因此，更新邮箱是否会影响流程中的某些环节，一时间很难准确知道。于是，我们可以采用预测试的方式，设计测试用例，在测试机运行一些订单，观察各个环节邮箱变更的影响，然后收集起来分析对策。测试法就像是探雷一样，主要用来解决未知风险点。这个方式的重点是记录和分析操作前状态、操作位点、操作后状态、操作后触发的连锁反应、数据流向等。4、“拔萝卜带出泥”的方式调研需求调研需求时，产品经理要拔萝卜带出泥,挖掘用户没看到的需求点和价值。举例说明：背景：公司入驻到销售平台后，销售平台会对入驻的店铺的违规行为进行罚款。需求：业务用户提出需求，将销售平台的罚款数据抓取到订单系统，关联订单数据，以便进行人工分析。分析：第一步，先拆分需求，确定什么是罚款数据，总共有哪些罚款种类，需要对接哪些罚款种类，罚款数据与订单系统关联方式是什么，是否都能关联到，关联不到怎么办，销售平台是否已经提供了公用的罚款接口，Token（请求权限）如何获取，抓取频率怎么样，数据增长幅度多大，获取之后做哪些展示和搜索，用户权限怎么设置，需要和订单系统做哪些交互，该需求的价值是什么……第二步，挖掘需求：是否需要作分析功能，分析功能的规则是什么；是否需要做监控和预警，是否需要指派负责人；其他业务人员是否也有类似需求，其他平台是否也有类似需求……通过“拔萝卜带出泥”的方式，连带出更多需求点。将上述调研结果重新组装起来，得到一个系统化的完整需求。罗列出需求要点和对应的验收目标，这样使得需求具象化，同时又不会遗漏细节，内部充实，外部闭环，并且进行了价值挖掘，做成控制阈值、预警、责任人分派、趋势分析、损失分析等高价值的功能，超出业务的预期。5、需求得分权重法该方法的思路就是将需求质量的维度进行权重，然后对需求进行打分，根据最终得分的多少排列顺序。可以采用五个维度：重要、紧急、收益、成本、风险，其中成本和风险是给予负分，五个维度的分值权重分别为30%、30%、20%、10%、10%。那么一旦对需求打了分，就可以用分数*权重，得到最终得分。注意：负分的要减。并且为了方便计算，分值最好设置0.5-5.0之间，或者0-10之间。这样避免打分的跨度过大出现较大偏差。如表所示，需求1的得分=6*30%+6*30%+8*20%-3*10%-7*10%=4.6。而需求2得分3.5，需求3的得分为-0.1。由此可以判断需求的价值顺序为：需求1>需求2>需求3。对于需求3，可以予以淘汰。以上的维度、分值和权重可以根据实际情况自行设计，但是要多考察和验证什么样的参数是较为合理的。并且也不能唯权重得分是从，而只是把它当做一个辅助工具。6、其他需求调研工具需求调研适合核心环节，该过程就会涉及到很多工具或分析方法，以确保需求调研高效、高质量。比如问卷调查、访谈、名义小组会议、头脑风暴法、观察法、亲和图、蒙特卡洛技术、鱼骨图、提示清单等。 三、需求的类型和态度笔者对B端或泛后台产品需求的一个定性划分：粗浅需求、噱头需求、踢球需求、过剩需求、建设性需求。1、被动的粗浅需求这类需求，属于想当然的需求，不考虑系统的兼容性和业务兼容性的。比如：电商场景中，要求：若库存为0，则果断给予下架；库存变为非0，果断自动上架。这种强制自然是存在极大风险的。并且库存为0也有曝光的价值；非零也有下架的场景。二者不等同。这种情况下实际是“概念偷换”的错谬，无库存=下架。对这类需求，产品可以持保留态度，持续观望，收集更多用户的深层次数据反馈。但不能轻举妄动。2、战略的噱头需求这种很好理解，很多公司其实都是这么玩没的。比如：看到竞争对手有的功能，我们要有；对手无的，我们也要有。这样可以显得产品更强大。或者是强行“组合创新”：一个做医药电商的，你让他做直播带货，且不说是否合规，你能想象药师在店里当着店长的面做网红吗？这种情况下实际是“感觉谬误”。理论上，产品经理需要拿数据论证的。所以产品经理能做的就是慢点做，保留资源。找机会慢慢把意见渗透到高层，试图止损。3、隔壁的踢球需求在多组织的团队中，这种踢来踢去丢需求的情况相当普遍。比如，对医药商品，配置一段免责声明，展示在商城。那么让商品后台在商品维度加字段并传给前端，看似从后端到前端，且商品维度的，似乎没错。但是没必要的。因为，这是共性字段，商品维度几乎不需要重复维护，也没有操作差异性。这类需求，产品经理需要从分工、系统职能、收益考虑，将事情客观表述出来，完成博弈。4、客服的过剩需求这类需求，往往是客服传达来自用户的需求。通常目的很明确，但是对功能设计进行了干涉，可能影响产品的分析。比如，客服传达某O2O用户的需求：要在商品的实际销售价旁边，展示线下零售价格。产品：然后呢？客服：若对比到差异，则修改线上价？产品：怎么修改？ 客服：在线下零售价的基础上按公式计算，比如上涨1%，得出线上零售价，然后逐个编辑。产品：是否可以理解为，目的是让线上价格，按自己期望的卖，不取线下零售价？ 客服：是 产品：那么为什么不在根源处理呢：创建一组用于线上销售的价格，直接引用不就可以了吗？这类问题，一定是要挖掘到用户的场景的，从用户的场景下寻求同理心，不受制于现有功能的设定。只有这样才能不受局限，找到用户的初心。以解决问题为标准。5、产品经理的建设需求所谓建设性需求，可能是每个产品经理心中都有的夙愿。前提是，产品经理的决策正确。比如：自主优化产品模型，拆分微服务，界面统一等，统筹规划和重构的类的内容。若前四类需求过多，将会挤压产品的建设性需求。产品经理能够腾出手来做一些真正正确的事情，往往能对全局带来增益。都看到这里了，点个关注吧！END

专家引领 需求调研2020年2月20日，洪安中学校“强校工程”研讨活动在“新见 书山”进行。何远忠校长首先向四川西部教育研究院的领导与专家介绍了项目合作与展望，并与专家组一起审议学校的三年规划，研讨并细化强校工程实施方案的措施，落实项目合作的启动仪式等工作。研讨活动的第二阶段内容是洪安中学教导处、教科室、政教处分别向专家组提出强校工程实施过程中存在的问题、困惑，专家组耐心细致地进行剖析与解答，提出了详细的应对措施。参加研讨活动的人员有：洪安中学何远忠校长、邱绍明副校长、教导处主任、教科室主任、政教处主任、团支部书记；四川西部教育研究院李鹏飞执行院长、周晓兵常务副院长、事业发展中心叶有龙副主任、龙泉驿区工作站叶长青站长等。

当你的领导质疑产品调研时间过久，甚至说出：一个产品的调研，如果是他做，两天就完事之类的话，那么作为项目负责人的你，怎样才能和领导说明需求调研的方法论，并准确的执行呢？作者从多年的项目经验出发，对B端产品需求调研的方法论进行梳理，与大家逐一分享，本文首先向大家介绍一下需求的背景分析。什么是需求？需求被定义为：用户在产品使用过程中对产品的预期和使用现状的差距，我们服务的传统企业客户比较多，一般传统企业进行转型都是为了降本增效、串联产业链，帮助企业解决实际问题，提高工作效率，当问题未得到解决或未得到高效解决的时候，就会产生需求。项目需求背景分析：需求背景是指需求产生的原因及想达到的目标，通常我们接到客户的需求的时候，需要通过一些工具进行分析，常用的方法就是5W2H，但是这里可以简略分析，谁(who)需要通过怎样的途径(how)去达到什么目标(what)，总结下来就是what、who、how三个核心元素。what：是指本次项目目标，在进行背景分析时，我们需要明确项目目标，在明确项目目标的前提下，可更清晰的确定需求的边界。who：是指本次项目的干系人，包括直接干系人和间接干系人，我们需要尽可能的确定需求干系人并对其进行用户访谈，通过用户访谈确定干系人目前的问题及其关注点以及需求的重要程度，并以此进行后期的功能设计。how：是指该项目的策略级实施方案，通过对需求进行背景分析，我们需要确定项目的策略级实施方案，并根据干系人关注点、项目目标、项目资源确定当前最优解决方案。总结来说就是三步，第一步确定项目目标，第二步，确定干系人，第三步，解决方案。下面我将为大家详细讲解一下该怎么做。第一，确定项目目标项目目标是贯穿整个项目周期的产品方向，B端项目的目标通常是基于当前的业务形态制定的，且每个版本均需明确该版本的项目目标。那么，该如何确定项目目标呢？确定项目目标的关键是明确【业务场景+当前情况+目标】。具体的业务场景是需求分析的基础，业务场景具有故事化的功效，可帮助进行产品设计，也可帮助技术部门理解需求，明确当前情况，可确定当前的问题，而目标即是需求人对产品设计的期望，通过明确现状期望即可提炼出产品需求。第二，确定干系人确定干系人是需求分析必不可少的一个环节，与C端产品需求分析过程中的用户分析不同，B端产品的干系人分析不仅包括产品的用户(直接使用人)，也包括产品的直接和间接相关人。干系人可从目标和风险两个维度进行识别：1. 根据目标识别关键干系人，例如直接部门负责人、间接部门负责人、核心用户等。2. 根据风险识别关键干系人，例如：该功能的直接使用人、具有一票否决权的评价者、技术部门负责人等，引用一张图可以更清晰的看出来。确定干系人后，需对干系人进行用户访谈，收集干系人当前遇到的问题以及问题发生的频率及影响，再对问题进行归纳整理，进而产出策略级的解决方案。第三，解决问题首先应记录原始问题在进行干系人访谈时，我们需要记录用户对遇到的问题及问题产生的影响的原始描述，原始描述有助于后期对原始需求的追溯。 接下来需要整理问题并分析影响第二步我们需要对干系人提出的问题进行归纳整理，并分析其影响，问题的影响包括直接影响和间接影响。最后产出策略级解决方案，明确问题影响后，则可产出策略级的解决方案，并对比不同的解决方案的优缺点，在权衡干系人关注点、问题影响、当前资源等情况后，产品负责人和关键干系人对当前需解决问题的优先级及问题的解决方案达成共识。总结：由上可知，对于需求做背景调研可按照第一步确定项目目标，第二步，确定干系人，第三步，解决方案。根据项目规模大小，此阶段可能需要项目团队投入2-4周进行精细化调研分析。下一篇我们将讲一讲需求调研的调研方式和提纲及访谈技巧等内容，请持续关注。(本文为原创，如需转载请联系作者）

为进一步推动滁州市智慧市场监管项目的建设工作，12月14日以来，市局科技信息化科牵头组织市局智慧市场监管项目建设方、相关科室局、各县市区局相关人员开展智慧市场监管项目（二期）建设需求调研工作。本次调研的主要内容有市场监管网格化管理地理信息系统、一单三库管理系统、监管任务自动分拨处置系统、移动监管管理系统等建设需求。调研过程中，科技和信息化科对智慧市场监管平台的结构、功能、基本信息等进行了深入详细的讲解。参加调研的人员围绕市场监管执法办案工作现状、工作重点流程等进行了深入研讨，并对完善平台功能提出了良好的建议。下一步，市局科技信息化科将根据本次调研结果，加快推进智慧市场监管项目（二期）建设，通过云计算、大数据分析等技术，切实提高市场监管的工作效率和监管效能，进一步提升市场监管工作信息化、科学化水平。【来源：滁州市市场监督管理局】声明：转载此文是出于传递更多信息之目的。若有来源标注错误或侵犯了您的合法权益，请作者持权属证明与本网联系，我们将及时更正、删除，谢谢。 邮箱地址：newmedia@xxcb.cn

编辑导读：作为一个产品经理，每天要接触到大大小小不同的需求。只有对这些需求进行分析，才能更好地了解问题，从而制定相应的解决方案。具体怎么做？本文作者基于自身经验，对此展开分析，希望对你有帮助。某日，渔歌群里几位产品经理的对话，大概意思：业务和产品沟通需求的时候，业务板上钉钉的要求做数据可视化，还说不做的话要上升到老板那。产品乖乖配合业务做了，但是那些可视化功能上线后竟然没有访问量。当时提需求的业务都直奔下载。紧接着，产品经理被开发怼，你这需求怎么弄的？浪费我的资源。产品经理表示怀疑人生。此时，渔歌群里好几位产品经理表示，他们也有类似遭遇，业务提需求的时候，旗帜鲜明的要可视化，说要看趋势、看变化，但上线后，滚犊子的全去下载了，下载的点击量永远排名第一。产品经理们又难受、又委屈，心里窝火，太难了。产品经理们你一言、我一语的讨论，业务为什么那么爱下载数据？为什么对可视化报表视而不见？当事的产品经理说很懵逼，搞不懂业务这路数。群里有产品经理说，那是因为一开始就没搞清楚业务的需求，被业务晃点了。群里也有小伙伴反问，产品经理为什么要搞清楚业务的需求？搞清楚了又怎样？又不会帮业务做，需求都做了的话，产品就极其臃肿，还是产品吗?所以没必要搞清楚业务需求。渔歌回应上面的问题：上产品前后需求为什么发生变化？为什么业务总喜欢下载？这对产品经理来说是专业域的讨论。而为什么要搞清楚需求？用户需求是否产品化？即是专业问题，也是态度问题。01 数据下载的必要性下载是数据产品中很常见的功能，很多用户强依赖下载，尤其2B客户，而服务业务的对内数据产品，本质上也是2B产品。数据产品的确应该通过可视化、诊断、解决方案将客户需要的最终结果呈现给用户，而不是让用户自行下载、分析。但现实是，纯粹通过报表和数据产品很难完成中高阶的数据分析，甚至连初阶的数据分析都难以支持。需要下载的原因：2B的业务场景复杂，需要在不断分析中尝试、求证，来完成分析。不管是对内，还是对外的数据产品，想通过一步到位的可视化来满足数据分析、商业分析，难度很大，也需要大量时间、精力；业务发展或者变化太快，新的节点不断长出来，老的节点随时消失。随着业务变化，可视化报表的有用性、易用性将大打折扣。数据产品经理对业务理解不够，或者缺少分析思维。有时候1个数据产品经理要对接十几条业务线，要让产品经理理解每个业务，确实不现实；所以对很多数据产品来说，无论从必要性和可行性上来说，下载都是刚需，即使数据可视化做的很好，也还是会存在下载的需求。所以不要怀疑人生，产品经理内心都很强大，不要因为这点事难受，也不值得我们难受。通过数据可视化、诊断、解决方案去逐步解决用户问题，这的确是数据产品经理需要持之以恒去解决的，但不影响有些业务场景和有些阶段，提供下载的功能。02 用户下载数据的动机渔歌不再赘述这个问题，在“到底什么是需求？动机才是需求”一文中，已经有阐述，只是每个业务场景下，用户下载数据的诉求会有差异，这是产品经理在产品化之前应该前置想清楚的，不然就真的被业务晃点，再被技术追着屁股打。如果想要解决业务强依赖下载的问题，需要先和业务沟通清楚，他们下载后到底是用来干嘛的。事前和业务一起梳理清楚，远比事后算账重要，也比事后再让业务拿excel演示重要。事前调研不要停留在嘴喷的状态，需要拿出真章法，刨根问底，看业务平时都做哪些临时取数，给老板汇报什么数据，汇报的PPT都是什么样的。如果只是嘴喷需求，一定不牢靠。搞清楚问题，也就是定义需求，是产品经理的最重要的工作之一。把业务日常的报表、PPT都搜集过来，认真研究，杜绝蜻蜓点水式的需求调研。03 为什么要知道客户的动机，挖掘出真实需求？渔歌群里有位产品经理提到，反正用户的很多需求在产品上都实现不了，要么资源不够，要么产品极其臃肿，那花九牛二虎之力把客户需求搞清楚，又是为什么？什么时候该搞清楚用户需求？这是很好的问题，或许也是很多人的困惑。渔歌的观点：1）无论需求是否最终产品化，前提条件都是搞清楚用户的真实需求。用户的真实需求都不清楚，就无法做出“是否要产品化”的正确决策，更像在抛硬币。2）的确不是所有的用户需求都能成为产品，但什么是用户需求，什么应该产品化是2个问题。产品化建立在用户需求、公司战略、技术性比价的基础上，取3者交集，只是单一用户需求，但和公司战略相悖，或者技术投入巨大，没有投入产出比，这种用户需求也无法产品化。3）产品是否臃肿，看的是产品的规划和设计能力，不是需求的多少。产品经理不是搬运工、管道工，简单把用户需求搬过来做复制、粘贴。产品经理定义完需求，并确定用户需求要产品化之后，还要精粹、提炼，输出产品架构，再把功能放到产品架构中合适的位置，不是随意堆砌。好的产品不会有臃肿感。04 小结在数据产品中下载是常见功能。是否需要提供下载需要根据业务场景做判断。是否需要下载是个表层命题，关键问题是下载数据是为了什么，根据下载的动机去找解决方案。而不是讨论为什么下载量这么大，可视化是不是没有用。产品经理和业务沟通需求时，需要做深度的需求调研，不是停留在嘴喷阶段。要看业务在没有数据前是怎么操作的，自己跑数后又怎么操作。扎实的前期调研是产品的基础。#专栏作家#11年经验的某大厂产品经理，专注产品和大数据。本文原创发布于人人都是产品经理，未经作者许可，禁止转载。题图来自Unsplash，基于 CC0 协议

3月2日，江西省抚州市东乡区气象局农业服务人员到邓家乡花果山水蜜桃基地开展服务需求调研，了解前期气候条件对水蜜桃树木生长发育的影响，结合后期天气形势，指导果农做好果林水肥管理、病虫害防治、疏花摘芽，提高水蜜桃座果率。由于今年前期气温持续偏高，降水偏少，水蜜桃提前进入花芽期。农业服务人员建议果农，要做好水肥管理，追施萌芽肥，可适当喷施石硫合剂，防治病虫害。同时，东乡区气象局将种植大户人员信息纳入一键式预警发布平台，开展精细化气象服务，切实保障特色农产品培育生产。（作者：谢良梅 责任编辑：苏杰西）【来源：中国气象报社】声明：转载此文是出于传递更多信息之目的。若有来源标注错误或侵犯了您的合法权益，请作者持权属证明与本网联系，我们将及时更正、删除，谢谢。 邮箱地址：newmedia@xxcb.cn

编辑导语：工欲善其事，必先利其器。在产品设计前需要通过调研详实的了解用户需求，才能设计出符合预期的产品。基于B端和C端的用户主体、使用目标、参与角色等因素的不同，在调研方法的实施中会存在差异。本篇以“用户访谈法”为例，讲述项目制的B端产品在用户调研准备、执行、总结各环节的操作方法及注意事项。一、为什么是“用户访谈”？为了满足我方项目目标以及客户（甲方）需求的双重目标，以及推动下一步工作，充分的需求调研是必不可少的。常用调研方法有很多，每个方法各有优劣。具体方法的选用要结合实际的资源限制情况来确定，比如调研时间、人力资源、调研环境。1. 行业研究说明：通过垂直的行业网站快速了解行业基础情况，包含产业链/供应链组成，业务在链条中所在位置等信息。或者通过研究竞品了解对应产品的构成和逻辑，以此反向解析用户需求；优势：找准信息渠道，能够快速获取相应行业或产品资料；局限：信息相对宏观或模糊，可作为基础储备，指导具体产品设计却不够。2. 调研问卷说明：通过设置一系列基础信息问题、围绕主题的逻辑问题，获取填写人对某事件或行为的观点、偏好等信息；优势：既可以用于定量分析也可以用于定性分析，同时易于大面积推广；局限：问卷篇幅限制，问卷发出后不能修改，回收质量得不到保障。3. 实习轮岗说明：通过调研人员在业务岗位上实际工作，可以深刻了解真实业务运作流程和各项细节点；优势：对该岗位负责的业务了解较为透彻，对业务细节掌握更清晰；局限：实习轮岗所需的时间过长。4. 数据分析说明：可以直观的了解过程数据、结果数据及各项指标等情况，通过数据（及趋势）推演出问题；优势：清晰明了，非常客观，能够做到有据可查；局限：要提前埋点或置入SDK等，才能对过去一段时间数据进行采集。注意数据解读误区。5. 现场访谈说明：是快速了解业务全景的方法，通过和各层级的相关负责人通话，可以直面问题和需求。优势：能够快速掌握主要情况，从战略、执行、经营等多个角度获取信息。局限：访谈的形式对业务细节无法很好掌握，需要后续补充完善。二、调研的“老套路”在实际操作中，调研可以分解成3个步骤：调研准备、调研执行、调研总结。1. 调研准备调研前的准备工作包含了明确调研目标、确认调研方法、选取调研对象、整理调研大纲等。1）明确调研目标在项目执行过程中会出现多次反复的调研，项目不同阶段的调研目标是不一样的。一般来说，项目初期的调研目标是明确项目背景、目标、目的、业务流程等；项目推进阶段会沟通具体的业务场景。如业务范围、业务场景、业务流程。2）确认调研方法我们知道了很多的调研方法，需要根据实际的情况选择恰当的方式。值得注意的是，和受访者建立良好的关系可以很好的帮助后续工作的开展。3）选取调研对象在资源允许的情况下，期望能够对接从领导层到执行层的所有主要干系人。当然，具体人员不是我们能确定的，但是需要拟定参与调研的角色和客户提要求。4）整理调研大纲提前了解客户基本信息，能够帮助我们设置调研大纲，包含调研思路和问题。需提前了解项目相关信息，整理业务场景中的问题；预设的场景会有偏差，要在调研时和客户确认。避免没有框架，造成调研不够全面。也可以准备需求调研表，便于做记录。2. 调研执行访谈式的调研不论参与人数多少，都是通过谈话的方式来进行。在执行中掌握访谈节奏和建立访谈框架是不可缺失的。1）掌握访谈节奏为了保障调研质量，需要稍稍掌控谈话节奏。同时根据客户描述调整自己的框架，提前准备的框架可能存在不恰当或缺失。2）建立访谈框架访谈内容应从整体到细节，从抽象到具体。可以从3个层面来聊：战略、战术、执行。战略：战略重要性不再赘述，调研首先明确项目在公司的战略定位和目标。项目也可能是企业战略的延伸的延伸，但是明确的定位和目标必不可少。战术：较为抽象的描述业务情况，战术决定了产品形态和管理模式。产品形态即产品如何运作，针对什么大场景做什么业务。管理模式即产品的管理策略，集中管理或分权管理，各方（大角色）能够参与什么任务。执行：下沉到业务执行层面，首先明确组织结构和角色配置，其次将角色代入到业务流程中，关注各环节各角色的任务来源，以及执行和交接的操作。3. 调研总结调研结束后一定需要输出完整的调研报告，表现形式不重要，目的在于调研情况的梳理和遗漏点的查找。1）现状梳理可以按照调研的层次，从战略、战术、执行不同层面进行梳理，将内容整理清楚即可。2）问题总结深入到具体业务流程，梳理当前整体及各环节存在的问题，并关注问题的影响面、紧急重要程度。3）总结报告输出报告后除了发送给内部相关人，也要同步给客户。注意和客户确认报告内容的准确性，如业务理解是否有偏差、问题梳理是否全面、问题优先级是否准确（可能因不同角色的关注点不同而出现偏差）等。4）其他补充并不是所有问题都要通过系统来解决，注意实物流和信息流的结合。现有的业务流程也不是一成不变的，而是随着业务发展和问题解决发生对应调整，带着发展的观念看问题。三、温馨的提示每个客户的访谈过程中都是不一样的，我们在访谈中围绕主题之外需要随机应变。基于过往经验，为了访谈顺利有以下几点需要注意：1. 从高级别人员开始访谈在和客户对接需求初期，建议先用高级别人员开始访谈。高级别人员不一定能提供最多的信息，但是能帮助我们从高层、全局的角度来看整个项目。帮助我们更好的把握主次关系，从全局到具体，避免一开始和执行人员对接后就陷入细节。访谈时可进行录音，便于结束后的内容回顾。2. 提前研究调研对象需要提前研究调研对象，是指尽早开始并保持持续关注。包含但不限于行业、企业、项目、关联业务、干系人。在关注项目干系人信息时，了解项目实施对不同干系人的影响，会出现推动力、阻力、或是脱离实际的需求等。因此调研是注意保持警惕，剔除干扰因素，不是客户方说什么就是什么。3. 保持和调研对象的联系访谈结束后需要建立和调研对象保持联系的渠道，便于后续工作中获得更多的帮助。几小时的访谈只能帮助我们大概了解业务的流程及客户的主要需求。后续重新梳理业务和需求时，肯定会出现信息缺失或待明确的内容。需要和客户进行多次沟通。不仅局限在需求澄清，在其他方便也会遇到需要客户帮助和配合的地方。本文由 @耳目不染 原创发布于人人都是产品经理。未经许可，禁止转载。题图来自Unsplash，基于CC0协议

写在前面大家好，我还是那个去年做了60个大屏页面的袋鼠云可视化设计师，这是《数据大屏设计师，我不信你没有这些困惑》系列的第二篇。这次就主要分享一个方面的心得经验 —— 数据大屏项目中的「需求调研」。还没有看过上一篇的童鞋，可以戳 下图去阅读：数据可视化大屏设计师，我不信你没有这些困惑！(上)好，开始营业！为什么大屏设计师需要加强关注「需求调研」首先，为什么我认为数据大屏的设计师，需要加强关注「需求调研」？这不是废话吗？你要帮客户画大屏，难道不该了解清楚客户想要什么吗？但事情并不是一句话这么简单。你注意看我写的，是“让设计师加强关注「需求调研」”，而不是“让设计师加强「需求调研」”，为什么这么写？因为在实际项目中，公司并不会让设计师直接和客户对接需求，而是让产品经理（往往兼项目经理）去和客户对接。说说有产品经理对接需求的好处（若无特殊说明，下文中的产品经理都默认兼项目经理）产品经理能更好地把控需求边界，综合评估客户需求、预算和公司能力、投入成本；产品经理比较（擅长和客户博弈，呸呸呸）擅长引导客户进行需求梳理和优化，为设计师安静地做设计提供了保障。其实反过来，设计师也应该学习一些项目需求的评估和管理，互相理解和成就。那么，这个话题实际要说的是 ——大屏的设计师为什么要关注产品经理调研需求？这不还是废话吗？产品经理对接完需求，接下来就是设计画大屏页面了，上游要是没调研清楚，下游怎么画得好？更重要的是，我觉得数据大屏设计师的工作更像是舞台设计/室内设计/PPT设计... 在项目中做的大屏是定制化的大屏，我们必须在前期对现场、硬件、客户需求有深入了解，才能作出让客户满意的东西；可以说，对于数据大屏这种侧重视觉设计的产品，从做原型规划时，就已经进入【设计阶段】了。坐在电脑面前把大屏画出来，只是“设计的执行阶段“，通过了解需求，知道设计这个东西的目的所在、侧重点所在、价值所在、限制所在，对于设计师是一种养分给予，能让设计师更好地进入设计执行。那么 ——设计师应该怎么关注“需求调研”？1、和产品经理“通气儿”。我想大家一定都会在设计执行阶段，遇到那种【因为前期没调查清楚所以很难进行设计决策的点】，这个时候，就要做一个成熟的设计师，想知道什么就和要产品经理说，让Ta去问，不要憋在心里做含糊的设计（我曾经就是不好意思说，最后开发完还是得改，累人累己），这样也能让产品经理得到“进步”，Ta会意识到【下次项目对接的时候，这些点是设计师关注的，要及时确认掉，避免后续麻烦】，这样项目才会越做越顺、越高效。2、设计师和产品经理要加强“原型规划”阶段的合作。大屏做多了就感觉像做装修，客户更期待看到的是对于内容布局、画面感的规划，所以项目经验不多的产品经理，往往会策划犯难，或者是策划得比较蹩脚，我想这时候，是需要一起来完成这份原型规划的。我们经常看到的大屏原型图大概是这个样子 —— 分好区，往里面粘截图或者用文字描述，但是对于设计师来说，画得太“粗”了，不够细致，往往不能及时发现问题。使用文字描述，很不直观，而且很容易造成误解；截图示意往往会存在数据量塞太多的问题，原型里硬塞下了，但在设计执行时，保证最小字号的前提下，很可能会放不下原型里规划的内容。项目背景对设计的影响项目背景，也就是客户做大屏的目的和期望。从大屏的使用目的来说，大致可以分成 3 类：「门面派」侧重汇报展示，就是要好看这类客户做大屏的主要用途是为了接待参观人员，对外进行企业形象展示，也有对内展示进行员工激励的（类似数字化的幼儿园小红花榜），想从大屏体现出公司的数字化建设和管理，展示一下公司的业绩成果等。对于这类需求应对建议—— 内容上，主次要足够分明，能形象通俗地传达数据背后的含义，例如公司业务发展到底有多好；视觉动效上能做出让人眼前一亮的效果；元素的使用上最好能结合企业VI和文化。配图来源：Easy[V]大屏模板 「实用派」侧重监控、数据分析，指标要全、维度要多这类需求会比较“务实”，一般是给内部的员工进行流程、现场、进度监控使用，或者是协助领导进行复盘、某个业务主题的数据分析。侧重这类需求的客户，通常不会对效果有很高的要求，而是重点关注他们的实际使用场景。对于这类需求的应对建议—— 一定要吃透他们的业务、指标内容，不然会全程只由客户主导，很被动；可以适当地减少装饰元素，突出指标数据的大小、状态；另外一个感触是，不要就简单地“重复造轮子”，要尝试作出优化，因为这类客户往往已有一套比较完备的后台业务系统，他们想“搬到”大屏上，所以很容易就变成了“照着美化了一遍”，会让设计过程比较“枯燥”；设计难点往往在于，比较较难挖掘可以做视觉主体的指标数据。配图来源：之前做过的一个运维大屏「雨露均沾型」这类需求想兼顾炫酷视效和庞杂的内容展示交互 —— 效果很炫，内容不能少。我感觉大部分的项目都是这样的目标心态，而且可视化行业里的大屏产品也是在朝着这个方向进步，所以要求大屏产品的性能、交互复杂度的支持都要跟得上。对于设计师而言，难点应该在指标内容的组织，以及场景视角、模块切换的动效设计上。Easy[V]申请试用链接https://easyv.dtstack.com/#jinwen 倾听客户的“蓝图”一般客户的对接人，会有自己的初步规划——要展示哪些指标，这就可以作为我们的【初代原型】。如果客户已经有自己的构想，我们接下来要做的不是基于他的构想进行设计，而是和他聊聊他的思路，不懂含义的指标，问清楚！你理解了客户的业务指标，你才能对客户的想法作出赞同或者改进，才能有自己的主动权，换个角度来说，才能体现专业性。对于一个陌生行业的项目，我们没有足够的时间和精力来摸清这个行业的全部方面，有的时候，你不得不承认，隔行如隔山，对于一些概念名词、业务逻辑关系，真的只有在行业里待过，才会了解，就像那个设计圈的梗“客户说：你不要用PS，要用PhotoShop”。所以，我们需要客户帮助来快速地了解他用到的业务指标和逻辑，反过来，客户本身也有义务协助配合乙方进行需求和业务调研，这样才能共赢，才能合作愉快。如果，不幸的话 ——遇到了毫无想法的客户，那就会比较“危险”打个比方，就像你刚到一家公司，老板给你一推数据资料，让你做成PPT，要体现公司今年的发展成果，你会很懵X，你不知道从哪些维度去入手，不知道自己挑选的维度是不是合适，不知道有没有抓到重点指标，这些都需要时间去反复核对，然后你就会加班 。所以，这里的“危险”意味着低效、被动。看似得到了“无限可能”、自由发挥，其实真相是你要花更多的精力去理清客户没有说出口的需求。不合理的需求与需求优化早些时候，我接到客户的一些修改需求时，会觉得emm*&#@... 实在是太不合理了，而且，为什么早不说？！后来，我们团队的人有一句话挺给我启发的 —— 你要去听客户话后背后的需求。也许他背后的需求是合理的，只是他告诉你的实施措施有问题。所以，希望大家也能在接到需求的时候，可以冷静深入思考一些，或许会有新的体会。（当然，如果真的不合理，那就别瞎想了）关于不合理的需求，我只有一点想说！不要以为大屏很面积大，就啥都想往上放！这个“温馨提示”还被我做为彩蛋加进了Easy[V]产品组件的预置数据里 。客户经常会比较“贪心”，对一屏页面上放多少指标内容没谱，这时候，反问自己和客户 —— 这些东西是必须同时看的吗？如果不是必须同时看的，考虑做交互切换；如果必须同时看，考虑按照重要次序做删减让位。怎么面对需求变更？就算前期把需求调研得再透彻，还是无法杜绝需求变更的发生。我们能做的，只能是尽最大的力量把不确定的因素降低，从而降低后期需求变更的可能性和修改成本。怎么面对呢？继续做好每一个流程的工作，及时发现、及时总结潜在的改稿隐患；周末集体去灵隐寺烧香祈祷接到的项目都一稿过；多囤点生姜洗发水 最后这次的分享到这里就结束了，下一期会分享大屏项目里的「数据调研」。 一些心声写这篇时，我去查补了”需求调研“方面的经验资料，试图将自己想表达的点包装得更全面化，但发现抱着这样的心态去写的内容，十分的“泛”、“百科化”，而且，为了显得理论完整而强加的东西，会让“写文章”变成“搬运”，这绝不是我想告诉别人的东西。我停下来反思之后，确认了两点：【自我瓶颈】以我现在的工作阅历和总结能力，并不足以写出全面的、洞见深刻的理论经验。【要放下包袱】我大概有点“端着”、“想装”，想被认为很厉害，这种心态会让我难以做到真诚。所以，我调整了心态——把自己经历过的、观察到的东西，尽量整理成思路清晰的文字，写下来就好。我认为大屏的“需求调研”，是完全可以从其他产品那里学习的，特别是ToB类产品。鼓励同行朋友们多看看，拓展自己的能力边界，或许会在大屏策划、设计时更有章法。