要想做出好的产品，前提就是要深刻的理解需求，需求不止是个问题，它贯穿了产品的全生命周期，它的形态不断发生变化。

需求是什么？需求本质上就是问题，问题是什么？问题本质就是现状和预期的差距，产品经理终其一生要做的事就是发现问题并提出问题的解决方案，同时让这个解决方案在商业上获得成功，这个解决方案就是我们所说的产品。

要想做出好的产品，前提就是要深刻的理解需求，需求不止是个问题，它贯穿了产品的全生命周期，它的形态不断发生变化，需求的变化过程也是从产品从一个初步构想的点子、到形成解决方案、完成功能设计到最后形成产品的过程。

1. 用户需求

随着产品的推进，需求形态也会发生变化，最开始的时候，当这个需求被发现时，我们管它叫用户需求，也许这个需求是运维或者市场人员传达过来的二手需求，也许是产品经理和用户调研后获取的一手需求，也可能是通过系统的数据分析得到的优化需求，本质上都是用户需求。

用户需求是最原始的需求，有以下4个特点：

（1）烟囱需求

这是一个特立独行的需求，类似的用户都没有这个诉求，完全是一个个性化的需求，用户的意图是追求满足个人的需求，而非满足带有集体人格的角色需求，这类需求被称为烟囱需求，在需求采集阶段发现了这类需求要果断抛弃掉 。

曾经我们做PMS系统，需要管项目的流程，一个项目可能涉及很多个流程环节，这些环节有严格的前后关系，有个别的项目经理提需求，希望能有项目信息补录功能，可以在项目执行完毕后统一补录，或者可以跳过某些环节。

显然这个需求不符合企业管理上对项目经理这个角色要求的定义，管理就是要固流程，规范项目经理的操作，领导可以实时看到项目的进展，如果按照某个项目经理要求开个后门，管理目标就达不到了，这个需求就是烟囱需求。

（2）重复需求

在需求调研时，从不同渠道、不同用户收集来的需求，可能存在很多相似或者重复的需求，这类需求在下一阶段需要进行合并处理，有时这些重复的需求带有一定的隐蔽性，只从用户的需求描述上感觉完全是两个不同的用户需求，但实际上是相同的需求。

这个时候就需要了解需求的层次，不能只看表面的需求，需要理解用户更深层次的需求，比如：一个用户说希望把某个功能菜单改为一级，另一个用户希望把这个功的菜单改为特殊颜色标志，只看表面确实是两个不同的需求，我们的解决方案可能最终按照用户的想法把菜单提升到一级并且修改了颜色，这么做是典型用户说什么，我们就做什么，最后的结果就是把系统做烂掉。

往深层次分析一下用户的动机，这两个用户的动机其实是一致的，都是为了快速找到自己常用的功能，只是分别提出了不同的解决方案。

分析到这个层次机会发现，要解决用户的这个问题，比较好的解决方案，不是改变现有的菜单体系，而是在个人首页单独增加一个快速菜单的入口，这是个通用的功能，用户可以定制自己经常访问的功能。

（3）矛盾需求

用户需求很多都是矛盾的，不同人提的需求有矛盾，比如：一个功能按钮的颜色，有的用户希望是灰色的，这样整体色调显得更协调，有的用户希望按钮颜色更深一些，可以更显眼。

还有就是一个人提的需求，前后存在矛盾的地方，针对这类问题一定要及时和用户沟通，有时候可能是表述上的失误，也有可能是我们理解上问题，一定和用户确认清楚。

（4）不可实现需求

用户一般不会考虑技术的可行性或者开发的成本，大部分用户都是不懂技术的，他们提出这些需求很多时候是被互联网产品教化的结果，用户接触太多互联网产品，总觉得实现起来都很简单，人家能做你们也应该能做。

比如：原来我们做订单管理模块，用户就说你们按照淘宝做就行了，有现成的可以借鉴，不用你们单独造轮子，这就是典型的不计成本，大公司互联网产品背后的研发团队岂能和一个项目组同日而语，遇到这这种情况也就只能呵呵了。

2. 业务需求

业务需求是对用户需求第一次过滤、分析后形成的需求， 业务需求本身并没有很抽象的功能设计，用户很容易看得懂，研发也能清晰的知道要做什么，所以业务需求更像一个用户思维和系统思维的转换器。

用户需求和业务需求之间的关系是多对多，也就是说不同的用户需求可以合并为一个业务需求，一个用户需求也可能拆分成多个业务需求，最终产出业务需求需要经过需求识别、场景分析、流程分析、数据分析4个步骤.

（1）需求识别

这个步骤就是对用户需求的重新筛选、整合的过程，去除技术上无法实现和烟囱需求、整合重复需求，明确矛盾需求，初步产出一个需求列表，这个需求列表还不是最终的业务需求，而是明确要做、能做、无歧义的用户需求。

（2）场景分析

对这些明确的用户需求通过具体的场景分析，明确产品的唤起点和唤起人，这个人就是角色，角色对B端产品而言非常重要，往往B端的产品涉及的角色更复杂。

场景的唤起存在主动唤起和被动唤起，主动唤起就是在某个场景下需要使用产品，比如：移动OA的主动唤起场景是用户在出差的火车上、被动唤起场景是系统的一条待办审批的短信通知。

另外做场景分析一定不要忘记例外场景分析，比如：我们设计一个工程现场管理的APP，要在现场采集一些施工检查的图片，很多时候施工都是在大山里，网络环境不好，如果连不上移动网络怎么办， 这个是时候就要考虑在网络不好情况下的缓存机制，后面可以直接将缓存数据导入PC服务端。

（3）流程分析

流程分析是对场景的细化，需要分析清楚具体的业务流程，这个流程不一定完全是系统流程，而是完整的业务流，有些需要在线下完成，有些需要通过系统完成，通过完整的业务流程分析，能够基本明确不同的用户通过系统需要完成哪些事。

流程也是分级的，管理级的流程看到的是端到端的业务线条，操作级的流程就是全流程中的一环。比如：采购过程从提出请购、采购方案立项到招标、是一个端到端的长流程，发出招标公告就是一个操作级的流程，由项目经理负责起草，相关领导审批后发出。

（4）数据分析

数据分析是在流程分析的基础上建立业务数据模型，明确每个流程的输入和输出数据，然后在此基础上梳理出整体数据模型，明确业务实体之间的关系，这个时候针对每个实体的属性可能并不全，没关系这是下个阶段的事，现在关键是要出一张完整的业务数据模型图。

是不是一定要用UML工具，我觉得也未必，UML是比较通用的语言，研发做设计是一定要用，描述需求只要能表达清楚，工具显得不那么重要。

3. 系统需求（项目需求）

系统需求一般是指针对某个项目的定制开发需求，所以系统需求也叫项目需求，这个时候完全是根据用户需求进行定制，不会考虑过多的灵活性、通用性、多版本。

业务需求要转化为系统需求还要经过功能设计、交互设计和数据割接设计3个步骤。

（1）功能设计

通过业务需求的整理，输出的是业务功能，而通过功能设计产出的是系统功能，业务功能和系统功能存在映射关系，一般也是多对多的关系。

举例说明，业务需求是一个报表需求，但是要在系统上完全实现这个报表需求可能需要很多个系统功能去实现。

• 首先分析这个报表需要展示的字段，目前系统数据不全，需要增加一个单独的采集功能采集更多的数据才能展示。
• 其次这个报表中的某些字段需要从现有的流程模块中提取，而目前流程模块记录形式不满足要求，需要对现有的流程模块进行功能优化。
• 最后这个报表的数据量非常大，可能是百万、千万级别的，目前的技术架构在性能上无法满足快速采集并生成数据报表，这个时候可能需要在技术架构层面进行优化，引入solr和es，可以实现数据的快速检索。

如果不在技术架构层面改造，也需要针对这种大数据量的报表增加定时处理功能，比如每天定时生成报表推送给用户，这在一定程度上也能规避性能问题。

经过分析发现要满足一个报表生成的业务功能需求，需要新增1个采集功能，1个定时报表生成功能、1个报表展示功能，优化1个流程表单，甚至还要优化技术架构。

（2）交互设计

交互设计这一步就是要根据具体的系统功能，由产品经理和交互设计师配合完成，通过交互设计输出原型，原型是系统需求的一部分，系统需求文档和原型设计才是一份完整的需求说书。

产出高保真原型的成本很低，针对B端产品我个人建议尽量产出高保真原型，很多时候需要和用户领导汇报，高保证原型是需求确认的最好方式，可以最大限度的避免需求理解的差异，减少后续的需求变更。

高保证原型大部分时候是由专职的交互设计师完成，产品经理和交互设计师对接的方式，根据不同的管理模式有差异。

如果设计师属于自己的产品团队，为了更高效的产出原型，产品经理可以通过白板画些草图就可以交付设计了，如果设计师是资源池共享资源，建议由产品经理先画一版线框图原型交付设计，当然作为产品经理具备交互设计师的能力，完全自己搞定也是可以的。

关于交互设计，相关的文章很多，我先前也写过一些类似文章，这里不再多说。

（3）数据割接设计案

这个步骤常常是容易被产品经理忽略的，总感觉这个是研发的事，实际在B端项目实施时，每次大的迭代都可能涉及到数据割接。比如：本次迭代设计流程变更，在原来基础上取消了几个流程环节，这些取消的环节可能在系统上线时候有很多正在处理的待办，这些待办如何处理？

一种方法是通知大家，在系统上线前人工把全部待办处理掉，还有一种方法就是把流程退回上一环节，取消当前待办，这就需要研发写个脚本在系统上线时统一处理，数据割接的业务规则，需要产品经理来定，研发给出割接的技术方案，最后由工程人员实施。

4. 产品需求

最后谈谈产品需求，产品需求是对多个项目需求的抽象总结，项目需求要干的事，产品需求都要做，功能设计、原型设计一个都不能少，除此之外有两个关键点，是产品需求有别于项目需求的部分，第一是需求抽象、第二是产品版本管理。

（1）需求抽象

产品抽象的初步目标是让系统的通用性更高，最直接的实现方式就是增加各种各样的配置功能，满足各种各样的需求，整个产品的灵活性更好，需求的响应速度更快。

产品需求抽象的最终目标是不断进行业务积累，逐渐形成自己产品线的业务中台。

比如：一个采购管理的产品，web门户、 采购订单、业务告警都是这个产品的功能模块，在这个产品里这些功能模块抽象程度很高，但是如果现在要做一个PMS系统，也会用到web门户，也需要对业务用户进行进度告警，直接把采购系统的功能拿过来没法直接用，还要进行大量的改造。

这时的办法就是把门户、告警单独提出来做成共享的产品模块，预留接口，不同的产品或者项目可以直接使用，可以快速完成不同项目的交付，所以做产品需求的目标是做中台需求甚至是后台需求。

（2）多版本

产品需求要考虑多版本，一个是按照市场定价，会有免费版、基本版、高级版等相关的版本，另外一个就是根据不同的行业划分不同的版本。

#专栏作家#

奋斗De奶爸，微信公众号：奶爸的小客栈（ID：naiba2000），人人都是产品经理专栏作家。10年以上产品、项目管理实战经验，关注企业供应链、数据中心、IT监控等产品，喜欢琢磨，希望把有价值的产品理念和实战经验传递给需要的人。

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

题图来自 Unsplash，基于CC0协议