前几天说了业务系统的产品设计，今天再来说说业务系统的用户调研与需求分析。业务系统由于其复杂性，在用户调研过程中往往容易被需求方带到坑里，对业务系统而言，只讲表面需求，对用户的表述奉行“拿来主义”，都是在耍流氓。

1.用户调研与开发流程优化

业务系统由于其复杂性，往往都是根据需求方深度定制，这就要对需求方进行调研。而需求方的想法往往天马行空、朝秦暮楚，若不能合理规划开发流程，则容易陷入每个阶段都在该需求的怪圈：程序员焦头烂额、怨声载道，需求方天天催促，产品经理里外不是人。

理想的开发过程大致如下（包含但并不唯一）：

但是理想与现实往往是有差距的，很多同学在用户调研时没有占据主动，那么开发过程可能是这样：

1.1症结所在

总结之前的项目经验，造成后期频繁修改的原因主要有以下几个：

• 调研中需求方需求表述不准确；
• 调研人员对需求分析不彻底，没有认识到需求本质；
• 产品方案与实际需求有偏差；
• 项目组内部（PM与开发人员）交流不畅；
• 出现需求变更时不能及时调整项目计划；
• 开发过程管控力度不足；

1.2对症下药

兵法有云：知己知彼，百战不殆。认识到了问题产生的原因，那么就要对症下药。要想在用户调研过程中避免被用户带进坑里，就要从调研过程、需求分析、需求确认、内部沟通、需求变更、开发过程把控六个方面入手。

调研过程

在调研时，用户所表述的需求未必是正确的需求（可能添加个人主观因素等），因此需要向尽可能多的用户了解需求。

在了解需求过程中要引导用户对需求的表述方式：比如A工作怎么完成，为什么要这样完成，其中的某个步骤是因为解决了什么实际业务的难点（痛点），而不是去听用户在滔滔不绝地讲他们怎么开展工作（此处可参考故事“我想要一匹更快的马”）。

绝大多数用户都不是专业的互联网人士，因此在调研和沟通时要占据主动，从专业角度给予用户引导和建议，否则很容易被用户天马行空的思维带到沟里。

需求分析

需求分析对产品经理而言是大坑，需求调研与产品方案之间往往不是简单的因果关系。

这就要求产品经理在整理和分析需求时要深入思考，不要执着于表象，具体在下面的章节会说到。

需求确认

产出原型和PRD之后，就需要进入需求确认的环节。需求确认的意义非常重要。这是后期需求变更或出现撕逼的有力证据。需求确认的常用打开方式一般是这样：①向需求方讲解产品方案；并打印书面的、含有原型截图的PRD；③由需求方签字确认，签字确认应包含签字日期。

需求确认旨在明确双方责任，并非借此保证需求一成不变。其作用是在需求出现变更时，明确因此对整个项目带来影响的责任主体，以避免出现需求方主动提出变更，但对项目工期不满意的情形。

内部沟通

俗话说的好：沟通不误开发工。内部沟通是避免出现项目组成员对需求理解不一致的重要解决方式。项目组内部往往包括产品经理、设计师、开发工程师、测试工程师等多种角色，若对需求的了解不统一，则容易在相应环节出现偏差，影响项目的正常进行。

因此，需求确认、需求变更等状况发生时，需要与相关人员及时有效沟通，同时要求所有相关人员在出现疑问时主动沟通而不是自我臆造，对于保证开发过程的顺利进行具有重要意义。

需求变更

需求变更在业务系统中是难以避免的，即使用户对原型及PRD进行了书面确认，但如果出现确认需求的相关人员对实际需求了解不够，或者用户在表达需求时有所遗漏，甚至于在开发完成后需求方修改了相关规章等情况，导致最终确实无法满足需求，那么修改仍然不可避免。

在需求变更时，需及时向各利益相关方告知需求变更事宜，并向需求变更提出方明确由此变更所带来的影响，包括新需求完成的时间节点，由此新需求占用的人力和由此需求变动造成的其他相关模块的变更，对既定开发计划的影响等。

开发过程监控

防范胜于救灾。对开发过程的监控旨在防止BUG，避免开发人员对需求理解出现偏差。应对开发进度进行每日回报，形成明确的疑问反馈机制。

过程监控并不意味着产出的完美无缺，但摸索到最大程度减少问题的合作方式，对于提高效率和需求方满意度是非常重要的。

在用户调研的过程中条条大路通罗马，能够将普遍性与团队、项目、需求的特殊性相结合，具体问题具体分析，找到最优方案，就是成功的调研。

2.需求分析

需求分析的难点在于用户表达出的需求未必是真正的需求，用户的表面需求往往隐藏着更深的本质需求。但是需求分析是工作开展的第一步，若需求理解过程中出现偏差，那么再好的产品设计、再好的原型，也是没有意义的。

写这一章其实是心怀忐忑的，作者和无数前辈大牛相比还是有很大差距，仅仅从业务系统的需求分析入手，谈一谈自己的看法，大家应以辩证、批判的角度去读。

2.1需求概述

需求是指用户的问题。对于业务系统而言，需求即业务的实现过程、原业务实现中的痛点。与互联网产品的区别是，业务系统的需求相对稳定，一般来说变化较少，而产品的生命周期则更多依赖于业务实现方式的调整。

相比于其他产品，业务系统的需求挖掘方式较少，而需求挖掘过程即调研过程，主要通过与用户深入交流、了解用户业务相关的规章制度（或行政业务的法律法规）、分析用户此前已经存在的业务系统、分析用户业务的发生场景等，本文对此不做赘述。

2.2需求分析

业务系统（平台）之所以称之为系统，是因为其业务、数据之间应该是互为关联而不是相互独立的，因此应该从整体的、全面的角度看待独立的需求。独立需求的特殊性共同构成系统的普遍性。

从要解决的问题看需求

这个观点想必对所有产品从业者而言都不陌生。需求的本质是为解决问题，但由于用户表达需求不明确、用户主观因素、或用户由于此前已经存在的系统形成思维定势，因此对用户的表述奉行拿来主义是不可取的。

在了解需求时，要通过刨根问底与业务场景分析，了解到实际的业务需求。产品设计必须建立在对实际应用场景充分了解的基础之上。

在与用户交流时，要根据实际业务提出自己更优的解决方案。从产品设计、流程优化、交互设计、工作协同、视觉设计、安全、性能等各方面对用户提出专业建议。

之前有同学与我交流时说起自己负责的项目，因为之前已有系统，用户的观点是按照原系统实现即可，其实从用户习惯的角度考虑并无不可。但一方面业务系统是往往是自上而下推动，另一方面，业务系统的出发点和落脚点是为更好满足业务。之前系统的交互方式已经融入用户习惯，可以参考，但若照搬照抄，新系统就很难发挥其意义了。

从整体的观点看需求

业务系统/平台的出现，尤其是对于存在多个分支机构、多类用户的系统而言，即将原来独立的业务使用云计算的形式统一起来。

该种情形下，不同独立的业务之间可能存在跨部门、跨单位协作，数据之间的互联互通。因此，需要从整体的观点看相对独立的业务，整合原本独立业务中相同的数据来源，删减冗余流程。

谨小慎微，脚踏实地

业务流程往往是通过相关规章制度而来，而规章制度往往会有明确的规定，比如业务发生的前置条件、业务流程节点的限制条件等，在需求分析时一定要梳理清楚，对系统中的条件限制是保障业务制度的重要方式。

但部分业务规章和实际执行过程中，往往由于实际业务发生时的复杂状况，不能完全按照制度开展业务，此时则需深入了解业务场景，保证业务的正常开展。

3.总结

业务系统相比于其他产品，有诸多特殊性。只有把握其特点，才能知己知彼，百战不殆。在任何时候，需求挖掘、需求分析、需求管理是进行产品设计的必要前提条件，对业务系统需求深刻认识的基础上，建立明确的需求池，按照优先级进行划分，才能为产品规划、设计打下坚实的基础。

 

作者：张骞（微信号zhangqian9208），开创集团产品经理。一年产品工作经验，曾负责山东省数字粮库业务管理系统的交互设计和山东省粮食流通管理云平台产品设计。

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