浅谈业务系统的用户调研与需求分析

2016-07-17 12:58:00

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

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

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

产品经理

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

产品经理

1.1症结所在

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

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

1.2对症下药

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

调研过程

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

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

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

需求分析

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

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

需求确认

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

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

内部沟通

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

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

需求变更

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

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

产品经理

开发过程监控

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

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

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

2.需求分析

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

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

产品经理

2.1需求概述

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

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

2.2需求分析

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

从要解决的问题看需求

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

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

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

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

从整体的观点看需求

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

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

谨小慎微，脚踏实地

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

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