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

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

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

sikao

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

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

理想的开发过程大致如下(包含但并不唯一):

0

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

1

1.1症结所在

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

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

1.2对症下药

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

调研过程

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

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

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

需求分析

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

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

需求确认

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

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

内部沟通

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

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

需求变更

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

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

2

开发过程监控

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

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

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

2.需求分析

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

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

3

2.1需求概述

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

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

2.2需求分析

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

从要解决的问题看需求

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

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

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

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

从整体的观点看需求

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

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

谨小慎微,脚踏实地

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

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

3.总结

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

 

作者:张骞(微信号zhangqian9208),开创集团产品经理。一年产品工作经验。

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

您的赞赏,是对我创作的最大鼓励。

评论( 2

登录后参与评论
  1. 对,给到技术的需求应该无懈可击才好往下推

    回复
    1. 回复

      需求分析要防止各种坑,认识到本质需求才是根本

加载中