需求研究

需求分析让人头秃，笔者针对这个问题展开了通俗易懂的阐释，希望给大家以帮助。你有没有因为需求分析四个字，而感到头发日渐稀少？你有多少个失眠的夜，是在思考领导说的“把系统优化一下”这句简单的话？你又有多少次面对客户无休止的需求变更，而想要拔刀相向的冲动？这一切的背后，到底是人性的扭曲，还是道德的沦丧？朋友，你的福音到了，欢迎来到大型情感类专题：如何进行有效需求分析？左脑喜欢逻辑，右脑喜欢故事；最好的陈述一定是起于故事，终于逻辑。今天的内容，就让我们从一则生活中的故事开始吧。生活故事有一天夜里，资深需求工程师老余刚忙完一个重要的项目，带着放松的心情进入了梦乡。这时他年仅3岁的小孩夜里醒来，吵着要吃饼干。孩子的妈妈首先被吵醒，带着情绪训斥了小孩：“半夜三更吃什么饼干，好好睡觉！”没想到小孩不依不饶，继续哭闹着。不久老余被吵醒了，他安静地走到客厅，找了一小会儿，果然没找到饼干。他随手拿了两块吐司面包走进卧室，脸上掠过一丝自信的微笑。“小子，没有饼干了，吃点面包填肚子吧！”老余边说边把吐司塞到小孩手中。果然，小孩接过面包后就不再哭闹了，吃完一片就乖巧地躺下。不一会儿，老余家又归了平静。分析从故事中我们可以看到：小孩子提了一个需求，即要吃饼干。而妈妈考虑的是，家里没有饼干了，并且是半夜，想要实现这个需求的话，肯定还要起床下楼，并且找到24小时营业的便利店。这个实现成本太高了，于是断然拒绝。而爸爸则透过现象看本质，小孩子半夜要吃饼干，这并不一定真的是想吃饼干，极有可能是饿了。这样的需求，可以通过其他更易实现的方式更好地解决。于是，随手的两块吐司面包，就让这个家庭又重归了平静。典型的三类人群孩子=客户那你也许会问，为什么小孩子不能够直接说“我饿了”，而是一定要“吃饼干”呢？因为，这就是典型的客户思维方式。我们先给出这样一个结论：在方案级的探讨，客户是感性的；而在问题级的探讨，客户是理性的。你是否有过这样的经历：客户说，xxx功能我们想要，你给我们加一下吧。这样看似非常明确的需求，但往往很容易发生颠覆性的需求变更，到最后客户自己明确说明的这个功能，自己又把它给亲手砍掉。原因可能很简单，也许就是三个字：不好用。这种经历，能给我们带来什么样的启发呢？这句话很关键：客户是问题专家，而非解决方案专家，他提出的方案未必能够完美解决他遇到的问题。小孩子提出想吃饼干，这是一个方案级需求，这极有可能是因为小孩子脑海中突然回忆起了饼干的味道，并且小孩子才3岁，客户的感性思维，在这里体现的淋漓尽致；而小孩子饿了，这是问题级需求，这才是需求的本质。我们可以看到，以“吃饼干”这样的方案来解决“饿了”这样的问题，显然是不合适的。我们再来说客户的理性一面，当你跟客户沟通这样的话题：“在当前工作中，有哪些方面你会觉得有困难呢？”这个时候，你会发现，客户表达出来的内容，就像滔滔江水、连绵不绝，如黄河泛滥、一发不可收拾，并且还会加上各种事例来佐证他的观点。如果可以，他可能更希望拿个U盘，把他遇到的这些困难直接传到你脑子里。而这些内容，往往都是理性的，都是客观存在的事实。当然，这也是我们需求分析的突破口，我们后面也会提及。妈妈=程序员典型的技术思维，关注的是“方案级需求”，即吃饼干这个方案能否实现。我们脱离这个故事，在我们的实际工作中，究竟什么是技术思维呢？关注点：实现方式、技术架构、技术价值、开发成本。定义：从功能和工程实现出发，在满足产品需求的同时，寻找可复用技术架构和低开发成本。爸爸=产品经理典型的产品思维，关注的是“问题级需求”，即小孩子遇到的本质问题是饿了。同样，我们看一下在实际工作中，产品思维是怎样的定义？关注点：用户价值、使用场景、商业价值、业务闭环。定义：从用户价值出发，在满足商业战略和业务目标的同时，寻找产品路径满足用户需求。需求打开的正确方式通过开篇生活中的故事，我们可以体会到，要做好软件需求工作，业务驱动需求思想是核心。而作为产品经理或者是需求分析师，我们不是简单的“需求传递者”，我们是“问题解决者”的角色。那么，在与客户进行沟通时，需求打开的正确方式是怎样的呢？澄清问题→了解背景→建议并确定解决方案1. 澄清问题想要解决谁的，什么问题？用户现在遇到这个问题会采用什么样的解决方案？这个问题中有需要进一步细化和明确的概念吗？2. 了解背景该需求谁使用？什么时候使用？具体怎么做？有需要澄清的业务术语吗？它们的格式是什么？不做谁生气？多久生气一次？多久用一次？3. 建议并确定解决方案要解决这个问题有哪些可行的解决方案？这些方案的实现成本分别有多大？你觉得哪种最合适？该解决方案对用户而言有什么优缺点？有其他需要挖掘的需求吗？需求全景图写到这里，不由地想起之前面试的经历。面试官问我，一个产品研发完整流程分为几个阶段，每个阶段的占比是多少。我当时做了这样的回答：一个完整的产品研发流程中各部分的占比，大概50%做需求，30%做开发，20%做测试。然后，面试官紧接着问我，既然需求分析占比这么高，那说一下需求分析的方法论吧。我突然发现自己对于这方面方法论的研究几乎空白，只知道最终的产物，是利用Xmind列一个功能清单，但至于这个功能清单是如何得出来的，我当时的认知是具体问题具体分析。当我看到《有效需求分析》这本书中，提出了“需求全景图”的概念时，真犹如哥伦布发现了新大陆一般，不禁惊喜万分。需求全景图，包含了诸多内容，但自己感触最深的还是“功能主线”这一项，毕竟我们每天都在与“功能”打交道。回到我面试的那个问题，最终的功能清单是如何得出来的呢？最好的思考角度，就是厘清系统中的所有功能是因何而存在的，这也正是我们前面所说的，需求分析的突破口。功能主线的梳理，无外乎以下三个角度：1. 业务支持固化优化业务流程，因此业务流程是核心；业务延伸到新的通道（诸如手机端），这从本质上来说也是一种流程的重构，核心还是业务流程；将个人能力转化为组织能力，这种能力存在于具体的业务场景中，因此“专家场景”是核心（后续的文章会详细论述）。2. 管理支持事前风险避免，通过增加管理流程；事中风险控制，通过“规则”和“审批”；事后总结优化，通过“数据分析”。前两种通常会在业务支持分析中统一处理，第三种则应该独立进行分析。3. 维护支持系统投入使用之后，还需要对其进行维护，最典型的包括初始化、配置、排错等，而这些运营维护场景也都需要有相应的功能来支持。当然，功能是我们的最终落脚点，但需求分析不单单是功能，这里先把需求全景图展现给大家吧：结语需求不是一场简单的头脑风暴，也并非高深的诸如马斯洛需求层次理论，更不是领导交代的任务、运营提供的方案或是客户要求添加的功能，需求是一项系统的工程，更是一门生活的艺术。我们经常在电视中看到，古代的那些位高权重的大臣，几乎每一个都是需求分析高手，没事就在那犯嘀咕：“皇上今天说的这句话是什么意思呢？”由此可见，需求分析不仅仅是软件领域的方法论，更是存在于我们生活的方方面面，让我们一起探索需求全景图的奥秘吧！注：我们探讨的需求分析，是基于B端产品。当然，C端的小伙伴也是可以参考的。#专栏作家#智慧校园领域的B端产品经理。本文原创发布于人人都是产品经理。未经许可，禁止转载题图来自Unsplash，基于CC0协议

本文梳理了什么是做需求分析与需求管理，以及为什么要做与如何去做。01 概述本文是梳理需求分析与需求管理方法-产品经理工作职责&工作核心技能之一，笔者写本文的目的一是把自己的知识体系做个输出，包含来自己的经验总结和最近学习到的知识总结，其二顺便分享。知识方法无定论，任何内容先看思路，实战为主。在分析一个问题时，可以用一个通用的框架方法论，WWH法：是什么？为什么？怎么做？这样可以把思路理清晰。因此引出了本文的主要内容：什么是需求？为什么要做需求分析？什么时候做需求分析？怎么做需求分析？说明：时间有限，本文的案例不代表实战解决方法案例，更为了快速说明和应用方法而举例。02 需求定义1. 什么是需求？需是是用户在某种场景下的未被满足的期望。为什么要明确需求的定义，需求很容易被误解，这里我们要区分下用户需求和产品需求。我们的产品在未被定义之前，我们研究的需求是用户需求，我们通常也会叫作问题（没有明确的解决方案），当我们定义产品时，我们就要把用户需求转化为产品需求，提供具体的可落地的解决发难，才能实现产品。我要吃饭睡觉打豆豆，这不是需求，这种需求对于产品没有任何价值。看定义，用户需求是用户基于某种场景下的未被满足的期望，在这里提炼出需求的基本结构：用户+场景+期望。强调：需求不是独立存在的，是依附于用户+场景一起存在的。用户需求案例： 小明（用户），每天早上起床后就要赶着去上班，没有也不想在家吃早餐，但是到了公司就要工作，所以常常没有早餐吃，又饿又不健康（场景），小明又想多睡会儿又想在上班前吃上早餐（期望）2. 什么是需求分析？需求分析，就是挖掘和提炼用户需求，解决用户痛点问题，即找到用户需求，并把用户需求转为产品需求（解决方案）的过程。这里强调两点：找到用户需求解决用户问题案例： 还是小明吃早餐的案例，目前小明希望在上班前能吃上早餐这个是用户需求，只找到用户需求，没有解决方案，等于0，我们还要帮小明解决问题。如，提供早餐外卖，小明可以提前在手机上预定早餐外卖，一起床就有早餐可以吃。这是一个较完整的产品需求。03 为什么要做需求分析产品首先要满足的就是用户需求，为用户产生价值，才能创造商业价值。满足用户需求是产生商业价值的本源。04 在什么阶段做需求分析需求分析贯穿在产品整个生命周期。1. 产品概念期这个阶段做需求分析，更强调需求调研，目的是定位目标用户群，做产品定位，市场研究并确认细分产品市场。提炼产品核心功能，解决目标用户群痛点问题。 交付物：BRD需求文档。（或类似的相关的文档，如需求调研报告、市场调研报告等）2. 产品设计开发期这个阶段的需求分析，目的是要设计一个可落地的解决用户痛点，满足用户需求的产品。设计一个目标用户可用好用的产品。深层次的挖掘和分析用户，描述需求，解决问题。实现用户如何通过一步步的使用产品满足其需求。该阶段交付物：产品原型+PRD操作文档。3. 上线后-成长期上线后的需求分析，目的是验证真实产品满足真实用户需求的结果，收集用户需求，优化产品。4. 成熟运营期本阶段需求分析，目的在为产品提供更好的运营方案，制定竞争策略。让产品持续更好的更多的为企业创造商业价值。5. 产品衰退期当产品进入衰退期时，需求分析重在研究市场发展趋势，以帮助决策是调整发展战略。05 需求分析方法需求分析可以分为三大步：明确问题–拆解需求–提供解决方案。1. 明确问题明确问题之前，我们首先要从各方搜集需求，然后经过分析，提出真正的需求。需求获取渠道以下是我们常用的一手需求获取渠道：收集到的一手需求还不是真正的需求，要先进行一个清洗过程，把一些无用的无根据的站不住脚的异常的等等都过滤掉。具体过程不做介绍啦。明确问题（提出要解决的问题）这里一定要注意，提问题的标准：提出的问题要聚焦，明确、开放。不能泛，模糊。要又用户、场景、问题。还要明确该需求带来的价值。需求最终是要交换成价值的。正确的问题VS错误的问题：明确需求的价值：2. 拆解问题（需求）拆解需求指的是把已经明确的问题，从多个维度进行拆解，目的就是为了找到更合适的解决方案。 该方法是某课程老师总结的拆解方法，笔者认为非常好，非常清晰和明确的一个方法，这里直接引用。（该方法也是老师对《六顶思考帽》里的解决问题方法做的灵活应用，同时书也推荐给大家）拆解问题的5个维度：积极层面：通常可以拆解出怎么做对用户来讲可以产生更积极的情感。否定层面：通常可以拆解，即使不做什么，依然可以产生好的结果。转移层面：转移指的是不直接单独解决当前用户的问题，通过转移法，用户转移、问题转移等。拆解：把当前问题刨根问底的拆，挖掘更多的可能性、找到问题本质。脑洞：这个更多的靠灵感、经验等进行头脑风暴，补充其他维度考虑不到的地方。案例： 问题：某视频APP，用户次日留存率低于30%，需要提高次日留存率 拆解过程如下图：注意在拆解问题的时候，不要去考虑能不能实现，先去拆解一切想到的问题，最后在分析解决方案的时候再来进一步筛选。3. 提供解决方案问题拆解完后，对所有提出的问题列出解决方案，这里注意，一开始思考解决方案的时候也不要去考虑实现的可行性，尽管去提供。等所有的解决方案都列出来之后，再进行方案分析、评估、排序。06 需求管理需求管理指的是如何安排已经明确产生的需求，工作中我们通常会遇到四面八方包括产品经理自己给的需求，但是资源和精力无法让做到有求必应，我们需要去把需求做一个分类和排序，尽可能的去做性价比高的需求开发。 这里我们介绍几种方法，帮助我们做需求分类和排序。1. Kano 模型KANO 模型是东京理工大学教授狩野纪昭（Noriaki Kano）发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。Kano模型把需求分为5类：基本型需求该类需求代表的用户的核心痛点，是产品的必备功能，如果没有该功能，用户会极度不满，甚至不用你的产品。但是如果有了该功能，用户并不会对你的产品的满意度增加。如微博的发布微博功能、社交APP的聊天功能、共享单车的开锁功能等。期望型需求这类需求代表的是用户的痒点，代表的是品质，对用户来讲是最好有的功能。好比我们的生活，我们都期望我的生活是有一定品质的。拥有此功能，用户满意度会明显提升（过的还可以），没有此功能，用户满意度会明显下降，但是凑合可以用户（过得下去）。这种需求一定要去努力挖掘和分析，并做好。代表了产品的竞争优势。如社交软件的语音聊天视频功能。兴奋型需求这类需求所在暗处，用户自己都想不到的需求。拥有此功能，即便表现的并不完善或完美，用户满意度也显著提升，但即便没有此功能，用户也并不会对产品对满意度降低。如，在微信刚刚推出红包功能的时候，这是一个非常典型的兴奋型需求。无差异型需求该功能对用户来讲，是不痛不痒的需求。可用可不用，有或者没有都不会影响用户的满意度。如，我们在设计某个按钮，是20px，还是22px，是第一个还是第二个位置。无论怎么做，对用户并无明显影响。我们就尽量不要去花精力在这上面，只需要执行任意一种即可。反向型需求该类需求提供对应的功能后，用户会对产品的满意度降低。该类需求，最好不做。如，前段时间上热搜的一款监测学生上课是否集中注意力的智能科技“紧箍咒”，得到的是网友几乎一边倒的差评和抵制。Kano模型实施方法：如何评估需求属于Kano模型中的哪一类需求，我们可以实施以下方法：Kano模型问卷调研法 可以直接设计问卷调研，通过定量问卷调研得出需求属于哪一种：按照上表的格式，对每一个功能做一个的调研，充分收集用户的数据并得出结果。2. 时间管理四象限法本方法可以快速帮助我们评估需求开发的时间优先级。从紧急重要程度两个维度比较合理的帮助产品有条理的安排开发秩序，避免盲目排序。3. ICE排序法ICE排序法也是一种比较严谨科学的需求排序方法，通过从几个维度考虑给需求打分，以总分高低去排序。I（Impact）：影响范围C（confidence）：对上线效果的自信程度评估E（ease）：开发难易程度（工作量+技术难易程度）评估应用实例：本文由 @娟姐 原创发布于人人都是产品经理。未经许可，禁止转载题图来自Unsplash，基于CC0协议

第一篇文章《需求分析师如何分析需求》蜻蜓点水讲了下如何分析功能性需求，也是由于想的不够深入，经过这段时间的需求分析总结，此篇文章将更详细的讲解如何分析功能需求。对于功能需求的分析主要从两方面入手：业务场景和系统界面。一、业务场景什么是业务场景？场景是我们设计功能时的一个重要参考依据。所谓场景，就是用户在进行这步操作时所处的周围环境。这里的周围环境包含的维度很多，比如用户的属性，年龄、身份、工作等。场景不仅指物理环境，比如在车上、飞机上、教室里，还指任务场景，比如开空调的业务场景是因为夏天很热，需求是身体凉快不热。任何产品都是一种物质存在，要使其有意义，就应该置其于恰当的社会环境中，而且这种环境与其他工具或人密不可分。可以通过一个表格来描绘业务场景，比如描绘信评人员在财报更新的时候需要做跟踪评级。为了保持寝室卫生，大学几个室友在寝室决定轮流打扫寝室卫生用户在提需求的时候，多问几个为什么，为什么要提这个需求？目前是遇到什么困难？现在是怎么做的？如果涉及到业务数量的，还可以问下量大不大？比如某公司就只有一个客户做某业务，为了这一个客户去开发一个大功能，浪费人力、物力甚至造成项目延期。但也不是说，就不做，如果后续做这项业务的客户会越来越多，开发功能是需要的。将用户提出的需求业务场景梳理清楚后，接下来就是需要过滤用户的需求，有时候客户提出的需求并不是“真”的需求。很多时候因为客户自己本身对业务的不了解或者对行业知识不了解，基于某些情况，客户提出一些假需求，客户提出“假需求”的情况有：客户对自己本身对业务或行业上的知识不是很了解；客户基于“花少的钱获得更多的功能”心理提出很多个性化的需求；客户在提需求的时候有时候也会撒谎；客户不知道自己要什么导致假需求的产生。识别客户的需求到底是不是真的需求，最重要的一条是识别客户提出需求的动机，知道为什么客户会提出这个需求？（又回到业务场景的问题了）知道客户提出需求的动机以后，多问几个为什么，如果客户在回答问题的时候前后不连贯，或者没有逻辑，这类需求往往就是假的需求。在过滤掉客户假的需求以后，需要知道如何去表达需求，为了使需求更连贯和完整，建议采用“情景场景剧本”的方式来表达需求。把需求当成一个情景剧，有人物、有业务场景、有目标、有故事背景、有做事的动机、有情节等，可以用语言或者图形的方式将故事描绘出来。如果发现故事中有些情节是是断裂的或者是讲不通的，那有可能你的需求并没有真正弄清楚，需要重新去梳理一下你的这个需求。二、功能界面将用户的需求理解清楚后，只是脑海中或者文字的说明，需要更形象，通常是除了文字说明还需要画原型图，很难理解的需求，画出系统界面后，开发人员能一下子看明白。功能界面需要将每个功能按钮、查询条件、交互方式、以及界面上字段的类型、取数来源、排序等都需要细化。画原型图的工具用的比较多的是Axure。以上是画的比较好的原型图，连滚动条和翻页都考虑到了，可以说是比较具体的，开发人员一看就知道要怎么做。

马斯洛需求层级理论也好，Y方法论、Z方法也好，归根到底都是一些思考框架和方法，如何把握需求、提炼需求，还是需要我们在真实的环境中多聊、多看、多做。无论是市场营销还是产品设计，“需求”这个词，是最频繁被提及的词汇。在市场营销领域，无论是新的产品的研发设计，还是制定推广活动方案，我们需要做的是“消费者洞察”。所以市面上有大量的调查公司，帮助品牌通过问卷、焦点小组访谈等方式，收集用户反馈，以求获得insight。近些年，随着互联网行业兴起和产品经理岗位的火热，“需求”一词有反复被提及，需求分析成为产品经济的必备技能之一；在“人人都是产品经理”上搜索8,226条结果。马斯洛需求层级理论也好，Y方法论、Z方法也好，归根到底都是一些思考框架和方法，如何把握需求、提炼需求，还是需要我们在真实的环境中多聊、多看、多做。需求的第一个层次：需求的忠实记录者腾讯推崇产品文化，其有一个著名的「10/100/1000法则」：即每位产品经理每个月必须做 10 个用户调查，关注 100 个用户博客，收集反馈 1000 个用户体验。于是，很多产品经理，特别是刚刚进入产品领域的新手，每天将“用户需求”、“使用场景”这些词挂在嘴边，并践行腾讯的「10/100/1000法则」，每天都在记录用户的反馈和槽点。能坚持倾听用户反馈并记录用户需求，固然不错，然而这还不够。举一个小例子。早些年，针对B端广告主制作视频素材的需求，做了一个小工具，小白用户选定模板之后按规定上传图片或者视频，就可以渲染出一支质量还凑合的视频，并且可以直接推送到投放后台。然而，很多广告主在后台留言，希望能开放下载功能。这个时候，我们就面临着一个选择：是否需要开放下载？需求的第二个层次：需求的挖掘机多问一句Why，发掘需求背后的动因。通常情况下，用户通过语言或者文字表达出来的，只是最直接的功能指向。每一个功能指向背后，都暗藏着一个刺激因素，这个刺激因素才是用户真正希望解决的问题。如果不能挖掘出需求的来源，那么产品经理基于此设计的解决方法，也不会真正解决用户问题，或者给用户的解决办法不是最优解。接着上文提到的开放视频下载功能为例。用户希望下载视频，而不是我们此前设定的生成→推送的使用路径，必然是在这个链路中某（几）个出了问题，并提出了以下2个假设：视频质量不及用户预期，用户下载下来之后，会进行重新剪辑；视频推送到投放后台的时候有问题，导致用户希望绕过这条链路。针对第一个问题，我去看了用户最后使用的视频素材，发现并没有二次加工的痕迹，即下载下来的视频是什么样，在投放时还是什么样。也就是说，视频质量并不是造成用户希望开放下载的原因。于是，我找了有类似需求的用户一一聊，问他们下载下来之后，会有哪些操作。答案竟然出奇的简单：下载之后，对视频重新命名，然后重新上传，因为在投放后台中视频素材量级非常大，之前推送之后，经常无法跟已经在库中的视频区分开来。需求的第三个层次：系统地思考需求每一个产品都可以视作一个小的系统。系统由元素、元素间的关联和目标构成。当我们收集需求的时候，更多地是在关注元素，经常会忘记元素间的关联和整个产品的目标，也即“一叶障目，不见泰山”。我们针对用户的反馈，做出了完善的解决方法，然而基于该方法的功能上线之后，会不会影响到其他功能？会不会有其他连锁反应？苹果一向被视作设计的标杆。然而其一款鼠标的充电口却在鼠标下方，导致充电的时候无法正常使用。当然，有些人视作是为了追求极致的美观，但是牺牲用户体验的美观，是否是最优选择？再比如我们经常吐槽的家庭中的插座，两孔与三孔的插孔经常不能同时使用。上次我在网购时，吊起某支付软件时，我突然想起要买另外一个商品，于是双击Home键想回到电商App中，结果指纹识别成功成功付款了。这样失败的案例不胜枚举。这里额外啰嗦几句。现在互联网产品中的分工越来越细致，一款App会按照功能模块进行拆解和分工，每个功能点都有专门的人负责。细致分工的好处是，每个功能点的体验都可以做到机制，然而如果没有一个产品整体负责人进行整体把控，是否一定能保证1+1>2？一个真正优秀的产品，必然会有一个操盘的产品经理，TA拥有生杀予夺的权力，决定某个功能点更新的方向、与其他功能点如何兼容、联动。TA负责顶层设计，然后在这样的框架下，某个功能模块的负责人各司其职，这样才能保证产品的体验和目标的唯一性。以上说了这么多，那么究竟该如何把握需求呢？要点1：放下高傲，培养同理心不是用户傻，而是你的产品设计失败。很多时候，产品经理有一种执念，认为自己的设计师最完美的，用户反而是需要教育的。这样的心态，不仅在产品新人身上可以看到，即使拥有丰富产品从业经历的人，也经常散发出这股谜一般的自信。看到用户吐槽或者差评时，不要气馁、不要悲伤，更不能气急败坏。这是在做产品分析时候的大忌，一旦先入为主，就不可能真正听进用户的需求。马化腾说切换成“傻瓜模式”，就是从普通用户的角度去思考你的产品。而这就需要我们积极培养同理心与共情的能力。每天我们都会遇到无数烦心的事情，产品上的糟糕体验只会加速用户逃离。要点2：观察用户做了什么而非说了什么情感专家会对恋爱中的少男少女们谆谆告诫：“判断对方是不是真的爱你，不要看TA说了什么，更要看TA做了什么”。有时用户会说谎，前几年我在美国拜访一家知名的电视台，那时候正直美国大选年。他们总编跟我们开玩笑说：我们做用户调研，每个人都说自己最关心的话题是政治和大选，但是他们阅读次数最多的还是Taylor Swift分手的八卦。市场调查中，会提到焦点小组访谈法和深度访谈法。最让我着迷的不是访谈提纲设计、主持人选择等，而是单面镜的设计。通过单面镜，你就可以观察一个人的真实行为和表情。如今，App中都有丰富的埋点，可以记录用户的行为数据。这些行为数据是用户表达真实喜好的重要宝库，与其花费很多时间去做用户访谈，不如多花一点时间，做好细致的行为数据分析。举一个市场营销的案例，这个案例也是在网上学习时看到的。Dove多芬希望推出中国女性的品牌营销活动。他们与百度合作，分析了用户在搜索多芬时，一般还会同时搜索哪些关键词。数据分析发现，用户在搜索多芬时，关联最多的词都与年龄相关，如“多芬适合多大的人用”、“多芬适合30岁的人用么”。多芬与年龄贡献的比例，远高于竞品。基于这样的消费者洞察，多芬发起了“hold住25岁”的营销活动，明确定位自己消费者的年龄层次。做好需求分析，没有捷径，多看、多聊、多想而已。作者：余子申；公众号“简写2019”本文由 @余子申 原创发布于人人都是产品经理。未经许可，禁止转载题图来自Unsplash，基于CC0协议

编辑导读：产品界有这样的一句话，用户想要墙上的洞，而不是钻墙的工具。产品经理要善于发现用户的需求，并且根据用户需求调整产品。但是，用户表达的信息就一定是真实的需求吗？本文作者基于自身经验，从四个方面分析如何更好地洞察用户需求，希望对你有帮助。时隔半年，2020发生了太多事，也让很多人认清了现实，这篇文章是对上一篇的一个拓展，也是对自己工作的总结，也是产品经理的一个核心能力，所以决定慢慢写出这篇文章。献出自己喜欢的一句话“现在的你就是最好的你，就是你过往所有经历带来的认知结果”，所以欢迎大家指导。正文开始。不管是什么类型的产品都会涉及到用户，涉及到使用其产品的人，但用户和客户的区别是什么呢？如果用一句话描述，那就是：用户是直接使用我们的服务，而客户是买单付钱的人。我们需要搞清楚哪些是会使用服务的人，哪些是会买单付钱的人，这样有助于想清楚商业画布中的场景，以及在以后的选择上，应该覆盖什么样的用户。一、怎么区分用户和客户我们先来看一个关于用户和客户的小故事。周鸿祎曾经提到，当年360儿童手表刚推向市场时，只有定位功能。因为当时小孩被抱走的新闻层出不穷，很多家长对孩子的安全问题充满了担忧。于是360儿童手表为了满足家长电池的长续航需求，必须极大程度缩减手表的其他功能，仅留下了定位功能。当他们把这个手表投放到市场后，一开始产品卖得不错，但是手表初次使用之后的活跃度特别差，没什么家长在用。这是因为从一开始项目团队就认为这批手表仅满足家长的要求就可以，而忽略了真正的用户“孩子”的需求，因为一款只有定位功能的手表，实在难以讨得小朋友的欢心，认为“这是我妈妈想要用的，可我一点也不喜欢。”其实一开始360就进入了一个关于客户和用户的误区。当产品经理开始意识到，原来手表真正的用户是小朋友，于是重新基于小朋友的喜好，在手表上迭代了例如：打电话、小游戏这样的功能。当小朋友可以用手表电话跟父母沟通，添加周围的小朋友为好友时，这款手表才真正建立了和用户的关系。与之相反，我们曾提到过一个产品，任天堂的Switch游戏机。任天堂在2018年发布了一款产品Nintendo Labo，这个游戏机的纸箱套装可以和任天堂的Switch游戏机配套使用。玩家可以将任天堂的Switch游戏机，插入到一个个形状各异的卡牌纸盒中实现不同的体验，比如钢琴、鱼竿、 摩托车、小房屋、遥控装置等玩法。任天堂这样做的成本并不高，但看起来酷炫十足的产品同时兼顾了用户和客户。我们必须要考虑我们的内容所面向的用户到底是谁，要重点关注的用户和客户这两种角色的观点一脉相承。任天堂通过纸板的方式把游戏机包装成了一个寓教于乐的产品，很好地说服家长，这是一个富有创意的产品，可以锻炼孩子的动手能力、想象力，不仅仅是游戏机更是一个教具。任天堂游戏纸箱案例图关于Switch，还有一个非常有趣的设计，由于家长给孩子买游戏机时，十分担心游戏机当中小小的游戏卡会被孩子误食，造成危险，于是任天堂在游戏机的卡带中添加了号称是世界上最苦的原料，无毒无害的苦味添加剂苯甲地那铵，孩子如果不小心把游戏卡往嘴里送，舔一口就会被苦味刺激。有趣的是，很多家长收到这款游戏机的第一时间，统一姿势都是拿出游戏卡带舔一下，据说上市三天时间，就被添了千万次，那酸爽滋味大概是能让人浑身颤抖一下再干呕的那种，于是又有很多家长纷纷表示，的确很苦，这个小话题再次形成了这款游戏机在用户群体当中的传播。可见，站在用户去重新打磨产品细节时，不仅更能说服用户，也更能说服为之买单的客户，还有可能会带来预期之外的传播与影响。二、用户表达的信息，不一定代表他们的真实需求用户表达的信息，一定是他们真实的需求吗?不一定。不然世界上怎么会有 “口是心非”这个词。用户想要的不一定是用户会付费购买的，用户说想要的也未必是用户内心真正想要的。有些产品，我们认为是自己想要的，用了之后才发现并不是。我曾经预订过一 段时间的健康减肥餐，我认为自己的需求是减肥控制体重，可当真正吃了一段时间之后发现，我有一个优先级更高的需求，那就是餐食的口味。所以，需求并非是独立存在的，有对比才能发现自己以为的需求其实并非自己真正最想要的需求。每日优鲜创始人徐正也分享过一个真实的故事：当时很多用户都反馈希望买到帝王蟹。于是，每日优鲜的产品经理就提议，干脆采购一些帝王蟹，将帝王蟹纳入每日优鲜的售卖范围。但是徐正否决了这个想法，原因是，有多少家庭主妇能在家搞定帝王蟹这种庞然大物?用户想要吃帝王蟹，并不代表想要买一只活的帝王蟹。所以用户想要的东西，不一定是用户会要的东西。我们需要从产品思维的角度去思考，用户想要的到底是什么?三、怎么更好地洞察用户需求产品需要依循的两大原则。抖音、拼多多、瑞幸咖啡，应该是近来增长最快的火爆产品。在这些火爆产品的背后，其实是有产品规律可依循的。可以发现，在产品方面他们遵循了两大原则：第一个原则：好产品要么节省用户时间，要么消耗用户时间。淘宝刚诞生时，它的目的是为了节省用户时间，让用户更快速地买到产品。不使用淘宝时，用户为了买一个东西可能需要花一个下午时间逛街寻找、反复砍价比价、选择，但使用淘宝很快就能足不出户完成找到商品、比价、下单。但随着淘宝的发展，开始有更多形形色色的产品在平台上出现，它开始不断地为用户推荐更吸引他们的产品，对某些用户而言，反而变成了消耗用户时间的产品。很多女生每天打开淘宝，刷一刷淘宝推荐的猜你喜欢的商品，欢欣雀跃不断向下翻页，于是大把的时间在指尖流逝。好的产品会至少符合其中一条属性，当然更好的产品同时符合两条属性。所以我们在设计产品时，更多地要去想我们的产品可以如何帮助用户节省时间，可以如何让用户沉迷，让用户喜欢从而消耗更多时间。第二个原则：直接把价值和结果传递给用户，而不是把过程、工具、材料给用户。比如前面提到的帝王蟹的故事，用户想要的是吃到帝王蟹，但并不代表用户想要将帝王蟹大卸八块的过程。在产品经理的圈子里，流行着这样一句话：用户想要的是墙上的一个洞，并不是钻墙的机器。从产品思维的角度出发，我们提供给用户的产品，应当是结果，而不是过程中的工具和材料。以上两个原则，可以帮助我们判断，我们设计出来的产品是否符合好产品的标准。第三个原则：第一人称视角感受需要。之前所以有摩拜单车，是因为创始人胡玮炜当时在上海、北京出差时，觉得特别不方便，下了地铁面临着1公里以内这种不远不近的距离，非常尴尬，当时的她特别希望有一辆自行车可以替代掉这种游走于步行和打车之间的需求。于是，在创办摩拜单车之前的很长时间里，她都在思考如何解决最后一公里的交通的问题。这个产品应该长什么样子?车辆是否可追踪、是否遍布地铁口、用户以什么方式开锁骑自行车、怎样结算?围绕着要解决的问题和要交付的产品价值， 她以第一人称的视角，从自己的需求作为出发点，打磨出这样一款产品。丰巢的诞生也是源于快递小哥，在没有这个产品之前，工作中让快递小哥最痛苦的事情，并不是发短信用户不来取，也不是要等待用户太长时间，而是在这等待的过程中，不方便短暂离开，因为担心包裹会遗失。连放心上厕所、吃饭这种最刚性的需求反而是快递小哥未被解决的痛点。创始人和产品团队在与快递员共同生活和工作中，察觉到了这个重要的信息， 于是上线了一款产品，让大家都有一些自己的时间。想要更好了解用户的需求，首先要用第一人称视角去感受用户到底需要的是什么。第四个原则：正确方法进行需求调研。调研与分析，一个主观的自己，只能代表一小群人，所以当站在第一人称视角去洞察用户的需求是为了确保我们对用户需求理解的准确性，就要通过调研和分析来验证我们对于需求的理解和判断。足够专业的调研分析，能够得到我们想要的信息。那如何进行专业的调研分析?有两种方式：定性调研分析和定量调研分析。定性调研分析，当去分析用户需求的时候，定性调研分析的结果应当输出用户画像。我们的用户是一群什么样的人，他们有什么喜好，他们会在什么样的情况下使用我们的产品和服务？在定性调研的时候，需要遵循3个原则：一是问题要开放、要深度。不要让用户的答案是“是”或者“否”，这样封闭式的问题，无法得到我们已知以外的答案。二是鼓励用户多讲述。三是避免诱导性问题。比如“如果我们提供这样一个服务，是不是一个特别好的服务?”，类似于这种，就是诱导性的提问。定量调研分析的目的，是输出用户需求优先级的分布。我们在洞察用户需求时，也许能够洞察出来很多种用户的需求，比如在打车这件事情上，需求有快速打到车，车要干净、安全，支付要方便，能开发票。这么多需求，优先级在哪里？这个就是我们在定量调研分析当中需要得到的结论。在定量调研的时候，也需要遵循5个原则：避免专业词汇，每次只提一个问题；避免笼统抽象的描述，尽可能使用大家理解清晰的客观描述；避免敏感问题；避免主动引导；避免笼统抽象描述，是导致很多调研得不到准确答案的重要原因。有时我们会去问用户一些笼统的问题，比如:“您对我们所提供的服务的感受如何?”。如果我们要问用户对我们的服务是不是满意，以更客观的调研方式来说，可以给用户5个选项:我们的服务是否满意到了让你愿意介绍给你的朋友?我们的服务是否让您 满意到了你愿意在应用市场给我们五星好评?我们的服务是否让您满意到了愿意再次使用？我们的服务您综合下来会打几分?我们的服务在速度、态度、品质几个方面，您分别会打几分?把问题尽可能客观描述，这样能够更明确用户对于该问题的真实态度，和其中的细节反馈。最后一个原则：MVP验证，做完用户需求洞察以及定性、定量的分析之后，我们还需要将我们洞察和分析之后的需求，梳理规划成具体的产品功能，然后从其中筛选出来用以测试的MVP，进行再次验证。假设我们是共享单车的团队，在以第一人称视角洞察到用户的需求，并且完成了一系列的定性定量调研分析和产品规划设计，这时要验证共享单车项目是否可行，最便捷的办法是先找五六辆自行车免押金租给用户，以人工方式收2块钱的单次使用费， 看是否有人愿意使用。我们做产品时，一旦开始开发，不管是什么样的产品，都涉及了一系列的成本，所以要先找到最小的MVP，验证可行，再开始花费成本。当完成用户需求洞察，也做完了调研和MVP，对自己的产品多了自信，基本证明想法是靠谱的，就可以从想法走向产品生产环节。四、最后需求自检清单：我是在满足用户真正特别想要的需求吗?在我提供的服务之前，用户有别的选择吗?对别的选择是否有不满的地方?如果有不满，用户愿意做出调整吗?当用户愿意做出调整时，我提供的服务是不是第一选择?当用户选择我的时候，我是否做到了扬长避短?除了不断自检我们对用户需求的理解，做一款真正产品时，我们还要通过定性和定量分析，更深入了解用户真正想要的东西到底是什么？什么是影响用户愿意选择产品和服务的主要原因。作者：胡子邯；公众号：产品经理的日常思考。本文由 @胡子邯 原创发布于人人都是产品经理。未经许可，禁止转载题图来自Unsplash，基于CC0协议

产品经理的工作从需求开始，只有开好头，才能把工作真正做好。产品经理是一群高情怀、高智商的积极分子。为什么这么说，因为他们总怀揣着梦想，想要通过自己的智慧打造出能够改变世界的产品，即使前行的路上充满艰难险阻依然满怀热情。产品经理的工作都是从需求开始，但是请不要一开始就错了，最痛苦的事情，莫过于一条路走到黑最终满盘皆输。今天，我们就来谈一个问题：什么是需求分析的最高境界？我们直接进入正题，需求调研的最高境界莫过于以下三点：实现价值导向；把握个体或集体人格；抓住产品机会。一、不要谈“目标导向”要谈“价值导向”一般的产品经理拿到需求后，就直接针对需求所要达到的目的进行各种分析和用户调研。这样的做法很容忽略这个“需求”在整个产品乃至整个生态的价值体现，即使达到了需求最初设定的目标，那么它在整个产品体系中，提供了什么样的价值呢？判断一个需求如何做，不应该通过目标导向，而应该通过价值导向来进行衡量。比如，你在设计订单系统中的一个子功能“改单”，你的leader给你的目标可能是实现订单的修改和维护，这个是最直接的目标。但是，把这个功能放到整个系统的价值链中，“改单”绝对不是一个简单的功能。首先，订单系统是一个业务的生命线，它的价值在于准确体现经营的信息流、资金流，降低财务风险，提高售后效率。你在设计改单功能的时候，就要充分考虑信息流的效率以及资金流的风险，自然而然就会考虑到，改单的审批流程和效率的平衡，以及涉及到的财务流程，包括退款、退票等一系列问题点。只有做到“价值导向”，才能站在全局的角度去思考，让需求在价值链路上的发挥出它应有的价值二、把握“去角色化的鲜活个人特征”或“集体人格”首先，我们来将2个概念“去角色化”、“集体人格”。员工在职场经历职业的各种方法论的培训，长时间投入专业的工作中，被驯化为一个个的角色。不管你是销售、客服、产品、运营、技术，都不例外。在专业分工上，每个角色的思维都会被固化，一旦进入公司，立刻就会被角色化，体现出角色化的应激性思维。去角色化，就是我们要卸下对方的角色化思考，将对方作为一个真实、完整、鲜活的个体来进行观察和接纳。上面我们说到，在工作中，每个人都扮演着某一种角色承担某种职能，而集体就是某种职能角色的聚集。集体人格所体现出的共同记忆和核心观念，便是需要深入研究的对象。如果你的产品的使用对象是一个个的“个体”（更多的是C端产品），那么就必须抛开对个体角色化的刻板印象，而把对方当成一个完整的、鲜活的人去研究；如果你的产品是针对某个特定的集体，那么你需要充分研究这个集体的集体人格、共同记忆和核心观念。三、痒点、痛点、爽点都是产品机会我们经常会讨论一个词叫“痛点”，很多初级产品经理对痛点、痒点、爽点，这3个需求层次有些混淆。首先，我们来看“痒点”，什么是痒点？就是不痛不痒的需求，你解决了当然非常好，不解决用户当前也能接受。再说说“痛点”，怎么才会痛？只有让用户产生“恐惧”的才可以称之为痛点。那么什么是爽点？爽点就是超出用户预期，让用户产生兴奋。“痒点”、“痛点”、“爽点”都是产品的机会。在需求过程中，需要有策略性地来进行实施。比如初期，着重用针对“痛点”来解决主要矛盾；中期用“痒点+爽点”来完善产品，让用户处于兴奋状态，提升整体产品的活跃度；后期通过不断的微创新来提高商业变现，各种组合拳的应用方能突破产品机会的边界。本文由 @长弓-PM 原创发布于人人都是产品经理。未经许可，禁止转载。题图来自Unsplash，基于CC0协议

拿到需求却不知道怎么办？这可能就是很多产品人的痛点，作者在本文阐述了自己的需求分析方法，供大家学习和参考。公司开启了每周知识分享环节，正好可以激励自己每周输出内容给咋们实习生做分享。本周分享的主题是实习生提出的一个实际工作中遇到的问题：如何准确把握用户需求？什么是用户需求？用户需求是什么，很多人有各种天花乱坠的解释，而我个人对于用户需求的定义很简单，就是用户认为他需要的就是用户需求。其中用户需求分为这几种，比如痛点需求、爽点需求、痒点需求。那么，他们之间的差别是什么呢？痛点：用户非常急迫想要解决的一个点。梁宁大大用“恐惧”一词做出了解释。比如我很胖，我害怕自己继续这么胖，所以减肥对我来说是痛点。爽点：这个点没有解决用户会难受，如果解决了，满意度会大幅度提升。其中注意的就是，要即时满足。如果这个爽点需要很长时间才能解决，那就不能让用户产生“爽”的感觉。痒点：可以满足人的虚拟自我。比如网红卖衣服，我穿上她的衣服就好像可以和网红一样美一样。PS：上述的几种需求类型均可以作为一个产品的价值点，并不是只有痛点才能做的。在哪些情况下我们会分析用户需求？为什么这个问题会单独列出来作为一个章节进行讲解，是因为我的实习生们在实际工作中存在一个很严重的问题，没有保持用户需求分析的习惯。不是只有做产品功能时才需要分析用户需求的，做运营也需要，用户需求分析可以用在产品框架的搭建，也可以用在一个活动文案、活动奖品怎么设置上。只有当你理解用户，你做出来的东西才能足够吸引你的目标用户，也有助于提升你的活动数据。如何准确分析用户需求？在思考这个问题前，我们先思考大家一般是用什么思维模式来进行判断的？我们一般是根据什么逻辑进行用户需求分析的呢？我用一个案例（反面）来讲解这个流程吧：第一步：老大给我布置了任务，我要做一个拉新活动。基于这个目的，我开始了活动的思考。第二步：最近抽奖好像挺火的，上一次我看到抽奖奖励锦鲤红包很多人参加（信息的获取：经验）。第三步：既然这样我也做一个锦鲤活动吧！第四步：开始制作锦鲤活动方案。以上的思考流程是很多初学者经常使用的方式，且不说这样的思考比较浅。在上述的思考流程中，并没有意识到存在几个重要的问题：我们在进行判断的时候，目标是否明确？我们决策时信息、假设从哪来？这些信息和假设的涵义你理解的对吗？你采取的推理方式正确吗？如何明确需求目标我们在做运营的时候经常遇到这样自嗨型的情况：这个活动为什么数据这么低？分析了一堆数据得出这次的活动不是很吸引用户，下次不做这类。为什么这个内容没人看？分析了一堆数据得出不匹配目标群体喜好。很多时候我们把做分析时的目标，定义成解释一个东西为什么不好，你为了解释而解释，目标定义错误，得出的结论看似有道理。但是你依然不能保证下一次活动、下一个内容数据就能起来。做需求分析的目标，应该结合产品的核心目标去判定。即是否能为用户带来价值？能带来多大的价值？举个例子，一道腾讯的面试题：作为微信方，怎么帮助微信生态中的小商户去运营顾客？大部分人看到这个问题，就开始点状思维回答。比如说可以优化小程序呀，做优惠券呀。看似你的回答很正确（确实是对的），但是作为一名优秀的产品经理/运营，光回答正确还不够，还需要深度思考，让回答全面且具有深度。所以根据上面我们的思考流程，我们先要确定这个问题的核心目标。这里给小白同学们一个思考题，这个题的核心目标是什么？优化微信生态中服务小商户的能力？优化小商户运营顾客的服务工具？我的回答：核心目标是思考小商户如何利用微信生态体系更好的给用户提供价值，并达到小商户本身的商业化目标。找到目标后我们很容易找到我们这一次要分析的需求点，针对服务对象：小商户，思考其需求是什么？那么，我们只需要对其需求进行分析，就很容易进行这个问题的回答了。如何获取分析信息1）亲力亲为比如日常培养同理心，学习体察他人的感觉，设身处地想。2）用户调研深入访谈：陪聊是产品经理了解用户的最佳途径，体会群体狂欢的快感。焦点小组：由一名主持人和一组用户（通常不超过八人）在一个主题下进行的访谈，通常会持续两三个小时。让每个成员都能真实地发表自己的意见，避免出现少数用户频繁地阐述自己的观点，而其他用户只是简单地附和——这是焦点小组经常遇到的不利局面。问卷调查：制作问卷发放给目标用户填写。可用性测试：在现场时间段内进行，请用户实际使用产品或demo。留置研究：用户在实际场景里长时间使用得出，用户在这过程记录自己感受并回答调研问题。做用户调研要注意的点：用户是否典型的目标用户、信息是否真实。3）已有数据整理比如产品以往的数据、竞品的数据等。4）各渠道收集贴吧、微博、知乎等各个渠道收集你需要相关的一些用户数据。信息的欺诈性在产品经理圈里有一个非常经典的案例：产品经理-福特：你还想要什么？用户：我想要一匹更快的马产品经理-福特：为什么你要一匹更快的马？用户：因为我想速度更快一些，好节省时间产品经理-福特：我造了个东西，叫汽车，比马快多了这个案例告诉我们，用户说的需求，具有欺诈性。一个很经典的面试题：小明要喝果汁，妈妈没空，怎么解决？这里就主要考察大家对信息欺诈性的分析能力。想喝果汁？为什么想喝果汁？是因为渴了，所以用户的核心需求是渴，而不是喝果汁。作为一名合格的产品，对信息内在含义的判断是非常重要的一个能力。如何提升自己对信息真正含义把握的能力我的秘诀就是，多问为什么，找到用户提出这个信息背后的动机。举个例子，刚刚提到的问题“作为微信方，怎么帮助微信生态中的小商户去运营顾客？”中，我们收集了一些小商户的的反馈：现在来店的人越来越少了，很多人都去网上买了。我搞的几个粉丝群，都没啥人活跃现在利润越来越低了，小店铺不好做啊那么请问，根据上面信息，你认为小商户的核心需求是啥？这时很多小白同学可能会说：付费人数、商品利润……此时你可以利用我刚刚说的方法，来做一个自检：为什么解决付费人数可以解决商户的问题？为什么解决商品利润可以解决商户苦恼的问题？当你提出这个为什么的时候，你会发现这些问题都指向一个答案，因为这样商户可以赚更多钱啊！所以商户的核心需求就是“赚钱！”如何推断结论？得出解决方案？接下来就是最难的一个部分了，如何根据上述信息，得出具体推断，去达成一开始提出的目标。这一板块涉及到两个部分：第一部分目标拆解，第二部分评估判断。在其他人的需求分析里，喜欢先进行评估，按照重要性、紧急性等画四象限坐标，然后再慢慢进行优先级筛选，判断是否贴合目标的方式。而我个人认为，先做目标拆解，再对其进行评估，可以更加快速有效的精准推断。第一部分 目标拆解套路一：公式拆解常见的一个问题：我要怎么提升产品的日活？乍一看这个问题这么大，太难了，其实你只需要分析“日活”的公式即可。日活=当日新增+之前产品的留存用户所以，产品日活只需要优化新增用户量+用户留存量即可。套路二：流程拆解流程拆解的意思，就是根据用户使用流程，按照步骤一步步进行拆解分析。用刚刚的问题举例吧，在“作为微信方，怎么帮助微信生态中的小商户去运营顾客？”这个问题中，我们知道商户的目标是赚钱，那商户一般是通过什么流程来赚钱的呢？以下是根据流程拆解，根据每一个步骤分析出的应该优化的推论方向：在这一阶段，如果你没有很好的分析评估能力，我建议你，能想到的都堆上去，越多越多，剩下的评估放在第二部分进行选择。第二部分 评估分析评估分析，顾名思义就是根据上面我们推导出的解决方案，进行优先级筛选和评估，找到最终的落地方向和落地优先级。比如我要做一个活动拉新，我根据用户信息调研和目标拆分，得出的结论是撒红包和提升产品内容质量都可以解决拉新问题，那我们应该做哪个呢？还是都做？如果都做的话排期优先级如何？在这里我给出一个评估分析的标准思考套路，根据产品核心价值的贴合程度+目标达成效率对解决方案进行综合评估。产品核心价值的贴合程度：即每一个产品都有一个核心功能，即满足用户的核心价值。如果你的解决方案可以更好的满足用户核心价值，那么它的贴合程度就是高的。目标达成效率：即采取这个解决方案，需要多久可以达成目标？达成的效果会好吗？接下来用实际案例给大家分析？如果要给一款社区产品拉新，有以下拉新策略，你作为产品应该怎么评估？推出一些红包增长拉新活动，利用现金吸引用户下载APP。推出内容创作奖励政策&内容创作大赛，一方面通过比赛拉新，一方面拓展产品内容。与知名IP联动，吸引ip粉丝加入当我们把产品目标定义成：产品的用户量，产品核心价值为：满足用户内容消费的需求。我们可以很明确绘制出4象限图：其中内容创作因为达成效率低，比较适合作为产品的长期目标。红包拉新效率高，如果产品下达了紧急KPI，则可以考虑采纳（注意红包拉新这里有一个小陷阱，如果你把产品目标定义成产品长期的用户量时，红包拉新并不是一个很好的策略了，所以第一部分我们讲的目标定义也是非常重要的）。所以4象限的方法能够更好地帮助大家进行决策，大家可以根据产品实际所处阶段、项目整体的KPI紧急性等安排，做出合理的规划安排。（因为每个产品目标、KPI不同，所以这里没有固定答案，以大家实际情况进行分析，在此仅表达我的一些分析思路。）作者：小默爱运营；WeChat：haojicom本文由 @小默爱运营 原创发布于人人都是产品经理，未经许可，禁止转载题图来自 Unsplash，基于 CC0 协议

不管是公司安排的软件项目，还是合同项目。我们拿到一个新的软件项目，首先要做的事情就是根据现有的人力资源、技术能力、项目工期合理地制定项目管理计划。如果现有的人力资源或技术能力不能满足项目工期要求，则需要增加人员或提高人员的技术能力。项目管理计划内容可多可少，主要以自己能够管控项目开发为原则。一般说来，项目管理计划包括项目组织架构、工作分解结构、进度管理计划、需求调研计划、配置管理计划、质量管理计划。小规模的软件项目可以只有进度管理计划，进度管理计划将整个软件项目工作分解为不同的阶段，每个阶段的工作又分解为多个子工作，分解的子工作以1周以内完成为宜。进度管理计划的第一个工作任务一般是需求调研工作，需求调研工作的主要任务是调查系统需求、绘制需求模型、编写需求规格说明书。下面这张图给出了需求调研的基本过程和步骤。图 1需求调研的基本步骤需求调研的基本步骤是调查系统需求、编制事件列表、发现系统角色、编制用例模型、编制类图模型、编制界面模型、编制部署模型、最后形成需求规格说明书。需求调研的第一步是调查系统需求，调查系统需求的方法，在前面的课程我们已经讨论过了。在这里主要采用与用户的面谈方式，通过与用户的面谈，找出系统的相关事件，并写出事件列表。需求调研的第二步是依据前面给出的事件列表，归纳和抽象出系统相关角色，建立角色列表。归纳和抽象系统相关角色，要注意角色不是指具体的人和事务，而是表示人或事物在系统中所扮演的角色。需求调研的第三步是建立角色用例图，角色用例图是系统需求的功能模型，描述了角色的行为及角色间的关系。每个用例需要给出用例规约，用例规约描述了用例的用例名称、参与角色、与其它用例间的关系、前置条件、后置条件、操作流程、输入与输出数据项等内容。需求调研的第四步是根据角色和用例模型建立类图模型。一般说来，前面分析的系统角色就是系统中的对象，也称为类。类图模型描述了类的名称、属性及行为，以及类与类之间的关系。需求调研的第五步是依据角色用例和用例规约建立界面模型，需求阶段的界面模型只要给出原型就可以了，不需要考虑界面的美观性。需求界面模型可以使用PowerPoint、Axure RP等工具进行绘制。需求调研的第六步是确定系统的部署需求。部署需求主要由网络环境、硬件环境、软件环境组成的需求。网络一般采用网络拓扑图等模型，给出部署系统所需的网络环境需求；硬件环境给出部署系统所需的硬件环境需求；软件环境给出系统所需的软件支撑环境需求。最后形成完整的需求规格说明书，将前面的文字表格资料、绘制的模型、图片等内容放置到需求规格说明书中。需求调研的成果物除了需求规格说明书外，还有需求跟踪矩阵，编写需求跟踪矩阵主要目的是可以有效跟踪项目需求变更和需求实现，做到在需求和项目之间维护双向可跟踪性。跟踪需求是因为在系统研发期间，需求会由于各种各样的原因而发生变更，因此有效的管理这些需求和需求变更是很重要的，我们有必要去了解每个需求的来源以及对系统的影响。

本文将需求分为两类——工具类需求、用户端需求；并进一步给出了两个案例方便理解。前言关于需求分析无疑是产品经理的一项必备基础功，也是每个产品经理可能工作大部分时间都在做的事情，但是绝大部分产品经理可能不会刻意的去总结一套方法论。总的来说不总结方法论也不会有多少问题，因为毕竟基本工作很熟手，但是总结了方法论并写出来有以下几个好处：指导自己工作，在自己不知该如何着手做一个需求的时候，可以为自己提供一个框架锻炼自己的结构化思维及总结能力写出来与自己对话能提高自己的认知，会获得意想不到的收获个人平时也比较懒，偶尔会写些东西，但是通常不能长久的坚持，也希望自己能慢慢坚持下去。什么是需求分析个人对需求分析就是：确认终点寻找路径的过程.从这一定义来说需求分为2类：第一类是终点比较明确，无太多争议性，此时的需求分析主要集中在寻找路径。第二类是终点不是非常明确、甚至是极为不明确，此时需要先确认终点再去寻找路径。第一类需求主要包括一些公司职能部门管理后台一些效率性工具、营销工具等如：财务管理、订单管理、路由配置等，这类需求考验的是产品经理的基本功，包括业务流程梳理、功能逻辑梳理、功能列表及细节，提供最终解决方案、优先级协调、方案拆解及迭代计划等。需要注意的是，这里所说的终点比较明确是相对的，有些新人产品经理比较容易犯的错误是，业务部门提啥后台需求我就接啥。这样很容易导致后续改改改，因为业务人员提的往往不是一个需求，而是一个解决了他们所认为的需求点的一个方案，产品经理一定要能识别需求和方案之间的差别，透过方案看到需求本身是什么。举个简单例子：运营人员提了个需求说，我想在推送配置界面里加一个EXCEL导入推送人员名单功能。这个需求看上去很合理，这样运营就可以快速的导入推送人员名单了，但是仔细想想这是一个需求吗？或者说这个需求本质是加一个EXCEL导入功能是产品的最终形态吗？这个问题在这里不做回答，后面会举一个相类似的我在工作中遇到的实例。第二类需求主要是一些用户端需求比如推出一个新的功能、一个新的玩法、对以前功能做优化。但是对于这个玩法究竟效果如何，大家都不能很确定。此类需求相对于第一类需求除了考验产品的基本功以外还需要产品经理有规划MVP（最小可行化产品）能力、数据分析能力等。可能会有人提出还有第三类需求，就是现在啥都没有从0~1打造产品。在这篇文章的场景限定下，此类不属于一个需求，这是要做一整条产品线，这即需要产品经理对宏观了解把握、对业务熟悉、对微观的有掌控等能力，个人暂时没有实力写这样文章，如果有同学想学习此类能力，推荐学习梁宁的《产品思维30讲》、《增长思维30讲》，后续个人也会尝试着从自己的工作理解中来简单谈谈需求分析框架需求分析框架用比较直白的话来说就是：值不值得做？做成啥样子？怎么来做？值不值得做需要去分析目标和价值，做成啥样子需要去梳理业务流程、分析使用场景、设计功能细节，而怎么来做主要就是确认优先级、调整配置资源、完成迭代计划，以下是个人总结的需求分析的框架图：严格来说，怎么来做已经不属于需求分析范畴，但是当面临的需求比较大但是研发资源不足时候就需要考虑怎么来做了，比如说优惠券系统，涉及到模板创建、运营发券、用户领券、用券、核销、数据统计等，在研发资源不足业务有比较急需情况下，就需要将一整个大需求进行拆解，分多期来做。从这个角度来说也够得着需求分析的边2个案例以下是自己工作中碰到的2个真实的需求分析案例：案例1：财务结算报表需求业务背景：公司甲为某小贷公司一级代理中介，其职能是为小额贷款公司寻找二级渠道客户，用户经二级渠道办理业务，钱款直接打到小贷公司（由于业务法规限制，系统无法直接在用户付款时候进行分账），每月月末，小贷公司分账给甲公司，甲再分账给二级代理公司。如下图所示：当时财务是这么跟我提需求的大概是这么说的——“我需要一个2个结算报表页面，两个报表都有balabala字段，都要有个EXCEL导出功能。”下面我们套用需求框架对此需求进行分析：1. 目标分析：此需求受众是谁？——财务（废话……）是否影响其他人？——否此需求目标是什么？——是要一个列表吗和EXCEL导出吗？显然不是，因为前期分账也有EXCEL，只不过是研发从数据库拉取的，她要的是能够更效率的分账与核账，最终目标是“更效率分账和核账”。此处必须要废话一下，因为有的新人产品经理会真的直接按照需求方提的要求做出这么两个表格出来。2. 价值分析：此需求有无价值，价值几何？很显然有，只不过是一个优先级问题，只要没有更高优先级需求这个需求肯定要做的，因为可以节约开发和财务双方的时间。3. 业务流程梳理：可参见上图，财务核心点就在于向上游和下游的结算、核账。4. 场景分析：在这里，因为这个是一个新项目，我不是太了解此条业务线结算场景，所以需要和财务进行了大概如下对话（这一步非常关键，知道怎么用，才能设计好对应功能）：我：你能简单说一下你以后要怎么用着两张报表吗？财务：每个月月底小贷公司打款过来，然后我用“报表1”进行核对打款是否正确。每个月我根据“报表2”计算应付渠道多少款我：那为什么要拆成两个报表？之前研发不是拉一张报表给你就OK了吗？财务：因为结算给渠道不能让他们看到成本，结算给小贷公司，也不会给他看渠道成本，他们也不关心（已经获得第1个结算场景全貌）我：那我做一个报表给你，你再拆不一样吗？（这么问不是为了偷懒，因为工作量差不了多少，主要目的还是旁敲侧击挖掘其使用场景）财务：这样也可以，但是有些麻烦，而且有的时候渠道方中途想核对一下月中数据是否一致，此时不用导出EXCEL报表发过去，比较麻烦，直接截个图对下数据就可以了（获得了第2个使用场景）我：除了对账，表格对你还有其他帮助吗？财务：还会去统计每个渠道带来利润，看看渠道大体情况我：那分成两个表格你怎么统计利润？财务：（财务有点支吾，估计之前没考虑到）我可以自己再把表格合起来然后对账（获取了第3个场景全貌）从以上的对话可以看出财务所提的方案，满足不了她自己所有的使用场景需求，当然后续对话还有一部分是关于功能细节的，这里不赘述了。有的人可能会问，财务说的也对，两个表格到时候她自己合起来对账就OK了？那么首先这样麻烦，容易造成错误不说，最关键的一个问题是，她如果要去做合表，必须保证后台所查出来的两个表格数据排序是一样的，否则就会造成数据对不齐！如果直接开发上线，后续就不得不面临着一个问题——需求变更#@￥！￥%@%￥！%￥5. 功能设计：有了具体的使用场景，对业务了解，基本功能设计就不太会出多少问题了，这个产品形态很简单。下面直接附上最终的交互稿：至于后续的几个步骤，在这个例子中不需要做，因为功能很简单工作量小案例二：优化认证转化率某小额贷款公司，整体业务流程为：用户登录注册→认证获取额度→申请→审批→打款需求背景：在该项目上线半年左右，业务已经逐步趋于稳定了。于是就琢磨着看能不能提高业务效率，在当时整体的认证转化率在35%左右，凭直觉有很大的优化空间，于是就自己倒腾备库，拉了一周的和认证相关的业务数与埋点数据，做出了下图：在这张图上很容易看出进入页面=》提交身份认证，联系人1点击=》联系人2点击，这2步跳变流失比明显比较大，于是就有了“优化认证转化率”的需求，套用需求分析框架。1. 目标分析：此需求受众是谁？所有进入我们APP无特定属性用户。是否影响其他部门/人？应该不影响。此需求的目标是什么？提高用户进入认证页到获得额度的总体转化率。2. 价值分析：此需求价值几何？简单来算一笔账，市场运营推广费，平均一个注册用户在4~10多块，我们就按照6块来算，我们每天新注册然后到认证页面用户在1W2左右，如果能将认证转化率提高X%，那么每天可以等价为公司节省下：12000*[1-35/(35+X)]*6=72000*X/(35+X)元（公式得来是因为我们要维持放款量是一定的，转化率高了对应的拉的用户量就可以减少，大家可以自己推算）简单代入，如果提高了1%，那么每天可以为公司节省2000元左右推广费，如果提高了5%呢？那么每天就可以节省9000元，一个月就可以省下27W！！！的推广费用。3. 业务流程梳理：此处应该说是问题分析了。第一步到第二步之所以跳失这么高，大胆猜测原因：1）骗贷用户，身份证提交不了（因为身份证需要拍照，我们接了三方防伪，假冒身份证提交不上来）2）未成年用户（身份证年龄前端计算低于18岁就不给提交）3）页面采集用全部展开方式，信息太多，对用户不太友好紧急联系人1→紧急联系人2 仔细去用了，分析一下大胆猜测跳失率如此高的原因：填写联系人系统需要读取用户通讯从通讯录中选取，当初在设计时候为了提高用户体验就将授权分散在各个步骤，需要用到时候才授权。此处猜测之所以联系人2比联系人1点击跳变这么大，可能是在联系人1点击时候，获取用户通讯录授权让用户产生担忧而造成大量流失。参考了其他竞品和世面上软件，所有授权在用户第一次进入APP之后就全部一起弹出。4. 场景分析：此处无5. 功能设计：针对以上的猜测，做以下优化：1）增加身份证照片上传报错上报埋点，将报错原因上传至后台2）将提交身份证按钮报错也上传（以前前端拦截不上传），并上传报错信息3）在用户打开APP即获取所有授权，减少用户获取联系人时候6. 优先级协调：系统和业务已比较稳定，精细化运营优先级可以提高。7. 资源协调：依照6，只要价值阐述得当，团队认可，资源肯定到位，而且工作量很小……8. 迭代计划（重点阐述一下）：1）因为这个需求效果不能确定，不能做全量更新，但是我们当时没有ABtest支持。所以就想了一个折中办法，就是挑选一个量相对来说还可以，认证页面漏斗和整体没有太大差异，（记得选的是华为渠道吧，每天注册量1000多）2）进行内部非强制升级提醒，此处提醒一下，一定不要在某一个渠道发包，因为渠道会有抓包机制，因为你在A渠道新版本的包，其他渠道如果版本低的话会将A渠道的包抓去更新，这样不仅会导致包的渠道号错乱，而且万一所做的改动起到的是负效果，损失将会很大。3）观察数据，如果有效果则全渠道更新，如果没效果，则将定向渠道代码回滚，再次更新，等待后续新版本将所有渠道全量升级统一版本后续又根据数据进行了多次优化验证，这里就不说了，直接说结果吧，优化的确有效果，联系人1点击→联系人2点击跳失率从原来的25%左右下降到16%左右，整体转化率提高了3个百分点样子。每个月可为公司节省17W左右推广成本（实际推广成本节省随着每个月目标不同而不同）。第一步到第二步的跳失根据上报数据和猜想大体一致，但是后续还做了交互上优化，也提高了一点，这里就不再阐述了。最后的话最好我想说，方法论与框架是用来帮助我们的，不是用来限制我们的。在自己对于需求分析不熟悉的时候或者需求比较复杂的时候可以套用框架来帮助我们找到解题思路，当我们对需求分析已经成为本能的时候应该学会放下框架和方法论，在实际工作中会遇到千种千样的需求，需求分析也要灵活多变，甚至有的需求就是改个文案，此时还陷入在框架或者方法论就无疑有点照猫画虎了。以上是个人对需求分析的理解与总结，说的不到位地方请大神指点，也欢迎大家一起交流。本文由 @wens 原创发布于人人都是产品经理。未经许可，禁止转载。题图来自Unsplash，基于CC0协议