文章作者基于自身实践经验，为大家分享了一个需求分析模型，希望他能够给你带来一些启发和帮助。

记得多年前我参与的一个行业2B的大型系统建设项目中，从启动到系统割接上线花了2年时间，需求分析就花了1年时间，而后一年需求争论和变更就从来没有停止过。

一直困扰研发人员的问题是就在系统上线的前一天需求还在变动，只是大家已经达成共识，为了保证系统正常稳定上线，我们建立了需求基线提前3个月就关闭新需求在上线版本体现，而是放到后续版本中，所以可以说需求就没有停止过变更，而上线后系统稳定，但甲方业务部门却抱怨这不是我想要的系统，我的需求不是这样的。

可能你也经历过相似过程，甲方和乙方都很辛苦2年的时间加班加点是常事，不断的开会讨论和需求确认，而且双方都为系统上线投入了大量的成本和时间，但却很难得到使用方的业务认可（但非常认可我们的工作态度）。

这个过程到底发生了什么呢？我们的需求访谈、收集和分析难道不够细吗？还是客户本身就是不可能满足的（因为他们经常善变）。

有经验的项目经理会告诉你们要用需求确认的方式逐条同客户进行需求签字确认，确保后期客户需求变更的责任划分，但这也不能阻止我们研发出来的系统并不是让客户欢喜雀跃的系统，而是一个平庸的系统。

这个问题其实本身也是软件工程一个一直存在的普世问题，无论我们如何改进软件开发过程（传统瀑布式、螺旋，敏捷开发模式等），而真正在项目实践中总有这样或那样问题涌现出来，这些研发模式总会感觉实践起来困难重重。

我们开过手动挡车的人都有这样一个体会，学开车或者是开好车最关键的其实并不是在驾校中学到的流程，规则或操作步骤，而是我总结的两种感觉，一个是：“机械感”，一个是：“路感”，“机械感”负责你对车这部机器进行操作的机械反馈的预判和掌握，负责你对车的控制力；“路感”负责你对道路反馈的预判和控制，是你对道路行驶的掌握。这些是你开车的细节，只要掌握这两个细节，你开车就会变得很容易。

为了说明需求分析中的细节决定成败，我再举一个中国足球的例子，大家都知道中国男足弱，但归结原因无非是足协体制，青训，教练，战术，球员不职业等，但我觉得中国足球最大问题是无“球感”，也就是对足球在身体各个部位接触反馈和预判和控制，而提高中国足球的方法是要拆解足球训练流程和步骤，专注在足球最核心的身体反馈训练上，过早开展技战术训练反而会影响运动员在球感上投入的专注，这也是日，韩虽然在足球体制和青训体制上世界一流，但为什么水平是三流的原因。

上面我讲的两个问题都是想说明决定我们项目成败的往往并不是宏观流程和步骤，而是实施细节和操作的潜意识。今天的主题就是想讲讲需求分析中的潜意识：需要2需求的动宾结构。

什么是需求？

市场营销学的解释是：需求是指人们有能力购买并且愿意购买某个具体商品的欲望。我们往往忽略需求的真实理解核心是：意愿，能力，商品。这三样组合在一起才是需求，用个公式表达什么是需求：意愿+能力=商品。

这里的能力指甲方客户购买力，如：财务能力，同时也指乙方提供客户购买意愿的能力，如：技术能力，资源整合能力等。在这点不容易产生误解所以我也不做过多描述，我将重点是阐述这个过程中最容易误解的意愿和需求这个话题。

客户意愿就是客户需要（need），是客户对于实现业务目的而产生内在意愿，比如：一个销售人员为了更有针对性的对客户开展销售，他必须要了解客户消费力。所以他的需要就是了解客户消费力。

需求（requirement）是：匹配客户意愿+能力=商品的过程，所以它是提供组合和匹配的结果，它不能从客户那里直接获取的，在过往项目中我们常常直接收集客户，然后将需求重组，归并同类项，从而形成系统功能。我们误解客户需要就是需求。

需要2需求模型

需要和需求是我们最容易搞混淆的概念，虽然在中文中他们很难区分，但在英文中区别还是比较明显的，需要（need）是动词，而需求（requirement）是名词，需要是指心理活动，以“我想。。。”，“我要。。。”开头的典型动宾结构，而需求则应该是具体包括了能解决客户需要，验证双方能力，最后提供具体功能的解决方案。需求是我们分析得到产物，所以我们常说的需求分析并不是分析的需求，而是分析的是需要。

为什么要咬文嚼字的去区分这个概念，这点为什么又那么重要呢？因为单纯开发一个系统确实没有必要搞清楚两者的区别也能上线运行，但如果不搞清楚客户的真实需求，就不能给他带来满足业务最佳实践的帮助的，就不是一个优秀的系统。

在行业2B客户的大型系统中，实际操作使用的用户是主要参与者和需要的提出者，但这些用户又常常给我们带来很多困扰，他们有多样化的角色，分工和不同的文化，社会背景，所以他们提出需要的规范并不一致，有些业务部门的用户提出的是含糊的需要，有些有IT背景的用户提出的又是比较细致的，符合他自己理解的需求（具体系统功能）。

对于构建新系统，新业务的用户常常提出的是需要，而对于旧系统改造，旧业务升级客户往往提出的是细致的需求，所以这就对我们的需求分析师或者产品经理带来了极大的挑战，对于需要和需求我们要怎么收集，整理和分析呢？下面我将用需要2需求模型来甄别和分析不同的需求或者需要。

需要，需求分析模型

上图给出了一个基本分析方法，通过需要如何分析成为需求，这是一个多年前我亲身经历的一个案例：

一次我在做需求收集的过程中，我询问一位客户的销售经理关于与销售管理功能相关的需求，我在同他的访谈中，他很快就给我了一个名词性需求：“一个实时销售额汇总报表”。

如果按照往常，我将很快收集该需求具体的维度、元素、统计条件、规则和实时性要求等，然后归档为报表需求，可是那天由于他是不假思索的脱口而出，直觉告诉我，这里边一定有故事（需求分析师有时非常像侦探，需要敏锐的嗅觉来探寻客户内在需求）。

我和他套了套近乎，然后点上一根烟和他聊了起来，具体就是上面图表中的步骤，他看似给了我一个需求（一张报表），不过我按照需要来处理，这样可以分析他真实的动机和系统需求。

不出意料，他之所以会提出一个实时报表需求，是因为他老板有抽查下属对实时销售额准确性的爱好。这儿插个不相干的话题，有些老板还喜欢随时问他部门经理，自己部门具体的人数是多少？特别是那种2，3百人的部门，你还真不一定答的上来（因为有人员进出，有些还在流程中等），传递一个这类情况的回答经验，无论正确与否，回答一定要肯定，不要含糊其辞，原因自己琢磨。

回到正题，通过三三法则，暨：三个洞察why，给客户三个解决方案评估，最后真正需求逐渐浮出水面，因为下属的工作过程对老板缺乏透明性，所以老板只能靠最简单的报数字游戏来检验下属是否认真。所以核心功能是提供一个销售经理巡店轨迹上传的功能，来解决老板对于日常管理的关注，最后至于销售额统计报表还要不要就仁者见仁智者见智了。谁知道从一张报表到一个巡店轨迹上传这两个完全不搭界的功能还有如此联系呢？ 一个小知识点，客户的报表需要往往是最容易隐藏内在需求的地方，当你接收到大量报表类需求的时候，你就要认真考虑一下这里边是否有故事了。

总结一下：

客户提出他们所谓需求的时候，往往有两类情况：

• 第一类是对于系统功能没有具体想法，只能用我想。。。，我要。。。这样的动宾结构来描述自己的心理需要。
• 第二类是对于系统有自己明确的看法直接提出系统需求，比如：一张报表，一个菜单功能，一个字段等名词结构。

无论是哪种情况，我们都需要按照“需要2需求模型”重新评估和分析，不能直接记录为系统需求，这种分析模式必须训练成潜意识，针对客户的需要多提几个为什么？只有通过为什么的挖掘，我们才能像侦探一下洞察真正的需求动机和诉求。培养需求分析模式的潜意识是关系项目成败的关键，当你接收到1，2百张的报表需求的时候你就该好好想想你有没有问过客户为什么？

#专栏作家#

黄锐，人人都是产品经理专栏作家。高级系统架构设计师、资深产品经理、多家大型互联网公司顾问，金融机构、高校客座研究员。主要关注新零售、工业互联网、金融科技和区块链行业应用版块，擅长产品或系统整体性设计和规划。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议