一、背景
首先我们看下这几个词的具体定义，弄清楚这几个到底是什么东西。
需求这个词，在经济学有一个明确的定义：一种商品的需求是指，消费者在一段时间内、在各种可能的价格水平下、愿意而且能够购买的该商品的数量。
显然这个定义和我们在做产品的过程中的需求定义差异甚大，但对这个定义往下钻时，我们可以获得以下两个衍生概念：“动机”、“需要”。
- 从心理学的角度很好地理解“动机”：动机是由一种目标所引导的，激发和维持个体活动的内在心理过程或内部动力。
- 心理学中的“需要”是什么：需要，是人们身体内部的一种不平衡的状态，表现在人们对内部环境或外部生活条件的一种稳定的追求，并成为活动的源泉；这种不平衡状态包括心理的和生理上的不平衡。
仔细分析这两个概念，我们发现与我们日常中对“需求”的理解比较接近；由此，我们可以对产品日常工作中“需求”的概念能够有更全面的理解：用户购买商品的数量、使用产品的意愿、用户的动机、用户的需要我们都可以使用需求这一概念进行表达。
我们再来看看场景，从百度中我们找到场景的定义：场景，指戏剧、电影中的场面，泛指情景。
影视剧中，场景是指在一定的时间、空间（主要是空间）内发生的一定的任务行动或因人物关系所构成的具体生活画面；相对而言，是人物的行动和生活事件表现剧情内容的具体发展过程中阶段性的横向展示
对场景的定义主要用于影视行业，在互联网行业逐渐兴起后场景一词在IT团队中也越来越“时髦”；任何一个用户需求一定要找到用户场景才能发挥价值，没有场景的需求绝大多数都是伪需求；而在描述场景时，我们一定要清楚：什么时间什么地点发生了什么事，人物心情怎样，接下来他想做什么，会有什么动作，为了达到什么目的。
接下来我们看看用户故事，用户故事描述范式：作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>；用户故事就是从需求/场景中提炼出who、why、what三要素。
最后我们看下用例的定义，从百度获取的定义：是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。
Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。
用例这个概念本身是在软件工程中产生的，其核心是对用户和系统的交互过程的描述，一个用例能够清晰的表达用户使用一个功能的完成过程，包括：功能描述、步骤、前置条件、后置影响、特殊需求、异常处理等。
在对以上的概念做了初步整理后，我们再来看看这些概念如何在实际工作中进行使用。
二、在B端产品工作中如何使用
互联网行业的重心从消费互联网逐渐向产业互联网转变，在产业互联网时代互联网与传统软件逐步进行融合，在企业中B端产品业务越来越复杂、架构也越来越复杂、参与系统建设的人员范围也越来越广泛；如何高效的在这么复杂的环境中进行有效沟通显得极为重要。
而在这种环境中产品经理是作为需求方和IT团队的纽带，如果把产品岗位负责的业务进行领域划分大体可分为两个大的领域：需求域、实现域。
- 需求域需要解决的核心问题是保障产品方向的正确性，包括：调研、收集需求、培训、产品理念宣导等；
- 实现域需要解决的核心问题是高效、正确的把产品实现出来，包括：需求分析、评审、验收等。
在把产品的工作分为两个大的领域后我们在不同的领域中进行沟通时需要使用大家都可理解的通用语言，在于需求域中的各个角色开展业务时 我们需要从需求、场景的角度出发；而在实现域中我们则需要使用故事、用例进行说明，以达到系统被高度实现出来。
在于业务方进行沟通时，大多数业务方不具备IT经验，其无法理解系统背后的实现逻辑，只能描述自己在实际业务开展的过程中遇到的问题，或者是基于自己的经验、见识而提出的解决方案；这种解决方案往往只是业务方短期遇到问题而想要，是否是其真实的需求还有待考证。
但不管怎么样，这些问题、解决方案就是我们最常见的业务方表达需求的形式；在处理需求时我们最好的方式就是尽量全面、完整的记录业务方的表达内容，包括通过语言描述出来的或未描述出来的（业务方需求产生的环境、提出人的工作背景以及提出人所处组织的情况等）；对于需求我们最重要的要求是能够准确的表达用户的想法，至于想法是否正确、如何去解决者都不是需求本身需要去解决的。
在拿到用户的需求之后，我们即进入需求分析的环境，不管用户提出的需求是问题还是解决方案；在这个环节我们都不需要关心，我们需要通过场景去还原用户的需求，我们需要知道用户是在什么时候、什么地点、什么情况下产生的需求，并且能够对客户的预期进行分析，设计对应的反馈机制。
一个需求往往能够分解成若干个场景，但哪些场景是真实存在的、哪些场景是臆想出来的则需我们以日常观察、工作经验、对用户的分析以及对竞品的分析为基础才能够判断出来；但即使做了充分的分析还是有可能抓不到真实的场景，不过不要紧通过不断试错、不断的调整我们肯定能够找到真实场景；场景是对需求的转化，让需求更加的具体，以叙事的方式进行更细节的描述，场景是由产品经理输出能够让用户无障碍的了解需求中的细节，如果场景中有过多的专业术语、有很强的逻辑推理则不适合。
需求更多的是客户提出的，场景则是产品经理经过一定的分析后对需求进行拆解后的内容——这两部分内容的核心目是让我们能够和用户达成一致，确保产品的方向的正确性，保障我们投入资源实现出来的产品或者功能是客户真正想要的；在和用户确定了需求、场景后我们就可以对其进行更加细节、专业的分析了，把让用户能够理解的语言转化成让IT团队能够理解的内容，以让团队成员能够实施、落地。
首先我们需要用到用户故事，用户故事是有严格的格式要求的：“作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>”；它是以能够实现某种价值（用户能够获得效用）为标准去定义一件事的，不能交付价值的事件是不能称之为一个故事的；这样表述的好处是能够让我们清晰的知道这个故事要解决的实际问题，为了解决这个问题我们需要设计一个或若干个产品功能（对应的就是要完成的活动），而用户则通过使用这些功能就能获得预期的价值。
但一个完整的用户故事除了以上这些内容外，我们还需要清晰的定义设计的功能的验收测试标准，我们需要从正常、特殊、异常等不同情况下进行验收测试的定义；验收测试能够让我们清晰的定义出用户故事是否被完全开发完成，也能够让团队中的开发、测试同学更全面的理解故事，减少信息的不对称性。
通过以上这些内容我们能够大体把要实现的需求表达的比较清晰，但以上这些还不足以让我们最终开发出一个完整的系统，我们最终需要通过用例的方式把功能规格进行详细描述，在用例中我们更多是站在系统的角度考虑若何逻辑严密的把系统功能实现出来，我们需要考虑数据流程、功能结构、页面交互、信息呈现等方面的所有内容。
系统中不会无缘无故产生数据，要不是人对系统进行了操作，要不是指定了规则让系统能够自动运行，那从数据的角度看我们任何一个字段能够产生值一定是有事件触发，我们需要对这些事件进行描述。
一个系统如果在功能结构、页面交互、信息呈现这几个方面设计的很糟糕，就像我们开车走到一个昏暗且指示标记十分混乱的停车场；即使停车场设备再先进、车位再充足，司机也是难以感受到、享受到这种功能和服务，只有以符合用户使用习惯的方式进行设计最终才能让用户方便、快捷的使用系统完成任务、享受服务。
三、总结
通过需求、场景、故事、用例让我们实现了“从用户来、到用户去”的过程，产品经理最重要的工作之一无疑是沟通；而我们要实现高效沟通，则必须要让团队在同一领域中使用统一的通用语言，只有如此才能够让大家尽量做到无障碍沟通，实现信息最大化的传播、流通。
以上的这些内容则是笔者对团队统一的通用语言的一个整体想法，希望能够对大家有一定的帮助。