标签 - 人人都是产品经理
这是一篇关于设计反馈和团队管理的文章，更多的聚焦在如何更好的在工作中沟通协作，以及如何激发团队的潜力，希望会对大家的工作有所帮助。
最近思考最多的一个主题是设计反馈。在我的工作环境中，我们的核心流程是每天早上都会召开内部会议。我们会回顾前一天的工作进度，并对哪些方法是有效的以及哪些方法可以改进，相互提供反馈意见。
了解如何给出反馈和懂得给出什么反馈同样重要。
最近我写了一篇关于反馈的文章，文章大致表达了如下观点：
在设计工作中，你选择不给出反馈与给出反馈同样重要，并列出了做反馈时的七条基本原则：
你不需要证明别人错了，就可以证明自己的观点你不需要用你的反馈向别人证明你知道多少你需要能够将概念反馈与详细设计反馈区分开你可以通过专注于哪些有效而不是哪些无效，来达到同样的效果负面反馈具有传染性，且会影响团队士气某些评论在私下比在公开场合更有效归根结底，这一切都是为了激发他人最好的一面在每一次回顾会议上，我脑海中不断浮现的另一个方面是反馈的标准，这对团队是最有帮助的：是更具规范性的反馈还是更具战略性的反馈，这是一个很好的平衡。
一方面，作为一个经验丰富的设计师，更容易想象出一些解决设计难题的潜在方法；另一方面，你要确保每天都在工作中面对挑战的设计师们感觉自己拥有最终的解决方案。
曾经有很多次，出于本能，我没有考虑给出战术反馈的结果，便告诉其他设计师某些屏幕的外观和表现应该是怎样的。
“当用户点击时，您应该使用下拉列表，而不是 UI 展开以显示其他位置的列表。当再次点击时，将刷新页面来展示他们选择的位置。”
我并不对此而感到自豪。战术反馈不仅限制了某些解决方案带来的创新性和惊喜感，同时削弱了团队自己提出解决方案的信心。
资深设计师自然会懂得，提出的解决方案只是众多解决方案之一。并且懂得如何用这个建议作为出发点，去集中的思考一个比原来的方案更有力、更有趣的新方案。
但是年轻的设计师可能会冒着风险，直接采用建议：他们这么做要么是因为无法立刻想出另外的解决方案，要么是他们太看重职级。（“好吧，要是我的上级告诉我应该用这个方案，我最好就用这个。”）
这些年来，我开发了这个快速的思维框架，试图迫使自己远离那些过于战术化和规范化的反馈:
01 提醒团队该页面要实现的目标（用户目标）
一开始沟通的时候就提醒其他设计师，这个页面、屏幕、功能的目标是什么——要从用户的角度来表达。这是一个很好地提醒，你和你的团队应该始终把
本文主要从审核机制、排序算法、评论运营、个性化推荐切入，思考如何让评论区更有趣。
对一个互联网产品来说，好的评论运营逻辑可以营造强大的社区氛围，助力增长，如网易云音乐、抖音。
目前市面上流行的评论样式有：平铺式、主题式、盖楼式、对话式、混合式，大家都很熟悉。
（资讯APP评论区截图）
先回忆下我们在评论区活跃的动机有哪些？
逛淘宝购物时翻阅评论，主要是想依靠评论消除疑问或做出决策；
听歌或阅读资讯APP时查看评论，主要是寻找共鸣或了解舆论风向（延伸阅读）；
当被提醒评论被回复/点赞（与己相关），情不自禁点击进入评论区。
基于上述用户在评论区的活跃动机，可将用户需求理解为：时效性（我要看最新的评论）、逻辑性（我要看懂评论）、趣味性（我要看最好玩或有用的评论）。
需求拆解完，我们来看看“让评论区FUN起来”的方案，下文主要从审核机制、排序算法、评论运营、个性化推荐切入，启发思路。
01 评论安全审核机制
同文章分发，评论的分发也需要安全审核机制，方式有：
先发后审先审后发处理优先级可遵循：流量热门的内容优先处理；重要账号的内容优先处理；高信用用户的内容优先处理。
安全审核机制和举报惩罚机制、用户头衔评级系统，共同构成评论土壤的守卫墙。除了以上官方的处理机制，还可以发挥用户“众志成城”的力量，共同维护评论或社区的内容生态，如下图：
（左：最右app，右：网易新闻）
评论清理的过程中，留意一些避免伤害用户参与积极性的小技巧。如先审后发的评论，仅用户自身可见、仅粉丝可见，待通过审核再取消曝光限制；评论删除同理，用户自身对评论仍可见，但该评论已从大众的曝光list中剔除。对一些“满怀恶意”且“屡教不改”的用户可进行禁言加黑名单的惩罚。
02 寻找优/劣质评论
以资讯APP为例，评论区展示逻辑一般有两种：热门评论（精彩评论）和最新评论，后者是以时间倒序排列，前者可以简单按点赞或回复数倒序排列，精细化运营可以有更多提升空间，整体思路是：找到优质/有趣的评论，制定合理健康的排序规则。
怎样从海量的评论中找到优质、有趣的评论，四字方针：除劣拔优。
先从文本入手，可以通过敏感词滤网和特征识别，将低质评论过滤掉，如：
有过多重复词违禁词错别字字数少、纯表情、乱码广告也是通过文本特征，可以识别出对联、打油诗、押韵、角色扮演、深度答疑、讲故事这类具有特殊的文本结构的特色评论（前期需要做浓度摸底），可在排序环节加权或强插。
另一方面，从
文章将讲解通用的启发式评估十项原则，以及由其延伸出来的移动端启发式评估原则。
用户体验直接关乎产品的成败，影响到业务能否正常开展并为公司赚取利润。而可用性作为用户体验的核心，是设计师投入最多精力去探究和实践的关键点。在产品上线之前，企业往往邀请可用性专家来评估产品的体验、可用性问题，希望通过专业人员的介入，发现产品存在的体验问题并及时纠正，以避免上线后的不良后果。
本文的主题就是关于可用性专家评估产品的用户体验的常用方法——启发式评估。
文章将讲解通用的启发式评估十项原则，以及由其延伸出来的移动端启发式评估原则。文章最后会附上启发式评估表格的 sketch 文件，大家可以在文末的链接点击下载。
启发式评估是什么？
「启发式评估允许一部分评估者检查界面，从而判断其是否符合公认的可用性原则」——Jaokb Nielsen
简单来说，启发式评估是 UX 领域的一种评估产品可用性的方法或者说一组原则、标准。在设计思维及产品设计的流程中，原型和测试是其中的关键步骤，通过将想法和策略原型化并进行测试，设计师可以避免不必要的成本投入，规避掉产品中的异常问题，帮助团队找寻到正确的设计方向，以及选择最佳的设计方案。
虽然在国内，原型工具主要用来进行视觉和交互的上下游对接，但不得不承认，原型的核心作用是用于测试、验证乃至规避风险，节省投入。
不考虑商业策略和业务方向的前提下，我们一般通过创建原型以及测试原型来排查可用性问题，即产品原型是否有较严重的可用性障碍，用户能否正常完成操作实现目标。
一方面，我们通常会将原型直接投入到真实场景中，并通过真实用户的实际体验来进行测试，获取用户的反馈从而进一步优化产品的可用性。
但另一方面，限于隐私、经验等问题，用户的真实想法并不一定能够完整的传达出来。产品的可用性不能够完全依赖于没有设计知识和经验的用户来实现。因此我们通常会邀请可用性专家对产品原型进行评估，通过其丰富的设计经验来发掘问题并进行规避。
启发式评估就是可用性专家常用的一组测试标准，由尼尔森发明，共包括十条原则。尼尔森最早发明它们用于网页设计的可用性评估，后来该十条可用性原则成为了通用设计原则，即适合包括移动端和 PC 端产品，也包括应用程序到工业设计产品，而不限于某个领域。
启发式评估适合在什么阶段和情况下使用？
启发式评估并不限于某个特定的时间段，或者产品阶段，在任何需要专家来评估和验证方案的地方，都可以使用
平台产品有自己的生态闭环：供给充足，能够适配多方的需求。连接用户和产品，是平台产品的运营重点。
快手本质是什么类型的产品，想清楚这个问题，再确定运营咋搞。首先快手毫无疑问是内容型产品，其次也是社区产品。
但一个2亿+DAU的产品，肯定可以从多个角度去解读，有多重属性。这次的视角是：快手还有平台属性。
啥是平台型产品，至少是海量数据的吧，不管是DAU还是GMV，量级小的产品也没脸说自己是平台。
称得上是平台的产品，是要解决一个生态的闭环，比如上下游、B端C端或生产消费。所以，数量级肯定是很大的，产品承载的用户类型也是多样的。
一、平台型产品有以下几个特征
1. 平台是双边或多边的，供求是动态不平衡的
其实这个观点来自美团高级副总裁张川的文章，我是跟着学习的，掺杂着自己的思考。
有生态闭环才叫平台，所以肯定就是有多样的角色，比如上文提到的B端C端、生产消费什么的。
比如淘宝就是一个巨大无比的生态，不仅有买家卖家，还有代运营服务商、广告代理商、物流公司等等，这就是平台的多边角色。以此逻辑去分析，也能得出像快手这样的产品，有平台属性。
供求是动态不平衡的，平台才有价值。针对这点，川哥举例是：用户交易的时候很少在固定的时候固定的买一家店固定的商品，用户也很少同时同刻在同一地点打上同一个司机的同一辆车。
也就是说，如果双边或多边能甩掉平台自己玩，那这个平台就没价值了。平台的动态不平衡，不是追求的目标，而是特点，是呈现结果。
对于快手的「动态不平衡」，体现在供求双方在内容品类上的匹配程度。比如在高速增长中，总有多个细分品类的内容供给，小于内容消费；反之也是一样的。
这是常态，也是正常现象，运营要做的就是不断优化内容品类，不断补缺。
2. 供给是核心，且供大于求才成立
我经常举这么一个例子，如果要从零做一个招聘网站，先搞B端还是C端，也就是先搞招聘方，还是求职方。只能二选一，理论上不存在同时搞。
看似是一个鸡生蛋和蛋生鸡的问题，但其实不是。答案肯定是先搞B端招聘方，先搞供给端。
从规律上来看，面对这样供求的选择时，就先搞供给。从具体情况来看，B端招聘方更好搞，因为他们就摆在那里，可以一个个去磕。而求职者的身份是隐性的，不会写在脸上。
同理快手的运营也应该先搞供给，原因也类似于上面提到的招聘网站。
供给搞到什么程度呢，从定性非定量角度说，供给要远大于需求的。因为需要提供给用户选择的空间，这样的平台才能成立，反之平台会死掉
评审会是产品开发的重要环节，产品参与人需要在这个会上对关键要素达成一致，从而才能保证产品的顺利上线。那么，评审会该如何开呢？
被怼，只能减少不能消除，减少是可以有方法，本文就讲述了一个方法，人人可做到。
PRD的评审会，是一个方案的确认会，主要讲产品“是什么”，为后续环节“怎么做”提供依据。
本文通过将PRD评审会议过程进行结构化拆解，然后将执行过程标准化，以解决PRD评审会常见问题，提高评审效率和质量。
本文主要对如下几个环节的操作进行了说明：
- PRD评审会目的；
- 会议的两大原则；
- 会前准备；
- 会议议程；
- 会后收尾。
一、会议目的
搞清楚目的是做事情的第一个步骤，因为有了目的才能有的放矢，确定原则，对方案进行取舍优化，对PRD的评审会议也是如此。
PRD评审会的会议目的有两个，一主一次：
- 最主要的是统一各方对产品方案的认知，以便项目组协同作战；
- 次要的方面是通过会议群策群力，查漏补缺。
如果主次弄混了，就会评审会变讨论会，讨论会是应该在方案确定之前进行的。
如果有大幅修改，不二审会有很大的认知不一致风险，进而给项目带来额外的成本和风险；进行二审不仅延误时间，同时还会让合作方对你能力产生怀疑。
如何评估PRD的评审会是开好了呢？
理想情况下，所有参会人员在三个方面都理解一致且认同了：方案的整体思路、关键点风险点、细节设计。
然而现实中大部分项目是不可能做到的，所以可行的标准是对产品方案：
- 整体思路理解一致且认同；
- 关键点风险点理解一致且认同；
- 对需要注意的详细设计点理解一致且认同，大部分的设计可以不记得，回头看PRD。
主要是需求目的，方案的实现思路、实现方式、实现程度、实现范围、时间计划、已知风险的理解达成一致。所谓认同，就是在对疑问进行质询后，认为方案可行。
二、会议两大原则
- 问题解决在会前；可能的问题，有预案；
- 就事论事，好的建议要吸收。
我们可以借助一个场景来理解：
有个大集团M，对某个功能的设计方案进行招标，产品方案就是针对这个招标进行的方案。
PRD评审会就是这个招标评审会，会议直接决定了你能不能拿到这个大集团合同，赚到钱。对方参与招标评审的是除产品经理外的相关方。
这时应该如何去做，才能最大可能的通过招标评审，拿下合同，限制条件是没有灰色行为。
总结起来，其实就是上面的两条。
三、会前准备
要将问题解决在会前，就需要充足的准备，一个会开的顺利不顺利，会前准备的工作可以占到80%，另外20%才是在会上取得的。
这个会前准
本篇文章通过使用、体验、研究等方式倒推「易捷加油APP」，借助 Axure 撰写 PRD 文档。与大家分享。
作为产品小白，希望通过倒推的方式，来锻炼产品思维、提升画原型的能力。同时分享在使用中获得的心得体会，欢迎提出宝贵建议。
目录：
一、文档综述
- 文档属性
- 产品综述
二、产品说明
- 产品功能结构图
- 产品信息结构图
- 产品结构图
三、全局说明
- 功能权限
- 键盘交互说明
- 异常情况说明
- 交互规则
- 数据说明
四、部分任务流程
- 购物流程
- 加油流程
五、部分功能详细说明
- 登录页/注册页
- 首页
- 商品详情
- 一键加油
- 我的
六、非功能性需求
- 性能需求
- 可用性需求
- 运营需求
七、优化建议
优化商品详情页
01 文档综述
1. 文档属性
2. 产品综述
二、产品说明
1. 产品功能结构图
2. 产品信息结构图
3. 产品结构图
三、全局说明
1. 功能权限
登录/未登录：
- 登录用户可以浏览所有页面、执行所有操作。
- 未登录用户可以以游客身份进行内容游览，可以游览商城商品。
2. 键盘交互说明
- 点击APP手机号码输入框，页面底部弹出数字键盘。
- 点击其他输入框时，页面底部弹出字母键盘。
3.异常情况说明
打断后重新打开APP：
点击空白区域或无网络情况：
无网络情况：
4. 交互规则
加载状态：
首页：
商品列表模块：
提示信息：
空状态：
页面在正常情况下，没有数据显示时，表现形式为插图配提示性文案。如需要，根据特定页面场景，增加引导用户操作的Button或链接等；
操作状态：
所有的按钮或者可点击的icon、文字均分为：可操作状态，不可操作状态两种。
其中可操作状态对应可操作颜色，不可操作状态一般可见，但为灰色，易捷加油APP没有做操作后的按钮状态变化。
5. 数据说明
四、部分任务流程
1. 购物流程
2. 加油流程
五、部分功能详细说明
1. 登录页/注册页
页面名称：登录
入口：初始登录APP
基本事件流程：
- app显示登录表单页面，表单中包含文本：①输入手机号码②输入验证码
- 用户输入11位手机号码，获取验证码并输入
- 点击登录按钮，进行登录
- 登录成功进入首页
页面逻辑：
- 登录方式：①手机号码登录②提供第三方登录
- 点击手机号/验证码登录，输入手机号和验证码进行登录
- 用户可点击注册，输入手机号码，填写验证码，设置密码进行登录，并默认“注册代表同意用户使用协议”
后置条件：登录成功/登录失败重新登录
异常流程：用户输入短信验证码错误，弹出“短信验证码错误”提示文本，2秒后消失，用户重新操作
页面内交互：
- 点击手机号、验证码输入框时，数字键盘从底部向
欢迎来到大型情感类专题：如何进行有效需求分析——业务场景篇！场景二字，或许我们再熟悉不过了，在整个产品的实现过程中，它都是这么的如影随形。场景是很具体的，因为它是客观存在的，我们凭借肉眼，就能够捕捉到它；但场景又似乎很抽象，我们每天都要纠结场景到底是什么，场景与功能之间到底有什么联系。今天，就让我们一起来探究一下场景的奥秘吧！
内容回顾
上一期我们讲述了业务流程的相关知识，按照惯例，我们先来一起回顾一下：
- 分工产生的原因：规模、风险、专业；
- 业务流程三个管理要素：审核、规则、异常；
- 业务流程五个基本要素：分工、活动、协作、产物关系、分支；
- 业务流程的起点即外部服务请求；业务流程的终点即满足服务请求；
- 业务流程的优化策略：“ESIA分析法”。
业务流程与业务场景是环环相扣、层层递进的关系，在开始本文的正题之前，先把这样两句话送给大家：
- 业务流程是指不同岗位之间通过协作满足外部服务请求的过程；而业务场景则是以某岗位为主完成的、相对独立的、可以汇报的业务活动；
- 管理层用户关注事到事的逻辑，他们关注的核心是业务流程；而操作层用户则更关注人到事的逻辑，他们关注的核心是业务场景。
思维方式
一切行为的改变，都源自于思维方式的转变。我单独将这两句话做成一张图片，也是为了能够引起大家的重视。
在我们需求分析系列的第一篇文章中，我们就探讨了“产品思维”与“技术思维”的两种不同思维方式，而以上图中的两句话，则是两种思维方式在用户场景这个阶段的进一步体现。
图中的红色箭头，不知是多少人难以逾越的鸿沟。大多数情况下，我们都在“以需求分析之名，行功能分解之实！”（对号入座的同学请举手~）
思维方式的转变，真的很难，这不仅需要我们坚定不移的信念，更需要我们千锤百炼的实践。
目的意义
先来说一下，我们研究业务场景的目的意义是什么呢？你也许会说，研究业务场景肯定是为了进一步的需求分析呀。没错，这的确是目的意义之所在，但这个描述太过笼统，而且业务场景所能带来的，也绝不止这些。
价值传递的介质
我曾经在自己的转正述职报告中，提到过价值驱动与任务驱动的相关内容。我觉得我们做任何一件事情，都应该明确其目的和意义，而不是单纯地去为了完成上级交代的任务而去开展工作。
而需求这种东西，经过层层传递，最终开发接收到的，可能就只剩功能了。于是，我们或许经常会听到这种声音：“这个需求当初为什么这么定呢？”“我也不知道，产品经理就是这么定的。”并且随着时间的
欢迎来到大型情感类专题：如何进行有效需求分析——业务流程篇！
大家可以看到本篇文章的标题，与前两篇内容不太一样了。这是因为，自己也画了几年的流程图了，但时至今日我才发现，自己也仅仅局限于会画流程图，甚至于连怎么画流程图，我都没有一个完整的方法论；但也很庆幸，时至今日我终于发现，关于业务流程的知识竟是这么的别有洞天！
内容回顾
我们近期的文章，是关于需求分析的知识体系，同样，我们还是先来回顾一下上期的关键知识点：
需求的定义：需求=预期-现状。
外因触发需求：
- 参观考察—>应对策略：分享收获；
- 竞争对手动向—>应对策略：竞品分析；
- 热点及新趋势—>应对策略：分享理解；
内因触发需求—>应对策略：还原表象、分享原因、共商决策。
机会场景往往来源于以下三个方面：
- 新业务；
- 新技术；
- 新人群。
stakeholder：项目是一个博弈游戏，重要的是获得足够的筹码，也就是需要找到关键的筹码人，赢得足够的筹码就可以赢得项目，并且你也不可能获得所有的筹码。
上期内容主要是谈论了宏观层面，也就是目标愿景树立的方法。当确定了项目的方向之后，我们就需要逐步深入，从抽象层逐渐将精力转移到具象层。今天就让我们一起解开业务流程的奥秘吧。
身世
我们都知道企业到处存在各种各样的业务流程，但这些流程为何而存在呢？一则小故事，带你探究业务流程的身世之谜！
改革开放伊始，有一个微不足道的小人物，并且他还是个文盲，7岁开始在路边捡烟头挣钱，9岁学徒经商，后来为了维持生计，买了点葵花籽炒了去卖。这个时候，所有的事情都是他一个人负责，自己进货、自己销售、自己发货、自己记账…
他也不知道从哪里偷学了一门手艺，炒出来的瓜子竟然非常好吃，一嗑三瓣，满口清香。就这样，他的生意越来越红火，一天的瓜子可以卖出上千斤，自己一个人显然忙不过来，于是请来了一些人当帮手。
他叫来了张大爷，让他帮忙订货、发货、管理仓库；叫来了大姑，让她帮忙记账、收钱、管钱。然后呢，交代张大爷必须等到大姑收到钱，将收钱证明交给他，并且检查过后才能发货，不然就会出现问题。
然后又过了一段时间，营业额越来越大，这个小人物觉得大姑虽然是亲戚，但他万一眼红，在账上做做手脚拿走一些钱也是麻烦事。因此，他又喊来了大姨，让她们一个人管钱、一个人管账，互相监督。
再后来啊，这个小作坊日益发展，开始要和税务局打交道了。但大姑的水平，能够记账就不错了，根本没法做这种事。怎么办呢，只好再找一个专业的会计来负责这
想要了解并反映真实的互联网用户需求，我们需要从多个方面进行梳理和分析，本文作者对这个问题展开了探究，希望给大家以帮助。
欢迎来到大型情感类专题：如何进行有效需求分析——价值需求篇！
所谓价值需求，从结果来说，是我们在项目方案或者PRD文档中所编写的愿景/目标；从过程来说，是我们与客户达成合作的关键步骤，这些内容可以说是组织应用类软件系统需求的灵魂和方向。
但很多时候对于这些内容的定义往往是空洞无物、混沌不清，抑或是放之四海而皆准的描述。这也正是导致项目范围蔓延，无底线需求变更的罪魁祸首。
今天，就让我们一起来探究一下价值需求背后的秘密吧！
内容回顾
本篇文章的内容，会涉及到前篇文章的部分观点，我们先来回顾一下：
- 客户是问题专家，而非解决方案专家，他提出的方案未必能够完美地解决他遇到的问题；
- 技术思维关注点：实现方式、技术架构、技术价值、开发成本；
- 产品思维关注点：用户价值、使用场景、商业价值、业务闭环；
- 需求打开的正确方式：澄清问题—>了解背景—>建议并确定解决方案。
（如果对这些结论感到陌生的同学，可自行翻阅前一篇文章，我会在文章结尾处加入跳转连接。）
问题场景
既然需求打开的第一步骤是澄清问题，那我们就从问题场景开始谈起吧。
参与过用户调研的同学，对这个环节肯定深有体会，有时候用户口若悬河地说了一大堆内容，然而对我们有价值的信息却寥寥无几。
尤其是跟管理层进行沟通时，有哪位同学获取过类似这样的反馈：“我们要打造一套先进的信息化系统，有效地推进管理的提升！”
面对这样的沟通记录，你有何种感受？反正我是如坐针毡、如芒刺背，再加一个词的话，如鲠在喉…
我们上篇文章表达过，指望用户把需求讲清楚是不现实的。既然如此，那我们就需要一些沟通技巧，来引导用户表达出有价值的信息。正所谓一切知道为什么的人，都自然知道怎么干。想要引导沟通，关键就在于搞清楚用户提出需求的背后原因。
用户主动提出项目需求的原因无在乎两种：一种是外因触发的，通常问题不太清晰；另一种是内部提出的，通常已经有了基本思路。为什么这么说呢，我们接着往下看。
外因触发
我们这里先给出结论，外因触发的常见触因有三种：参观考察、竞争对手动向、热点及新技术趋势。
1. 参观考察
作为企业的领导层，经常会有全国各地到处参观考察的机会，而每次归来之时，往往就会带回一些新的想法和思路。但领导嘛，一般不会跟你说太多“为什么”的内容，结果就会导致我们接收到的需求，很容易被抽
需求分析让人头秃，笔者针对这个问题展开了通俗易懂的阐释，希望给大家以帮助。
你有没有因为需求分析四个字，而感到头发日渐稀少？你有多少个失眠的夜，是在思考领导说的“把系统优化一下”这句简单的话？你又有多少次面对客户无休止的需求变更，而想要拔刀相向的冲动？
这一切的背后，到底是人性的扭曲，还是道德的沦丧？
朋友，你的福音到了，欢迎来到大型情感类专题：如何进行有效需求分析？
左脑喜欢逻辑，右脑喜欢故事；最好的陈述一定是起于故事，终于逻辑。
今天的内容，就让我们从一则生活中的故事开始吧。
生活故事
有一天夜里，资深需求工程师老余刚忙完一个重要的项目，带着放松的心情进入了梦乡。
这时他年仅3岁的小孩夜里醒来，吵着要吃饼干。孩子的妈妈首先被吵醒，带着情绪训斥了小孩：“半夜三更吃什么饼干，好好睡觉！”
没想到小孩不依不饶，继续哭闹着。不久老余被吵醒了，他安静地走到客厅，找了一小会儿，果然没找到饼干。
他随手拿了两块吐司面包走进卧室，脸上掠过一丝自信的微笑。“小子，没有饼干了，吃点面包填肚子吧！”老余边说边把吐司塞到小孩手中。
果然，小孩接过面包后就不再哭闹了，吃完一片就乖巧地躺下。不一会儿，老余家又归了平静。
分析
从故事中我们可以看到：
- 小孩子提了一个需求，即要吃饼干。
- 而妈妈考虑的是，家里没有饼干了，并且是半夜，想要实现这个需求的话，肯定还要起床下楼，并且找到24小时营业的便利店。这个实现成本太高了，于是断然拒绝。
- 而爸爸则透过现象看本质，小孩子半夜要吃饼干，这并不一定真的是想吃饼干，极有可能是饿了。这样的需求，可以通过其他更易实现的方式更好地解决。于是，随手的两块吐司面包，就让这个家庭又重归了平静。
典型的三类人群
孩子=客户
那你也许会问，为什么小孩子不能够直接说“我饿了”，而是一定要“吃饼干”呢？
因为，这就是典型的客户思维方式。
我们先给出这样一个结论：在方案级的探讨，客户是感性的；而在问题级的探讨，客户是理性的。
你是否有过这样的经历：
客户说，xxx功能我们想要，你给我们加一下吧。
这样看似非常明确的需求，但往往很容易发生颠覆性的需求变更，到最后客户自己明确说明的这个功能，自己又把它给亲手砍掉。原因可能很简单，也许就是三个字：不好用。
这种经历，能给我们带来什么样的启发呢？
这句话很关键：客户是问题专家，而非解决方案专家，他提出的方案未必能够完美解决他遇到的问题。
小孩子提出想吃饼干，这是一个方案级需求，这极有可能是